Abstract:
A system and method for sharing network resources; the system comprising at least one network switch, at least one computing device comprising at least one network connection and at least one storage device containing software capable of initializing and maintaining: (i) a management local area network (MLAN) comprising a virtual or physical firewall; and (ii) a plurality of client virtual local area networks (VLANs), wherein each client VLAN comprises a virtual firewall and a plurality of network resources.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a divisional of, and claims priority to, U.S. patent application Ser. No. 13/113,919 filed on May 23, 2011, now U.S. Pat. No. 8,549,607, which is a divisional of U.S. patent application Ser. No. 11/977,143 filed on Oct. 23, 2007, now U.S. Pat. No. 7,975,033. Both applications are incorporated by reference herein. 
    
    
     BACKGROUND OF THE INVENTION 
     Traditionally, clients of a data center are required to buy or rent physical servers, switches, and storage arrays to put into data centers to house items such as web applications, databases, voip servers, data servers, etc. This can be extremely costly for small businesses which may only need to run a small web application such as a storefront or a payroll application. 
     Alternatively, the same client can rent web space on a database and web server, but is often limited to what can be done with it, number of users or databases that can be contained within, or how much traffic it can receive. 
     What is needed is a system where a client may purchase CPU cycles, storage, and network resources “a la carte,” being able to obtain only what is required by their business, no more, no less. It would be beneficial to the client to be able to purchase these resources on the fly, as needed, without having to leave the comfort of the office and having them work automatically. There would be nothing to hookup, nor anything to configure so that hardware works with one another. In addition to fully-functional servers, clients may lease shared resources and have them integrate with existing infrastructures seamlessly. 
     In the field metropolitan area networks (MANs), a system is used to isolate users into virtual local area networks, or VLANs. Recently, the idea of encapsulating a VLAN inside another VLAN has been introduced simply to be able to house more users. While before network engineers were limited to 256 VLANs on most equipment, they may now be able to use 256×256 separate VLANs. 
     What is described herein is using the concepts of VLANs and virtualization on a large pooled system to be able to dynamically allocate network resources to users, as well as bridge and share network resources. 
     Herein, the term “computing device” refers to any electronic device with a processor and means for data storage. Used herein, the term “network connection” refers to any means to allow a plurality of computing devices to communicate. Further, the term “trunked” used herein refers to programmatically relating multiple network connections to each other to create redundancy and greater bandwidth in a single logical connection. The term “network packets” refers to a formatted message transmitted over a network. The term “hardware resource” refers to a networkable computing device. The term “virtual resource” refers to an allocation on a networkable computing device which refers to a virtual representation of a computing device or a software application, such as a database. Used herein, the term “management local area network”, sometimes referred to as a “MLAN”, refers to a LAN containing hardware or virtual resources used exclusively for the initialization, configuration, and maintenance of other LANs. 
     Used herein, the term “data center” refers to a central storage complex containing a multitude of servers and network routing hardware. A “traditional data center” is a data center absent of virtualization. The term “virtual firewall” refers to a virtual implementation of a firewall with a virtual Ethernet port. Used herein, the term, “maintaining” refers to keeping a network resource functioning. 
     BRIEF SUMMARY 
     Disclosed herein is a system, method and computer program product for initializing and maintaining a series of virtual local area networks (VLANs) contained in a clustered computer system to replace a traditional data center. A physical network contains a management local area network (MLAN) and numerous client VLANs nested within a top-level VLAN. The MLAN contains at least a physical or virtual firewall. Each client VLAN contains a virtual firewall as well as a number of physical hardware machines and virtual machines maintained by the clustered system. The client VLAN appears as a normal subnet to the user. A network administrator is able to create, change, move, and delete virtual resources contained in a client VLAN dynamically and remotely. 
     The system itself connects a plurality of computer systems as a clustered system through a switched fabric communications link, such as a switch fabric communications link sold under the name INFINIBAND®. All storage devices in the system are clustered to create a distributed file system, which makes the drives appear to be a giant pool of space in which any particular virtual machine may be contained anywhere within. 
     Also described herein is a method for sharing a network resource, physical or virtual, between a plurality of client VLANs. The shared resource may be contained in one of the client VLANs, or in a separate top-level VLAN. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram of the hardware used in the system; 
         FIG. 2  is a block diagram of the VLAN structure; 
         FIG. 3  demonstrates reaching shared resources through a single port of a shared resource firewall; 
         FIG. 4  demonstrates reaching shared resources through multiple ports of a shared resource firewall; and 
         FIG. 5  demonstrates reaching shared resources through private, non-editable client firewalls. 
     
    
    
     DETAILED DESCRIPTION 
     Referring to  FIG. 1 , system  100  comprises a plurality of redundant array of inexpensive storage nodes (RAIDS)  101   a - 101   f , a plurality of non-redundant storage nodes  102   a - 102   c , a plurality of processing nodes  103   a - 103   g , a plurality of network connections  104   a - 104   g , and a plurality of network switches  105   a - 105   b . Storage nodes  101   a - 101   f  are redundant high level storage. Each node is mirrored for a redundant distributed fault tolerant file system. In the embodiment presented in  FIG. 1 , storage nodes  101   a  and  101   b  make a pair,  101   c  and  101   d  make a pair, and  101   e  and  101   f  make a pair. Non-redundant storage nodes  102   a  through  102   c  contain 48 different disk drives with no cross-server redundancy for customers who don&#39;t need the added security of redundancy. Each processing node  103   a  through  103   g  contains 2, 4, 8, or more dual processors. In the preferred embodiment, network connections  104   a  through  104   g  may either be 6 trunked 1 Gbps Ethernet connections, or 2 trunked 4×2.5 Gbps INFINIBAND® connections. In additional embodiments, network connections  104  may use more or less connections and use other protocols. Network switch  105   a  may be a switch such as an Ethernet switch or an INFINIBAND® switch depending on what protocol network connections  104  use; network switch  105   b  is may be a switch such as an Ethernet switch used to communicate outside the network. INFINIBAND® switches use IP-over-INFINIBAND®. The switches are able to add VLANs on a granular level. The switches may natively support Q-in-Q double tagged VLANs, which allow for nested client VLANs out of the box. In other embodiments, all nested client VLAN tags are handled by processing nodes  103 . One of ordinary skill in the pertinent art will recognize that the number of components shown in  FIG. 1  is simply for illustration and may be more or less in actual implementations. 
     Referring to  FIG. 2 , VLAN  2100  is a top-level VLAN used as a management LAN, or MLAN, containing the firewall  2101  initialized by the storage server. MLAN  2100  is responsible for the initialization, configuration, and maintenance of all client VLANs in system  100 , as well as shared resource networks and physical networks on the system. Firewall  2101  has 3 ports, one connected to MLAN  2100 , one connected to the untagged Ethernet port “VLAN 0”, and one connected to VLAN  2200 , the shared resources VLAN. In some embodiments, firewall  2101  is mirrored several times and referred to as a firewall cluster. The firewall cluster is spread across several multiple processing nodes  103  for faster routing. Top-layer VLAN  2300  contains multiple client VLANs  2310 , all with their own firewalls,  2311 . One of ordinary skill in the pertinent art will recognize that the numbers of elements depicted in  FIG. 2  are only exemplary. For instance, each top-layer VLAN may contain up to 255 client VLANs. 
     On bootup, each storage node  101  contacts each of the other storage nodes to discover whether or not any of them has started the boot process of creating a management firewall  2101  of  FIG. 2 , a boot server and a management console  2102 . If none of the other nodes has started the process yet, the pinging node begins the process. Initially the management firewall  2101  or a management firewall cluster is started. If the MLAN  2100  is routed by a virtual firewall, the storage nodes  101  will need to initially run the process that starts the management firewall cluster. This does not preclude a hardware firewall for the MLAN  2100 , but in the preferred embodiment only servers and switches are needed and the same underlying structures that provide redundancy and availability to servers can give high availability to firewalls and routers in a virtual environment. In this preferred embodiment, a group of storage servers can start redundant copies of the firewall/router  2101 . Each instance of the firewall will have the same MAC address and VLAN assignment for any attached Ethernet ports. Using normal routing schemes, this may cause a bank of switches to route packets to differing firewalls depending on the source of a connection, but this will have no ill effects if the network devices in question continue to have the same settings and routing information. 
     The management console  2102  has many of the same properties as the firewall in system  100 . While in the preferred embodiment it is run on the storage nodes  101  as a virtual machine, can likewise be a physical machine. It is started up at the same time as the firewall/router cluster and can also be deployed in a cluster format. 
     In one embodiment, the boot server contains a tftp server, an NFS server, a PXE boot service and a preconfigured kernel image. This image will have a runtime environment for the local interconnect (INFINIBAND®, trunked Ethernet or other similar high speed interconnect) and the ability to mount the clustered file system that exists across the storage nodes  101 . The processing nodes  103  then contact the management console  2102  for initial settings such as an IP address and host name, for example. The clustered file system is mounted and the processing nodes  103  boot in a normal fashion. Once startup is complete the processing nodes  103  contact the management console  2102  and indicate that they are ready to take a load of virtual machines to host for clients. 
     Once the processing nodes  103  have begun to activate, the management console  2102  gets a list of virtual machines that need to be started up by the processing nodes  103  from its datasource. The management console  2102  then begins to start virtual machines on processing nodes  103  in a weighted round robin fashion. Processing nodes  103  are assigned to groups based on their capabilities and architecture; for example, 64-bit processing nodes would be associated as a group. There is a server mask for each virtual machine that assigns it to a particular processing node group. This is both to comply with per-processor licensing issues and to ensure that virtual servers with particular hardware, redundancy or connectivity requirements can be met by the appropriate physical machine. During the startup process management console  2102  may even initiate a delay if more virtual machines exist than the bank of processing nodes  103  can run. After a predetermined interval, if this imbalance is not corrected, a warning system will be started to alert human operators of the lack of server resources. As the virtual machines are assigned to physical servers, each physical server reports CPU and memory usage to the management console  2102  and these figures are used as selection mechanisms to ensure that processor and memory loads are evenly distributed across all physical nodes. Even after the physical layer is booted, the processing nodes  103  continue to report CPU and memory usage to the management console  2102  at regular intervals. 
     The virtual servers undergo a normal startup process themselves. Once a command to start a virtual server is issued, (either by a system-wide startup, client start command or other system need) the management console  2102  takes the start request and queries the datasource of available processing nodes. Once one is selected by the mechanism mentioned above; that virtual server creates an Ethernet device that is attached to either the top layer VLAN or the Q-in-Q nested VLAN  2310  that the virtual server connects to. Unlike normal Ethernet devices, this VLAN device is not given an IP address or any routing information. The physical server itself does not respond and actually does not see any packets it receives from this interface. The physical device is instead mapped directly to a virtual one, giving the virtual machine access to a completely separate network than the physical machine exists on. After the appropriate network devices are added to a processing node, the management console  2102  then queries its datasource and connects to the client&#39;s hidden firewall. This firewall, as described later in reference to  FIG. 5 , is for routing console and virtual screen information from the MLAN  2100  back to the client&#39;s network and represents a NAT mapping from the MLAN  2100  to the clients subnet. In the current embodiment, a virtual serial port is used to add rules to this virtual routing device to keep the methodology consistent with non-addressable firewalls that clients may want to add rules and configurations to. This is not necessary, however since this translating firewalls an IP address that exists in the MLAN  2100  directly. 
     On startup of the virtual machine a rule is added to provide the client with console access to a web interface to the management console  2102 . This gives the clients the ability to access virtual servers as if they were at the keyboard of a physical machine. From the clients secure management console web interface they are able to control the screen, keyboard and mouse inputs of their virtual servers. In the current embodiment VNC is used as a remote console but other protocols are available. During this process the virtual server itself is issued a start command and is then accessible to the client. 
     When a new client is added, they are given a number of external IPs and a unique subnet of their network. Every possible IP of the subnet is statically assigned to a MAC address that may or may not be used. A client VLAN  2310  is created and the first address of the subnet is assigned to the client VLAN&#39;s firewall  2311 . The firewall contains a DHCP table that is created when the firewall is initialized to hold the mappings of the preregistered MAC addresses to IPs so that the IP is known as machines are added. The client is given a gateway  2001  configured to deliver the client&#39;s network packets directly to the virtual firewall  2311  through an IPSEC tunnel. In addition, network packets of all external traffic are routed directly to the client&#39;s virtual firewall  2311 . Virtual firewall  2311  has one port connected to external port  2317  which receives external traffic through network switch  205   b , which is equivalent to network switch  105   b . Traffic from the client through the IPSEC tunnel to the client&#39;s personal VLAN  5310   a  is shown as a dotted line in  FIG. 2 . Virtual firewall  2311  further has one port connected to their personal client VLAN  2318 , and in some embodiments, an optional port for connecting to shared resources  2319 , such as those contained in VLAN  2200 , or in another client VLAN. 
     The last address of the subnet is assigned as the management console  2102 . The management console  2102  is connected to main firewall  2101  in MLAN  2100  and, in some embodiments, is reached through the optional port of the client firewall. From there, the client may view network settings and add machines  2312 - 2315 . The client is able to create and be charged for virtual machines on their client VLAN through the management console  2102  remotely. The client is capable of adding 253 virtual machines. The virtual machines may be just about any kind of machine, such as a Windows or Linux web server, a voice-over-IP server, etc. After a machine is chosen, a MAC address is assigned from the client firewall  2311  and a template image corresponding to the machine from a storage node  101  is taken and initialized in storage depending on the kind of storage system the client has chosen (redundant storage nodes  101 , or non-redundant storage nodes  102 ). From there, the management console  2102  adds the machine to the list of machines that need to be ran. The next processing node  103  that inquires on tasks that need to be run is assigned the machine. If it is the first machine run on that particular client VLAN, it starts up a virtual listening port for that VLAN. Once the virtual machine is connected to the VLAN, the firewall looks at its MAC address and assigns it its preconfigured IP address from the DHCP table. 
     The client is able to use VNC or remote desktop to login to the newly created virtual machine and see the user API/GUI as if they were sitting in front of a physical machine with the same image. From there the user is allowed to do anything that can be normally done on a physical machine, completely abstracted from the virtualization of the machine or the fact that it is contained in a VLAN ran on system  100  in a distant data center. To the user, virtual machines  2312 - 2315  appear to be like any other machine contained on a traditional network subnet. 
     The client is also able to add a physical machine to their subnet. In the preferred embodiment, the switches natively support Q-in-Q double tagging, which allows for routing double tagged network packets to physical machines out of the box. In other embodiments, the nested client VLAN is turned into another top-layer VLAN to allow for physical machines on the VLAN. 
     Clients are able to share resources either between their client VLANs, or in a shared resources network such as resources  2202 - 2205  in VLAN  2200 . In some embodiments, clients are able to connect to these resources by setting up the optional port on their client firewall  2311  to connect to the IP of the selected shared resource. An empty VLAN is created between the ports of both firewalls on both sides as a “virtual wire”. Rules are set up on the firewalls on both ends to handle the new traffic. On the client VLAN side, firewall  2311  dynamically adds a virtual port to itself and maps the port in a network address table within client firewall  2311 . If a client wishes to share resources from more than one location, multiple optional ports may be added. In this situation, the firewall must be temporarily shutdown to make the configuration. 
       FIG. 3 ,  FIG. 4 , and  FIG. 5  show alternate embodiments for routing data through system  100 . Referring to  FIG. 3 , shared resource VLAN  3200  and client VLANs  3310  are identical to shared resource network  2200  and client VLANs  2310 , respectively. Shared resource firewall  3201  has one port for incoming resource requests. The connection is essentially a “virtual switch”, labeled as  3206 , that filters traffic based on incoming IPs. Using the “virtual switch”, client VLANs  3310  are able to reach their designated shared resources, residing within  3202 - 3205 . Referring now to  FIG. 4 , shared resource VLAN  4200  and client VLANs  4310  are identical to shared resource network  2200  and client VLANs  2310 , respectively.  FIG. 4  shows an alternate embodiment that has a separate port on shared resource firewall  4201  for each incoming connection from client VLANs  4310  attempting to use a shared resource  4202 - 4205 . A firewall rule is designed for each individual port. 
       FIG. 5  illustrates the preferred embodiment of handling shared resources. The system of  FIG. 5  is identical to that of  FIG. 2  with the addition of each client VLAN  5310  containing a second firewall, private firewall  5316 . Private firewall  5316  is not editable by the client and contains predefined rules to reach shared resources within shared resource VLAN  5200  or within another client VLAN, VNC connections to physical machines on the client&#39;s subnet, and the management console  5102 . Using this non-editable private firewall ensures that a user does not inadvertently change routing rules that hinder routing throughout system  100 .