Ceph: Почему большее количество "групп размещения" является "плохой вещью"?
Я исследовал распределенные базы данных и файловые системы, и, хотя я изначально интересовался Hadoop/HBase, потому что я программист на Java, я нашел этот очень интересный документ о Ceph, который в качестве основного плюса теперь интегрирован в Ядро Linux.
Ceph как масштабируемая альтернатива HDFS
Есть одна вещь, которую я не понял, и я надеюсь, что один из вас сможет мне это объяснить. Вот:
Простая хеш-функция отображает идентификатор объекта (OID) в группу размещения, группу OSD, в которой хранится объект и все его реплики. Существует ограниченное количество групп размещения, чтобы создать верхнюю границу для количества экранных меню, в которых хранятся реплики объектов, хранящихся в любом данном экранном меню. Чем выше это число, тем выше вероятность того, что отказ нескольких узлов приведет к потере данных. Если, например, каждое OSD имеет отношение реплики к любому другому OSD, сбой всего трех узлов во всем кластере может уничтожить данные, которые хранятся во всех трех репликах.
Можете ли вы объяснить мне, почему большее количество групп размещения увеличивает вероятность потери данных? Я бы подумал, что все наоборот.
1 ответ
В настоящее время я изучаю ceph как альтернативу нашему хранилищу данных. Я нашел ваш вопрос и немного почитал, и надеюсь, что эта идея имеет смысл. То, как они выполняют динамическое распределение данных, предполагает, что если у вас большое количество OSD (значительно больше, чем уровень репликации). Тогда кажется, что было бы возможно (и вероятно), что алгоритм распределения поместил бы некоторые части файлов в огромное количество OSD, так что если вы потеряли N узлов (где N больше, чем ваш уровень репликации), очень вероятно, что вы может потерять ваши данные (или, по крайней мере, иметь значительный объем коррупции). Что на самом деле не удивительно. Я ожидал бы потерю данных, если вы потеряли 3 узла в вашем кластере (как их пример), если ваш уровень репликации не был 4 или выше.