Должен ли я беспокоиться о бит-рейдах на Amazon S3?

Question

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

Answer 1

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

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

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

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

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

Answer 2

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

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

ДЕЛАТЬ ПРЕДСТАВЛЕНИЯ ИЛИ ГАРАНТИЙ ЛЮБОГО РОДА, ЯВНЫХ, ПОДРАЗУМЕВАЕМЫХ, УСТАНОВЛЕННЫХ ЗАКОНОМ ИЛИ ИНАЧЕ В ОТНОШЕНИИ СЛУЖБЫ подношения. (..omiss ..) МЫ И НАШИ ЛИЦЕНЗИАРЫ НЕ ГАРАНТИРУЕМ, ЧТО ПРЕДЛАГАЕМЫЕ УСЛУГИ БУДУТ ФУНКЦИЕЙ, ОПИСАННОЙ ОПИСАНИЕМ, БУДУТ БЕСПЕРЕБОЙНЫМИ ИЛИ БЕСПЛАТНЫМИ ИЛИ БЕСПЛАТНЫМИ СЛУЧАЙНЫМИ КОМПОНЕНТАМИ, ИЛИ ЧТО ДАННЫЕ, КОТОРЫЕ ВЫ ЗАПРЕЩАЕТЕСЬ В СЕРВИСНЫХ ПРЕДЛОЖЕНИЯХ, БУДУТ БЕЗОПАСНЫМИ ИЛИ НЕ ПРОЧИЕ УБЫТКИ ИЛИ ПОВРЕЖДЕННЫЕ.

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

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

Answer 3

есть два способа читать ваш вопрос: «Является Amazon S3 совершенных»

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

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

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

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

Answer 4

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

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

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

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

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