Disk Volumes for Resource Pools

Whenever you talk file sharing, you need to talk about disk structures. And, with the coming of Hyper-V and the associated division of IT infrastructures into resource pools and virtual service offerings, the disk structure you build becomes more and more important. Resource pools will deal with physical disks since they act at the hardware level. But virtual service offerings will deal with virtual disk drives, which are files that reside on the physical disks used by the resource pool. This means that you need to begin by building and creating your resource pool of physical disks and then, once those are ready, you can build the virtual file servers they will host.

You've already begun this process, but a more in-depth discussion is necessary, one that will focus on the use of shared storage for the host servers. Shared storage is essential for resource pools if you want to build business continuity and high availability into your IT infrastructure. When host servers share disk resources, you can move workloads from one host to another, because both have access to the disk resource where the virtual disk drives making up the virtual machine reside. Of course, you also need to include the failover clustering feature to your host servers.

Shared storage means using either network attached storage (NAS) or storage area networks (SAN). Windows Server 2008 can connect to shared storage through SCSI, fiber channel, or Internet Small Computer Systems Interface (iSCSI) interfaces. Each requires its own hardware component to work. But once the shared storage is linked to the server, you begin to work with the disk units created and structured within your shared storage environment. These units will be able to take advantage of the redundancy features available in your shared storage infrastructure. Begin by preparing these structures, then move on to Windows to work with its disk management interfaces.

Since host servers run the Server Core implementation of WS08, you do not have access to the graphical interface enhancements WS08's full installation offers for shared storage management. Instead, you need to rely on command-line tools. One such tool is the DISKPART.EXE command. This command lets you control both direct-attached and shared storage. It lets you create initial disk configurations as well as expand disk volumes once they are created. It can either be used interactively, through its own command environment, or it can be scripted by first listing commands in a text file and then calling the text file when you run the command.

You should create a standard disk structure for all physical servers in the resource pool. This structure should include the following:

• C: Drive: This is the system disk.
• D: Drive: The shared data storage disk. This disk will host all of the virtual hard drives that make up the virtual service offerings.
• E: Drive: A secondary shared disk that is used to provide backup services for the contents of the data drive.
• Y: Drive: The DVD/CDRW server drive.

All of your host servers should use this disk structure. Since all disk volumes can be extended, no other drive letters should be required.

When working with the DISKPART command, you'll need to first select the disk, volume, or partition you want to work with, then apply the commands to the selected object. Since it is an execution environment, the best way to obtain help from this command is to first type DISKPART at the command prompt; then, once the execution environment is open, type HELP. Type EXIT to close the DISKPART execution environment and return to the command prompt. Work with your storage manufacturer to determine how you should configure your storage and connect it to your Server Core installations.

NOTE: You should also store the C: drive in your shared disk infrastructure; this way, your blade servers can consist of nothing more than random access memory (RAM), processors, and network interfaces. Using shared-disk infrastructures to store boot drives makes it really easy to provision servers, since you can capture an installation, copy it through the shared disk infrastructure tools, run SYSPREP on it, and then use it to seed other installations, just like you would with a virtual hard disk drive. The major difference here is that you work with a storage partition inside your shared disk infrastructure, but you get all of the advantages disk abstraction provides when provisioning servers.