What is the difference between SAN routing, channel extension and virtualization? |
 |
| 09 Jan 2007 | Greg Schulz |
|
|
Some folks see storage area network (SAN) routing as just segmentation; some see it as protocol conversion; some see it as distance enablement. SAN routing really embraces all those -- and even more functionality.
On closer inspection, SAN segmentation is about logically separating different fabrics. That is, you can connect multiple Fibre Channel (FC) fabrics together, yet have them logically isolated to maintain their own autonomy and namespaces, and not have to worry about management traffic crossing the different fabrics. This is very similar to the way you would segment a LAN. Another form of routing deals with distance, which has traditionally been known as "channel extension" in the mainframe world. For example, you see storage over IP, FCIP or other technologies that enable storage to be moved over long distances for remote tasks like mirroring, replication, copy, backup and so on. Yet another form of routing is protocol conversion, such as FC to iSCSI or iSCSI to FC -- mapping a protocol across different interfaces allowing traffic to be bridged or routed across different networks. Consequently, you'll hear terms like router, gateway, bridge, etc. but they are all routing traffic between network segments, routing protocols across different interfaces or routing data over long distances across the same (or different) networks.
Virtualization is a bit more nebulous. It can mean volume management, LUN pooling, LUN management, mirroring, replication, snapshots/point-in-time copies, transparent data migration and other functions that would normally be handled through a volume manager or within a storage system or storage array itself. A point of confusion about virtualization is that different vendors' products can often do different things. For example, the Brocade Communications Sytems Inc. Multiprotocol Router AP7420 (MPR can convert protocols (e.g., iSCSI to FC) and can also host storage virtualization applications, such as EMC Corp. Invista and Fujitsu virtualization platform. Another popular device is the Cisco Systems Inc. Storage Services Module (SSM) blade. The software that you run on it will define the device's suite of capabilities. When a vendor first introduces a blade or other module, it's important to determine the software that will run on it.
Some solutions specialize. For example, QLogic Corp., Sanrad Inc. and others make purpose-built appliances that only do protocol conversion or SAN extension -- often with some level of volume management. Those are particularly attractive when keeping acquisition and deployment costs down while tackling specific tasks. Then, you have the multiprotocol or multifunction type devices like the Cisco and Brocade modules that can do a variety of things depending on the software you choose to deploy on them. Today, vendors frequently offer tiers of functionality to meet each organization's needs. That's great because now you can match the notion of tiered storage with tiered connectivity -- applying the right technology to the task at hand without wasting money or functionality.
Listen to the SAN FAQ audiocast here.
Go back to the beginning of the Storage Area Network FAQ Guide.
|
|
|
|
