1 person found this helpful
We have been testing it significantly. We have had good success but still feel there are some things to work out prior to putting it into production. We were replicating 4 VM's across a 10mb link so the initial pass took a very long time. We also adjusted from which hosts the vm's were being replicated from and to, as well as the VMFS partition (LUN's) they resided on to try to fine tune the performance. We did have one VM that didn't replicated the 2nd VMDK file associated with the VM upon subsequent passes. We are looking into that. Overall its a good product if it fits your environment and serves the purpose you are looking for.
After tearing the environment to the ground and starting over things started to work better the second time around.
But the one thing I don't like is the amount of console resources it uses. We were told to increase memory to 768 and to increase the console cpu reservation to 1200 mhz. During replication the cpu consistenly runs at >90%.
I really want to use this product and I'm hoping this works out.
>consistenly runs at >90%.
How have you configured the jobs? How many?
We haven't deployed yet, but are positioning/designing it into many solutions. Talking to Kix offline he gave some pointers;
\- keeping it to one replication job per core on the server
\- staggering replication passes
\- not replicating more than you NEED
\- using DRS anti-affinity rules to keep apart similar jobs (i.e. servers doing 15 min jobs)
I am really interested in your feedback. Some of the current designs have 30+ replicaitons jobs (mixture of 15 mins, 4 hourly and daily) so I need to sanity check! unfortunately a new product means no track record....yet.
yes and I get the impression from talking to others that the success of any replication type arrangment is dependant upon the overall health of your ESX hosts beforehand. if the hosts are choking then things like snapshot take and delete may fail due to console strain etc ...
At this point we are trying to replicate 6 vm's every 15 minutes. After letting them run over the weekend 4 are still running, one has completely stopped replicating, one needed to have the job re-created. The replicator processes esxreplicator.client.exe esxreplicator.service.exe were also hung and consuming 800MB of memory. The vm's are not production vm's either, just stand alone test vm's with pretty much no activity or change in them.
We have less than one replication per core since the box is dual quad core and we are only attempting the recommended 4 - 6 vm's. In reality we are looking at replicating close to 30 across several hosts for production but for now we are only testing with 4 -6 on one host.
That is the first I have heard of the anti-affinity rules, could you elaborate a little more please?
We are very interested in feedback as well, we are beginning to feel more comfortable with the product but not close to as comfortable as we want to be before going into production or giving to a client.
1 person found this helpful
- staggering replication passes
The problem with staggering is that there is no option for absolute scheduling. You can only schedule passes relative to the time the job completed last. So the schedules for all the jobs will eventually converge.
I was told that we should only schedule as many jobs as the host can handle at one time.
We are evaluating towards a purchase of replicator and have had mixed results. One big item we learned from tech support today is that when the replication job kicks off it has to scan for block changes since the last replication. The scan speed is 1.5gb per minute, so if you have a 15gb vmdk it takes 10 minutes before it sends data. We have also had issues with VM's crashing during the replication process (infrequently) Our impression is that this product is a work in progress and still needs some coding changes before it is ready for prime time. If someone comes up with a simple backup solution to a DR site that works consistently with ESX 3.01 they will make a fortune.
We have also had issues
with VM's crashing during the replication process
That must have nothing to do with esxReplicator. Perhaps it has to due with the snapshots and IO redirection? We don't touch the Guest OS.
esXpress is an awesome backup product which will backup your vm's to a DR site but they need to be restored once sent. It does changes only as well. Once the mass restore option is implemented in esXpress for VI3, then you wont need to manually restore them any more.
esXpress is not a competitive product to esxReplicator. esxRanger is.
The market is small for VMDK replication products. There DoubleTake (which just launched a v2), but it has major design flaws (requires snapshot in place permanently - scary!). Also Symantec's Volume/Cluster Thingy.
esxReplicator is the closest we have so far...and if Vizioncore's past devleopment lifecycle is anything to go by, features and improvements will come quickly.
well, he said backup solution to a DR site not replication and I much much prefer express to ranger for backups. It's just a more intelligent piece of software in my eyes. But thats an intel vs amd type discussion that I feel people just have their own opinion on and should use whatever best suits their environment.
But I totally agree that replicator is the closest thing to complete replication and I hope it does work out so we can push it out.
I think platespin is claiming to have something as well ... but I havent trialed it or anything.
I think platespin is claiming to have something as well
Repurposing an existing product to provide completely new functionality comes at a price. I'll leave it there.