The Switchs Operating System

If a Storage Area Networks heart is the switch, continuously pumping data between the storage and the servers, then the networks brain is the switchs operating system. Switch operating systems are similarly configured to the microkernel RTOS used in NAS solutions. In fact, the operating systems, in many cases, are a derivative of the same technology used by certain NAS vendors . Switch operating systems, regardless of implementation, operate with the same core -level operating systems that support other embedded options.

Figure 15-1 illustrates the basic components of a typical switch operating system, the foundation of which is the core-level, or kernel-level system calls that provide basic system-level functions, such as interrupt processing, memory management, and task prioritization. The ability to execute Fibre Channel commands through low-level system calls to the FC chip-set is the specialization encapsulated in the switch, given that microkernel performance of the switchs operating system is paramount to the successful operation and effective utilization of switch hardware.

Figure 15-1: The basic components of the switchs operating system

There are two major issues that impact the operation and performance of the switchs OS. The first is the extensibility of the systems functions to successfully execute existing functionality while being able to encompass new levels of applications which have become increasingly important to the operation of the SAN as a whole. Surrounding this level of compatibility and scalability is the microkernels capability to coexist alongside a commodity-level chip and Fibre Channel microprocessor. Consideration must be given to the addressability of the operating environment and its ability to multiprocess and multitask the network linking functions of the switch. The second issue is the operating systems capability to provide reliable yet efficient Name Service functions for intraswitch operations and interswitch communications. The inherent danger in mixing and matching different vendors switch components should be duly noted, and strongly heeded.

Figure 15-2 illustrates the importance of add-on applications that must also utilize the operating systems resourcesfor example, recovery services, management services, external API, and communication components.

Figure 15-2: SAN applications running within the switchs OS

The following list discusses the additional components that process under the control of the fabric operating system. The specific processes will be implemented differently depending on the vendor selection of FC switch products; however, the common functions as explained here should be included to achieve a complete operational SAN fabric.

• Recovery   Core-level services that provide specific class processing within the switch, including link recovery, sequence retransmission, and frame recovery of, specifically , class 2 processing. This also includes class 3 and 4, not to mention the added value functions related to Fibre Channel that enable disk-to-disk communications. These leverage node functions from layer 3, 4, and upwards, along with the extended copy command that allows devices to communicate without a third-party supervisor. As you might have guessed, recovery functionality is essential. For additional information, see Chapters 21 and 22.

• Management   Not an easy one. The big difficulty with any embedded system is its inability to be seen within the environment it operates. SAN configurations are just about the least visible to existing server-level applications, so it falls to the switchs operating system to provide some level of visibility. This is accomplished through the use of a Management Information Base (MIB). Given its network-centricity, MIBs, and its subsequent access method of Simple Network Management Protocol (SNMP), are the foundation components monitoring the SAN. These unwieldy components are difficult enough within a network environment, and have proved to be just as obtuse in storage network environments. As hard as they are, though, MIBs have provided management vendors and those users intrepid enough to brave the waking nightmare that is SNMP an opportunity to gather information about the operation of the switch. So, choose the fabric component, but please make sure the operating system is compatible with third-party management tools. Please

• External Application Programming Interface (API)   Most switch operating system implementations will make some accommodation for an API to facilitate third-party programs that enhance the operation of the SAN. APIs include data sharing software, management software, and communications software.

• Communication components   A way to get from the switch to the outside world. This is yet another important duty of the switchs operating system, given that port communications are encapsulated within core-level functions, outside communication to IP networks, serial communication to console functions, and the leveraging of E_Port switch-to-switch communication. The switchs capability to direct these functions is dependent on size and scalability. IP overhead communication through a G_Port provides sufficient latency to affect the performance of the switch. E_Port interswitch communication stacks additional processing cycles that subtract from the core functionality of the switch itself. As a result, console configurations through a serial port should have sufficient low-level prioritization to interrupt kernel functions in order to reconfigure or solve a problem.

Taking all of this into consideration, it becomes plain that the concurrency of port-to-port communication, outside communications, switch-to-switch communications, and the latency factors for the microkernel can, and will, quickly become overwhelming.

At the end of the day, the microkernel operating system is not likely to handle a lot of other work on top of what its core-level job is, which is the linking of ports. Low-end, generic switches of 8 to 32 ports arent likely to support additional data sharing, management, or switch-to-switch latencies without taking away from core-level functionality. These switches are designed to provide a switch fabric set of operations for hooking switches to storage, and thats it. Microkernel operating systems just werent designed to be general operating systems. So why are we asking them to be general operating systems?