Difference between revisions of "OpenStack"
Line 88: | Line 88: | ||
| c28.m224|| 28 || None || 224 GB | | c28.m224|| 28 || None || 224 GB | ||
|- | |- | ||
− | | * | + | | * c64.m120|| 64 || None || 120 GB |
|- | |- | ||
− | | * | + | | * c128.m240|| 128 || None || 240 GB |
|- | |- | ||
− | | colspan="4" style="text-align:left;" | ''* GPU flavors | + | | ** ''c4.t1.m20'' || 4 || 1 '''[https://www.nvidia.com/en-us/data-center/tesla-t4/ Nvidia Tesla T4]''' || 20 GB |
− | |} | + | |- |
+ | | ** ''c14.g1.m60'' || 14 || 1 '''[https://www.nvidia.com/en-us/data-center/tesla-v100/ Nvidia Tesla V100]''' || 60 GB | ||
+ | |- | ||
+ | | colspan="4" style="text-align:left;" | * Flavors with AMD EPYC cores. Cannot be resized to flavors with 28 or fewer (Intel) cores. | ||
+ | ''** GPU flavors|} | ||
When you are first starting an instance, we '''recommend''' that you select the smallest flavor (least number of CPUs) that you think will be able to handle installation and configuration of the software and environment on your instance, and then [[Resizing an Instance|resize the instance]] when you are ready to run. The "c1.m8" flavor will typically be enough, as you will not need much memory or compute power while setting up your software. This way you will save core hours that would otherwise have been spent idle. This method is especially useful when configuring a ''GPU instance'' due to the number of cores. Also note: you can begin with a smaller instance size (or flavor) that does not contain a GPU, and later resize to one that does. | When you are first starting an instance, we '''recommend''' that you select the smallest flavor (least number of CPUs) that you think will be able to handle installation and configuration of the software and environment on your instance, and then [[Resizing an Instance|resize the instance]] when you are ready to run. The "c1.m8" flavor will typically be enough, as you will not need much memory or compute power while setting up your software. This way you will save core hours that would otherwise have been spent idle. This method is especially useful when configuring a ''GPU instance'' due to the number of cores. Also note: you can begin with a smaller instance size (or flavor) that does not contain a GPU, and later resize to one that does. |
Revision as of 15:29, 10 March 2022
OpenStack is an open-source cloud stack that is currently running on Red Cloud. Also, for more information, see the Official Documentation for OpenStack.
This page is intended as a quick walk-through of the most-used features of OpenStack, so it is not comprehensive, but links to a lot of supporting documentation for more thorough explanations and advanced topics.
Using the OpenStack Web Interface (Horizon)
There are two ways to manage Red Cloud resources:
Most users will use the OpenStack Web Interface (called Horizon). This web-based interface can be used to manage instances and volumes. For Linux Instances, however, some users may choose to use the OpenStack CLI. This section focuses on the OpenStack Web Interface.
Logging into OpenStack
Log in to the OpenStack Web Interface to create and manage Red Cloud resources. There are two ways to login:
- CAC Account - Enter cac as the "Domain" and your CAC username and password, not your Cornell NetID. If your CAC password has expired, you will need to reset it before you will be able to login to the OpenStack Web Interface.
- Globus Auth - Log in through Globus
- Currently, this feature is only available to Aristotle users. This feature will be enabled for all users in the future.
- You must link your Cornell account, or any accounts attached to the projects you are on, in order to have access to them when using Globus Auth.
- If you can't log in with Globus Auth, it may be that you have not linked your account yet.
You can use the "Authenticate using" drop-down to switch between the two options. Neither option requires you to enter a project ID; you can switch between the projects you are on once logged in.
Overview Page
The Overview page is the first place you will be taken upon logging into Red Cloud.
- Provides useful metrics on currently selected project
- Before creating an instance, you will need to:
- Select the correct project from the "Project" drop-down at the top right of the page (if you are on multiple projects)
- Create a key pair - for authentication when you log in the first time
- Create a security group - defines allowable types of port access for an instance
- Optional: Set up a private network - if you do not want your instance to be available on the public network
- You may also want to:
- Create and Attach a Volume (can also be done when launching an instance)
- Associate a Floating IP address - a fixed IP address that can be assigned to an instance
Key Pairs
To get to the Key Pairs page: select the "Compute" tab along the top (you should start here at login), then click on "Key Pairs" along the top bar as pictured above. If you are logged in already, you can also get to it by this link: Key Pairs.
On the Key Pairs page, you can view the list of available key pairs for your project. From here, you can also create or import a key pair. If you do not already have a key pair listed, you can either create one before launching an instance, or create or upload a key pair during instance setup.
For more information, here is a walk-through on OpenStack Key Pairs.
Security Groups
To get to the Security Groups page: select the "Network" drop-down menu along the top, then click on "Security Groups" as pictured above. If you are already logged in, you can also get to it by following this link: Security Groups
On the Security Groups page, you can view a list of available security groups for your project, including a default security group. On this page, you can also create and delete security groups. It is not recommended that you use the default security group without modifying the rules to fit your needs. A good security practice is to have one security group per application or one per user. Instances that have no business talking to each other should generally be in separate security groups.
If you do not already have a security group set up, you will want to create one before launching an instance because you cannot create one during instance setup. However, you can assign a security group to an instance later, and even add or modify the rules of the security group at any time.
For more information, here is a walk-through on OpenStack Security Groups.
Instances
Each instance is a Virtual Machine (VM) in the cloud. You can select CPU/RAM/disk configurations (called "flavors") for the VM. Note that each vCPU currently equates to one core. The available VM configurations are:
Flavor | vCPUs | GPUs | RAM |
---|---|---|---|
c1.m8 | 1 | None | 8 GB |
c2.m16 | 2 | None | 16 GB |
c4.m32 | 4 | None | 32 GB |
c8.m64 | 8 | None | 64 GB |
c14.m112 | 14 | None | 112 GB |
c20.m160 | 20 | None | 160 GB |
c28.m224 | 28 | None | 224 GB |
* c64.m120 | 64 | None | 120 GB |
* c128.m240 | 128 | None | 240 GB |
** c4.t1.m20 | 4 | 1 Nvidia Tesla T4 | 20 GB |
** c14.g1.m60 | 14 | 1 Nvidia Tesla V100 | 60 GB |
* Flavors with AMD EPYC cores. Cannot be resized to flavors with 28 or fewer (Intel) cores.
** GPU flavors|} When you are first starting an instance, we recommend that you select the smallest flavor (least number of CPUs) that you think will be able to handle installation and configuration of the software and environment on your instance, and then resize the instance when you are ready to run. The "c1.m8" flavor will typically be enough, as you will not need much memory or compute power while setting up your software. This way you will save core hours that would otherwise have been spent idle. This method is especially useful when configuring a GPU instance due to the number of cores. Also note: you can begin with a smaller instance size (or flavor) that does not contain a GPU, and later resize to one that does. The root disk size of the instance will default to the size of the image you select. You have the option to create a volume as the root disk beyond the image size at launch time. Note that we do not oversubscribe physical RAM, CPU cores, or GPUs (hyperthreading is disabled). To work with instances, select the "Instances" page under the "Compute" tab, as pictured below: Launch an InstanceThis section is a general walk-through for creating a new instance, which is not specific to an Operating System (OS). For more specific information per OS, see either of these pages: To launch a new instance
The full "Launch Instance" menu will pop up like this:
Configuring the Instance
Instance StatesOpenStack defines several Server States through which you can move your instances. You change the state of your instance by making a selection from a drop-down menu under the Actions column. Three significant actions to know about are "Resize Instance", "Shelve Instance", and "Unshelve Instance"; these are described below. Allowed actions—i.e., the ones that appear in the drop-down menu—depend on the current state of the instance. For example, the "Resize Instance" action is allowed only for instances that are in the Active state. The figure below shows the possible states in OpenStack and the transitions that are allowed in each case. When your instance has been created, the "Instances" tab will list its current state (as well as the state of your other instances) under the "Status" column. In the rightmost column called "Actions," you will see a drop-down menu for each instance. This menu lists the actions that are allowed for the given instance. Below we describe the typical states and list some of the common actions you will use to change instance state. Important StatesNote: The only state where you are NOT being charged for computational resources is Shelved Offloaded
Operations to transition between statesThese options are available, subject to the current state of the Instances, from the dropdown available in the "Actions" column of the Instances page. Remember that Shelving is the only operation that will free up the computational resources your Instance has been using so that you stop being charged for them!
Deleting a Red Cloud instanceFor data safety, make sure to back up any data you want to keep before deleting any volumes or instances. You can avoid creating orphaned boot volumes by (a) choosing "Delete Volume on Instance Delete" when you first launch an instance, or (b) deleting the boot volume immediately after you delete the related instance. You do the latter by following the two-step procedure below. If the instance was deleted before the boot volume could identified, skip to step 2. Step 1: Identify the boot volumes before deleting the instances.
Volumes Attached Attached To d35e1234-b99d-48a9-a827-97d6f8eca4fb on /dev/vda
Migrate an Instance to a New ProjectOccasionally, you may have an instance in one Red Cloud project that you would like to migrate to a different project. If you have been working in an exploratory project and are transitioning to using a permanent project, you may want to bring along the instances you have created. Or, you may want to share an instance with someone who is working in another project. The steps to perform such migrations are not difficult and can be performed through the Red Cloud (Horizon) web interface. |