Skip to content

Commit

Permalink
Update Standards/scs-0111-v1-volume-type-decisions.md
Browse files Browse the repository at this point in the history
Co-authored-by: Felix Kronlage-Dammers <[email protected]>
Signed-off-by: Markus Lindenblatt <[email protected]>
  • Loading branch information
maliblatt and fkr authored Sep 12, 2023
1 parent d0f3254 commit d75f0a9
Showing 1 changed file with 1 addition and 1 deletion.
2 changes: 1 addition & 1 deletion Standards/scs-0111-v1-volume-type-decisions.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ track: IaaS

## Introduction

Volumes in OpenStack are virtual drives. They are managed by the storage service Cinder, which abstracts creation and usage of many different storage backends. While it is possible to use a backend like lvm which can reside on the sam host as the hypervisor, the SCS wants to make a more clear differenciation between volumes and the ephemeral storage of a virtual machine. For all SCS deployments we want to assume that volumes are always residing in a storage backend that is NOT on the same host as a hypervisor - in short terms: Volumes are network storage. Ephemeral storage on the other hand is the only storage residing on a compute host. It is created by creating a VM directly from an Image and is automatically los as soon as the VM cease to exist. Volumes on the other hand have to be created from Images and only after that can be used for VMs. They are persistant and will remain in the last state a VM has written on them before they cease to exit. Being persistant and not relying on the host where the VM resides, Volumes can easily be attached to another VM in case of a node outage and VMs be migrated way more easily, because only metadata and data in RAM has to be shifted to another host, accelerating any migration or evacuation of a VM.
Volumes in OpenStack are virtual drives. They are managed by the storage service Cinder, which abstracts creation and usage of many different storage backends. While it is possible to use a backend like lvm which can reside on the same host as the hypervisor, the SCS wants to make a more clear differentiation between volumes and the ephemeral storage of a virtual machine. For all SCS deployments we want to assume that volumes are always residing in a storage backend that is NOT on the same host as a hypervisor - in short terms: Volumes are network storage. Ephemeral storage on the other hand is the only storage residing on a compute host. It is created by creating a VM directly from an Image and is automatically los as soon as the VM cease to exist. Volumes on the other hand have to be created from Images and only after that can be used for VMs. They are persistent and will remain in the last state a VM has written on them before they cease to exit. Being persistent and not relying on the host where the VM resides, Volumes can easily be attached to another VM in case of a node outage and VMs be migrated way more easily, because only metadata and data in RAM has to be shifted to another host, accelerating any migration or evacuation of a VM.

Volume Types are used to classify volumes and provide a basic decision for what kind of volume should be created. These volume types can sometimes very be backend-specific and it might be hard for a user to choose the most suitable volume type, if there is more than one default type. Nevertheless the most of configuration is done in the backends themself, so volume types only work as a rough classification.

Expand Down

0 comments on commit d75f0a9

Please sign in to comment.