Building a Resilient CommandCenter Datacenter Management System

June 21, 2010

One of the most important considerations in designing a Raritan enterprise datacenter management system is the architecture of the CommandCenter systems. This discussion provides an overview of how CommandCenter works and how it can be effectively deployed.

CommandCenter Architecture Overview

CommandCenter provides a single point of user access for all devices and systems under its management. The CommandCenter appliance is based on a hardened and secured Linux kernel. The CommandCenter appliance has dual hard drives in a RAID 1 configuration, dual 10/100/1000 NICS, and available dual power supplies. It is a fault tolerant appliance that is not prone to Windows/MS issues.

The primary function of CommandCenter is to provide centralized access to all datacenter IT resources. It also provides centralized user authentication, authorization, auditing, and reporting. Users connect to the CommandCenter and are authenticated and granted access based on local CommandCenter policies. User authentication can be Local, Active Directory, LDAP, TACACS, Radius, Radius w/RSA, or any combination of these. Once users are authenticated, their session is redirected and is sent directly to the desired KVM/Serial switch or datacenter device. This keeps traffic local between the user PC and the KVM/Serial switch or datacenter device. This architecture means CommandCenter systems are very robust, very scalable, and require minimal LAN/WAN bandwidth.

One of the most important considerations in designing a Raritan enterprise datacenter management system is the architecture of the CommandCenter systems. This discussion provides an overview of how CommandCenter works and how it can be effectively deployed.

CommandCenter Architecture Overview

CommandCenter provides a single point of user access for all devices and systems under its management. The CommandCenter appliance is based on a hardened and secured Linux kernel. The CommandCenter appliance has dual hard drives in a RAID 1 configuration, dual 10/100/1000 NICS, and available dual power supplies. It is a fault tolerant appliance that is not prone to Windows/MS issues.

The primary function of CommandCenter is to provide centralized access to all datacenter IT resources. It also provides centralized user authentication, authorization, auditing, and reporting. Users connect to the CommandCenter and are authenticated and granted access based on local CommandCenter policies. User authentication can be Local, Active Directory, LDAP, TACACS, Radius, Radius w/RSA, or any combination of these. Once users are authenticated, their session is redirected and is sent directly to the desired KVM/Serial switch or datacenter device. This keeps traffic local between the user PC and the KVM/Serial switch or datacenter device. This architecture means CommandCenter systems are very robust, very scalable, and require minimal LAN/WAN bandwidth.

CommandCenter Deployment Strategies

Single CommandCenter  --  A single CommandCenter may be used for basic deployments where KVM systems are not considered strategic and CommandCenter redundancy is not essential. While the CommandCenter is a fault tolerant device, it still may be vulnerable to failures as well as network issues that may prevent users from accessing it.

The CommandCenter system was designed modularly and allows users to implement many levels of fault tolerance. In normal operation, devices under CommandCenter control (managed mode) will not allow direct user network logons (configurable), this by design, requires users to connect to the CommandCenter for access (the local port of the KVM switch is always available). In the event the CommandCenter fails or is unreachable, users can directly access via IP, it’s managed devices such as KVM or serial switches, after approximately 7 minutes. The managed device will automatically detect that the CommandCenter is no longer reachable and run in standalone mode. When CommandCenter is reachable again, the devices will automatically revert to managed mode.

CommandCenter Cluster  --  In enterprise environments, the CommandCenter is most often deployed as a cluster. A cluster consists of two CommandCenter systems. The cluster implements a primary/backup strategy with one unit active and the other passive. This clustering strategy is very effective and scalable because the CommandCenter only parses authentication/authorization requests. The active/passive configuration assures consistency at all times. Changes made to the primary are dynamically updated on the backup. The CommandCenter cluster always has the current configuration status as well as the entire log of user activities and access. It is simple to deploy, cost effective, and most importantly, very reliable. The two CommandCenter’s can be placed anywhere on the network. Clustered CommandCenter’s are best deployed (each) at two different locations, preferably at main datacenter facilities, or on two different IP networks. This provides high availability and fault tolerance. The two CommandCenter applications exchange a “heartbeat” protocol so that the status of each is always known. In the event of a CommandCenter failure or network outage, the backup will detect the loss of connectivity to the primary, and automatically switch to primary mode. This allows users to continue to access managed devices in a failure mode. When an unreachable primary CommandCenter recovers, it can automatically rejoin the cluster (this is a configurable option).

CommandCenter Cluster with Hot Spares  --  For strategic KVM deployments with many datacenters, Clustered CommandCenter’s and hot spares offer another level of resiliency. A CommandCenter cluster is deployed at two main datacenters. Additional hot spare CommandCenter’s are deployed at other facilities. The hot spares are simply powered on, given an IP address, and connected to the network. A typical deployment might be the primary CommandCenter is in the New York datacenter, the backup CommandCenter in the Chicago datacenter, a hot spare in a disaster recovery site, and another hot spare in the Washington datacenter. If the primary CommandCenter in New York fails, the backup in Chicago will automatically come on-line as the new primary. A cluster can then be created between the Chicago and disaster recovery sites or the Washington site CommandCenter.

CommandCenter Neighborhoods  --  For deployments with many sites across multiple continents or large multinational companies, CommandCenter Neighborhoods may be desirable. Large organizations such as multinational companies often segregate systems based on geographic or functional/divisional boundaries. Neighborhoods allow each region/division to be autonomous and maintain independent control and administration of their CommandCenter system, while still allowing users access to all devices in all neighborhoods from a single GUI and logon. This approach consists of deploying a separate CommandCenter Neighborhood for each region or division. For a large multi-national company, a Europe Neighborhood, an Asia Neighborhood, and a North America Neighborhood may be optimal. Each Neighborhood is a separate and independent entity. Implementing Neighborhoods will require at least one CommandCenter per Neighborhood and ideally a cluster for redundancy within the Neighborhood. This also provides additional fault tolerance and resiliency since each Neighborhood is independent and effectively isolated. Each Neighborhood can perform authentication based on regional objectives, or use a centralized authentication scheme for a more integrated approach. Users access any Neighborhood’s devices from a single logon and GUI. The underlying operation of a CommandCenter Neighborhood is best understood if you envision a browser with a separate link to each Neighborhood’s CommandCenter system. By selecting the appropriate link, users seamlessly access each Neighborhoods IT resources.

Other Considerations  --  IP-based KVM systems provide a tool to access and resolve server and other device issues. These systems are dependent on a reliable and well architected IP network infrastructure. A best practice is to put KVM/Serial systems on a separate “Service LAN” within the datacenter. If there is a failure on the Primary LAN, KVM/Serial systems may still be accessible to remediate the problems. The key to reliable datacenter access is to integrate the CommandCenter architecture with a resilient LAN/WAN infrastructure.