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.
También encontré este sitio de referencia interesante para Azure Blob de almacenamiento: http://azurescope.cloudapp.net/BenchmarkTestCases/ –
Otra entrada en el blog de Netflix que habla de por qué evitan EBS: http://techblog.netflix.com /2011/04/lessons-netflix-learned-from-aws-outage.html –
Y un comentario de ese blog que describe EBS vs EC2 Ephemeral Disk performance: http://victortrac.com/EC2_Ephemeral_Disks_vs_EBS_Volumes –