38,907
edits
Managing your cloud resources with OpenStack/en: Difference between revisions
Jump to navigation
Jump to search
Managing your cloud resources with OpenStack/en (view source)
Revision as of 16:02, 26 October 2018
, 6 years agoUpdating to match new version of source page
(Updating to match new version of source page) |
(Updating to match new version of source page) |
||
| Line 4: | Line 4: | ||
OpenStack is the software suite used on the Compute Canada Cloud to control hardware resources such as computers, storage and networking. It allows the creation and management of virtual machines ("VMs", or "instances"), which act like separate individual machines, by emulation in software. This allows users complete control over their computing environment, from choosing an operating system to software installation and configuration. Diverse use cases are supported, from hosting websites to creating virtual clusters. More documentation on OpenStack can be found at the [http://docs.openstack.org/ OpenStack web site]. | OpenStack is the software suite used on the Compute Canada Cloud to control hardware resources such as computers, storage and networking. It allows the creation and management of virtual machines ("VMs", or "instances"), which act like separate individual machines, by emulation in software. This allows users complete control over their computing environment, from choosing an operating system to software installation and configuration. Diverse use cases are supported, from hosting websites to creating virtual clusters. More documentation on OpenStack can be found at the [http://docs.openstack.org/ OpenStack web site]. | ||
This page describes how to perform common tasks encountered while working with OpenStack. It is assumed that you have already read [[Cloud Quick Start]] and understand the basic operations of launching and connecting to a VM. Most tasks can be performed using the dashboard as described below; however, some require using command line tools, for example [[#Sharing_an_image_with_another_project|sharing an image with another project]]. | This page describes how to perform common tasks encountered while working with OpenStack. It is assumed that you have already read [[Cloud Quick Start]] and understand the basic operations of launching and connecting to a VM. Most tasks can be performed using either the dashboard (as described below), [[OpenStack Command Line Clients|CLI]], or a tool called [https://www.terraform.io/ terraform]; however, some require using command line tools, for example [[#Sharing_an_image_with_another_project|sharing an image with another project]]. | ||
=Projects= | |||
OpenStack projects group VMs together and provide a quota out of which VMs and related resources can be created. A project is unique to a particular cloud. All accounts which are members of a project have the same level of permissions, meaning anyone can create or delete a VM within a project they are a member of. You can view the projects you are a member of by logging into an OpenStack dashboard for the cloud(s) you have access to (see [[Cloud#Using_the_Cloud|using the cloud]] for a list of cloud URLs). The active '''project name''' will be displayed in the top left of the dashboard to the right cloud logo. If you are a member of more than one project you can switch between active projects by clicking on the drop down menu and clicking a project name. | |||
Depending on your allocation your project may be limited to certain types of VM [[Virtual_machine_flavors|flavors]]. For example, if you have a compute allocation your project maybe limited to only "c" flavors, while if you have a persistent allocation your project maybe limited to only "p" flavors. | |||
Projects can be thought of as owned by primary investigators (PIs) and new projects and quota adjustments can only be requested by PIs. In addition request for access to an existing project must be confirmed by the PI owning the project. | |||
=Security Groups= | =Security Groups= | ||
A security group is a set of rules to control network traffic into and out of your virtual machines. To manage security groups go to ''Project->Compute->Access & Security'' and select the ''Security Groups'' tab. You will see a list of currently defined security groups. If you have not previously defined any security groups, there will be single default security group. | A security group is a set of rules to control network traffic into and out of your virtual machines. To manage security groups go to ''Project->Compute->Access & Security'' and select the ''Security Groups'' tab. You will see a list of currently defined security groups. If you have not previously defined any security groups, there will be single default security group. | ||
| Line 10: | Line 18: | ||
To add or remove rules from a security group, click ''Manage Rules'' beside that group. When the group description is displayed, you can add or remove rules by clicking the ''+Add Rule'' and ''Delete Rule'' buttons. | To add or remove rules from a security group, click ''Manage Rules'' beside that group. When the group description is displayed, you can add or remove rules by clicking the ''+Add Rule'' and ''Delete Rule'' buttons. | ||
== Default security group == | |||
[[File:Default_security_group_rules_en.png|400px|thumb| Default Security Group Rules (Click for larger image)]] | [[File:Default_security_group_rules_en.png|400px|thumb| Default Security Group Rules (Click for larger image)]] | ||
The '''default security group''' contains rules which allow a VM access out to the internet, for example to download operating system upgrades or package installations, but does not allow another machine to access it, except for other VMs belonging to the same default security group. We recommend you do not remove rules from the default security group as this may cause problems when creating new VMs. The image on the right shows the default security group rules that should be present: | The '''default security group''' contains rules which allow a VM access out to the internet, for example to download operating system upgrades or package installations, but does not allow another machine to access it, except for other VMs belonging to the same default security group. We recommend you do not remove rules from the default security group as this may cause problems when creating new VMs. The image on the right shows the default security group rules that should be present: | ||
| Line 16: | Line 25: | ||
It is safe to add rules to the default security group and you may recall that we did this in [[Cloud Quick Start]] by either adding security rule for [[Creating_a_Linux_VM#Firewall.2C_add_rules_to_allow_SSH|SSH]] or [[Creating_a_Windows_VM#Firewall.2C_add_rules_to_allow_RDP|RDP]] to your default security group so that you were able to connect to your VM. | It is safe to add rules to the default security group and you may recall that we did this in [[Cloud Quick Start]] by either adding security rule for [[Creating_a_Linux_VM#Firewall.2C_add_rules_to_allow_SSH|SSH]] or [[Creating_a_Windows_VM#Firewall.2C_add_rules_to_allow_RDP|RDP]] to your default security group so that you were able to connect to your VM. | ||
You can define multiple security groups and a VM can belong to more than one security group. When deciding on how to manage your security groups and rules, think carefully about what needs to be accessed and who needs to access it. Strive to minimize the IP addresses and ports in your Ingress rules. For example, if you will always be connecting to your VM via SSH from the same computer with a static IP it makes sense to allow SSH access only from that IP. To specify the allowed IP or IP range use the [ | == Managing security groups == | ||
You can define multiple security groups and a VM can belong to more than one security group. When deciding on how to manage your security groups and rules, think carefully about what needs to be accessed and who needs to access it. Strive to minimize the IP addresses and ports in your Ingress rules. For example, if you will always be connecting to your VM via SSH from the same computer with a static IP it makes sense to allow SSH access only from that IP. To specify the allowed IP or IP range use the [[OpenStack#Using_CIDR_rules|CIDR]] box (use this web based tool for converting [http://www.ipaddressguide.com/cidr IP ranges to CIDR] rules). Further, if you only need to connect to one VM via SSH from the outside and then can use that as a gateway to any other Cloud VMs, it makes sense to put the SSH rule in a separate security group and add that group only to the gateway VM. However, you will also need to ensure your SSH keys are configured correctly to allow you to use SSH between VMs (see [[SSH Keys]]). In addition to CIDR, security rules can be limited within a project using security groups. For example, you can configure a security rule for a VM in your project running a MySQL Database to be accessible form other VMs in the default security group. | |||
The security groups a VM belongs to can be chosen when it is created on the ''Launch Instance'' screen under the ''Access & Security'' tab, or after the VM has been launched by selecting ''Edit Security Groups'' form the drop down menu of actions for the VM on the ''Project->Compute->Instances'' page. | The security groups a VM belongs to can be chosen when it is created on the ''Launch Instance'' screen under the ''Access & Security'' tab, or after the VM has been launched by selecting ''Edit Security Groups'' form the drop down menu of actions for the VM on the ''Project->Compute->Instances'' page. | ||
==Using CIDR rules== | |||
CIDR stands for Classless Inter-Domain Routing and is a standardized way of defining IP ranges (see also this wikipedia page on [https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing CIDR]). | |||
An example of a CIDR rule is <code>192.168.1.1/24</code>. This looks just like a normal IP address with a <code>/24</code> appended to it. IP addresses are made up of 4, 1 byte (8 bit) numbers ranging from 0 to 255. What this <code>/24</code> means is that this CIDR rule will match the first left most 24 bits (3 bytes) of an IP address. In this case any IP address starting with <code>192.168.1</code> will match this CIDR rule. If <code>/32</code> is appended the full 32 bits are specified the IP address must match exactly, likely wise if a <code>/0</code> is appended no bits must match and therefor any IP address will match it. | |||
=Working with Volumes= | =Working with Volumes= | ||
| Line 173: | Line 188: | ||
Then you can create a new virtual machine and attach the vmdk image to it (see [http://techathlon.com/how-to-run-a-vmdk-file-in-oracle-virtualbox/ how to run a vmdk file in virtualbox] for detailed instructions on this). | Then you can create a new virtual machine and attach the vmdk image to it (see [http://techathlon.com/how-to-run-a-vmdk-file-in-oracle-virtualbox/ how to run a vmdk file in virtualbox] for detailed instructions on this). | ||
=Resizing VMs= | = Working with VMs= | ||
== Locking VMs == | |||
When working with multiple people in a project or to protect a VM from accidental deletion or shutdown it can be useful to lock it. | |||
To '''lock''' a VM, click on the "Lock Instance" from the action menu in the dashboard.<br/> | |||
Once a vm is locked most of the action menu item will not be able to be executed until the instance is unlocked. There is an icon indicating the lock state for every instance. | |||
To '''unlcok''' a VM, select the "Unlock Instance" from the action menu in the dashboard.<br/> | |||
==Resizing VMs== | |||
It is possible to resize a VM by changing its flavor. However, there are some things to be aware of when choosing to resize a VM which depends on whether you have a "p" flavor or a "c" flavor VM (see [[Virtual machine flavors]]). Resizing a VM may involve some risk as it is similar to deleting and recreating your VM with a new flavor, if in doubt contact cloud [[technical support]]. | It is possible to resize a VM by changing its flavor. However, there are some things to be aware of when choosing to resize a VM which depends on whether you have a "p" flavor or a "c" flavor VM (see [[Virtual machine flavors]]). Resizing a VM may involve some risk as it is similar to deleting and recreating your VM with a new flavor, if in doubt contact cloud [[technical support]]. | ||
==c flavors== | ===c flavors=== | ||
"c" flavors often have extra ephemeral drives, which will be resized when you choose a new "c" flavor. These ephemeral drives can not become smaller, and as such "c" flavor VMs can only be resized to flavors with equal or larger ephemeral drives. After the resize however, you will not immediately see a larger ephemeral drive within your VM (e.g. the [https://en.wikipedia.org/wiki/Df_(Unix) <code>df -h</code>] command will not show the size increase). To see this extra space you will need to resize your file system (see the [https://linux.die.net/man/8/resize2fs <code>resize2fs</code>] command). However, filesystem resizes should be treated with caution and can take considerable time if the partitions are large. Before resizing a filesystem it is recommend to create backups of its contents (see [[backing up your VM]]). | "c" flavors often have extra ephemeral drives, which will be resized when you choose a new "c" flavor. These ephemeral drives can not become smaller, and as such "c" flavor VMs can only be resized to flavors with equal or larger ephemeral drives. After the resize however, you will not immediately see a larger ephemeral drive within your VM (e.g. the [https://en.wikipedia.org/wiki/Df_(Unix) <code>df -h</code>] command will not show the size increase). To see this extra space you will need to resize your file system (see the [https://linux.die.net/man/8/resize2fs <code>resize2fs</code>] command). However, filesystem resizes should be treated with caution and can take considerable time if the partitions are large. Before resizing a filesystem it is recommend to create backups of its contents (see [[backing up your VM]]). | ||
==p flavors== | ===p flavors=== | ||
Unlike "c" flavors, "p" flavors do not typically have extra ephemeral drives associated with them, so they can be resized to larger and smaller flavors. | Unlike "c" flavors, "p" flavors do not typically have extra ephemeral drives associated with them, so they can be resized to larger and smaller flavors. | ||