While subscribers to cloud-hosted versions of CSO, like CSO 5.0, do not need to be concerned with installing the software, it is often helpful to understand the installation environment. This topic covers the installation architecture. The details of which are relevant to on-premise CSO deployments.
CSO is installed as a series of VMs connected and working together to provide the complete platform. CSO requires Ubuntu as the bare-metal OS, and supports two hypervisor options: KVM (provided by Ubuntu) and VMware ESXi.
For on-premise CSO Releases 4.1 and later, there are three environment types:
Large (HA-capable) - supports approximately 6000 sites
Medium (HA-capable) - supports approximately 3500 sites
Small (not HA-capable) - supports approximately 450 sites
Whether or not HA is enabled is controlled by choices during the installation process. The general architectures for these environments are described below.
For details regarding installation requirements, sizing options, and more, see CSO 4.1 release notes and Contrail Service Orchestration Installation and Upgrade Guide - Version 4.1.
Installation Architecture Design
While the large and medium deployment options above provide HA in the form of spreading the central, regional, and Contrail analytics nodes across multiple physical servers, this in itself is not necessarily enough to provide full HA support for the environment. It is also important to consider how best to distribute the servers and build redundancy into the infrastructure to ensure that the loss of a server does not impact overall CSO functionality.
Figure 1 shows an example of a highly redundant large CSO installation environment. This setup has many layers of redundancy built in:
With the large installation option, CSO functionality is spread across three nodes—central, regional, and Contrail analytics (CAN)
The three nodes are spread equally across seven physical servers
The servers are separated into three “server redundancy groups” that include one server from each node type
Each server redundancy group uses a separate power supply
Each server redundancy group connects to a separate (logical) TOR switch
Each TOR switch is actually multiple EX/QFX Series devices configured as a Virtual Chassis
Each TOR switch has dual connections to the aggregation switch
The aggregation switch has dual connections to the gateway