Dumb and Dumber Switches? Page 2 - EnterpriseStorageForum.com

Dumb and Dumber Switches? Page 2

Continued from Page 1

Why Such Complexity?

This complexity, though, is not the result of simple sloth on the part of vendors. Even the notorious fabric interoperability issues of the past were not entirely due to underhanded competitive maneuverings (although a few switch vendors crafted subversion of interoperability into something of an art form).

Despite Jacob’s longing for simpler times, the painful fact is that fabric switches are necessarily powers of ten more complex than their LAN cousins. By the nature of the devices it connects, storage networking demands more intelligence in the SAN.

In a LAN environment, intelligence resides in the end systems or hosts, which are typically computer platforms such as servers or workstations. Through end-to-end protocols such as TCP, the hosts are responsible for establishing and maintaining sessions with their peers on the far side of the network. The network itself, composed of Ethernet switches, IP routers, or switched optical infrastructure, is primarily responsible for expeditiously moving data from source to destination. A workstation, for example, is not required to log on to an Ethernet switch to register its presence.

In a SAN environment, by contrast, an end device such as a JBOD may be relatively dumb. Storage targets in general are passive participants in the SAN, waiting for active intervention by an initiator (server) to establish communications across the SAN. Fabric switches must accommodate the disparity of intelligence on the end systems by providing logon services, simple name server (SNS) registration, and state change notification (RSCN) broadcasts to signal changes in the SAN. In the early days of Fibre Channel fabrics, these basic intelligence services were the focus of interoperability testing and debugging just to ensure that the attached servers and disk assets obeyed common standards of behavior in order to properly communicate with the fabric.

Even in a single-vendor, single-switch environment, fabric switches therefore require more sophisticated logic than LAN switches. Additional layers of complexity appear when fabric switches are connected to build multi-switch SANs.

The original architects of Fibre Channel decided that fabrics should be self-configuring. Consequently, in addition to fabric-based intelligence in the form of logon services, SNS registration, and RSCNs, fabric switches require intelligence to perform fabric building, exchange of SNS data, zoning information, and routing tables.

Fabric building, for example, involves an intensive exchange between multiple switches to determine which will be the principal switch responsible for allocating unique 64K address blocks to the other switches. If the principal switch leaves the fabric, or if an operational switch is inadvertently inserted into an established fabric, switch-to-switch protocols trigger a fabric reconfiguration process.

This may require the suspension of ongoing storage transactions, logging off servers and arrays, and/or reallocating addresses to the end devices. Successfully monitoring this procedure is no trivial task, especially when tens of switches are involved. Likewise, melding zoning information and SNS entries between multiple switches requires processing overhead to ensure that the proper devices are mapped across inter-switch links.

Page 3: Simplicity and Complexity Coexisting in Harmony?


Page 2 of 3

Previous Page
1 2 3
Next Page

Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 

Storage Daily
Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date