Installer Overview

CloudCenter Installer Architecture

Installer Files

The easiest way to install CloudCenter components is to use the Virtual Appliance method. A majority of our CloudCenter customers use Virtual Appliances to install all CloudCenter components.

We recommend that you only use the Installer method for unique installation scenarios (for example, if you use custom OS images).

The …-installer-artifacts.tar file  is available from software.cisco.com and un-tar the downloaded file. Installers are available for ALL components for all supported clouds. To use the installer method, contact CloudCenter Support team.

Modes

You can set up CloudCenter components in various modes based on scalability or high availability requirements. Each mode has its unique infrastructure requirements (VM, Load Balancer-LB, Virtual/Elastic IP address). Different CloudCenter components can be installed in different modes in the same installation. For example, you can install CCM in HA mode and the AMQP in Non-HA mode.

Sample network architectural diagrams for each mode are available at the end of this section.

  • NON-HA: This mode is available for all components. A single VM is required for each component while both the web server and database for the CCM reside on the same VM.

  • NON-HA-Non-HA Standalone: This mode is only available for the CCM web server. A single VM is required for each component while the web server and database for the CCM resides on two separate VMs. This is the recommended mode to transition to the HA mode in the future.

  • HA: This mode is only available for CCM, PostgreSQL database, CCO, AMQP and Guacamole servers.

    • Two separate VMs are required for the following components:

      • CCM web server (2) plus a load balancer

      • PostgreSQL database (2) plus a load balancer

      • AMQP (2) plus a load balancer

      • Guacamole (2) plus a load balancer

    • Three separate VMs are required for the CCO (3) plus a load balancer

    • One CM for the Cloud Health Monitor (1) – a required component.

See the tables at the end of this page for a detailed breakdown of the number of servers required for each mode.

Network Architecture Diagrams

         

Components

The CloudCenter platform is made up of 4 required components and multiple optional components. Each component VM is assigned a role depending on the mode (Non-HA, Non-HA Standalone, or HA) in which you install each component. For example:

  • CCM role for a Non-HA deployment
  • CCM_SA and MGMTPOSTGRES roles for a Non-HA Standalone deployment
  • CCM_SA_PRIMARY, CCM_SA_SECONDARY, MGMTPOSTGRES_MASTER, MGMTPOSTGRES_SLAVE, CCM_LB roles for a HA deployment

The roles for each component and mode are described in the following sections.

Per CloudCenter Deployment

These components are installed on a per-deployment basis.

CCM (Required)

The CloudCenter Manager (CCM) is a centralized management console that allows users to model, deploy, and manage workloads on different clouds.

CCM ModesRole NameTypeOS OptionsPurpose
NON-HA
CCMVM
  • CentOS7
  • CentOS6
  • RHEL7
  • RHEL6
CCM web server and database
NON-HA-Non-HA Standalone
CCM_SAVMNon-HA Standalone CCM – web server only
NON-HA-Non-HA StandaloneMGMTPOSTGRESVMNon-HA Standalone PostgreSQL database server only
HA
CCM_SA_PRIMARYVMNon-HA Standalone Primary CCM – web server only
HA
CCM_SA_SECONDARYVMNon-HA Standalone Secondary CCM – web server only
HA
MGMTPOSTGRES_MASTERVMPostgreSQL Master database server
HA
MGMTPOSTGRES_SLAVEVMPostgreSQL Slave database server
HA
CCM_LBLoad Balancer -Balance incoming requests across both CCM VMs
HA
MGMTPOSTGRES_VIPVirtual IP (VIP) or Elastic IP (EIP)

 -

Attach to one of the PostgreSQL servers to enable dynamic switching to the active server if one of the servers go down

Cloud Health Monitor (Required)

The Cloud Health Monitor (monitor) is a required, independent CloudCenter component that monitors the cloud and CCO health status. The monitor performs the following functions:

  • Periodically checks the health status of the CCO for each cloud.

  • Persists cloud health status change events.

  • Displays results from these checks on the CCM UI Dashboard.

  • Contains the log repositories for the CCM and CCO logs.

The Elasticsearch, Logstash, and Kibana, collectively referred to as the ELK stack, are installed by default when you install the Health Monitor.

Monitor ModesRoleTypeOS OptionsPurpose
NON-HA
MONVM
  • CentOS7
  • CentOS6
  • RHEL7
  • RHEL6
Monitor health of Cloud Region and report to the CCM

CloudCenter Bundle Store (Required if you do not have Internet access)

The CloudCenter Bundle Store is an HTTP repository and consists of the following files (provided by Cisco): 

  • Agent package: Files used by your application VMs for bootstrapping purposes

  • Service definitions: Files used to install, deploy, and configure out-of-box (OOB) service definitions

This store is hosted by Cisco at cdn.cliqr.com. If your application VMs do not have access to the Bundle Store over the Internet, you must host you own local bundle store.

The CloudCenter platform uses the following role to validate access to the network.

Bundle Store TypeRoleOS OptionsPurpose
HTTP Web Server    BUNDLE_STORE-Host CloudCenter agent binaries and out-of-box service scripts

CloudCenter Package Store (Required if you do not have Internet access)

The CloudCenter Package Store contains different packages for CloudCenter components, such as out-of-box services.

The Package Store is available at repo.cliqrtech.com. It uses a static IP address that you can retrieve by issuing the following command:

ping repo.cliqrtech.com

If you do not have internet access, then you must create a local version of the Package Store and register it with your CCO implementation.

The CloudCenter platform uses the following role to validate access to the network.

Package Store TypeRoleOS OptionsPurpose
VM                                                PACKAGE_STORE
  • CentOS7
  • CentOS6
  • RHEL7
  • RHEL6
Host binaries for out-of-box service scripts and software required to setup other CloudCenter components (JDK, PostgreSQL, and so forth)

Dedicated Docker Registry (Required if you do not have Internet access)

By default, some CloudCenter like CloudCenter services and some features like external script executor require access to the base Docker image provided (by default, CentOS 7 images) by Cisco. If you have internet access, the container image is pulled directly from the Docker hub over the intenet. If you do not have internet access, you must set up a dedicated Docker registry that can host the container images.

The CloudCenter platform uses the following role to validate access to the network.

Dedicated Docker Registry TypeRoleOS OptionsPurpose
VM                 DOCKER_REGISTRY
  • CentOS7
  • CentOS6
  • RHEL7
  • RHEL6
Docker-based host container images for out-of-box services

Per Cloud Region

Cloud Region refers to single public cloud region, private virtualized datacenter, or private cloud supported by CloudCenter. Each cloud region is identified in the CCM UI when you configure clouds. For every cloud region that needs to be managed by the CloudCenter platform, you must install, setup, and configure the following CloudCenter components.

CCO (Required)

The CloudCenter Orchestrator (CCO) must be deployed to every cloud region. The CCO is a backend server that intelligently interacts with cloud endpoints to handle application deployment and runtime management. CCO decouples an application from its underlying cloud infrastructure in order to reduce the cloud deployment complexity.

  • CloudCenter requires one CCO per cloud region, unless the application network is completely isolated and does not have outgoing connections.
  • CloudCenter treats an isolated network (VPC) with VPN as a private cloud which requires a separate CCO.
  • Each CCO must register with a CCM. The CCO communicates directly with the CCM irrespective of the cloud on which the CCO is deployed.
CCOs Per Cloud Region

Depending on the cloud type, one CCO is required for each cloud region or private data center.

Cloud Type

Supports only one combination of these per CCO

Supports any number of these per CCO

AWSRegion
  • Accounts
  • Sub-Accounts
  • Identity and Access Management (IAM)

VMware vCenter

vCenter instance

  • Datacenter
  • Clusters
  • Resource pools
  • Accounts
  • Datastores
  • Datastore clusters
VMware vCD

vCD instance/endpoint

vCD

MicrosoftAzureRegion
  • Networks
  • Cloud services
  • Accounts
Google CloudRegion
  • Projects
  • Accounts
OpenStackRegion
  • Tenants
  • Networks
  • Accounts
SoftLayer (Bluemix)Region
  • Accounts
  • Networks
AlibabaRegion
  • Accounts

  • Networks

Dimension Data (DiData)

Region

  • Accounts

  • Networks

Cisco UCSD

UCSD instance

Not applicable


CCO ModesRoleTypeOS OptionsPurpose
NON-HA
CCOVM
  • CentOS7
  • CentOS6
  • RHEL7
  • RHEL6
The Orchestrator
HA
CCO_PRIMARYVMThe Primary Orchestrator
HA
CCO_SECONDARYVMThe Secondary Orchestrator
HACCO_TERTIARYVMThe Tertiary Orchestrator
HA
CCO_LBLoad Balancer -Balance incoming requests across both CCO VMs

AMQP (Required)

The CloudCenter platform features Advanced Message Queuing Protocol (AMQP) based communication between the CCO and the Agent VM. The CloudCenter platform incorporates RabbitMQ as the open source message broker for AMQP implementation.

If your application VMs run in isolated networks (like Amazon's VPC), setup your NAT rules for only outgoing traffic so that your VMs can connect to RabbitMQ.

The following diagram shows the association between CloudCenter components and AMQP. Note that one AMQP instance is required for each CCO implementation.

AMQP ModesRoleTypeOS OptionsPurpose
NON-HA
AMQPVM
  • CentOS7
  • CentOS6
  • RHEL7
  • RHEL6
RabbitMQ-based Message Queue
HA
AMQP_PRIMARYVMPrimary RabbitMQ-based Message Queue
HA
AMQP_SECONDARYVMSecondary RabbitMQ-based Message Queue
HA
AMQP_LBLoad Balancer-Balance incoming messages across both AMQP VMs


External Script Executor (Required if RHEL/CentOS 6.x)

The CloudCenter platform enables you to execute custom scripts by the CCO during your CloudCenter application lifecycle. The custom scripts are run inside a Docker-based script executor (referred to as External Script Executor) for security purposes.

This component is required if your CCO OS Version is RHEL 6.x or CentOS 6.x:

CCO Server's Base OS ImageThe Script Executor SetupRequired?
RHEL 7.x and CentOS 7.x

Embedded in the CCO by default on the OS(s) used by CloudCenter.

Optional based on your requirement for a dedicated server.

RHEL 6.x and CentOS 6.x

Docker is not supported for this OS.

You must set up an External Script Executor.

Yes

Scalability Considerations

You may also choose to setup a dedicated script executor (standalone Docker container) for regions using RHEL 7x or CentOS 7x in order for the CCO server to be suited for a possible increase in scalability.

Ext_Script_Executor ModeRoleTypeOS OptionsPurpose
NON-HAEXT_SCRIPT_EXECUTORVM
  • CentOS7
  • RHEL7
Docker-based isolated script execution environment

Guacamole Server (Optional, to restrict AMQP server access)

The CloudCenter platform uses the Guacamole server to enable remote secure web based connections (for example, SSH, VNC, and RDP) to access VMs launched during the application lifecycle process. By default, the Guacamole module is packaged with the AMQP component and installed by default.

If you need to deploy Guacamole as a Non-HA Standalone server to prevent the exposure of AMQP servers to your end users, then install the Guacamole module on the Non-HA Standalone server and open the ports listed in Guacamole Firewall Rules.

Guacamole ModesRoleTypeOS OptionsPurpose
NON-HA
GUACVM
  • CentOS7
  • CentOS6
  • RHEL7
  • RHEL6
Guacamole-based server to enable web based SSH/VNC/RDP
HAGUAC_PRIMARYVMPrimary Guacamole server.
HA

GUAC_SECONDARY

VMSecondary Guacamole server.
HAGUAC_LBLoad BalancerBalance incoming messages across both Guacamole servers.

Base OS Image Preparation (Required for Clouds that do not support Dynamic Bootstrapping)

Base OS Images (also referred to as Worker images) are only required for clouds that do not support dynamic bootstrapping. Some clouds, such as VMware, SoftLayer, and DiData, that do not support dynamic bootstrapping will require base OS image preparation. See Base OS Images for additional context.

Base OS TypesRoleOS OptionsPurpose
VM image                         LINUX_WORKER_OS_VERSION
  • CentOS7
  • CentOS6
  • RHEL7
  • RHEL6
  • Ubuntu 12.04
  • Ubuntu14.04
Machine image to be used when launching VMs during application orchestration.

VM image

WINDOWS_WORKER_OS_VERSION
  • Win2k8,
  • Win2k12
Machine Image to be used for launching VMs during application orchestration.

Unable to render {include} The included page could not be found.



© 2017-2019 Cisco Systems, Inc. All rights reserved