Viewing Cloud Resources

Let’s take a look at the various resources in your OpenStack private cloud from Cisco Metacloud.

Using the CLI and Credentials

As a cloud administrator, we figure you are comfortable with the command-line clients. We recommend using brew to install Python on Mac OSX, and then installing with pip within virtual environments to protect your system. Refer to Installing the OpenStack command line clients on Windows or Installing the OpenStack command line clients on Mac OSX for details.

The OpenStack Command Line Interface (CLI) is a common client that many services are moving towards. Here are some common commands to get you started to learn the shape of your cloud. These should help with troubleshooting with the Metacloud team also.

Your credentials are a combination of username, password, and project (previously named tenant). You can extract these values from the openrc.sh file downloaded from Project, Access & Security, API Access tab. Source those credentials in your environment before running these commands.

To look at your OpenStack service catalog:

$ openstack catalog list

You can see a list of the services installed, the type of service provided, and the endpoints including publicURL, internalURL, and adminURL. The long ID appended to some of the endpoints is the tenant ID.

Understanding Your Control Plane

As an administrator, you have a few ways to discover what your Metacloud cloud looks like by using the OpenStack tools available.

You can view basic statistics and listings for both compute hosts and the control plane servers using the CLI. Refer to Viewing Usage Statistics for Hosts and Instances for more information.

You can perform host-level network diagnostics using the Metacloud Dashboard to check the connectivity of a host and troubleshoot routing issues on the Live Stats page. The Live Stats page also provides controller and hypervisor information. See Performing Network Diagnostics and Viewing Statistics.

Viewing OpenStack Notifications

Metacloud can send OpenStack notifications using an rsyslog feed to your syslog server to monitor and report events in your environment. These notifications contain information about user-initiated requests or events that have taken place within your cloud. This feed does not include Host Operating System logs. To request configuration, open a request with Metacloud Support and provide your syslog server and port value. (Port 514 is the default value.)

Note Metacloud delivers the log stream via UDP and filters it. A portion of feed could be lost if there are problems with your syslog server or the connection to it.

Once configured, you see messages for oslo.messaging.notification with event type, timestamp, and which client initiated the call to a service.

<182>1 2017-01-28T18:10:04.409119+00:00
<MCP[N].[AZ.]METACLOUD.NET> keystone 57362 - -
_impl_log:notify:42 scmnr-4 req-776...5c3
INFO oslo.messaging.notification.identity.authenticate
{  
   "priority":"INFO",
   "event_type":"identity.authenticate",
   "timestamp":"2017-01-28 18:10:04.408908",
   "publisher_id":"<mcp[N].[AZ.]metacloud.net>",
   "payload":{  
      "typeURI":"http://schemas.dmtf.org/cloud/audit/1.0/event",
      "initiator":{  
         "typeURI":"service/security/account/user",
         "host":{  
            "agent":"python-keystoneclient",
            "address":"nnn.nn.nn.nn"
         },
         "id":"63b...9c9"
      },
      "target":{  
         "typeURI":"service/security/account/user",
         "id":"openstack:253...524"
      },
      "observer":{  
         "typeURI":"service/security",
         "id":"openstack:1ed...ca0"
      },
      "eventType":"activity",
      "eventTime":"2017-01-28T18:10:04.408197+0000",
      "action":"authenticate",
      "outcome":"success",
      "id":"openstack:3aa...fdf"
   },
   "message_id":"4eb...ca6"
}

Setting up the Identity Service

You can use the Identity service (Keystone) to see what users, roles, and projets are set up. You can also add projects, users, and roles with the OpenStack CLI.

The following commands require you to have your shell environment configured with the proper administrator variables:

Note
If you get an HTTP 401 error (The request you have made requires authentication) for CLI commands, make sure you are using admin credentials and that you have indicated the domain context for command using either the --domain or --user-domain parameters. When using the Identity v3 API on Metacloud 4.0 and later versions, you must indicate the domain context for the user.

$ openstack user list --domain <DOMAIN_NAME>
$ openstack project list
$ openstack role list

Determining Your Compute Capacity and Setup

By default, your cloud has a memory subscription ration of 1:6 cores. You can request to have that modified for your workloads by logging a support request.

You can inspect each host by name with a nova command, host-describe and the name of the host from the openstack service list command output.

$ nova host-describe <MHV[N].[AZ.]METACLOUD.NET>

 +-----------------------------+--------------+-----+-----------+---------+
 | HOST                        | PROJECT      | cpu | memory_mb | disk_gb |
 +-----------------------------+--------------+-----+-----------+---------+
 | <MHV[N].[AZ.]METACLOUD.NET> | (total)      | 48  | 257700    | 51339   |
 | <MHV[N].[AZ.]METACLOUD.NET> | (used_now)   | 54  | 112640    | 1080    |
 | <MHV[N].[AZ.]METACLOUD.NET> | (used_max)   | 54  | 110592    | 1080    |
 | <MHV[N].[AZ.]METACLOUD.NET> | ee61...f3af  | 8   | 16384     | 160     |
 | <MHV[N].[AZ.]METACLOUD.NET> | 9d14...af2c  | 8   | 16384     | 160     |
 | <MHV[N].[AZ.]METACLOUD.NET> | 5373...ac8c  | 4   | 8192      | 80      |
 | <MHV[N].[AZ.]METACLOUD.NET> | 6163...aefe  | 7   | 14336     | 140     |
 | <MHV[N].[AZ.]METACLOUD.NET> | 47a3...b1c7  | 7   | 14336     | 140     |
 | <MHV[N].[AZ.]METACLOUD.NET> | 045c...a33c  | 12  | 24576     | 240     |
 | <MHV[N].[AZ.]METACLOUD.NET> | 1774...e51d  | 2   | 4096      | 40      |
 | <MHV[N].[AZ.]METACLOUD.NET> | 7912...5e8f  | 6   | 12288     | 120     |
 +-----------------------------+--------------+-----+-----------+---------+

You also have detailed compute capacity reports coming to you each month. In addition, on your Dashboard you have drill-in information for each instance. Click Admin, Instances, and then click an instance name to see CPU utilization %, Disk read/write operations, and Network usage in MB/second.

Determining Storage Requirements

You can look at the volumes and storage controllers you have available with a cinder command and your administrator credentials sourced in your environment.

$ cinder service-list

    +------------------+--------------------------------+------+---------+-------+----------------------------+-----------------+
    | Binary           | Host                           | Zone | Status  | State | Updated_at                 | Disabled Reason |
    +------------------+--------------------------------+------+---------+-------+----------------------------+-----------------+
    | cinder-scheduler | <MHV[N].[AZ.]METACLOUD.NET>    | nova | enabled |   up  | 2016-05-05T13:54:12.000000 |   -             |
    | cinder-scheduler | <MHV[N].[AZ.]METACLOUD.NET>    | nova | enabled |   up  | 2016-05-05T13:54:14.000000 |   -             |
    | cinder-scheduler | <MHV[N].[AZ.]METACLOUD.NET>    | nova | enabled |   up  | 2016-05-05T13:54:12.000000 |   -             |
    |  cinder-volume   | <MHV[N].[AZ.]METACLOUD.NET>    | nova | enabled |   up  | 2016-05-05T13:54:19.000000 |   -             |
    +------------------+--------------------------------+------+---------+-------+----------------------------+-----------------+

In addition, your Dashboard has extra storage metrics available. Click Admin, Storage to see an Overview of total storage (GB), available (GB), raw used (GB), reported by hour, day, month, or year. You can also see graphs for read/write throughput, IOPS (op/sec), and Latency (ms). Your storage pools are also listed with the amount used and available.

Next, you can inspect the storage quotas for each project. Put the project name where Demos appears below. Remember that a -1 value indicates no quota limits on that resource.

$ project_id=$(openstack project show -f value -c id Demos)

$ cinder quota-defaults $project_id

 +----------------+-------+
 |    Property    | Value |
 +----------------+-------+
 |   gigabytes    |  1000 |
 | gigabytes_Ceph |   -1  |
 | gigabytes_NFS  |   -1  |
 |   snapshots    |   10  |
 | snapshots_Ceph |   -1  |
 | snapshots_NFS  |   -1  |
 |    volumes     |   10  |
 |  volumes_Ceph  |   -1  |
 |  volumes_NFS   |   -1  |
 +----------------+-------+

If the defaults have been changed, you can compare to the defaults with this command:

$ cinder quota-show $project_id

Note You cannot snapshot a volume with NFS.

Allocating Resources with Quotas

For each project, you choose the maximum limits, or quotas for the project as a whole. You want to set resource quotas so that you don’t allow a single user to exhaust system capacity for computing or storage resources. That said, some quotas can be set to unlimited, which is -1. To take a look at what’s currently set up, use the OpenStack CLI and the name of the project:

$ openstack quota show Demos

+--------------------+----------------------------------+
| Field              | Value                            |
+--------------------+----------------------------------+
| cores              | 20                               |
| fixed-ips          | -1                               |
| floating-ips       | 2                                |
| gigabytes          | 1000                             |
| gigabytes_Ceph     | -1                               |
| gigabytes_NFS      | -1                               |
| injected-file-size | 10240                            |
| injected-files     | 5                                |
| injected-path-size | 255                              |
| instances          | 10                               |
| key-pairs          | 100                              |
| network            | 5                                |
| port               | -1                               |
| project            | 7ed0a...6157                     |
| properties         | 128                              |
| ram                | 51200                            |
| router             | 2                                |
| secgroup-rules     | 20                               |
| secgroups          | 10                               |
| snapshots          | 10                               |
| snapshots_Ceph     | -1                               |
| snapshots_NFS      | -1                               |
| subnet             | 5                                |
| volumes            | 10                               |
| volumes_Ceph       | -1                               |
| volumes_NFS        | -1                               |
+--------------------+----------------------------------+

Each project has a default set of values for each quota. For workloads that need higher quotas, ensure users are in that project when they need higher allocations. You can modify those in the Dashboard, command line, or API, see Managing Projects.

Using Aggregates

Host aggregates are visible to administrators. You can assign key-value pairs to groups of hypervisors, and the scheduler uses the values to make scheduling decisions. You can define logical groups for migration, or enable advanced scheduling of which hosts launch which VM instances. One example would be providing a flavor that provides high I/O because of SSD storage, and then ensuring that users know they can launch on an aggregate where that flavor is present. Refer to Creating and Managing Host Aggregates for more information.

Providing Images

You have default images already available. You can modify those as needed.

Your cloud uses flavors to describe how much compute (CPU) power, memory available, and disk space allocation for launching instances. You want to ask yourself and your team, what flavors do we want to create? Your cloud comes with a predefined set of flavors, and you can add more or change them by deleting one flavor and adding another flavor.

You can assess your flavor requirements compared to the hardware you have by calculating:

  • How many virtual machines (VMs) you expect each hypervisor to run? Example: (overcommit fraction × cores) / virtual cores per instance
  • How much storage is required per VM? Example: flavor disk size × number of instances

Beyond the base images, find out what your users need. You can build Windows images for example, or prepare images from existing VMWare or AWS images. A fast way to bring over AWS images is to use CloudFormation templates.