Este es un tema particularmente popular cuando se trata de la confiabilidad de la nube pública. Como anécdota, nunca he recibido un error 405 de S3 en docenas de terabytes de datos almacenados, no estoy seguro de cuántos objetos se distribuyen, pero probablemente en las decenas de millones. Creo que esto probablemente ponga mi uso en la mediana de los usuarios de AWS S3, por lo que valga la especulación.
Con respecto al análisis riguroso, creo que debemos considerar seriamente que no tenemos suficiente información para probar o refutar la afirmación de Amazon de 11 9s de durabilidad. Soy terrible con las estadísticas, pero el problema que hay que resolver es determinar el intervalo de confianza en base a una estimación de 2 billones de objetos almacenados, desafortunadamente no se sabe cuál es la tasa de pérdida de objetos observada, y una complicación adicional es que la distribución de La pérdida de objetos casi seguramente no sigue una distribución simple de Poisson.
Ciertamente no es suficiente decir que debido a que el diseño de S3 permite 11 9s de durabilidad que necesariamente se pierden miles de objetos cada año. Con suerte, Amazon publicará 405 tasas de error en las regiones S3 en el futuro, sin duda sería un mejor marketing (menos FUD) que su página de estado actual o 11 9s.
- Cómo hacer la aversión de disco de RDS
- ¿F5 está en la nube? ¿O debería ir con ALB / ELB?
- ¿Dónde podemos encontrar el código en Openstack?
- ¿Qué es la tecnología en la nube y la ingeniería de aplicaciones móviles? ¿Hay alguna posibilidad para lo mismo hoy?
- ¿Debería un estudiante de ECE aprender computación en la nube?
Lo que sí sabemos es que los datos se almacenan en S3 con un factor de replicación de 3 en todas las zonas de disponibilidad. RRS simplemente reduce el factor de replicación a 2. Cada vez que se reemplaza el almacenamiento, volver a replicar los datos introduce más posibilidades de que los datos se corrompan y desencadenen una nueva replicación. Esta es la razón por la cual Amazon comprueba los datos en reposo, así como durante el tránsito por las redes. Es indeterminado si estas verificaciones adicionales también se eliminan cuando se utiliza RRS.
Es probable que la causa más común de la replicación sea el reemplazo del disco. El reemplazo del disco puede ocurrir debido a una falla, pero sospecho que los discos que muestran algún error se programan para el retiro y las pruebas antes de ser potencialmente reintroducidos en el grupo de almacenamiento. Algunas fallas de disco pueden ser de naturaleza catastrófica, pero muchas veces los sensores internos como las pruebas SMART pueden indicar una degradación de la durabilidad mucho antes de la falla total de la unidad.
Para un enfoque más exhaustivo de la falla del disco en la computación en clúster, consulte https://www.usenix.org/legacy/ev… En comparación con los clústeres en ese artículo, S3 tiene, suponiendo 40 PB de almacenamiento en RF = 3, al menos 60,000 Unidades de 2 TB en uso, quizás 40,000 unidades de 3 TB, pero probablemente algunas se mezclan dependiendo del precio del hardware.
