|
iSCSI iSCSI is an abbreviation of Internet Small Computer System Interface, an IP-based storage networking standard for linking data storage facilities. Advances in Network Interface Cards (NICs) to support 1 and 10 Gbit Ethernet has made it feasible to construct computer systems with no 'local' storage. This has particular advantages in server installations, allowing construction of multiply-redundant systems without single point of failure in the underlying storage system. Windows and iSCSI For Windows server systems, there are two aspects of iSCSI-only systems that present particular problems. Firstly, early during bootstrap it is necessary to have READ access to the boot media before Windows has fully initialisied. Most NICs feature firmware that can offer this service but for those that do not, the files loaded by the BIOS must be able to access the boot source via the IP network. The second problem requirment is the need to have WRITE access in order to crate a crashdump file onto the boot medium after a Windows (or component) failure that has brought down the system. |
The problem The two problem areas are characterised by the absence of a full operating system to support execution, at boot time because it hasn't been loaded yet, and at crashdump time because it is broken. So the driver must be able to operate with almost no support - interrupts, threads and synchronisation primitives can only be used under strict conditions, monitored by a boot/dump-aware Windows driver library.. A further complication is that the driver is not a simple one - it must provide both iSCSI protocol support and a full TCPIP capability. Neither of these are trivial components. The solution Prior to SystemSoft's involvement, our customer had sketched out the architecture to be used - they had some iSCSI code from a now-retired Windows project and had identified a portable TCPIP implementation called LWIP. These components, together with stripped-down versions of the customers NDIS NIC drivers were to be used to create a 3-layer driver that could be used a boot and dump time by both Windows Server 2003 and Server 2008. SystemSoft's Role SystemSoft were pleased to agree with the proposed architecture. We'd previously used UIP (a close relation of LWIP) and were comfortable with the non-multithreading aspects of those implementations. |
Working from the bottom of the driver stack upwards, we progressively implemented Ethernet Frame transmission/reception, TCPIP and Finally iSCSI. A desire to keep as much code common with other developments for the same NIC family as well as preserving the functionality of the old iSCSI capability imposed particular constraints, mainly because of the need to operated in a single execution thread, which made the iSCSI and TCPIP event/state handlers somewhat convoluted. Debugging with Windbg was problematical - boot time debugging is difficult because the Windows environment isn't fully set up, and crashdump debugging, while possible, is restricted to single-shot breakpointing because once a breakpoint is hit during crashdump processing, the debug infrastructure cannot access the Windows data structures (for example, Paging is not possible) and execution rarely resumed in a satisfactory manner. A final complication was the need to integrate with the iSCSI-boot variant of the NIC firmware which was being developed in Russia against very tight timescales. Our driver relied on the firmware for TCPIP & ISCSI configuration data. In complex configurations any errors in the data structures would produce strange results, often a long time after the incorrect item was processed. Since Development Although clearly functional when SystemSoft involvement concluded, the availability of firmware and multiple configurations against which to integrate meant that some additional work was need before it could be used as a component of the NIC manufacturers submission for consideration for inclusion as the LAN-on-Motherboard (LOM) in server manufacturers (e.g. Dell, HP) systems |
Go back to the home page