Compute Service (Nova)
Overview
firstcolo Clouds Compute Service is built on the OpenStack Nova project. It manages the life-cycle of compute instances in your environment. Its responsibilities include spawning, scheduling and decommissioning of virtual machines on demand.
You can manage your compute instance both via our public OpenStack API endpoints, as well as using the Dashboard.
Flavors
Flavor Generations
Over time, our compute hypervisors in the cloud will use new hardware generations to ensure the best possible performance. As we make a new generation of hypervisors available in the cloud, we will also deploy new flavor versions to ensure that instances which are intended to use the most performance available are only created on the new hypervisors.
You can identify the hardware version by the ascending number after the flavor type.
| Flavor | Type | Hardware Generation | Size |
|---|---|---|---|
| g2.small | General | v2 (2022) (Current Generation) | Small |
| g1.small | General | v1 (2020) | Small |
Instance types
Standard instances generally offer you good performance, availability and storage durability. Disk data will be distributed across multiple servers (firstcolo Distributed Storage).
We recommend these instance types for most workloads and applications.
General Purpose
| Name | API Name | Memory | vCPUs | Storage* |
|---|---|---|---|---|
| G2 Small | g2.small | 2GiB | 1 | 20GiB |
| G2 Medium | g2.medium | 4GiB | 2 | 40GiB |
| G2 Large | g2.large | 8GiB | 4 | 80GiB |
| G2 XLarge | g2.xlarge | 16GiB | 8 | 160GiB |
| G2 XXLarge | g2.xxlarge | 32GiB | 16 | 320GiB |
CPU optimized
| Name | API Name | Memory | vCPUs | Storage* |
|---|---|---|---|---|
| C2 Small | c2.small | 2GiB | 2 | 20GiB |
| C2 Medium | c2.medium | 4GiB | 4 | 40GiB |
| C2 Large | c2.large | 8GiB | 8 | 80GiB |
| C2 XLarge | c2.xlarge | 16GiB | 16 | 160GiB |
RAM optimized
| Name | API Name | Memory | vCPUs | Storage* |
|---|---|---|---|---|
| M2 Small | M2.small | 4GiB | 1 | 20GiB |
| M2 Medium | M2.medium | 8GiB | 2 | 40GiB |
| M2 Large | M2.large | 16GiB | 4 | 80GiB |
| M2 XLarge | M2.xlarge | 32GiB | 8 | 160GiB |
| M2 XXLarge | m2.xxlarge | 64GiB | 16 | 320GiB |
(*) You can extend ephemeral storage using our durable Block Storage Service.
Local SSD storage
When creating an instance with a flavor mentioned above you have the option to directly boot from a volume. This tells the compute service to mount the root disk of your instance from a volume provisioned by our Block Storage Service.
When you do not choose to do that the instance will use the local ssd storage provided by the compute hypervisor. This storage offers a lower latency and faster read / write speeds with downside of less fault tolerance. These can be useful for special workloads like replicated databases.
Warning
Availability and data durability are reduced, because data is only stored locally on one server.
Note
When using local storage the only way of increasing the size of your root disk is by upgrading to a larger flavor
In general we recommend our customers to use the Block Storage Service for persistent storage since the data gets replicated at least three times to different locations inside the availability zone.
For more information, see the local storage documentation.
Flavor change (resizing)
Note
After the initial resize request was placed, additional confirmation is required before the system will resize the instance when resizing via GUI/CLI.
Flavor change to different storage type
If more resources are required for an instance, the fastest solution is to build a new instance and migrate the required data (if any) via network or an attached volume.
If a conversion of an existing instance seems inevitable, a similar result can be achieved by creating an image from that instance and using it as a boot source for a new instance with another flavor. Please keep in mind that hardware specifications and CPU flags may change with change of flavor.
Instance Snapshots
Instance snapshots can be created from instances, if they are not booted from a cinder volume.
Warning
Creating instance snapshots of your server will make it unresponsive for a period of time (depending on the disk size).
openstack server image create --name <MyInstanceSnapshotName> <MyInstanceName>
Data consistency
For best results, we recommend to shut off the instance before creating a snapshot. Otherwise there might be data inconsistencies and file system corruption.
Another variant to avoid data inconsistencies is to use the QEMU Guest Agent. Unfortunately it's not sufficient to install the Guest Agent in your virtual machine.
You have to start with a Glance image where the QEMU Guest Agent is already properly installed and configured. This image must have the property hw_qemu_guest_agent=yes.
Only if the virtual machine was created from such an image the compute service learns that the Guest Agent is available.
Launch instances from snapshots
Snapshots can be used as templates for new instances.
Questions & Answers
What is the difference between local ssd storage and distributed storage?
firstcolo Cloud distributed storage distributes several copies of segments of your data over many physical ssd devices attached to different physical compute nodes connected via network. This allows for high overall performance, because several devices can work simultaneously, but introduces a latency for single operations, because data has to be transmitted via network.
firstcolo Cloud local ssd storage stores your data on a local raid10 ssd storage directly attached to the compute node. This reduces the latency, because no network is involved, but also redundancy, because only four devices and one compute node are involved.
Which storage flavor fits my needs best?
In general, workloads where large volumes of data are transmitted or many small chunks of data are handled in parallel benefit from the overall performance of distributed storage and of course the redundancy and availability whereas workloads with tiny requests that need to be executed serially benefits from the lower latency of local ssd storage.
Why are instances migrated?
Software Updates
firstcolo regularly updates the software on the hypervisor host machines. Sometimes those updates require restarts of services or even a reboot of the whole hypervisor. In such cases we will live-migrate all running instances to another hypervisor host prior to applying the update.
Hardware Maintenance
All hardware nodes require maintenance at some point. Sometimes the required maintenance work cannot be done while the machine is online. In such cases we will live-migrate all running instances to another hypervisor host prior to performing the maintenance.
Hardware failure
Unfortunately live migrations are not possible in case of a hardware failure. In such a situation running instances will be automatically restarted on another hardware node. Stopped instances will also be assigned to another hypervisor but remain stopped.
How long does a migration take?
A live migration takes usually about 5-10 seconds. In some situations migrations may take longer.
Why are instances disconnected while migrating?
To transfer the active state of instances (incl. RAM/Memory) they need to be 'frozen' prior to the migration. During the transfer network packets can get lost. It depends on the operating system and application that is being used if connection can be reestablished.
Can I allocate a fixed IP to a compute instance?
Normally a fixed IP shouldn't play a big role in a cloud setup, since the infrastructure might change a lot. If you need a fixed IP, you can assign a port from our networking service as a fixed IP to our compute instance.
My compute instance was created, but is e.g. not accessible via SSH/HTTP
By default all compute instances are using the "default" security group which allows egress (outgoing) traffic to any destination and ingress (incoming) traffic from ports which have the default security group assigned. Any further ports need to be opened by adding a rule to the security group the instance uses. See Create Security Groups for more details.
How to set a password to get console access?
Usually cloud images does not have set a password for the default user, so logging in to the console is not possible.
A password can be set via cloud-init during instance creation using the following customization script (change my-password to a secure password):
#cloud-config
password: my-password
chpasswd: { expire: False }
The name of the default user can be found in the image property image_original_user.
Note that most cloud images does not allow SSH password authentication.