openstack implementation guide - dell emc...networking openstack neutron manages logical networking...

VxRack™ System 1000 with NeutrinoVersion 1.1

OpenStack Implementation Guide302-003-041

03

Copyright © 2016 EMC Corporation All rights reserved.

Published November 2016

Dell believes the information in this publication is accurate as of its publication date. The information is subject to changewithout notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS-IS.“ DELL MAKES NO REPRESENTATIONS ORWARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLYDISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. USE,COPYING, AND DISTRIBUTION OF ANY DELL SOFTWARE DESCRIBED IN THIS PUBLICATION REQUIRES ANAPPLICABLE SOFTWARE LICENSE.

Dell, EMC, and other trademarks are trademarks of Dell Inc. or its subsidiaries. Other trademarks may be the property oftheir respective owners. Published in the USA.

EMC CorporationHopkinton, Massachusetts 01748-91031-508-435-1000 In North America 1-866-464-7381www.EMC.com

2 VxRack System 1000 with Neutrino 1.1 OpenStack Implementation Guide

5

Introduction 7About this guide........................................................................................... 8OpenStack projects supported by VxRack Neutrino.....................................8

Configure a client to run OpenStack CLI commands 11Configure a client to run OpenStack CLI commands................................... 12Create and source the project openrc.sh file...............................................12OpenStack CLI command examples............................................................ 14

OpenStack resource tasks performed by OpenStack scoped role15

Introduction to OpenStack scoped roles..................................................... 16Nova instances............................................................................................ 17Cinder volumes............................................................................................17Neutron networks....................................................................................... 18Neutron routers.......................................................................................... 18Glance images............................................................................................. 19Nova flavors................................................................................................19Compute quotas......................................................................................... 20Heat stacks................................................................................................ 20Ceilometer meters.......................................................................................21Swift containers and objects (for EMC ECS-attached object storage)....... 21

Configure thin provisioning 23Introduction to VxRack Neutrino volume provisioning types.......................24Ephemeral volumes.....................................................................................24Persistent volumes..................................................................................... 24

Configure a Heat Orchestration Template (HOT) 27Introduction to HOT templates...................................................................28Overview of a HOT template...................................................................... 28Create an Apache web server using a HOT template ................................. 29Autoscale instances from the OpenStack CLI.............................................33Manually scale instances............................................................................ 38

Call the Amazon Elastic Compute Cloud (EC2) API 41VxRack Neutrino compatibility with the Amazon EC2 API.......................... 42How to call the Amazon EC2 API ............................................................... 42

OpenStack best practices 45Check system defaults in the OpenStack Dashboard UI............................. 46Use caution when increasing the default CPU overcommit ratio from 2 .... 47Do not perform user management tasks in the OpenStack Dashboard UI... 47

Tables

Chapter 1

Chapter 2

Chapter 3

Chapter 4

Chapter 5

Chapter 6

Chapter 7

CONTENTS

VxRack System 1000 with Neutrino 1.1 OpenStack Implementation Guide 3

Select a default security group for instances..............................................48Do not modify default flavor attributes in the OpenStack Dashboard UI.....48Remove unused flavors from OpenStack....................................................48Modify default vCPU and RAM quotas before launching large instances withthe p3.8xlarge, e3.8xlarge, k3.8xlarge flavors............................................ 50

VxRack Neutrino OpenStack limitations 53OpenStack features that VxRack Neutrino does not support..................... 54Keystone v2 API allows access to only the Default domain.........................54Live instance migration will fail using the OpenStack Keystone v3 client....54Instances must be created in private network............................................ 55OpenStack Dashboard UI displays incorrect number of available vCPUs....55Cloud Administrator must set domain context to view users/groups inOpenStack ................................................................................................ 55Nova scheduling filter SimpleCIDRAffinityFilter does not work properly.... 56Instance creation fails when sourced from volume..................................... 56OpenStack Glance volume is provisioned from the first storage pool created...................................................................................................................56

Chapter 8

CONTENTS


VxRack Neutrino supported OpenStack Mitaka projects.............................................. 8OpenStack scoped roles..............................................................................................16Nova instance tasks performed by role in the OpenStack Dashboard UI and CLI.........17Cinder volume tasks performed by role in the OpenStack Dashboard UI and CLI........ 17Neutron network tasks performed by role in the OpenStack Dashboard UI and CLI.... 18Neutron router tasks performed by role in the OpenStack Dashboard UI and CLI....... 18Glance image tasks performed by role in the OpenStack Dashboard UI and CLI..........19Nova flavor tasks performed by role in the OpenStack Dashboard UI and CLI............ 19Quota tasks performed by role in the OpenStack Dashboard UI and CLI.................... 20Heat stack tasks performed by role in the OpenStack Dashboard UI and CLI............. 20Meter tasks performed by role in the OpenStack Dashboard UI and CLI..................... 21Overview of a template...............................................................................................28Valid Heat template versions...................................................................................... 29OpenStack standard system default quotas that cap the VxRack Neutrino defaultquotas with values of -1 ............................................................................................. 46Default OpenStack flavors..........................................................................................48OpenStack RAM and vCPU default quotas compared to three large flavor attributes...................................................................................................................................50OpenStack features not supported in VxRack Neutrino..............................................54

1234567891011121314

1516

17

TABLES

VxRack System 1000 with Neutrino 1.1 OpenStack Implementation Guide 5

TABLES


CHAPTER 1

Introduction

This chapter provides an overview of the content in this document and a list of theOpenStack Mitaka projects supported by VxRack Neutrino.

l About this guide................................................................................................... 8l OpenStack projects supported by VxRack Neutrino.............................................8

Introduction 7

About this guide

The content in this document is directed at users working in the OpenStackenvironment using the OpenStack Dashboard UI or the OpenStack command-lineclients. Users working in the OpenStack environment may or may not have access tothe VxRack™ System 1000 with Neutrino management UI. Users who have access toboth OpenStack and VxRack Neutrino UIs have:

l the admin role in the OpenStack Default domain; these users are VxRackNeutrino/OpenStack Cloud Administrators

l the admin role in any domain other than the Default domain; these users areVxRack Neutrino Account Administrators/OpenStack domain administrators

VxRack Neutrino provides the underlying compute, storage, and networkinfrastructure to host the virtual computing OpenStack environment. The OpenStackenvironment allows developers to create and manage large groups of virtual machines(instances) in a cloud computing environment. Users working in the OpenStackenvironment have admin or member roles in projects and perform cloud compute taskssuch as creating and managing instances (virtual machines), images, and volumes.

This guide focuses on:

l several tasks that are helpful to know when working in the OpenStack privatecloud, such as how to:

n configure a client to run OpenStack CLI commands

n configure thin-provisioned volumes

n configure a Heat Orchestration Template (HOT)

n call the Amazon Elastic Compute Cloud (EC2) API

l which tasks users with particular roles can perform on cloud resources

l best practices to use when working in the VxRack Neutrino OpenStack privatecloud

l VxRack Neutrino OpenStack limitations

This guide does not provide in-depth detail on all operations that can be performed inan OpenStack environment. For comprehensive information on OpenStack operations,refer to the OpenStack documentation set for the Mitaka release at http://docs.openstack.org/.

OpenStack projects supported by VxRack Neutrino

VxRack Neutrino supports the OpenStack projects listed in the following table.

Table 1 VxRack Neutrino supported OpenStack Mitaka projects

Service Project/Technology Description

Compute OpenStack Nova Manages OpenStack compute instances on demand. VxRackNeutrino uses the Linux KVM hypervisor technology to create virtualmachine instances.

Introduction


http://docs.openstack.org/

http://docs.openstack.org/

Table 1 VxRack Neutrino supported OpenStack Mitaka projects (continued)

Service Project/Technology Description

Identity management OpenStack Keystone Provides authentication and authorization within VxRack Neutrino aswell as a catalog of endpoints for OpenStack services. In VxRackNeutrino Keystone is used for all services.

Block storage OpenStack Cinder Manages persistent block storage used by OpenStack computeinstances. Cinder is automatically configured to use the EMC ScaleIOblock storage integrated into VxRack Neutrino.

Object storage EMC Elastic CloudStorage (ECS) withOpenStack Swift interface

Stores unstructured data objects via a RESTful, HTTP-based API.VxRack Neutrino provides integration with ECS storage to provideCinder backups and Keystone-authenticated object storage forOpenStack instances.

Image store OpenStack Glance Stores virtual machine images used as a template for OpenStackinstance provisioning. VxRack Neutrino stores images on ScaleIO.

Dashboard/user interface OpenStack Horizon A dashboard that provides developers a graphical interface tomanage OpenStack services.

Networking OpenStack Neutron Manages logical networking for OpenStack services. Neutron isconfigured to use the Open vSwitch with VXLAN.

Orchestration OpenStack Heat Provides application automation and auto scaling via heat templates.

Telemetry OpenStack Ceilometerand Aodh

Provides metering, usage reporting, and billing services.

EC2 API compatibility Ec2-Api Provides an EC2-compatible API for accessing OpenStack features.For additional information, refer to VxRack Neutrino compatibilitywith the Amazon EC2 API on page 42.

Introduction

OpenStack projects supported by VxRack Neutrino 9

Introduction


CHAPTER 2

Configure a client to run OpenStack CLIcommands

This chapter describes how to configure a client to run OpenStack command lineinterface (CLI) commands.

l Configure a client to run OpenStack CLI commands...........................................12l Create and source the project openrc.sh file...................................................... 12l OpenStack CLI command examples....................................................................14

Configure a client to run OpenStack CLI commands 11

Configure a client to run OpenStack CLI commands

In order to access VxRack Neutrino and run OpenStack command line interface (CLI)commands from a client, you must download the OpenStack clients and create a<projectname>-openrc.sh file. The <projectname>-openrc.sh is anenvironment file that sets the required environment variables for the OpenStackcommand-line clients. This project-specific environment file contains the credentialsthat all OpenStack services use. You must set the environment variables beforeOpenStack CLI commands can run. When you source the file, environment variablesare set for your current shell. The variables enable the OpenStack client commands tocommunicate with the OpenStack services that run in the cloud.

Environment variables specify parameters such as user name, domain, project, andhow to connect to the VxRack Neutrino system. Note that some of these parameterscan also be specified on the command line itself, in which case the environmentvariables are not needed. This appendix specifies the environment variables, but youcan specify them on the command line instead if you prefer.

There are two categories of OpenStack CLI commands:

l Domain-scoped commands - These commands are primarily related to Keystoneoperations and are not specific to a particular project. Examples are theendpoint list, user list, and project list commands. Thesecommands respectively list all the endpoints, users, and projects in an OpenStackdomain (which maps to a VxRack Neutrino account).

l Project-scoped commands - These commands apply to a project. Examples arevolume list (lists the volumes in the project) and server list (lists theinstances in the project),

Domain-scoped and project-scoped commands require different environment variablesas described in Create and source the project openrc.sh file on page 12.

Create and source the project openrc.sh file

Before you begin

You must download the OpenStack clients. For information on how to installOpenStack command-line clients, see http://docs.openstack.org/user-guide/common/cli_install_openstack_command_line_clients.html.

You may want to run the unset OS_<variable_name> command to clear out oldenvironment variables that you used in previous OpenStack sessions. This will clearyour environment before creating and sourcing the project openrc.ch file.

Procedure

1. In a text editor, create a file named <projectname>-openrc.sh file and addthe authentication information as shown in the following example where theproject is named project_emc, the user name is jdoe, the user password ismysecret, and the identity host is located at 10.0.0.11.

export OS_AUTH_URL=https://10.0.0.11:6100/v3export OS_IDENTITY_API_VERSION=3export OS_USERNAME=jdoeexport OS_PASSWORD=mysecretexport OS_USER_DOMAIN_NAME=emc



http://docs.openstack.org/user-guide/common/cli_install_openstack_command_line_clients.html

http://docs.openstack.org/user-guide/common/cli_install_openstack_command_line_clients.html

export OS_DOMAIN_NAME=emc

export OS_PROJECT_DOMAIN_NAME=emcexport OS_PROJECT_NAME=project_emc

2. On any shell from which you want to run OpenStack commands, source the<projectname>-openrc.sh file for the respective project. In this example,you source the project_emc-openrc.sh file for the project_emc project:

$ source project_emc-openrc.sh

3. Map the user to the environment variable depending on whether the commandis project-scoped or domain-scoped.

Commandscope

User's environment variable

Domain-scoped

Cloud Administrators must set the domain(OS_USER_DOMAIN_NAME, OS_DOMAIN_NAME) as defaultinstead of emc.

Account Administrators, Project Administrators, and projectmembers must set the domain to the account name instead ofemc

Project-scoped

Cloud Administrators must set the domain(OS_USER_DOMAIN_NAME, OS_PROJECT_DOMAIN_NAME) asdefault instead of emc.

Account Administrators, Project Administrators, and projectmembers must set the domain to the account name instead ofemc.

Project members must set OS_PROJECT_NAME to the name ofthe project.

4. Depending on whether the command is project-scoped or domain-scoped,uncomment/comment out the appropriate variables, as described in thefollowing list.

l For domain-scoped commands, uncomment the OS_DOMAIN_NAME variableand comment out the OS_PROJECT_DOMAIN_NAME andOS_PROJECT_NAME variables.

l For project-scoped commands, comment out the OS_DOMAIN_NAMEvariable and set the OS_PROJECT_DOMAIN_NAME and OS_PROJECT_NAMEvariables. An example follows.

export OS_AUTH_URL=https://10.0.0.11:6100/v3export OS_IDENTITY_API_VERSION=3export OS_USERNAME=jdoeexport OS_PASSWORD=mysecretexport OS_USER_DOMAIN_NAME=emc

#export OS_DOMAIN_NAME=emc


Create and source the project openrc.sh file 13

export OS_PROJECT_DOMAIN_NAME=emcexport OS_PROJECT_NAME=project_emc

OpenStack CLI command examples

After you have set the environment variables in the <projectname>-openrc.shfile, you can run OpenStack CLI commands. The following examples show the domain-scoped user list and project list commands, and the project-scoped serverlist command.

usxxdoej1m1:os doej1$ openstack --insecure user list --domain 73ca4e95fe4e4f51996ceb59720c4ae2Password: +----------------------------------+---------+| ID | Name |+----------------------------------+---------+| 8c38c05bb2f24286b17fae1645cff0df | jdoe || fdda966798834a84aeca010825fd8afd | djones |+----------------------------------+---------+

usxxdoej1m1:os doej1$ openstack --insecure project list --domain 73ca4e95fe4e4f51996ceb59720c4ae2Password: +----------------------------------+-------------+| ID | Name |+----------------------------------+-------------+| 0e7e130fb18f4932ba0193ef0f5b70bd | project_emc |+----------------------------------+——————+

usxxdoej1m1:os doej1$ openstack --insecure server listPassword: +--------------------------------------+------+--------+------------------------------+| ID | Name | Status | Networks |+--------------------------------------+------+--------+------------------------------+| eb18c857-30d8-4ad3-8713-c87ac2aae970 | test | ACTIVE | default_network=102.41.294.6 |+--------------------------------------+------+--------+------------------------------+



CHAPTER 3

OpenStack resource tasks performed byOpenStack scoped role

This chapter provides the OpenStack resource tasks that users with the OpenStackCloud Administrator, Project Administrator, and Project Member roles can complete inthe OpenStack Dashboard UI and CLI.

l Introduction to OpenStack scoped roles.............................................................16l Nova instances................................................................................................... 17l Cinder volumes................................................................................................... 17l Neutron networks...............................................................................................18l Neutron routers.................................................................................................. 18l Glance images.................................................................................................... 19l Nova flavors....................................................................................................... 19l Compute quotas.................................................................................................20l Heat stacks........................................................................................................20l Ceilometer meters.............................................................................................. 21l Swift containers and objects (for EMC ECS-attached object storage)...............21

OpenStack resource tasks performed by OpenStack scoped role 15

Introduction to OpenStack scoped rolesOpenStack users' scoped roles are defined by their scope and role. The VxRackNeutrino OpenStack implementation has two scopes: the Default domain/account(Cloud) and project. The user roles could be admin, openstack_admin, or _member_.

The three typical OpenStack scoped roles are:

l Cloud Administrator - has both the admin and openstack_admin roles in the adminproject in the Default domain/account

l Project Administrator - has the admin role in a project (may or may not haveopenstack_admin role as well)

l Project member - has the _member_ role in a project

Table 2 OpenStack scoped roles

Domainscope

Projectscope

Role OpenStackscoped role

Notes

Default admin admin andopenstack_admin

CloudAdministrator

Can see all the projects in the system and can see/manage the resources (volumes, instances, snapshots,networks) within all the projects.

any domain any project(other thanadminproject)

admin ProjectAdministrator

Can see and manage the resources within their ownproject.

Can see all the projects in the Identity > Projectspage of the OpenStack Dashboard UI, but cannot seethe resources within the other projects, that is, cannotview the instances and volumes of projects other than

their own in the Admin tab of the OpenStackDashboard UI.

any domain any project(other thanadminproject)

admin andopenstack_admin

ProjectAdministrator/OpenStackAdministrator

Can see and manage the resources within his/her ownproject.Can see all the projects in the OpenStack Dashboard UI,and can see/manage the resources within all projects inthe system.

any domain any project _member_ Project Member Can see and manage the resources within his/her ownproject.Can only see his/her own project in the OpenStackDashboard UI.

The tables in the following sections summarize the tasks for each OpenStack resourcethat can be completed in the OpenStack Dashboard UI and CLI by users having theOpenStack Cloud Administrator, Project Administrator, and Project Member roles. It isassumed that the Cloud Administrator has both the admin and openstack_adminproject-level roles assigned in order to perform the tasks listed in the tables.

OpenStack resource tasks performed by OpenStack scoped role


Nova instances

Table 3 Nova instance tasks performed by role in the OpenStack Dashboard UI and CLI

OpenStack Dashboard UI OpenStack CLI

Create List Change Delete Create List Change Delete

CloudAdmin

Yes All instancesin thesystem

All instancesin thesystem





ProjectAdmin

Yes Instancescreated bythis user

Instancescreated bythis user



Instances inthis project


ProjectMember

Yes Instancescreated bythis user



Yes Instances inthis project



Note

From the OpenStack CLI:

Project Admin: If you add --all-tenants (or --all-projects, based on theOpenStack client version) you can see all the instances in the system.

Project Member: If you add --all-tenants, you can see all the instances in theproject.

Cinder volumes

Table 4 Cinder volume tasks performed by role in the OpenStack Dashboard UI and CLI



CloudAdmin

Yes All volumesin thesystem

All volumesin thesystem


Yes All volumesin thesystem



ProjectAdmin

Yes All volumesin theproject

All volumesin theproject





ProjectMember








Nova instances 17

Neutron networks

Table 5 Neutron network tasks performed by role in the OpenStack Dashboard UI and CLI



CloudAdmin

Yes All networksin thesystem

All networksin thesystem


Yes All networksin thesystem



ProjectAdmin

Yes All networksin thisproject andthe sharednetwork

All networksin thisproject andthe sharednetwork


Yes All networksin thisproject andthe sharednetwork



ProjectMember

No All networksin thisproject andthe sharednetwork

No No No All networksin theproject andthe sharednetwork

No No

Note

You can only delete a network when there are no instances in that network; otherwisethe deletion will fail.

Neutron routers

Table 6 Neutron router tasks performed by role in the OpenStack Dashboard UI and CLI



CloudAdmin

Yes All routersin thesystem

All routersin thesystem


Yes All routersin thesystem



ProjectAdmin

Yes All routersin thisproject

All routersin thisproject


Yes All routersin thisproject



ProjectMember

No All routersin thisproject

No No No All routersin thisproject

Yes Yes



Glance images

Table 7 Glance image tasks performed by role in the OpenStack Dashboard UI and CLI



CloudAdmin

Yes All images inthe system

All images inthe system

Non-protectedimages inthe system




ProjectAdmin







ProjectMember

Yes Publicimages orimages inthis project

Publicimages orimages inthis project

Publicimages orimages inthis project

Yes Publicimages orimages inthis project

Yes Yes

Note

If you set a Glance image to be public, everyone in the system can see that image. Ifyou set the image as protected, no one but the owner can delete that image.

Nova flavors

Table 8 Nova flavor tasks performed by role in the OpenStack Dashboard UI and CLI



CloudAdmin

Yes All theflavors inthe system

All theflavors inthe system


Yes All theflavors inthe system



ProjectAdmin

No All theflavors inthe system

No No No All theflavors inthe system

No No

ProjectMember

No Flavorsshared tothis project

No No No Flavorsshared tothis project

No No


Glance images 19

Note

From the OpenStack Dashboard UI:

Cloud Admin: Can create, update, and delete all the flavors in the system.

Project Admin: Can see all the flavors from the Admin tab in the OpenStackDashboard UI. Can only use the flavors that belong to their project.

Project Member: Can only use the flavors that belong to their project.

Compute quotas

Table 9 Quota tasks performed by role in the OpenStack Dashboard UI and CLI



CloudAdmin

N/A Defaultquota andProjectquota

Defaultquota andProjectquota

N/A N/A Defaultquota andProjectquota


N/A

ProjectAdmin

N/A Defaultquota

No N/A N/A Defaultquota andProjectquota


N/A

ProjectMember

N/A No No N/A N/A No No N/A

Note

Cloud Admin: Can change both the default quotas and the quotas for a specificproject.

Project Admin: Can see the default quotas in the OpenStack Dashboard UI.

Heat stacks

Table 10 Heat stack tasks performed by role in the OpenStack Dashboard UI and CLI



CloudAdmin

Yes Stacks inthis project

Stacks inthis project


Yes All stacks inthe system



ProjectAdmin







ProjectMember









Table 10 Heat stack tasks performed by role in the OpenStack Dashboard UI andCLI (continued)

Note

All users must have the heat_stack_owner role added to perform any stack actions.

Cloud Admin: Can't modify or delete stacks outside of their project. There is anOpenStack bug tracking this: https://bugs.launchpad.net/heat/+bug/1466694.

Ceilometer meters

Table 11 Meter tasks performed by role in the OpenStack Dashboard UI and CLI



CloudAdmin

N/A All meters inthe system

No No Yes All meters inthe system

All meters inthe system

All meters inthe system

ProjectAdmin

N/A Meterscreated bythis user

No No Yes All meters inthe system

Meters inthis project


ProjectMember

N/A Meterscreated bythis user

No No Yes Meters inthis project



Swift containers and objects (for EMC ECS-attached objectstorage)

Swift Container API Swift Object API


CloudAdmin

N/A N/A N/A N/A N/A N/A N/A N/A

ProjectAdmin

Yes Yes Yes Yes Yes Yes Yes Yes

ProjectMember

No No No No Per ACL Per ACL Per ACL Per ACL


Ceilometer meters 21

https://bugs.launchpad.net/heat/+bug/1466694

Note

Access Control Lists (ACLs) must be created using the Swift API.

An ACL is created on the EMC Elastic Cloud Storage (ECS) system and associatedwith an OpenStack Project Member or an OpenStack project-scoped admin or_member_ role.



CHAPTER 4

Configure thin provisioning

This chapter describes how you can configure volumes to be thin-provisioned insteadof thick-provisioned in the OpenStack Dashboard UI.

l Introduction to VxRack Neutrino volume provisioning types.............................. 24l Ephemeral volumes............................................................................................ 24l Persistent volumes.............................................................................................24

Configure thin provisioning 23

Introduction to VxRack Neutrino volume provisioning types

In the VxRack Neutrino OpenStack cloud, volumes are thick-provisioned by default.This includes the ephemeral volumes used by instances, as well as the persistentvolumes attached to instances. With thick provisioning, space is pre-allocated when avolume is created. With thin provisioning, space is only consumed when data is writtento a volume. 1 MiB is the minimum size of a thin-provisioned volume.

In the OpenStack Dashboard UI, you can configure thin-provisioned storage. You canuse thin-provisioned storage to improve performance when launching multipleinstances with flavors that use capacity (HDD) storage. Launching multiple instancesthat use thick-provisioned capacity storage may take some time. For this reason, ifyou plan to launch large amounts of instances at once using capacity storage, you maywant to consider using thin provisioning.

Ephemeral volumes

To configure thin provisioning for the ephemeral volumes (root disk and ephemeraldisk) used by a particular instance, you must update the metadata of the instance'sflavor.

Procedure

1. In the OpenStack Dashboard UI, on the System tab, click the Flavors category.

2. On the Flavors page, select the instance's flavor from the list of flavors.

3. In the Actions column next to the instance's flavor, click the downward-facingarrow in the drop-down list and select Update Metadata.

4. On the Update Flavor Metadata page, in the Custom field in the AvailableMetadata box, type provisioning_type and click the blue plus sign.

provisioning_type is now added as a field in the Existing Metadata box.

5. In the Existing Metadata box, in the provisioning_type field, typethinprovisioned.

6. Click Save.

All instances that use the selected flavor and all instances created with thisflavor will now have thin-provisioned ephemeral volumes.

Persistent volumes

To configure thin provisioning for persistent (Cinder) volumes, you must create a newthin-provisioned volume type.

Procedure

1. In the OpenStack Dashboard UI, on the System tab, click the Volume category.

2. On the Volumes page, click the Volume Types tab.

3. On the Volume Types page, select the volume/storage type in which you wantto configure the thin provisioning (for example, Capacity).

4. In the Actions column next to the volume type, click the downward-facingarrow in the drop-down list and select View Extra Specs.



5. On the Volume Type Extra Specs page, click the Create button.

6. On the Create Volume Type Extra Spec page, .

l In the Key field, type sio:provisioning_type.

l In the Value field, type thinprovisioned.

7. Click Create.

You may now create volumes using this thin-provisioned volume type andattach thin-provisioned volumes to instances.


Persistent volumes 25

CHAPTER 5

Configure a Heat Orchestration Template(HOT)

This chapter provides a quick-start reference on how to configure HOT templates torun a web server and to autoscale instances.

l Introduction to HOT templates.......................................................................... 28l Overview of a HOT template..............................................................................28l Create an Apache web server using a HOT template .........................................29l Autoscale instances from the OpenStack CLI.................................................... 33l Manually scale instances.................................................................................... 38

Configure a Heat Orchestration Template (HOT) 27

Introduction to HOT templates

Heat is an OpenStack service that orchestrates multiple composite cloud applicationsusing templates, through a native OpenStack REST API. Heat templates (referred toas HOT templates) enable you to create most OpenStack resource types and providemore advanced functionality, such as instance autoscaling and nested stacks. A HOTtemplate describes the infrastructure for a cloud application in a text file that can betreated like code. Heat has the concept of a stack which is simply the environmentitself.

HOT templates make use of Cloud-Init for a very powerful way of deploying clouds.Cloud-init is a package bundled with many images which handles the early initializationof a cloud instance. This chapter provides a quick-start overview of how to start up aweb server using an example HOT template that includes networking and cloud-initresource types. For more information on HOT templates, refer to the OpenStackTemplate Guide and OpenStack resource types.

Overview of a HOT template

HOT templates are defined in YAML and follow the structure outlined in the followingtable.

Table 12 Overview of a template

Component Description

description: > An apache2 "Hello World" using the existing Neutron network. Specify network and subnet IDs in the parameters.

A description of the template. Optional. A pipe | following the

description mapping indicates that newlines are convertedinto literal newline escape sequences. This preserves theindentation, and is ideal for code. The > character indicates

that newlines are folded into spaces. This is ideal for human-readable text, such as this description.

heat_template_version: 2015-04-30 Template version header. Required.

outputs: apache_private_ip: value: {get_attr: [apache, first_address]} apache_public_ip: value: {get_attr: [apache_floating_ip, floating_ip_address]}

This is where you would place output URLs after the stackcompletes. Optional.

parameters: flavor: type: string default: v4.medium image: type: string default: ubuntu network: type: string default: test-net password:

Create parameter mappings for properties that will be usedfrequently by resources. Optional, but highly recommended.

Configure a Heat Orchestration Template (HOT)


http://docs.openstack.org/developer/heat/template_guide/

http://docs.openstack.org/developer/heat/template_guide/

http://docs.openstack.org/developer/heat/template_guide/openstack.html

http://www.yaml.org/spec/1.2/spec.html

Table 12 Overview of a template (continued)

Component Description

type: string default: pass

resources: vm1: type: OS::Nova::Server properties: image: {get_param: image} flavor: {get_param: flavor} key_name: {get_param: key_name} networks: - port: {get_resource: neutron_port} user_data: {get_resource: cloud_init_resource} user_data_format: RAW

Resources map to actual OpenStack operations. Required.

Valid template versionsVxRack Neutrino currently uses the Mitaka release of Heat, and is backwardscompatible with older versions, as shown in the following table.

Table 13 Valid Heat template versions

heat_template_version OpenStack release

2013-05-23 Icehouse

2014-10-16 Juno

2015-04-30 Kilo

2015-10-15 Liberty

2016-04-08 Mitaka

Create an Apache web server using a HOT templateThis section describes how to construct a basic HOT template to run an Apache 2 webserver.

Procedure

1. Place the header in the first line.

heat_template_version: 2015-04-302. Use input parameters for commonly-used for allowing the template to be more

reusable. Obtain the required public and private network/subnet IDs fromhttps://<VxRack_Neutrino_VIP>/horizon/project/networks/ orneutron --insecure net-list

parameters: key_name: type: string description: Name of a keypair to enable SSH access to the instance


Create an Apache web server using a HOT template 29

default: key flavor: type: string description: Flavor type forApache2 webserver default: v4.medium image: type: string description: > http://docs.openstack.org/image-guide/obtain-images.html http://uec-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-disk1.img default: ubuntu network: type: string default: test-net description: Private network public_network_id: type: string description: ID of the publicnetwork forfloating IP default: 6e4106fa-3a29-48eb-9d32-fb15aaaaf950 private_network_id: type: string description: Private network ID default: f45eaf0a-8954-4d53-99d1-e3e735fb990e private_subnet_id: type: string description: Private sub network ID default: c80faaf5-8701-4351-8008-1cc847eb1a0a password: type: string default: pass description: Password forinstance. Username is 'ubuntu'

3. Create an instance, a port for network access, a floating IP, and a securitygroup. This example grants SSH and internet access to the instance.

apache: type: OS::Nova::Server properties: image: {get_param: image} flavor: {get_param: flavor} key_name: {get_param: key_name} networks: - port: {get_resource: apache_port} user_data: {get_resource: init_apache} user_data_format: RAWapache_port: type: OS::Neutron::Port properties: network_id: {get_param: private_network_id} fixed_ips: - subnet_id: { get_param: private_subnet_id } security_groups: [{get_resource: apache_security_group}] apache_floating_ip: type: OS::Neutron::FloatingIP properties: floating_network_id: {get_param: public_network_id} port_id: {get_resource: apache_port} apache_security_group: type: OS::Neutron::SecurityGroup properties: description: Add security group rules forserver name: security-group rules: - protocol: icmp - protocol: tcp



remote_ip_prefix: 0.0.0.0/0 port_range_min: 22 port_range_max: 22 - protocol: tcp remote_ip_prefix: 0.0.0.0/0 port_range_min: 80 port_range_max: 80

4. Use the multi-part mime resource type to break down the boot order intoreusable chunks.

cloudinit: type: OS::Heat::CloudConfig properties: cloud_config: password: {get_param: password} chpasswd: {expire: False} ssh_pwauth: Trueinstall_apache: type: OS::Heat::CloudConfig properties: cloud_config: packages: - apache2 - libapache2-mod-wsgiinit_apache: type: OS::Heat::MultipartMime properties: parts: - config: {get_resource: cloudinit} - config: {get_resource: install_apache}

5. Outputs

outputs: apache_private_ip: value: {get_attr: [apache, first_address]} apache_public_ip: value: {get_attr: [apache_floating_ip, floating_ip_address]}

6. Build the stack.

unset ${!OS_*}export OS_USERNAME=cpsaexport OS_PASSWORD=$(python -meci_python_libs.ks_password cpsa)export OS_AUTH_URL=$(python -meci_python_libs.tools.get_keystone_private_endpoint_url)/v3export OS_IDENTITY_API_VERSION=3export OS_USER_DOMAIN_NAME=defaultexport OS_PROJECT_DOMAIN_NAME=defaultexport OS_PROJECT_NAME=adminheat --insecure stack-create -f template.yaml stack1

7. Check that the Apache server is up and running.

$ curl <apache_public_ip> | grep 'It works!' % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed It works!1001151010011510001240k 0--:--:-- --:--:-- --:--:-- 1405k

Or from a web browser, enter the floating IP address.


Create an Apache web server using a HOT template 31

Results

The final template looks like this:

Apache Web Server

heat_template_version: 2015-04-30description: > An apache2 "Hello World" using the existing Neutron network. Specify network and subnet IDs in the parameters.parameters: key_name: type: string description: Name of a keypair to enable SSH access to the instance default: key flavor: type: string description: Flavor type for Apache2 webserver default: v4.medium image: type: string description: > http://docs.openstack.org/image-guide/obtain-images.html http://uec-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-disk1.img default: ubuntu network: type: string default: test-net description: Private network public_network_id: type: string description: ID of the public network for floating IP default: 6e4106fa-3a29-48eb-9d32-fb15aaaaf950 private_network_id: type: string description: Private network ID default: f45eaf0a-8954-4d53-99d1-e3e735fb990e private_subnet_id: type: string description: Private sub network ID default: c80faaf5-8701-4351-8008-1cc847eb1a0a password: type: string default: pass description: Password for instance. Username is 'ubuntu'resources: cloudinit: type: OS::Heat::CloudConfig properties: cloud_config: password: {get_param: password} chpasswd: {expire: False} ssh_pwauth: True install_apache: type: OS::Heat::CloudConfig properties: cloud_config: packages: - apache2 - libapache2-mod-wsgi init_apache: type: OS::Heat::MultipartMime properties: parts: - config: {get_resource: cloudinit}



- config: {get_resource: install_apache} apache: type: OS::Nova::Server properties: image: {get_param: image} flavor: {get_param: flavor} key_name: {get_param: key_name} networks: - port: {get_resource: apache_port} user_data: {get_resource: init_apache} user_data_format: RAW apache_port: type: OS::Neutron::Port properties: network_id: {get_param: private_network_id} fixed_ips: - subnet_id: { get_param: private_subnet_id } security_groups: [{get_resource: apache_security_group}] apache_floating_ip: type: OS::Neutron::FloatingIP properties: floating_network_id: {get_param: public_network_id} port_id: {get_resource: apache_port} apache_security_group: type: OS::Neutron::SecurityGroup properties: description: Add security group rules for server name: security-group rules: - protocol: icmp - protocol: tcp remote_ip_prefix: 0.0.0.0/0 port_range_min: 22 port_range_max: 22 - protocol: tcp remote_ip_prefix: 0.0.0.0/0 port_range_min: 80 port_range_max: 80 outputs: apache_private_ip: value: {get_attr: [apache, first_address]} apache_public_ip: value: {get_attr: [apache_floating_ip, floating_ip_address]}

Autoscale instances from the OpenStack CLI

This section provides a reference for launching an autoscaling cloud orchestrationstack using the OpenStack CLI. The Heat stack template describes the logic for how aHeat stack will be built and managed. This is where you can create an auto scalinggroup and configure Ceilometer thresholds.

Procedure

1. Set credentials.

unset ${!OS_*}export OS_USERNAME=cpsaexport OS_PASSWORD=$(python -meci_python_libs.ks_password cpsa)export OS_AUTH_URL=$(python -meci_python_libs.tools.get_keystone_private_endpoint_url)/v3


Autoscale instances from the OpenStack CLI 33

export OS_IDENTITY_API_VERSION=3export OS_USER_DOMAIN_NAME=defaultexport OS_PROJECT_DOMAIN_NAME=defaultexport OS_PROJECT_NAME=admin

2. Make sure that there is a Neutron network present.

3. Obtain an image and add it to Glance.

In this example, we will use Fedora Cloud. Select the Base Cloud Image inQCOW2 format.

wget https://download.fedoraproject.org/pub/fedora/linux/releases/22/Cloud/x86_64/Images/Fedora-Cloud-Base-22-20150521.x86_64.qcow2

openstack --insecure --os-project-name admin image create --file Fedora-Cloud-Base-22-20150521.x86_64.qcow2 --disk-format qcow2 --container-format bare --public fedora

4. Add or create a Nova Keypair.

ssh-keygen -t rsa -f key -N 12345

openstack --insecure keypair create test_kp_heat --public-key key.pub

5. Use the following template. The parameter defaults can be changed to suit yourexisting network, images, and so forth. Using the m1.medium flavor for theFedora image is recommended.

Use caution when modifying Ceilometer alarm timings. TheOS::Ceilometer::Alarm period property describes the acquisition rate (inseconds) of the CPU usage meter data. For best performance, it is best to leavethe evaluation period at the default settings.

heat_template_version: 2013-05-23description: AutoScaling Testparameters: image: type: string description: Image used for servers default: fedora key: type: string description: SSH key to connect to the servers default: key flavor: type: string description: flavor used by the servers default: v4.medium network: type: string description: network in which to launch server default: test-netresources:



http://docs.openstack.org/image-guide/content/ch_obtaining_images.html

https://getfedora.org/en/cloud/download/

server_scaleup_policy: type: OS::Heat::ScalingPolicy properties: adjustment_type: change_in_capacity auto_scaling_group_id: {get_resource: server_group} cooldown: 60 scaling_adjustment: 1 server_scaledown_policy: type: OS::Heat::ScalingPolicy properties: adjustment_type: change_in_capacity auto_scaling_group_id: {get_resource: server_group} cooldown: 60 scaling_adjustment: -1 cpu_alarm_high: type: OS::Ceilometer::Alarm properties: description: Scale-up if the average CPU > 50% for 600 seconds meter_name: cpu_util statistic: avg period: 600 evaluation_periods: 1 threshold: 50 alarm_actions: - {get_attr: [server_scaleup_policy, alarm_url]} matching_metadata: {'metadata.user_metadata.stack': {get_param: "OS::stack_id"}} comparison_operator: gt cpu_alarm_low: type: OS::Ceilometer::Alarm properties: description: Scale-down if the average CPU < 15% for 600 seconds meter_name: cpu_util statistic: avg period: 600 evaluation_periods: 1 threshold: 15 alarm_actions: - {get_attr: [server_scaledown_policy, alarm_url]} matching_metadata: {'metadata.user_metadata.stack': {get_param: "OS::stack_id"}} comparison_operator: lt server_group: type: OS::Heat::AutoScalingGroup properties: min_size: 1 max_size: 10 resource: type: OS::Nova::Server properties: flavor: {get_param: flavor} image: {get_param: image} key_name: {get_param: key} networks: - network: {get_param: network} metadata: {"metering.stack": {get_param: "OS::stack_id"}} user_data: | #cloud-config password: pass chpasswd: {expire: False} ssh_pwauth: True user_data_format: RAWoutputs: scale_up_url: description: > This URL is the webhook to scale up the autoscaling group. You can invoke the scale-up operation by doing an HTTP POST to this URL; no body nor extra headers are needed. value: {get_attr: [server_scaleup_policy, alarm_url]} scale_dn_url: description: >



This URL is the webhook to scale down the autoscaling group. You can invoke the scale-down operation by doing an HTTP POST to this URL; no body nor extra headers are needed. value: {get_attr: [server_scaledown_policy, alarm_url]} ceilometer_query: value: str_replace: template: > ceilometer statistics -m cpu_util -q metadata.user_metadata.stack=stackval -p 600 -a avg params: stackval: {get_param: "OS::stack_id"} description: > This is a Ceilometer query for statistics on the cpu_util meter Samples about OS::Nova::Server instances in this stack. The -q parameter selects Samples according to the subject's metadata. When a VM's metadata includes an item of the form metering.X=Y, the corresponding Ceilometer resource has a metadata item of the form user_metadata.X=Y and samples about resources so tagged can be queried with a Ceilometer query term of the form metadata.user_metadata.X=Y.

6. Create the stack.

heat --insecure stack-create stack1 -f autoscaling.yml

Property Value

capabilities []creation_time 2015-07-14T21:19:53Zdescription AutoScaling Testdisable_rollback Trueid 86010d60-7940-4120-b931-d498c084c223links http://10.242.27.76:8004/v1/d42d86a0968a489c8c28f99eef2b0ff2/stacks/

stack1/86010d60-7940-4120-b931-d498c084c223 (self)notification_topics []outputs

[ { "output_value": "ceilometer statistics -m cpu_util -q metadata.user_metadata.stack=86010d60- 7940-4120-b931-d498c084c223 -p 600 -a avg\n", "description": "This is a Ceilometer query for statistics on the cpu_util meter Samples about OS::Nova::Server instances in this stack.The -q parameter selects Samples according to the subject's metadata. When a VM's metadata includes an item of the form metering.X=Y, the corresponding Ceilometer resource has a metadata item of the form user_metadata.X=Y and samples about resources so tagged can be queried with a Ceilometer query term of the form metadata.user_metadata.X=Y.\n", "output_key": "ceilometer_query"

}, { "output_value": "http://10.242.27.76:8000/v1/signal/arn%3Aopenstack%3Aheat%3A%3Ad42d86a0968a489c8c 28f99eef2b0ff2%3Astacks%2Fstack1%2F86010d60-79404120-b931-d498c084c223%2Fresources%2Fserver_ scaledown_policy?Timestamp=2015-07-4T21%3A20%15Z&SignatureMethod=HmacSHA256&AWSAccessKeyId=2290b c602c20470a8579567fdcd64ba2&SignatureVersion=2&Signature=npL86SIfTvcI%



"description": "This URL is the webhook to scale down the autoscaling group. You can invoke the scale-down operation by doing an HTTP POST to this URL; no body nor extra headers are needed.\n" "output_key": "scale_dn_url"

}, { "output_value": "http://10.242.27.76:8000/v1/signal/arn%3Aopenstack%3Aheat%3A%3Ad42d86a0968a489 c8c28f99eef2b0ff2%3Astacks%2Fstack1%2F86010d60-7940-4120-b931-d498c084c223%2Fresources%2Fserver_ scaleup_policy?Timestamp=2015-07-14T21%3A20%3A16Z&SignatureMethod=HmacSHA256&AWSAccessKeyId= 9ae03345d3d64f4093dfac156c2608a9&SignatureVersion=2&Signature=Y0h59LTtZXJLycAXBB6RyMG5PwLZQQug%2 Fo0CtC0Qz0I%3D", "description": "This URL is the webhook to scale up the autoscaling group. You can invoke the scale-up operation by doing an HTTP POST to this URL; no body nor extra headers are needed.\n","description": "This URL is the webhook to scale up the autoscaling group. You can invoke the scale-up operation by doing an HTTP POST to this URL; no body nor extra headers are needed.\n", "output_key": "scale_up_url”

parameters] { "network": "test-net", "OS::stack_id": "86010d60-7940-4120-b931-d498c084c223", "OS::stack_name": "stack1", "image": "fedora", "key": "test_kp_heat", "flavor": "m1.medium" }

parent Nonestack_name stack1stack_owner adminstack_status CREATE_COMPLETEstack_status_reason Stack CREATE completed successfullytemplate_description AutoScaling Testtimeout_mins Noneupdated_time None

7. To autoscale, you must meet the condition of sustaining greater than 50percent CPU usage inside the instance for 10 minutes, as described in thetemplate.

a. Log in to the newly-created instance. Username is fedora, password ispass.

b. Stress the CPU.

for i in 1 2 3 4; do while : ; do : ; done & done

8. View existing Ceilometer alarms and meter statistics.

Alarm may exist in either of three states:



l insufficient data - alarm may need more time to formulate an average fromthe cpu_util meter, or alarm is non-functional

l ok

l alarm

After the initial 10 minute evaluation window, new instances will be created, at arate constrained by the cooldown period (in seconds) described in theOS::Heat::ScalingPolicy section.

9. View polling data for the cpu_util meter by running the Ceilometer statisticscommand generated by the stack template. See the stack overview page in theOpenStack Dashboard UI, or run heat --os-project-domain-name default--os-user-domain-name default stack-show <stack>.

10. To autoscale down, kill the stress processes. Allow another polling period topass until the instances begin to be deleted.

Manually scale instances

Procedure

1. Send a POST request to the output URL to manually scale. It may take up to 15seconds for the instance to launch or complete deletion.

# curl -X POST -i "http://10.242.27.76:8000/v1/signal/arn%3Aopenstack%3Aheat%3A%3Ad42d86a0968a489c8c28f99eef2b0ff2%3Astacks%2Fstack1%2F604ab5e7-0f0d-4270-bba5-e13426a81ad0%2Fresources%2Fserver_scaleup_policy?Timestamp=2015-07-14T17%3A19%3A08Z&SignatureMethod=HmacSHA256&AWSAccessKeyId=553999ad78df4898895f42df1617f97f&SignatureVersion=2&Signature=ZySxT9u6kQs8LVh4N7Jyk%2FWdQXISJYw9zCVmGbzmKxc%3D"

HTTP/1.1 200 OK

Content-Type: text/html; charset=UTF-8

Content-Length: 0

Date: Tue, 14 Jul 2015 17:43:20 GMT



Clicking on the webhook URL will not work, as web browsers interpret a click asa GET request, and this will result in an error message:

# curl -X GET -i "http://10.242.27.76:8000/v1/signal/arn%3Aopenstack%3Aheat%3A%3Ad42d86a0968a489c8c28f99eef2b0ff2%3Astacks%2Fstack1%2F604ab5e7-0f0d-4270-bba5-e13426a81ad0%2Fresources%2Fserver_scaleup_policy?Timestamp=2015-07-14T17%3A19%3A08Z&SignatureMethod=HmacSHA256&AWSAccessKeyId=553999ad78df4898895f42df1617f97f&SignatureVersion=2&Signature=ZySxT9u6kQs8LVh4N7Jyk%2FWdQXISJYw9zCVmGbzmKxc%3D"

HTTP/1.1 403 AccessDenied

Content-Type: application/xml; charset=UTF-8

Content-Length: 149

Date: Tue, 14 Jul 2015 17:46:06 GMT

<ErrorResponse><Error><Message>User is not authorized to perform action</Message><Code>AccessDenied</Code><Type>Sender</Type></Error></ErrorResponse


Manually scale instances 39

CHAPTER 6

Call the Amazon Elastic Compute Cloud (EC2)API

This chapter describes how to call the Amazon EC2 API.

l VxRack Neutrino compatibility with the Amazon EC2 API..................................42l How to call the Amazon EC2 API .......................................................................42

Call the Amazon Elastic Compute Cloud (EC2) API 41

VxRack Neutrino compatibility with the Amazon EC2 API

VxRack Neutrino supports the OpenStack Ec2-Api project, which is an EC2 APIcompatibility layer for OpenStack. This means that the EC2 API can be used to accessVxRack Neutrino OpenStack features. VxRack Neutrino is compatible with theAmazon EC2 API, with the following exceptions:

l Uploading images in Amazon Machine Image (AMI) format is not supported inGlance.

l Glance-related EC2 API calls are not supported because they require the AmazonSimple Storage Service (S3). For example, the EC2 API cannot be used to uploada Glance image.

l All EC2 API functionality is limited to the services and features that VxRackNeutrino supports. In other words, you can only use the EC2 API in the context ofthe OpenStack services supported in the VxRack Neutrino OpenStack privatecloud.

How to call the Amazon EC2 API

Procedure

1. Set the EC2_ENDPONT_URL variable, as shown below.

export EC2_ENDPONT_URL= https://<VxRack_Neutrino_VIP>:8788/services/CloudNote: This environment variable must be set in addition to the environmentvariables set for domain-scoped commands as described in Configure a client torun OpenStack CLI commands on page 12.

2. Create credentials for access, as shown in the example below.

# openstack credential create --type ec2 --project adminadmin '{"access": "1234567890", "secret": "0987654321"}'Output:

3. Install the Amazon Web Service (AWS) CLI using the pip install awsclicommand.

4. Configure the AWS CLI using the aws configure command and input thefollowing parameters. (The access and secret keys must match what was usedin Step 2.)

AWS Access Key ID [None]:1234567890

Call the Amazon Elastic Compute Cloud (EC2) API


AWS Secret Access Key [None]: 0987654321

Default region name [None]: regionOne

Default output format [None]: json

Note: The AWS CLI supports three different output formats: JSON (json), tab-delimited text (text), and ASCII-formatted table (table).

5. List images using this command:

aws --endpoint-url $EC2_ENDPONT_URL ec2 describe-imagesOutput:

{ "Images": [ { "Name": "fedora", "ImageId": "ami-22134e5b", "State": "saving", "Architecture": "", "ImageLocation": "None (fedora)", "OwnerId": "6194fd5fd4814c60a1f8a720101c9fb0", "Public": true, "ImageType": "machine" }, { "Name": "cirros", "ImageId": "ami-3471c571", "State": "available", "Architecture": "", "ImageLocation": "None (cirros)", "OwnerId": "6194fd5fd4814c60a1f8a720101c9fb0", "Public": true, "ImageType": "machine" } ]}

6. Launch an instance using this command:

aws --endpoint-url $EC2_ENDPONT_URL ec2 run-instances --image-id ami-3471c571 --instance-type v4.mediumNote: --image-id is obtained from the output of the describe-imagescommand in Step 5.

Output:

{ "OwnerId": "6194fd5fd4814c60a1f8a720101c9fb0", "ReservationId": "r-0ilfgzol", "Groups": [ { "GroupName": "default" } ], "Instances": [ { "Placement": { "AvailabilityZone": "nova" }, "InstanceId": "i-40ae7461",


How to call the Amazon EC2 API 43

"PublicDnsName": "", "ImageId": "ami-3471c571", "PrivateDnsName": "", "State": { "Code": 0, "Name": "pending" }, "KeyName": "", "LaunchTime": "2016-02-03T21:14:33Z", "AmiLaunchIndex": 0, "InstanceType": "v4.medium", "PrivateIpAddress": "" } ]}



CHAPTER 7

OpenStack best practices

This chapter describes some OpenStack best practices that you should consider whenyou work in the OpenStack Dashboard UI.

l Check system defaults in the OpenStack Dashboard UI.....................................46l Use caution when increasing the default CPU overcommit ratio from 2 ............ 47l Do not perform user management tasks in the OpenStack Dashboard UI...........47l Select a default security group for instances..................................................... 48l Do not modify default flavor attributes in the OpenStack Dashboard UI............ 48l Remove unused flavors from OpenStack........................................................... 48l Modify default vCPU and RAM quotas before launching large instances with the

p3.8xlarge, e3.8xlarge, k3.8xlarge flavors.......................................................... 50

OpenStack best practices 45

Check system defaults in the OpenStack Dashboard UI

When you use the OpenStack Dashboard UI to perform cloud compute tasks, youshould familiarize yourself with the system default limits in the System > Defaultspage of the OpenStack Dashboard UI. The default limits, such as maximum volume/snapshot size, and numbers of instances, vCPUs, and volumes per project, are set forvarious aspects of the VxRack Neutrino OpenStack private cloud on this page.

When you perform tasks, such as launching instances, you should periodically checkthe Defaults page to ensure that your projects are within the default limits. If youexceed a default system limit, you will receive an error message. For example,OpenStack has a default limit of 10 instances and 10 volumes per project. If you have10 instances in a project and you try to launch another instance in this project, theoperation will fail with an error message. You will be unable to launch additionalinstances in that project until you delete existing instances.

Similarly, if you have 10 volumes in a project, you will be unable to create additionalvolumes without deleting existing volumes. To avoid exceeding the 10 volumes perproject limit, ensure that when you delete instances that you also delete the volumesassociated with the deleted instances if the volume data is not needed.

System defaults with a value of -1When looking at the Defaults page, you will notice that several defaults have a valueof -1. These defaults are specific to VxRack Neutrino, and are not standard OpenStackdefaults. In general, in OpenStack, a value of -1 means unlimited, where there is noquota limit for a resource. However, in the VxRack Neutrino OpenStackimplementation, this is not the case. The defaults that have a value of -1 are subsets ofa comparable OpenStack standard quota value.

For example, the VxRack Neutrino OpenStack Volumes of Type Capacity quota andthe Volumes of Type Performance quota each have a value of -1. The comparableOpenStack standard quota value is the Volumes quota, which has a value of 10. TheVolumes quota takes precedence over the Volumes of Type Capacity and the Volumesof Type Performance quotas. This means that you may have any number of volumestype capacity or performance up to the volume quota limit of 10 in a project.

The same thing applies for the VxRack Neutrino Volume Snapshots of Type Capacityand Volume Snapshots of Type Performance quotas: the standard OpenStack VolumeSnapshots quota of 10 takes precedence. You can have any number of volumesnapshots type capacity or performance up to the volume snapshot quota limit of 10 ina project.

The following table lists the VxRack Neutrino OpenStack default quotas with values of-1 and the standard OpenStack default quotas that cap them.

Table 14 OpenStack standard system default quotas that cap the VxRack Neutrino defaultquotas with values of -1

VxRack Neutrino OpenStack systemdefault quotas with values of -1

OpenStack standard system defaultquota caps

Volumes of Type Capacity

Volumes of Type Performance

Volumes (10)

Volume Snapshots of Type Capacity

Volume Snapshots of Type Performance

Volume snapshots (10)



Table 14 OpenStack standard system default quotas that cap the VxRack Neutrino defaultquotas with values of -1 (continued)

VxRack Neutrino OpenStack systemdefault quotas with values of -1

OpenStack standard system defaultquota caps

Total Size of Volumes and Snapshots (GiB) ofType Capacity

Total Size of Volumes and Snapshots (GiB) ofType Performance

Total Size of Volumes and Snapshots (1000)

Per Volume Size (GiB) Total Size of Volumes and Snapshots (1000)

Use caution when increasing the default CPU overcommitratio from 2

In the VxRack Neutrino OpenStack cloud, the number of vCPUs available toOpenStack users is calculated by the number of physical CPU cores on the cloudcompute nodes times 4. For example, if there is one cloud compute node with 12physical CPU cores, then there are 48 vCPUs available to OpenStack users (12physical CPU cores x 4 = 48 vCPUs).

It's possible to increase the number of vCPUs in the OpenStack environment beyondthe default configuration which gives you 4 vCPUs for every physical CPU core on acloud compute node. This can be done by configuring the cpu_allocation_ratioOpenStack property (also referred to as the CPU overcommit ratio). This property isthe vCPU to logical core allocation ratio and it is set to 2 by default. This means forevery cloud compute logical core, there are 2 vCPUs.

In VxRack Neutrino, there are two logical cores for every physical CPU core (becauseof hyperthreading). The 4 vCPUs per physical core ratio is calculated as: the numberof cloud compute node physical CPU cores x 2 (2 is the VxRack Neutrinohyperthreading value) = number of logical cores x 2 (2 is the defaultcpu_allocation_ratio value) = number of available vCPUs.

As an example, let's say we set the cpu_allocation_ratio property to 5. A computenode with 12 physical CPU cores would have 120 available vCPUs, instead of thedefault 48 available vCPUs. (12 x 2 (hyperthreading value) = 24 logical cores x 5 = 120vCPUs). The benefit of this is that you increase the number of vCPUs available percompute node, which allows you to increase the number of instances you can haverunning in your cloud. The disadvantage is that you may run into performance issueswith the instances that you are overcommitting on the compute nodes.

Do not perform user management tasks in the OpenStackDashboard UI

VxRack Neutrino Cloud or Account Administrators should manage users only in theVxRack Neutrino UI. While VxRack Neutrino Cloud or Account Administrators cancreate or delete users and add or remove users from projects through the OpenStackDashboard UI, such actions are not recommended.


Use caution when increasing the default CPU overcommit ratio from 2 47

Select a default security group for instances

When you launch an instance from the OpenStack Dashboard UI, click Project >Compute > Access & Security and select the default security group on the SecurityGroups tab. If you don't select this checkbox, the default security group rule will stillbe applied to the instance. Because future versions of OpenStack might allow users tolaunch instances without a default security group, it is considered a good practice tomanually apply the default security group when you launch an instance.

Do not modify default flavor attributes in the OpenStackDashboard UI

The default OpenStack flavors that are included during the initial VxRack Neutrinoinstallation should not be changed. A Cloud Administrator can create or delete acustom flavor, but cannot change any attributes of the existing default flavors that areincluded in the OpenStack deployment.

Remove unused flavors from OpenStack

The VxRack Neutrino default installation provides the 28 flavors listed in the followingtable. Your environment may not require all these flavors. For example, if you have notdeployed the Cloud Compute Service on any capacity nodes that contain HDDs, youwill not need all the flavors that have a 3 as the second character in their name. In thiscase, it would be advisable to remove all those flavors from OpenStack so thatunneeded flavor types do not display as choices when you launch instances. To deleteunneeded flavors in the OpenStack Dashboard UI:

1. In the Admin tab, open the System tab and click the Flavors category.

2. Select the flavors you want to delete.

3. Click Delete Flavors.

Table 15 Default OpenStack flavors

OpenStackflavor name

vCPUs RAM* Rootdisk**

Ephemeraldisk***

Storage poolfrom which theroot andephemeral diskstorage isprovisioned****

Use cases

General purpose GB

v4.medium 1 4 GB 0 GB 8 GB Performance (SSD) Small and mid-sizedatabases, dataprocessing tasks thatrequire additionalmemory, cachingcollections of instances,and for running backendservers for SAP,

v4.large 2 8 GB 0 GB 32 GB Performance (SSD)

v4.xlarge 4 16 GB 0 GB 80 GB Performance (SSD)

v4.2xlarge 8 32 GB 0 GB 160 GB Performance (SSD)

v3.medium 1 4 GB 0 GB 8 GB Capacity (HDD)



Table 15 Default OpenStack flavors (continued)



Ephemeraldisk***


Use cases

v3.large Microsoft SharePoint,cluster computing, andother enterpriseapplications.

2 8 GB 0 GB 32 GB Capacity (HDD)

v3.xlarge 4 16 GB 0 GB 80 GB Capacity (HDD)

v3.2xlarge 8 32 GB 0 GB 160 GB Capacity (HDD)

Compute optimized

p4.large 2 4 GB 0 GB 32 GB Performance (SSD) High performance front-end collections ofinstances, web-servers,batch processing,distributed analytics,high performancescience and engineeringapplications, ad serving,massively multiplayeronline (MMO) gaming,video-encoding, anddistributed analytics

p4.xlarge 4 8 GB 0 GB 80 GB Performance (SSD)

p4.2xlarge 8 16 GB 0 GB 160 GB Performance (SSD)

p3.large 2 4 GB 0 GB 32 GB Capacity (HDD)

p3.xlarge 4 8 GB 0 GB 80 GB Capacity (HDD)

p3.2xlarge 8 16 GB 0 GB 160 GB Capacity (HDD)



Memory optimized

e4.large 2 16 GB 0 GB 32 GB Performance (SSD) Memory-optimizedinstances for highperformance databases,distributed memorycaches, in-memoryanalytics, genomeassembly and analysis,larger deployments ofSAP, MicrosoftSharePoint, and otherenterprise applications.

e4.xlarge 4 32 GB 0 GB 80 GB Performance (SSD)

e4.2xlarge 8 64 GB 0 GB 160 GB Performance (SSD)

e3.large 2 16 GB 0 GB 32 GB Capacity (HDD)

e3.xlarge 4 32 GB 0 GB 80 GB Capacity (HDD)

e3.2xlarge 8 64 GB 0 GB 160 GB Capacity (HDD)



Storage optimized

k3.xlarge 4 32 GB 0 GB 800 GB Capacity (HDD) NoSQL databases likeCassandra andMongoDB, scale outtransactional databases,data warehousing,Hadoop, and cluster filesystems.

k3.2xlarge 8 64 GB 0 GB 1,600 GB Capacity (HDD)



*GB for RAM, root disk capacity, and ephemeral disk capacity is based on the binary system (base 2) of measurement, whichcalculates 1 GB as 1,073,741,824 bytes.


Remove unused flavors from OpenStack 49

Table 15 Default OpenStack flavors (continued)



Ephemeraldisk***


Use cases

**When an instance is launched with any one of the listed flavors, two ephemeral volumes are created (root and ephemeraldisks). The root disk is the primary ephemeral volume that the base image is copied into; it stores the operating system. The 0GB size of the root disk allows the root disk to take the size of the image used to launch the instance, with a minimum rootdisk size of 8 GB. ( VxRack Neutrino block storage requires that volume sizes must be in increments of 8 GB.) For example,when an instance is sourced from an image that is 870 MB in size, the root disk would be 870 MB, but then rounded up to thenext multiple of 8, which is 8 GB. An instance sourced from an image that is 870 MB in size, with the v4.large flavor selected,would result in a launched instance with a root disk of 8 GB, and an ephemeral disk of 32 GB.

***The secondary ephemeral volume that stores data.

****Flavor names that contain the number 3 as the second character denote that the instance's storage will be provisionedout of the VxRack Neutrino capacity storage pool which contains HDD storage devices. Flavor names that contain the number4 as the second character denote that the instance's storage will be provisioned out of the performance storage pool whichcontains SSD storage devices.

Modify default vCPU and RAM quotas before launchinglarge instances with the p3.8xlarge, e3.8xlarge, k3.8xlargeflavors

When creating large sized instances with the p3.8xlarge, e3.8xlarge, k3.8xlargeflavors, you must adjust the default quotas (operational limits) for vCPUs and RAM inthe OpenStack Dashboard UI before you launch an instance with one of these flavors.Otherwise, instance creation with these flavors will fail.

The OpenStack default quotas for RAM and vCPUs are shown in the following tableand compared to the flavor attributes.

Table 16 OpenStack RAM and vCPU default quotas compared to three large flavor attributes

OpenStack quotaname anddescription

OpenStack defaultquota

p3.8xlarge e3.8xlarge k3.8xlarge

vCPUs - numbervCPUs allowed perproject

20 32 32 32

RAM - RAMmegabytes allowed foreach instance.

51,200 MB 64 GB 256 GB 256 GB

For example, if you want to launch an instance with the p3.8xlarge flavor, you shouldmodify the default vCPUs quota to 32, and the RAM quota to 64000 MB. To edit theRAM and vCPUs default quotas in the OpenStack Dashboard UI:



1. On the Admin tab, open the System tab and click the Defaults category.

2. Click the Update Defaults button.

3. In the Update Default Quotas window, you can edit the default quota values.

4. Click the Update Defaults button.


Modify default vCPU and RAM quotas before launching large instances with the p3.8xlarge, e3.8xlarge, k3.8xlarge flavors 51

CHAPTER 8

VxRack Neutrino OpenStack limitations

This chapter describes the OpenStack limitations related to the VxRack Neutrino 1.1release.

l OpenStack features that VxRack Neutrino does not support.............................54l Keystone v2 API allows access to only the Default domain................................ 54l Live instance migration will fail using the OpenStack Keystone v3 client........... 54l Instances must be created in private network....................................................55l OpenStack Dashboard UI displays incorrect number of available vCPUs........... 55l Cloud Administrator must set domain context to view users/groups in OpenStack

...........................................................................................................................55l Nova scheduling filter SimpleCIDRAffinityFilter does not work properly............56l Instance creation fails when sourced from volume.............................................56l OpenStack Glance volume is provisioned from the first storage pool created....56

VxRack Neutrino OpenStack limitations 53

OpenStack features that VxRack Neutrino does not supportThe following table describes the OpenStack features that are not supported inVxRack Neutrino 1.1.

Table 17 OpenStack features not supported in VxRack Neutrino

OpenStack feature notsupported

Description

Host aggregates andavailability zones

A host aggregate creates logical units in an OpenStack deployment by grouping togetherhosts that share common resources like storage and network. Only administrators can see orcreate host aggregates. An availability zone is the end-user view of a host aggregate.OpenStack host aggregates and availability zones are used to divide a single computedeployment. In the VxRack Neutrino OpenStack private cloud, all cloud compute hosts areshared across all accounts and projects and any instance can be launched on any physicalhost.

Regions When you need discrete regions with separate API endpoints and no coordination betweenregions, OpenStack regions segregate a cloud, which results in separate computedeployments.

Firewall-as-a-Service Firewall-as-a-Service (FWaaS) is an OpenStack Networking (Neutron) extension thatprovides perimeter firewall management to Neutron.

Load-Balancing-as-a-Service Load-Balancing-as-a-Service (LBaaS) is an advanced Neutron service. It enables proprietaryand open-source load balancing technologies to drive the load balancing of requests.

Keystone v2 API allows access to only the Default domain

When you use the Keystone v2 API to get an authentication token for access to theOpenStack services REST API (or CLI), you only have access to users and projects inthe VxRack Neutrino Default domain. (The Default domain is the implicit domainreferenced in the OpenStack API and CLI commands when Keystone v2 is used toauthenticate.) This is because in Keystone v2 API, the concept of multiple domainsand groups did not exist, so when Keystone v2 API is used for authentication, it onlyprovides information on one domain: the Default domain (and the projects and userswithin the Default domain). For example, if you use the OpenStack API list userscall, the response will only list the users for the Default domain, and no other domain.If you use the Keystone v3 API for authentication to access the OpenStack servicesREST API, you will have access to other domains (other than the Default domain), andthe users, groups, and projects in those domains. The difference in domain accessbetween using the Keystone v2 and v3 API only applies to Keystone.

Live instance migration will fail using the OpenStackKeystone v3 client

Live migration is the movement of a live instance from one compute node to another.

The VxRack Neutrino OpenStack implementation requires that you perform livemigrations with either the OpenStack Keystone v2 client or the OpenStack DashboardUI. Live migration will fail using Keystone v3.



Instances must be created in private network

OpenStack instances must be created in a private network. SSH cannot reachinstances that are created in public networks and, the instances will be incorrectlycounted towards the router quota for the project.

OpenStack Dashboard UI displays incorrect number ofavailable vCPUs

There is a discrepancy in the way the number of available vCPUs is calculated anddisplayed in the OpenStack Dashboard and VxRack Neutrino UIs.

VxRack Neutrino calculates the number of available vCPUs as the number of physicalCPU cores on nodes running the Cloud Compute Service times 4. (Nodes running thePlatform Service and unallocated nodes are not included in the vCPU calculation.) Forexample, if there are ten cloud compute nodes with 12 physical CPU cores each, therewould be 480 available vCPUs (10 cloud compute nodes x 12 CPU cores = 120 CPUcores x 4 = 480 vCPUs). The number of vCPUs determines the number of instancesthat can be launched in the OpenStack Dashboard UI.

Note

The physical CPU core x 4 calculation is based on: number of cloud compute nodephysical CPU cores x 2 (2 is the VxRack Neutrino hyperthreading value) = number oflogical cores x 2 (2 is the default VxRack Neutrino vCPU oversubscription ratio) =number of available vCPUs. The VxRack Neutrino default 2:1 vCPU oversubscriptionratio is a configurable OpenStack property called the cpu_allocation_ratio. It is thevCPU to logical core allocation ratio.

The OpenStack Dashboard UI presents the number of available vCPUs as the numberof logical cores, which is the number of cloud compute node physical CPU cores times2 (the hyper-threading value). So if there are 120 cloud compute physical CPU cores,OpenStack will display the number of available vCPUs as 120 x 2 = 240. This is notaccurate, as there are actually 480 vCPUs available for use in creating instances. TheHypervisors page in the OpenStack Dashboard UI will display 240 available vCPUs ,while the VxRack Neutrino UI will display 480 available vCPUs on the Cloud Computepage. This discrepancy reflects the difference in how each product computes thenumber of available vCPUs.

Cloud Administrator must set domain context to viewusers/groups in OpenStack

When the Cloud Administrator logs into OpenStack Dashboard UI to view users orgroups, an error message displays: Error: Unauthorized: Unable toretrieve user/group list. The workaround for this issue is to set your domaincontext to view the users and groups in all the appropriate domains. To do this:

1. Click Identity > Domains.

2. In the Domains list, click the Set Domain Context button next to the domain(s) inwhich you want to view the users/groups.


Instances must be created in private network 55

For more information about this known OpenStack issue, see https://bugs.launchpad.net/horizon/+bug/1415588.

Nova scheduling filter SimpleCIDRAffinityFilter does notwork properly

The Nova component that is part of the VxRack Neutrino software includes severalNova scheduling filters that are enabled by default. The filters are listed under thescheduling_filter property for the Nova component on the Services > CloudCompute > Configuration page of the VxRack Neutrino UI. They are used todetermine which cloud compute nodes you want your instances to run on. Each filteroffers a different way of choosing which cloud compute nodes will host yourinstances. You can activate these filters when using the OpenStack Nova command-line client to boot an instance. For information on Nova scheduling filters, see http://docs.openstack.org/mitaka/config-reference/compute/scheduler.html.

All of the scheduling filters listed for the Nova component in the UI are supportedexcept the SimpleCIDRAffinityFilter, which schedules instances based on host IPsubnet range. If you use this filter to boot instances, it may not schedule to the rightcloud compute nodes in the subnet range you specify; therefore it is notrecommended that you use this filter.

Instance creation fails when sourced from volume

Instance creation fails when the instance is sourced from a volume that was createdfrom an instance snapshot. For example, instance creation will fail in the followingscenario:

Procedure

1. Create an instance and create a new volume during instance creation.

2. Take a snapshot of the instance.

3. Create a volume from the instance snapshot.

4. Launch an instance using this volume.

Instance launch fails.

OpenStack Glance volume is provisioned from the firststorage pool created

When a Cloud Administrator adds the first set of nodes to the Cloud Compute Service,a 256 GB volume named glance_volume is created. This Glance volume stores theoperating system images used to create instances in OpenStack. It is provisioned bythe storage on the initial set of nodes added to the Cloud Compute Service. Forexample, if a Cloud Administrator initially adds six performance nodes (that containSSD disks) to the Cloud Compute Service, then the Glance volume is provisioned fromthe performance storage pool that is created. In VxRack Neutrino 1.1, a CloudAdministrator cannot choose which storage pool the Glance volume is provisionedfrom, it is simply provisioned from the storage pool that is created on the initial set ofnodes added to the Cloud Compute Service.



https://bugs.launchpad.net/horizon/+bug/1415588

https://bugs.launchpad.net/horizon/+bug/1415588

http://docs.openstack.org/mitaka/config-reference/compute/scheduler.html

http://docs.openstack.org/mitaka/config-reference/compute/scheduler.html

openstack implementation guide - dell emc...networking openstack neutron manages logical networking...

Documents