Pull to refresh

Comments 14

Занятно, но есть один нюанс.
> Потерянные данные составляют только малую часть всего набора данных в кластере
Изменение размера данных меняет дело. Если считать, что и маленький, и большой кластеры собраны из одинаковых нод по N Гбайт, то в большом ребилд N Гбайт (при потере ноды) занимает примерно в P раз меньше времени (если в большом в P раз больше нод). И вероятность отказа второй ноды за время ребилда будет уже не 0,1%, а 0,1%/P, что резко просаживает правую часть графика.
Время ребилда не может быть меньше чем время считывания с оставшихся двух реплик, что от размеров кластера не зависит.
Не могу согласиться.
Схема репликации «нода целиком на две других ноды» наивна и устарела вместе с ранними версиями DRBD. Но даже если так, то время ребилда будет определяться не скорость считывания с оставшихся двух нод, а скоростью записи на новую.
В современном мире на каждой ноде хранится несколько кусков данных (в Ceph, например, куски называются placement group, PG), реплики каждого куска находятся на своей паре нод, то есть теоретически реплики данных равномерно размазаны по всему кластеру. На практике они равномерно размазываются, пока количество нод (в терминологии Ceph ближайший синоним — OSD) не станет сильно больше количества PG на одном OSD.
Про зависимость вероятности потери данных от количества нод уже подумано и написано в документации.
In other words, if the probability of losing one OSD is 0.0001% during the recovery time frame, it goes from 17 * 10 * 0.0001% in the cluster with 10 OSDs to 4 * 20 * 0.0001% in the cluster with 20 OSDs.
In a nutshell, more OSDs mean faster recovery and a lower risk of cascading failures leading to the permanent loss of a Placement Group.
Скорость считывания имеющегося деградировавшего куска увеличить нельзя, а запись можно временно на быстрый буфер делать (а потом перенести на более медленное хранилище), так что фундаментально скорость чтения важнее.
не важно, вся ли нода восстанавливается или диск или кусок. Если падает один жесткий диск, то нужно восстановить все фрагменты которые на нём были с других дисков. Пусть число фрагментов на диск равно Х. Число операций восстановления которые нужно произвести равно Х. Каждая операция длится Т. Шанс падения во время восстановления пропорционален 1/Т и для отдельного фрагмента не зависит от числа нод. Вероятность того, что хотя бы одна из операций восстановления упадёт пропорционален Х/Т и тоже не зависит от числа нод. При этом не важно, на одном диске лежат «вторые» копии Х или на разных. Ошибка восстановления тут — пуассоновский процесс. Шанс отказа для маленькой порции мал, но порций много, так что в среднем одно и то же.

Всё просто, существует вероятность необратимой ошибки чтения, которая обычно тем выше чем больше кусок. Однако чем больше кусок, тем меньше их надо что бы обеспечить тот же объем данных. Вероятность потери данных на совсем равна вероятности трех(степень репликации) последовательных отказов. Каждое считывание может закончится отказом. Чем больше нод, тем больше считываний (степень загрузки считаем неизменной).
Мне незнакомы промышленные системы с кэшем больше самого хранилища. In-memory — да, но и в них упрётся в запись. Ну пусть будет чтение, не принципиально.
Шанс падения во время восстановления пропорционален 1/Т
<...>
При этом не важно, на одном диске лежат «вторые» копии Х или на разных.
Я не понял, мы делим единицу на время и получаем что-то в герцах? Может, здесь 1/X? По существу соглашусь, второй диск может сломаться с вероятностью независимой от количества нод.

Но в статье про RF=3, для потери данных нужно сломать два диска, вероятность чего пропорциональна 1/X^2, что снижает вероятность потери относительно линейной графика в статье.

И относительно маленького кластера, да.
примерно один день требуется для замены ноды и восстановления потерянных данных на новые диски

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


А по поводу самой вероятности потери данных. Как я понял, если мы будем для каждого куска данных выбирать наугад три ноды, то начинается комбинаторика и вероятность потери хотя бы одного куска большая. А что будет, если ноды будут "стремиться" хранить одни и те же куски? То есть, скажем если кусок1 попал на ноды 1, 2, 3 и кусок2 попал на ноду 1, то он так же попал и на ноду 2 и ноду 3. То есть по сути на данных трёх нодах будет одинаковый набор кусков, на других трёх нодах — другой набор кусков, но тоже одинаковый. Интуиция подсказывает, что так мы избавимся от комбинаторики и вероятность потери хотя бы одного куска снизится.


Часто данные в кластерах хранят с использованием кодов Рида — Соломона. Краем уха я слышал, что вероятность потери куска данных в этом случае ниже, чем в случае с тройной репликацией, и места они сжирают сильно меньше. Согласуется ли это с вашими расчётами?

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

ИМХО нужно копировать на другие ноды. Т.к. по изначальной постановке каждый кусок данных всегда в 3-х экземплярах.
Если это соблюдать, то умирание ноды должно вызывать автоматическое создание копии данных, которые на ней были, в других нодах.
Если будет так, то без разницы сколько нод в кластере и график вырождается в горизонтальную линию.

Как оно на практике — не знаю, не сталкивался. У любой автоматики есть своя цена.

Было бы логично включать авторепликацию блока на другую (живую) ноду кластера при потере одной из трех нод, хранящих этот блок. Правда, тогда расходы на репликацию данных по такому алгоритму будут расти квадратично от количества нод в кластере при постоянной вероятности выхода одной ноды из строя.

Думаю, автор не принял во внимание, что так оно все и работает. Т.е. нужно было оценивать вероятность выхода из строя двух оставшихся реплик в течение времени, пока авторепликация еще не завершена.

Не понимаю, что тут неочевидного. Чем больше кластер, тем больше данных, чем больше данных — тем больше с ними манипуляций в единицу времени. При постоянной вероятности ошибки одной операции и линейном росте количества операций естественно, что шанс хотя бы одной ошибки растет также линейно. В данном случае ошибка — это отказ сразу трех дисков. Представьте себе, что три диска — это один диск, вероятность отказа которого равна вероятности отказа всех трех дисков за время создание одной полной реплики. Чем больше таких "тридисков" — тем выше шанс отказа одного из них. И разбиение на меньшие кластеры не поможет, так как вероятности отказа одного тридиска в в двух кластерах половинного размера и одном кластере единичного равны.

Вероятность потери любой конкретной порции данных при этом от размера кластера не зависит, что вполне соответствует интуиции. Ну во всяком случае если как причину отказа мы рассматриваем только сбои отдельных дисков.
У вас ключевая проблема — это то, что вы считаете время восстановления фактора репликации == 3 не зависящим от числа нод. В реальности, если у вас большой кластер с нормальной матрицей коммутации, то это время обратно пропорционально числу нод — если сразу после падения ноды те машины, на которых лежат резервные копии отдельных шардов (а это можно считать, что все машины кластера!), начинают куда-то лить данные (на случайные узлы, опять же, то есть на все машины, опять же) — время, в течение которого фактор репликации снизится до 2-х уменьшится пропорционально числу узлов, а значит (в случайной модели отмирания узлов) — и вероятность умирания тоже уменьшится пропорционально числу узлов. Так что время — важный параметр, зря вы его выкинули.
время восстановления потерянной реплики (в идеале) не зависит от числа узлов т.к. упирается в скорость чтения с двух оставшихся реплик.
При правильной реализации, предел — максимум из времени чтения и записи одного блока данных + задержка сети. Если блоки данных по 10 мегабайт, например, то это 10 миллисекунд, на чтение/запись на современных ssd + 10 миллисекунд на сеть между дата-центрами на расстоянии 3000 км.
Sign up to leave a comment.

Articles