Data disaster recovery has traditionally been a task reserved for a large IT staff in a large enterprise environment. However, SMB data is just as important to the SMB as large enterprise data is to the large enterprise. In many ways SMBs have the same disaster recovery needs that large corporations do, but they must be more creative as they tend to have fewer resources (staff, infrastructure, budget, etc.) to establish a disaster recovery plan. This is where a value-added reseller (VAR) armed with storage virtualization know-how and technologies can really be a boon to the SMB.
While a complete data disaster recovery plan is beyond the scope of this tip, with some proper application of virtual storage technology and creative planning, at least one part of the disaster recovery plan -- the technology infrastructure -- can be established.
A virtual storage infrastructure can help with any disaster recovery plan, even if you are not planning on taking advantage of virtual server technology. When thinking about disaster recovery, the storage infrastructure should create a flexible, solid foundation for the infrastructure anyway. A replicated storage area network (SAN) can make recovering from a disaster a quick process. An SMB will find that an IP-based (iSCSI) SAN provides the most flexibility, ease of use and the lowest price when compared to a Fibre Channel SAN. Besides, an SMB is more likely to have staff that knows about IP networking than Fibre Channel.
A few approaches could be used to build an iSCSI SAN. Use this step-by-step guide to weigh the options, prepare a hot site environment for data disaster recovery, and establish reliable remote access to data for business continuity.
| TABLE OF CONTENTS
Step 1: Choose a virtual storage approach
Step 2: Virtualize hot-site servers
Step 3: Set up remote access to hot-site servers
|Choose a virtual storage approach||Return to Table of Contents|
Virtual storage approach: Third-party iSCSI storage array
The third-party storage array will probably be less complex since most iSCSI arrays follow an approach that involves storage configuration, plugging into the network and repeating. If you need more storage you just configure a new array, plug it into the network and add it to your pool of storage.
Since SAN storage is virtualized and you carve up volumes any way that you wish, adding those volumes to a different server at a later date is trivial. Just tell the server to acquire a new iSCSI target. You can even replicate the volumes to an offsite hot site for disaster recovery purposes. Once a storage array has done the initial replication, most usually replicate only changes to data at the bit level. All you have to do is the initial replication and then ship the standby array to the hot site. From that point forward the replication is very efficient over the WAN. The downside for these third-party arrays is that they can be more expensive than a build-it-yourself solution. If you are interested in iSCSI arrays, two of the more well-known solutions are provided by EqualLogic, Inc. and Lefthand Networks.
Virtual storage approach: iSCSI bridge to connect storage
The advantage to this type of device is mainly cost. It is a little more complicated to set than a third-party iSCSI array. However, you can use pretty much any flavor of off-the-shelf storage that you would like. This could include SCSI or Fibre Channel attached. This brings the price down because you are not locked into a third-party vendor's proprietary storage product, but it has all the benefits of a virtualized iSCSI SAN, including off-site replication, virtual storage volumes and capacity add on the fly.
Virtual storage approach: Custom-built iSCSI SAN
The third approach is more of a custom-built solution than any of the previous storage virtualization tactics. You essentially need a server to act as the iSCSI target, and then coordinate storage virtualization and allocation to the infrastructure servers. You also need the iSCSI target software to install on the server and some storage to allocate. The servers, storage and software required for this approach can be even less expensive than the third-party array and the iSCSI switch.
Essentially the storage is attached to the iSCSI server, the iSCSI target software is installed on the server and the attached storage is presented to the file or application servers. This can be relatively easy to set up and it tends to be significantly less expensive than the other two storage virtualization options for the amount of storage that you want. However, this approach requires a server with an operating system that needs maintenance like all other servers with operating systems. This means patching and downtime. Depending on your environment, scheduled downtime may be acceptable. As in the other cases, the benefits of a virtualized iSCSI SAN are included.
|Virtualize hot-site servers||Return to Table of Contents|
So, let's say that you have a newly virtualized storage infrastructure provided by one of these three methods. You have the volumes replicated to an offsite hot site with standby infrastructure servers. If your main data center becomes unavailable, you can bring the hot site online and attach the standby virtual storage to the standby infrastructure servers. At this point you are back in business. However, depending on the number of infrastructure servers involved at the main site, reproducing the same environment at a hot site can be quite expensive. You either have to choose some of the most critical servers to reproduce or look for an alternative method to provide an identical hot site. This is where server virtualization technology can be beneficial.
With VMware ESX 3.0, you can virtualize your hot site servers by either converting existing physical servers with a P2V product such as VMware's Converter 3 or Platespin Powerconvert, or creating new virtual machines for the hot site. Then, you can maintain a few VMware ESX 3.0 host servers, rather than many physical infrastructure servers.
The combination of virtual server technology and an iSCSI storage SAN really becomes potent if your main data center is completely virtualized. One of the tricky things about a hot site is that you need to keep up with server changes (patches, etc.) at both sites in order for the switch to the hot site to be truly effective. If your main data center consists of virtual servers stored on an iSCSI SAN that is replicated to the hot site, you no longer have to keep up with server changes at both sites. The replication will take care of this for you. When you need to bring the hot site online, you will have an environment that is close if not exactly like the main data center environment.
|Set up remote access to hot-site servers||Return to Table of Contents|
You have the data center taken care of at the snazzy new hot site. How will client users access their data and applications if their desktops, laptops or thin clients are unavailable? Since we can't have the users logging in locally to servers, we will have to come up with another option. Besides, the hot site may become an uncomfortably hot site if you try to pack all users into the server room.
There has been a lot of talk lately about Virtual Desktop Infrastructure (VDI). This involves hosting a Windows XP or Vista desktop environment as a virtual machine in the data center. The users then connect to these virtual machines via Remote Desktop Protocol (RDP). If this RDP connection is Web-based via Citrix or some other means, then the users can use pretty much any computer with an Internet connection and a browser to securely connect to their desktop environment almost as seamlessly as if they were at the office. Traditionally VDI requires a lot of storage capacity because a separate virtual hard drive needs to be created for each virtual desktop machine to be hosted. However, a product called Ardence Software-Streaming Platform considerably reduces the storage requirements.
Ardence allows you to maintain a single virtual image of an operating system, such as Windows XP. The machines that network-boot(pxe) using Ardence will share the same image. The client session is cached on the booting machine in RAM on the hard drive or on the Ardence server. This means that a single 10 GB virtual image can be shared among many VMware virtual machines if they pxe-boot using the image. So use an Ardence server at the hot site serving up a virtual image to some VMware virtual desktop machines. These virtual desktop machines (VDI environment) can then be presented to the users via Web-enabled Citrix or some other means. Instant office environment!
In summary, virtual storage always brings many flexible options to the table when planning for disaster recovery. You should carefully consider what you are trying to accomplish for your client and help them weigh the options against their budget. A holistic solution including storage, server and desktop virtualization will provide a smooth transition for users should their resources at the main site become unavailable. As a virtualization-savvy VAR, you can help the client really shine when it comes to data disaster recovery planning.
About the author: Harley Stagner has been an IT professional for almost eight years. He has a wide range of knowledge in many areas of the IT field, including network design and administration, scripting and troubleshooting. Of particular interest to Harley is virtualization technology. He was the technical editor for Chris Wolf and Erick M. Halter's book Virtualization: From Desktop to the Enterprise and currently writes his own blog at www.harleystagner.com. Ask Harley your server virtualization questions today.