Storage Management Strategies for the CIO
This article can also be found in the Premium Editorial Download "Storage magazine: Optimizing your enterprise database storage."
Download it now to read this article plus other related content.
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.
 |
|
|
|
|||
| ||||||
Requires Free Membership to View
|
|
|
||||||||||||||||||||
|
|
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.
This was first published in November 2002
Join the conversationComment
Share
Comments
Results
Contribute to the conversation