Ask the Expert

Storage-area network (SAN) fabrics: Mesh versus core-edge topology

What are the pros and cons of mesh and core-edge topologies when designing a storage-area network (SAN) fabric?

    Requires Free Membership to View

When redundancy is required for a storage-area network (SAN) topology, a best practice is to implement two identical SAN fabrics and have devices connect to each one. This ensures that if a host is connected to both fabrics it will still be able to operate if there is a failure with the host bus adapter (HBA) or switch, or even an entire fabric failure. There are two types of SAN topologies: mesh and core-edge.

Mesh SAN: In a mesh SAN, every switch in the fabric is connected to every other switch by way of an inter-switch link (ISL). In such a configuration a host will traverse a maximum of one ISL to access its storage. When configuring a mesh SAN it is favourable to group hosts and their storage on the same switch to cut down the amount of traffic on the ISLs. As a mesh grows, the number of ISLs on a single switch grows at the rate of one for every additional switch. After a certain point there is minimal benefit gained by adding extra switches as many of the additional ports will be required for ISLs.

Core-edge SAN: This SAN configuration utilises a large switch at the core of the fabric to which storage arrays are connected. Hosts are attached to smaller port count 'edge' switches, which are attached to the core switch via ISLs. This topology can grow to hundreds of ports while ensuring that hosts only have to traverse two switches to access their storage. Hosts that require lower latency or higher throughput can be connected directly to the core switch.

The mesh topology is an excellent choice for small- and medium-sized businesses (SMBs) because a core-edge topology would leave many empty ports in the core switch. The core-edge topology is best suited to large fabrics because it minimises the number of wasted ISL ports as a fabric grows.

This was first published in January 2010

 

COMMENTS powered by Disqus  //  Commenting policy