Comments 23
Событие выхода из строя 3х дисков одновременно становится обыденным, и должно случаться несколько раз в год (3-6 раз, расчёты опускаю).
Упрекая других в отсутствии расчётов, покажите-ка доказательство этого утверждения. Если можно, без рассуждений, а просто взяв статистику отказов и включив теорвер, ок?
Время репликации данных для 1Тб диска составляет примерно 5-8 часов.
Упрекая других в отсутствии расчётов, покажите-ка доказательство этого утверждения. Если можно, без рассуждений, а просто взяв статистику отказов и включив теорвер, ок?
Время репликации данных для 1Тб диска составляет примерно 5-8 часов.
Вероятность выхода из строя 1 диска за год — 5% (взято из статистики Google — 2-10% в зависимости от возраста диска).
Время восстановления 12 часов (5-8 часов, это когда 2 диска рядом — абсолютно неприменимо для Swift)
В году 8760 часов. Вероятность выхода из строя диска за 12 часов — 0,0000685. Для 3000 дисков — 0.202
Событие для 3х дисков 0.202% ^ 3 = 0,0082
Таких промежутков по 12 часов в году — 730. 0,0082*730= 5,986 событий в год.
Время восстановления 12 часов (5-8 часов, это когда 2 диска рядом — абсолютно неприменимо для Swift)
В году 8760 часов. Вероятность выхода из строя диска за 12 часов — 0,0000685. Для 3000 дисков — 0.202
Событие для 3х дисков 0.202% ^ 3 = 0,0082
Таких промежутков по 12 часов в году — 730. 0,0082*730= 5,986 событий в год.
Не понял, каким образом вы умножаете 0.202 на само себя? Нас же интересует не _любой_ диск, а диск с резервными копиями?
(с вашего позволения я смухлюю и посчитаю сумму вероятности отказа двух дисков как сумму вероятности двух несовместимых событий (то есть просто просуммирую)).
Так что имеем 0.202*(0,0000685+0,0000685) = .0000276740. После умножения на 730 имеем .0202020200. Таким образом, мы имеем 2% вероятность наступления такого события.
Алсо, мы не гугль, у нас много дисков, у дисков вероятность отказа примерно 1% в год, 5-12% или 1% зависит от того, сигейт ли это или нет. Плюс ресинк длится всё-таки не больше 8 часов, потому что 10G уже давно объективная реальность.
А на самом деле, мы просто неправильно считаем, так как считать вероятность нужно как плотность относительно гигабайта. Ведь свифт оперирует не массивами и дисками, а объектами.
ЗЫ А ещё нужно учитывать, что львиная доля заменяемых дисков заменяется не по «смерти», а по первому отказу (первой write/read error).
(с вашего позволения я смухлюю и посчитаю сумму вероятности отказа двух дисков как сумму вероятности двух несовместимых событий (то есть просто просуммирую)).
Так что имеем 0.202*(0,0000685+0,0000685) = .0000276740. После умножения на 730 имеем .0202020200. Таким образом, мы имеем 2% вероятность наступления такого события.
Алсо, мы не гугль, у нас много дисков, у дисков вероятность отказа примерно 1% в год, 5-12% или 1% зависит от того, сигейт ли это или нет. Плюс ресинк длится всё-таки не больше 8 часов, потому что 10G уже давно объективная реальность.
А на самом деле, мы просто неправильно считаем, так как считать вероятность нужно как плотность относительно гигабайта. Ведь свифт оперирует не массивами и дисками, а объектами.
ЗЫ А ещё нужно учитывать, что львиная доля заменяемых дисков заменяется не по «смерти», а по первому отказу (первой write/read error).
Тут есть гуру теорвера?
Выше уже выяснили, где у товарища ошибка. Он считает, что после смерти первого винта, для потери данных достаточно смерти любых других двух дисков. Любых из 3000, а не тех, что с данными.
Товарищ правильно считает, если исходить из тезиса статьи: «Если все копии разбросаны по дискам случайно, как это сделано в Swift, то наверняка какой-то из файлов окажется в трёх умерших дисках.»
Показывайте математику. «наверняка» — это такая единица измерения (равна примерно 0.01-100 сигма в зависимости от обстоятельств). Используется в отечественной космонавтике постсоветского периода.
Вероятность того, что есть хоть один файл, три копии которого лежат как раз на трёх вышедших из строя дисках равна (1-(1-1/N^3)^K), где N — число жестких дисков, а K — число файлов.
Если число файлов больше N^3 то вероятность близка к 1.
Сколько файлов реально хранит Swift я не знаю.
Если число файлов больше N^3 то вероятность близка к 1.
Сколько файлов реально хранит Swift я не знаю.
Свифт хранит по файлу на каждый файл клиента.
о, осознал суть проблемы в рассуждениях. Неявно подразумевалось, что репликация файла займёт столько же, сколько репликация диска. А это не так.
Если диск 1Тб и средний размер файла 1М, это миллион файлов (пока опускаем в сторону неполную утилизацию места). Время репликации 1М файла — меньше 1/10 секунды. Какова вероятность, что в этот момент выйдут из строя оставшиеся два жёстких диска?
Мне кажется, что этот вопрос нужно разбирать аккуратно, с нуля, и без «очевидно», «вероятно» и т.д.
о, осознал суть проблемы в рассуждениях. Неявно подразумевалось, что репликация файла займёт столько же, сколько репликация диска. А это не так.
Если диск 1Тб и средний размер файла 1М, это миллион файлов (пока опускаем в сторону неполную утилизацию места). Время репликации 1М файла — меньше 1/10 секунды. Какова вероятность, что в этот момент выйдут из строя оставшиеся два жёстких диска?
Мне кажется, что этот вопрос нужно разбирать аккуратно, с нуля, и без «очевидно», «вероятно» и т.д.
К сожалению это далеко не единственная фундаментальная проблема дизайна Swift.
Там есть большие проблемы с репликацией на больших объёмах, с производительностью доступа при большой плотности, etc.
Там есть большие проблемы с репликацией на больших объёмах, с производительностью доступа при большой плотности, etc.
Вы не разобрались в топики и сделали выводы. Swift предлагает покупать дешевое железо, не строить никаких рейдов и прочее. Поэтому идет тупое копирование тройное. + вы отталкиваетесь от количества дисков, а нужно от количества ваших нод. Кстати говоря в BigData (Apache Hadoop) тоже идет тройное копирование всех данных в файловое системе HDFS, но его можно менять к примеру поставить 10 копий. Все зависит от вашего количества нод.
И не стоит забывать, что это сырой продукт. Когда уже народ, который берется за такие продукты поймет, что для внедрения и использование, нужно иметь 10 девелоперов для допилования и быстрого фикса багов.
И не стоит забывать, что это сырой продукт. Когда уже народ, который берется за такие продукты поймет, что для внедрения и использование, нужно иметь 10 девелоперов для допилования и быстрого фикса багов.
Я к сожалению читал только доки по Swift поэтому конкретно не могу с вами спорить. Не стоит забывать, что Swift используется Rackspace в продакшене. Полный аналог Amazon S3, Rackspace Cloud Files. Думаю там толковые ребята работают и знают что делают. А вы тупо взяли и залажали все. Возможно у вас стоят задачи, которые не решает Swift.
Представьте что у Вас DVD плеер, в нем 3 щели для трех дисков. И сами фильмы всегда идут в 3х копиях.
И что б просмотреть фильм, надо вставить сразу 3 диска.
Ваш телефон принимает/отправляет сразу 3 SMS, а штрих коды выглядели бы приблизительно так: dl.dropbox.com/u/20909492/3copiesqr.png
На орбите висят сразу 3 спутника и вещают один, вещая один и тот же канал.
Так бы выглядел мир если б для надежности всегда использовалось лишь простое дублирование.
И что б просмотреть фильм, надо вставить сразу 3 диска.
Ваш телефон принимает/отправляет сразу 3 SMS, а штрих коды выглядели бы приблизительно так: dl.dropbox.com/u/20909492/3copiesqr.png
На орбите висят сразу 3 спутника и вещают один, вещая один и тот же канал.
Так бы выглядел мир если б для надежности всегда использовалось лишь простое дублирование.
Вы неправильно понимаете, зачем делается 3 копии.
Все 3 копии должны быть в разных ДЦ, при этом все 3 копии сделаны на одинаковом железе. Во всех ДЦ (а их может быть и больше 3) есть железо, на котором исполняется код, который запрашивает данные из хранилища, и при этом данные приходят из ближайшей (локальный ДЦ, затем соседний ДЦ по какой либо метрике) копии. При такой схеме выход из строя одного ДЦ — штатная ситуация, не влияющая на работу всей системы в целом.
Если вылетает 1 диск — то запускается восстановление. 3 копии — чтобы был кворум для чтения/записи при выходе из строя 1 диска или при отключении одного из ДЦ. Кворум на 2 копиях, по понятным причинам, мало возможен. При использовании кодов Рида-Соломона читать из локального дц уже получится не всегда, дополнительно возникают вопросы, как записывать данные, если диск вылетел (возможно, придётся переводить этот кусок хранилища в режим read-only).
Все 3 копии должны быть в разных ДЦ, при этом все 3 копии сделаны на одинаковом железе. Во всех ДЦ (а их может быть и больше 3) есть железо, на котором исполняется код, который запрашивает данные из хранилища, и при этом данные приходят из ближайшей (локальный ДЦ, затем соседний ДЦ по какой либо метрике) копии. При такой схеме выход из строя одного ДЦ — штатная ситуация, не влияющая на работу всей системы в целом.
Если вылетает 1 диск — то запускается восстановление. 3 копии — чтобы был кворум для чтения/записи при выходе из строя 1 диска или при отключении одного из ДЦ. Кворум на 2 копиях, по понятным причинам, мало возможен. При использовании кодов Рида-Соломона читать из локального дц уже получится не всегда, дополнительно возникают вопросы, как записывать данные, если диск вылетел (возможно, придётся переводить этот кусок хранилища в режим read-only).
в хранилище 3000 дисков. за год эксплуатации выйдет из строя 1-5% дисков. Событие выхода из строя 3х дисков одновременно становится обыденным, и должно случаться несколько раз в год (3-6 раз, расчёты опускаю). Если все копии разбросаны по дискам случайно, как это сделано в Swift, то наверняка какой-то из файлов окажется в трёх умерших дисках.Надуманный вывод.
Если событие выхода 3 дисков из строя одновременно (из 3000) раз в год обыденное, то событие выхода из строя именно нужных для эпик-феила 3 дисков это как получить на трех брошенных кубиках (упрощая для ТС) 3 единицы одновременно с одного раза… при условии что на каждом кубике не 6, а 1000 граней. Что весьма маловероятно.
Для 3000 дисков, при 100 partitions на один диск epic fail будет происходить с вероятностью 1/10000.
У Amazon S3 заявленая надежность составляет 99,999999999%.
Приблизительно тоже самое можно было бы добиться и в Swift, если б он был нормально спроектирован.
У Amazon S3 заявленая надежность составляет 99,999999999%.
Приблизительно тоже самое можно было бы добиться и в Swift, если б он был нормально спроектирован.
Очень хороший пример с кубиками. 1000 граней на кубике. Когда объекты на дисках лежат упорядочено (как в RAID1), это так и происходит. Но в Swift то что лежит на одном диске — копии размазаны по 100-1000 другим дискам. Изза этого вероятность потери данных совершенно другая.
С одной стороны Вы правы, мы не просто не подумали о том, о чем Вы говорите поначалу.
С другой стороны, даже при «размазывании» инфы по дискам — ведь когда речь идет об 1-5% отказов, речь ведь не идет о смерти сразу всего диска, а именно о непригодности его к дальнейшей эксплуатации, и если при этом из реальных данных погибает 1/100-1/1000 от объема диска, то это в целом не меняет ситуации с кубиками.
С другой стороны, даже при «размазывании» инфы по дискам — ведь когда речь идет об 1-5% отказов, речь ведь не идет о смерти сразу всего диска, а именно о непригодности его к дальнейшей эксплуатации, и если при этом из реальных данных погибает 1/100-1/1000 от объема диска, то это в целом не меняет ситуации с кубиками.
Вы имеете несколько странное представление об источнике «правила трех копий».
Вторая копия необходима на тот случай, если выйдет из строя первая. Но после выхода из строя первой копии потребуется выполнить полное копирование диска, а это длительный процесс. Получается, что есть ненулевая вероятность того, что вторая копия накроется в процессе восстановления первой. Отсюда и третья копия.
Да, по поводу статистики. Если каждый файл находится на трех дисках, то вероятность полной потери файла равна вероятности одновременного выхода из строя этих трех дисков. И от общего количества дисков в кластере тут ничего не зависит.
Для сравнения: сколько дисков умирает во всем мире за сутки? Но вы же не боитесь, что в один из дней этими умершими дисками окажутся исключительно ваши диски? С файлами так же.
Вторая копия необходима на тот случай, если выйдет из строя первая. Но после выхода из строя первой копии потребуется выполнить полное копирование диска, а это длительный процесс. Получается, что есть ненулевая вероятность того, что вторая копия накроется в процессе восстановления первой. Отсюда и третья копия.
Да, по поводу статистики. Если каждый файл находится на трех дисках, то вероятность полной потери файла равна вероятности одновременного выхода из строя этих трех дисков. И от общего количества дисков в кластере тут ничего не зависит.
Для сравнения: сколько дисков умирает во всем мире за сутки? Но вы же не боитесь, что в один из дней этими умершими дисками окажутся исключительно ваши диски? С файлами так же.
Допустим в хранилище 3000 дисков. Согласно статистики от Google, за год эксплуатации выйдет из строя 1-5% дисков. Событие выхода из строя 3х дисков одновременно становится обыденным, и должно случаться несколько раз в год (3-6 раз, расчёты опускаю).
Это так в одном случае, если все 3000 дисков находятся в одной RAID-группе типа RAID-6. Что, совершенно ясно, в жизни не так.
Например при размере RAID-группы в 10 дисков (для простоты расчета), то есть 8d+2p, на массиве в 3000 дисков могут одновременно выйти из строя 600 (!) дисков, с полным сохранением хранимой на массиве информации. По 2 диска в каждой из 300 RAID-групп.
Это так в одном случае, если все 3000 дисков находятся в одной RAID-группе типа RAID-6. Что, совершенно ясно, в жизни не так.
Например при размере RAID-группы в 10 дисков (для простоты расчета), то есть 8d+2p, на массиве в 3000 дисков могут одновременно выйти из строя 600 (!) дисков, с полным сохранением хранимой на массиве информации. По 2 диска в каждой из 300 RAID-групп.
— OpenStack пытается раскрутиться через громкое слово «облако» и поддержке «Rackspace and NASA». Другие знаменитые компании подключаются к этому проекту. Хотя всё может оказаться не так радужно. Бесконечной масштабируемости в настоящее время нет.
Очень неожиданный вывод, учитывая что Swift сам по себе не является неотъемлимой частью OpenStack. Можно без особенных проблем сконфигурировать кластер для работы с любым S3-совместимым хранилищем. И, поверьте, большая часть коммьюнити совсем не в восторге от Swift, который все еще страдает кучей детских болячек.
Очень неожиданный вывод, учитывая что Swift сам по себе не является неотъемлимой частью OpenStack. Можно без особенных проблем сконфигурировать кластер для работы с любым S3-совместимым хранилищем. И, поверьте, большая часть коммьюнити совсем не в восторге от Swift, который все еще страдает кучей детских болячек.
Идея насчет использования более эффективных алгоритмов реплицирования для больших хранилищ интересная, но расчет и выводы в корне неправильные.
Вероятность выхода из строя трех дисков в течение 12 часов вычисляется как произведение вероятностей выхода одного диска за 12 часов, т.е.
(68,5*10^-6 )^3 = 0.3*10^-12. Вероятность наступления такого события за 1 год =730*0.3*10^-12=219*10^-12.
Для 3000 дисков количество таких событий за 1 год составит 0.6*10^-6 Т.е. надо ждать около 2 миллионов лет, чтобы такое событие произошло.
Разработчики пошли по самому простому пути и предложили максимально простой и максимально надежный алгоритм резервирования. Да, при этом он получается слишком избыточным, но это пожалуй единственный его основной минус такого рода.
BTW, GFS использует точно такой же алгоритм резервирования — создания как минимум трех реплик для хранимых чанков информации. Наверное из-за того, что создание трех копий делает вероятность наступление события epic fail ничтожно малой, а реализацию алгоритма — простой и предсказуемой. Хотя они не раз отмечали, что работают над оптимизацией алгоритма, но пока ничего нового на замену ему не пришло.
Вероятность выхода из строя трех дисков в течение 12 часов вычисляется как произведение вероятностей выхода одного диска за 12 часов, т.е.
(68,5*10^-6 )^3 = 0.3*10^-12. Вероятность наступления такого события за 1 год =730*0.3*10^-12=219*10^-12.
Для 3000 дисков количество таких событий за 1 год составит 0.6*10^-6 Т.е. надо ждать около 2 миллионов лет, чтобы такое событие произошло.
Разработчики пошли по самому простому пути и предложили максимально простой и максимально надежный алгоритм резервирования. Да, при этом он получается слишком избыточным, но это пожалуй единственный его основной минус такого рода.
BTW, GFS использует точно такой же алгоритм резервирования — создания как минимум трех реплик для хранимых чанков информации. Наверное из-за того, что создание трех копий делает вероятность наступление события epic fail ничтожно малой, а реализацию алгоритма — простой и предсказуемой. Хотя они не раз отмечали, что работают над оптимизацией алгоритма, но пока ничего нового на замену ему не пришло.
Sign up to leave a comment.
OpenStack Swift. Не все три копии одинаково полезные