How to understand the importance of SAN routing protocol development

Many people may not know much about the SAN routing protocol, so I have studied the significance of the development of the SAN routing protocol. I would like to share with you here and hope it will be useful to you. In 1988, Indian Canadian Kumar Malavalli began his six-year-long creation of the Fiber Channel standard. With the unremitting efforts of him and other Engineers interested in this process, fiber channel was finally approved by the US National standardization administration as a national standard in 1994.

This great career of Kumar Malavalli originated from his comparison and Investigation of the world's popular network technologies represented by Ethernet and the channel technologies represented by SCSI. The basic starting point for the creation of the Optical Fiber Channel SAN routing protocol is to create an advanced network architecture that combines the advantages of the network technology and the advantages of the channel technology. Because Fiber Channel learned the network technology at that time, the advantages of the channel technology were eliminated, and engineers with various network technology backgrounds were competing to take the network they knew, the channel SAN routing protocol is rewritten to the layer-4 (FC-4) of the fiber channel. At that time, SAN routing protocols that were standardized to FC-4 were SCSI, IP, ATM, FICON (ESCON's fiber channel version) and so on. Over the past 10 years, SCSI has evolved into a storage lan san routing protocol. FICON has also become the mainstream of the Mainframe (Mainframe) storage protocol. The IP Technology Based on Fiber Channel is applied to the management of fiber channel switches.

Storage Area Network, a Storage Domain Network Based on Fiber Channel, can transmit data at a high speed of 200 MB/sec. An important difference between fiber channel and other network SAN routing protocols is that its data transmission bandwidth utilization can easily reach more than 99% in the Fiber Channel architecture. This is incomparable to other Network SAN routing protocols. Fiber Channel can extend the SAN connection distance to over 100 kilometers.

If the technology is supplemented by SAN routing protocol conversion (for example, from fiber channel to SONET and from fiber channel to IP address conversion), the SAN connection distance can reach the global scale. A Fabric consisting of fiber channel switches connected to each other can connect 239 fiber channel switches with up to 24-bit device address space. Compared with Ethernet, fiber channel data transmission in the same Fabric is device-to-device, while data transmission in the same Ethernet Subnet is broadcast. This is the main reason why fiber channel bandwidth usage is several times higher than that of Ethernet. It is precisely because the data transmission device of the Optical Fiber Channel in the same Fabric is opposite to the device, and the optical fiber channel stipulates a strict system to constitute a management system. In the management system of this system, the access and removal of devices, including fiber channel switches, are broadcast to devices that communicate with the access and removal devices in the form of broadcast.

The more fiber channel switches in a Fabric, the larger the SAN routing protocol network. There are more opportunities for Device Access and migration. As a result, more information is sent to the outbound broadcast. Although such broadcast information is insignificant compared with the data broadcast storm in Ethernet, it cannot be ignored for the high availability level and network management required by the storage network.

In various disaster recovery systems, once the local and remote SAN routing protocols are connected, a large Fabric is formed. However, the long-distance bare fiber or IP connection that connects local and remote SAN routing protocols is often the weakest link in this Fabric. On the premise that the local and remote SAN belong to the same Fabric, if the connection between them is unstable, Fabric reconfiguration that affects the whole SAN will occur ). This is an important cause of unstable disaster recovery systems.

The Disaster Tolerance System is at a historical development stage from traditional disaster tolerance between two points to mutual disaster tolerance between multiple data centers and the provision of disaster tolerance as a service to multiple customers. The traditional isolated Fabric Structure of fiber channel can no longer meet the requirements of Multi-Point Disaster Tolerance and make disaster tolerance a service. Today, there are already hundreds of thousands of SAN islands in the world. Users often need to integrate these SAN islands. If this integration is integrated into a Fabric, the customer will face complicated operations such as adjusting the Fiber Channel switch parameters and rewriting the system composition files on some servers. In many cases, the customer cannot even arrange enough scheduled downtime to complete such system integration.

Different functional departments in the company objectively need to have the storage network development space and freedom of their own departments. The storage network of other departments should not be affected by the expansion of a department's SAN. However, it is difficult to achieve this when all the company's server memory is in the same Fabric.