Это правильный расчет? (воспроизведение ладьи)

Question

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

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

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

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

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

Если бы у меня было 6 узлов вместо 5, я мог бы потерять 1 OSD на неопределенное время, хотя:

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

Правильно ли исходное предположение? Если да, то вам подходит математика?

Answer 1

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

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

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