The difference between storage success and failure is simply a little tweak to the hard drive configuration of virtual servers and some well-orchestrated maintenance.
Virtualized data centers often rely on storage area networks (SANs) to centralize storage, streamline storage provisioning and management, and take advantage of the SAN's native data protection features like remote replication. But some organizations prefer to distribute virtual machine (VM) and data storage across individual servers. This can mitigate storage traffic on the local area network or eliminate complexity and cost in a SAN, but data center administrators must wrestle with storage provisioning and performance on a server-by-server basis. Let's consider some issues involved in storage configuration for virtual servers.
Hard drive speeds and RAID configuration
IT administrators recognize three essential characteristics about disk storage: rotational speed, local interface, and the tradeoffs of performance and protection. When specifying storage for a server, it's important to understand the anticipated workload demands and select disk characteristics that will best meet those demands.
Rotational speed is measured in rotations per minute (RPM), and faster disks offer lower latency because the disk can rotate to desired sectors faster. Enterprise applications benefit from 15,000 rpm disks, though disk capacity at 15,000 rpm is usually limited. Somewhat slower 10,000 rpm disks may provide adequate latency for less critical applications and offer larger storage capacities.
The interface passes data from the disk's cache to the server. Serial-Attached SCSI (SAS) is the most popular serial interface for high-performance local storage and can achieve transfer speeds to 6 gigabits per second (Gbps).
Serial ATA (SATA) interfaces are slower with transfer speeds to 3 Gbps, though the architecture and command set usually conspire to reduce performance even further. In many cases, SAS disks offer lower storage capacities than SATA disks, so SAS disks are usually employed for top performance production workloads, and SATA disks are used for less critical workloads, near-line storage or archival data. SATA disks can be attached to SAS interfaces, so it is possible to deploy SAS and SATA disks on the same SAS-based server motherboard. However, it is important to review the server's documentation to verify disk compatibility and performance limitations beforehand.
Most SAN storage uses RAID groups that boost performance by engaging multiple disks simultaneously where data is distributed across several disks in the RAID configuration. With more spindles, each disk can access its piece of the file at the same time and performance can be enhanced. This is not so easy with server-based storage because servers rarely support more than a few disks. For example, a 1U rack server may only offer space for two or four disks, while a 2U server may support four to eight disks. Larger rack servers can accommodate more physical disks (and larger power supplies to drive them), but this can limit the size of RAID groups and the provisioning options available.
In addition, the choice of RAID level may have an adverse effect on hypervisor performance. For example, RAID 5 may impose an unacceptable write penalty on a production VM. Instead, it might be better to run an operating system and hypervisor on a pair of 146 GB 15,000 rpm SAS disks protected with RAID 1, and then fill the remainder of the server with 10,000 rpm SAS or SATA disks protected with RAID 0+1 to combine the performance improvement of striping with the protection of mirroring.
Administrators can choose from myriad different disk sizes and protection options, so it is worth testing server performance in a lab setting to find the best configuration for your specific workloads.