About Volumes

BSU volumes are virtual hard drives that you can attach to an FCU virtual machine (VM) created in the same Subregion to store data. A volume is defined by its size and IOPS capacity.

Volumes and VMs

When you create a VM, a volume is automatically created and attached to it to store all the data related to the operating system (OS). This volume is called a root device and appears in your account. Root devices have a default size of 10 GiB for Linux VMs (8 GiB for CentOS 7 VMs), and 50 GiB for Windows VMs. You can store data on a root device. However, depending on the block device mapping configuration of the OUTSCALE Machine Image (OMI) used to create the VM, this root device may be deleted when terminating this VM.

To add storage capacity to your VMs or to separate your data from the OS files, you can create volumes with the storage capacity of your choice (within the limit of the quotas allocated to your account).

Volumes are placed in a Subregion. If you do not specify any Subregion, the Subregion A is used by default.

You can attach volumes to any VM created within the same Subregion, in the public Cloud or in a Net. When attached to a VM, a volume works exactly like a physical hard drive and can be used in the same way, after initializing this volume as you would have done with a physical one. The VM can then interact with the volume and access your data. When you stop a VM, the attached volumes remain attached to it and can therefore be accessed after the VM is restarted.

  • A volume attached to a running VM is a hot volume.

  • A volume attached to a stopped VM or a detached volume is a cold volume.

A volume persists independently from the VM lifecycle: it can be easily detached from the VM it was previously attached to, and then attached to another VM. When terminating a VM, volumes attached to it are either deleted or detached, depending on the block device mapping of the VM. For more information, see Defining Block Device Mappings.

You can attach up to 40 volumes (including the root device) to a same VM. However, a volume can be attached to only one VM at the same time.

A volume can be in these different states:

  • creating: The creation process of the volume is in progress.

  • available: The volume is created but not attached to a VM. A volume is in the available state even if there is data stored on it.

  • in-use: The volume is attached to a VM. A volume is in the in-use state even if the VM it is attached to is stopped.

  • deleting: The deletion process of the volume is in progress.

  • error: The creation of the volume failed.

To identify your resources more easily, you can add tags to them. For more information, see Tagging Your Resources.

Volumes Attachment and Device Names

You must always attach and mount the root device (bootdisk) of a VM as the /dev/sda1 device name, even though it appears as /dev/vda1 in the VM. For any other volume you attach to a VM, you must use a device name in the /dev/xvdX or /dev/xvdXX format (where the first X is a letter between b and z, and the second X is a letter between a and z).

Non official OMIs must support the PCI Hotplug. Otherwise, the volume is not visible when attached to a VM. You need to reboot the VM and add the following modules to the /etc/modules files:

  • pci-hotplug

  • acpiphp

Linux VMs

For Linux VMs, the /dev/xvdX or /dev/xvdXX device name you choose for your volumes is transformed by Linux in a /dev/sdY or /dev/sdYY device name, following the order in which you attach your volumes to the VM. Two OUTSCALE packages for CentOS and Ubuntu VMs enable you to link the /dev/xvdX or /dev/xvdXX device name to the corresponding /dev/sdY or /dev/sdYY Linux one. You can see these links when listing the devices from the Linux VM in the /dev directory:

Devices Listing Sample
$ ls -l /dev/[svx][vd]*
brw-rw---- 1 root disk   8,  0 30 mai   14:40 /dev/sda
brw-rw---- 1 root disk   8, 16 30 mai   14:41 /dev/sdb
brw-rw---- 1 root disk 253,  0 30 mai   14:16 /dev/vda
brw-rw---- 1 root disk 253,  1 30 mai   14:16 /dev/vda1
lrwxrwxrwx 1 root root       3 30 mai   14:41 /dev/xvdd -> sdb
lrwxrwxrwx 1 root root       3 30 mai   14:40 /dev/xvdh -> sda

The /etc/fstab file of your Linux VMs must be configured with /dev/xvdX and /dev/xvdXX device names.

Windows VMs

Inside a Windows VM, volumes are numbered according to the order in which you attached them, independently from the /dev/xvdX or /dev/xvdXX device name you choose. The root device is numbered 0, the first volume you attach is numbered 1, and so on. If you detach a volume, its associated number is released and reassigned to the next volume you attach to the VM.

To retrieve the device names of your volumes in a Windows VM, you can run the following PowerShell command:

Get-WmiObject -class "Win32_DiskDrive" | Select-Object Name,SerialNumber
Result Sample
Name               SerialNumber
----               ------------
\\.\PHYSICALDRIVE0
\\.\PHYSICALDRIVE1 sdb
\\.\PHYSICALDRIVE2 sdh

To find the device names, replace sd with /dev/xvd. In the above example, volume 0 is the bootdisk, while volume 1 has the device name /dev/xvdb and volume 2 has the device name /dev/xvdh.

Data Persistence

Data stored on a volume is persistent as long as the volume exists and can be accessed when the volume is attached to a VM. If you delete a volume, data stored on it is deleted too.

When detaching a volume from a VM, all the data remains stored on it and this volume becomes available again. This volume can then be attached to another VM, enabling you to access and manage your data again.

You can backup your data stored on a volume using snapshots, that can be copied to another Region. Snapshots enable you to retrieve your data in case of failure of a volume or after you deleted a volume. For more information about snapshots and how to use them, see Working with Snapshots.

Volume Types and IOPS

Volume performance is measured in IOPS (input output per second), that is, the number of read (input) and write (output) operations that the volume can perform in one second.

You can choose between different volume types, depending on the performance you need:

  • Magnetic, with a fixed number of IOPS, no matter its size.

  • Performance, with a burst possibility for volumes below 1 TiB.

  • Enterprise, enabling you to create a volume with the number of IOPS you need. Enterprise volumes are SSD volumes, and therefore have a reduced latency between the time the operation order is sent to the volume and the time the volume executes it.

BSU volumes support the Discard command to clean unused blocks. For more information, see Configuring and Using the Discard.

The following table presents basic use cases for each volume type and describes their performance characteristics:

Magnetic Performance (SSD) Enterprise (SSD)

API and AWS CLI volume name

standard

gp2

io1

Use cases

  • Cold workloads where you do not need to access data frequently

  • Cases in which the lowest storage cost highly matters

  • Most workloads that require moderate performance with moderate costs

  • Applications that require high performance for a short period of time (for example, starting a file system)

  • Workloads where you must access data frequently (for example, a database)

  • Critical business applications that can be blocked by a low performance when accessing data stored on the volume

Volume size

1 GiB - 14.55 TiB (14901 GiB)

1 GiB - 14.55 TiB (14901 GiB)

4 GiB - 14.55 TiB (14901 GiB)

IOPS performance

  • 250 read operations per second in average

  • 150 write per second operations in average

  • Between 1 GiB and 1 TiB: Baseline performance of 3 IOPS (read and write operations per second) per gibibyte, with burst possibility

  • Between 1 TiB and 3.33 TiB: 3 IOPS (read and write operations per second) per gibibyte

  • Between 3.34 TiB and 14.55 TiB: 10000 IOPS (read and write operations per second)

Maximum performance ratio of 300 IOPS per gibibyte

I/O size

16 KiB

16 KiB

16 KiB

Minimum IOPS/volume

/

100

100

Maximum IOPS/volume

/

10000

13000

Maximum IOPS/VM

36000

36000

36000

Maximum throughput/volume

  • 12 MiB/s for read operations

  • 10 MiB/s for write operations

156 MiB/s

208 MiB/s

Maximum throughput per VM is 36000 IOPS, i.e. 562.5 Mio/s.

IOPS Credit and Burst Possibility for Performance Volumes

The IOPS performance of Performance (gp2) volumes depends on their size. Between 1 GiB and 1 TiB, their performance is ruled by the principle of a leaky bucket, which is described below.

Each Performance volume between 1 GiB and 1 TiB receives an initial IOPS credit balance of 5.4 million IOPS, which enables the volume to burst up to 3000 IOPS per second for a maximum duration of 30 minutes. Every second, your IOPS credit balance is refilled with 3 IOPS per gibibyte. The more IOPS credit you have for the volume, the longer it can burst beyond its baseline performance of 3 IOPS per gibibyte.

Burst possibility and IOPS credits are only available for Performance volumes with a size below 1 TiB, as the baseline performance for volume sizes above 1 TiB exceeds the maximum burst performance of 3000 IOPS per second.

The burst duration depends on the following three elements:

  • IOPS credit balance (5.4 million IOPS maximum)

  • Burst performance (3000 IOPS maximum)

  • Volume size

To calculate your maximum burst duration in seconds, use the following equation:

Burst duration = IOPS credit balance / (Burst performance - 3 x Volume size)

When your IOPS credit balance is empty, the volume cannot burst anymore. Its performance remains at its baseline performance level of 3 IOPS per gibibyte, until the IOPS demand drops below this baseline performance level and that IOPS credits you do not use are added to your IOPS credit balance.

Related Pages

AWS™ and Amazon Web Services™ are trademarks of Amazon Technologies, Inc or its affiliates in the United States and/or other countries.

Export to PDF