Large FileServer - delta files and VCB

[KyleWeir]

I have a file server which at this point is spread across 3 lun's (two of which are 2TB each, which are set to independent, persistent) this was because when they were first setup it would right the changes to a delta file on LUN1, and never actually commit the data to LUN2 or LUN3 where the actual data disks are this is after 4-5 months when it filled Lun1 and we had to shutdown the server, which then took several hours to commit the data to the disks, now they are set to persistent to avoid this issue. Is this because I used 100% of the second two LUNs for both of the 2 TB vmdk files? or is it that there is a problem with vmware committing the changes to a vmdk file on a different lun?

And I realy need to be able to do is to backup the 2.6 terabytes of data we have in use on the system via our SAN we have VCB and are using dataprotector but other then vmware all of a sudden allowing us to talk directly from a vm to the tape drives. We were planning on using vcb_file but without snapshots VCB doesn't work. Currently as far as I know you can't take a snapshot with persistent disks, but I also can't afford the main file server going down for several hours. I am open to any ideas, at this point we are willing to do just about anything, we are even considering putting it back onto a physical box, just so we can back it up over the san. But we don't want to loose the HA of vmware, and a microsoft fileserver cluster isn't very appealing, but if we need to build a whole new sandbox for it, and move the data we'll do it. Any help ASAP would be appreciated.

[Lightbulb]

It is the "independent" part that is giving the hard time not the "persistent" :smileyblush:

What model and type of SAN are you using i.e. ISCSI. FC or NAS

[kjb007]

A couple of points here. Snapshots don't work on independent disks as pointed out already.

Second, delta files are created in your workingdir. By default, this is the same location as your vmx files, so if you change your disks out of independent mode, and do create snapshots on them, they should be created in LUN1, where your vmx file exists. You can change this default behavior, by adding a workingDir = "/vmfs/volumes/..." in your vm's vmx file. This will result in your delta files all being created in a new location. If you want all of the snapshots to exist with their respective disks, then you will have to manually edit the vmx file location, as well as the delta files themselves into the LUN/datastore you want to use for each.

-KjB

[KyleWeir]

We are using a FC SAN, at the moment I'm limited to 2TB luns (that's supposed to be upped to 8TB I think before the end of the year). I know there are things such as business copy, and other methods of backing up the whole LUN, but I need to be able to restore specific files, and I don't have the licenses for that.

Kyle Weir

[Lightbulb]

Well so much for SAN based backup methods.

You could go old scholl and backup the Fileserver VM using a client agent on the VM itself to a dedicated backup server, but that will cost $ and hit performance. Hmmm

[kjb007]

With that much data, you definitely want to be able to take incremental backups, so you'll need to get either a client in your guest, or change your disks to allow VCB file-based backups. Since you're using FC, I'd go with the VCB route. You can keep your data on the SAN, in the method of a virtual mode RDM, so the guest is still mapping directly a LUN on SAN, but then you'll also get VCB benefits as well.

2 TB LUNs are also huge, and I/O going through that large of a disk will be relatively sluggish as compared to smaller LUNs. If you can, I'd break it down into smaller LUNs, you can still use nested folders within windows, so that may be another way to break down your large LUN into smaller ones.

-KjB

[KyleWeir]

It's a 4GB FC path and the I/O is normally pretty low, but I know what you mean. Does anyone know what the limitations of virtual RDM's are? And why should I use that instead of a regular disk? Would using a vRDM disk eliminate the problem I had in the past of the data being dumped to delta/redo files and never being committed to the disk (after 6 months and no snapshots taken)? Is there a pro/con matrix or anything like that?

Kyle Weir

Senior Network Team

Lehigh County

kyleweir@lehighcounty.org

610-782-3828 (O)

610-770-6708 (F)

[kjb007]

A virtual mode RDM gives you access to a RAW SAN LUN with the I/O going through the ESX server. This allows you to use snapshots along with the disk, and if needed, to also implement SAN-based snapshots. You get to have the best of both worlds. As opposed to a virtual disk, which is visible through an ESX host vm. Since this is not a virtual disk anymore, you don't have the independent disk option, they are either physical or virtual mode RDM. Physical mode RDM would preclude snapshots as well.

You want to use vmware snapshots sparingly as the size is not limited with snapshots. In the case of backups in concert with array-based snapshots, you can create a snapshot of your vm's, then take an array-based LUN snapshot. Then, delete your vmware snapshot. You now have a filesystem consistent point in time restore of the data on that disk, and don't have the additional overhead of maintaining a long-term snapshot. This won't help you with file-based restore, but if you are utilizing vcb, the snapshots can still be taken, the backup done with VCB, and then deleted again. Both will work, one will be more efficient (this depends on the storage capabiltiy as well) for restores.

-KjB