¿Debería preocuparme los cambios de bits en Amazon S3?

Question

Tengo algunos datos que quiero guardar en Amazon S3. Algunos de estos datos están encriptados y algunos están comprimidos. ¿Debería preocuparme por los volcados de un solo bit? Sé del encabezado hash MD5 que se puede agregar. Esto (según mi experiencia) evitará volteos en la parte más poco confiable del trato (comunicación de red), sin embargo, todavía me pregunto si necesito protegerme contra volteos en el disco.

Answer 1

Estoy casi seguro de que la respuesta es "no", pero si quieres ser paranoico extra que puede precalcular el hash MD5 antes de subir, que para comparar el hash MD5 se obtiene después de la carga, a continuación, al descargar calcular el MD5 hash de los datos descargados y compárelo con su hash almacenado.

No estoy seguro de cuál es el riesgo que le preocupa. En algún momento, debe aplazar el riesgo para otra persona. ¿Los "datos dañados" se incluyen en el Acuerdo de nivel de servicio de Amazon? Presumiblemente ellos saben lo que es el archivo hash supuesto, y si el hash de los datos que le dan no coincide, entonces es claramente su problema.

supongo que hay otros enfoques también:

• almacenar sus datos con un FEC para que pueda detectar y corregir errores de bits N hasta su opción de N.
• almacenar sus datos más de una vez en Amazon S3, tal vez en sus centros de datos de EE. UU. y Europa (creo que también hay uno nuevo en Singapur próximamente en línea), con redundancia similar a RAID para que pueda recuperar sus datos si algunas fuentes desaparecen o se corrompen.

Realmente depende de cuán valiosos sean para usted los datos que está almacenando y cuánto riesgo está dispuesto a aceptar.

Answer 2

Veo su pregunta desde dos puntos de vista, una teórica y práctica.

Desde un punto de vista teórico, sí, debería preocuparse, y no solo sobre el cambio de bits, sino sobre varios otros posibles problemas. En particular section 11.5 de los acuerdos con el cliente dice que Amazon

no hacen ninguna representación o garantías de ningún tipo, ya sea explícita, implícita, LEGAL O DE OTRO CON RESPECTO A LOS ofertas de servicios. (..omiss ..) NOSOTROS Y NUESTROS LICENCIATARIOS NO GARANTIZAMOS QUE LAS OFRENDAS DEL SERVICIO FUNCIONEN SEGÚN LO DESCRITO, SERÁN ININTERRUMPIDAS O LIBRES DE ERRORES, O LIBRES DE COMPONENTES DAÑINOS, O QUE LOS DATOS QUE ALMACEN DENTRO DE LAS OFRENDAS DEL SERVICIO SERÁN SEGUROS O NO PERDIDAS O DAÑADAS DE OTRO MODO.

Ahora, en la práctica, no me preocuparía. Si pierde su información, publicará un blog sobre ella y (aunque es posible que no enfrente ninguna acción legal), su negocio habrá terminado.

Por otro lado, eso depende de la importancia de sus datos. Supongamos que está rodando sus propias cosas en su (s) propio (s) centro (s) de datos. ¿Cómo planificarías la recuperación de desastres allí?Si dice: Solo mantendría dos copias en dos bastidores diferentes, solo use la misma técnica con Amazon, tal vez manteniendo dos copias en dos centros de datos diferentes (ya que escribió que no está interesado en cómo para proteger contra volteos de bits , estoy proporcionando sólo un ejemplo trivial aquí)

Answer 3

Hay dos maneras de leer su pregunta: "¿Es Amazon S3 perfecta"

2. "¿Cómo manejo el caso donde Amazon S3 no es perfecto?"

La respuesta a (1) es casi seguro que "no". Podrían tener mucha protección para acercarse, pero aún existe la posibilidad de falla.

Eso deja (2). El hecho es que los dispositivos fallan, a veces de manera obvia y otras veces de maneras que parecen funcionar pero dan una respuesta incorrecta. Para hacer frente a esto, muchas bases de datos utilizan un CRC por página para garantizar que una página leída del disco sea la misma que la que se escribió. Este enfoque también se utiliza en los sistemas de archivos modernos (por ejemplo, ZFS, que puede escribir varias copias de una página, cada una con un CRC para controlar las fallas del controlador de incursión. He visto que ZFS corrige errores de un solo bit leyendo una segunda copia; no son perfectos.)

En general, debe verificar que el sistema funcione como espera. Usar una función hash es un buen enfoque. Qué enfoque adopta cuando detecta una falla depende de sus requisitos. Almacenar múltiples copias es probablemente el mejor enfoque (y ciertamente el más fácil) porque puede obtener protección contra fallas del sitio, fallas de conectividad e incluso fallas del proveedor (al elegir un segundo proveedor) en lugar de solo redundancia en los datos mediante el uso de FEC.

Answer 4

Probablemente no: Amazon está usando sumas de comprobación para la protección contra bits voltea, peinar regularmente a través de los datos en reposo, lo que garantiza que no se han producido lanzamientos bits. Entonces, a menos que tenga daños en todas las instancias de los datos dentro del intervalo de los bucles de verificación de integridad, debería estar bien.

Internamente, S3 utiliza las sumas de comprobación MD5 en todo el sistema para detectar/proteger contra los bitflips. Cuando PONE un objeto en S3, calculamos el MD5 y almacenamos ese valor. Cuando obtienes un objeto, recalculamos el MD5 a medida que lo volvemos a transmitir. Si nuestro MD5 almacenado no coincide con el valor que calculamos al enviar de vuelta el objeto, devolveremos un error para la solicitud GET. Luego puede volver a intentar la solicitud.

También revisamos continuamente todos los datos en reposo, volviendo a calcular las sumas de comprobación y valiéndolos contra el MD5 que guardamos cuando originalmente almacenamos el objeto. Esto nos permite detectar y reparar bit flips que ocurren en los datos en reposo. Cuando encontramos un pequeño giro en los datos en reposo, lo reparamos usando los datos redundantes que almacenamos para cada objeto.

También puede protegerse contra los bitflips durante la transmisión hacia y desde S3 proporcionando una suma de comprobación MD5 cuando PONE el objeto (cometeremos un error si los datos que recibimos no coincide con la suma de comprobación) y validando el MD5 cuando OBTENER un objeto.

Fuente: https://forums.aws.amazon.com/thread.jspa?threadID=38587