Section 7.4. Microsoft Storage Virtualization Vision

   

---

7.4 Microsoft Storage Virtualization Vision

With Windows Server 2003 and the storage-related features that will ship beyond Windows Server 2003, Microsoft is clearly working diligently toward a vision of steadily enhancing the Windows NT platform with more storage- related features. Virtualization at the volume level (FtDisk and Logical Disk Manager) and file system level (Hierarchical Storage Management and distributed file system) has been available on the Windows NT platform for quite some time now. Microsoft is working toward building better infrastructure into the Windows NT platform for storage management. Among other things, this infrastructure will allow an administrator to easily accomplish routine tasks in a highly automated manner.

As an example, consider an administrator that wants to do a backup. This administrator does the following:

1. Sets up a volume (some disk or RAID management may be required)

2. Ensures that the volume is visible to a snapshot engine (rezoning may be needed)

3. Performs a snapshot

4. Moves the snapshot volume to be visible to a backup server

5. Performs the backup

6. Frees the volume and moves it back into the free storage pool

The goal is to allow administrators effective control of each of the steps above, either programmatically, via a command-line interface, or via a management GUI application. At each step, the desired functionality is specified in a functional manner rather than a physical manner. For example, the volume allocation step should be stated like this: "create a volume, make it 50GB, RAID 5, and so on"and not like this: "make E: 50GB." To achieve this vision, Microsoft is shipping the disk virtualization service with Windows Server 2003 and the fabric virtualization service at a later date.

7.4.1 Disk Virtualization Service

The disk virtualization service provides functionality to manage block storage that is itself virtualized. The disk virtualization service can provide this functionality irrespective of where the virtualization occurs (e.g., host, RAID hardware). In particular, the disk virtualization service provides functionalities such as these:

• Creation of LUNs by characteristics

• Creation of file systems

• Management of paths

As shown in Figure 7.2, the virtual disk service has a three-tiered model, consisting of applications, the disk virtualization service, and several providers, some developed by Microsoft and some developed by third parties.

Figure 7.2. Virtual Disk Service

Software providers are responsible for managing volumes ; providers are implemented as COM servers. Software providers implement functionality as specified in the virtual disk service SDK, which is available from Microsoft on an NDA ( nondisclosure agreement) basis. The functionality includes creating COM objects that represent the volume, disk, and provider itself, as well as other objects. A software provider also exports status and health information about the objects it manages , and it sends out notifications. The virtual disk service receives all notifications; it then filters the notifications and sends them on to applications that have registered for the appropriate alerts. The virtual disk service co-ordinates with file systems as neededfor example, while extending or shrinking a volume.

Hardware providers are responsible for managing LUNs. Just like software providers, hardware providers are implemented as COM servers and implement functionality as specified in the virtual disk service SDK available under NDA. Hardware providers implement functionality related to LUNs, drives , LUN masking, and so on and send notification events.

Microsoft will ship three providers, and RAID hardware vendors are expected to write hardware providers for their particular offerings. The three providers that Microsoft will ship are

1. A Storport provider that caters to host-based RAID hardware (this is local direct-attached hardware and not SAN hardware)

2. A provider that manages basic disks (which are described in Chapter 6)

3. A provider that manages dynamic disks (also described in Chapter 6)

It appears that the virtual disk service will be extremely useful to a slew of storage management applications, including utilities for managing disks, backup, mirroring, and snapshot applications. It also remains to be seen how Microsoft itself builds management applications and utilities using the virtual disk service. Note that historically, Microsoft has put some useful tools or utilities in the resource kit rather than the operating system offering itself. An excellent example is the linkd.exe utility for creating links. Thus the reader should also check out the Windows Server 2003 Resource Kit to see if it has any storage management tools.

The virtual disk service is expected to run on multiple Windows NT servers. The software providers will run only on servers where the appropriate volumes are mounted. A management application that uses the virtual disk service can run remotely or on the same machine. The virtual disk service will run in OEM installation environments (called WinPE or Windows NT Lite). In WinPE, a machine boots with a minimal Windows NT configuration and installs Windows NT in a custom configuration on that machine or runs some tests. In such situations, a minimal configuration might be the virtual disk service and the basic disk provider.

7.4.2 Fabric Virtualization Service

The fabric virtualization service plays a key role in offering a capability to automate storage management. In particular, the fabric virtualization service provides programmatic and management applet (GUI or command line) access for managing storage interconnects.

Note that the fabric virtualization service is not part of Windows Server 2003. In reality, it may or may not ship at all. Few details beyond this presentation have been available on a nonconfidential basis. It is also interesting to note that many industry vendors, including at least one prominent switch vendor, have declared their intent to adopt the DMTF or SNIA Common Information Model. Taken to its logical conclusion, this would mean that the vendor APIs for switch management would have secondary importance to the methods and objects exposed via the Common Information Model. How this evolves and how the fabric virtualization service architecture fits into this evolution is something only time (and perhaps a later edition of this book) will tell.

Figure 7.3 is a highly speculative attempt to define the fabric virtualization service architecture. The fabric virtualization service will present an API for the benefit of management applications and get information about the fabric from a WMI provider.

Figure 7.3. Fabric Virtualization Service

---

Top