openstack/openstack-manuals
Code Issues Proposed changes

Merge "[network-guide] Update L3 HA scenarios"

Browse Source
This commit is contained in:
Jenkins 2015-08-31 03:30:29 +00:00 committed by Gerrit Code Review
commit 5af0b3f444
2 changed files with 62 additions and 40 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

71
doc/networking-guide/source/scenario_l3ha_lb.rst
View File

@ -6,21 +6,23 @@ This scenario describes a high-availability implementation of the OpenStack
Networking service using the ML2 plug-in and Linux bridge. Networking service using the ML2 plug-in and Linux bridge.
This high-availability implementation augments the :doc:`scenario_legacy_lb` This high-availability implementation augments the :doc:`scenario_legacy_lb`
architecture with Virtual Router Redundancy Protocol (VRRP) to provide quick architecture with Virtual Router Redundancy Protocol (VRRP) using
failover of layer-3 services. ``keepalived`` to provide quick failover of layer-3 services. See
:ref:`scenario_l3ha_lb-packet_flow` for VRRP operation. Similar to the legacy
If the layer-3 (L3) agent on a network node fails or a network node loses scenario, all network traffic on a project network that requires routing
connectivity with a peer, the ``keepalived`` service automatically migrates actively traverses only one network node regardless of the quantity of network
routing services and active connections to another network node. Similar to nodes providing HA for the router. Therefore, this high-availability
the legacy scenario, all network traffic that requires routing relies on a implementation primarily addresses failure situations instead of bandwidth
network node. Therefore, this high-availability implementation addresses constraints that limit performance. However, it supports random distribution
failure situations rather than bandwidth constraints that limit performance. of routers on different network nodes to reduce the chances of bandwidth
Consider deploying :doc:`scenario_dvr_ovs` to increase performance in constraints and to improve scaling. Also, this implementation does not address
addition to redundancy. As of the Kilo release, you cannot combine the DVR situations where one or more layer-3 agents fail and the underlying virtual
and L3HA mechanisms. networks continue to operate normally. Consider deploying
:doc:`scenario_dvr_ovs` to increase performance in addition to redundancy. As
of the Kilo release, you cannot combine the DVR and L3HA mechanisms.
.. note:: .. note::
The migration process only retains the state of network connections for The failover process only retains the state of network connections for
instances with a floating IP address. instances with a floating IP address.
The example configuration creates one flat external network and one VXLAN The example configuration creates one flat external network and one VXLAN
@ -71,10 +73,6 @@ the tunnel network uses 10.0.1.0/24, the VRRP network uses 169.254.192.0/18,
and the external network uses 203.0.113.0/24. The VLAN network does not and the external network uses 203.0.113.0/24. The VLAN network does not
require an IP address range because it only handles layer-2 connectivity. require an IP address range because it only handles layer-2 connectivity.
.. note::
To reduce the chance of "split-brain" issues, we recommend that you
deploy an odd quantity of network nodes with a minimum of three nodes.
.. image:: figures/scenario-l3ha-hw.png .. image:: figures/scenario-l3ha-hw.png
:alt: Hardware layout :alt: Hardware layout
@ -163,11 +161,13 @@ The compute nodes contain the following network components:
.. image:: figures/scenario-l3ha-lb-compute2.png .. image:: figures/scenario-l3ha-lb-compute2.png
:alt: Compute node components - connectivity :alt: Compute node components - connectivity
.. _scenario_l3ha_lb-packet_flow:
Packet flow Packet flow
~~~~~~~~~~~ ~~~~~~~~~~~
The L3HA mechanism simply augments :doc:`scenario_legacy_lb` with quick The L3HA mechanism simply augments :doc:`scenario_legacy_lb` with quick
migration of layer-3 services to another router if the master router failover of layer-3 services to another router if the master router
fails. fails.
During normal operation, the master router periodically transmits *heartbeat* During normal operation, the master router periodically transmits *heartbeat*
@ -182,6 +182,11 @@ IP addresses on the interfaces in the ``qrouter`` namespace. In environments
with more than one backup router, the router with the next highest priority with more than one backup router, the router with the next highest priority
becomes the master router. becomes the master router.
.. note::
The L3HA mechanism uses the same priority for all routers. Therefore, VRRP
promotes the backup router with the highest IP address to the master
router.
Example configuration Example configuration
~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~
@ -215,7 +220,7 @@ Controller node
[ml2] [ml2]
type_drivers = flat,vlan,gre,vxlan type_drivers = flat,vlan,gre,vxlan
tenant_network_types = vlan,gre,vxlan tenant_network_types = vlan,gre,vxlan
mechanism_drivers = openvswitch mechanism_drivers = linuxbridge
[ml2_type_flat] [ml2_type_flat]
flat_networks = external flat_networks = external
@ -228,7 +233,7 @@ Controller node
vxlan_group = 239.1.1.1 vxlan_group = 239.1.1.1
[securitygroup] [securitygroup]
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver firewall_driver = neutron.agent.linux.iptables_firewall.IptablesFirewallDriver
enable_security_group = True enable_security_group = True
enable_ipset = True enable_ipset = True
@ -582,10 +587,9 @@ This example creates a flat external network and a VXLAN project network.
+-----------------------+--------------------------------------+ +-----------------------+--------------------------------------+
.. note:: .. note::
Default policy might prevent the ``ha`` flag from appearing The default :file:`policy.json` file allows only administrative projects
appearing in the command output. To see all fields, run the to enable/disable HA during router creation and view the ``ha`` flag
``neutron router-show demo-router`` command using the administrative for a router.
project credentials.
#. Attach the project subnet as an interface on the router: #. Attach the project subnet as an interface on the router:
@ -605,8 +609,7 @@ Verify network operation
------------------------ ------------------------
#. Source the administrative project credentials. #. Source the administrative project credentials.
#. On the controller node, verify creation of the HA ports on the #. On the controller node, verify creation of the HA network:
``demo-router`` router:
.. code-block:: console .. code-block:: console
@ -619,6 +622,22 @@ Verify network operation
| fde31a29-3e23-470d-bc9d-6218375dca4f | ext-net | 2e1d865a-ef56-41e9-aa31-63fb8a591003 203.0.113.0/24 | | fde31a29-3e23-470d-bc9d-6218375dca4f | ext-net | 2e1d865a-ef56-41e9-aa31-63fb8a591003 203.0.113.0/24 |
+--------------------------------------+----------------------------------------------------+-------------------------------------------------------+ +--------------------------------------+----------------------------------------------------+-------------------------------------------------------+
#. On the controller node, verify creation of the router on more than one
network node:
.. code-block:: console
$ neutron l3-agent-list-hosting-router demo-router
+--------------------------------------+----------+----------------+-------+----------+
| id | host | admin_state_up | alive | ha_state |
+--------------------------------------+----------+----------------+-------+----------+
| e5a4e06b-dd9d-4b97-a09a-c8ba07706753 | network1 | True | :-) | active |
| 85d5c715-08f6-425d-9efc-73633736bf06 | network2 | True | :-) | standby |
+--------------------------------------+----------+----------------+-------+----------+
.. note::
Older versions of *python-neutronclient* do not support the ``ha_state`` field.
#. On the controller node, verify creation of the HA ports on the #. On the controller node, verify creation of the HA ports on the
``demo-router`` router: ``demo-router`` router:

29
doc/networking-guide/source/scenario_l3ha_ovs.rst
View File

@ -8,16 +8,18 @@ Networking service using the ML2 plug-in and Open vSwitch (OVS).
This high-availability implementation augments the :doc:`scenario_legacy_ovs` This high-availability implementation augments the :doc:`scenario_legacy_ovs`
architecture with Virtual Router Redundancy Protocol (VRRP) using architecture with Virtual Router Redundancy Protocol (VRRP) using
``keepalived`` to provide quick failover of layer-3 services. See ``keepalived`` to provide quick failover of layer-3 services. See
:ref:`packet-flow` for VRRP operation. Similar to the legacy scenario, all :ref:`scenario_l3ha_ovs-packet_flow` for VRRP operation. Similar to the legacy
network traffic on a project network that requires routing actively traverses scenario, all network traffic on a project network that requires routing
only one network node regardless of the quantity of network nodes providing HA actively traverses only one network node regardless of the quantity of network
for the router. Therefore, this high-availabilty implementation addresses nodes providing HA for the router. Therefore, this high-availability
failure situations rather than bandwidth constraints that limit performance. implementation primarily addresses failure situations instead of bandwidth
However, it does not address situations where one or more layer-3 agents fail constraints that limit performance. However, it supports random distribution
and the underlying virtual networks continue to operate normally. Consider of routers on different network nodes to reduce the chances of bandwidth
deploying :doc:`scenario_dvr_ovs` to increase performance in addition to constraints and to improve scaling. Also, this implementation does not address
redundancy. As of the Kilo release, you cannot combine the DVR and L3HA situations where one or more layer-3 agents fail and the underlying virtual
mechanisms. networks continue to operate normally. Consider deploying
:doc:`scenario_dvr_ovs` to increase performance in addition to redundancy. As
of the Kilo release, you cannot combine the DVR and L3HA mechanisms.
.. note:: .. note::
The failover process only retains the state of network connections for The failover process only retains the state of network connections for
@ -168,13 +170,13 @@ The compute nodes contain the following components:
.. figure:: figures/scenario-l3ha-ovs-compute2.png .. figure:: figures/scenario-l3ha-ovs-compute2.png
:alt: Compute node components - connectivity :alt: Compute node components - connectivity
.. _packet-flow: .. _scenario_l3ha_ovs-packet_flow:
Packet flow Packet flow
~~~~~~~~~~~ ~~~~~~~~~~~
The L3HA mechanism simply augments :doc:`scenario_legacy_ovs` with quick The L3HA mechanism simply augments :doc:`scenario_legacy_ovs` with quick
migration of layer-3 services to another router if the master router failover of layer-3 services to another router if the master router
fails. fails.
During normal operation, the master router periodically transmits *heartbeat* During normal operation, the master router periodically transmits *heartbeat*
@ -595,7 +597,7 @@ This example creates a flat external network and a VXLAN project network.
+-----------------------+--------------------------------------+ +-----------------------+--------------------------------------+
.. note:: .. note::
The default ``policy.json`` file allows only administrative projects The default :file:`policy.json` file allows only administrative projects
to enable/disable HA during router creation and view the ``ha`` flag to enable/disable HA during router creation and view the ``ha`` flag
for a router. for a router.
@ -616,6 +618,7 @@ This example creates a flat external network and a VXLAN project network.
Verify network operation Verify network operation
------------------------ ------------------------
#. Source the administrative project credentials.
#. On the controller node, verify creation of the HA network: #. On the controller node, verify creation of the HA network:
.. code-block:: console .. code-block:: console