A root disk is used to boot the compute instance and typically contains an operating system image.
When creating a new instance via the dashboard you are asked to select a Boot Source. You can choose to use an image provided by Catalyst Cloud, images uploaded by you, instance snapshots, existing volumes, or volume snapshots:
Image: Public images are pre-configured operating system images provided
by Catalyst Cloud or our partners. Private images are images you have
Instance Snapshot: Assuming you have previously created a snapshot of
another compute instance, this option will create a new compute instance that
is a clone of an existing compute instance (at the point the snapshot was
Volume: Will re-attach an existing volume as the root disk of the new
compute instance. This option assumes that the existing volume is a valid
boot source (i.e.: contains an operating system).
Volume Snapshot: Assuming you have previously created a snapshot of a
volume, this option will create a new root disk that is a clone of an
existing volume (at the point in time the snapshot was taken).
Compute instances can have their root disk backed by a
Persistent Volume or
Ephemeral Disk. The table below outlines the main differences between
these two options:
Root disk type
Will continue to exist after the compute instance is deleted, so long the option delete on terminate was not selected.
Snapshots will take less than a second to be performed and will use less space.
Copy on Write (CoW) is used for the snapshot. As a result, the snapshot will depend and require the original volume to remain available.
Will be deleted when the compute instance is deleted.
Will take longer to be performed and will use more space.
A complete copy of the data will be created. As a result, the snapshot will be independent and the original ephemeral disk can be deleted.
By default the web dashboard will create a
Persistent Volume. This is the
recommended option for most use cases, and in doubt, the one that should be
Ephemeral Disk is only recommended for true cloud native applications,
built using the immutable infrastructure principle, or one-off jobs.
For convenience, it is possible to request the compute service to delete the
Persistent Volume used for the root disk when the compute instance is
deleted. To do so, select “Yes” for “Delete Volume on Instance Delete”.
For production workloads it is not recommended to delete volumes automatically when compute instances are deleted.
In order to launch an instance from an NVMe volume we need to create a volume of the right type based on the image that we need to run. Once this is done we can launch a new instance from that volume.
Got into the
Volumes screen and select Create Volume and set the following
Volume Name: something meaningful so it can be easily identified in
Volume Source: needs to be set to
Use image as source: this option is made visible by the previous choice,
select the OS image that you wish to run.
Type: select one of the NVMe storage tier options from the dropdown.
Here is an example using Ubuntu 18.04 as the image on a b1.sr-r3-nvme-1000 volume.
Once the volume has been successfully created we can launch the instance.
Go to the Instances page and select Launch Instance. Populate the Details section as required.
On the Source page set
Select Boot Source to
Volume, you should now be
able to see the volume you created in the previous step under
Select your volume and ensure it now appears under Allocated like this.
Complete the rest of the Launch Instance dialogue as required and launch the instance.
The compute instance flavor (US spelling is correct here) defines the amount of CPU and RAM allocated to your virtual servers. The price per hour for a compute instance varies according to its flavor. Existing flavors can be found here: https://catalystcloud.nz/services/iaas/compute/
Our flavors are named after the amount of CPU and RAM they provide you, so you don’t need to consult our documentation to find out their specifications. We currently provide a number of common combinations of CPU and RAM, and are prepared to introduce new flavors if required.
A virtual CPU (vCPU), also known as a virtual processor, is a time slice of a physical processing unit assigned to a compute instance or virtual machine. The mapping of virtual CPUs to physical cores is part of the performance and capacity management services performed by the Catalyst Cloud on your behalf. We aim to deliver the performance required by applications, and to increase cost efficiency to our customers by optimising hardware utilisation.
Since virtual CPUs do not map one-to-one to physical cores, some performance variation may occur over time. This variation tends to be small, and can be mitigated by scaling applications horizontally on multiple compute instances in an anti-affinity group. We monitor the performance of our physical servers and have the ability to move compute instances around, without downtime, to spread out load if required.
A script called cloud-init is included in all images provided by the Catalyst Cloud. This script is there to assist you with instance configuration at boot time. It communicates with the meta-data agent of our cloud and, for example, configures the network of your compute instance as defined by you via our APIs.
Cloud-init is very powerful. It’s a de facto multi-distribution and multi-cloud way of handling the early initialisation of a cloud instance.
When you launch a compute instance on the Catalyst Cloud, you can pass
initialisation configuration to cloud-init via “user-data” (either using the
--user-data parameter of
openstack server create, or as a post-creation
customisation script via the web dashboard).
In the following sections, we provide examples that illustrate how to perform common initialisation tasks with cloud-init, using different configuration formats.
Some of the content types supported by the MIME format include:
text/cloud-config: cloud config format
text/x-shellscript: shell script (written in any language)
text/x-include-url: read content from a URL
text/upstart-job: upstart job