You are here

CC-Cloud

The Compute Canada Cloud is an OpenStack, Infrastructure-as-a-Service (IAAS) cloud.  OpenStack provides the ability for a user to create virtual machines (VMs) and virtual networks from the pool of physical resources (processing, storage and networking).

Cloud-West at the University of Victoria is a component of the Compute Canada Cloud. 

Users should at a minimum have basic linux systems administrator skills, and be familiar with installing and configuring an operating system and requisite applications and software. Anything beyond a very simple single VM will also require familiarity with basic network administration.

Users are responsible for the behaviour of their VMs and networks. This includes the provision of suitable firewalls and security configurations, and system patching when vulnerabilities are reported.

Please refer to the Compute Canada Cloud Quick Start Guide for more information on getting started with the CC-Cloud.

Please email cloud@computecanada.ca to request an account.

To access the CC-Cloud West use a web browser and go to https://west.cloud.computecanada.ca. Then login using your Compute Canada (CCDB) username and password. If you receive an access denied message please send an email to cloud@computecanada.ca

Please refer to the Compute Canada Cloud Quick Start Guide for more information on getting started with the CC-Cloud.

The following guide will step users through the basics of OpenStack using the web interface (Horizon) and command line interface.

Command Line Tools

The command line tools provide access to all the OpenStack functionality. The web interface does not currently support all functionality so it is useful to familiarize yourself with both interfaces. Most operating systems will provide packages for the command line tools.  For more information please see http://docs.openstack.org/user-guide/content/install_clients.html.

Once the CLI tools are installed you need to setup some environment variables to access OpenStack. The best approach for this is to create a file you can source before accessing Nefos, for example open a file named nefos.rc. The file should contain the following, substituting "WGUSERNAME" and "WGTENANT" with your credentials:

export OS_USERNAME=WGUSERNAME        # your WestGrid username
export OS_TENANT_NAME=WGTENANT       # your tenant name (see below)
export OS_AUTH_URL=https://nefos.westgrid.ca:35357/v2.0
export OS_REGION_NAME=regionOne
export OS_VOLUME_API_VERSION=2
# With Keystone you pass the keystone password.
echo "Please enter your OpenStack Password: "
read -sr OS_PASSWORD_INPUT
export OS_PASSWORD=$OS_PASSWORD_INPUT

This script will prompt for the password each time it is sourced.  Alternatively you could enter the password into this file. If you decide to enter the password into this file make sure it is chmod 600 and that access to a desktop session with access to this file is protected by a password. If you do not know the name of your Tenant, login to the Horizon Dashboard and you will see a drop down menu at the top middle of the page with the Tenants/Projects you have access to. (See figure below)

An alternative way to create the nefos.rc file is to login to the Horizon dashboard and select the Access & Security menu item under the Compute menu. Click on the API Access tab and click the Download OpenStack RC file, as shown below:

 

To access the Nefos cloud using the command line source your nefos.rc  file and try the commands shown in the documentation below.

Networking

Once successfully logged into the web interface you will have an empty tenant/project. For testing purposes each user will have their own tenant as this will allow users to do their own testing without harming other users. The first step is to create the networking for the VM instances to use. Nefos uses software defined networking implemented with VXLAN for its networking. Using SDN allows users to create networks that suit their needs without the need for System or Network Administrator intervention. Users can create multiple networks if required and is limited through the quota for each tenant. If the VM instances require access to external resources then the network will require a Public IP address for NAT.  If you are testing multiple networks, each one may consume a public IP address, which are currently in limited supply. The network range used for the NAT/Gateway IP's is the same range used for floating IP's that get assigned to VM instances.

To create a network, click on the Network menu on the left hand side of the page and select Networks. On the top right hand side click on the + Create Network button, shown below:

This will bring up the Create Network dialogue. Give the network a meaningful name.

Click next to define the subnet. Give the subnet a meaningful name and define the Network Address range required for this network. The ranges defined should be in the Private IP space and need to be large enough to allocate to all the instances you intend to boot at any given time. For example if you have an allocation of 600 cores and plan to boot 2 core VM's you will need at least a /23 which will provide 510 IP addresses. In most cases a /24 would likely be sufficient. Select IPv4 as the IP Version. The Gateway IP defaults to the first address in the range, if you want to define something different, then enter the IP in the box otherwise you can leave it blank. If a Gateway IP is not required (VM instances do not need access to the outside world) select the Disable Gateway check box. Below is an example configuration:

Finally, complete the Subnet Detail configuration by defining the DHCP Allocation Pools, DNS servers and Host Routes. If hosts will be using DHCP to get their IP address assigned for this network then click the Enable DHCP box. In the Allocation Pools define start and end IP's that can be assigned by DHCP separated with a ','. You can have multiple start/end ranges within your subnet, each one is on a separate line. Next define the DNS Servers you wish to use for this network. The Nefos network has access to use the UVic DNS servers (142.104.6.1, 142.104.80.2) so they are listed here, you may wish to use the DNS servers provided by your institution, but make sure they provide access from off-site or once your public IP Address has been assigned you can allow access from a single IP. Host Routes are used to provide additional routes for VM Instances, this would only be required for a complex SDN setup. Finally, click the Create button to complete this step. Below is an example Subnet Detail configuration:

 

Now that the network has been created a Router will need to be defined if the network requires public access. Click on the + Create Router button and choose a meaningful name for the Router Name. For this example the router name is test-router.

Now that a router has been defined a gateway IP address needs to be set. Click on the Set Gateway button to bring up the Set Gateway dialogue. 

 Choose VLAN3337 from the External Network drop down menu and click the Set Gateway button.

 The previous step defined the public gateway IP address, now the internal gateway IP address needs to be defined. Click on the router defined previously as shown below:

Next, Click on the + Add Interface button.

This will bring up the Add Interface dialogue. Select the subnet that was defined previously and then enter the Gateway IP address that was defined for the subnet or you can leave this blank as the default value will be the IP address of the gateway as shown by the description in the dialogue box below. Finally click on the Add Interface button to complete the network setup.

To get a visual representation of the configured network, click on the Network Topology menu item on the left hand side of the page. An image similar to the figure below should be presented:

 

Images

Before a VM instance can be booted an image needs to be uploaded into OpenStack. To upload an image, click on the Images menu on the left hand side of the page and then click on the + Create Image button as shown below:

This will bring up the Create an Image dialogue. Give the Image a meaningful name and description. The Image Source can be a URL or a local file. In the example below an image is uploaded from a URL. The Format for the image will depend on the image source and the most popular is qcow2. The Architecture is optional but should be filled out as some software may require a specific architecture, some examples are x86 for 32-bit or x86_64 for 64-bit. The Minimum Disk requirements are useful to fill out for VM's that require more disk space then the m1.tiny flavor as it will avoid errors caused when booting an image that requires more disk space. Users will receive an error that is not descriptive of the problem (Error: no valid host was found). Specify the Minimum Ram if there is one for this image. Finally select the Public box if the image should be accessible by all users and select Protected if you do not want your image to be deleted by non-admin users. Finally click on Create Image.

Access & Security

Before booting a VM instance for the first time, an SSH Key pair should be created/added as well as some Security Groups (ACL rules) to allow SSH access from a remote IP address.  Click on the Access & Security menu and then click on the Key Pairs tab. There are 2 options for adding a key pair, creating a new key pair via the + Create Key Pair button or if there is an existing SSH key pair which will be used, select the Import Key Pair and paste the contents of the public key. Give the key pair a meaningful name as it can help identify who has launched a VM.

Next, click on the Security Groups tab to allow SSH access from a remote IP address. There are 2 options, edit the default rules or create a new security group. That choice is left up to the user, but the default rule set will be applied to a VM instance by default so there is one less step to do when launching a VM. For managing several VM’s the best approach will be to add all global rules to default set and then create host specific rules in a separate group and only associate the added security group to those hosts that require them.

For this example, edit the default rule set by clicking on the Manage Rules button. Next, click on the + Add Rule button. This will bring up the Add Rule dialogue box, which provides several default rules to choose from. This example is allowing SSH access, so select the SSH rule from the drop down list and leave the Remote as CIDR (Classless Inter-Domain Routing). Next enter the remote IP address block that requires SSH access to the VM instances. The example below uses the VLAN for the Hermes/Nestor interactive nodes.

Instances

To startup a VM, click on the Instances menu option under the Compute menu. Next click on the + Launch Instance button on the top right of the page to bring up the Launch Instance dialogue.

The Launch Instance dialogue allows the user to select various attributes about the VM that will be launched. Nefos currently has a single Availability Zone so that can be left at nova. Give the image a meaningful Instance Name. This is the name that will be assigned to the VM through cloud-init as well as the name of the image shown in the Instances menu. The Flavor of the image will depend on the requirements of the software running on the VM, keep in mind some images require a minimum disk space and will not boot with the m1.tiny flavor. The Instance Count allows for multiple VM’s to be launched at the same time. The Image Name will be appended with the UUID of the image to distinguish each instance. The Instance Boot Source has several options, these are Boot from image, Boot from snapshot, Boot form volume, Boot from image (creates a new volume) and Boot from volume snapshot (create new volume).  For ephemeral jobs Boot from image will be the most likely candidate and any changes to the image will be lost once the VM has been terminated. If this is a persistent image then Boot from image (creates a new volume) or Boot from volume will be the best choices. Images are ephemeral and will be stored locally on the hypervisors disk drives. Each hypervisor has 3 x 600GB SAS drives for a total of ~1.6TB. Booting Volumes is done directly from Ceph and will have greater IO and storage capacity and will generally be used for persistent instances and data. In the example below an Instance is launched using Boot from image and then uses the Test Image that was uploaded previously. By default OpenStack will associate the key pair, default Security Group and the network that was defined previously. If there is more than one choice of network or key pair in the Tenant/Project then it will need to be selected manually by clicking on the appropriate tab. Finally, click on the Launch button as shown below to boot the VM.

After a few seconds the instance should change from Build to Active and then VM should begin booting. To watch the boot progress, click on the Instance Name and then click on the Log tab for a text snapshot of the boot process or the Console tab for a real-time graphical console. Once the VM instance has finished booting, Associate a floating IP address so external SSH access can be tested. 

Finally, click on the Associate button to assign the selected IP address to the VM instance. The Instance will now have 2 IP addresses associated with it, a private VXLAN IP and a Public IP (206.12…). Copy the Public IP address and open an SSH client. Using the user name cloud-user and the SSH Key pair that was defined earlier login to the Public IP address that was assigned to the VM. 

November 2016