Increased fabric scalability by designating router groups

Is in a Fibre Channel storage area network (SAN) and its included routers, the routers are placed in groups or pods. Each router only contains router port and fabric access data for routers in the same group or pod. In this manner the size of the relevant tables are reduced, which allows for greater expansion of the SAN as a whole. Each router may be programmed by an administrator with a pod value, indicating the pod containing the router. This value may be provided to the Name Server during router registration and may be requested from the Name Server when developing the router's inter-fabric router (IFR) topology or the pod value can be exchanged in the IF_ILS_HLO messages. Router port database information is only stored from routers in the same pod or provided to routers in the same pod, thus reducing the entries in the router port database.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to storage area networks.

2. Description of the Related Art

Storage area networks (SANs) are becoming extremely large. Some of the drivers behind this increase in size include server virtualization and mobility. With the advent of virtualized machines (VMs), the number of connected virtual host devices has increased dramatically, to the point of reaching scaling limits of the SAN. Classically Fibre Channel fabrics are limited in the number of domains, usually synonymous with switches, that can exist in the fabric, due to both addressing issues and stability issues. Fibre Channel routers were developed as a way to allow the overall SAN to grow larger without having to reach scale limits of any individual fabric.

The operation of the Fiber Channel routers is generally defined in various Fibre Channel specifications, such as FC-IFR, Rev. 1.06, dated May 12, 2010; FC-FS-3, Rev. 1.11, dated Oct. 22, 2010; FC-SW-5, Rev. 8.0, dated Nov. 22, 2006 and FC-LS-2, Rev. 2.00, dated Jun. 26, 2008, all from T11 and all incorporated herein by reference. A portion of the operations includes developing a table to identify which router port can access which fabric. Conventionally this table is a global table and contains information on all of the routers in the fabric. With the continuing growth of SANs, this table can become extremely large and thus a scaling concern itself. Certain efforts have been made to address the problem for particular SAN topologies, such as the use of LSAN zone binding by Brocade Communications, Systems, Inc., but other SAN topologies have not been addressed. Therefore there is a need to address router scaling issues in these other topologies.

SUMMARY OF THE INVENTION

In a Fibre Channel SAN and its included routers according to the present invention, the routers are placed in groups or pods. Each router only contains router port and fabric access data for routers in the same group or pod. In this manner the size of the relevant tables are reduced, which allows for greater expansion of the SAN as a whole.

Each router may be programmed by an administrator with a pod value, indicating the pod containing the router. This value may be provided to the Name Server during router registration and may be requested from the Name Server when developing the router's inter-fabric router (IFR) topology. Alternatively, the pod value can be exchanged in the IF_ILS_HLO messages exchanged between the routers.

As only routers in the same pod have entries placed into the router IFR or port database, the number of entries in the table is greatly reduced from the prior situation where entries from all routers in the SAN were included. This reduced number of entries allows larger SANs to be developed.

DETAILED DESCRIPTION

Referring now toFIG. 1, an exemplary network100is illustrated. This network100is used to illustrate both the prior art and an embodiment according to the present invention. Three Fibre Channel routers (FCRs)102,104,106are illustrated as being in a backbone fabric108. FCR1102is connected to FCR2104and an edge fabric100110. FCR2104is connected to an edge fabric3112and FCR3106. FCR3106is connected to an edge fabric4114and to edge fabric100110. Two hosts116and118are connected to edge fabric100110. A storage device120is connected to edge fabric3112and a storage device122is connected to edge fabric4114. Host118and storage device122are in LSAN1124, while host116and storage device120are in LSAN2126.

Shown below each FCR is its respective router port database. As can be seen, each router port database contains the entries of all router ports connecting to edge fabrics. While this simple example shows a few router port entries, it is remembered that this is a very simple SAN provided for explanatory purposes and a normal SAN where the router port database space is limiting the size of the SAN there are thousands of such entries.

FIG. 2is a flowchart of the development of the router port database. In step200a router determines if an edge fabric has been connected locally so that a local router port is developed. If so, in step202the port is added to the local portion of the router port database. In the preferred embodiment the router port database has local and remote portions for ease of handling. In step204it is determined if any FCRs are coupled to the instant FCR performing the operations. For example, if FCR1102is performing the operation, then the other routers are all coupled FCRs. If there are any coupled FCRs, the router port information is provided to the other routers. Operation returns to step200.

If a local port is not connected, in step208it is determined if a remote port has been connected. This can be done when two FCRs are coupled, such as by exchanging IFR topology and router port databases, or when a port is connected for an individual remote FCR. If so, then in step210the router port or ports are added to the remote portion of the router port database.

If there has not been a remote port connection in step208, there are no FCRs in step204or after step210, operation returns to step200.

It is understood that the actual software may be configured differently from the flowchart ofFIG. 2, asFIG. 2is provided for explanatory purposes. For example, routines or daemons could be executed upon the connection of a port, one for local ports and one for remote ports. As another example, the indicated logic could be a small part of much larger software modules.

FIG. 3illustrates the network100ofFIG. 1modified according to the present invention. FCR1102and FCR2104are placed in pod1300, while FCR3106is placed in pod2302. Router port database entries are only developed for routers in the same pod, not all routers in the network as done in the prior art. This results in the databases shown inFIG. 3. FCR1102and FCR2104only have two ports in their databases, the ports connecting to fabric3112and fabric100110. FCR3106has only its own ports in the router port database as there are no other routers in pod2302.

As can be seen, this reduces the size of the router port database in the present examples by half. In the illustration each host116,118can still access each storage unit120,122, assuming proper zoning, but in more complicated environments, which would be the norm in cases where the router port database size is limiting network size, a given host may not be able to access a given storage unit as necessary routers may not be in the same pod. In practice this is generally not a limitation as in most cases careful pod planning can resolve this situation, though in some cases it may be necessary to move hosts or storage units to different edge fabrics. The tradeoff is considered acceptable to address the growth limit issue.

FIG. 4Ais a first flowchart of router operation according to the present invention. In general operation is the same as illustrated inFIG. 2except that step208is modified to form step208′. In step208′ it is determined if there is a remote port connection from a router in the same pod, not just any router as done in step208. Each router is preferably programmed by an administrator with a pod value, indicating the pod containing the router. This value may be provided to the Name Server during router registration and may be requested from the Name Server when developing the router's inter-fabric router (IFR) topology. Alternatively, the pod value can be exchanged in the IF_ILS_HLO messages exchanged between the routers. Thus step208′ limits the inclusion of router ports into the router port database by filtering for matching pod values.

FIG. 4Bis a second flowchart of router operation according to the present invention. In general operation is the same as illustrated inFIG. 2except that steps204and206are modified to form steps204′ and206′. In step204′ the determination is whether there are any FCRs in the same pod. If so, then in step206′ only those routers receive the indication of the new port local to the router. Therefore a given router will only receive router port values from other routers in the same pod, thus also limiting the size of the router port database.

In an alternate embodiment steps204′,206′ and208′ can all be present, replacing steps204,206and208. While either steps204′ and206′ or step208′ should limit the entries in the router port database to those of the same pod, performing both alternatives in one flowchart provides further guarantees.

FIG. 5is a block diagram of an exemplary router598. A control processor590is connected to a router ASIC595. The router ASIC595is connected to media interfaces580which are connected to ports582. Generally the control processor590configures the router ASIC595and handles higher level operations, such as the name server, routing table setup, routing port database setup and the like. The router ASIC595handles general high speed inline or in-band operations, such as switching, routing and frame translation. The control processor590is connected to flash memory565or the like to hold the software and programs for the higher level router operations and the router port database operations ofFIGS. 4A and 4B; to random access memory (RAM)570for working memory, such as the name server and route tables; and to an Ethernet PHY585and serial interface575for out-of-band management.

The router ASIC595has four basic modules, port groups535, a frame data storage system530, a control subsystem525and a system interface540. The port groups535perform the lowest level of packet transmission and reception. Generally, frames are received from a media interface580and provided to the frame data storage system530. Further, frames are received from the frame data storage system530and provided to the media interface580for transmission out of port582. The frame data storage system530includes a set of transmit/receive FIFOs532, which interface with the port groups535, and a frame memory534, which stores the received frames and frames to be transmitted. The frame data storage system530provides initial portions of each frame, typically the frame header and a payload header for FCP frames, to the control subsystem525. The control subsystem525has the translate526, router527, filter528and queuing529blocks. The translate block526examines the frame header and performs any necessary address translations, such as those that happen when a frame is redirected as described herein. There can be various embodiments of the translation block526, with examples of translation operation provided in U.S. Pat. Nos. 7,752,361 and 7,120,728, both of which are incorporated herein by reference in their entirety. Those examples also provide examples of the control/data path splitting of operations. The router block527examines the frame header and selects the desired output port for the frame. The filter block528examines the frame header, and the payload header in some cases, to determine if the frame should be transmitted. In the preferred embodiment of the present invention, hard zoning is accomplished using the filter block528. The queuing block529schedules the frames for transmission based on various factors including quality of service, priority and the like.

Therefore by placing the routers in pods, the size of the router table database is reduced, allowing further expansion of the network.

The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of this disclosure. The scope of the invention should therefore be determined not with reference to the above description, but instead with reference to the appended claims along with their full scope of equivalents.