Directors take on more tasks

When to move to a director
IT organizations currently using a core-to-edge architecture often ask when they should consider a director-class product. There are four key scenarios that would likely trigger such a decision.
1. If 25% or more of the ports in the fabric are dedicated to inter-switch links (ISLs), then a director would probably make more sense. This decision is driven by practical financial realities: Director-class ports cost

Requires Free Membership to View

25% to 50% more than standard Fibre Channel switch ports, but the total price of this scenario will be in the same ballpark because you won't need to burn as many ISL ports with a director, and the director will deliver greater resilience and better total throughput.
2. If the core-to-edge architecture is oversubscribed for bandwidth needed by the applications, the non-blocking nature of directors will improve performance.
3. If the number of cascades (commonly referred to as "hops") between core and edge switches exceeds three, then a director should be considered. Each hop introduces latency into the data path, and sensitive database applications will begin to be affected after three hops.
4. If the service-level requirement demands 99.999% uptime, meeting such a requirement isn't really feasible in a core-to-edge environment. Planned maintenance alone will cause an SLA violation.
Of course, directors and core/edge switches are not mutually exclusive. Fabric management tools operate identically for both devices. In a hybrid architecture, the director serves as the backbone, usually in the data center, with core/edge devices elsewhere. Outside the data center, core/edge devices will take care of remote operations quite satisfactorily. A hybrid architecture can serve as either a transitional step toward consolidation or a permanent solution to support a geographically dispersed organization.

Managing large SANs
SANs with more than 1,000 devices are certainly not commonplace, but they aren't unheard of. SANs with hundreds of devices are becoming common, and these large configurations introduce a variety of problems. The "any-to-any" nature of SAN architectures poses a threat to information security and increases management complexity. Of these, security is perhaps the most significant.

Most security threats in a SAN environment come from within the organization. IT groups shouldn't fall prey to a false sense of security just because storage is behind the firewall. Ports can be intentionally or inadvertently exposed to the outside, and unscrupulous admins can look for unencrypted passwords. Thus, issues such as password encryption, authentication and proper "hard" and "soft" zoning must be addressed. Each director vendor has well-developed security within its own fabrics. Brocade offers Secure Fabric OS, Cisco has the Intelligent SAN Security Suite and McData offers SANtegrity Security Suite. However, each solution is proprietary and won't interoperate with the others. The ANSI T11.3 security standard will eventually solve this problem, but it's not widely adopted; mixing different vendors' switches in the same fabric is often not advisable.

Connecting SAN islands improves management and availability (see When to move to a director, this page). While SAN islands were once the norm, most companies have consolidated, or are planning to consolidate, their SANs. This capability is enabled by functionality referred to as "Layer 3" switching. In the IP world, Layer 3 provides inter-LAN routing. Similarly, Layer 3 SAN switches facilitate routing between SANs. Obviously, security is a key component. Brocade's SilkWorm Router Module is a separate device on the fabric, as is McData's Director Service Module. Cisco's Multiprotocol Services Module plugs into the 9509 chassis, thereby reducing the number of devices in the fabric.

The flip side of linking SAN islands is dividing large SANs into logical entities that are more manageable and secure. Each vendor has its own architecture to do this: Brocade has the Logical Storage Area Network (LSAN), Cisco has Virtual SAN (VSAN) and McData has Director Flexible Partition (DPAR) (see Director differences).

Brocade LSAN. The LSAN can be thought of as a "many-to-one" approach that combines SANs using the Router Module. Thus, the SAN can be managed as one large entity or multiple smaller entities. The Router Module acts like a firewall and prevents faults from propagating between SANs.

Cisco VSAN. The VSAN can be thought of as "one to many." Specifically, one large SAN can be broken into multiples by partitioning directors, switches or fabrics. Resources can be shared across VSANs (called Inter-VSAN routing), and faults can be isolated to VSANs. VSAN technology has been adopted by ANSI as the T11.3 standard, but Cisco is the only company that supports it. VSANs can encapsulate non-Cisco products, but basically treat them as dumb devices.

McData DPAR. With DPARs, a fabric can be divided into SAN units that can be isolated from one another. McData also prescribes a process where DPARs can be used to transition from SAN islands to a unified fabric.

Virtualization and other buzzwords
For this article, virtualization is defined as "abstracting the storage infrastructure from the app so that storage becomes a 'service' to the app." As such, virtualized storage must have the intelligence to manage the location, data protection, replication and service-level delivery. As more intelligence resides in the fabric, key apps will include heterogeneous data replication, backup and recovery, storage management and data encryption. Fabric vendors don't provide these storage apps, but rather the hardware platforms they run on. Virtualization is also available from other third-party devices, usually on Microsoft Windows- or Linux-based appliances. Data encryption is also available, again using separate appliances. But the additional appliances complicate SAN deployment, use expensive ports, create additional points of failure and introduce more management software. Through the end of this decade these apps will reside on intelligent director-class switches.

An example of an application moving to the fabric is Cisco's recent announcement of its Network-Accelerated Serverless Backup (NASB), based on the Xcopy standard. With NASB, the backup data stream moves directly from disk to MDS 9XXX to tape without passing through the backup/media server. As a result, processing overhead is greatly reduced and backup speeds are increased. Only the meta data is passed to the media server for cataloging. Although NASB improves backups, it doesn't always improve restore operations. The restore data path still requires the backup/media server in most cases. The exception is volume restores using either CommVault Systems Inc.'s Galaxy or Computer Associates International Inc.'s BrightStor ARCserve. In all other cases, the restore process will see no resource reduction or speed improvement.

Falling prices
Competition for directors and fabric switches is driving per-port prices down at a rate of 40% to 50% annually. The market for intelligent devices is really a two-horse race: Brocade's SilkWorm Fabric Application Platform (AP) and Cisco's MDS 9000. Although McData has made some strategic acquisitions and partnerships, it doesn't currently sell an intelligent fabric device of its own. Presently, the list price for intelligent ports is around $4,000 per port, while the list price for conventional products is approximately $1,500 per port.

Cisco's intelligent switch architecture, called Network-Hosted Storage Applications, is based on a Storage Services Module that resides in the MDS 9509 frame. This module can have as many as 32 ports. The Brocade SilkWorm Fabric AP is also a blade, with up to 16 ports that reside in the 24000 director. The race is on for each vendor to attract as many OEM partners as possible. OEM qualification is a significant task and successful completion offers a substantial time-to-market advantage for the director vendor. Cisco has been qualified by IBM Corp. for its SAN Volume Controller, by Veritas Software Corp. for Storage Foundation for Networks and by EMC Corp. for Storage Router virtualization software. Brocade has also landed EMC, as well as Hewlett-Packard's VersaStor product. Eventually, both platforms will be supported by all OEM vendors.

This was first published in June 2005

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: