Replicating VM from SAN into ESXi 4 Local Datastore

[h4x0r]

Hi All,

I'm looking for your suggestion and advise in utilizing the empty unused Local SATA-II datastore for my VM.

I've got the following ESXi 4.0 build 164009 and a valid license of vSphere Essentials license, therefore I could use VCB but the problem is that using NBD from the SAN into the backup server is way too slow :-| it took 55 hrs to fullbackup the whole 1 TB VMFS partition (D2D over 2 network subnet).

and now I'm thinking that rather than using backup solution Is it possible to clone the VM on the fly to more than 2 datastore like clustering service fault tolerance? (in this case to local datastore and the SAN_VMFS) in case there is a failure in the SAN, the VM can run off the Local Datastore, well it doesn't have to be realtime though.

or perhaps there is a VCB backup that can copy the VM from he SAN VMFS into the local datastore vmfs ? that is also possible.

Any kind of comments will be greatly appreciated.

Thanks

[decepticon_eazy_e]

Hi All,

I'm looking for your suggestion and advise in utilizing the empty unused Local SATA-II datastore for my VM.

I've got the following ESXi 4.0 build 164009 and a valid license of vSphere Essentials license, therefore I could use VCB but the problem is that using NBD from the SAN into the backup server is way too slow :-| it took 55 hrs to fullbackup the whole 1 TB VMFS partition (D2D over 2 network subnet).

and now I'm thinking that rather than using backup solution Is it possible to clone the VM on the fly to more than 2 datastore like clustering service fault tolerance? (in this case to local datastore and the SAN_VMFS) in case there is a failure in the SAN, the VM can run off the Local Datastore, well it doesn't have to be realtime though.

or perhaps there is a VCB backup that can copy the VM from he SAN VMFS into the local datastore vmfs ? that is also possible.

Any kind of comments will be greatly appreciated.

Thanks

The problem with backing up the actual VM files is that they are running and constantly changing. You need an agent that will recognize this and deal with it, or that will stop the processes and run the backup automatically. You could clone it live and call that a backup, I suppose. I wouldn't call any of those options clustering.

VMFS is slow, VMware will admit that. But they didn't create it to be fast, they created it to be solid for the files to sit in. If your resources over commit and it starts a SWAP file, your server will CRAWL. The purpose is to keep files contiguous and ready to pull into ram. VMs don't run off the disk, they just sleep there. They get up and go to work in the RAM.

So you need to find an agent that understands VMs, typically we recommend backup solutions that run INSIDE the VM. Something more traditional like commvault or networker. These agents run on the windows OS and backup like they were physical machines. Rarely do we backup the VMDK files, especially running ones.

[h4x0r]

The problem with backing up the actual VM files is that they are running and constantly changing. You need an agent that will recognize this and deal with it, or that will stop the processes and run the backup automatically. You could clone it live and call that a backup, I suppose. I wouldn't call any of those options clustering.

VMFS is slow, VMware will admit that. But they didn't create it to be fast, they created it to be solid for the files to sit in. If your resources over commit and it starts a SWAP file, your server will CRAWL. The purpose is to keep files contiguous and ready to pull into ram. VMs don't run off the disk, they just sleep there. They get up and go to work in the RAM.

So you need to find an agent that understands VMs, typically we recommend backup solutions that run INSIDE the VM. Something more traditional like commvault or networker. These agents run on the windows OS and backup like they were physical machines. Rarely do we backup the VMDK files, especially running ones.

Yes, you could be right sir :-|

but since we have soo many VMs inside the SAN datastore backing it up to the NAS took soo long to finish ~ approx. 29 hrs which is over lapped 4 hrs.

see the current server deployment diagram, I make it easier for you to see the network connection.

The reason that I chose this configuration is that direct connection from the SAN into the ESXi servers without anything in the middle, can eliminate the single point of failure caused by the Switch and also provide redundancy.

each color in the iSCSI network is different IP subnet by itself. from the ESXi into the production network i put two cable connected to two different ports and then add those pNIC into same vSwitch for failover

Any kind of comments will be greatly appreciated.

[decepticon_eazy_e]

Yes, you could be right sir :-|

but since we have soo many VMs inside the SAN datastore backing it up to the NAS took soo long to finish ~ approx. 29 hrs which is over lapped 4 hrs.

see the current server deployment diagram, I make it easier for you to see the network connection.

The reason that I chose this configuration is that direct connection from the SAN into the ESXi servers without anything in the middle, can eliminate the single point of failure caused by the Switch and also provide redundancy.

each color in the iSCSI network is different IP subnet by itself. from the ESXi into the production network i put two cable connected to two different ports and then add those pNIC into same vSwitch for failover

Any kind of comments will be greatly appreciated.

If you really have a terabyte to back up, that's probably an accurate time. I really don't think backing up the VMFS partition is the best/fastest solution. There's probably a few servers that don't need nightly incrementals, so you could eliminate those. Then apply backup solutions to the VMs themselves. Find an agent that does a dedupe before sending the data to disk/tape.

You do have alot to backup, and perhaps outsourcing a solution would best if you're stuck. I think you have to put some serious money into this in some form, either prof services or backup software or backup hardware...