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)

Migrar Servidores a Linux


La migración de sistemas de plataformas Windows a plataformas Linux surge de la necesidad lisa y llana de abaratar costos. Este es un resumen (muy resumido) de mis experiencias:

Escenario: Tenía una serie de servidores Windows, en su mayoría W2003R2, brindando los siguientes servicios:
– File Server, Mail Server, Proxy, Antivirus, Active Directory, Sql Server.

La cuestión es que de a poco y con paciencia es posible migrarlos a todos…, o casi todos a Linux.

– El Active Directory + el File Server se puede configurar directamente en un Linux con Samba + Ldap. El ldap (openldap) nos va a dar la funcionalidad de autenticación de usuarios mientras que el samba nos va a brindar los recursos compartidos necesarios para trabajar con archivos en la red.

– Con Squid reemplazamos cualquier proxy.

– Respecto del servidor de mail, he sido bastante masoquista al respecto (eso dicen ja, ja). Me he dedicado a instalar un servidor QMail con listas RBL que para instalarlo, me ha llevado unas cuántas horas de “plática” con él.

– Respecto de la base de datos, la mejor manera de reemplazar el SQL server es migrando los datos y el código a Mysql o Postgres.
El tema es el siguiente: los datos son fáciles de migrar. Inclusive hay herramientas que realizan dicha taréa. Pero en mi caso, tengo cientos de Stored Procedures… éstos si o sí requieren un análisis y traducción de código que no he visto que realice ninguna herramienta, con lo cuál, en mi caso, el costo de migración es sumamente alto.
Otro tema a evaluar en el caso de la base de datos es la aplicación que hace uso de dicha base. Es posible migrar su enlace a la base?

– Respecto del antivirus, no he encontrado un reemplazo realmente eficiente para el Symantec Corporate Server. Este antivirus, trabaja una base de virus centralizada y hace un deploy a todos los clientes windows conectados.
Creo que la mejor solución para este reemplazo va a surgir cuando pueda reemplazar todos los clientes windows por clientes Linux !!!