For DCs, Simple Storage Is Better Storage
Using a SAN for VMs is a flexible option, but might not be the best choice for domain controllers when you're virtualizing Active Directory.
July 23, 2010
Virtualization frees systems from residing on a single piece of hardware, giving virtualized systems a flexibility of location that's restricted mainly by where the virtual machine's (VM's) disk files can be accessed from. In a simple network, if you want to use a virtual disk on another host, you must copy that multigigabyte file over your network, which takes time and can be a complicated sequence of exporting, copying, and importing files.
A SAN can simplify this process because the disk files don't necessarily move—the machines that access them are what changes. Depending on how it's configured, in a centralized SAN an available VM disk file can run in a data center in California, then quickly be changed so a server in New York is using it. When the SAN is configured for shared storage, you can put multiple VMs into a virtualization failover cluster.
But should you place your domain controllers (DCs) on a SAN? Active Directory (AD) is a distributed system. Its fault tolerance stems from the fact that its components—for example, its disks—are scattered throughout the enterprise. As you begin to consolidate its pieces, it begins to lose its fault tolerance. A DC's disk needs are modest. It must support an indexed, sequential database file that's read from more frequently than it's written to, and is usually less than 10GB in size. But the availability of every AD domain is absolutely essential.
If your data center rules are that every VM's disk must be on the SAN, and you lose the SAN, you've lost your domain or even your forest until the SAN is back up. You can argue that SANs don’t often fail, but when you're working with such a basic level of your company's IT infrastructure as AD, systems should depend on each other as little as possible. You expect a SAN failure to prevent multiple application servers from functioning, but a completely redundant SAN can be extremely expensive and cost-prohibitive. But do you want to lose the ability to log on to the network also?
With a distributed, straightforward database application such as AD, SAN storage is not only unnecessary, but it also increases the risk of a single point of failure. Using local disks, a single DC might fail due to disk failure, but the outage will be isolated to the DC. Locating your DC’s AD databases on a SAN makes your forest dependent on the SAN. The recommendation: Keep it simple. Keep it local.
Sean writes about cloud identity, Microsoft hybrid identity, and whatever else he finds interesting at his blog on Enterprise Identity and on Twitter at @shorinsean.
About the Author
You May Also Like