COVID-19: Critical business support and our focus on employee health. Learn More

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

The New Dominion LX II: Why You Should Trade Up
Posted on April 2, 2020
Coronavirus Remote Management Checklist
Posted on March 18, 2020
The New Dominion LX II: Java-Free KVM-Over-IP for SMBs
Posted on February 5, 2020
Dominion KX IV-101 Newest Firmware Update
Posted on December 17, 2019
Rack PDUs Outlet Density and Types
Posted on November 14, 2019

View all Blog Posts

Subscribe


Upcoming Events

2020 DoDII Worldwide
August 2–5  •  Phoenix, AZ
AFCOM Data Center World 2020
August 24–27  •  San Antonio, TX
DCD NY 2020
September 1–2  •  New York City, NY
Critical Facilities Connect 2020
September 14–15  •  Charlotte, NC
Spiceworld 2020
September 15–20

View all Events

Latest Raritan News

Raritan Introduces Economical New Generation KVM-Over-IP Switch and Serial Access for SMBs
Posted on March 2, 2020
Extended IT rack power mapping possibilities with Raritan’s locking solution
Posted on October 23, 2019
Raritan Ranked as the Global Leader in KVM-over-IP Switches
Posted on October 21, 2019
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

View all news