Backup Strategies for Integrity Virtual Machines

Transcription

1 Backup Strategies for Integrity Virtual Machines Introduction...2 Basic Aspects of Data Protection for Virtual Environments...2 Backup and Recovery from the VM Host System...3 Backup and Recovery of Individual Virtual Machines...3 Protecting the Virtual Environment Configuration...4 Data Protection Scenarios for Virtual Machines...5 Network Backup and Recovery...5 Statically Attached Device Backup and Recovery...6 Dynamically Attached Device Backup and Recovery...7 Volume Splitting on the VM Host...9 Consolidated Virtual System Backup from VM Host...10 Disaster Recovery, Ignite-UX, and Integrity Virtual Machines...10 General Guidelines and Suggestions...11 Storage Configuration for Reliability...11 Plan for Recovery of the Virtual Environment...11 Best Practices for Using EBS on Integrity Virtual Machines...11 Configuration Tips for Backup and Recovery Software...11 Summary...12 Conclusion...12 For more information...12 General information online...12 Documentation and white papers...12

2 Introduction Data protection arguably the most important aspect of data center management applies to any system whether it is physical, partitioned, or virtual. The architecture of HP Integrity Virtual Machines (Integrity VM) enables multiple approaches to data protection for virtual machines, providing the flexibility to apply existing backup and recovery solutions to your virtual environment. This white paper outlines various strategies for backing up critical data, including both the virtual environment definition as well as that used by applications running in virtual systems. By providing you with the advantages and caveats of each approach here, you may choose the best solutions for your environment. In illustrating the various backup and recovery (B&R) strategies, it is important to establish two basic concepts. There are two entities (manifested as agents, daemons, etc.) common to almost all Enterprise Backup Solutions (EBS). We will borrow terminology from the HP DataProtector software product to reference these entities. First, there is the disk agent an entity that writes or reads data to or from (disk) storage on a computer system and sends or receives that data to or from a media agent. The media agent is an entity that reads or writes from or to media in the backup device (e.g., tape) and sends or receives data from the disk agent. Graphics used to represent the disk agent (DA) and media agent (MA) entities Basic Aspects of Data Protection for Virtual Environments At a high level, the Integrity VM architecture consists of a VM Host system and the virtual machines often referred to as guests that run on that VM Host system. Figure 1 illustrates the relationship between these basic entities. Virtual disks on the virtual machines map to one of three basic storage types residing on the VM Host system: 1. Whole logical storage units, either entire disks or SAN LUNs, 2. Logical volumes, and 3. Files This fact provides the foundation for two basic data protection paradigms for Integrity VM environments

3 Figure 1 Generalization of Integrity Virtual Machines architecture. Backup and Recovery from the VM Host System Keeping in mind that a virtual machine s storage can be accessed from the VM Host system, one can imagine that backups run on the VM Host can also effectively backup storage on the virtual machines. This is true because the virtual machine s storage must be accessible by the VM Host system. From this perspective, the virtual machines are effectively applications running on the VM Host system and their storage is effectively the data used by those applications (virtual machines) while they run on that (VM Host) system. Most backup software will not archive any storage that is open for I/O by a process or application running on the system. This makes for a potential issue with backing up all virtual machines from one location the VM Host system without taking some additional actions discussed in below in the section Protecting the Virtual Environment Configuration. This paradigm will be referred to as backup and recovery at the VM Host level. Backup and Recovery of Individual Virtual Machines Another approach, arguably more natural when compared to data protection scenarios for physical systems, is to do backup and recovery of individual virtual machines. That is, each virtual machine s EBS configuration is effectively independent of the VM Host system. The basic difference between these two approaches is where the disk agent resides. For data protection at VM Host level, the disk agent resides on the VM Host system. Conversely, the disk agent must reside on each virtual machine in the data protection of individual virtual machines paradigm. Figure 2 summarizes these two basic paradigms.

4 Figure 2 Two basic paradigms for backing up an Integrity VM environment are: 1) backup and recovery at VM Host level (shown on the left), and 2) backup and recovery of individual virtual machines (shown on the right). Protecting the Virtual Environment Configuration Be sure to include the VM Host system s data, independent of the storage used by the virtual machines themselves as their virtual disks, in your data protection strategy. One of the distinct advantages of Integrity Virtual Machines is that you can use off-the-shelf EBS software to protect not only your virtual machines, but also the VM Host system. With Integrity Virtual Machines, the VM Host system runs a standard, albeit lean, version of the HP-UX operating system. As a result, you can use Enterprise Backup Solution that supports HP-UX, such as NetBackup and HP Data Protector Software, to protect the VM Host system s data including the virtual environment configurations. So far, the focus has been on protecting the data used by the virtual system and its applications. It is critical to include protection of the virtual environment configuration in your data protection strategy. That is, you must protect each virtual machine s definition virtual CPU counts and entitlement, virtual I/O device definitions, memory size, etc. so that you can reconstruct those virtual machines in the event of a disaster. Configuration files that reside on the VM Host system in the directory /var/opt/hpvm contain these virtual machine definitions. Because some of the configuration files may be open (e.g., the VM may be restarting, causing the configuration file to be opened for reading), it is a good practice to take a snapshot of the /var/opt/ hpvm directory periodically. You can accomplish this with the Enterprise Backup Solution s open file management capability. Alternatively, you can explicitly create the snapshot independent of the EBS software. For example, create a snapshot of the /var/opt/hpvm directory in the file /var/opt/hpvm.tar with the tar utility: # tar cf /var/opt/hpvm.tar /var/opt/hpvm Then be sure to include the resulting snapshot (in this example, /var/opt/hpvm.tar) in the backup configuration for the VM Host system.

5 Data Protection Scenarios for Virtual Machines The recent releases, 3.0 and 3.5, of Integrity Virtual Machines delivered new functionality in areas that directly benefit data protection strategies for virtual systems, including: Attached I/O device support for tape drives, media changers, and optical media burners, Online add and delete capability for virtual storage devices, Accelerated Virtual I/O devices, Boot-from-tape capability. By leveraging these capabilities, you have many choices for protecting data used by virtual systems. In the following sections, you will find several scenarios including general configuration examples and approaches. These scenarios serve as examples and are not an exhaustive list but rather a summary of practices that you can modify as necessary to fit into your overall data center protection practices. Network Backup and Recovery You can achieve virtual system data protection via network connection with a disk agent in the virtual system connecting to a separate system where the media agent resides. The virtual systems do not need a direct connection to an attached device (e.g., tape drive), nor does it require media agents in the virtual systems. Figure 3 shows the media agent residing on a physical system connected to a storage system, but this system could also be a virtual machine with an attached device connection as outlined in Figure 4. Figure 3 Network backup and recovery for virtual machines

6 Statically Attached Device Backup and Recovery Having a virtual machine serve as the backup server is, in a sense, a variation on the network B&R strategy. You may configure such a scenario so that only a single VM need an attached device connection while not requiring a physical network adapter. With such a configuration, the backup and restore traffic is isolated from the public LANs both virtual and physical in that environment. Another advantage to this arrangement is that a media agent is only required on the VM with the attached device as illustrated in Figure 4. Note that an attached device is not limited to a locally connected tape drive, but may also be an individual LUN connected to tape drives, media changers, or optical media burners on storage systems. Figure 4 Backup and recovery of virtual machines using attached device capability

7 Dynamically Attached Device Backup and Recovery By taking advantage of the online add and delete capabilities of Integrity VM attached devices, you can avoid network connections for B&R altogether. While attached devices cannot be shared amongst virtual machines simultaneously, they can be accessed exclusively by individual virtual machines without having to restart them. You can automate the online addition and deletion of the attached device by leveraging pre-exec and post-exec scripts executed by the EBS software. As shown in Figure 5, this does require both a disk agent and a media agent in each virtual machine, but it does not require a network connection. You will be required to define the backup configurations for each virtual machine so that the EBS software does not attempt to initiate the backup of more than one VM at a time on a single VM Host system. Figure 5 Backup and recovery of virtual systems using OLA and OLD of attached devices Note that you will need to define your pre-exec and post-exec scripts to execute on the VM Host system. Use the hpvmmodify command to add and remove the attached device. For example, if you are using a tape drive that corresponds to the path /dev/rscsi/c0t1d3, then add the tape drive to the VM named vmdev1 with: hpvmmodify P vmdev1 a tape:scsi::attach:/dev/rscsi/c0t1d3 Subsequently, you remove the tape drive from vmdev1 using the following: hpvmmodify P vmdev1 d tape:scsi::attach:/dev/rscsi/c0t1d3

8 Volume Splitting Inside the Virtual System Another popular approach to data protection is the notion of volume splitting which draws on data redundancy capabilities to take snapshots of data storage volumes at a given point in time. After the split occurs, the volume management software typically tracks the changes made to the volumes so that, subsequently, the volumes are merged back together. By periodically splitting and merging volumes that correspond to storage on separate storage entities you effectively create backups of the data residing on those volumes. There are many different implementations of such technology, many of which have a logical implementation, so that they are independent of the specific storage devices involved. HP s Logical Volume Manager is one example of such technology, which provides the capability to split a volume (lvsplit command) and then merge (lvmerge command). Figure 6 provides an example configuration for such an approach. You typically cannot use volume-splitting technologies that rely on specific storage devices or the behavior of a device driver when the storage is virtualized. Figure 6 Volume splitting inside a virtual system. Note that the split volume or device may be backed up to a physical tape (or other media) before the merge and resynchronization.

9 Volume Splitting on the VM Host Let us now explore virtual system data protection through the VM Host. You can protect the virtual system s data can be protected in a similar fashion by taking the volume-splitting concept down to the VM Host level. The major difference between this approach and splitting volumes inside the virtual system relates to the application using that data. As illustrated in Figure 7, only one virtual disk may correspond to a volume on the VM Host system. In order to get a consistent snapshot of the virtual storage, one must disconnect it from the virtual machine. To do so, you may dynamically remove the virtual disk from the virtual system which requires transitioning the state of all applications using that virtual disk so that I/O transactions cease. This removal flushes all I/O transactions from the application and the virtual system out to the volume. Next, you merge the volumes, synchronizing the physical storage devices with changes made to the volume. After the merge, split the volume again and dynamically reconnect the corresponding virtual disk to the virtual system. Subsequently, the application using that storage resumes execution. Unfortunately, you cannot disconnect a virtual machine s root disk; hence, one may not back up a virtual machine s operating system storage using this approach. In this case, you must shut down the virtual machine before backing up that storage using the volume-splitting approach outlined above. Figure 7 Volume splitting at the VM Host level. Similar to splitting in the guest, one may want to back up the split volume to tape or other media after the split.

10 Consolidated Virtual System Backup from VM Host You can simplify your backup approach by consolidating all of your virtual system backups by using the VM Host system as a single client for data protection purposes. To do so, you must make sure that the virtual systems have completed all of their I/O transactions by either disconnecting their virtual disks or by shutting down the virtual machine and its operating system. Backup and recovery software with the pre-exec and post-exec capability discussed earlier facilitates such an approach. After disconnecting the virtual disks by either online removal of the virtual disks or halting the virtual machines the backup executes on the VM Host system. Once the backup completes, reconnect the virtual disks and resume processing inside the virtual machines. Figure 8 Consolidated virtual system backup from the VM Host Disaster Recovery, Ignite-UX, and Integrity Virtual Machines You can use many of the backup and recovery scenarios discussed above to create a disaster recovery solution, especially with regard to application data. When considering operating system recovery perspective, you may find it appropriate to investigate additional, complementary software. For virtual systems running HP-UX, Ignite-UX addresses the need for system administrators to perform operating system recovery. Ignite-UX provides tools to archive, i.e., backup operating system configurations that you can use for system recovery or replication. Periodically, you may use Ignite-UX tools such as make_tape_recovery and make_net_recovery to create operating system archives. Version 3.5 of Integrity VM supports the capability to boot virtual machines from a tape device, enabling both a tape and network approach to system recovery for your virtual machines.

11 General Guidelines and Suggestions Based on the scenarios presented here and some practical experience, there are some data protection guidelines and pitfalls in a virtual environment you should be aware of. Storage Configuration for Reliability In several figures above a subtle but important storage configuration detail is illustrated whenever mirroring inside the guest, take care that the virtual disks in that mirror map to storage entities on separate physical storage devices. Otherwise, the backup and recovery strategies for volume splitting will fail to provide the data protection you are trying to achieve. For example, suppose that the two virtual disks shown in Figure 6 map to logical volumes instead of LUNs. If those logical volumes reside on separate disks or LUNs, then splitting the volume inside the guest will succeed in protecting your data. However, if those two logical volumes reside on the same disk or LUN then your data is at risk. This is because a failure on that physical disk or LUN may corrupt or destroy data on both those logical volumes. Plan for Recovery of the Virtual Environment A good approach to protecting your virtual environment is to combine incremental backup practices with disaster recovery planning. That is, in addition to regularly scheduled backups for the virtual machines and the VM Host system, you should also consider periodically creating a recovery image of the VM Host system. In doing so, you may fully recover the VM Host system in the event of a disastrous failure on the physical system while also enjoying the granularity and flexibility provided by the EBS software. You can create recovery images with the Ignite tools mentioned above. An alternative is to use the dynamic root disk capabilities on the VM Host system. Using the drd (q.v.) command, one can create a recovery image of the root disk on the VM Host system that may be subsequently used to recover the VM Host system in the even the primary root disk fails for whatever reason. Best Practices for Using EBS on Integrity Virtual Machines The accelerated virtual I/O (AVIO) capability of Integrity VM provides significant performance benefit when backing up individual virtual machines. For best performance, define the virtual NIC used by the EBS software with an accelerated virtual I/O (AVIO) network adapter for best performance. By using AVIO storage adapters, you will incrementally improve overall performance and reduce load on the physical system. Configuration Tips for Backup and Recovery Software The AVIO technology operates to its maximum potential when transferring data from multiple I/O connections. Therefore, to get the maximum benefit from AVIO, configure your backups to use multiple streams at most one for each virtual disk. This will reduce the overall time needed to backup the virtual machine while utilizing the physical system s resources most efficiently. When using Data Protector you increase the number of streams by changing the concurrency setting, either per device or per backup specification. The concurrency per device defines the number of parallel jobs sent to a device. The concurrency per backup specification defines the number of parallel streams a backup specification can send. You can find details for configuring concurrency in the Data Protector Administrator's Guide. To increase the number of streams with NetBackup, you should increase the Maximum jobs per client global attribute in your NetBackup configuration.

12 Summary Data protection activities such as backups and restores will execute quickly and efficiently by practicing the following: Configuring the virtual NIC used for backups to use the AVIO network adapter, Using the AVIO storage adapter wherever possible when configuring virtual disk storage, and Enabling multiple, concurrent streams in the virtual system s backup configuration. Always check the support matrix provided by the EBS vendor for support of your environment. Many EBS vendors now provide a virtual systems compatibility statement in their support matrix documentation. Conclusion You have multiple data protection options for virtual systems with Integrity Virtual Machines. Unlike some virtualization technologies, you are not limited to a vendor-specific backup and recovery solution for your overall virtual environment. Quite the opposite actually as you may use the same hardware-independent data protection solutions such as those offered by Symantec and HP Software to protect your data and system configurations both virtual and physical across your entire data center. Before deploying an Enterprise Backup Solution in your virtual environment, be sure to consult the support matrices of that solution s vendor for details For more information General information online (HP Integrity Virtual Machines) ww.hp.com/go/dataprotector (HP Data Protector Software) ww.hp.com/go/ebs (HP Enterprise Backup Solutions) Documentation and white papers HP Integrity Virtual Machine EBS Solutions Guide (available from Successful System Recovery using Ignite-UX ( Using Ignite-UX with Integrity Virtual Machines ( HP OpenView Storage Data Protector Concepts Guide (available from Veritas NetBackup Backup Planning and Performance Tuning Guide (available from Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. Symantec, NetBackup, and Veritas are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners. Version 1.0, March 2008