How Storage Virtualization can help you Save Money on your VMWare VI3 Server Consolidation Project
I've been putting off writing this White Paper, pending inspiration and time. Alas, I'm a so-called "Road Warrior"
and while I'm grateful my boarding passes don't say "Platinum" or "Chairman", I'm still often on the road and have
little time to write these papers. I thought I'd take a pass at an outline and hope that the eloquence follows...
In a nutshell, if you're planning a server consolidation project, make sure you do it right: don't put all your
eggs in one basket. It's bad enough having a failed Voltage Regulator take out your Exchange server, but in the
Virtual Machine world, such a physical hardware failure could take out the Exchange server, the three SQL servers,
the Web server, the DNS/DHCP server, the whole shop! Yikes! [Don't laugh, I've had customers who took virtualization
to the extreme: even their DNS server was running as a VM... NOT what I would
call a "Best Practice".]
So my recommendation is this: make sure you implement a "Highly-Available" server consolidation: separate your eggs
into at least two baskets, and with the ability to move them from basket to basket as needed. In the world of VMWare,
that means "VMotion". And VMotion means "SAN required". Now before you say "I can't afford a SAN" and close this
browser page, let me assure you there are ways to do this without giving the 3LA's (Three-Letter-Acronym Vendors) big
bucks. Furthermore, what I am about to propose will allow you to achieve a level of availability you wouldn't have
even if you could deploy the costly EMC CX!
Building a Highly Available SAN on a Limited Budget
The solution I am going to propose for the SAN is a "virtual" solution. It is a software solution
from a company that specializes in Storage Virtualization. It makes sense that if you are going to
virtualize your servers, you go all the way and virtualize the storage, too. (And the desktop, for
[Discuss synchronous data mirroring between two physically separate SAN storage arrays and
how to implement with SAN storage software for under $10K. C.f. SANmelody by DataCore.]
For a concrete example of how to build a SAN using ordinary x86 architecture servers and SANmelody software,
read my White Paper "How To Build A Low-Cost High-Performance iSCSI SAN using Dell PowerEdge PE840 Servers."
Combining Redundancy with Physical Separation for Extreme High-Availability
One of the most common mistakes I find when visiting data centers is the tendancy to rack redundant or clustered
servers one on top of the other. The proximity means that the redundancy will only protect against internal server
failures. If a localized incident occurs (water, fire, structural damage, etc.), it can easily take out both
servers. Even separating redundant servers by a few feet in different racks can make a big difference in
In terms of server and storage virtualization, this translates to separating both the ESX servers and their redundant
SAN attached storage. Using Synchronous Data Mirroring between two SAN storage arrays as described above means your
VMFS data is always available to all of your ESX servers, even if one of the SAN storage servers (or its site) fails.
Use Thin Provisioning to Decouple Server Sprawl From Storage Capacity Requirements
In larger datacenters, one of the challenges that faces administrators in the virtual world is that of
"Server Sprawl": it becomes so easy to deploy new servers that VMs proliferate rapidly. While the administration
of all those VMs may become a daunting task, the real problem becomes one of storage resource management.
Each VM will require at least one VMDK, a disk file that represents the server's "hard disk" or "C:" drive. As you know,
most servers typically have more than one: the system drive and then one or more data drives. In ESX, the VMDK uses
real space out of the VMFS volume. If your new VM needs a 12GB C: partition for the Windows 2003 R2 install, that
means you'll be allocating 12GB of disk space for the VMDK. In reality, the Windows 2003 R2 install takes less
than 4GB, meaning about 8GB worth of space is wasted.
is a feature of some advanced Storage Virtualization packages such as the aforementioned
SANmelody™ package. With
Thin Provisioning, pooled storage is allocated in small chunks (called "Storage Allocation Units") on an as-needed
basis. You create a large disk or "virtual volume" for your VMFS file system, but in reality, the disk is only
an empty geometry. Storage will be allocated chunk by chunk as your ESX servers write data into the associated
With Thin Provisioning, creating a 12GB VMDK file doesn't actually allocate 12GB of space from the pool.
Only when you install Windows will Storage Allocation Units be assigned to the VMFS volume to satisfy the
write requests. When the 2003 R2 Installation is complete, you'll note that less than 4GB have been allocated.
Combining VI3 RDM's with Thin-Provisioned Snapshots is yet another way you can make your storage go much
further: several unique boot volumes can share the same physical disk space.
Flexible, Scalable Software Solution Grows, Adapts to Your Organization's Needs
[It's software. You can install it on your preferred server platform. You can repurpose your existing
servers to host the SAN Storage Virtualization software as you implement P2V and decommission servers.]
Integrated support for both iSCSI and Fibre Channel allows you to mix and match media.
[iSCSI is all you need, but be reassured your investment is future-proofed. If you later want to implement
Fibre Channel, just drop the FC HBA's into your SANmelody servers and ESX servers and you're good to go.]
Asynchronous Replication to Remote Site for Implementing DR Plan
[Discuss best practices, including
- Use of RDM's
- Keeping system and data and separate volumes
- Isolating swap space / page files to separate, non-replicated volumes.
- How to calculate Bandwidth requirements for replication.
- Use of Thin Provisioning to improve Initialization, re-synchronization
- Don't Defrag your volumes! It generates a ton of replication traffic!
[Discuss difference between BC and DR, also explain how to achieve both in the same solution (synch replication
between two live sites combined with VMotion). Example of township near Indianapolis that has done this between
Police Department and Town Hall using iSCSI over their existing fibre.]
Read my white paper on Best Practises for Asynchronous Replication in a DR Implementation
which covers many of these points in more detail.
Summarizing the Benefits of This Solution
IT Directors often need concise bullet points to sell their project to the folks that hold the purse.
Here's a first draft at that list. If you can think of others you would like to share, please drop
me a line using our contact form.
- Radically reduces datacenter footprint, electricity, cooling, administration, and budget for maintaining IT services.
- Radically reduces acquisition and administrative costs for bringing on new services.
- Facilitates implementing a Business Continuance and Disaster Recovery across all the department's services.
- Virtualization makes it not only practical but essential to create a fully redundant server and storage infrastructure.
- Storage Virtualization software makes implementing redundant SAN storage an affordable reality. When combined with
server redundancy, your IT services can withstand the otherwise catastrophic loss of half of your server and storage infrastructure.
- Thin Provisioning means the reality of VM server sprawl won't cause your storage capacity requirements to run rampant.
- Storage Virtualization software makes implementing a flexible DR solution affordable. The virtualization software can
implement the replication of your servers and data to a remote site, ready to turn on in case of site-wide disaster.
- The Storage Virtualization software that implements your SAN can run on the same type of servers you are using for your Server Virtualization.
If you are an HP shop, pick your favorite DL- series box for the Storage Server and add in an MSA-60 or two for the drives.
If you prefer Dell, pick your favorite PowerEdge and add in the MD-1000 shelves for the drives. IBM shops can pick their
favorite System X and add an EXP-3000 or equivalent for the drives. One hardware vendor, one warranty.
If you are serious about your virtualization project, don't underplay the virtualization of the storage. Putting off
the storage virtualization into a "Phase II" project is a formula for migration headaches and will almost inevitably
involve downtime of the VMs as you attempt to migrate them to the virtual storage.
It will also be a waste of money. If you decide to split your project into phases, implementing the SAN with some
EqualLogic or Pillar type storage, and with the intention of implementing Storage Virtualization in the future
(for cost-effective replication, Thin Provisioning, etc.), you will probably end up paying for "features" in the SAN
that the Storage Virtualization software would have provided. And ultimately, those "appliance" SAN storage devices
won't provide you with the homogenous "single hardware vendor" environment and will end up being more costly than if
you had just bought a standard server with adequate direct-attached storage and deployed the DataCore solution from the start.
"I'm Ready To Get Started. How Do I Buy SANmelody™?"
Las Solanas Consulting is not a DataCore or Dell reseller, and DataCore does not publish their prices on the
web. Please contact DataCore™ or a
for pricing information.
If you want to take a test drive of the SANmelody software, you can download a
30-day evaluation. The evaluation software includes iSCSI and FC support, as well as support for their
unique Thin Provisioning feature however, it does not have support for the Synchronous Mirroring feature.
Nonetheless, you'll see for yourself how SANmelody out-performs the traditional storage vendor's SANs or Storage Arrays.