Блог

Если происходит сбой 1 экранного меню, rook-ceph в конечном итоге пытается реплицировать недостающие данные на все еще работающие экранные меню или он ждет, пока все экранные меню снова станут работоспособными? Давайте скажем «да», чтобы я мог объяснить, как я рассчитал :

Я начал с 1,71 ТБ, выделенных для kubernetes PVCS, и 3 узлов по 745 ГБ каждый (всего 2,23 ТБ). Коэффициент репликации Ладьи равен 2 (RF = 2).

Для работы репликации мне нужно 2 раза по 1,71 ТБ (3,42 ТБ), поэтому я добавил 2 узла по 745 ГБ каждый (всего 3,72 ТБ), допустим, я использую все предоставленные 1,71 ТБ.

Если я потеряю экранное меню, мой кластер K8S все еще работает, потому что данные реплицируются, но когда отсутствующие данные реплицируются сами на все еще работающем экранном меню, другое экранное меню может выйти из строя, потому что, предполагая, что экранные меню всегда распределены одинаково (что, как я знаю, в долгосрочной перспективе неверно) :

• У меня 290 ГБ неиспользуемого пространства в моем кластере (всего 3,72 — 3,42 резервирования ПВХ)
• Что составляет 58 ГБ на экранное меню (290 / 5)
• Разбитое экранное меню имеет 687 ГБ (всего 745 дисков — 58 ГБ неиспользуемых)
• Ceph пытается реплицировать 172 ГБ недостающих данных на каждом оставшемся экранном меню (687/4)
• Это слишком много, потому что у нас осталось всего 58 ГБ, что должно привести к каскадным сбоям экранного меню

Если бы у меня было 6 узлов вместо 5, я мог бы потерять 1 экранное меню на неопределенный срок. :

• Новый пул составляет 4,5 ТБ (6×745)
• У меня есть 1 ТБ свободного места в кластере (всего 4,5 — 3,42 поливинилхлорида)
• Что составляет 166 ГБ на экранное меню (~ 1 ТБ / 6)
• Разбитое экранное меню содержит не более 579 ГБ данных (745 — 166).
• Ceph пытается реплицировать менее 100 ГБ недостающих данных на каждом оставшемся экранном меню (579/6)
• Это меньше, чем свободное место на каждом OSD (166 ГБ), поэтому репликация снова работает, осталось всего 5 узлов, но если другой OSD выйдет из строя, я обречен.

Верно ли первоначальное предположение? Если да, правильно ли для вас математика?

Первое: если вы цените свои данные, не используйте репликацию с размером 2! В конечном итоге у вас возникнут проблемы, приводящие к потере данных.

Что касается вашего расчета: Ceph не распределяет каждый МБ данных равномерно по всем узлам, между вашими OSD будут различия. Из-за этого экранное меню с наибольшим количеством данных будет вашим узким местом в отношении свободного места и возможности перебалансировки после сбоя. Ceph также не очень хорошо обрабатывает полные или почти полные кластеры, ваш расчет очень близок к полному кластеру, что приведет к новым проблемам. Старайтесь избегать кластера с более чем 85 или 90% используемой емкости, планируйте заранее и используйте больше дисков, чтобы избежать переполнения кластера, а также иметь более высокую устойчивость к отказам. Чем больше у вас OSD, тем меньшее влияние сбой одного диска окажет на остальную часть кластера.

И что касается восстановления: ceph обычно пытается восстановить автоматически, но это зависит от вашей фактической crushmap и наборов правил, с которыми настроены ваши пулы. Например, если у вас есть дерево раздачи, состоящее из 3 стоек, и ваш пул настроен на размер 3 (таким образом, всего 3 реплики), распределенных по вашим 3 стойкам (сбой-домен = стойка), то происходит сбой всей стойки. В этом примере ceph не сможет восстановить третью реплику, пока стойка снова не будет подключена. Данные по-прежнему доступны клиентам и всем остальным, но ваш кластер находится в ухудшенном состоянии. Но эта настройка должна выполняться вручную, поэтому она, вероятно, не будет применяться к вам, я просто хотел указать, как это работает. Обычно по умолчанию используется пул размером 3 с хостом в качестве домена сбоя.