Section 10.4. Post-Windows Server 2003

   

---

10.4 Post-Windows Server 2003

Not content to rest on its laurels in terms of storage features added to the Windows NT platform in Windows 2000 and Windows Server 2003, Microsoft continues to build on the momentum with a host of storage features planned for the post-Windows Server 2003 release. These include support for iSCSI and further improvements in storage management infrastructure.

10.4.1 Fabric Virtualization Service

The fabric virtualization service was disclosed briefly at a recent trade show and appears to be an attempt to provide a single interface to manage fabric switches, no matter who the switch vendor is or what the particular model or features of the switch are.

Consider what a storage administrator typically does to accomplish a routine task such as a backup:

1. Create a volume that will serve as a repository for the snapshot.

2. Rezone switches to make this volume visible to the server that is hosting the source volume from which a snapshot is to be created. Some port manipulation may also have to be done, as well as LUN management at the source server.

3. Create the snapshot.

4. Move the snapshot (e.g., rezoning, LUN reconfiguration) to make it visible to the backup server.

5. Accomplish the backup.

6. Return the snapshot to the storage pool, which involves yet some more switch and LUN configuration.

Typically, the process goes like this: The storage administrator does some manual work, starts some software, does some more manual work, starts some different software, and so on.

The fabric virtualization service, when used in conjunction with the virtual disk service (described in Section 10.3.3) will facilitate full automation of such tasks . The fabric virtualization service has no known time frame for a release, and there is no firm commitment that Microsoft will have such software.

10.4.2 LUN Management

Windows NT is overly aggressive when it comes to handling storage; its philosophy is "see disk, claim disk." Windows spins up every disk it sees to read the partition table and then attempts to mount each file system that it sees. Needless to say, the potential for data corruption is fairly high.

At the time of this writing, LUN masking is available as a feature from third parties (IHVs and ISVs), but not as a built-in feature of Windows itself. One of the problems with these third-party solutions is that there is a chance for the third-party driver or utility software not to be loadedfor example, when a server boots into safe mode. Thus the chances of data corruption still exist. LUN masking is also available as a feature of hardwarefor example, RAID boxes or Fibre Channel switchesbut the problem with that solution is that the hardware cannot be controlled programmatically. Typically the hardware comes with a graphical configuration utility that can be run remotely.

A future version of Windows NT server is expected to ship with LUN masking implemented in the native driver stack that Microsoft itself ships, and in particular, in the Storport driver at the very minimum.

As per the trial balloons floated at past trade shows (WinHEC), the Microsoft implementation can be expected to have the following features:

• IOCTLs to allow a management application to accomplish and control the LUN masking.

• An inclusion list that can be configured via the IOCTL just mentioned. An inclusion list contains a list of devices that the driver should expose to applications.

• The ability to bypass the LUN masking. ^[2]

  ^[2] Without details of the implementation being available, it is difficult to say for certain, but one can expect that a determined kernel mode piece of software may be able to do this. This is not a security risk, because the Windows philosophy is to trust kernel mode software and restrict the ability of people to install kernel mode software, thus allowing a system administrator to install and run only kernel mode software that has been thoroughly tested and can be trusted.

As this book goes to press, Microsoft is believed to be working on implementing LUN-masking capability in the port driver. The advantage of having such functionality in the port driver is that the port driver is always loaded and hence the window of opportunity for nonparticipation in the LUN masking is considerably reduced. The chances of having the wrong port driver loaded are considerably smaller compared to the chances of having the wrong miniport driver loaded as well.

One should not assume that all device vendors are equal in their capability to dynamically configure any port as any kind of port. Some devices have this capability built in and can reconfigure a port on the fly without a reboot or power cycle, but some devices need firmware upgrades or swapping of option cards for the particular port that may require a power cycle.

There is no known time frame or firm commitment for any such software to be released by Microsoft.

10.4.3 iSCSI Support

iSCSI is an industrywide effort to implement block storage over existing network-centric infrastructure. Though iSCSI is not expected to perform on as high a level as other existing storage interconnects, such as Fibre Channel, the focus is on solutions that do not require high performance and can leverage existing network infrastructure. The expected arrival of hardware accelerators for TCP/IP, where some protocol processing overhead is expected to be moved from the server CPU to dedicated network card hardware, should only help advance the case for iSCSI.

Microsoft has indicated that it is actively implementing iSCSI support in Windows NT. There is no exact release time frame, though the expectation is that Microsoft might release such software after Windows Server 2003, but before the next major release cycle of the Windows operating system.

Figure 10.10 shows the architecture for the Windows NT iSCSI implementation. The iSCSI initiator is implemented as a miniport driver that can work with both SCSIPort and the new Storport port driver.

Figure 10.10. Windows NT iSCSI Architecture

The discovery DLL tracks all changes dynamically and acts as a single repository for all LUNs discovered through any mechanism, including iSNS (Internet Storage Name Service) client or port notification. The discovery DLL provides an API for management applications to discover new LUNs and, if appropriate, a means for the management application to direct the discovery DLL to perform a login to the new LUN.

Highlights of Microsoft's iSCSI plans include the following:

• To focus on implementing iSCSI on the Windows Server 2003 platform. However, Microsoft will also provide iSCSI code for the Windows 2000 and Windows XP platforms. This code is expected to be available within months of the Windows Server 2003 release.

• To provide code for iSNS server and client.

• To emphasize the use of IPsec as a data protection and security mechanism.

• To focus on iSCSI initiator implementation. There are no current plans to implement iSCSI target on the Windows NT platform.

• To transmit all communication between discovery DLL and iSCSI initiator through WMI.

The port driver also provides a communication path to the HCA miniport, as well as the InfiniBand managers such as the subnet and connection managers. The subnet manager is responsible for managing fabric topology by programming switches and setting host channel adapter (HCA) attributes. The subnet manager also provides a point of confluence for management policies pertaining to access control, performance, and fault tolerance (multipath). The connection manager implements InfiniBand connection-oriented features, as well as policy-based features for failover.

10.4.4 Multipath I/O

Multipath I/O is available for Windows 2000 and Windows Server 2003. Microsoft provides a development kit to vendors, and users can get the complete solution only from vendors. Microsoft is expected to extend the multipath solution to cover removable media (the existing solution works only for fixed hard disks). This explains the shaded portion of the multipath area in Figure 10.5.

---

Top