Dimensionando soluciones de almacenamiento hibridas con Storage Gateway

Bruno Laurenti, Solutions Architect at Amazon Web Services

Extender las capacidades de almacenamiento local hacia la nube se ha convertido en una alternativa atractiva para los clientes que se enfrenten a problemas como:

· Limitaciones para poder incrementar la capacidad del almacenamiento local.
· Imposibilidad de encontrar métodos simples para enviar grandes volúmenes de información a la nube o permitir que servicios locales interactúan transparentemente con los datos en la nube.
· Soluciones de backups locales que no tienen mas soporte y no cumplen con los estándares de preservación de la información que la empresa necesita.

Para solucionar estos problemas es donde el Storage Gateway puede ayudarlos.
Es por eso que a lo largo de este blog detallaremos los diferentes modos de operación del Storage Gateway explicando los casos de uso y como exitosamente dimensionarlo teniendo en cuenta requerimientos técnicos.

Comencemos por la definición del servicio. El Storage Gateway es una solución que permite conectar infraestructura local con almacenamiento en la nube para que puedan transparentemente leer y escribir información sin necesidad de hacer modificaciones en la infraestructura local o en las aplicaciones, permitiéndole a nuestros clientes implementarlo para cubrir diversos escenarios como:

· Extender las capacidades del almacenamiento local.
· Migrar información.
· Backups
· Recuperación frente a desastres

El funcionamiento es simple, un servidor virtual o físico que se despliega en la infraestructura local del cliente. El Storage Gateway permite exponer volúmenes de almacenamiento para que estos sean utilizados por las aplicaciones y/o servidores locales para leer y escribir.
Internamente el Storage Gateway tiene inteligencia para transferir esta información en forma asincrónica hacia los servicios de almacenamiento de AWS.

Actualmente el Storage Gateway soporta tres modos de funcionamiento básico.

File Gateway

File Gateway convierte al Storage Gateway en una solución de almacenamiento que puede ser accedida haciendo uso de los protocolos NFS v3/v4.1 y SMB v2/v3. La información se envía en forma asincrónica a S3 en donde se mantiene una copia completa la cual puede ser visualizada a nivel de archivos de la misma manera que se visualiza en el volumen del Storage Gateway local.
Ideal para casos de uso como enviar información que debe ser digerida y procesada por servicios en la cloud o backups de archivos.

Volumen Gateway Cache Mode

Volume Gateway Cache Mode se presenta como una solución de almacenamiento que es accedida por el protocolo iSCSI. Esta modalidad trabaja almacenando la información de acceso mas frecuente en forma local mientras se mantiene una copia completa en S3 en formato snapshots de Elastic Block Store (EBS).
Ideal para casos de uso como el de minimizar la necesidad de aumentar la capacidad del almacenamiento local manteniendo bajas latencias para acceder a la información.

Volume Gateway Stored Mode

Volume Gateway Stored Mode opera de la misma forma que el Volume Gateway Cache Mode pero la diferencia fundamental es que almacena una copia completa de la información en forma local mientras mantiene una copia en S3 en forma de snapshots EBS.
Ideal para mantener backups de discos pertenecientes a maquinas virtuales o utilizarla como una herramienta complementaria para recuperarse frente a un desastre.

Tape Gateway

Por último Tape Gateway es una modalidad de operación que permite emular el comportamiento de una librería de cinta tradicional accedida por iSCSI la cual puede ser operada por sistemas de Backups que tengan la capacidad de operar sistemas de cinta.
La información que se guarda en estas cintas virtuales se envía a S3 en forma asincrónica y esta misma información, mediante políticas de envejecimiento de S3, pueden ser migradas a Glacier.

Para terminar esta introducción, aquí les dejo un Link en donde podrán ver casos de éxito de nuestros clientes haciendo uso de Storage Gateway.

Ahora que tenemos claro los modos de operación, nos enfocaremos en profundizar los aspectos de diseño del Storage Gateway. Este punto resulta de gran importancia para el éxito de los proyectos que utilizarán esta solución.

Es importante aclarar que en este blog solo nos enfocaremos en dimensionar el storage Gateway virtual. Comencemos…

Cantidad de vCPUs

La recomendación según nuestra documentación oficial es como mínimo 4 vCPUs en un host que no tenga niveles de overcommit, es decir, que no existan mas vCPUs que CPUs físicos. Y si ese es el caso que el ratio de overcommit no supere el 2:1.
Mayor cantidad de vCPUs aumenta la capacidad de procesamiento del Storage Gateway y según la carga de trabajo puede ser necesario aumentar la cantidad de vCPUs pero solo si hay un justificativo para hacerlo.

Cantidad de Memoria RAM

Para la cantidad de memoria como base inicial se recomienda 16GB de RAM, en lo posible, reservada para que en el caso de existir falta de recursos de memoria en el host físico, los mecanismos de reclamación de memoria del hypervisor no reclamen memoria del Storage Gateway.

Diseño de los discos

Para poder comenzar a dimensionar los discos es importante entender como es la estructura de discos según cada modo de operación del Storage Gateway.

·      El disco de Upload Buffer se utiliza como una área de espera, la información que se almacena se encuentra lista para ser transferida a S3 por una canal seguro y solo es utilizado cuando el SG opera en modo Volume Gateway o Tape Gateway.

·      El disco de Cache se encarga de almacenar toda aquella información que haya sido accedida recientemente para garantizar baja latencia.

·      El disco de Data del (solo para Volume Gateway Stored Mode), representa el disco que almacenaría toda la información de cliente.

Existen dos consideraciones de diseño muy importantes que deben tenerse en cuenta para arquitectar correctamente los discos del Storage Gateway:

1)   Primera Parte: Tamaño de los discos

a.    Upload Buffer
b.    Cache

2)   Segunda Parte: Rendimiento

Primera Parte A – Tamaño del Upload Buffer

El Upload Buffer debe ser dimensionado teniendo cuenta la cantidad de información que ingresa, respecto de la cantidad de información que egresa.
Queda claro que si se escribe mas rápido de lo que puede subirse a S3, el Storage Gateway no podrá mantener toda la información sincronizada con la nube y es por eso que el tamaño del Upload Buffer debe estar basado en la siguiente formula:

[ Wr (MB/s)– BW (MB/s) ] x Tr (s)= Upload Buffer (MB)

Wr = Cantidad de Escrituras en MB/s al Storage Gateway
BW = Ancho de banda en MB/s disponible para subir información a S3.
Tr = Tiempo estimado en segundos de una ráfaga de escritura.

Hagamos un ejemplo:

Tenemos un servidor que escribe en el orden de los 125 MB/s por unas 6 horas (21.600 Segundos) y el ancho de banda de subida que tenemos es de 100Mbits (12MB/s).

[125 MB/s – 12 MB/s] x 21600 = 2.440.800 MB = 2.384 GB = 2.32 TB

Para poder lograr absorber esta transferencia es necesario contar con un disco de Upload Buffer de 2.32 TB.

Tengan en cuenta que el mínimo recomendado para el Upload Buffer es de 150GB.
Si el resultado de la formula les da menos que eso, entonces mantengan el mínimo recomendado.
¿Cómo podrían darse cuenta si dimensionaron incorrectamente el Upload Buffer?
Pueden monitorear las siguientes métricas en CloudWatch:

·      UploadBufferPercentUsed
·      UploadBufferUsed
·      UploadBufferFree

Y en el caso de necesitarlo pueden agregar mas discos para que formen parte del Upload Buffer pero no intenten redimensionar el tamaño del disco que están utilizando.

Primera Parte B – Tamaño de la Cache

Cuando el Storage Gateway esta operando en modo Volume Gateway o Tape Gateway la regla general es:

Tamaño del Upload Buffer (MB)x 1.1 = Cache (MB)

Si nos basamos en nuestro ejemplo seria:

2.32 TB x 1.1 = 2.5 TB

Finalmente a la hora de aprovisionar el espacio para los discos, es importante que pre asignen la totalidad del espacio, lo que se conoce como Thick Provisioning, para obtener el máximo rendimiento conforme los discos se van llenando.

Segunda Parte – Rendimiento

Debido a que el Storage Gateway básicamente esta operando como una solución de almacenamiento debemos arquitectarla adecuadamente para que pueda responder eficientemente las peticiones de lectura y escrituras, mejor conocidas como IOPS (Input Output per Second). Por tal motivo a continuación se presenta el diseño de todo el stack almacenamiento.

Si bien la cantidad de discos y el propósito de los discos puede cambiar según el modo de operación del SG, lo importante es respetar las siguientes características:

·      Una controladora de disco SCSI para cada disco.
Esto permite que la carga total de IOPS pueda distribuirse mas eficientemente.
Además como cada controladora tiene su propio Queue Depth esto aumenta la capacidad de IOPS que pueda procesar paralelamente el Storage Gateway sobre cada disco.

·      Cada disco del Storage Gateway debería estar respaldado por una LUN diferente.
Las LUNs son objetos lógicos que agrupan pools de discos físicos. A mayor cantidad de discos físicos que tenga la LUN, mayor será la cantidad de IOPS que puede soportar cada disco del SG.

Lo que se pretende lograr con este diseño es maximizar el nivel de paralelismo de IOPS y aumentar la flexibilidad de poder asignar diferentes LUNs de diferentes características de rendimiento según la carga de trabajo que haya sido estimada previamente.

Si no cuentan con un ambiente virtualizado o no tienen la posibilidad de poder configurar una maquina virtual extra en su ambiente local o estén en la situación de que no tengan control sobre los detalles del diseño de almacenamiento detallados mas arriba, pueden evaluar la solución de Storage Gateway Hardware Appliance.

No quiero olvidar compartirles este Link para aquellos que quieran dar los primeros pasos con este servicio.

Bueno y con esto finalizamos el dimensionamiento del Storage Gateway.
Espero que pueda ayudarlos a construir soluciones hibridas para sus clientes de la mejor forma posible.

Les deseo mucha suerte.

Bruno Laurenti

Solutions Architect at Amazon Web Services