pricing - Diferencias entre Amazon Elastic Block Storage(EBS) y Microsoft Azure Drives

how do you access data on elastic block storage in aws

Question

He estado buscando utilizar Amazon EC2 o Microsoft Azure para alojar un nuevo proyecto, y planeo usar Amazon EBS o Microsoft Azure Drives para almacenar los archivos utilizados para ejecutar un sitio web ASP.NET. Que yo sepa, estas dos tecnologías son muy similares y ambas proporcionan un disco duro virtual respaldado por el almacenamiento en la nube ( Amazon S3 o Azure Blobs ). Con el reciente corte de EC2 y EBS (Ver Post Mortem ), me gustaría saber más acerca de cómo se compara EBS con las unidades de Azure. Específicamente:

1. Sé que las unidades Azure se pueden montar como lectura / escritura en una sola instancia o como de solo lectura en varias instancias. ¿Es lo mismo para EBS? También he escuchado que las unidades Microsoft Azure se pueden usar en modo lectura / escritura en varias instancias usando el protocolo SMB . Alguien tiene experiencia con esto?

2. Ha habido mucha gente quejándose de la confiabilidad de Amazon EBS, incluso antes del corte de hoy. Incluso he escuchado que algunas personas hacen referencia al uso de múltiples volúmenes de EBS para crear un sistema RAID, lo que me parece una tontería. ¿Qué tan confiables se han comparado las unidades Microsoft Azure con EBS?

3. Creo que las unidades EBS y Microsoft Azure le permiten tomar instantáneas, que pueden usarse para realizar copias de seguridad o montarse en una instancia de VM y modificarse sin cambiar el volumen original. ¿Es esta una forma razonable de actualizar un sitio web que se ejecuta en varias instancias (por ejemplo, crear instantáneas, implementar cambios y montarlo como de solo lectura en todas las instancias)?

Esas son solo algunas de las preguntas básicas que tuve, pero me encantaría saber de alguien que tenga experiencia con Amazon EBS y Microsoft Azure Drives.

Answer 1

Pude responder algunas de mis preguntas leyendo el documento técnico Windows Azure Drives , que explica en detalle cómo se crea Azure Drive usando Page Blobs . Esto significa que debe estar cubierto por el SLA de almacenamiento de Windows Azure que indica:

Windows Azure tiene SLA separados para cómputo y almacenamiento. Para el cómputo, le garantizamos que cuando implemente dos o más instancias de roles en diferentes dominios de fallas y actualizaciones, sus roles orientados a Internet tendrán conectividad externa al menos el 99.95% del tiempo. Además, supervisaremos todas sus instancias de roles individuales y garantizamos que el 99.9% del tiempo lo detectaremos cuando el proceso de una instancia de rol no se esté ejecutando e iniciemos acciones correctivas.

Para el almacenamiento, garantizamos que al menos el 99,9% del tiempo procesaremos correctamente las solicitudes formateadas que recibimos para agregar, actualizar, leer y eliminar datos. También garantizamos que sus cuentas de almacenamiento tendrán conectividad a nuestra puerta de enlace de Internet.

Esto proporciona una ventana de tiempo de inactividad anual de alrededor de 26,28 minutos para las funciones web / trabajador y 52,56 minutos para el almacenamiento o las funciones que requieren acceso a las unidades Azure. Windows Azure tiene regiones similares a las que ofrece Amazon AWS, pero dentro de las regiones no tienen distintas zonas de disponibilidad. En su lugar, tienen Dominios de actualización y Dominios de fallas , que se utilizan para desplegar actualizaciones y localizar instancias de roles en diferentes bastidores de hardware . Los dominios de falla no son configurables por el usuario, por lo que si desea un mayor nivel de disponibilidad, debe configurar los servicios por separado en otra región.

No pude encontrar una descripción similar de cómo se crean las unidades de Amazon EBS , pero parece que en realidad NO están respaldadas por Amazon S3 , sino que son un sistema de almacenamiento por separado. El SLA de Amazon S3 proporciona 99.999999999% de durabilidad y 99.99% de disponibilidad , pero todo lo que se menciona para EBS es:

Los volúmenes de Amazon EBS se colocan en una zona de disponibilidad específica, y luego se pueden adjuntar a instancias también en esa misma zona de disponibilidad.

Cada volumen de almacenamiento se replica automáticamente dentro de la misma Zona de disponibilidad. Esto evita la pérdida de datos debido a la falla de cualquier componente de hardware individual.

Amazon EBS también ofrece la capacidad de crear instantáneas puntuales de los volúmenes, que persisten en Amazon S3. Estas instantáneas se pueden usar como punto de partida para los nuevos volúmenes de Amazon EBS y proteger los datos para una mayor durabilidad a largo plazo. La misma instantánea se puede usar para crear la instancia de tantos volúmenes como desee.

También indican que EBS tiene una tasa de falla anual esperada de entre 0.1% - 0.5% en comparación con los discos duros típicos que fallan alrededor del 4% anual. Como los volúmenes de EBS se basan completamente en una zona de disponibilidad, también es importante crear instantáneas para las copias de seguridad:

Los volúmenes de EBS tienen redundancia incorporada, lo que significa que no fallarán si falla un disco individual o si ocurre alguna otra falla. Pero no son tan redundantes como el almacenamiento S3 que replica datos en múltiples zonas de disponibilidad: un volumen EBS vive completamente en una zona de disponibilidad. Esto significa que hacer copias de seguridad de instantáneas, que se almacenan en S3, es importante para la protección de datos a largo plazo.

El informe post mortem para la interrupción reciente de EBS / EC2 tiene muchos más detalles sobre la arquitectura de EBS e indica que el desencadenante fue un cambio de configuración de red no válido. Ese cambio provocó que varios volúmenes se desasociaran de sus réplicas y los quickly led to a “re-mirroring storm,” where a large number of volumes were effectively “stuck” while the nodes searched the cluster for the storage space it needed for its new replica. Esto combinado con unas pocas condiciones de carrera, tiempos de espera inadecuados y errores de software causaron la interrupción prolongada que afectó a múltiples zonas de disponibilidad. Amazon ha declarado que están tomando una serie de medidas para evitar que esto ocurra en el futuro, incluido hacer que el plano de control EBS sea más tolerante a las fallas en las zonas de disponibilidad individuales.

Al final, los sistemas que fueron diseñados para esperar y tolerar fallas se vieron mucho menos afectados por la interrupción de AWS. Como mínimo, cualquier sistema que use Azure Drives o Amazon EBS debe crear copias de seguridad periódicas utilizando la función de instantáneas proporcionada e incluso puede considerar enviar la instantánea a una región separada o a un proveedor de almacenamiento completamente separado.