In today's san (storage area network) environment, Fibre Channel (FC) switch architectures have pro-gressed beyond the either/or choices of yesterday. It used to be either you needed a high-availability FC switch chassis architecture or you didn't-and then chose accordingly. For many organizations, that time has passed.
Server, switch and storage consolidations, higher uptime requirements and cost-cutting efforts across the enterprise now require an integration of high availability and scalability from all FC switch architectures, regardless of which vendor provides the solution. With these increased requirements, the need to choose and build the right FC switch architecture for your organization has never been greater.
|Sampling of switch players|
So what criteria needs to be considered in this choice of switch architectures? Common ones continue to be affordability, availability, compatibility, interoperability, manageability, scalability and the ability to be upgraded. But factors weighing more heavily on decision makers today include security and simplicity of management, as well as the ability to use your existing investments in your SAN infrastructure.
Telecom and ESCON switch infrastructures
While there are a number of documented switch infrastructure models, two models preeminently exist in most large organizations. Which one that's being used depends heavily upon the requirements of the organization.
If your organization has a SAN in a rapidly growing or more cost-conscious FC environment, the network or telecom model will most likely exist within your infrastructure. If that's the case, Brocade is likely the vendor of your switch, as they provide the majority of the port count in this segment of the market.
On the other hand, if your SAN exists in a data center or some other high-availability environment, the black box or ESCON model predominates. Here you'll likely find directors from vendors such as McData or Inrange providing the connectivity on the SAN as these two combined control a large segment of the port count in these environments.
Why is there such dominance by two totally different architectures and a handful of vendors within those respective architectures? To understand the telecom and ESCON models and why they have prevailed in their respective environments, some definitions and an understanding of their environments are required.
The telecom model in FC switches closely parallels the intelligent switching architectures used in the telecom and networking worlds today. These switches have an intelligent and programmable OS, provide greater security functionality and can handle more complex routing operations. Due to this, they scale more easily and are more adaptable to a rapidly growing environment.
However, complexity exists within the telecom solution. It requires more up-front design work, more management after deployment and a better understanding of the data traffic patterns of the SAN infrastructure into which they are being deployed. This is an important item of note. A telecom solution deployed or utilized in a poorly understood or poorly documented environment could cause unpredictable results.
The ESCON model differs in that it has its roots in the ESCON directors of the mainframe world. In the mainframe world, ESCON directors are essentially black boxes used to connect mainframes to external storage arrays. The desirability of this model comes from the ability to provide a highly available solution that is simpler to understand, deploy, manage and maintain. It also generally provides a higher port count than switches on the telecom side.
While it generally comes with a higher port count, upgrading and scaling this solution should these ports fill up becomes a logistical problem. This issue has its roots in its underlying microcode that is less geared to handle trunking between switches than its telecom counterpart. Also, the security features in this solution appear to presume a physically secure environment, an assumption that can't necessarily be made in most open systems environments.
Convergence of these models
To meet the emerging business requirements of high availability, security and scalability, these existing models appear poised to converge to a more robust model that will connect the core and edge switches in the enterprise. Based upon what has been occurring internally at San Jose, CA-based Brocade and McData, Broomfield, CO, it appears they understand this convergence is coming and the limitations of their current designs. To address these design limitations, both are taking steps to meet these emerging business requirements.
McData announced in mid-October its Sphereon 4500, a 24-port SAN switch. Aimed at the midrange market it allows users to upgrade the switch in 8-port increments through McData's FlexPort technology. The 4500 ships with all 24 ports physically present, and customers have the option of whether to enable 8, 16, or all 24 of them and pay only for the ports they use. The Sphereon "offers buy what you need-flexibility," says Steve Duplessie, analyst for the Enterprise Storage Group.
McData has also recently addressed its deficiencies in its security and scalability capabilities. Its October 2002 microcode release, 5.0, took major steps in both of these areas. They will soon release a 4.0 code update prior to a more comprehensive 5.0 release, which is scheduled for early 2003. For the first time, the option now exists for servers to log on to the SAN that would require a user name and password prior to joining the fabric. This helps to prevent unauthorized or hostile servers from joining the SAN environment and accessing other servers' data. McData also chose this release to introduce more robust trunking functions into the software of its microcode. Up to this point, when connecting between McData directors, ISLs (Inter-Switch Links) were required using a round robin methodology to send data down the different paths, but they were not treated as one logical path. With their new microcode, these ISL links are now treated as one logical path between the directors permitting more sophisticated load balancing across these paths.
In the meantime, Brocade has responded by releasing its Silkworm 12000 switch into the director marketplace. Until the 12000's release, Brocade has lacked a true single chassis high availability solution. In its current and first release, the 12000 meets most of the requirements of a high-availability solution such as redundant and hot swappable power supplies, fans and port blades. While its Fabric OS still lacks the hot code load functionality normally associated with a core director, the time required to load its existing Fabric OS takes twenty five seconds. Brocade forecasts that its next code upgrade to its Fabric OS, 4.1, will offer this functionality.
The other major player currently in this space, Inrange, Lumbertown, NJ, still appears to be following the path of larger monolithic directors with limited ability to connect the edges of the enterprise. And smaller switch vendors such as Bothell, WA-based Vixel and QLogic, located in Aliso Viejo, CA, are either content to stay in the market niche they own or have found ways to capture new markets.
QLogic has diversified their product offerings beyond strictly being a FC switch vendor, aggressively expanding into markets such as the Host Bus Adapter (HBA) FC market. Vixel, meanwhile, has continued to capitalize on their core competency of being a high performance switch vendor. According to Claude Lorenson, Vixel's director of product management and marketing, Vixel continues to generate the majority of its revenue from the traditional hub and fabric switch business where it currently dominates the video/media streaming markets due to their switch's high performance capabilities.
In any case, this coming convergence would clearly seem to favor Brocade's telecom model. They dominate the switch end of the market, and their underlying operating system, Fabric OS, was designed with this coming convergence in mind. In addition, their Silkworm 12000 has been released to pull this model together.
Does Brocade win all the chips?
All of the SAN switch vendors, including Brocade, have yet to deliver and show this solution can work seamlessly for years on end. Additionally, not every organization necessarily needs or desires the telecom model for every application. And Brocade will face more competition in this space as time progresses from the telecom gorilla, Cisco, who in August 2002 announced their first model, the MDS 9000 series, and from McData, who intends to come on strong in this market with its latest code release.
With Cisco's formal entry into this space as well as more startups and the need for continuing better backup performance times on the SAN, the FC architecture seems primed for change. So from this, one can expect to see both an emergence of new architectures and a divergence of existing architectures to meet new requirements.
Future switch architectures
The entry of Cisco into this segment of the market presents some interesting scenarios for decision makers. Cisco pervades the telecom space. Almost every organization of almost any size has some Cisco equipment installed somewhere and engineers or administrators to support it. In fact, one would think to introduce FC switching into an existing Cisco environment would be as easy as plug-and-play. Simply plug a new blade into one of Cisco's core switches, upgrade the existing Cisco IOS and presto-a new SAN infrastructure magically appears.
But there is no smoke and mirrors in the SAN space. Unfortunately for Cisco, vendors such as Brocade and McData-long-time players in the SAN space-appear to have a decided advantage in that they understand the unique challenges presented by a SAN.
Jay Kidd, Brocade's vice president of product development, concurs. He points out that FC, unlike TCP/IP, doesn't understand the concept of either dropped packets or rearranging packets if they arrive in the wrong order. In a FC environment, data packets must be delivered and arrive in the same order they were sent or else data corruption or loss may occur.
That might help to explain Cisco's recent acquisition of Andiamo Systems, a company they have privately funded for a few years. This acquisition may indicate that Cisco, rather than using their existing product lines, will need to complement them with Andiamo's product line. The fact that this product line contains switches ranging from 8 ports to 256 ports that closely mirrors Brocade's and McData's line of offerings seems to confirm these assumptions.
So while a SAN may be taking on the features of today's telecom networks, it still will have and require a certain ESCON mentality at its core, specifically the simplicity and manageability aspects of it. The SAN also carries with it data integrity and availability questions as well as performance monitoring issues at every point within its infrastructure that the SAN telecom model may or may not be ready to address.
New players entering the SAN market also may alter how SAN architectures develop going forward. Three new vendors coming to market with products in this space include Milpitas, CA-based LightSand Communications, Nishan System, San Jose, CA, and Pirus Networks, Acton, MA, which was recently purchased by Sun Microsystems.
LightSand Communications has recently emerged after two and a half years in development with FC over SONET gateway. Their first two products, the S-600 and S-2500, are scheduled to ship in late Q3 of 2002. These products allow connectivity of FC SANs over wide-area SONET networks, in essence giving SANs acting in the same fabric the ability to extend over large geographic areas (up to 8000K) with real time synchronous connectivity.
Assuming statistics bear out and the telecom providers install this switch, the technology can expand the capability of synchronous SANs beyond the current 100 km limit. While this technology is obviously still in its infancy, LightSand's chairman is Kumar Mallavali, one of Brocade's original founders. So it's not a reach to conclude that the combination of his contacts and this technology could open doors for this company to succeed.
Another vendor looking to extend the SAN space is Nishan Systems. Nishan takes a slightly different angle than LightSand in extending the SAN. John Conlin, a regional manager with Nishan Systems, described their solution this way. "One of the strengths of Nishan Systems is that it allows you to connect any number of disparate SANs together, regardless of who the switch vendor is on each SAN, while maintaining the autonomy of each fabric. This helps to avoid SAN switch vendor lock-in or the complexity of meshing fabrics together when two different SAN fabrics are joined together."
Their IPS 4000 Series IP Storage switches support iSCSI, iFCP, and E_Port for trunking to both IP backbones and legacy Fibre Channel (FC) fabrics. This differs from LightSand's approach to essentially trunk remote SAN fabrics together, something organizations may or may not want to do.
Nishan's most recent and notable success is with the Carlson Companies based in Minneapolis. Carlson partly chose Nishan from this very reason, the ability to connect SANs and still maintain separate fabrics. This allows data to be passed between different regional SANs without introducing the complexity of a meshing these separate SAN fabrics or architectures into one.
Pirus Networks brings to Sun its SAN routing switch, the PSX-1000. It consists of a networking component, a system component and a storage component layer. The networking component provides connectivity to IP-based LANs or SANs. The system component provides the multiprotocol capability of the PSX-1000. Finally, the storage component contains FC ports that grant access to the FC-SAN.
Virtualization in the switch
The answer from vendors such as Pirus Networks would appear to be more. And based upon recent announcements from Brocade, they would concur that the switch should contain storage management and virtualization capabilities among others. However, since this functionality appears on the road map for inclusion into the core of the SAN switch, the definition of what comprises a switch architecture must also expand to include the providers of in-band storage virtualization solutions.
Storage virtualization itself is a very complex subject. And while one can not definitively say at what level storage virtualization should exist in the SAN in every environment, one has to note that vendors like Fujitsu Softek, Hitachi, and IBM have already announced their plans to put storage virtualization on a device on the SAN between the servers and the storage. So while storage virtualization may exist on either the server or the storage array, the storage virtualization solution that exists in the SAN, or the in-band solution, seems to be gaining momentum.
In-band storage virtualization is a technology by which storage arrays are seen by and controlled by a device between the servers and the storage array. The $64,000 question is whether this device should be the switch itself or yet another device in the SAN where this device sits in the data path between the servers and the storage. For most of the larger current providers of this technology, Fujitsu Softek, Hitachi Data Systems, Hewlett Packard, and the smaller ones such as DataCore and FalconStor, the answer is another device on the SAN. For vendors like Brocade and Pirus Networks, they would likely answer the switch itself.
Regardless of which approach is adopted, each of the solutions from these in-band virtualization vendors use different techniques to attempt to accomplish the same objective: manage and provide storage irrespective of operating systems or storage vendor. While this technology may seem farfetched to some, this one may hold the most potential for the growth and acceptance of SANs for two reasons.
First, it simplifies the zoning and configuration of the SAN. It provides a central point to which all servers come to for storage. This simplifies the provisioning of storage. Second, once all storage can be managed and controlled through a central management interface, it opens up new possibilities for data management and replication regardless of storage vendor or operating system. Of all the emerging technologies with the switch architecture, this one would appear to hold the most promise and seems to be gaining increased acceptance.
SAN security and backup
Another feature more companies are asking for is security. While many of today's SANs exist in physically secure environments, the inclusion of SAN islands throughout the enterprise in could compromise this security. Hence the increased interest for switch vendors to provide secure logins, authenticated logins and requirements to encrypt data between the server and the storage.
Another technology worth watching is the inclusion of backup agents and management code by vendors such as Veritas into the FC switches. But with all of these emerging technologies, some divergences are occurring as well. One interesting divergence is the re-emergence of what SANs were originally designed for, SANs designed exclusively for backups. In most SAN environments, two paths to the storage exist so that if one path fails, the other can maintain the connectivity to the disk. However, when backups occur in the SAN environment, contention may also arise on these data paths when the backups run. This contention inhibits the free flow of data and creates performance issues for the application if it is needed at the same time the backup is running.
By creating a tertiary SAN with existing technology, it's possible to eliminate or minimize the contention issues that arise between the backups and the primary paths to direct access storage device (DASD). While creating this tertiary SAN would require additional FC connections for all of the servers using it and at least one more SAN switch in the infrastructure, it could help to resolve the performance problems experienced in many SAN environments today during peak backup periods.
Switch within the storage array
The other interesting divergence going largely unnoticed but that may also have an impact to the bottom line of businesses is that of the creation of the back end switch within the storage array. Vixel has taken its patented rights to the arbitrated loop switch, put it on a chip, and has started marketing a back end for SANs within the storage array between the storage controller and the disk drives. Vixel then uses its documented switch performance advantage to speed up disk performance, increase the ability of a RAID controller to manage 3X to 4X as many back-end disks-up to 120 disks as opposed to only 30 to 45 now-and lowers the cost per megabyte to the end user by 15% to 20%. Their competition in their space is essentially nil and they report an increased amount of interest in this architectural design, especially since Hewlett-Packard came to market with a storage array using this architecture in July 2002.
With the emergence and divergence of these new and existing technologies within the SAN architecture, the bar for data delivery and availability on SANs will be raised even further. While the evidence points to a convergence of existing SAN architectures for many environments, it also points to a new level of expectations and base line for functionality performance in the SAN switch infrastructure and even the storage arrays themselves. This new infrastructure will create a new SAN infrastructure, one that is simpler to manage, better performing, easier to scale and more reliable than ever before.