The Raritan Blog

Building a Resilient CommandCenter Datacenter Management System

Posted on June 21, 2010 by Website Administrator

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 it’s 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 it’s 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 offers 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 site 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 allows 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.

Other Blog Posts

What Is Environmental Monitoring?
Posted on September 18, 2019
Different Types of Rack PDUs
Posted on September 10, 2019
Power Monitoring And Metering
Posted on August 28, 2019
Virtual Power Button on the KX IV-101
Posted on August 27, 2019
Common Electrical Terminology
Posted on August 20, 2019

View all Blog Posts

Subscribe


Upcoming Events

West 2019
February 13 - 15  •  San Diego, CA
Data Center World Global 2019
March 19 - 22  •  Phoenix, AZ
Data Center Dynamics NY
April 9 - 10  •  New York, NY
NAB 2019 - National Association of Broadcasters Show
April 6 - 11  •  Las Vegas
Interop 19
May 20 - 23  •  Las Vegas, NV

View all Events

Latest Raritan News

Raritan’s New KVM-over-IP User Station Brings 4K Performance and Productivity to Remote Equipment Access
Posted on September 18, 2019
Raritan’s New 4K Ultra HD KVM-over-IP Switch Wins Best of Show Award at NAB
Posted on May 21, 2019
Raritan Unveils KVM-over-IP Switch with Enhanced Performance and 4K Ultra HD
Posted on April 4, 2019
Raritan Announces New SmartSensors™ for Accurate Insights on Data Center Environmental Health
Posted on January 28, 2019
Raritan Extends Reach of Remote Server Management with New KVM Product
Posted on November 26, 2018

View all news