Creating a Highly Available Router | User Guide

documentation.suse.com › Documentation › User Guide › Cloud Admin User Guide › Creating a Highly Available Router

Applies to HPE Helion OpenStack 8

6 Creating a Highly Available Router

6.1 CVR and DVR High Available Routers
6.2 Creating a High Availability Router
6.3 Test Router for High Availability

6.1 CVR and DVR High Available Routers #

CVR (Centralized Virtual Routing) and DVR (Distributed Virtual Routing) are two types of technologies which can be used to provide routing processes in HPE Helion OpenStack 8. You can create Highly Available (HA) versions of CVR and DVR routers by using the options in the table below when creating your router.

The neutron command for creating a router neutron router-create router_name --distributed=True|False --ha=True|False requires administrative permissions. See the example in the next section, Creating a High Availability Router.

--distributed	--ha	Router Type	Description
False	False	CVR	Centralized Virtual Router
False	True	CVRHA	Centralized Virtual Router with L3 High Availablity
True	False	DVR	Distributed Virtual Router without SNAT High Availability
True	True	DVRHA	Distributed Virtual Router with SNAT High Availability

6.2 Creating a High Availability Router #

You can create a highly available router using the neutron command line interface.

To create the HA router simply add --ha=True to the neutron router-create command. If you want to also make the router distributed, add --distributed=True. In this example, a DVR SNAT HA router is created with the name routerHA.
```
$ neutron router-create routerHA --distributed=True --ha=True
```

Set the gateway for the external network and add interface

$ neutron router-gateway-set routerHA <ext-net-id>
$ neutron router-interface-add routerHA <private_subnet_id>

Once the router is created, gateway set and interface attached, you now have a router with high availability.

6.3 Test Router for High Availability #

You can demonstrate that the router is HA by running a continuous ping from a VM instance that is running on the private network to an external server such as a public DNS. As the ping is running, list the l3 agents hosting the router and identify the agent that is responsible for hosting the active router. Induce the failover mechanism by creating a catastrophic event like shutting down node hosting the l3 agent. Once the node is shut down, you will see that the ping from the VM to the external network continues to run as the backup l3 agent takes over. To verify the agent hosting the primary router has changed, list the agents hosting the router. You will see a different agent is now hosting the active router.

Boot an instance on the private network

$ nova boot --image <image_id> --flavor <flavor_id> --nic net_id=<private_net_id> --key_name <key> VM1

Log into the VM using the ssh keys
```
ssh -i <key> <ipaddress of VM1>
```
Start a ping to X.X.X.X. While pinging, make sure there is no packet loss and leave the ping running.
```
$ ping X.X.X.X
```

Check which agent is hosting the active router

$ neutron l3-agent-list-hosting-router <router_id>

Shutdown the node hosting the agent.
Within 10 seconds, check again to see which L3 agent is hosting the active router
```
$ neutron l3-agent-list-hosting-router <router_id>
```
You will see a different agent.

Print this page