EBS Storage Performance Notes – Instance throughput vs Volume throughput


I just wanted to write a couple lines/guidance on this regard as this is a recurring question when configuring storage, not only in the cloud, but can also happen on bare metal servers.

What is throughput on a volume?

Throughput is the measure of the amount of data transferred from/to a storage device per time unit (typically seconds).

The throughput consumed on a volume is calculated using this formula:

IOPS (IO Ops per second) x BS (block size)= Throughput

As example, if we are writing at 1200 Ops/Sec, and the chunk write size is around 125Kb, we will have a total throughput of about 150Mb/sec.

Why is this important?

This is important because we have to be aware of the Maximum Total Throughput Capacity for a specific volume vs the Maximum Total Instance Throughput.

Because, if your instance type (or server) is able to produce a throughput of 1250MiB/s (i.e M4.16xl)) and your EBS Maximum Throughput is 500MiB/s (i.e. ST1), not only you will hit a bottleneck trying to write to the specific volumes, but also throttling might occur (i.e. EBS on cloud services).

How do I find what is the Maximum throughput for EC2 instances and EBS volumes?

Here is documentation about Maximum Instance Throughput for every instance type on EC2: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html

And here about the EBS Maximum Volume throughput: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html

How do I solve the problem ?

If we have an instance/server that has more throughput capabilities than the volume, just add or split the storage capacity into more volumes. So the load/throughput will be distributed across the volumes.

As an example, here are some metrics with different volume configurations:

1 x 3000GB – 9000IOPS volume:

GP2-1x3000GB-9000IOPS

3 x 1000GB – 3000IOPS volume:

GP2-3x1000GB-3000IOPS

Look at some of the metrics: these are using the same instance type (m4.10xl – 500Mb/s throughput), same volume type (GP2 – 160Mb/s throughput) and running the same job:

  • Using 1 volume, Write/Read Latency is around 20-25 ms/op. This value is high compared to 3x1000GB volumes.
  • Using 1 volume, Avg Queue length 25. The queue depth is the number of pending I/O requests from your application to your volume. For maximum consistency, a Provisioned IOPS volume must maintain an average queue depth (rounded to the nearest whole number) of one for every 500 provisioned IOPS in a minute. On this scenario 9000/500=18. Queue length of 18 or higher will be needed to reach 9000 IOPS.
  • Burst Balance is 100%, which is Ok, but if this balance drops to zero (it will happen if volume capacity keeps being exceeded), all the requests will be throttled and you’ll start seeing IO errors.
  • On both scenarios, Avg Write Size is pretty large (around 125KiB/op) which will typically cause the volume to hit the throughput limit before hitting the IOPS limit.
  • Using 1 volume, Write throughput is around 1200 Ops/Sec. Having write size around 125Kb, it will consume about 150Mb/sec. (IOPS x BS = Throughput)

Backup de Volúmenes Lógicos en servidor remoto / LVM Snapshot to Remote


Tengo varias máquinas virtuales KVM corriendo en un CentOS. Estas VMs trabajan sobre volúmenes LVM almacenados en /dev/VolGroup01/vm01 , /dev/VolGroup01/vm02, etc
El tema es que necesitaba realizar backups de estos LVMs para tenerlos como respaldo en un equipo backup , y en caso de contingencia levantar la máquina virtual en dicho equipo.
El CentOS que administra todas estas máquinas virtuales, no tiene mas espacio en disco como para hacer snapshots locales de los LVM para luego transferirlos a otro equipo.
Como hacer para mandar estos snapshots a otro equipo? La opción que encontré hasta ahora es la siguiente:

# dd if=/dev/VolGoup01/vm01 | ssh root@equiporemoto “dd of=/var/lib/libvirt/images/vm01.img”

opcionalmente , puedo poner un gzip en el medio para reducir el tamaño del archivo y el tráfico:

# dd if=/dev/VolGoup01/vm01 | gzip |ssh root@equiporemoto “dd of=/var/lib/libvirt/images/vm01.img.gz”

Con esto, teniendo preconfigurada la máquina en el KVM del equipo backup, en caso de necesidad, solo debo descomprimir el archivo y ponerla en marcha.

Si alguien tiene una sicutación similar y le encontró otra vuelta lo escucho ansioso !!!

Physical to Virtual with rsync – Migrar Servidores Fisicos a Virtuales


Resulta que me encuentro con un gran tema: como pasar un servidor (linux por supuesto) de físico a virtual sin tener que reinstalarlo por completo.

Un opción que evalúe fué: http://www.mondorescue.org/ (gracias Mauro) esta aplicación (excelente por cierto) permite realizar un backup completo del sistema operativo y lo almacena en archivos .ISO, uno o varios, del tamaño que le indiquemos.
Esta opción no debe descartarse para esta taréa, aunque merece que sea evaluada en otro post.

La opción que hoy nos interesa es la del rsync.
(Vale la aclaración de que hay cientos de maneras de hacer esta taréa. Yo les planteo la que se me ocurrió a mi y dió resultado.)

Para pasar un equipo fisico a virtual con rsync, lo que hice fué lo siguiente:
Crear la maquina virtual destino con los parámetros adecuados, e instalando el mismo sistema operativo base que el servidor físico (en mi caso un CentOS 5.5).
Para que? Para que el filesystem sea lo mas parecido entre el orígen y el destino.

En el equipo físico realice un rsync como el siguiente:
# rsync -vah –exclude-from=excludes.cfg / root@equipo-virtual:/

En el excludes.cfg puse lo siguiente:

/proc/
/tmp/
/mnt/
/mirror/
/etc/fstab
/etc/grub/
/etc/sysconfig/network-scripts/ifcfg-eth0

En el equipo virtual necesito que el fstab mantenga la configuración original, al igual que la placa de red y el grub. Es por eso que están en la exclusión.

Una vez realizado el rsync, y verificado que se hayan copiado todos los directorios, en la maquina virtual, necesitamos bootear con el CD de intalación en modo rescate “linux rescue” para hacer la reinstalación del grub:

# grub-install /dev/hdc

Si el grub-install nos da el error:
“/dev/hdc does not have any corresponding BIOS drive”
Lo resolvemos agregando la siguiente línea en el /boot/grub/device.map:
(hd2) /dev/hdc

Un detalle muy importante:
Va a ser necesario generar una nueva imagen de los módulos del kernel dado que el initrd del equipo fisico, tiene una entrada (init) donde guarda los nombres de los dispositivos de disco en uso (sda, sdb, etc) y por mas que hayamos guardado el fstab de la máquina virtual, en el momento de booteo va a buscar estos dispositivos definidos en el initrd.
Para crear un nuevo initrd que se utilizará en el booteo hagamos lo siguiente:
Hacemos un backup primero del actual en uso:
# cp initrd-$(uname -r).img initrd-$(uname -r).img.back

Compilamos uno nuevo:
# mkinitrd initrd-$(uname -r).img $(uname -r)

Con esto, la máquina virtual debería reinicar correctamente y deberíamos tener el sistema operativo funcionando igual que en el equipo físico.

KVM: Configurar Bridged Networking – Adaptador Puente


Bueno, resulta que entrando en el mundo de la virtualización, este es un tema de consulta permanente, así que merece la presente entrada.

Aplicable a: Fedora / CentOS / Redhat con KVM / qemu / libvirt

– Deshabilitar el Network Manager. Aparentemente el Network Manager no soporta el bridging.

# chkconfig NetworkManager off
# chkconfig network on
# service NetworkManager stop
# service network start

Otra opción para no deshabilitar el servicio es editar el /etc/sysconfig/network-scripts/ifcfg-eth0 y agregar la entrada: “NM_CONTROLLED=no”.

– Creamos las interfaces bridge:

Editar el /etc/sysconfig/network-scripts/ifcfg-eth0 y agregar la entrada:

BRIDGE=br0

Crear el archivo /etc/sysconfig/network-scripts/ifcfg-br0

con un contenido similar a este:

DEVICE=br0
TYPE=Bridge
BOOTPROTO=dhcp
ONBOOT=yes
DELAY=0

Ojo que “Bridge” es case-sensitive y va como en el ejemplo.

– Restarteamos la red

# service network restart

– Configuramos las iptables para que permitan que el trafico sea redirigido forwarded a través del bridge:

# iptables -I FORWARD -m physdev –physdev-is-bridged -j ACCEPT
# service iptables save
# service iptables restart

Opcionalemente podemos evitar que el trafico del puente sea procesado por las reglas de las iptables. Esto lo hacemos modificando los parámetros del kernel en el /etc/sysctl.conf y agregando las siguientes líneas:

net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

Luego, releemos los parametros del kernel:

# sysctl -p /etc/sysctl.conf

– Restarteamos el libvirt daemon:

# service libvirtd reload

Ahora, debería aparecer el “shared physical device” habilitado.

– Podemos chequear el bridge de la siguiente manera:

# brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.000000000000       yes
br0             8000.000e0cb30550       no              eth0

Ojo que este bridge es completamente independiente del virbr0.

El virbr0 se utiliza unicamente para hacer NAT.