openstack/charm-deployment-guide
Code Issues Proposed changes

Add OVN sub-section to the Octavia appendix

Browse Source 
Fix up style: headings, alignment of blocks, etc.

Change-Id: Ibae6a2b54345ba913dc984c6107ee9ab790c3c60
This commit is contained in:
Frode Nordahl 2020-05-12 14:20:31 +02:00
parent 62f861541c
commit b4cec4df1b
No known key found for this signature in database
GPG Key ID: 6A5D59A3BA48373F
1 changed files with 131 additions and 105 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

236
deploy-guide/source/app-octavia.rst
View File

@ -1,8 +1,9 @@
=========================
Appendix H: Octavia LBaaS Appendix H: Octavia LBaaS
========================= =========================
Overview Overview
++++++++ --------
As of the 18.11 charm release, with OpenStack Rocky and later, OpenStack As of the 18.11 charm release, with OpenStack Rocky and later, OpenStack
Octavia can be deployed to provide Load-balancing services as part of an Octavia can be deployed to provide Load-balancing services as part of an
@ -17,63 +18,82 @@ placed haproxy instances on neutron-gateway units.
.. warning:: .. warning::
Octavia is only supported by the OpenStack Charms for OpenStack Octavia is only supported by the OpenStack Charms for OpenStack
Rocky or later. Rocky or later.
.. warning:: .. warning::
There is no automatic migration path for Neutron LBaaS There is no automatic migration path for Neutron LBaaS
haproxy-on-host configurations (as deployed under the existing haproxy-on-host configurations (as deployed under the existing
support) to Octavia Amphora configurations. New load balancers support) to Octavia Amphora configurations. New load balancers
must be created in Octavia before the octavia charm is related must be created in Octavia before the octavia charm is related
to the existing neutron-api charm. Floating IP's can then be to the existing neutron-api charm. Floating IP's can then be
moved prior to deletion of existing LBaaS based balancers. moved prior to deletion of existing LBaaS based balancers.
Deployment Deployment
++++++++++ ----------
Octavia makes use of OpenStack Barbican for storage of certificates for Octavia makes use of OpenStack Barbican for storage of certificates for
TLS termination on load balancers; Barbican makes use of Vault for secure TLS termination on load balancers; Barbican makes use of Vault for secure
storage of this data. Follow the instructions for deployment and storage of this data. Follow the instructions for deployment and
configuration of Vault in `Appendix C <./app-vault.html>`_ and then configuration of Vault in the `Vault`_ and `Certificate Lifecycle Management`_
deploy Barbican: appendices and then deploy Barbican:
.. code:: .. code-block:: none
juju deploy barbican --config openstack-origin=cloud:bionic-rocky juju deploy barbican --config openstack-origin=cloud:bionic-rocky
juju deploy barbican-vault juju deploy barbican-vault
juju add-relation barbican mysql juju add-relation barbican mysql
juju add-relation barbican rabbitmq-server juju add-relation barbican rabbitmq-server
juju add-relation barbican keystone juju add-relation barbican keystone
juju add-relation barbican barbican-vault juju add-relation barbican barbican-vault
juju add-relation barbican-vault vault juju add-relation barbican-vault vault
Octavia can then be deployed: Octavia can then be deployed:
.. code:: Neutron ML2+OVS
~~~~~~~~~~~~~~~
juju deploy octavia --config openstack-origin=cloud:bionic-rocky .. code-block:: none
juju add-relation octavia rabbitmq-server
juju add-relation octavia mysql juju deploy octavia --config openstack-origin=cloud:bionic-rocky
juju add-relation octavia keystone juju add-relation octavia rabbitmq-server
juju add-relation octavia neutron-openvswitch juju add-relation octavia mysql
juju add-relation octavia neutron-api juju add-relation octavia keystone
juju add-relation octavia neutron-openvswitch
juju add-relation octavia neutron-api
juju deploy octavia-dashboard
juju add-relation octavia-dashboard openstack-dashboard
Neutron ML2+OVN
~~~~~~~~~~~~~~~
.. code-block:: none
juju deploy octavia --config openstack-origin=cloud:bionic-ussuri
juju add-relation octavia rabbitmq-server
juju add-relation octavia mysql
juju add-relation octavia keystone
juju add-relation octavia ovn-chassis
juju add-relation octavia neutron-api
juju deploy octavia-dashboard
juju add-relation octavia-dashboard openstack-dashboard
juju deploy octavia-dashboard
juju add-relation octavia-dashboard openstack-dashboard
.. note:: .. note::
Octavia uses a Neutron network for communication between Octavia uses a Neutron network for communication between
Octavia control plane services and Octavia Amphorae; units will Octavia control plane services and Octavia Amphorae; units will
deploy into a 'blocked' state until the configuration steps deploy into a 'blocked' state until the configuration steps
are executed. are executed.
Configuration Configuration
+++++++++++++ -------------
Generate Certificates Generate Certificates
--------------------- ~~~~~~~~~~~~~~~~~~~~~
Octavia uses client certificates for authentication and security of Octavia uses client certificates for authentication and security of
communication between Amphorae (load balancers) and the Octavia communication between Amphorae (load balancers) and the Octavia
@ -84,62 +104,62 @@ as configuration.
The script below generates example certificates and keys with a 365 The script below generates example certificates and keys with a 365
day expiry period: day expiry period:
.. code:: .. code-block:: none
mkdir -p demoCA/newcerts mkdir -p demoCA/newcerts
touch demoCA/index.txt touch demoCA/index.txt
touch demoCA/index.txt.attr touch demoCA/index.txt.attr
openssl genrsa -passout pass:foobar -des3 -out issuing_ca_key.pem 2048 openssl genrsa -passout pass:foobar -des3 -out issuing_ca_key.pem 2048
openssl req -x509 -passin pass:foobar -new -nodes -key issuing_ca_key.pem \ openssl req -x509 -passin pass:foobar -new -nodes -key issuing_ca_key.pem \
-config /etc/ssl/openssl.cnf \ -config /etc/ssl/openssl.cnf \
-subj "/C=US/ST=Somestate/O=Org/CN=www.example.com" \ -subj "/C=US/ST=Somestate/O=Org/CN=www.example.com" \
-days 365 \ -days 365 \
-out issuing_ca.pem -out issuing_ca.pem
openssl genrsa -passout pass:foobar -des3 -out controller_ca_key.pem 2048 openssl genrsa -passout pass:foobar -des3 -out controller_ca_key.pem 2048
openssl req -x509 -passin pass:foobar -new -nodes \ openssl req -x509 -passin pass:foobar -new -nodes \
-key controller_ca_key.pem \ -key controller_ca_key.pem \
-config /etc/ssl/openssl.cnf \ -config /etc/ssl/openssl.cnf \
-subj "/C=US/ST=Somestate/O=Org/CN=www.example.com" \ -subj "/C=US/ST=Somestate/O=Org/CN=www.example.com" \
-days 365 \ -days 365 \
-out controller_ca.pem -out controller_ca.pem
openssl req \ openssl req \
-newkey rsa:2048 -nodes -keyout controller_key.pem \ -newkey rsa:2048 -nodes -keyout controller_key.pem \
-subj "/C=US/ST=Somestate/O=Org/CN=www.example.com" \ -subj "/C=US/ST=Somestate/O=Org/CN=www.example.com" \
-out controller.csr -out controller.csr
openssl ca -passin pass:foobar -config /etc/ssl/openssl.cnf \ openssl ca -passin pass:foobar -config /etc/ssl/openssl.cnf \
-cert controller_ca.pem -keyfile controller_ca_key.pem \ -cert controller_ca.pem -keyfile controller_ca_key.pem \
-create_serial -batch \ -create_serial -batch \
-in controller.csr -days 365 -out controller_cert.pem -in controller.csr -days 365 -out controller_cert.pem
cat controller_cert.pem controller_key.pem > controller_cert_bundle.pem cat controller_cert.pem controller_key.pem > controller_cert_bundle.pem
The generated certs and keys must then be provided to the octavia charm: The generated certs and keys must then be provided to the octavia charm:
.. code:: .. code-block:: none
juju config octavia \ juju config octavia \
lb-mgmt-issuing-cacert="$(base64 controller_ca.pem)" \ lb-mgmt-issuing-cacert="$(base64 controller_ca.pem)" \
lb-mgmt-issuing-ca-private-key="$(base64 controller_ca_key.pem)" \ lb-mgmt-issuing-ca-private-key="$(base64 controller_ca_key.pem)" \
lb-mgmt-issuing-ca-key-passphrase=foobar \ lb-mgmt-issuing-ca-key-passphrase=foobar \
lb-mgmt-controller-cacert="$(base64 controller_ca.pem)" \ lb-mgmt-controller-cacert="$(base64 controller_ca.pem)" \
lb-mgmt-controller-cert="$(base64 controller_cert_bundle.pem)" lb-mgmt-controller-cert="$(base64 controller_cert_bundle.pem)"
.. note:: .. note::
Future versions of the charm may automatically generate the internal Future versions of the charm may automatically generate the internal
Certification Authority required to operate Octavia. Certification Authority required to operate Octavia.
Resource Configuration Resource Configuration
---------------------- ~~~~~~~~~~~~~~~~~~~~~~
The charm will automatically create and maintain the resources required for The charm will automatically create and maintain the resources required for
operation of the Octavia service by running the `configure-resources` action operation of the Octavia service by running the `configure-resources` action
on the lead octavia unit: on the lead octavia unit:
.. code:: .. code-block:: none
juju run-action --wait octavia/0 configure-resources juju run-action --wait octavia/0 configure-resources
This action must be run before Octavia is fully operational. This action must be run before Octavia is fully operational.
@ -147,7 +167,7 @@ Access to the Octavia load-balancer API is guarded by policies and end users
must have specific roles to gain access to the service. The charm will request must have specific roles to gain access to the service. The charm will request
Keystone to pre-create these roles for you on deployment but you must assign the Keystone to pre-create these roles for you on deployment but you must assign the
roles to your end users as you see fit. Take a look at roles to your end users as you see fit. Take a look at
`Octavia Policies <https://docs.openstack.org/octavia/latest/configuration/policy.html>`_. `Octavia Policies`_.
The charm also allows the operator to pre-configure these resources to support The charm also allows the operator to pre-configure these resources to support
full custom configuration of the management network for Octavia. If you want full custom configuration of the management network for Octavia. If you want
@ -176,7 +196,7 @@ The UUID of the Nova flavor to use for Amphorae can be set using the
`custom-amp-flavor-id` configuration option. `custom-amp-flavor-id` configuration option.
Amphora image Amphora image
------------- ~~~~~~~~~~~~~
Octavia uses Amphorae (cloud instances running HAProxy) to provide LBaaS services; Octavia uses Amphorae (cloud instances running HAProxy) to provide LBaaS services;
an appropriate image must be uploaded to Glance with the tag `octavia-amphora`. an appropriate image must be uploaded to Glance with the tag `octavia-amphora`.
@ -190,17 +210,17 @@ image store.
Example usage: Example usage:
.. code:: .. code-block:: none
juju deploy glance-simplestreams-sync \ juju deploy glance-simplestreams-sync \
--config source=ppa:simplestreams-dev/trunk --config source=ppa:simplestreams-dev/trunk
juju deploy octavia-diskimage-retrofit \ juju deploy octavia-diskimage-retrofit \
--config amp-image-tag=octavia-amphora --config amp-image-tag=octavia-amphora
juju add-relation glance-simplestreams-sync keystone juju add-relation glance-simplestreams-sync keystone
juju add-relation glance-simplestreams-sync rabbitmq-server juju add-relation glance-simplestreams-sync rabbitmq-server
juju add-relation octavia-diskimage-retrofit glance-simplestreams-sync juju add-relation octavia-diskimage-retrofit glance-simplestreams-sync
juju add-relation octavia-diskimage-retrofit keystone juju add-relation octavia-diskimage-retrofit keystone
After the deployment has settled and ``glance-simplestreams-sync`` has After the deployment has settled and ``glance-simplestreams-sync`` has
completed its initial image sync, you may ask a ``octavia-diskimage-retrofit`` completed its initial image sync, you may ask a ``octavia-diskimage-retrofit``
@ -208,40 +228,40 @@ unit to initiate the Amphora image retrofitting process.
This is accomplished through running an action on one of the units. This is accomplished through running an action on one of the units.
.. code:: .. code-block:: none
juju run-action --wait octavia-diskimage-retrofit/leader retrofit-image juju run-action --wait octavia-diskimage-retrofit/leader retrofit-image
Octavia will use this image for all Amphora instances. Octavia will use this image for all Amphora instances.
.. warning:: .. warning::
It's important to keep the Amphora image up-to-date to ensure that It's important to keep the Amphora image up-to-date to ensure that
LBaaS services remain secure; this process is not covered in this LBaaS services remain secure; this process is not covered in this
document. document.
See the Octavia `operators maintenance <https://docs.openstack.org/octavia/latest/admin/guides/operator-maintenance.html#rotating-the-amphora-images>`_ guide for more details. See the Octavia `operators maintenance`_ guide for more details.
Usage Usage
+++++ -----
To deploy a basic HTTP load balancer using a floating IP for access: To deploy a basic HTTP load balancer using a floating IP for access:
.. code:: .. code-block:: none
lb_vip_port_id=$(openstack loadbalancer create -f value -c vip_port_id --name lb1 --vip-subnet-id private_subnet) lb_vip_port_id=$(openstack loadbalancer create -f value -c vip_port_id --name lb1 --vip-subnet-id private_subnet)
# Re-run the following until lb1 shows ACTIVE and ONLINE status': # Re-run the following until lb1 shows ACTIVE and ONLINE status':
openstack loadbalancer show lb1 openstack loadbalancer show lb1
openstack loadbalancer listener create --name listener1 --protocol HTTP --protocol-port 80 lb1 openstack loadbalancer listener create --name listener1 --protocol HTTP --protocol-port 80 lb1
openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP
openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type HTTP --url-path /healthcheck pool1 openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type HTTP --url-path /healthcheck pool1
openstack loadbalancer member create --subnet-id private_subnet --address 192.168.21.100 --protocol-port 80 pool1 openstack loadbalancer member create --subnet-id private_subnet --address 192.168.21.100 --protocol-port 80 pool1
openstack loadbalancer member create --subnet-id private_subnet --address 192.168.21.101 --protocol-port 80 pool1 openstack loadbalancer member create --subnet-id private_subnet --address 192.168.21.101 --protocol-port 80 pool1
floating_ip=$(openstack floating ip create -f value -c floating_ip_address ext_net) floating_ip=$(openstack floating ip create -f value -c floating_ip_address ext_net)
openstack floating ip set --port $lb_vip_port_id $floating_ip openstack floating ip set --port $lb_vip_port_id $floating_ip
The example above assumes: The example above assumes:
@ -256,6 +276,12 @@ The example is also most applicable in cloud deployments which use overlay
networking for project networks and floating IP's for network ingress to project networking for project networks and floating IP's for network ingress to project
networks. networks.
For more information on creating and configuring load balancing services in Octavia For more information on creating and configuring load balancing services in
please refer to the Octavia please refer to the `Octavia cookbook`_.
`Octavia cookbook <https://docs.openstack.org/octavia/latest/user/guides/basic-cookbook.html>`_.
.. LINKS
.. _Vault: app-vault
.. _Certificate Lifecycle Management: app-certificate-management
.. _Octavia Policies: https://docs.openstack.org/octavia/latest/configuration/policy.html
.. _Octavia cookbook: https://docs.openstack.org/octavia/latest/user/guides/basic-cookbook.html
.. _operators maintenance: https://docs.openstack.org/octavia/latest/admin/guides/operator-maintenance.html#rotating-the-amphora-images