tripleo-docs/deploy-guide/source/features/deployed_server.rst
Rajesh Tailor 6901c3aa8a Fix typos in doc pages
Change-Id: Ia68d3469318dd423ceb0843c39d3ac2734a5f264
2022-09-28 20:46:32 +05:30

698 lines
26 KiB
ReStructuredText

.. _deployed_server:
Using Already Deployed Servers
==============================
TripleO can be used with servers that have already been deployed and
provisioned with a running operating system.
In this deployment scenario, Ironic from the Undercloud is not used
to do any server deployment, installation, or power management. An external to
TripleO and already existing provisioning tool is expected to have already
installed an operating system on the servers that are intended to be used as
nodes in the Overcloud.
Additionally, Neutron can be optionally used or not.
.. note::
It's an all or nothing approach when using already deployed servers. Mixing
using deployed servers with servers provisioned with Nova and Ironic is not
currently possible.
Benefits to using this feature include not requiring a dedicated provisioning
network, and being able to use a custom partitioning scheme on the already
deployed servers.
Deployed Server Requirements
----------------------------
Networking
^^^^^^^^^^
Network interfaces
__________________
It's recommended that each server have a dedicated management NIC with
externally configured connectivity so that the servers are reachable outside of
any networking configuration done by the OpenStack deployment.
A separate interface, or set of interfaces should then be used for the
OpenStack deployment itself, configured in the typical fashion with a set of
NIC config templates during the Overcloud deployment. See
:doc:`../features/network_isolation` for more information on configuring networking.
.. note::
When configuring network isolation be sure that the configuration does not
result in a loss of network connectivity from the deployed servers to the
undercloud. The interface(s) that are being used for this connectivity should
be excluded from the NIC config templates so that the configuration does not
unintentionally drop all networking access to the deployed servers.
Undercloud
__________
Neutron in the Undercloud is not used for providing DHCP services for the
Overcloud nodes, hence a dedicated provisioning network with L2 connectivity is
not a requirement in this scenario. Neutron is however still used for IPAM for
the purposes of assigning IP addresses to the port resources created by
tripleo-heat-templates.
Network L3 connectivity is still a requirement between the Undercloud and
Overcloud nodes. The undercloud will need to be able to connect over a routable
IP to the overcloud nodes for software configuration with ansible.
Overcloud
_________
Configure the deployed servers that will be used as nodes in the overcloud with
L3 connectivity from the Undercloud as needed. The configuration could be done
via static or DHCP IP assignment.
Further networking configuration of Overcloud nodes is the same as in a typical
TripleO deployment, except for:
* Initial configuration of L3 connectivity from the undercloud to the
overcloud.
* No requirement for dedicating a separate L2 network for provisioning
Testing Connectivity
____________________
Test connectivity from the undercloud to the overcloud nodes using SSH over the configured IP
address on the deployed servers. This should be the IP address that is
configured on ``--overcloud-ssh-network`` as passed to the ``openstack overcloud
deploy`` command. The key and user to use with the test should be the same as
used with ``--overcloud-ssh-key`` and ``--overcloud-ssh-user`` with the
deployment command.
Package repositories
^^^^^^^^^^^^^^^^^^^^
The servers will need to already have the appropriately enabled yum repositories
as packages will be installed on the servers during the Overcloud deployment.
The enabling of repositories on the Overcloud nodes is the same as it is for
other areas of TripleO, such as Undercloud installation. See
:doc:`../repositories` for the detailed steps on how to
enable the standard repositories for TripleO.
Deploying the Overcloud
-----------------------
Provision networks and ports if using Neutron
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If using Neutron for resource management, Network resources for the deployment
still must be provisioned with the ``openstack overcloud network provision``
command as documented in :ref:`custom_networks`.
Port resources for the deployment still must be provisioned with the
``openstack overcloud node provision`` command as documented in
:ref:`baremetal_provision`.
Set the ``managed`` key to false in either the ``defaults`` dictionary for each
role, or on each instances dictionary in the baremetal provision configuration
file.
The generated file must then be passed to the ``openstack overcloud deploy``
command.
Deployment Command
^^^^^^^^^^^^^^^^^^
With generated baremetal and network environments
_________________________________________________
Include the generated environment files with the deployment command::
openstack overcloud deploy \
--deployed-server \
-e ~/overcloud-networks-deployed.yaml \
-e ~/overcloud-baremetal-deployed.yaml \
<other arguments>
Without generated environments (no Neutron)
___________________________________________
The following command would be used when the ``openstack overcloud network
provision`` and ``openstack overcloud node provision`` commands were not used.
Additional environment files need to be passed to the deployment command::
openstack overcloud deploy \
--deployed-server \
-e /usr/share/openstack-tripleo-heat-templates/environments/deployed-server-environment.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/deployed-networks.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/deployed-ports.yaml \
-e ~/hostnamemap.yaml \
-e ~/deployed-server-network-environment.yaml \
<other arguments>
The environment file ``deployed-server-environment.yaml`` contains the necessary
``resource_registry`` mappings to disable Nova management of overcloud servers
so that deployed servers are used instead.
``deployed-networks.yaml`` and ``deployed-ports.yaml`` enable the necessary
mappings to disable the Neutron management of network resources.
``hostnamemap.yaml`` is optional and should define the ``HostnameMap``
parameter if the actual server hostnames do not match the default role hostname
format. For example::
parameter_defaults:
HostnameMap:
overcloud-controller-0: controller-00-rack01
overcloud-controller-1: controller-01-rack02
overcloud-controller-2: controller-02-rack03
overcloud-novacompute-0: compute-00-rack01
overcloud-novacompute-1: compute-01-rack01
overcloud-novacompute-2: compute-02-rack01
``deployed-server-network-environment.yaml`` should define at a minimum the
following parameters::
NodePortMap
DeployedNetworkEnvironment
ControlPlaneVipData
VipPortMap
OVNDBsVirtualFixedIPs
RedisVirtualFixedIPs
EC2MetadataIp
ControlPlaneDefaultRoute
The following is a sample environment file that shows setting these values
.. code-block:: yaml
parameter_defaults:
NodePortMap:
controller0:
ctlplane:
ip_address: 192.168.100.2
ip_address_uri: 192.168.100.2
ip_subnet: 192.168.100.0/24
external:
ip_address: 10.0.0.10
ip_address_uri: 10.0.0.10
ip_subnet: 10.0.0.10/24
internal_api:
ip_address: 172.16.2.10
ip_address_uri: 172.16.2.10
ip_subnet: 172.16.2.10/24
management:
ip_address: 192.168.1.10
ip_address_uri: 192.168.1.10
ip_subnet: 192.168.1.10/24
storage:
ip_address: 172.16.1.10
ip_address_uri: 172.16.1.10
ip_subnet: 172.16.1.10/24
storage_mgmt:
ip_address: 172.16.3.10
ip_address_uri: 172.16.3.10
ip_subnet: 172.16.3.10/24
tenant:
ip_address: 172.16.0.10
ip_address_uri: 172.16.0.10
ip_subnet: 172.16.0.10/24
compute0:
ctlplane:
ip_address: 192.168.100.3
ip_address_uri: 192.168.100.3
ip_subnet: 192.168.100.0/24
external:
ip_address: 10.0.0.110
ip_address_uri: 10.0.0.110
ip_subnet: 10.0.0.110/24
internal_api:
ip_address: 172.16.2.110
ip_address_uri: 172.16.2.110
ip_subnet: 172.16.2.110/24
management:
ip_address: 192.168.1.110
ip_address_uri: 192.168.1.110
ip_subnet: 192.168.1.110/24
storage:
ip_address: 172.16.1.110
ip_address_uri: 172.16.1.110
ip_subnet: 172.16.1.110/24
storage_mgmt:
ip_address: 172.16.3.110
ip_address_uri: 172.16.3.110
ip_subnet: 172.16.3.110/24
tenant:
ip_address: 172.16.0.110
ip_address_uri: 172.16.0.110
ip_subnet: 172.16.0.110/24
ControlPlaneVipData:
fixed_ips:
- ip_address: 192.168.100.1
name: control_virtual_ip
network:
tags: []
subnets:
- ip_version: 4
VipPortMap:
external:
ip_address: 10.0.0.100
ip_address_uri: 10.0.0.100
ip_subnet: 10.0.0.100/24
internal_api:
ip_address: 172.16.2.100
ip_address_uri: 172.16.2.100
ip_subnet: 172.16.2.100/24
storage:
ip_address: 172.16.1.100
ip_address_uri: 172.16.1.100
ip_subnet: 172.16.1.100/24
storage_mgmt:
ip_address: 172.16.3.100
ip_address_uri: 172.16.3.100
ip_subnet: 172.16.3.100/24
RedisVirtualFixedIPs:
- ip_address: 192.168.100.10
use_neutron: false
OVNDBsVirtualFixedIPs:
- ip_address: 192.168.100.11
use_neutron: false
DeployedNetworkEnvironment:
net_attributes_map:
external:
network:
dns_domain: external.tripleodomain.
mtu: 1400
name: external
tags:
- tripleo_network_name=External
- tripleo_net_idx=0
- tripleo_vip=true
subnets:
external_subnet:
cidr: 10.0.0.0/24
dns_nameservers: []
gateway_ip: null
host_routes: []
ip_version: 4
name: external_subnet
tags:
- tripleo_vlan_id=10
internal_api:
network:
dns_domain: internalapi.tripleodomain.
mtu: 1400
name: internal_api
tags:
- tripleo_net_idx=1
- tripleo_vip=true
- tripleo_network_name=InternalApi
subnets:
internal_api_subnet:
cidr: 172.16.2.0/24
dns_nameservers: []
gateway_ip: null
host_routes: []
ip_version: 4
name: internal_api_subnet
tags:
- tripleo_vlan_id=20
management:
network:
dns_domain: management.tripleodomain.
mtu: 1400
name: management
tags:
- tripleo_net_idx=5
- tripleo_network_name=Management
subnets:
management_subnet:
cidr: 192.168.1.0/24
dns_nameservers: []
gateway_ip: 192.168.1.1
host_routes: []
ip_version: 4
name: management_subnet
tags:
- tripleo_vlan_id=60
storage:
network:
dns_domain: storage.tripleodomain.
mtu: 1400
name: storage
tags:
- tripleo_net_idx=3
- tripleo_vip=true
- tripleo_network_name=Storage
subnets:
storage_subnet:
cidr: 172.16.1.0/24
dns_nameservers: []
gateway_ip: null
host_routes: []
ip_version: 4
name: storage_subnet
tags:
- tripleo_vlan_id=30
storage_mgmt:
network:
dns_domain: storagemgmt.tripleodomain.
mtu: 1400
name: storage_mgmt
tags:
- tripleo_net_idx=4
- tripleo_vip=true
- tripleo_network_name=StorageMgmt
subnets:
storage_mgmt_subnet:
cidr: 172.16.3.0/24
dns_nameservers: []
gateway_ip: null
host_routes: []
ip_version: 4
name: storage_mgmt_subnet
tags:
- tripleo_vlan_id=40
tenant:
network:
dns_domain: tenant.tripleodomain.
mtu: 1400
name: tenant
tags:
- tripleo_net_idx=2
- tripleo_network_name=Tenant
subnets:
tenant_subnet:
cidr: 172.16.0.0/24
dns_nameservers: []
gateway_ip: null
host_routes: []
ip_version: 4
name: tenant_subnet
tags:
- tripleo_vlan_id=50
net_cidr_map:
external:
- 10.0.0.0/24
internal_api:
- 172.16.2.0/24
management:
- 192.168.1.0/24
storage:
- 172.16.1.0/24
storage_mgmt:
- 172.16.3.0/24
tenant:
- 172.16.0.0/24
net_ip_version_map:
external: 4
internal_api: 4
management: 4
storage: 4
storage_mgmt: 4
tenant: 4
.. note::
Beginning in Wallaby, the above parameter values from
``deployed-server-network-environment.yaml`` and the
``deployed-networks.yaml`` and ``deployed-ports.yaml`` environments replace the use of the
``DeployedServerPortMap`` parameter, the
``environments/deployed-server-deployed-neutron-ports.yaml`` environment, and
the ``deployed-neutron-port.yaml`` template.
The previous parameters and environments can still be used with the
exception that no resources can be mapped to any Neutron native Heat
resources (resources starting with ``OS::Neutron::*``) when using
:doc:`ephemeral Heat <../deployment/ephemeral_heat>` as there is no Heat
and Neutron API communication.
Note that the following resources may be mapped to ``OS::Neutron::*``
resources in environment files used prior to Wallaby, and these mappings
should be removed from Wallaby onward::
OS::TripleO::Network::Ports::ControlPlaneVipPort
OS::TripleO::Network::Ports::RedisVipPort
OS::TripleO::Network::Ports::OVNDBsVipPort
.. admonition:: Victoria and prior releases
The ``DeployedServerPortMap`` parameter can be used to assign fixed IP's
from either the ctlplane network or the IP address range for the
overcloud.
If the deployed servers were preconfigured with IP addresses from the ctlplane
network for the initial undercloud connectivity, then the same IP addresses can
be reused during the overcloud deployment. Add the following to a new
environment file and specify the environment file as part of the deployment
command::
resource_registry:
OS::TripleO::DeployedServer::ControlPlanePort: ../deployed-server/deployed-neutron-port.yaml
parameter_defaults:
DeployedServerPortMap:
controller0-ctlplane:
fixed_ips:
- ip_address: 192.168.24.9
subnets:
- cidr: 192.168.24.0/24
network:
tags:
- 192.168.24.0/24
compute0-ctlplane:
fixed_ips:
- ip_address: 192.168.24.8
subnets:
- cidr: 192.168.24..0/24
network:
tags:
- 192.168.24.0/24
The value of the DeployedServerPortMap variable is a map. The keys correspond
to the ``<short hostname>-ctlplane`` of the deployed servers. Specify the ip
addresses and subnet CIDR to be assigned under ``fixed_ips``.
In the case where the ctlplane is not routable from the deployed
servers, the virtual IPs on the ControlPlane, as well as the virtual IPs
for services (Redis and OVNDBs) must be statically assigned.
Use ``DeployedServerPortMap`` to assign an IP address from any CIDR::
resource_registry:
OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
OS::TripleO::Network::Ports::ControlPlaneVipPort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
# Set VIP's for redis and OVN to noop to default to the ctlplane VIP
# The ctlplane VIP is set with control_virtual_ip in
# DeployedServerPortMap below.
#
# Alternatively, these can be mapped to deployed-neutron-port.yaml as
# well and redis_virtual_ip and ovn_dbs_virtual_ip added to the
# DeployedServerPortMap value to set fixed IP's.
OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
OS::TripleO::Network::Ports::OVNDBsVipPort: /usr/share/openstack-tripleo-heat-templates/network/ports/noop.yaml
parameter_defaults:
NeutronPublicInterface: eth1
EC2MetadataIp: 192.168.100.1
ControlPlaneDefaultRoute: 192.168.100.1
DeployedServerPortMap:
control_virtual_ip:
fixed_ips:
- ip_address: 192.168.100.1
subnets:
- cidr: 192.168.100.0/24
network:
tags:
- 192.168.100.0/24
controller0-ctlplane:
fixed_ips:
- ip_address: 192.168.100.2
subnets:
- cidr: 192.168.100.0/24
network:
tags:
- 192.168.100.0/24
compute0-ctlplane:
fixed_ips:
- ip_address: 192.168.100.3
subnets:
- cidr: 192.168.100.0/24
network:
tags:
- 192.168.100.0/24
In the above example, notice how ``RedisVipPort`` and ``OVNDBsVipPort`` are
mapped to ``network/ports/noop.yaml``. This mapping is due to the fact that
these VIP IP addresses comes from the ctlplane by default, and they will use
the same VIP address that is used for ``ControlPlanePort``. Alternatively
these VIP's can be mapped to their own fixed IP's, in which case a VIP will
be created for each. In this case, the following mappings and values would be
added to the above example::
resource_registry:
OS::TripleO::Network::Ports::RedisVipPort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
OS::TripleO::Network::Ports::OVNDBsVipPort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
parameter_defaults:
DeployedServerPortMap:
redis_virtual_ip:
fixed_ips:
- ip_address: 192.168.100.10
subnets:
- cidr: 192.168.100.0/24
network:
tags:
- 192.168.100.0/24
ovn_dbs_virtual_ip:
fixed_ips:
- ip_address: 192.168.100.11
subnets:
- cidr: 192.168.100.0/24
network:
tags:
- 192.168.100.0/24
Use ``DeployedServerPortMap`` to assign an ControlPlane Virtual IP address from
any CIDR, and the ``RedisVirtualFixedIPs`` and ``OVNDBsVirtualFixedIPs``
parameters to assign the ``RedisVip`` and ``OVNDBsVip``::
resource_registry:
OS::TripleO::DeployedServer::ControlPlanePort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
OS::TripleO::Network::Ports::ControlPlaneVipPort: /usr/share/openstack-tripleo-heat-templates/deployed-server/deployed-neutron-port.yaml
parameter_defaults:
NeutronPublicInterface: eth1
EC2MetadataIp: 192.168.100.1
ControlPlaneDefaultRoute: 192.168.100.1
# Set VIP's for redis and OVN
RedisVirtualFixedIPs:
- ip_address: 192.168.100.10
use_neutron: false
OVNDBsVirtualFixedIPs:
- ip_address: 192.168.100.11
use_neutron: false
DeployedServerPortMap:
control_virtual_ip:
fixed_ips:
- ip_address: 192.168.100.1
subnets:
- cidr: 192.168.100.0/24
network:
tags:
- 192.168.100.0/24
controller0-ctlplane:
fixed_ips:
- ip_address: 192.168.100.2
subnets:
- cidr: 192.168.100.0/24
network:
tags:
- 192.168.100.0/24
compute0-ctlplane:
fixed_ips:
- ip_address: 192.168.100.3
subnets:
- cidr: 192.168.100.0/24
network:
tags:
- 192.168.100.0/24
Scaling the Overcloud
---------------------
Scaling Up
^^^^^^^^^^
When scaling out compute nodes, the steps to be completed by the
user are as follows:
#. Prepare the new deployed server(s) as shown in `Deployed Server
Requirements`_.
#. Start the scale out command. See :doc:`../post_deployment/scale_roles` for reference.
Scaling Down
^^^^^^^^^^^^
Starting in Train and onward, `openstack overcloud node delete` can take
a list of server hostnames instead of instance ids. However they can't be
mixed while running the command. Example: if you use hostnames, it would
have to be for all the nodes to delete.
.. admonition:: Victoria and prior releases
:class: victoria
The following instructions should be used when the cloud is deployed on
Victoria or a prior release.
When scaling down the Overcloud, follow the scale down instructions as normal
as shown in :doc:`../post_deployment/delete_nodes`, however use the following
command to get the uuid values to pass to `openstack overcloud node delete`
instead of using `nova list`::
openstack stack resource list overcloud -n5 --filter type=OS::TripleO::<RoleName>Server
Replace `<RoleName>` in the above command with the actual name of the role that
you are scaling down. The `stack_name` column in the command output can be used
to identify the uuid associated with each node. The `stack_name` will include
the integer value of the index of the node in the Heat resource group. For
example, in the following sample output::
$ openstack stack resource list overcloud -n5 --filter type=OS::TripleO::ComputeDeployedServerServer
+-----------------------+--------------------------------------+------------------------------------------+-----------------+----------------------+-------------------------------------------------------------+
| resource_name | physical_resource_id | resource_type | resource_status | updated_time | stack_name |
+-----------------------+--------------------------------------+------------------------------------------+-----------------+----------------------+-------------------------------------------------------------+
| ComputeDeployedServer | 66b1487c-51ee-4fd0-8d8d-26e9383207f5 | OS::TripleO::ComputeDeployedServerServer | CREATE_COMPLETE | 2017-10-31T23:45:18Z | overcloud-ComputeDeployedServer-myztzg7pn54d-0-pixawichjjl3 |
| ComputeDeployedServer | 01cf59d7-c543-4f50-95df-6562fd2ed7fb | OS::TripleO::ComputeDeployedServerServer | CREATE_COMPLETE | 2017-10-31T23:45:18Z | overcloud-ComputeDeployedServer-myztzg7pn54d-1-ooCahg1vaequ |
| ComputeDeployedServer | 278af32c-c3a4-427e-96d2-3cda7e706c50 | OS::TripleO::ComputeDeployedServerServer | CREATE_COMPLETE | 2017-10-31T23:45:18Z | overcloud-ComputeDeployedServer-myztzg7pn54d-2-xooM5jai2ees |
+-----------------------+--------------------------------------+------------------------------------------+-----------------+----------------------+-------------------------------------------------------------+
The index 0, 1, or 2 can be seen in the `stack_name` column. These indices
correspond to the order of the nodes in the Heat resource group. Pass the
corresponding uuid value from the `physical_resource_id` column to `openstack
overcloud node delete` command.
The physical deployed servers that have been removed from the deployment need
to be powered off. In a deployment not using deployed servers, this would
typically be done with Ironic. When using deployed servers, it must be done
manually, or by whatever existing power management solution is already in
place. If the nodes are not powered down, they will continue to be operational
and could remain functional as part of the deployment, since there are no steps
to unconfigure, uninstall software, or stop services on nodes when scaling
down.
Once the nodes are powered down and all needed data has been saved from the
nodes, it is recommended that they be reprovisioned back to a base operating
system configuration so that they do not unintentionally join the deployment in
the future if they are powered back on.
.. note::
Do not attempt to reuse nodes that were previously removed from the
deployment without first reprovisioning them using whatever provisioning tool
is in place.
Deleting the Overcloud
----------------------
When deleting the Overcloud, the Overcloud nodes need to be manually powered
off, otherwise, the cloud will still be active and accepting any user requests.
After archiving important data (log files, saved configurations, database
files), that needs to be saved from the deployment, it is recommended to
reprovision the nodes to a clean base operating system. The reprovision will
ensure that they do not start serving user requests, or interfere with future
deployments in the case where they are powered back on in the future.
.. note::
As with scaling down, do not attempt to reuse nodes that were previously part
of a now deleted deployment in a new deployment without first reprovisioning
them using whatever provisioning tool is in place.