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

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 usados ​​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 outage of EC2 and EBS (Ver Post Mortem) me gustaría saber más acerca de cómo se compara EBS con las unidades Azure. Específicamente:

1. sé Drives Azure se pueden montar como de lectura/escritura en una sola instancia o como de sólo lectura en varias instancias. ¿Es lo mismo para EBS? También escuché que Microsoft Azure Drives se puede usar en Read/Write mode on multiple instances using the SMB protocol. Alguien tiene experiencia con esto?

2. Ha habido mucha gente quejándose de t he reliability of 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 para actualizar un sitio web que se ejecuta en varias instancias (Ej: crear instantánea, implementar los cambios, a continuación, montar como de sólo lectura en todos los casos)

Estas son sólo algunas de las preguntas básicas que tenía, pero me 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 Windows Azure Drives whitepaper, que explica en detalle cómo se crea la unidad Azure usando Page Blobs. Esto significa que debe estar cubierto por el Windows Azure Storage SLA que dice:

Windows Azure tiene SLA separados para el cálculo y el 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 da una ventana de tiempo de inactividad anual de alrededor de 26.28 minutes papeles web/trabajador y 52.56 minutes para su almacenamiento o papeles que requieren acceso a las unidades de Azure. Windows Azure tiene regiones similares a las que ofrece Amazon AWS, pero dentro de las regiones no tienen distintas zonas de disponibilidad. En cambio, tienen Upgrade Domains and Fault Domains, que se utilizan para desplegar actualizaciones y localizar role instances on different hardware racks. 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 Amazon EBS, pero parece que son actually NOT backed by Amazon S3, pero en su lugar son un sistema de almacenamiento por separado.El Amazon S3 SLA proporciona 99.999999999% durability and 99.99% availability, pero todo lo que se menciona por EBS es:

volúmenes de Amazon EBS se colocan en una zona de disponibilidad específico, y luego se pueden unir a los casos también en ese mismo 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 de volúmenes en un punto en el tiempo, 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% al año. Ya que los volúmenes de EBS se basan totalmente en una zona de disponibilidad también es importante para crear instantáneas de copias de seguridad:

volúmenes de EBS tienen redundancia incorporada, lo que significa que no se producirá un error si falla una unidad individual o de alguna otra sola falla ocurre 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 reciente EBS/EC2 outage tiene muchos más detalles sobre la arquitectura de EBS e indica que el disparador fue un cambio en la configuración de red no válido. Ese cambio provocó que varios volúmenes se desasociaran con sus espejos y 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 de retroceso y errores de software, causó 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 designed to expect and tolerate failures 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.