Download the authoritative guide: Enterprise Data Storage 2018: Optimizing Your Storage Infrastructure
In a recent trade press article, Jacob Farmer of Cambridge Computer Systems defiantly declared his opposition to the industry trend towards intelligence in fabric switches. In taking this contrarian position, Jacob has braced himself against a backlash of opposing views, but so far there has been little public response by switch vendors or customers to his valid points.
Jacob’s essential argument is that fabric switches should simply switch, efficiently moving data from A to B, without the encumbrances of additional storage processing. Like LAN and WAN switching technology, the role of fabric switches in his view is to provide high performance, low latency transport. Adding storage management or virtualization functionality to fabric switches increases both the complexity and cost of products that, according to Jacob, should be as simple to manage and support as possible.
The desire for simple, efficient, and interoperable SAN switches is understandable. Ethernet switches, for example, may offer basic quality of service (QoS), VLAN, or flow control options to optimize data transport, but are generally transparent to the end devices they serve. By contrast, much of the complexity attributed to SANs stems from switch-related issues, both from interoperability issues with HBAs and disk arrays as well as from a legacy of interoperability issues between different vendor’s switch products.
As Jacob rightly states, transparency, simplicity, and interoperability are assumed in the LAN world. No one expects a horde of field service engineers to descend if a customer plugs a Foundry Big Iron into a Cisco Catalyst. Customers do, however, have to exercise caution when connecting fabric switches together, even if the switches are from the same vendor. Microcode levels must be compatible, interoperability modes must be set, and enhanced features sacrificed when crossing vendor lines.