Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 11. Performing overcloud post-installation tasks
This chapter contains information about tasks to perform immediately after you create your overcloud. These tasks ensure your overcloud is ready to use.
11.1. Checking overcloud deployment status Copier lienLien copié sur presse-papiers!
To check the deployment status of the overcloud, use the openstack overcloud status command. This command returns the result of all deployment steps.
Procedure
Source the
stackrcfile:source ~/stackrc
$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow Run the deployment status command:
openstack overcloud status
$ openstack overcloud statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow The output of this command displays the status of the overcloud:
+-----------+---------------------+---------------------+-------------------+ | Plan Name | Created | Updated | Deployment Status | +-----------+---------------------+---------------------+-------------------+ | overcloud | 2018-05-03 21:24:50 | 2018-05-03 21:27:59 | DEPLOY_SUCCESS | +-----------+---------------------+---------------------+-------------------+
+-----------+---------------------+---------------------+-------------------+ | Plan Name | Created | Updated | Deployment Status | +-----------+---------------------+---------------------+-------------------+ | overcloud | 2018-05-03 21:24:50 | 2018-05-03 21:27:59 | DEPLOY_SUCCESS | +-----------+---------------------+---------------------+-------------------+Copy to Clipboard Copied! Toggle word wrap Toggle overflow If your overcloud uses a different name, use the
--planargument to select an overcloud with a different name:openstack overcloud status --plan my-deployment
$ openstack overcloud status --plan my-deploymentCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.2. Creating basic overcloud flavors Copier lienLien copié sur presse-papiers!
Validation steps in this guide assume that your installation contains flavors. If you have not already created at least one flavor, complete the following steps to create a basic set of default flavors that have a range of storage and processing capabilities:
Procedure
Source the
overcloudrcfile:source ~/overcloudrc
$ source ~/overcloudrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow Run the
openstack flavor createcommand to create a flavor. Use the following options to specify the hardware requirements for each flavor:- --disk
- Defines the hard disk space for a virtual machine volume.
- --ram
- Defines the RAM required for a virtual machine.
- --vcpus
- Defines the quantity of virtual CPUs for a virtual machine.
The following example creates the default overcloud flavors:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Use $ openstack flavor create --help to learn more about the openstack flavor create command.
11.3. Creating a default tenant network Copier lienLien copié sur presse-papiers!
The overcloud requires a default Tenant network so that virtual machines can communicate internally.
Procedure
Source the
overcloudrcfile:source ~/overcloudrc
$ source ~/overcloudrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create the default Tenant network:
(overcloud) $ openstack network create default
(overcloud) $ openstack network create defaultCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create a subnet on the network:
(overcloud) $ openstack subnet create default --network default --gateway 172.20.1.1 --subnet-range 172.20.0.0/16
(overcloud) $ openstack subnet create default --network default --gateway 172.20.1.1 --subnet-range 172.20.0.0/16Copy to Clipboard Copied! Toggle word wrap Toggle overflow Confirm the created network:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
These commands create a basic Networking service (neutron) network named default. The overcloud automatically assigns IP addresses from this network to virtual machines using an internal DHCP mechanism.
11.4. Creating a default floating IP network Copier lienLien copié sur presse-papiers!
To access your virtual machines from outside of the overcloud, you must configure an external network that provides floating IP addresses to your virtual machines.
This procedure contains two examples. Use the example that best suits your environment:
- Native VLAN (flat network)
- Non-Native VLAN (VLAN network)
Both of these examples involve creating a network with the name public. The overcloud requires this specific name for the default floating IP pool. This name is also important for the validation tests in Section 11.7, “Validating the overcloud”.
By default, Openstack Networking (neutron) maps a physical network name called datacentre to the br-ex bridge on your host nodes. You connect the public overcloud network to the physical datacentre and this provides a gateway through the br-ex bridge.
Prerequisites
- A dedicated interface or native VLAN for the floating IP network.
Procedure
Source the
overcloudrcfile:source ~/overcloudrc
$ source ~/overcloudrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create the
publicnetwork:Create a
flatnetwork for a native VLAN connection:(overcloud) $ openstack network create public --external --provider-network-type flat --provider-physical-network datacentre
(overcloud) $ openstack network create public --external --provider-network-type flat --provider-physical-network datacentreCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create a
vlannetwork for non-native VLAN connections:(overcloud) $ openstack network create public --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 201
(overcloud) $ openstack network create public --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 201Copy to Clipboard Copied! Toggle word wrap Toggle overflow Use the
--provider-segmentoption to define the VLAN that you want to use. In this example, the VLAN is201.
Create a subnet with an allocation pool for floating IP addresses. In this example, the IP range is
10.1.1.51to10.1.1.250:(overcloud) $ openstack subnet create public --network public --dhcp --allocation-pool start=10.1.1.51,end=10.1.1.250 --gateway 10.1.1.1 --subnet-range 10.1.1.0/24
(overcloud) $ openstack subnet create public --network public --dhcp --allocation-pool start=10.1.1.51,end=10.1.1.250 --gateway 10.1.1.1 --subnet-range 10.1.1.0/24Copy to Clipboard Copied! Toggle word wrap Toggle overflow Ensure that this range does not conflict with other IP addresses in your external network.
11.5. Creating a default provider network Copier lienLien copié sur presse-papiers!
A provider network is another type of external network connection that routes traffic from private tenant networks to external infrastructure network. The provider network is similar to a floating IP network but the provider network uses a logical router to connect private networks to the provider network.
This procedure contains two examples. Use the example that best suits your environment:
- Native VLAN (flat network)
- Non-Native VLAN (VLAN network)
By default, Openstack Networking (neutron) maps a physical network name called datacentre to the br-ex bridge on your host nodes. You connect the public overcloud network to the physical datacentre and this provides a gateway through the br-ex bridge.
Procedure
Source the
overcloudrcfile:source ~/overcloudrc
$ source ~/overcloudrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create the
providernetwork:Create a
flatnetwork for a native VLAN connection:(overcloud) $ openstack network create provider --external --provider-network-type flat --provider-physical-network datacentre --share
(overcloud) $ openstack network create provider --external --provider-network-type flat --provider-physical-network datacentre --shareCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create a
vlannetwork for non-native VLAN connections:(overcloud) $ openstack network create provider --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 201 --share
(overcloud) $ openstack network create provider --external --provider-network-type vlan --provider-physical-network datacentre --provider-segment 201 --shareCopy to Clipboard Copied! Toggle word wrap Toggle overflow Use the
--provider-segmentoption to define the VLAN that you want to use. In this example, the VLAN is201.
These example commands create a shared network. It is also possible to specify a tenant instead of specifying
--shareso that only the tenant has access to the new network.+ If you mark a provider network as external, only the operator may create ports on that network.
Add a subnet to the
providernetwork to provide DHCP services:(overcloud) $ openstack subnet create provider-subnet --network provider --dhcp --allocation-pool start=10.9.101.50,end=10.9.101.100 --gateway 10.9.101.254 --subnet-range 10.9.101.0/24
(overcloud) $ openstack subnet create provider-subnet --network provider --dhcp --allocation-pool start=10.9.101.50,end=10.9.101.100 --gateway 10.9.101.254 --subnet-range 10.9.101.0/24Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a router so that other networks can route traffic through the provider network:
(overcloud) $ openstack router create external
(overcloud) $ openstack router create externalCopy to Clipboard Copied! Toggle word wrap Toggle overflow Set the external gateway for the router to the
providernetwork:(overcloud) $ openstack router set --external-gateway provider external
(overcloud) $ openstack router set --external-gateway provider externalCopy to Clipboard Copied! Toggle word wrap Toggle overflow Attach other networks to this router. For example, run the following command to attach a subnet
subnet1to the router:(overcloud) $ openstack router add subnet external subnet1
(overcloud) $ openstack router add subnet external subnet1Copy to Clipboard Copied! Toggle word wrap Toggle overflow This command adds
subnet1to the routing table and allows traffic from virtual machines usingsubnet1to route to the provider network.
11.6. Creating additional bridge mappings Copier lienLien copié sur presse-papiers!
Floating IP networks can use any bridge, not just br-ex, provided that you map the additional bridge during deployment.
For example, to map a new bridge called br-floating to the floating physical network, include the NeutronBridgeMappings parameter in an environment file:
parameter_defaults: NeutronBridgeMappings: "datacentre:br-ex,floating:br-floating"
parameter_defaults:
NeutronBridgeMappings: "datacentre:br-ex,floating:br-floating"
With this method, you can create separate external networks after creating the overcloud. For example, to create a floating IP network that maps to the floating physical network, run the following commands:
source ~/overcloudrc
$ source ~/overcloudrc
(overcloud) $ openstack network create public --external --provider-physical-network floating --provider-network-type vlan --provider-segment 105
(overcloud) $ openstack subnet create public --network public --dhcp --allocation-pool start=10.1.2.51,end=10.1.2.250 --gateway 10.1.2.1 --subnet-range 10.1.2.0/24
11.7. Validating the overcloud Copier lienLien copié sur presse-papiers!
The overcloud uses the OpenStack Integration Test Suite (tempest) tool set to conduct a series of integration tests. This section contains information about preparations for running the integration tests. For full instructions about how to use the OpenStack Integration Test Suite, see the OpenStack Integration Test Suite Guide.
The Integration Test Suite requires a few post-installation steps to ensure successful tests.
Procedure
If you run this test from the undercloud, ensure that the undercloud host has access to the Internal API network on the overcloud. For example, add a temporary VLAN on the undercloud host to access the Internal API network (ID: 201) using the 172.16.0.201/24 address:
source ~/stackrc
$ source ~/stackrc (undercloud) $ sudo ovs-vsctl add-port br-ctlplane vlan201 tag=201 -- set interface vlan201 type=internal (undercloud) $ sudo ip l set dev vlan201 up; sudo ip addr add 172.16.0.201/24 dev vlan201Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Run the integration tests as described in the OpenStack Integration Test Suite Guide.
After completing the validation, remove any temporary connections to the overcloud Internal API. In this example, use the following commands to remove the previously created VLAN on the undercloud:
source ~/stackrc
$ source ~/stackrc (undercloud) $ sudo ovs-vsctl del-port vlan201Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.8. Protecting the overcloud from removal Copier lienLien copié sur presse-papiers!
Set a custom policy for heat to protect your overcloud from being deleted.
Procedure
-
Create an environment file called
prevent-stack-delete.yaml. Set the
HeatApiPoliciesparameter:Copy to Clipboard Copied! Toggle word wrap Toggle overflow ImportantThe
heat-deny-actionis a default policy that you must include in your undercloud installation.Add the
prevent-stack-delete.yamlenvironment file to thecustom_env_filesparameter in theundercloud.conffile:custom_env_files = prevent-stack-delete.yaml
custom_env_files = prevent-stack-delete.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow Run the undercloud installation command to refresh the configuration:
openstack undercloud install
$ openstack undercloud installCopy to Clipboard Copied! Toggle word wrap Toggle overflow
This environment file prevents you from deleting any stacks in the overcloud, which means you cannot perform the following functions:
- Delete the overcloud
- Remove individual Compute nor Ceph Storage nodes
- Replace Controller nodes
To enable stack deletion, remove the prevent-stack-delete.yaml file from the custom_env_files parameter and run the openstack undercloud install command.