As data centers increase server density, server deployment and management continues to be a resource intensive task. A server administrator typically must log on to each server and individually configure each server for communicating on the network. The configuration of the servers and attached network devices (switches, bridges, and routers) must be carefully coordinated to ensure reliable and secure operation. This configuration is manually performed by a server administrator. Accordingly, administrating servers and network devices, in data centers can be inefficient, time-consuming, costly, and potentially error prone.
Network server management may be automated through the use of a hidden network which exists between a collection of end nodes and a collection of external networks. To the external networks, the hidden network emulates a collection of network ports on the end nodes, and to the end nodes it provides a corresponding set of network connections. The hidden network maintains the connections between end nodes and external networks and transparently adapts as configurations and topologies change. By discovering the identities and monitoring the attached network equipment, the hidden network adapts to changes in cabling topology or network configuration without requiring changes to end node configuration. The hidden network adapts automatically to changes in the configuration and topology of its own elements (switches, bridges, links, etc.) without administrative action by a user.
There is difficulty in automatically managing a collection of servers and network devices from a variety of vendors through standard management protocols such as Simple Network Management Protocol (SNMP). Hidden network can utilize topology management protocols, such as rapid spanning tree protocol (RSTP), to prevent loops in the external network, as discussed previously. In systems which use RSTP to prevent loops some of the uplinks to the data center network are placed in a stand-by state and placed in a blocking mode. While only a single uplink to the data center network is placed in an active state. Those uplinks which are in a standby state are wasted bandwidth. They are there for redundancy, but do not operate as a data path due to their stand-by state.
Embodiments are directed to apparatus, and methods for full utilization of network uplinks in virtual connection environments. The embodiments provide an alternative method to the Virtual Connect (VC) loop prevention logic that maintains the same benefits and simplicity of previous VC solutions, yet allows all uplinks to be actively forwarding traffic at the same time. This can lead to significant improvements by allowing redundancy of connections without the previous wasted bandwidth in networking equipment of previous solutions.
Current Virtual Connect Ethernet network (VC Enet) restrict the number of network uplinks actively forwarding traffic to one individual port or Link. Aggregation Group (LAG) in order to achieve a loop-free operation while appearing as a pass-through module to the data center networks by not participating in the data center Ethernet networks' Spanning Tree Protocol (STP) topology calculation. This restriction leads to idle resources when fault-tolerant networks are desired by configuring redundant uplinks to the data center switches.
One possible solution to the wasted bandwidth is to create a plurality VC networks with a single uplink assigned to each network. This allows all uplinks to be active, and passing traffic at the same time, however there is no network redundancy built into this configuration. To maintain some redundancy in the configuration, server side redundancy, such as network interface card teaming can be configured. This solution is less than desirable because of the extra time necessary to configure and maintain multiple networks instead of a single network for the Virtual Connect environment.
To eliminate the wasted bandwidth in a VC environment, one embodiment would place an external layer 2 switch at the boundary of the Virtual Connect Domain. To prevent the need for management of the external layer 2 switch, it must operated from a data center network view as edge modules where Ethernet data loops are not possible else it will simply be another switch in the data center which must be managed. From the Virtual Connect Domain view, it must operate as a simple pass through to the Data Center network. To accomplish this, an external layer 2 switch must participate in the spanning tree protocol of the Virtual Connect Domain. By the external switch participating in the spanning tree protocol in the Virtual. Connect Domain, the uplinks will participate in the VC's spanning tree protocol the same as the stacking links.
In another embodiment, a Root Bridge is virtualized and instantiated in each system of the VC Domain. Each virtual instance of this state machine is configured to behave exactly the same in each VC system, creating the illusion of a real external Root Bridge to the VC systems.
The flow diagrams in accordance with exemplary embodiments of the present invention are provided as examples and should not be construed to limit other embodiments within the scope of the invention. For instance, the blocks should not be construed as steps that must proceed in a particular order. Additional blocks/steps may be added, some blocks/steps removed, or the order of the blocks/steps altered and still be within the scope of the invention. Further, blocks within different figures can be added to or exchanged with other blocks in other figures. Further yet, specific numerical data values (such as specific quantities, numbers, categories, etc.) or other specific information should be interpreted as illustrative for discussing exemplary embodiments. Such specific information is not provided to limit the invention.
In the various embodiments in accordance with the present invention, embodiments are implemented as a method, system, and/or apparatus. As one example, exemplary embodiments are implemented as one or more computer software programs to implement the methods described herein. The software is implemented as one or more modules (also referred to as code subroutines, or “objects” in object-oriented programming). The location of the software will differ for the various alternative embodiments. The software programming code, for example, is accessed by a processor or processors of the computer or server from long-term storage media of some type, such as a CD-ROM drive or hard drive. The software programming code is embodied or stored on any of a variety of known media for use with a data processing system or in any memory device such as semiconductor, magnetic and optical devices, including a disk, hard drive, CD-ROM, ROM, etc. The code is distributed on such media, or is distributed to users from the memory or storage of one computer system over a network of some type to other computer systems for use by users of such other systems. Alternatively, the programming code is embodied in the memory (such as memory of the handheld portable electronic device) and accessed by the processor using the bus. The techniques and methods for embodying software programming code in memory, on physical media, and/or distributing software code via networks are well known and will not be further discussed herein.
The above, discussion is meant to be illustrative of the principles and various embodiments of the present invention. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.
Filing Document | Filing Date | Country | Kind | 371c Date |
---|---|---|---|---|
PCT/US2010/022613 | 1/29/2010 | WO | 00 | 1/17/2012 |