Use native tools for your infrastructure services
For IT services you provide, take the time to identify your key critical Infrastructure services and architect them run in parallel in both data centers. Then build your core services like groupware (email) and enterprise databases and have them perform native mirroring between the two sites. While email and database mirroring are different topics beyond what we are talking about in this tip, a good example would be native SQL mirroring for your databases to a remote database server. In this way, the core of your IT environment would be available at your RDC without implementing solution that is not supported by your database vendor or the email platform.
Server roles such as domain name service (DNS), Active Directory, and dynamic host configuration protocol (DHCP) are great candidates for virtualization in the RDC. This would entail having a smaller version of your virtual environment in the RDC. Providing this additional
Should you be in a contingency situation, these lesser important systems can be shut down to make way for the mission critical virtual machines. If you are looking for one tip to spend a lot of time in the planning stage, it would be very wise to have good naming conventions and DNS entry logic to ensure easy switching between the two sites. The use of DNS canonical name (CNAME) records assist in this very nicely.
Determine critical application servers
Take an assessment and determine what systems are required for your organization to make money (or whatever it takes to execute your mission statement). And once you have set up mirrored copies of your core infrastructure systems - what does this now include? Of course all of your direct line of business applications, but does it include all of your evaluation or test systems – probably not. That is why they may be good candidates to run from the RDC as the normal procedure. Should the primary data center not be available, these lesser tiered systems can be offline as the business critical systems are made available in the RDC.
We always need storage
If you don't have remote SAN replication to another data center, you will still need storage available remotely. The RDC would not have to be SAN storage, but it would be ideal as you would not have to manage the local storage requirements for the critical virtual machine inventory. This may be an adequate solution for your RDC stop gap storage solution.
Storage VMotion from VMware
With the recent release of VMware ESX 3.5, Storage VMotion is now available. This allows you to migrate running virtual machines from one logical unit number (LUN) on a SAN to another or other attached shared storage. This opens many new options for administrators to meet their RDC or disaster recovery requirements. The key behind this advantage is the VMware disk snapshot technology. The only negative to Storage VMotion is that right now it must be administered through the VMware remote command line interface (remote CLI) and is a separate download from ESX 3.5 and Virtual Center.
You can get fancy – or not
One option available to VMware environments is to use the VI Perl Toolkit. The toolkit was first mentioned on the Search VMware.com blog by Andrew Kutz "Why you should listen to me" and boy, does this get the creative juices flowing. Simply speaking, the VI Perl Toolkit can perform many tasks automatically including cloning and migration tasks within VMware ESX. This can be a very sophisticated way to move virtual machines around automatically within your VMware environment.
However, the solution may not need to be as daunting as it may seem. Your standard operating system backup and restore mechanism may be the solution for the RDC. Most backup and restore mechanisms are thorough enough to offer a bare-metal restore or otherwise enable you to restore the system quickly. Should you have the network bandwidth to back up your most critical systems at your remote site, this standard mechanism may be adequate for your needs. Being able to restore locally from a remote backup may meet the requirements you set forth in a RDC configuration.
Tools to get the job done
VMware Converter and PlateSpin PowerConvert can also be critical tools to your arsenal for RDC management. You can have standby copies of your most critical virtual machines available by using these tools. The PlateSpin PowerConvert tool also allows you to schedule conversions of the systems to a virtual machine, so you can keep the environment up to date and leave the transient data to your normal backup and restore process. Further, you can use these tools to convert physical machines to virtual ones in the situation where you have a system that is not a good virtualization candidate – but would be acceptable in a contingency mode. Comparatively, selective conversion can be attractive to other more complicated replication mechanisms. Consider also that these tools can be used not only for physical-to-virtual (P2V) conversions, but also virtual-to-physical (V2P), physical-to-physical (P2P), and virtual-to-virtual (V2V) across virtualization platforms. This way, you can apply the same availability principles to non-virtual systems in the situation where your primary data center is not available and you do not have spare hardware for your critical systems.
Get a stopgap plan in place
Until you get the coveted SAN replication, these tips can assist you in delivering RDC capabilities. How are you handling alternate data center availability for your critical virtual machines without multi-site available storage?
About the author: Rick Vanover is a MCSA-certified system administrator for Belron p in Columbus, Ohio. Previous roles included software engineering roles with Siemens and Dematic in Grand Rapids, Michigan, working with complex supply chain execution systems. Rick has been working information technology for over 10 years and virtualization technologies for over seven years. He has been publishing articles online for over six years. This was first published in January 2008
This was first published in January 2008