Component-Specific Processes

Overview

The CloudCenter platform is based on several processes that enable multiple CloudCenter functionalities. The process-based, service-oriented-architecture provides a more reliable and resilient platform.

Required Components

This section identifies the processes used by each required CloudCenter component.

CCM Processes

If you start the CCM (ccm) service, it should start all the dependent processes as needed by the CCM server. The list of CloudCenter processes on the CCM server are as follows:

  • notification

  • mgmtserver

  • hazelcast-server

  • config-server

  • cliqr-esb

  • ccm

  • nginx

  • mongod

  • capacity-manager

  • filebeat

MGMTPOSTGRES Processes

If you start the postgres service, it should start all the dependent processes as needed by the MGMTPOSTGRES server(s).

In a HA environment, the list of CloudCenter processes on the MGMTPOSTGRES servers are as follows:

  • pcs

  • pacemaker

  • corosync

CCO Processes

If you start the CCO (cco) service, it should start all the dependent processes as needed by the CCO server(s). The list of CloudCenter processes on the CCO server are as follows:

  • gateway

  • config-server

  • cco

  • mongod

  • docker

  • cloudblade

  • container-blade

    Depending on the cloud that is enabled, the CloudCenter platform enables either the cloudblade process or the container-blade process at the time of installation.

    You can view log levels and log tracking status for the following processes:

    • config-server

    • cloudblade

    • container-blade (for containers like Kubernetes)

    See the View Log Elements API for additional context.

  • docker

  • capacity-collector

AMQP Processes

The list of CloudCenter processes on the AMQP server are as follows:

  • config-server

  • cliqr-guacamole-client

  • cliqr-connection-broker

  • rabbitmq-server

Optional Components

This section identifies the processes used by each optional CloudCenter component.

Log Collector Processes

The list of CloudCenter processes on the Log Collector server are as follows:

  • ElasticSearch

  • Logstash

  • Kibana

Repo Processes

If you start the Nginx service, it should start all the dependent processes as needed by the REPO server(s).

The Cloud-Specific capacity-collector Process on the CCO

The capacity-collector process is only enabled on the CCO if the cloud name is one of the following:

  • VMware vCenter

  • OpenStack

For all other clouds, if you see that the capacity-collector process is running, you must stop the service. See Capacity Management for additional context on this feature.

  1. Verify if the capacity-collector process is running by executing the JPS command on the CCO server as root:

    root> jps
    3619 config-server.jar
    5011 container-blade.jar
    3638 gateway.jar
    5052 Jps 
    3615 capacity-collector.jar #This indicates that this process is running
  2. If this command is running, issue the following command to manually stop the capacity-collector.


    root> systemctl stop capacity-collector


Log File for a Process

The log file message in the corresponding log file for each component indicates that the process is up and running. The following is an example of the successful CCO gateway process (/usr/local/cliqr/logs/gateway.log):

2018-04-09 23:55:20,470 INFO  orchestrator.OrchestratorServer [main]  - 
Started OrchestratorServer in 30.553 seconds (JVM running for 32.062)

See the Locate Log Files for additional details.

Stopping a Process

This procedure requires root access.


To stop any process, issue the following command:

root> systemctl stop <process>

Restarting a Process

This procedure requires root access.

To restart any process, issue the following command:

root> systemctl start <process>

If for some reason one of these processes don’t start after a reboot the most common cause of the problem could be the lack of sufficient resources.

The Status of a Process

To view the status of any process, issue the STATUS command:

systemctl status <process>
  • No labels
© 2017-2019 Cisco Systems, Inc. All rights reserved