Most of our compute-workloads utilizes network-based storage, as that gives great flexibility and resilliency. Some applications are quite sensitive to disk response-times, and even though our central network-storage utilizes SSD's with very low latency the VM's will experience some latency as the disk-access-time includes network-delay. For latency-sensitive applications it is possible to equip compute-nodes with SSD's and VM's created on the compute-nodes will then get one extra disk (block-device) with very low latency.

Availability

To get a VM with a local disk you need to create it using a flavor with local disks. These flavors are currently only available for tenants owning compute-nodes equipped with SSD's, and are unfortunatley not generally available.

Usage considerations.

Using a flavor with local storage (instead of the network-based storage) gives some implications that you as user need to be aware of.

Local storage is "ephemeral" - Lasting for only a short time

Compute-nodes with local disks are intended to supply ephemeral data storage with higher performance profiles. The downside is a lot less reliability, which is fine as the data should be "ephemeral", meaning "lasting for only a short time". All data that need to be persistent needs to be stored on separate cinder volumes, or other reliable storage locations. The ephimeral disks are lost if:

• The VM is deleted
• The compute-node experiences a disk-failure.
• The VM is "shelved", meaning that it is temporarily placed in cold storage and can be re-created later.
  • The "shelve" stores the VM's root-disk, but not any ephemeral-disks.

Slower creation of VMs

Creating a VM where the root-disk is on local storage means that the image you boot need to be copied to the local disk before the VM can be booted. For large images that might involve tens of gigabytes that needs to be copied over the network, resulting in longer creation-times than wat you might be used with from the network-based compute-nodes.

Slower deletion of VMs.

When a virtual machine is deleted it is needed to zero out the disks the VM's had allocated to avoid the next user of the disk to have access to the data which were in the disk. When an instance is deleted a part of the deletion-process is to fill the disk with zeroes, meaning that the deletion of virtual machines with large local disks might take some time. The flavors with 16TB of local SSD will for instance use a couple of hours to be deleted.

Access to network-based storage

Even the flavors utilizing local-disks can have access to the network-based storage through the use of "volumes" (Openstack Cinder). So all your regular openstack volumes can also be attached to VM's running with local disk. 

For faster VM creation times it is actually recommended to boot from a volume.