In this tutorial, you will learn how to deploy a highly available instance pair
using VRRP. This tutorial is largely based on a blog post by Aaron O’Rosen
with modifications appropriate for the Catalyst Cloud. Networks and names have
been kept largely compatible with the source material. Additional information
about configuring allowed_address_pairs in Heat was sourced from this
post.

You will be using two different methods to set up this stack. Initially you will
use the openstack command line tool to complete the setup
manually. You will then replicate the manual configuration using a heat
template to instantiate the same stack automatically.

VRRP provides hardware redundancy and automatic failover for routers. It
allows specifying a virtual router which maps to two or more physical routers.
Individual VRRP router instances share an IP address, but at any time, only one
of the instances is the master (active); the other instances are backups and
will not respond using the virtual address. If the master fails, one of the
backups is elected as the new master and will begin to respond on the virtual
address.

Instances use priorities from 1 (lowest) to 255 (highest). Devices running
VRRP dynamically elect master and backup routers based on their respective
priorities. Only the router that is acting as the master sends out VRRP
advertisements at any given point in time. The master router sends
advertisements to backup routers at regular intervals (default is every second).
If a backup router does not receive an advertisement for a set period, the
backup router with the next highest priority takes over as master and begins
forwarding packets.

VRRP instances communicate using packets with multicast IP address 224.0.0.18
and IP protocol number 112. The protocol is defined in RFC3768.

Allowed Address Pairs is a Neutron Extension that extends the port attribute to
enable you to specify arbitrary mac_address/ip_address(cidr) pairs that are
allowed to pass through a port, regardless of the subnet associated with the
network.

Let’s double check that this extension is available on the Catalyst Cloud:

Next, set up a subnet of the network you have just created. You are going to
do this so you can use part of the vrrp-net as a dynamically assigned pool
of addresses and reserve the rest of the addresses for manual assignment. In
this case, the pool addresses are in the range 2-200, while the remainder of the
/24 will be statically assigned.

If you look at the ports created at this point using the openstackportlist-cID-c'FixedIPAddresses' command you will notice three interfaces have been created. The IP 10.0.0.1 is the gateway address while 10.0.0.2 and 10.0.0.3 provide DHCP for this network.

Note the DNS nameservers, gateway address, subnet mask and allocation pool of the subnet from the openstacksubnetcreate command.

Next you will create ports with a fixed IP for your new Keepalived instances:

The next step is to boot two instances where you will run Keepalived and Apache.
You will be using the Ubuntu 14.04 image and c1.c1r1 flavor. You will assign
these instances to the vrrp-sec-group security group. You will also provide
the name of your SSH key so you can log in to these machines via SSH once they are
created:

You will be passing a script to our instance boot command using the
--user-data flag. This script sets up Keepalived and Apache on your master
and backup instances. This saves you from having to execute these commands manually.
This script is located in the git repository you cloned previously at
Clone Orchestration Git Repository.

If you want to take a closer look at what is happening when you switch between
VRRP hosts, you need to SSH to the instances. You won’t use the floating IP
associated with your virtual router, as that will be switching between instances,
which will make our SSH client unhappy. Consequently, we will assign a floating
IP to each instance for SSH access.

At this point many people will want to clean up the OpenStack resources you have
been using in this tutorial. Running the following commands should remove all
networks, routers, ports, security groups and instances. Note that the order
in which you delete resources is important.

Up to this point in this tutorial, you have been using the Nova and Neutron
command line clients to set up our system. You have needed to run a large number
of different commands in the right order. It would be nice if you could define
the entire setup in one configuration file and ask OpenStack to create that
setup based on your blueprint.

OpenStack provides just such an orchestration system, known as Heat. In
this section, you will run Heat, in order to recreate with a single command
the stack you previously created manually.

It is beyond the scope of this tutorial to explain the syntax of writing Heat
templates, thus you will make use of a predefined example from the
cloud-orchestration repository. For more information on writing Heat templates
please consult the documentation at Orchestration.

That said, there are a number of parts of the Heat template you should have a
look at in more detail. The template is located in the
catalystcloud-orchestration repository we cloned earlier.

Note the line user_data_format:RAW in the server properties; this is
required so that cloud init will setup the ubuntu user correctly (see this
blog post for details).

The allowed_address_pairs section associates the shared VRRP address with
the instance port. You are explicitly setting the port IP address to
10.0.0.4. This is not required; you are doing it in order to stay consistent
with the manual configuration. If you do not set it, you cannot control which
IPs are assigned to instances and which are assigned for DCHP. If you don’t
set these, the assigned addresses will be inconsistent across Heat invocations.

Once all resources in your stack are in the CREATE_COMPLETE state, you are
ready to re-run the tests as described under VRRP Testing. The Neutron
floatingip-list command will give you the IP addresses and port IDs you
need:

$ openstack floating ip list

If you wish, you can SSH to the master and backup instances as described under
Instance Access.

Once satisfied with the configuration, you can clean up and get back to
your original state:

$ openstack stack delete vrrp-stack
Are you sure you want to delete this stack(s)[y/N]? y

This ends the tutorial on setting up hot swap VRRP instances in the Catalyst
Cloud.