Comments 11
3-кратная репликация, размер чанка 1 Мб, 4 ТБ диски, 1000 серверов в кластере, каждый сервер с 12 дисками, ARR для диска составляет 1%, 1 день на замену сломавшегося диска.
Расчет:
- 1000 серверов, каждый с 12 дисками, итого в кластере 12'000 дисков. Отдельные диски вмещают до 4 ТБ / 1 МБ = 4'000'000 чанков.
Когда один диск ломается, 4'000'000 его чанков становятся недоступными. Каждый из оставшихся в кластере дисков будет содержать приблизительно 4'000'000 / 12'000 = 333 чанка данных, хранившихся на сломанном диске. Это означает, что любые 2 отказавших диска в кластере приведут к тому, что 333 чанка в кластере останутся с единственной репликой. Эти 333 чанка должны лежать на разных дисках. Итого, когда любые 2 жестких диска в кластере одновременно выходят из строя, отказ любого из 333 жестких дисков, содержащих последнюю реплику наших данных, приведет к потере данных. - 12000 дисков в кластере и ARR 1%, дает нам 12000 * 1% = 120 отказов жестких дисков в год. Если замена происходит в течение 1 дня, то когда один жесткий диск вышел из строя, вероятность того, что сломается еще один, равна 11999 * 1% * 1/365 ~= 33%. Поскольку у нас 120 сломанных дисков в год, каждый из которых требует ремонта в течение 1 дня, примерно 120 * 33% ~= 39,5 дней в году, мы будем работать в кластере с двумя отказавшими дисками.
- В кластере с двумя отказавшими дисками мы зависим от 333 других дисков, содержащих последнюю живую реплику данных. Какова вероятность того, что один из них откажет? 333 диска * 1% ARR * 39,5 дней в году без 2 дисков / 365 = 36%, в год. Таким образом, примерно раз в три года вы потеряете один чанк своих данных. Для многих приложений недоступность одного чанка — это уже проблема.
Так или иначе, это никак не 100'000'000 лет. Теперь добавим сверху падения других компонент кроме дисков, проблемы с сетью, перезагрузки серверов (накатываем обновления, например), когда часть чанков тоже становится недоступна, время на обнаружение проблемы с диском и восстановление данных, и т.д. Итоговая цифра намного больше соотносится с реальностью, чем ваши вычисления. Уж вы-то в Яндексе должны знать на основании своего опыта, что для кластера с 1000 машин и 3-кратной репликацией потеря данных будет происходить раз в год или чаще.
Вы делаете ровно ту же ошибку, что и Клеппман в оригинальной статье. А именно: не учитывается динамика.
Это проявляется в том, что вы неявно предполагаете, что время жизни диска и время жизни чанка — одинаковое. Понятно, что выпадание диска — это выпадание чанков этого диска. Однако характерное время восстановления чанка не совпадает со временем замены дисков и является сильно меньшей величиной. Поэтому даже если во время поломки диска сломается другой с этим же чанком, то это может быть не фатально, т.к. чанк с этого диска уже мог отреплицироваться на третий за существенно меньшее время.
Таким образом, расчет сломанных дисков без учета механизма репликации — странная затея, которая дает фундаментально неверные результаты.
Вы работаете с реальными кластерами подобных размеров, и сами используете LRC-8-2-2 (то есть можно потерять до 2 реплик из группы без потери данных) — какая у вас статистика по потерям чанков? Неужели действительно ни одной потери? Как следует из вашей формулы с 100 000 000 лет, даже вы имея 100 кластеров в течении 10 лет, получите вероятность отказа вероятность отказа всего 0.001%
В предложенном подходе я хотел продемонстрировать качественный анализ системы без привязки к конкретному железу. Если хочется посчитать для конкретных параметров — то сделать это можно легко, просто подставив соответствующие цифры.
в зависимости от нагрузки на кластере это время может быть довольно значительным, полчаса-час
А может быть и другим. Не суть. Просто получатся другие числа. Модель при этом не поменяется.
Плюс диск не всегда отказывает и исчезает, иногда он начинает просто отдавать битые данные. Диск в наличии, а данные на нем неправильные, на диагностику такой проблемы тоже нужно время.
Да, это действительно проблема. И такое поведение можно включить в модель без проблем.
Вы работаете с реальными кластерами подобных размеров, и сами используете LRC-8-2-2 (то есть можно потерять до 2 реплик из группы без потери данных)
Мы используем разные подходы. Конкретные цифры я бы не хотел называть по понятным причинам. В данной статье используются некоторые цифры, приближенные к какой-то реальности.
В любом случае, я хотел продемонстрировать моделирование и подход, позволяющий делать выводы о поведении системы. Простые подходы и рассуждения, подобные этому, к сожалению, неверны. Думаю, по цифрам и количеству учитываемых факторов становится понятно, почему.
Люди могут прочитать, и пойти деплоить кластеры Hadoop на 1000 нод с r=3 и думать, что они могут спать спокойно. Но, например, при выпадении ToR свича вы потеряете сразу всю стойку. Та же HDFS хранит r=3, но при этом 2 копии по умолчанию приземляются на одну стойку, значит при выпадении стойки приблизительно треть хранимых ей блоков оказывается в единственном экземпляре. Треть полной стойки двухюнитовых серверов — это до 320'000'000 чанков, соответственно каждый из оставшихся в кластере дисков будет в среднем хранить 27'210 чанков, у которых осталась одна последняя живая реплика. Если у сети нет oversubscription, то дореплицироваться эти чанки в идеальном случае будут: 27210 чанков * 1MB / 50 MB/sec ~= 9 минут. Плюс время на обнаружение проблемы. Плюс заметим, что в используемой у вас LRC-8-2-2 нужно еще и контрольные чанки пересчитать, то есть при восстановлении вам придется прочитать раз в 6 больше данных, то есть мы уже говорим о почти часе на абсолютно пустом кластере. Плюс в критический момент оказывается, что Hadoop сам не инициирует восстановление коэффициента репликации, и делать это нужно ручками на уровне файлов или директорий. А во время восстановления кластера выпадение еще одного любого диска — это недоступность данных.
Поэтому я склонен считать что ваши рассуждения, к сожалению, тоже не верны. Автор критикуемой вами статьи не учитывает динамику. Вы учитываете динамику, но не учитываете другие возможные причины отказа — проблемы сетевого оборудования, проблемы питания, возвращение нодами некорректных данных, ошибки памяти, человеческий фактор и т.д. Не учитываете также то, что «динамика» — вещь относительная, и для вашего кластера и кластера Hadoop динамика восстановления будет отнюдь не одинаковая. Добавление же всех этих факторов в модель сделает её настолько сложной, что практическая польза от нее будет весьма спорной. Но на бумаге выглядит хорошо.
Модель хорошая, но боюсь, что из вашей статьи могут сделать неверные выводы
Не надо бояться. Цифра получена исходя из предположений о величинах констант скоростей процессов. Для других величин может получиться другая цифра.
Особенно режет глаза цифра в 100'000'000 лет для кластера в 1000 нод.
Аргументация в стиле: "мне цифра не нравится", конечно, имеет право на существование, но полезность этого крайне сомнительна. Гораздо конструктивнее, если вы найдете, например, изъян в модели и обоснуете его.
Люди могут прочитать, и пойти деплоить кластеры Hadoop на 1000 нод с r=3 и думать, что они могут спать спокойно. Но, например, при выпадении ToR свича вы потеряете сразу всю стойку.
Для этого есть rack awareness, который присутствует во всех уважающих себя крупных системах.
Вообще, мне не очень нравится рассуждать в категориях "а вдруг кто-то что-то подумает".
Плюс заметим, что в используемой у вас LRC-8-2-2 нужно еще и контрольные чанки пересчитать
Очень рад, что вы знаете, что я использую. Может еще расскажете, сколько чанков мы теряем? Думаю, всем было бы интересно.
Поэтому я склонен считать что ваши рассуждения, к сожалению, тоже не верны.
К сожалению, не могу разделить вашу склонность.
Вы учитываете динамику, но не учитываете другие возможные причины отказа — проблемы сетевого оборудования, проблемы питания, возвращение нодами некорректных данных, ошибки памяти, человеческий фактор и т.д.
Давайте я процитирую свою статью. Оказывается, не все в состоянии прочитать написанное.
Конечно, данная модель является лишь первым приближением к тому, что реально происходит на кластере. Здесь мы лишь учитывали наиболее значимые процессы для получения качественного результата…
Ноды кластера могут выходить из строя из-за различных сбоев оборудования. Поломка конкретного узла как правило имеет различную вероятность. Более того, поломка, например, процессора, не теряет данные, а лишь дает временную недоступность ноды…
Добавление в модель нод различных типов: с частично поврежденными дисками, забаненные и др. Например, можно детально проанализировать влияние выключения целой стойки и выяснения характерных скоростей перехода кластера в стационарный режим.
Каждый диск имеет несколько отличающиеся характеристики чтения/записи, включая латентность и пропускную способность. Тем не менее, можно более точно оценивать константы скоростей процессов, интегрируя по соответствующим функциям распределения характеристик дисков...
Если добавить все это в модель, она была бы еще более сложной. Задача стояла в демонстрации нового подхода на вполне понятном и простом примере. Это первый подход к снаряду, который можно и нужно развивать и дополнять.
Скорость репликации задается параметром 50МБ/с. Обычные крутящиеся диски дают производительность на уровне 100МБ/с, а твердотельные еще выше. Таким образом, пропускная способность репликации задает константу скорости репликации k_r. Можно возразить, что пропускная способность репликации не учитывает время, необходимое на первый seek диска, установку соединения и т.п. Эти факторы можно учесть в константе планирования репликации k_s, просто просуммировав соответствующие времена. При этом k_s — это не константа скорости обнаружения, а константа скорости планирования процесса репликации, включая обнаружение, постановку в пул задач, обработку, получение метаинформации и т.п.
Тут есть другой интересный момент: а что будет, если кластер будет настолько большим, что весь объем не сможет равномерно распределиться по всем нодам из-за дискретного характера чанков. Простой расчет показывает, что количество чанков при размере одного чанка 1 МБ в рассматриваемом случае с размером 5 ТБ на ноду будет равно 5 000 000, что с большим запасом покрывает существующие размеры кластеров. Если же окажется, что это не так (очень большие чанки, мало места на дисках и т.п.), то эффективно такое также можно учесть, просто добавив некоторую константу к времени планирования репликации.
Кинетика больших кластеров