711 lines
27 KiB
ReStructuredText
711 lines
27 KiB
ReStructuredText
Example 3. - Advanced example using split cell controller/compute architecture and routed networks in Train release
|
||
===================================================================================================================
|
||
|
||
.. warning::
|
||
Multi cell support is only supported in Stein or later versions.
|
||
This guide addresses Train release and later!
|
||
|
||
.. contents::
|
||
:depth: 3
|
||
:backlinks: none
|
||
|
||
This guide assumes that you are ready to deploy a new overcloud, or have
|
||
already installed an overcloud (min Train release).
|
||
|
||
.. note::
|
||
|
||
Starting with CentOS 8 and TripleO Stein release, podman is the CONTAINERCLI
|
||
to be used in the following steps.
|
||
|
||
In this example we use the :doc:`deploy_cellv2_advanced` using a routed spine and
|
||
leaf networking layout to deploy an additional cell. Not all nodes need
|
||
to be co-located at the same physical location or datacenter. See
|
||
:ref:`routed_spine_leaf_network` for more details.
|
||
|
||
The nodes deployed to the control plane, which are part of the overcloud stack,
|
||
use different networks then the cell stacks which are separated in a cell
|
||
controller stack and a cell compute stack. The cell controller and cell compute
|
||
stack use the same networks,
|
||
|
||
.. note::
|
||
|
||
In this example the routing for the different VLAN subnets is done by
|
||
the undercloud, which must _NOT_ be done in a production environment
|
||
as it is a single point of failure!
|
||
|
||
Used networks
|
||
^^^^^^^^^^^^^
|
||
The following provides and overview of the used networks and subnet
|
||
details for this example:
|
||
|
||
.. code-block:: yaml
|
||
|
||
InternalApi
|
||
internal_api_subnet
|
||
vlan: 20
|
||
net: 172.16.2.0/24
|
||
route: 172.17.2.0/24 gw: 172.16.2.254
|
||
internal_api_cell1
|
||
vlan: 21
|
||
net: 172.17.2.0/24
|
||
gateway: 172.17.2.254
|
||
Storage
|
||
storage_subnet
|
||
vlan: 30
|
||
net: 172.16.1.0/24
|
||
route: 172.17.1.0/24 gw: 172.16.1.254
|
||
storage_cell1
|
||
vlan: 31
|
||
net: 172.17.1.0/24
|
||
gateway: 172.17.1.254
|
||
StorageMgmt
|
||
storage_mgmt_subnet
|
||
vlan: 40
|
||
net: 172.16.3.0/24
|
||
route: 172.17.3.0/24 gw: 172.16.3.254
|
||
storage_mgmt_cell1
|
||
vlan: 41
|
||
net: 172.17.3.0/24
|
||
gateway: 172.17.3.254
|
||
Tenant
|
||
tenant_subnet
|
||
vlan: 50
|
||
net: 172.16.0.0/24
|
||
External
|
||
external_subnet
|
||
vlan: 10
|
||
net: 10.0.0.0/24
|
||
external_cell1
|
||
vlan: 11
|
||
net: 10.0.1.0/24
|
||
gateway: 10.0.1.254
|
||
|
||
Prepare control plane for cell network routing
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
|
||
.. code-block:: bash
|
||
|
||
openstack overcloud status
|
||
+-----------+-------------------+
|
||
| Plan Name | Deployment Status |
|
||
+-----------+-------------------+
|
||
| overcloud | DEPLOY_SUCCESS |
|
||
+-----------+-------------------+
|
||
|
||
openstack server list -c Name -c Status -c Networks
|
||
+-------------------------+--------+------------------------+
|
||
| Name | Status | Networks |
|
||
+-------------------------+--------+------------------------+
|
||
| overcloud-controller-2 | ACTIVE | ctlplane=192.168.24.29 |
|
||
| overcloud-controller-0 | ACTIVE | ctlplane=192.168.24.18 |
|
||
| overcloud-controller-1 | ACTIVE | ctlplane=192.168.24.20 |
|
||
| overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.24.16 |
|
||
+-------------------------+--------+------------------------+
|
||
|
||
Overcloud stack for the control planed deployed using a `routes.yaml`
|
||
environment file to add the routing information for the new cell
|
||
subnets.
|
||
|
||
.. code-block:: yaml
|
||
|
||
parameter_defaults:
|
||
InternalApiInterfaceRoutes:
|
||
- destination: 172.17.2.0/24
|
||
nexthop: 172.16.2.254
|
||
StorageInterfaceRoutes:
|
||
- destination: 172.17.1.0/24
|
||
nexthop: 172.16.1.254
|
||
StorageMgmtInterfaceRoutes:
|
||
- destination: 172.17.3.0/24
|
||
nexthop: 172.16.3.254
|
||
|
||
Reuse networks and adding cell subnets
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
To prepare the `network_data` parameter file for the cell controller stack
|
||
the file from the control plane is used as base:
|
||
|
||
.. code-block:: bash
|
||
|
||
cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml cell1/network_data-ctrl.yaml
|
||
|
||
When deploying a cell in separate stacks it may be necessary to reuse networks,
|
||
subnets, segments, and VIP resources between stacks. Only a single Heat stack
|
||
can own a resource and be responsible for its creation and deletion, however
|
||
the resources can be reused in other stacks.
|
||
|
||
To reuse network related resources between stacks, the following parameters have
|
||
been added to the network definitions in the network_data.yaml file format:
|
||
|
||
.. code-block:: yaml
|
||
|
||
external_resource_network_id: Existing Network UUID
|
||
external_resource_subnet_id: Existing Subnet UUID
|
||
external_resource_segment_id: Existing Segment UUID
|
||
external_resource_vip_id: Existing VIP UUID
|
||
|
||
These parameters can be set on each network definition in the `network_data-ctrl.yaml`
|
||
file used for the deployment of the separate stack.
|
||
|
||
Not all networks need to be reused or shared across stacks. The `external_resource_*`
|
||
parameters can be set for only the networks that are meant to be shared, while
|
||
the other networks can be newly created and managed.
|
||
|
||
In this example we reuse all networks, except the management network as it is
|
||
not being used at all.
|
||
|
||
The resulting storage network here looks like this:
|
||
|
||
.. code-block::
|
||
|
||
- name: Storage
|
||
external_resource_network_id: 30e9d52d-1929-47ed-884b-7c6d65fa2e00
|
||
external_resource_subnet_id: 11a3777a-8c42-4314-a47f-72c86e9e6ad4
|
||
vip: true
|
||
vlan: 30
|
||
name_lower: storage
|
||
ip_subnet: '172.16.1.0/24'
|
||
allocation_pools: [{'start': '172.16.1.4', 'end': '172.16.1.250'}]
|
||
ipv6_subnet: 'fd00:fd00:fd00:3000::/64'
|
||
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:3000::10', 'end': 'fd00:fd00:fd00:3000:ffff:ffff:ffff:fffe'}]
|
||
mtu: 1500
|
||
subnets:
|
||
storage_cell1:
|
||
vlan: 31
|
||
ip_subnet: '172.17.1.0/24'
|
||
allocation_pools: [{'start': '172.17.1.10', 'end': '172.17.1.250'}]
|
||
gateway_ip: '172.17.1.254'
|
||
|
||
We added the `external_resource_network_id` and `external_resource_subnet_id` of
|
||
the control plane stack as we want to reuse those resources:
|
||
|
||
.. code-block:: bash
|
||
|
||
openstack network show storage -c id -f value
|
||
openstack subnet show storage_subnet -c id -f value
|
||
|
||
In addition a new `storage_cell1` subnet is now added to the `subnets` section
|
||
to get it created in the cell controller stack for cell1:
|
||
|
||
.. code-block::
|
||
|
||
subnets:
|
||
storage_cell1:
|
||
vlan: 31
|
||
ip_subnet: '172.17.1.0/24'
|
||
allocation_pools: [{'start': '172.17.1.10', 'end': '172.17.1.250'}]
|
||
gateway_ip: '172.17.1.254'
|
||
|
||
.. note::
|
||
|
||
In this example no Management network is used, therefore it was removed.
|
||
|
||
Full networks data example:
|
||
|
||
.. code-block::
|
||
|
||
- name: Storage
|
||
external_resource_network_id: 30e9d52d-1929-47ed-884b-7c6d65fa2e00
|
||
external_resource_subnet_id: 11a3777a-8c42-4314-a47f-72c86e9e6ad4
|
||
vip: true
|
||
vlan: 30
|
||
name_lower: storage
|
||
ip_subnet: '172.16.1.0/24'
|
||
allocation_pools: [{'start': '172.16.1.4', 'end': '172.16.1.250'}]
|
||
ipv6_subnet: 'fd00:fd00:fd00:3000::/64'
|
||
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:3000::10', 'end': 'fd00:fd00:fd00:3000:ffff:ffff:ffff:fffe'}]
|
||
mtu: 1500
|
||
subnets:
|
||
storage_cell1:
|
||
vlan: 31
|
||
ip_subnet: '172.17.1.0/24'
|
||
allocation_pools: [{'start': '172.17.1.10', 'end': '172.17.1.250'}]
|
||
gateway_ip: '172.17.1.254'
|
||
- name: StorageMgmt
|
||
name_lower: storage_mgmt
|
||
external_resource_network_id: 29e85314-2177-4cbd-aac8-6faf2a3f7031
|
||
external_resource_subnet_id: 01c0a75e-e62f-445d-97ad-b98a141d6082
|
||
vip: true
|
||
vlan: 40
|
||
ip_subnet: '172.16.3.0/24'
|
||
allocation_pools: [{'start': '172.16.3.4', 'end': '172.16.3.250'}]
|
||
ipv6_subnet: 'fd00:fd00:fd00:4000::/64'
|
||
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:4000::10', 'end': 'fd00:fd00:fd00:4000:ffff:ffff:ffff:fffe'}]
|
||
mtu: 1500
|
||
subnets:
|
||
storage_mgmt_cell1:
|
||
vlan: 41
|
||
ip_subnet: '172.17.3.0/24'
|
||
allocation_pools: [{'start': '172.17.3.10', 'end': '172.17.3.250'}]
|
||
gateway_ip: '172.17.3.254'
|
||
- name: InternalApi
|
||
name_lower: internal_api
|
||
external_resource_network_id: 5eb79743-7ff4-4f68-9904-6e9c36fbaaa6
|
||
external_resource_subnet_id: dbc24086-0aa7-421d-857d-4e3956adec10
|
||
vip: true
|
||
vlan: 20
|
||
ip_subnet: '172.16.2.0/24'
|
||
allocation_pools: [{'start': '172.16.2.4', 'end': '172.16.2.250'}]
|
||
ipv6_subnet: 'fd00:fd00:fd00:2000::/64'
|
||
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:2000::10', 'end': 'fd00:fd00:fd00:2000:ffff:ffff:ffff:fffe'}]
|
||
mtu: 1500
|
||
subnets:
|
||
internal_api_cell1:
|
||
vlan: 21
|
||
ip_subnet: '172.17.2.0/24'
|
||
allocation_pools: [{'start': '172.17.2.10', 'end': '172.17.2.250'}]
|
||
gateway_ip: '172.17.2.254'
|
||
- name: Tenant
|
||
external_resource_network_id: ee83d0fb-3bf1-47f2-a02b-ef5dc277afae
|
||
external_resource_subnet_id: 0b6030ae-8445-4480-ab17-dd4c7c8fa64b
|
||
vip: false # Tenant network does not use VIPs
|
||
name_lower: tenant
|
||
vlan: 50
|
||
ip_subnet: '172.16.0.0/24'
|
||
allocation_pools: [{'start': '172.16.0.4', 'end': '172.16.0.250'}]
|
||
ipv6_subnet: 'fd00:fd00:fd00:5000::/64'
|
||
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:5000::10', 'end': 'fd00:fd00:fd00:5000:ffff:ffff:ffff:fffe'}]
|
||
mtu: 1500
|
||
- name: External
|
||
external_resource_network_id: 89b7b481-f609-45e7-ad5e-e006553c1d3a
|
||
external_resource_subnet_id: dd84112d-2129-430c-a8c2-77d2dee05af2
|
||
vip: true
|
||
name_lower: external
|
||
vlan: 10
|
||
ip_subnet: '10.0.0.0/24'
|
||
allocation_pools: [{'start': '10.0.0.4', 'end': '10.0.0.250'}]
|
||
gateway_ip: '10.0.0.1'
|
||
ipv6_subnet: '2001:db8:fd00:1000::/64'
|
||
ipv6_allocation_pools: [{'start': '2001:db8:fd00:1000::10', 'end': '2001:db8:fd00:1000:ffff:ffff:ffff:fffe'}]
|
||
gateway_ipv6: '2001:db8:fd00:1000::1'
|
||
mtu: 1500
|
||
subnets:
|
||
external_cell1:
|
||
vlan: 11
|
||
ip_subnet: '10.0.1.0/24'
|
||
allocation_pools: [{'start': '10.0.1.10', 'end': '10.0.1.250'}]
|
||
gateway_ip: '10.0.1.254'
|
||
|
||
.. note:
|
||
|
||
When not sharing networks between stacks, each network defined in `network_data*.yaml`
|
||
must have a unique name across all deployed stacks. This requirement is necessary
|
||
since regardless of the stack, all networks are created in the same tenant in
|
||
Neutron on the undercloud.
|
||
|
||
Export EndpointMap, HostsEntry, AllNodesConfig, GlobalConfig and passwords information
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
Follow the steps as explained in :ref:`cell_export_overcloud_info` on how to
|
||
export the required data from the overcloud stack.
|
||
|
||
Cell roles
|
||
^^^^^^^^^^
|
||
Modify the cell roles file to use new subnets for `InternalApi`, `Storage`,
|
||
`StorageMgmt` and `External` for cell controller and compute:
|
||
|
||
.. code-block:: bash
|
||
|
||
openstack overcloud roles generate --roles-path \
|
||
/usr/share/openstack-tripleo-heat-templates/roles \
|
||
-o $DIR/cell_roles_data.yaml Compute CellController
|
||
|
||
For each role modify the subnets to match what got defined in the previous step
|
||
in `cell1/network_data-ctrl.yaml`:
|
||
|
||
.. code-block::
|
||
|
||
- name: Compute
|
||
description: |
|
||
Basic Compute Node role
|
||
CountDefault: 1
|
||
# Create external Neutron bridge (unset if using ML2/OVS without DVR)
|
||
tags:
|
||
- external_bridge
|
||
networks:
|
||
InternalApi:
|
||
subnet: internal_api_cell1
|
||
Tenant:
|
||
subnet: tenant_subnet
|
||
Storage:
|
||
subnet: storage_cell1
|
||
...
|
||
- name: CellController
|
||
description: |
|
||
CellController role for the nova cell_v2 controller services
|
||
CountDefault: 1
|
||
tags:
|
||
- primary
|
||
- controller
|
||
networks:
|
||
External:
|
||
subnet: external_cell1
|
||
InternalApi:
|
||
subnet: internal_api_cell1
|
||
Storage:
|
||
subnet: storage_cell1
|
||
StorageMgmt:
|
||
subnet: storage_mgmt_cell1
|
||
Tenant:
|
||
subnet: tenant_subnet
|
||
|
||
Create the cell parameter file
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
Each cell has some mandatory parameters which need to be set using an
|
||
environment file.
|
||
Add the following content into a parameter file for the cell, e.g. `cell1/cell1.yaml`:
|
||
|
||
.. code-block:: yaml
|
||
|
||
parameter_defaults:
|
||
# new CELL Parameter to reflect that this is an additional CELL
|
||
NovaAdditionalCell: True
|
||
|
||
# The DNS names for the VIPs for the cell
|
||
CloudName: cell1.ooo.test
|
||
CloudNameInternal: cell1.internalapi.ooo.test
|
||
CloudNameStorage: cell1.storage.ooo.test
|
||
CloudNameStorageManagement: cell1.storagemgmt.ooo.test
|
||
CloudNameCtlplane: cell1.ctlplane.ooo.test
|
||
|
||
# Flavors used for the cell controller and computes
|
||
OvercloudCellControllerFlavor: cellcontroller
|
||
OvercloudComputeFlavor: compute
|
||
|
||
# number of controllers/computes in the cell
|
||
CellControllerCount: 3
|
||
ComputeCount: 0
|
||
|
||
# Compute names need to be uniq, make sure to have a uniq
|
||
# hostname format for cell nodes
|
||
ComputeHostnameFormat: 'cell1-compute-%index%'
|
||
|
||
# default gateway
|
||
ControlPlaneStaticRoutes:
|
||
- ip_netmask: 0.0.0.0/0
|
||
next_hop: 192.168.24.1
|
||
default: true
|
||
DnsServers:
|
||
- x.x.x.x
|
||
|
||
Virtual IP addresses
|
||
^^^^^^^^^^^^^^^^^^^^
|
||
The cell controller is hosting VIP’s (Virtual IP addresses) and is not using
|
||
the base subnet of one or more networks, therefore additional overrides to the
|
||
`VipSubnetMap` are required to ensure VIP’s are created on the subnet associated
|
||
with the L2 network segment the controller nodes is connected to.
|
||
|
||
Add a `VipSubnetMap` to the `cell1/cell1.yaml` or a new parameter file to
|
||
point the VIPs to the correct subnet:
|
||
|
||
.. code-block:: yaml
|
||
|
||
parameter_defaults:
|
||
VipSubnetMap:
|
||
InternalApi: internal_api_cell1
|
||
Storage: storage_cell1
|
||
StorageMgmt: storage_mgmt_cell1
|
||
External: external_cell1
|
||
|
||
Create the network configuration for `cellcontroller` and add to environment file
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
Depending on the network configuration of the used hardware and network
|
||
architecture it is required to register a resource for the `CellController`
|
||
role in `cell1/cell1.yaml`.
|
||
|
||
.. code-block:: yaml
|
||
|
||
resource_registry:
|
||
OS::TripleO::CellController::Net::SoftwareConfig: cell1/single-nic-vlans/controller.yaml
|
||
OS::TripleO::Compute::Net::SoftwareConfig: cell1/single-nic-vlans/compute.yaml
|
||
|
||
.. note::
|
||
|
||
For details on network configuration consult :ref:`network_isolation` guide, chapter *Customizing the Interface Templates*.
|
||
|
||
Deploy the cell controllers
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
Create new flavor used to tag the cell controller
|
||
_________________________________________________
|
||
Follow the instructions in :ref:`cell_create_flavor_and_tag` on how to create
|
||
a new flavor and tag the cell controller.
|
||
|
||
Run cell deployment
|
||
___________________
|
||
To deploy the overcloud we can use use the same `overcloud deploy` command as
|
||
it was used to deploy the `overcloud` stack and add the created export
|
||
environment files:
|
||
|
||
.. code-block:: bash
|
||
|
||
openstack overcloud deploy \
|
||
--templates /usr/share/openstack-tripleo-heat-templates \
|
||
-e ... additional environment files used for overcloud stack, like container
|
||
prepare parameters, or other specific parameters for the cell
|
||
...
|
||
--stack cell1-ctrl \
|
||
-n $HOME/$DIR/network_data-ctrl.yaml \
|
||
-r $HOME/$DIR/cell_roles_data.yaml \
|
||
-e $HOME/$DIR/cell1-ctrl-input.yaml \
|
||
-e $HOME/$DIR/cell1.yaml
|
||
|
||
Wait for the deployment to finish:
|
||
|
||
.. code-block:: bash
|
||
|
||
openstack stack list
|
||
|
||
+--------------------------------------+------------+----------------------------------+-----------------+----------------------+----------------------+
|
||
| ID | Stack Name | Project | Stack Status | Creation Time | Updated Time |
|
||
+--------------------------------------+------------+----------------------------------+-----------------+----------------------+----------------------+
|
||
| 6403ed94-7c8f-47eb-bdb8-388a5ac7cb20 | cell1-ctrl | f7736589861c47d8bbf1ecd29f02823d | CREATE_COMPLETE | 2019-08-15T14:46:32Z | None |
|
||
| 925a2875-fbbb-41fd-bb06-bf19cded2510 | overcloud | f7736589861c47d8bbf1ecd29f02823d | UPDATE_COMPLETE | 2019-08-13T10:43:20Z | 2019-08-15T10:13:41Z |
|
||
+--------------------------------------+------------+----------------------------------+-----------------+----------------------+----------------------+
|
||
|
||
Create the cell
|
||
^^^^^^^^^^^^^^^
|
||
As in :ref:`cell_create_cell` create the cell, but we can skip the final host
|
||
discovery step as the computes are note yet deployed.
|
||
|
||
|
||
Extract deployment information from the cell controller stack
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
Follow the steps explained in :ref:`cell_export_cell_controller_info` on
|
||
how to export the required input data from the cell controller stack.
|
||
|
||
Create cell compute parameter file for additional customization
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
Create the `cell1/cell1-cmp.yaml` parameter file to overwrite settings
|
||
which are different from the cell controller stack.
|
||
|
||
.. code-block:: yaml
|
||
|
||
parameter_defaults:
|
||
# number of controllers/computes in the cell
|
||
CellControllerCount: 0
|
||
ComputeCount: 1
|
||
|
||
The above file overwrites the values from `cell1/cell1.yaml` to not deploy
|
||
a controller in the cell compute stack. Since the cell compute stack uses
|
||
the same role file the default `CellControllerCount` is 1.
|
||
|
||
Reusing networks from control plane and cell controller stack
|
||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||
For the cell compute stack we reuse the networks from the control plane
|
||
stack and the subnet from the cell controller stack. Therefore references
|
||
to the external resources for network, subnet, segment and vip are required:
|
||
|
||
.. code-block:: bash
|
||
|
||
cp cell1/network_data-ctrl.yaml cell1/network_data-cmp.yaml
|
||
|
||
The storage network definition in `cell1/network_data-cmp.yaml` looks
|
||
like this:
|
||
|
||
.. code-block::
|
||
|
||
- name: Storage
|
||
external_resource_network_id: 30e9d52d-1929-47ed-884b-7c6d65fa2e00
|
||
external_resource_subnet_id: 11a3777a-8c42-4314-a47f-72c86e9e6ad4
|
||
external_resource_vip_id: 4ed73ea9-4cf6-42c1-96a5-e32b415c738f
|
||
vip: true
|
||
vlan: 30
|
||
name_lower: storage
|
||
ip_subnet: '172.16.1.0/24'
|
||
allocation_pools: [{'start': '172.16.1.4', 'end': '172.16.1.250'}]
|
||
ipv6_subnet: 'fd00:fd00:fd00:3000::/64'
|
||
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:3000::10', 'end': 'fd00:fd00:fd00:3000:ffff:ffff:ffff:fffe'}]
|
||
mtu: 1500
|
||
subnets:
|
||
storage_cell1:
|
||
vlan: 31
|
||
ip_subnet: '172.17.1.0/24'
|
||
allocation_pools: [{'start': '172.17.1.10', 'end': '172.17.1.250'}]
|
||
gateway_ip: '172.17.1.254'
|
||
external_resource_subnet_id: 7930635d-d1d5-4699-b318-00233c73ed6b
|
||
external_resource_segment_id: 730769f8-e78f-42a3-9dd4-367a212e49ff
|
||
|
||
Previously we already added the `external_resource_network_id` and `external_resource_subnet_id`
|
||
for the network in the upper level hierarchy.
|
||
|
||
In addition we add the `external_resource_vip_id` of the VIP of the stack which
|
||
should be reused for this network (Storage).
|
||
|
||
Important is that the `external_resource_vip_id` for the InternalApi points
|
||
the the VIP of the cell controller stack!
|
||
|
||
.. code-block:: bash
|
||
|
||
openstack port show <id storage_virtual_ip overcloud stack> -c id -f value
|
||
|
||
In the `storage_cell1` subnet section we add the `external_resource_subnet_id`
|
||
and `external_resource_segment_id` of the cell controller stack:
|
||
|
||
.. code-block:: yaml
|
||
|
||
storage_cell1:
|
||
vlan: 31
|
||
ip_subnet: '172.17.1.0/24'
|
||
allocation_pools: [{'start': '172.17.1.10', 'end': '172.17.1.250'}]
|
||
gateway_ip: '172.17.1.254'
|
||
external_resource_subnet_id: 7930635d-d1d5-4699-b318-00233c73ed6b
|
||
external_resource_segment_id: 730769f8-e78f-42a3-9dd4-367a212e49ff
|
||
|
||
.. code-block:: bash
|
||
|
||
openstack subnet show storage_cell1 -c id -f value
|
||
openstack network segment show storage_storage_cell1 -c id -f value
|
||
|
||
Full networks data example for the compute stack:
|
||
|
||
.. code-block::
|
||
|
||
- name: Storage
|
||
external_resource_network_id: 30e9d52d-1929-47ed-884b-7c6d65fa2e00
|
||
external_resource_subnet_id: 11a3777a-8c42-4314-a47f-72c86e9e6ad4
|
||
external_resource_vip_id: 4ed73ea9-4cf6-42c1-96a5-e32b415c738f
|
||
vip: true
|
||
vlan: 30
|
||
name_lower: storage
|
||
ip_subnet: '172.16.1.0/24'
|
||
allocation_pools: [{'start': '172.16.1.4', 'end': '172.16.1.250'}]
|
||
ipv6_subnet: 'fd00:fd00:fd00:3000::/64'
|
||
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:3000::10', 'end': 'fd00:fd00:fd00:3000:ffff:ffff:ffff:fffe'}]
|
||
mtu: 1500
|
||
subnets:
|
||
storage_cell1:
|
||
vlan: 31
|
||
ip_subnet: '172.17.1.0/24'
|
||
allocation_pools: [{'start': '172.17.1.10', 'end': '172.17.1.250'}]
|
||
gateway_ip: '172.17.1.254'
|
||
external_resource_subnet_id: 7930635d-d1d5-4699-b318-00233c73ed6b
|
||
external_resource_segment_id: 730769f8-e78f-42a3-9dd4-367a212e49ff
|
||
- name: StorageMgmt
|
||
name_lower: storage_mgmt
|
||
external_resource_network_id: 29e85314-2177-4cbd-aac8-6faf2a3f7031
|
||
external_resource_subnet_id: 01c0a75e-e62f-445d-97ad-b98a141d6082
|
||
external_resource_segment_id: 4b4f6f83-f031-4495-84c5-7422db1729d5
|
||
vip: true
|
||
vlan: 40
|
||
ip_subnet: '172.16.3.0/24'
|
||
allocation_pools: [{'start': '172.16.3.4', 'end': '172.16.3.250'}]
|
||
ipv6_subnet: 'fd00:fd00:fd00:4000::/64'
|
||
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:4000::10', 'end': 'fd00:fd00:fd00:4000:ffff:ffff:ffff:fffe'}]
|
||
mtu: 1500
|
||
subnets:
|
||
storage_mgmt_cell1:
|
||
vlan: 41
|
||
ip_subnet: '172.17.3.0/24'
|
||
allocation_pools: [{'start': '172.17.3.10', 'end': '172.17.3.250'}]
|
||
gateway_ip: '172.17.3.254'
|
||
external_resource_subnet_id: de9233d4-53a3-485d-8433-995a9057383f
|
||
external_resource_segment_id: 2400718d-7fbd-4227-8318-245747495241
|
||
- name: InternalApi
|
||
name_lower: internal_api
|
||
external_resource_network_id: 5eb79743-7ff4-4f68-9904-6e9c36fbaaa6
|
||
external_resource_subnet_id: dbc24086-0aa7-421d-857d-4e3956adec10
|
||
external_resource_vip_id: 1a287ad7-e574-483a-8288-e7c385ee88a0
|
||
vip: true
|
||
vlan: 20
|
||
ip_subnet: '172.16.2.0/24'
|
||
allocation_pools: [{'start': '172.16.2.4', 'end': '172.16.2.250'}]
|
||
ipv6_subnet: 'fd00:fd00:fd00:2000::/64'
|
||
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:2000::10', 'end': 'fd00:fd00:fd00:2000:ffff:ffff:ffff:fffe'}]
|
||
mtu: 1500
|
||
subnets:
|
||
internal_api_cell1:
|
||
external_resource_subnet_id: 16b8cf48-6ca1-4117-ad90-3273396cb41d
|
||
external_resource_segment_id: b310daec-7811-46be-a958-a05a5b0569ef
|
||
vlan: 21
|
||
ip_subnet: '172.17.2.0/24'
|
||
allocation_pools: [{'start': '172.17.2.10', 'end': '172.17.2.250'}]
|
||
gateway_ip: '172.17.2.254'
|
||
- name: Tenant
|
||
external_resource_network_id: ee83d0fb-3bf1-47f2-a02b-ef5dc277afae
|
||
external_resource_subnet_id: 0b6030ae-8445-4480-ab17-dd4c7c8fa64b
|
||
vip: false # Tenant network does not use VIPs
|
||
name_lower: tenant
|
||
vlan: 50
|
||
ip_subnet: '172.16.0.0/24'
|
||
allocation_pools: [{'start': '172.16.0.4', 'end': '172.16.0.250'}]
|
||
ipv6_subnet: 'fd00:fd00:fd00:5000::/64'
|
||
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:5000::10', 'end': 'fd00:fd00:fd00:5000:ffff:ffff:ffff:fffe'}]
|
||
mtu: 1500
|
||
- name: External
|
||
external_resource_network_id: 89b7b481-f609-45e7-ad5e-e006553c1d3a
|
||
external_resource_subnet_id: dd84112d-2129-430c-a8c2-77d2dee05af2
|
||
external_resource_vip_id: b7a0606d-f598-4dc6-9e85-e023c64fd20b
|
||
vip: true
|
||
name_lower: external
|
||
vlan: 10
|
||
ip_subnet: '10.0.0.0/24'
|
||
allocation_pools: [{'start': '10.0.0.4', 'end': '10.0.0.250'}]
|
||
gateway_ip: '10.0.0.1'
|
||
ipv6_subnet: '2001:db8:fd00:1000::/64'
|
||
ipv6_allocation_pools: [{'start': '2001:db8:fd00:1000::10', 'end': '2001:db8:fd00:1000:ffff:ffff:ffff:fffe'}]
|
||
gateway_ipv6: '2001:db8:fd00:1000::1'
|
||
mtu: 1500
|
||
subnets:
|
||
external_cell1:
|
||
vlan: 11
|
||
ip_subnet: '10.0.1.0/24'
|
||
allocation_pools: [{'start': '10.0.1.10', 'end': '10.0.1.250'}]
|
||
gateway_ip: '10.0.1.254'
|
||
external_resource_subnet_id: 81ac9bc2-4fbe-40be-ac0e-9aa425799626
|
||
external_resource_segment_id: 8a877c1f-cb47-40dd-a906-6731f042e544
|
||
|
||
Deploy the cell computes
|
||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||
|
||
Run cell deployment
|
||
___________________
|
||
To deploy the overcloud we can use use the same `overcloud deploy` command as
|
||
it was used to deploy the `cell1-ctrl` stack and add the created export
|
||
environment files:
|
||
|
||
.. code-block:: bash
|
||
|
||
openstack overcloud deploy \
|
||
--templates /usr/share/openstack-tripleo-heat-templates \
|
||
-e ... additional environment files used for overcloud stack, like container
|
||
prepare parameters, or other specific parameters for the cell
|
||
...
|
||
--stack cell1-cmp \
|
||
-r $HOME/$DIR/cell_roles_data.yaml \
|
||
-n $HOME/$DIR/network_data-cmp.yaml \
|
||
-e $HOME/$DIR/cell1-ctrl-input.yaml \
|
||
-e $HOME/$DIR/cell1-cmp-input.yaml \
|
||
-e $HOME/$DIR/cell1.yaml \
|
||
-e $HOME/$DIR/cell1-cmp.yaml
|
||
|
||
Wait for the deployment to finish:
|
||
|
||
.. code-block:: bash
|
||
|
||
openstack stack list
|
||
+--------------------------------------+------------+----------------------------------+--------------------+----------------------+----------------------+
|
||
| ID | Stack Name | Project | Stack Status | Creation Time | Updated Time |
|
||
+--------------------------------------+------------+----------------------------------+--------------------+----------------------+----------------------+
|
||
| 12e86ea6-3725-482a-9b05-b283378dcf30 | cell1-cmp | f7736589861c47d8bbf1ecd29f02823d | CREATE_COMPLETE | 2019-08-15T15:57:19Z | None |
|
||
| 6403ed94-7c8f-47eb-bdb8-388a5ac7cb20 | cell1-ctrl | f7736589861c47d8bbf1ecd29f02823d | CREATE_COMPLETE | 2019-08-15T14:46:32Z | None |
|
||
| 925a2875-fbbb-41fd-bb06-bf19cded2510 | overcloud | f7736589861c47d8bbf1ecd29f02823d | UPDATE_COMPLETE | 2019-08-13T10:43:20Z | 2019-08-15T10:13:41Z |
|
||
+--------------------------------------+------------+----------------------------------+--------------------+----------------------+----------------------+
|
||
|
||
Perform cell host discovery
|
||
___________________________
|
||
The final step is to discover the computes deployed in the cell. Run the host discovery
|
||
as explained in :ref:`cell_host_discovery`.
|
||
|
||
Create and add the node to an Availability Zone
|
||
_______________________________________________
|
||
After a cell got provisioned, it is required to create an availability zone for the
|
||
compute stack, it is not enough to just create an availability zone for the complete
|
||
cell. In this used case we want to make sure an instance created in the compute group,
|
||
stays in it when performing a migration. Check :ref:`cell_availability_zone` on more
|
||
about how to create an availability zone and add the node.
|
||
|
||
After that the cell is deployed and can be used.
|
||
|
||
.. note::
|
||
|
||
Migrating instances between cells is not supported. To move an instance to
|
||
a different cell it needs to be re-created in the new target cell.
|