|
Within ESX, there are many possible methods to perform a backup to a storage system. It is important to use a deterministic strategy to perform a backup and recovery analysis in light of the desired backup and recovery points. This should be done according to customer approved SLAs (Service Level Agreements) or goals in order to come up with a viable solution to minimize downtime and address these goals.
This document presents on a storage based backup solution for RDMs, which can be fully accessed via Fibre Channel or iSCSI. The method presented in this technical white paper produces the following benefits:
Zero downtime
Zero CPU load on host and guest
Zero network traffic
Instantaneous
24/7 backup window
No need for backup agent in guest
Systems administrators who have experienced problems with backing up VMs as physical servers have chosen to back up their VMware environment by backing up the files that make up the VM (the virtual disk files and configuration files). Backing up this data directly to tape drives results in the same problems as those encountered for traditional file-based backups. There is typically too much data behind each physical server to back up in a traditional backup window.
To maintain high utilization ratios, many customers have asked their storage vendors to implement some form of storage-based backup for their virtual infrastructure. With this method, the virtual machines are placed in a hot backup mode; the virtual disks are locked and all new data is written to temporary log files. Once in this state, the virtual disks are backed up. When the virtual disks have been successfully backed up, the locks are released and the contents of the temporary files are flushed back into the virtual disks.
Disk-based backup practices include copying the VMDK file from the production disk to a second set of disks, or, for customers who want a faster operation, some form of split mirror backup technology. Although both of these solutions provide a much faster backup than backing up directly from the production system to tape, both solutions require 100% additional storage for every backup, and that storage needs to be completed and kept online. This requirement for additional storage runs contrary to the utilization goals associated with VMware deployments and should not be considered. Some storage vendors offer copy-out snapshot technologies as alternatives to the 100% additional storage required with split mirror technologies. The I/O overhead required with copy-out snapshot technologies, and the subsequent performance impact, prevent these solutions from being implemented.
The inherent negative features of traditional disk-based backups do not apply to the NetApp patented Snapshot™ technology. With NetApp technology there is no performance penalty for taking Snapshot copies, because the data is never moved, as it is with copy-out technologies.
The cost for Snapshot copies is only at the rate of block level changes, not 100% for each backup, as with mirror copies. By combining NetApp Snapshot technology with VMware ESX server, administrators can back up their entire virtual infrastructure in seconds and support other data management possibilities. The NetApp Snapshot copies can then be backed up to tape and replicated to another facility with NetApp SnapMirror® or SnapVault. VMs can be restored almost instantly, individual files can be quickly and easily recovered, and clones can be instantly provisioned for test and development environments. OSSV can be incorporated along with Snapshot copies for a very robust solution.
This section describes the Loyola Marymount University IP SAN Architecture.
All ESX servers connect to a NetApp 3050 filer via an iSCSI SAN. In order to utilize VMotion, the ESX servers are all in one initiator group (igroup).
Each VMFS (VMware filesystem) volume is a LUN in the same flexible volume with its corresponding RDM LUNs. We limit the number of RDM LUNs in a single flexible volume because we want to limit the number of simultaneous VMware snapshots that the ESX hosts must handle. There is a maximum of 25 RDMs per flexible volume, and we store the vmx files in a VMFS LUN in the same flexible volume. That allows us to group VMs according to the flexible volume to which they belong. A 50GB VMFS volume is large enough to handle the vmx files, COW files and other configuration files used by ESX..
|
