Using an Instance Host with a Services Director VA
Introduction
This section describes how to deploy Traffic Managers to an instance host from a Services Director VA.
Other form-factor configurations are supported:
- To deploy Traffic Managers to an instance host from a software form-factor Services Director, see Using an Instance Host with a Software Services Director.
- To register externally-deployed Traffic Managers, see Registering Externally-Deployed Traffic Managers.
See also Services Director Form-Factors and Working with an Instance Host.
Overview: Using an Instance Host with a Services Director VA
This section describes how to deploy Traffic Manager instances from a system that combines a Services Director VA with an instance host.
The following Services Director VA functions are known to have issues when using an instance host, see Deploying a vTM Instance:
- Deploying Traffic Managers. You must deploy from the REST API.
- Editing properties of deployed instances. Only container properties can be edited through the GUI. For all other properties, you must use the CLI or REST API.
- The vTM Instance Host page displays warning information about instance host limitations.
An instance host is an Ubuntu or RedHat / CentOS machine (virtual or physical) that is configured specifically for the purpose of allowing Services Director to deploy instances to it. Please see the release notes for details of currently supported versions. In this guide we have assumed the use of Ubuntu 14.04.
If you want an instance host that will support interaction with a software form-factor Services Director, see Using an Instance Host with a Software Services Director.
This section assumes that you have already installed and configured your Services Director VA.
To create an instance host, the required steps are:
- Create an Ubuntu 14.04 machine and its network interfaces, see Creating the Instance Host.
Ensure that an SSH Server is present on the Ubuntu 14.04 machine.
- On the Ubuntu 14.04 machine, set up the required directory structures on the Ubuntu 14.04 machine, see Preparing the Directory Structure.
- Set up local networking (interfaces/NICs and bridges) on the Ubuntu 14.04 machine, see Configuring the Local Network. Exact details will depend on your networking requirements (see example below).
- On the Ubuntu 14.04 machine, set up an LXC configuration file for each required LXC container, see Creating an LXC Container Configuration File.
- Establish SSH communications between the Services Director VA and the Ubuntu 14.04 machine, see Configuring Passwordless SSH.
- Create any required resources (feature packs and legacy FLA if required) on the Services Director VA, see Creating Required Resources.
- Create any required version resources on the Services Director VA by the upload of any required Virtual Traffic Manager (vTM) images, see Uploading a Traffic Manager Image.
- Register the instance host on the Services Director VA, see Adding the Instance Host to the Services Director VA.
For example:
Once these steps are complete the instance host is ready.
To create a vTM on the instance host, request the deployment from the Services Director REST API, see Deploying a vTM Instance. The following events then occur automatically:
- The Services Director VA contacts the instance host using SSH to request that LXC deploys a vTM on the instance host.
- The Services Director VA transfers the required vTM image file to the instance host.
- On the instance host, LXC retrieves the required LXC configuration file based on the information passed from the Services Director VA.
- On the instance host, LXC uses the LXC configuration file to create an LXC container.
- The instance host uses the required vTM image to deploy a vTM to the LXC container, and then configures its interfaces.
- The new vTM is added to the list of vTMs that are in the estate of the Services Director VA.
Once these events are complete, the first vTM is ready for use.
You can repeat this process to deploy a second (and subsequent) vTMs onto the same instance host. This is broadly similar to the first vTM. Please note that:
- This requires a different LXC configuration file.
- A second container configuration file must already exist or be created. You cannot deploy a second vTM to the same container as the first vTM.
- A vTM image file is only transferred to the instance host if the vTM image file is not already cached there.
- All other events are the same as for the first vTM.
Creating and Configuring an Instance Host
You can use an instance host (either virtual or physical) with both the software form-factor Services Director and the Services Director VA.
Creating the Instance Host
To create an instance host, you must first create an Ubuntu 14.04 machine. During this process, you will need:
- The IP address and hostname that is required for the instance host.
- The IP address for the management interface (eth0).
- Optionally, an IP address for each of the required network interfaces (eth1, eth2, and so on).
- Optionally, the IP address(es) of the DNS name server(s).
Perform the following steps:
- Create a machine to contain the Ubuntu 14.04 operating system. This machine can be either virtual or physical.
The machine's management network interface must be accessible from the Services Director
- Install the Ubuntu 14.04 operating system using the standard set-up software.
- Ensure that the Ubuntu 14.04 machine has SSH server installed and running.
- Install LXC and bridge utilities on the Ubuntu 14.04 machine to enable container deployment:
apt-get install lxc bridge-utils
Preparing the Directory Structure
You must prepare the Ubuntu 14.04 instance host directory structure to receive the required Traffic Manager files. These are required when you register the instance host on the Services Director.
- On the instance host, create a directory to place files for use. For example, for Traffic Manager image files and license files. For example:
/var/cache/ssc- Then, create a parent directory for all deployed Traffic Managers. For example:
/root/install- Check that suitable permissions are set for both of the new directories (from steps 1 and 2).
Services Director assumes that all required directories on the instance host have read/write/execute permissions for the root user / group. Check this on the instance host:
$ stat --format=%a <directory>And set if required by using:
$ chmod 770 <directory>Configuring the Local Network
Configure a virtual network on the instance host for the Traffic Manager instance. Typically, this configuration requires setting up a virtual bridge (using, for example, Linux bridge or Open vSwitch), then configuring the Linux container to attach to the bridge when running Traffic Manager.
You must disable the default bridge configured by LXC. This is unsuitable for Services Director operations.
- On the instance host, edit the /etc/network/interfaces file and configure the network interfaces and bridges as required. For example:
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address XX.XX.XX.XX
netmask YY.YY.YY.YY
network ZZ.ZZ.ZZ.ZZ
broadcast AA.AA.AA.AA
gateway BB.BB.BB.BB
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers DD.DD.DD.DD
dns-search cam.demo.com
# The primary bridge
auto br0
iface br0 inet static
bridge_ports eth1
bridge_fd 0
address EE.EE.EE.EE
netmask FF.FF.FF.FF
network GG.GG.GG.GG
# The secondary network interface
auto eth1
iface eth1 inet static
address 0.0.0.0In this example, there is a Linux bridge setup to which LXC containers can attach virtual network interfaces.
- You must now disable the LXC default bridge. Edit the /etc/default/lxc-net file and set the following:
USE_LXC_BRIDGE="false"Also comment out any other lines that contain 'LXC_*='.
- You must now turn off strict return path filtering. Edit the /etc/sysctl.conf file:
net.ipv4.conf.default.rp_filter=2
net.ipv4.conf.all.rp_filter=2- Either reboot, or restart the networking services. This ensures that the networking configuration is correct and the default LXC bridge is removed.
Creating an LXC Container Configuration File
Traffic Manager instances can cohabit on an instance host using LXC containers.
LXC containers support network isolation and a degree of resource isolation. The software form-factor Services Director expects prepared container configuration files in advance of instance deployment. You must put these files in the installation root directory of the instance host.
Before you create an LXC container for a Traffic Manager, you must create an LXC configuration file. This file describes the properties for the container.
- On the instance host, create an LXC configuration text file.
This must be located in the parent directory for installations (see Preparing the Directory Structure). For example, in the /root/install directory.
The container configuration file must include networking entries for your Traffic Manager instance IP address. You can use either Linux virtual networking or Open vSwitch to set up network isolation for your Traffic Manager instance.
The filename of the container configuration file must match the FQDN or IP address of the required container. That is: <container-fqdn-or-ip>.conf.
This filename must be specified as the container_name property when you deploy the instance.
For Instance resources that are not able to use the Universal FLA License, <container-fqdn-or-ip>.conf must match the value of the lxc.utsname used in the file, and the management_address specified in the REST request.
- Create contents for the LXC container configuration file. For example:
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.ipv4 = XX.XX.XX.XX/SS
lxc.network.ipv4.gateway = YY.YY.YY.YY
lxc.utsname = vtm-mgmt.example.comIn this example:
- XX.XX.XX.XX/SS is the IP address and subnet mask of the LXC container network.
- YY.YY.YY.YY is the IP address of the subnetwork gateway inside the LXC container.
- If the Legacy FLA License is in use for this instance, the filename of the container configuration file must be vtm-mgmt.example.com.conf.
Creating Required Resources
You must create the following resources using the Services Director VA.
- Feature Packs, see Creating a Feature Pack Resource.
- Legacy FLA licenses (where required), see Creating a Legacy FLA Resource.
- vTM Clusters, see Creating a vTM Cluster.
A Version resource is also required, but that is created when you upload a Traffic Manager image to the Services Director VA, see Uploading a Traffic Manager Image.
Creating a Feature Pack Resource
Before you register a Traffic Manager, you must define a Feature Pack for the Traffic Manager.
When you install a primary Services Director VA, you provide a software license. This license is based on a single Stock-Keeping Unit (SKU).
Your choice of SKU determines whether you are a Cloud Service Provider (CSP) or Enterprise customer. It also defines the features that are available on your Services Director VA.
A SKU is used when you create a Feature Pack. Each Feature Pack is a subset (or total set) of the available features in a SKU.
To create a Feature Pack, you must select your SKU (historical SKUs that are still supported are also listed) and then identify any features from your SKU that are excluded in your Feature Pack. All other features supported by your SKU are included in the Feature Pack.
When you register a Traffic Manager, you select a single Feature Pack.
A default Feature Pack (typically a SKU with no exclusions) is created automatically when you install the Services Director VA.
- Access your Services Director VA from a browser, using its Service Endpoint IP Address.
- Log in as the administration user. The Home page appears.
- Click the Catalogs menu, and then click SKUS and Feature Packs.
The SKUS and Feature Packs page appears.
- In the table of SKUs, locate the SKU from which you wish to create a Feature Pack.
- Expand this SKU to view its supported features. For example, the STM-400 SKU:
- Locate the function(s) that you wish to exclude, and make a note of the feature name. For example, the Lbrnd (Random Load Balancing) feature. That is, this Feature Pack will not support the Random load balancing feature. Other load balancing features, such as Round Robin, will still be supported.
- Collapse the SKU in the table.
- Click the Add button.
The Add Feature Pack dialog appears.
- Enter a Feature Pack Name.
This name will appear in the table of Feature Packs.
- Select the required feature tier from your SKU.
- Enter a space-separated list of excluded features.
- Select any required add-on SKUs.
- Enter a description for the Feature pack as Info.
This description will appear in the table of Feature Packs.
- Click Add. The new Feature Pack is added to the table of Feature Packs.
- Expand the Feature Pack to view its full details.
- Repeat this process to create all required Feature Packs.
Once you have created all required Feature Packs, you can use these to register and deploy Traffic Managers.
Creating a Legacy FLA Resource
The Services Director comes with a pre-installed Universal FLA License. This is suitable for any Traffic Manager at version 10.1 with an active REST API. In all other cases, a Legacy FLA License is required. That is:
- The Traffic Manager version is 10.0 or earlier.
- The Traffic Manager (any version) has its REST API disabled.
You can install a Legacy FLA License using the Services Director VA, after which you can install either of these Traffic Manager types.
- Access your Services Director VA from a browser, using its Service Endpoint IP Address.
- Log in as the administration user. The Home page appears.
- Click the Catalogs menu, and then click Licensing: FLA Licenses. The Flexible Licenses page appears.
When the Services Director is first installed, only the pre-installed Universal FLA License is shown on this page; no Legacy FLA Licenses are present.
- Click the Add License plus symbol.
The Add FLA License dialog appears.
- Either:
- Paste the text of the Legacy FLA License into the text box, OR
- Click Populate from File, select the file and then click Upload. This will populate the text box.
The remainder of the fields in the dialog will then update to provide license information:
- Click Add. A relicensing dialog appears.
- Click Later.
The new license is added to the FLA Licenses page.
- Repeat this procedure if you require additional licenses.
- Both Legacy FLA Licenses and Universal FLA Licenses have a default FLA. If you have more than one FLA license for either type, and want to make it the default license for that type, click Make Default.
Creating a vTM Cluster
There are two types of clusters used by the Services Director VA:
- Discovered - this is a cluster present on one or more externally-deployed Traffic Managers. When an externally-deployed Traffic Manager is registered, a cluster name is displayed automatically. See the Services Director Getting Started Guide for details.
This cluster type cannot be used by Traffic Managers that you deploy from the Services Director VA.
You cannot create a Discovered cluster from the vTM Clusters page.
Services Director’s awareness of Discovered clusters is limited to Traffic Managers at version 10.2 or above with an enabled REST API.
- User Created - this is a cluster that you create manually on the vTM Clusters page, see Creating a vTM Cluster for Deployed vTM Instances. This cluster type can only be used for Traffic Managers that you deploy from the Services Director VA.
You must select a cluster when you deploy a Traffic Manager if you want to use cluster-level backup and restore. See the Services Director Getting Started Guide for full details.
Services Director supports backup and restore for cluster configurations.
Viewing vTM Clusters
The vTM Cluster page displays a list of all clusters known to the Services Director VA.
The vTM Cluster page also enables you to assign a backup schedule to each cluster, and to inspect the details of the cluster backups taken. See the Services Director Getting Started Guide.
Creating a vTM Cluster for Deployed vTM Instances
- Start your Services Director VA from a browser, accessing it using its Service Endpoint IP Address.
- Log in as the administration user. The Home page appears.
- Click the Services menu, and then click Services Director: vTM Clusters. The vTM Clusters page appears.
- Click the Add button above the cluster table. The Add vTM Cluster dialog appears.
- Provide a vTM Cluster Name. This will be available as the vTM Cluster ID when you deploy a Traffic Manager. This name must be unique within the current subnet.
- Enter an Owner.
- (Optional) Specify an Analytics Profile for the cluster. See the Services Director Getting Started Guide for full details.
- (Optional) Specify a Backup Schedule. See the Services Director Getting Started Guide for full details.
- Click Add. The new User Created cluster is added.
- Repeat for any other required vTM clusters.
All User Created clusters are available for use as the vTM Cluster ID when you deploy a Traffic Manager. See Deploying a vTM Instance using the Services Director VA GUI.
Uploading a Traffic Manager Image
Before you can deploy a Traffic Manager, you must upload the required Traffic Manager image onto the Services Director VA. During this process, you also specify the required version resource for the image.
The Traffic Manager image files are not replicated automatically between the Services Director nodes. You must manually transfer the files into both nodes.
- Access your Services Director VA from a browser, using its Service Endpoint IP Address.
- Log in as the administration user. The Home page appears.
- Access the vTM Images page from the menus using System > Deployment > vTM Images.
- Click the plus symbol above the table of images. The Add Traffic Manager Version dialog appears.
- Click From file and then Choose File. Then, select the required local Traffic Manager image file. This is in TGZ format.
- Specify the required Version Name. Typically, this is the version number, for example 11.0.
- Optionally, complete the Info property.
- Click Apply.
The image file is uploaded to the Services Director VA. When complete, it is displayed in the vTM Images page. This may take several minutes.
Configuring Passwordless SSH
The Services Director VA uses passwordless SSH to communicate with any instance hosts. Passwordless SSH enables the Services Director VA to copy files and remotely run commands to deploy, start, stop, upgrade, and delete Traffic Manager instances.
Each Services Director VA in an HA pair has its own unique SSH authentication key pair. When you add a new instance host to the Services Director VA, you must set up passwordless SSH between each Services Director VA and the new instance host.
The following is a general procedure for configuring the establishing passwordless SSH between the Services Director VA and an instance host.
- Once your VA is configured, licensed, and running, SSH into the VA as admin, and generate the SSH key pair that will be used for passwordless SSH access to the instance host:
> enable
# configure terminal
# ssh client generate identity user root
# show ssh client private- Copy the listed public key and paste it into the /root/.ssh/authorized_keys file on the instance host.
- Test the password-less connection from the Services Director VA:
ssh slogin root@<instance host>Adding the Instance Host to the Services Director VA
Perform the following procedure to add the instance host to the Services Director VA.
- Log into the Services Director VA.
- Access the vTM Instance Hosts page from the menus using System > Deployment > vTM Instance Hosts.
- Click the plus sign above the table of instance hosts. The Add vTM Instance Host dialog appears.
- On the Add vTM Instance Host dialog, specify the Instance Host Name. This is either a hostname or an IP address.
- Specify the administrative Username for the instance host.
- (Optional) Specify Info to provide a description for the instance host.
- Click Add to add the instance host. The instance host is added to the vTM Instance Hosts page
- To test the registered Host, make a REST request to:
https://<Services Director>:8100/api/tmcm/2.9/host/<hostname>?status_check=trueThe response will include a status_check property that will be an empty object if the Host is correctly configured for deployments.
If not, status_check will have a further setup_errors property describing the problems found with the Host.
Deploying a vTM Instance
Once you have registered an instance host on the Services Director VA, you can deploy vTM instances on the instance host.
The default method for deploying a vTM instance to an instance host is by using the Services Director VA GUI, see Deploying a vTM Instance using the Services Director VA GUI.
However, you can use the REST API to do this if required, see Deploying a vTM Instance Using the REST API.
Deploying a vTM Instance using the Services Director VA GUI
To deploy a vTM instance on a registered instance host, perform the following procedure:
- Before starting the VA GUI, create a container configuration file on the instance host(?). This must be in the/root/install directory, with filename:
<container-fqdn-or-ip>.conf.The <container-fqdn-or-ip> element of the filename must be used as the Container Name property of the Instance resource in a later step.
For vTM instances that will not be able to use the Universal FLA License, the hostname/IP part of the container configuration filename must match the value of the lxc.utsname property in the file and the Management Address of the Instance resource.
- Create the contents of the container configuration file. For example:
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.ipv4 = XX.XX.XX.XX/XX
lxc.network.ipv4.gateway = YY.YY.YY.YY
lxc.utsname = djones-04.cam.demo.com- Access your Services Director VA from a browser, using its Service Endpoint IP Address.
- Log in as the administration user. The Home page appears.
- Click the Services menu, and then click Services Controller: vTM Instances. The vTM Instances page appears.
- Click the plus symbol above the table. The Add a vTM instance dialog box appears:
- Click Deploy an instance to a container, and then click Next.
The Add Managed vTM Instance dialog appears.
- Select an instance host from the Instance Host Name list.
- Specify an Instance Name for the new instance.
- Specify a Bandwidth for the vTM instance.
- (Optional) Specify the CPU Usage for the vTM instance.
- Select an Owner for the vTM instance.
- Select an License Name for the vTM instance.
- Select an Feature Pack for the vTM instance.
- Select an vTM Version for the vTM instance.
- (Optional) In the Advanced Options:
- Select a vTM Cluster ID if required. This must be a User Created vTM Cluster, which are visible on the vTM Clusters page, see Viewing vTM Clusters.
- Select Extra Options as required. These are described under the config_options property in Properties for a Deployed Instance.
- Select Skip FLA Check if required, see Checking the Health of an FLA License Automatically.
- Specify a Container Name for the new instance. This must be the <container-fqdn-or-ip> element of the configuration file name from step 1.
- Specify the Management Address for the new instance.
- Click Add.
It may take a long time to perform the first deployment, as the vTM image needs to be copied to the instance host, extracted from its TAR file, and installed.
Once complete, the instance appears in the vTM Instances page of the VA GUI.
The Instance Type is correctly described as Container, but the container properties may be undefined.
The Instance Lifecycle, Instance Health and Licensing Health columns on the vTM Instances page will operate as expected. Similarly, monitoring and metering function correctly with vTM instances that are deployed on instance hosts.
The Extra Options property is for optional advanced configuration options. These are described under the config_options property in Properties for a Deployed Instance.
Any attempt to perform non-container updates will throw the error 'Failed to update Instance (Unknown container flavor ())'. Instead, use the REST API or CLI for any required property updates.
Any attempt to perform container property updates through the CLI will fail.
Deploying a vTM Instance Using the REST API
The default method for deploying a vTM instance to an instance host is by using the Services Director VA GUI, see Deploying a vTM Instance using the Services Director VA GUI.
However, you can use the REST API to do this if required.
You cannot use the VA CLI to deploy a containerised vTM instance to an instance host.
Non-containerised Instances that are deployed via the REST API will show as having an Instance Type of 'Externally Deployed' in the Services Director UI.
The following worked example uses the two-NIC example host configuration from above, to deploy a simple containerised Instance:
- Create a container configuration file, in the/root/install directory, with filename:
<container-fqdn-or-ip>.conf.This filename must be the value specified for the container_name property of the Instance resource. For Instance resources that will not be able to use the Universal FLA License, the hostname/IP part of the container configuration filename must match the value of the lxc.utsname used in the file and the management_address specified in the REST request (see the example below).
- Create contents for the container configuration file. For example:
lxc.network.type = veth
lxc.network.flags = up
lxc.network.link = br0
lxc.network.ipv4 = XX.XX.XX.XX/XX
lxc.network.ipv4.gateway = YY.YY.YY.YY
lxc.utsname = djones-04.cam.demo.com- Use an HTTP client (for example, POSTMAN) to PUT the Instance resource:
$ curl -k -u admin:password https://djones-02.cam.demo.com:8100/api/tmcm/2.9/instance/r04-conf -X PUT -H "Content-type: application/json"
-d '{"management_address": "djones-06.cam.demo.com", "container_name": "djones-04.cam.demo.com", "owner": "me", "bandwidth": 100,
"stm_feature_pack": "STM-400_full", "stm_version": "17.1", "host_name": "djones-06.cam.demo.com", "cpu_usage": "0"}'It may take a long time to perform the first deployment, as the vTM Image needs to be copied to the Host, un-tarred, and installed.
Once complete, the instance appears in the vTM Instances page of the VA GUI.
The Instance Type is correctly described as Container, but the container properties may be undefined.
The Instance Lifecycle, Instance Health and Licensing Health columns on the vTM Instances page will operate as expected. Similarly, monitoring and metering function correctly with vTM instances that are deployed on instance hosts.
The Extra Options property is for optional advanced configuration options. These are described under the config_options property in Properties for a Deployed Instance.
Any attempt to perform non-container updates will throw the error 'Failed to update Instance (Unknown container flavor ())'. Instead, use the REST API or CLI for any required property updates.
Any attempt to perform container property updates through the CLI will fail.