Sample OpenStack Appliance Setup

Setup Process

To prepare infrastructure using CloudCenter appliances for OpenStack clouds, follow this process.

  1. Import the CloudCenter QCOW2 images into the OpenStack Console.
  2. Launch the instance for each component using the imported images:
  3. Configure the security groups to associate with each VM and enable communication across various components.

    The network settings in this page provide the minimal port requirements for inter-component communication. In environments where all the components can communicate with each other via any port (typically POC environments or private datacenters), you can skip this phase.

    Production environments typically are secured by only allowing communication through the ports specified in this section.

    The tables in Phase 2: Configure Firewall Rules list the networking requirements for each Component Role.

  4. Select a new or existing key pair to log into each instance – if multiple key pairs are available, you must select one to be used for the CloudCenter instance.

    If you do not select a key pair, you will not be able to log into the component VM!


    • Select an existing key pair from your OpenStack console.

    • Import a new key pair – use the following authentication details to access the key pair information:

      • Username: centos

      • Key: The key used to launch the instance in the OpenStack console – use the following command to retrieve the key pair from your server and paste it in the OpenStack cloud console:

        $ cat my-public-key.pub 
        ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC4x93DDQBAwT5D54aQrKdUHQNaakuddaWZxpcYfQCTL
        ...
        ...
        /fHJlDYDjFqrCILgvZqQ76J

        After adding a Private Network to the instance, be sure to inject the key-pair correctly.

  5. Setup hostname – For all launched VMs, update the hostname. Choose a hostname that matches the Virtual Appliance Overview > Role. For example:

    1. hostname – For all launched VMs, update the hostname.

      Don't change the hostname after you install and configure a component as it may cause unknown issues.

      Choose a hostname that matches the Role. For example:

      Example
      CCM.mydomain.com
    2. Setup the hostname resolution – Once you update the hostname, ensure that the VM host name is resolvable by running the following command

      1. hostname

      2. If the VM name is not resolvable, edit the file /etc/hosts and add your VM’s hostname.
        For example:

        Example
        12.168.20.5 ccm.example.com
      3. In addition, for OpenStack you must make sure that the hostname doesn't change in case of a server restart. Add the hostname entry in the /etc/sysconfig/network file, on each server that requires a DNS name instead of the IP address:

        Required for OpenStack Deployments!
        HOSTNAME=<hostname>
    3. Network routing loopback:

      1. Refers to deployed CCMs that are running behind the Network Address Translation (NAT).

      2. This setup places a restriction on machines from internal networks to ensure that they do not use an external IP to access the CCM.

      3. To address this restriction, you must add a line to the CCO and AMQP server's /etc/hosts file and include the internal private IP of the CCM. For example: If the CCM DNS name is ccm.example.com and it is behind a NAT, and the internal private IP address is 192.168.20.5 and its external public IP address is 54.16.20.5, then enter the following line in the local /etc/hosts file:

        Example
        192.168.20.5 ccm.example.com

        When configuring the CCM, the hostname used above (ccm.example.com) must match what you configure as the Public DNS while configuring CCM.

    4. Create the CloudCenter-specific Checker JSON file:
      After you setup the infrastructure for all the CloudCenter components, create a CloudCenter checker JSON file that lists all the CloudCenter components with their modes and the IP address that correspond to infrastructure elements for each mode and role. This Checker JSON file will be used for network compliance check in Phase 3 of the CloudCenter installation process. 

      The overall file structure will depend on factors like modes of various components, number of cloud regions, use of conditional/optional components and repos etc. Also, the region names used in the file should be unique, but do not need to match up with any cloud or datacenter names. These strings are merely used to perform network compliance checks and report results.

Sample JSON File

A sample Checker JSON file based on some common combination of CloudCenter component modes is provided below. Create a Checker JSON file that is specific to your environment and is similar to the following example.

{
    "CloudCenterComponents": {
        "CCM": {
            "CCM_IP": "CCM.Company1.com",
            "mode": "NON-HA "
        },
        "CloudRegions": [{
            "components": {
                "AMQP": {
                    "AMQP_IP": "AMQP.Company1.com",
                    "mode": "NON-HA"
                },
                "CCO": {
                    "CCO_IP": "CCO.Company1.com",
                    "mode": "NON-HA"
                }
            },
            "name": "OSEast"
        }],
        "REPOS": {
            "BUNDLE_STORE": "http://cdn.cliqr.com",
            "DOCKER_REGISTRY": "http://repo.cliqrtech.com:5000",
            "PACKAGE_STORE": "http://repo.cliqrtech.com"
        }
    }
}

Once you create the Checker JSON file, proceed to Prerequisite Checker JSON File to understand the file structure.

Back to:  Virtual Appliance Process

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