The following sections
provide examples of Cisco VIM OpenStack configurations in the setup_data.yaml
file.
OpenStack Admin Credentials
ADMIN_USER: <admin>
ADMIN_TENANT_NAME: <admin tenant>
OpenStack HAProxy and Virtual Router Redundancy Protocol
Configuration
external_lb_vip_address: An externally routable ip address in API nework
VIRTUAL_ROUTER_ID: vrrp_router_id #eg: 49 (range of 1-255)
internal_lb_vip_address: <Internal IP address on mgmt network>
OpenStack DNS Name Configuration
For web and REST
interfaces, names are commonly used instead of IP addresses. You can set the
optional external_lb_vip_fqdn parameter to assign a name that resolves to the
external_lb_vip_address. You must configure the services to ensure the name and
address match. Resolution can be made through DNS and the Linux /etc/hosts
files, or through other options supported on your hosts. The Cisco VIM
installer adds an entry to /etc/hosts on the management and other Cisco NFVI
nodes to ensure that this resolution can be made from within the pod. You must
ensure the resolution can be made from any desired host outside the pod.
external_lb_vip_fqdn: host or DNS name matching external_lb_vip_address
OpenStack TLS and HTTPS Configuration
Enabling TLS is
important to ensure the Cisco VIM network is secure. TLS encrypts and
authenticates communication to the cloud endpoints. When TLS is enabled, two
additional pieces of information must be provided to the installer: haproxy.pem
and haproxy-ca-crt. These must be placed in the
~/installer-xxxx/openstack-configs directory.
haproxy.pem is the
server side certificate file in PEM format. It must include the server
certificate, any intermediate certificates, and the private key for the server.
The common name of the certificate must match the external_lb_vip_address
and/or the external_lb_vip_fqdn as configured in the setup_data.yaml file.
haproxy-ca.crt is the certificate of the trusted certificate authority that
signed the server side.
For production
clouds, these certificates should be provided by a trusted third party CA
according to your company IT policy. For test or evaluation clouds, self-signed
certificates can be used quickly enable TLS. For convenience, the installer
includes a script that will create and install self-signed certificates
Note |
Do not use the
certificates generated by this tool for production. They are for test purposes
only.
|
To use this tool,
make the following changes to the setup data file, then run the tool:
external_lb_vip_address: <IP address on external network>
external_lb_vip_tls: True
external_lb_vip_fqdn: host or DNS name matching external_lb_vip_address (if FQDN is needed)
To run the tool, from
the /working_dir/ directory, execute
./tools/tls_cert_gen.sh -f
openstack-configs/setup_data.yaml.
OpenStack Glance Configuration with Dedicated Ceph/Netapp
For OpenStack Glance, the OpenStack image service, the dedicated Ceph object storage configuration is show below. Do not change it. The Ceph and Glance keys are generated during the Ceph installation step, so you do not need to specify the keys in setup_data.yaml file. STORE_BACKEND: ceph/netapp #supported as ‘ceph’ for ceph backend store;and netapp for netapp backend
OpenStack Glance Configuration
STORE_BACKEND: <set to ‘file’ for local filesystem store>
OpenStack Cinder Configuration with Dedicated Ceph/Netapp
For OpenStack Cinder, the OpenStack storage service, the dedicated Ceph object storage configuration is show below. Do not change it. The Ceph and Cinder keys are generated during the Ceph installation step, so you do not need to specify the keys in setup_data.yaml file. Use the vgs command to check your volume groups available on your controller nodes. The controller nodes run the Cinder volume containers and hold the volume groups for use by Cinder. If you have available disks and want to create a new volume group for Cinder use the vgcreate command. VOLUME_DRIVER: ceph/netapp
OpenStack Nova
Configuration
To reduce the boot time, the NOVA_BOOT_FROM parameter is set to local for Cisco VIM in the OpenStack Newton release. While this reduces the boot time, it does not provide Ceph back end redundancy. To overwrite it, you can set NOVA_BOOT_FROM to ceph . This only applies to when the backend is ceph. For Netapp, no entry for this parameter is allowed.. # Nova boot from CEPH
NOVA_BOOT_FROM: <ceph> #optional
OpenStack Neutron
Configuration
OpenStack Neutron
configuration is shown below.
# ML2 Conf – choose from either option 1 or option 2
# option 1: LinuxBridge-VXLAN
MECHANISM_DRIVERS: linuxbridge
TENANT_NETWORK_TYPES: "VXLAN"
Or
## option 2: OVS VLAN
MECHANISM_DRIVERS: openvswitch
TENANT_NETWORK_TYPES: "VLAN"
# VLAN ranges can be one continuous range or comma separated discontinuous ranges
TENANT_VLAN_RANGES: 3001:3100,3350:3400
# Jumbo MTU functionality. Only in B series, OVS-VLAN
# more info here [Mercury] Jumbo MTU feature in Mercury (B Series)
# ENABLE_JUMBO_FRAMES: True
# for Provider networks, just specifying the provider in the segments under
# the NETWORKING section is enough.
# Note : use phys_prov as physical_network name when creating a provider network
Note |
When creating an
external or provider network, use physical_network=phys_ext (need to be
specified) or physical_network=phys_prov (need to be specified), respectively.
|
The JUMBO_MTU
functionality is available only for OVS over VLAN in a UCS B-Series pod. In a
VLAN setup, by default the MTU size is set to 1500 (1450 for VXLAN) and 8972
bytes. When JUMBO_MTU is enabled (with 28 bytes left for the header), the VLAN
MTU will be 9000 and VXLAN will be 8950.
Cisco VIM also supports the installation of a handful of optional services, namely, Keystone v3 and Heat. OpenStack Heat, an orchestration service that allows you to spin up multiple instances, logical networks, and other cloud services in an automated fashion. To enable Heat, add the following in the setup_data.yaml.
# Optional Services:
OPTIONAL_SERVICE_LIST:
- heat
To disable Heat, remove the Optional Services section from the setup_data.yaml file. The Optional Services support provides an infrastructure to support additional services in the future.
Note |
Auto-scaling is not supported in Cisco VIM, release 2.2 and higher releases.
|
To continue enhancing the security portfolio, and multi-tenancy with the use of domains, Keystone v3 support has been added in Cisco VIM from an authentication end-point. It should be noted that Keystone v2 and Keystone v3 are mutually exclusive; that is the administrator has to decide during installation: the authentication end-point version should be Keystone v2 or Keystone v3 . By default, VIM orchestrator picks keystone v2 as the authentication end-point.
To enable Keystone
v3, you need to define the following under the optional services section.
# Optional Services:
OPTIONAL_SERVICE_LIST:
- keystonev3
LDAP support with
Keystone v3
With the
introduction of Keystone v3, the OpenStack service authentication can now be
delegated to an external LDAP server. In Cisco VIM 2.0, this feature has been
introduced optionally if the authorization is done by Keystone v3.
An important
pre-requisite for enabling LDAP integration is that the LDAP endpoint should be
reachable from all the Controller nodes that run OpenStack Keystone Identity
Service.
To benefit LDAP
support with Keystone v3 feature, the setup_data needs to be augmented with the
following information during the installation of the pod.
LDAP:
domain: <Domain specific name>
user_objectclass: <objectClass for Users> # e.g organizationalPerson
group_objectclass: <objectClass for Groups> # e.g. groupOfNames
user_tree_dn: '<DN tree for Users>' # e.g. 'ou=Users,dc=cisco,dc=com'
group_tree_dn: '<DN tree for Groups>' # e.g. 'ou=Groups,dc=cisco,dc=com'
suffix: '<suffix for DN>' # e.g. 'dc=cisco,dc=com'
url: '<ldap:// host:port>' # e.g. 'ldap://172.26.233.104:389'
user: '<DN of bind user>' # e.g. 'dc=admin,dc=cisco,dc=com'
password: <password> # e.g. password of bind user
Note |
The values for
the parameters may differ based on the Directory Service provider. For Example:
OpenLDAP or Microsoft Active Directory.
|
Integrating
identity with LDAP over TLS: The automation supports keystone integration
with LDAP over TLS. In order to enable TLS, the CA root certificate must be
presented as part of the /root/openstack-configs/haproxy-ca.crt file. The url
parameter within the LDAP stanza must be set to
ldaps.
url parameter
supports the following formats
url: '<ldaps | ldap>://<FQDN | IP-Address>:[port]’
The protocol can be
ldap for non-ssl OR ldaps if TLS is to be enabled
The ldap host can
be a fully-qualified domain name (FQDN) or an IP Address depending on how the
SSL certificates are generated.
The port number is
optional and if it is not provided it is assumed that the ldap services are
running on the default ports For Example:389 for non-ssl and 636 for ssl.
However, if these ports are not the default ports, then the non-standard port
numbers must be provided.
OpenStack Object Storage
integration with Cisco VIM
Cisco VIM supports
automated integration with a customer-managed object storage solution. The
integration points reside primarily in the OpenStack Identity (Keystone)
component of Cisco VIM. In the current release, this integration is restricted
to Keystone v2 only. It currently integrates with SwiftStack as the choice of
object storage solution. The deployment assumes a customer-managed SwiftStack
solution. Installation of the SwiftStack Controller/PACO cluster is out of
scope of this document and customer should reach out to the SwiftStack team for
license and installation details. While OpenStack can support multiple
endpoints for a given object-store service, the current setup in the context of
automation supports a single Keystone object-store service per SwiftStack PACO
cluster endpoint.
The current
automation uses the admin role for authentication and authorization of
SwiftStack users between the Keystone SwiftStack tenant and SwiftStack account.
Pre-requisites
Since it is a
customer-managed deployment model, the minimum pre-requisite is to have a
SwiftStack controller, Cluster deployed with appropriate PAC
(Proxy/Account/Container) and Object configured ahead of time. The swift
endpoint of the PAC outward facing ip address, the corresponding admin user,
password and service tenant information is known at the time of configuring
Keystone integration. The networking should be configured in such a way that
the PAC outward facing ip address and the POD API network can talk to each
other. Also the Keystone Auth and Keystone Auth Token middleware are
pre-configure in SwiftStack (see the steps in subsequent section).
In order for Horizon
and Cinder Backup Service to talk to the SwiftStack endpoints, it is necessary
for the OpenStack controllers to have network reachability to the SwiftStack
API endpoints.
Keystone Configuration
Requirements in SwiftStack
Configuring Keystone
Authorization: From the SwiftStack controller, select the
Cluster> Manage > Middleware > Keystone Auth
option.
Note |
reseller_prefix
will enable the Keystone Auth middleware invocation at the time of
authentication.
|
Figure 2. Configuring
Keystone
Configuring Keystone Auth
Token Support: From the SwiftStack controller, select the
Cluster
> Manage > Middleware > Keystone Auth Token Support
option.
Note |
auth_uri is
deprecated
|
Usage in Cisco VIM
In order to support
SwiftStack endpoint configuration, the following section needs to be configured
in setup_data.yaml.
##########################################
# Optional Swift configuration section
##########################################
# SWIFTSTACK: # Identifies the objectstore provider by name
# cluster_api_endpoint: <IP address of PAC (proxy-account-container) endpoint>
# reseller_prefix: <Reseller_prefix configured in Swiftstack Keystone middleware E.g KEY_>
# admin_user: <admin user for swift to authenticate in keystone>
# admin_password: <swiftstack_admin_password>
# admin_tenant: <The service tenant corresponding to the Account-Container used by Swiftstack>
# protocol: <http or https> # protocol that swiftstack is running on top
The automation
supports two modes of Integration with SwiftStack- Integration during fresh
install of the pod and a reconfigure option to add a SwiftStack endpoint to an
existing Pod running CiscoVIM 2.0.
In the Fresh Install
mode, adding the setup_data.yaml will automatically provision the following in
Keystone.
-
Keystone
service for Object Store.
-
Keystone
endpoints for the Object Store service.
-
A SwiftStack
admin user with admin role in a SwiftStack tenant.
Integration
Testing: In order to test if the Keystone integration has been successful,
request a token for the configured swift user, tenant
Output must contain
a properly generated endpoint for the object-store service that points to the
SwiftStack PAC cluster endpoint with the expected "reseller_prefix" For
example: KEY_
curl -d
'{"auth":{"passwordCredentials":{"username": "<username>", "password":
"<password>"},"tenantName":"<swift-tenant>"}}' -H "Content-type:
application/json" < OS_AUTH_URL >/tokens
Output should list
endpoints generated by Keystone for the object-store cluster endpoint of
SwiftStack for the user tenant (SwiftStack account).
Sample output
snippet (all IP and Keys are just examples, they will vary from Pod to Pod):
{
"access": {
"metadata": {
"is_admin": 0,
"roles": [
"33f4479e42eb43529ec14d3d744159e7"
]
},
"serviceCatalog": [
{
"endpoints": [
{
"adminURL": "http://10.30.116.252/v1",
"id": "3ca0f1fee75d4e2091c5a8e15138f78a",
"internalURL": "http://10.30.116.252/v1/KEY_8cc56cbe99ae40b7b1eaeabb7984c77d",
"publicURL": "http://10.30.116.252/v1/KEY_8cc56cbe99ae40b7b1eaeabb7984c77d",
"region": "RegionOne"
}
],
"endpoints_links": [],
"name": "object-store",
"type": "object-store"
},
......
Verify that the
Keystone user has access to the SwiftStack cluster. Using the token generated
preceding for the swiftstack user and tenant, make a request to the SwiftStack
cluster
curl -v -H "x-auth-token: <auth-token>" http://10.30.116.252/v1/KEY_8cc56cbe99ae40b7b1eaeabb7984c77d
This will list all
the containers (if present) for the SwiftStack tenant (account)
Integrating SwiftStack
over TLS: The automation supports SwiftStack integration over TLS. To
enable TLS, the CA root certificate must be presented as part of the
/root/openstack-configs/haproxy-ca.crt file. The
protocol
parameter within the SWIFTSTACK stanza must be set to https. As a
pre-requisite, the SwiftStack cluster will need to be configured to enable
HTTPS connections for the SwiftStack APIs with termination at the proxy
servers.
Cinder Volume Backup on
SwiftStack
Cisco VIM, enables
cinder service to be configured to backup its block storage volumes to the
SwiftStack object store. Cinder Volume Backup on SwiftStack feature is
automatically configured if the SWIFTSTACK stanza is present in the
setup_data.yaml. The mechanism to authenticate against SwiftStack during volume
backups leverages the same keystone SwiftStack endpoint configured for use to
manage objects. The default SwiftStack container to manage cinder volumes
within the Account (Keystone Tenant as specified by "admin_tenant") is
currently defaulted to
volumebackups.
Once configured,
cinder backup service will automatically be enabled as follows.
cinder service-list
+------------------+----------------+------+---------+-------+----------------------------+-----------------+
| Binary | Host | Zone | Status | State | Updated_at | Disabled Reason |
+------------------+----------------+------+---------+-------+----------------------------+-----------------+
| cinder-backup | c43b-control-1 | nova | enabled | up | 2017-03-27T18:42:29.000000 | - |
| cinder-backup | c43b-control-2 | nova | enabled | up | 2017-03-27T18:42:35.000000 | - |
| cinder-backup | c43b-control-3 | nova | enabled | up | 2017-03-27T18:42:33.000000 | - |
| cinder-scheduler | c43b-control-1 | nova | enabled | up | 2017-03-27T18:42:32.000000 | - |
| cinder-scheduler | c43b-control-2 | nova | enabled | up | 2017-03-27T18:42:32.000000 | - |
| cinder-scheduler | c43b-control-3 | nova | enabled | up | 2017-03-27T18:42:31.000000 | - |
| cinder-volume | c43b-control-1 | nova | enabled | up | 2017-03-27T18:42:35.000000 | - |
| cinder-volume | c43b-control-2 | nova | enabled | up | 2017-03-27T18:42:30.000000 | - |
| cinder-volume | c43b-control-3 | nova | enabled | up | 2017-03-27T18:42:32.000000 | - |
+------------------+----------------+------+---------+-------+----------------------------+-----------------+
Backing up of an
existing cinder volume is as follows
openstack volume list
+--------------------------------------+--------------+-----------+------+-------------+
| ID | Display Name | Status | Size | Attached to |
+--------------------------------------+--------------+-----------+------+-------------+
| f046ed43-7f5e-49df-bc5d-66de6822d48d | ss-vol-1 | available | 1 | |
+--------------------------------------+--------------+-----------+------+-------------+
openstack volume backup create f046ed43-7f5e-49df-bc5d-66de6822d48d
+-------+--------------------------------------+
| Field | Value |
+-------+--------------------------------------+
| id | 42a20bd1-4019-4571-a2c0-06b0cd6a56fc |
| name | None |
+-------+--------------------------------------+
openstack container show volumebackups
+--------------+--------------------------------------+
| Field | Value |
+--------------+--------------------------------------+
| account | KEY_9d00fa19a8864db1a5e609772a008e94 |
| bytes_used | 3443944 |
| container | volumebackups |
| object_count | 23 |
+--------------+--------------------------------------+
swift list volumebackups
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00001
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00002
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00003
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00004
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00005
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00006
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00007
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00008
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00009
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00010
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00011
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00012
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00013
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00014
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00015
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00016
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00017
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00018
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00019
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00020
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc-00021
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc_metadata
volume_f046ed43-7f5e-49df-bc5d-66de6822d48d/20170327185518/az_nova_backup_42a20bd1-4019-4571-a2c0-06b0cd6a56fc_sha256file