Configuring Storage for High Availability
You have many options for configuring storage devices to support high availability (HA) in Sun xVM Ops Center. Storage that you use in an HA configuration must meet these requirements:
- Storage must offer data redundancy capability, such as mirroring or RAID 5
- Storage must be transferable between the primary and secondary Enterprise Controller systems
- Storage must offer performance that is sufficient to support Sun xVM Ops Center operations
- Storage must have the capacity to hold the data that Sun xVM Ops Center stores in the /var/opt/sun/xvm directory structure
Caution – You must configure the transferable storage on the system that you want to use as the primary Enterprise Controller before you install Sun xVM Ops Center software on that system.
A wide variety of storage solutions can meet these criteria, including hardware RAID arrays and external JBODs. Storage may be attached to the Enterprise Controllers using various means, including Storage Area Networks, or directly connected Fibre Channel (FC) or SCSI interfaces. You must determine what storage solution will offer the capacity, performance, connectivity, and redundancy capabilities required for use with Sun xVM Ops Center. This is true both for systems running the Solaris OS and the RHEL 5.0 OS. Configuration procedures vary greatly among the available storage solutions, and between these two operating systems.
Example Storage Configuration
The following procedure provides a simple example that uses a JBOD array and ZFS on Solaris systems to provide the required transferable storage. The example configuration includes the following components and connections:
- One Sun StorEdge 3510 Fibre Channel (FC) array (JBOD configuration) with 2 FC interfaces, and 12 146 Gbyte disks
- Two SunFire systems with the Solaris 10 OS installed, and one available FC interface each
- Each SunFire system is attached to one FC port on the array
In this configuration, both systems have access to all of the disks in the array. Using the FC ports in this way avoids changing interface connections in the failover procedure. You must be certain to prevent the two systems from using the same disks at the same time. In this example configuration, only the primary Enterprise Controller accesses the /var/opt/sun/xvm directory on the array.
The example array has no inherent data redundancy capability, so ZFS is used to create a mirrored storage pool, and a file system that will mount as the /var/opt/sun/xvm directory.
To resolve an issue regarding when ZFS and LOFS mounts take place in the system boot process, this configuration sets the mountpoint property of the example ZFS file system to legacy. The legacy value indicates that the legacy mount and umount commands, and the /etc/vfstab file, will control mounting and unmounting this ZFS file system. Other storage solutions typically use these legacy commands and the /etc/vfstab file to control mounting and unmounting operations. Refer to Release Notes for more information about the LOFS race condition issue.
To Create a Simple HA Storage Solution on a Solaris System
- Attach the array to the system that you will configure as the Enterprise Controller, and verify that the system can access the disks that it contains.
- Create the /var/opt/sun/xvm directory to use as a mount point for the file system that you create.
For example:# mkdir -p /var/opt/sun/xvm - Identify two disks of identical size to use to create a ZFS mirrored pool.
- Use the zpool command to create a ZFS mirrored pool named OpsCenter, with no mounted file system.
For example:# zpool create -m none OpsCenter mirror c1t65d0 c1t66d0 #
- Verify the amount of space that is available in the OpsCenter pool.
For example:# zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT OpsCenter 136G 72K 136G 0% ONLINE - #
In this example, 136 Gbytes of space is available in the OpsCenter pool.
- Create a file system named OpsCenter/xvm and specify legacy as its mount point.
For example:# zfs create -o mountpoint=legacy OpsCenter/xvm #
- Verify that the new file system exists and that its mount point is set to legacy.
For example:# zfs list NAME USED AVAIL REFER MOUNTPOINT OpsCenter 104K 134G 1.50K none OpsCenter/xvm 24.5K 134G 24.5K legacy #
- Edit the /etc/vfstab file and add an entry at the bottom of the file for the new ZFS file system.
For example:OpsCenter/xvm - /var/opt/sun/xvm zfs - yes -In this example, the device to mount is OpsCenter/xvm, the mount point is /var/opt/sun/xvm, the file system type is zfs, and the mount at boot option is set to yes.
- Mount the new file system, and then verify that it is mounted.
For example:# mount /var/opt/sun/xvm # mount (output omitted) /var/opt/sun/xvm on OpsCenter/xvm read/write/setuid/devices/exec/xattr/atime/dev=4010002 on Mon Feb 23 07:59:22 2009
- Use the following procedures to install and configure Sun xVM Ops Center Enterprise Controller software:
Creating a Storage Solution for RHEL 5.0 Systems
You must determine what storage solution will offer the capacity, performance, connectivity, and redundancy capabilities that are required for use with Sun xVM Ops Center. Contact Sun Support Services to determine a suitable HA storage solution for your particular installation.
HA Failover Procedures
You must determine what specific HA failover procedures to use for the HA storage solution that you decide to implement. The following HA failover procedures provide examples that are based on the storage solution for Solaris systems that is described above.
- HA Failover Overview
- Shutting Down the Primary Enterprise Controller
- Preparing the Secondary Enterprise Controller for Failover
- Transferring a Storage Asset
- Completing HA Failover
Contact Sun Support Services to determine the specific HA failover procedures to use for your particular installation.
Where to Go From Here
Return to High Availability Support, or proceed to Quick Start Guide for Solaris Systems or Quick Start Guide for RHEL 5.0 Systems to install the Sun xVM Ops Center Enterprise Controller software.