Стоит ли беспокоиться о переворотах на Amazon S3?

Question

У меня есть некоторые данные, которые я хочу сохранить на Amazon S3 . Некоторые из этих данных зашифрованы, а некоторые сжаты. Должен ли я беспокоиться об однобитовых флипах? Я знаю о хеш-заголовке MD5, который можно добавить. Это (из моего опыта) предотвратит сбои в самой ненадежной части сделки (сетевая связь), однако мне все еще интересно, нужно ли мне защититься от сальто на диске?

Answer 1

Я почти уверен, что ответ «нет», но если вы хотите быть параноиком, вы можете предварительно вычислить хеш MD5 перед загрузкой, сравните его с хешем MD5, полученным после выгрузки, а затем при загрузке вычислите хеш MD5. загруженных данных и сравните их с сохраненным хешем.

Я не уверен, какой именно риск тебя беспокоит. В какой-то момент вы должны отложить риск для кого-то еще. Подпадают ли «поврежденные данные» под соглашение Amazon об уровне обслуживания? Предположительно они знают, что такое хеш файла , как предполагается , и если хеш данных, которые они вам дают, не совпадает, то это, очевидно, их проблема.

Полагаю, есть и другие подходы:

• Храните ваши данные с FEC , чтобы вы могли обнаруживать и исправлять N-битные ошибки вплоть до вашего выбора N.
• Храните ваши данные более одного раза в Amazon S3, возможно, в их центрах обработки данных в США и Европе (я думаю, что в Сингапуре скоро появится и новый), с RAID-подобной избыточностью, так что вы можете восстановить свои данные, если их количество источников исчезают или становятся испорченными.

Это действительно зависит от того, насколько ценными для вас являются данные, которые вы храните, и какой риск вы готовы принять.

Answer 2

Я вижу ваш вопрос с двух точек зрения, теоретической и практической.

С теоретической точки зрения, да, вы должны быть обеспокоены - и не только о переключении битов, но и о некоторых других возможных проблемах. В частности в разделе 11.5 клиентских соглашений говорится, что Amazon

НЕ ПРЕДОСТАВЛЯЙТЕ НИКАКИХ ПРЕДСТАВЛЕНИЙ ИЛИ ГАРАНТИЙ ЛЮБОГО ВИДА, ЯВНЫХ, ПОДРАЗУМЕВАЕМЫХ, УКАЗАННЫХ ИЛИ ИНЫХ, В ОТНОШЕНИИ ПРЕДЛОЖЕНИЙ ОБСЛУЖИВАНИЯ. (..omiss ..) МЫ И НАШИ ЛИЦЕНЗИАРЫ НЕ ГАРАНТИРУЕМ, ЧТО ПРЕДЛОЖЕНИЯ ОБСЛУЖИВАНИЯ БУДУТ ФУНКЦИОНИРОВАННЫМ, КАК ОПИСАНО, БУДЕТ НЕПРЕРЫВНО ИЛИ ОШИБКИ, ИЛИ БЕЗ ВРЕДНЫХ КОМПОНЕНТОВ, ИЛИ ЧТО ДАННЫЕ, КОТОРЫЕ ВЫ ХОТИТЕ В ПРЕДЛОЖЕНИЯХ ОБСЛУЖИВАНИЯ, БЕЗОПАСНЫ НЕ ПРОТИВ УТРАЧЕННЫХ ИЛИ УЩЕРБНЫХ.

Теперь на практике меня это не касается. Если ваши данные будут потеряны, вы будете писать об этом в блоге и (хотя они могут не столкнуться с какими-либо судебными исками), их бизнес будет в значительной степени завершен.

С другой стороны, это зависит от того, насколько важны ваши данные. Предположим, что вы катали свои собственные вещи в ваших собственных центрах данных. Как вы планируете там аварийное восстановление? Если вы скажете: я бы просто держал две копии в двух разных стойках, просто использовал бы ту же технику с Amazon, возможно, держал бы две копии в двух разных центрах обработки данных (поскольку вы писали, что вам не интересно как защита от переворотов, я приведу здесь только тривиальный пример)

Answer 3

Вероятно, нет: Amazon использует контрольные суммы для защиты от переворачивания битов, регулярно просматривая данные в покое, гарантируя, что перестановки битов не произошло. Таким образом, если у вас нет повреждений во всех экземплярах данных в пределах интервала циклов проверки целостности, все будет в порядке.

Внутренне S3 использует контрольные суммы MD5 во всей системе для обнаружения / защиты от битовых флипов. Когда вы помещаете объект в S3, мы вычисляем MD5 и сохраняем это значение. Когда вы ПОЛУЧАЕТЕ объект, мы пересчитываем MD5 и возвращаем его обратно. Если наш сохраненный MD5 не соответствует значению, которое мы вычисляем при потоковой передаче объекта назад, мы вернем ошибку для запроса GET. Затем вы можете повторить запрос.

Мы также постоянно циклически перебираем все данные в состоянии покоя, пересчитывая контрольные суммы и проверяя их по MD5, который мы сохранили при первоначальном сохранении объекта. Это позволяет нам обнаруживать и исправлять биты, которые происходят в данных в состоянии покоя. Когда мы находим немного перевернутых данных в покое, мы восстанавливаем их, используя избыточные данные, которые мы храним для каждого объекта.

Вы также можете защитить себя от битовых флипов во время передачи на и от S3, предоставляя контрольную сумму MD5, когда вы кладете объект (мы ошибемся, если полученные данные не соответствуют контрольной сумме), и проверяя MD5 при GET объект.

Источник: https://forums.aws.amazon.com/thread.jspa?threadID=38587

Answer 4

Есть два способа прочитать ваш вопрос:

1. «Является ли Amazon S3 идеальным?»
2. «Как мне справиться со случаем, когда Amazon S3 не идеален?»

Ответ на (1) почти наверняка "нет". У них может быть много защиты, чтобы приблизиться, но все еще есть вероятность отказа.

Это оставляет (2). Дело в том, что устройства выходят из строя, иногда очевидными способами, а иногда - способами, которые кажутся работающими, но дают неправильный ответ. Чтобы справиться с этим, многие базы данных используют CRC для каждой страницы, чтобы гарантировать, что прочитанная страница с диска совпадает с той, которая была записана. Этот подход также используется в современных файловых системах (например, ZFS , которые могут записывать несколько копий страницы, каждая с CRC для обработки сбоев raid-контроллера. Я видел, как ZFS исправляет однобитовые ошибки с диска чтение второй копии; диски не идеальны.)

Как правило, вы должны иметь проверку, чтобы убедиться, что ваша система работает, как вы ожидаете. Использование хеш-функции - это хороший подход. Какой подход вы используете при обнаружении сбоя, зависит от ваших требований. Хранение нескольких копий, вероятно, является лучшим подходом (и, безусловно, самым простым), поскольку вы можете получить защиту от сбоев сайта, сбоев подключения и даже сбоев поставщика (выбрав второго поставщика) вместо просто избыточности в самих данных с помощью FEC.