Практикум по приёмке кластера

Хватит ли ресурсов после отказа узла: расчёт и размещение Pacemaker

Посчитайте ресурс после потери каждого узла, проверьте размещение отдельных сервисов и разберите стратегии Pacemaker. Примеры ограничены руководством RHEL 9.0; расчёты не заменяют испытаний выбранной системы.

База → пресейл и приёмка30 минут3 модуля6 вопросов
После курса

Что вы сможете сделать

  1. Проверять суммарный резерв после потери каждого узла и место для отдельного сервиса.
  2. Различать настроенные потребности, стратегию размещения и фактическую нагрузку.
  3. Составлять план приёмки резерва без обещания надёжности по одному расчёту.
Модуль 1 из 3

Сначала — ёмкость каждого узла

Подсчёт серверов ещё не доказывает, что после отказа найдётся место для каждого сервиса. В примерах ниже числа заданы автором, а не взяты из испытания оборудования.

  • В utilization сопоставляют одноимённые целочисленные параметры узла и ресурса. В учебной конфигурации договоримся указывать memory в МиБ, а cpu_slot — в условных вычислительных единицах. Это наша система учёта, не универсальная норма Pacemaker. Примеры ниже для удобства даны в ГиБ; перед вводом их переводят в МиБ: 1 ГиБ = 1024 МиБ.

  • Учебный пример: после служебного запаса узлы A, B и C имеют бюджеты 112, 112 и 48 ГиБ. Сервисы требуют 200 ГиБ. При потере C останется 224 ГиБ, при потере A или B — 160 ГиБ. Во втором случае не хватает 40 ГиБ; схема не выдерживает любой одиночный отказ.

  • Положительная сумма — лишь первая проверка. При свободных 40 ГиБ на B и 40 ГиБ на C ресурс с фиксированным запросом 64 ГиБ не проходит проверку ни на одном узле. Здесь ресурс не делится между серверами, подкачка и превышение бюджета запрещены условиями примера.

Модуль 2 из 3

Затем — правила размещения

Учёт потребностей, выбор узла и резерв физических ресурсов — три разные проверки.

  • В RHEL 9.0 режим default не использует utilization. Поэтому одних заполненных значений cpu и memory недостаточно: сначала выясните действующую стратегию, а не добавляйте серверы из-за неожиданного выбора узла.

  • Режим utilization проверяет, хватит ли ёмкости, но балансирует по числу ресурсов. Balanced учитывает ёмкость и при балансировке; minimal стремится занять меньше подходящих узлов. Ни один режим не добавляет серверу физических ресурсов.

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

Модуль 3 из 3

Наконец — проверка под нагрузкой

Бюджеты проверяют до закупки, а способность системы выполнять работу — на согласованном стенде.

  • NodeUtilization может заполнить в CIB сведения о CPU и памяти узлов. CIB — база конфигурации кластера. Описание этого агента не обещает расчёт потребностей каждого вашего приложения, GPU, сети и дискового массива.

  • Если резерв рассчитан только по спокойному часу, аварийная нагрузка остаётся непроверенной. Подготовьте представительную нагрузку, согласуйте время ответа и допустимый перерыв, затем проверьте выбранный сценарий отказа без воздействия на рабочую систему.

  • Результат расчёта RAM/CPU не объявляйте приёмкой всего кластера. В отдельные проверки вынесите GPU, доступ к данным, сеть, изоляцию отказавшего узла и восстановление приложения. Этот практикум ограничен размещением по ёмкости в RHEL 9.0/Pacemaker.

Финишная прямая

Проверьте инженерное мышление

Вопросы проверяют не память на аббревиатуры, а умение не делать лишних выводов.

01В RHEL 9.0 заданы utilization для узлов и ресурсов, но placement-strategy оставлен default. Как эти значения влияют на выбор узла?
02На B и C свободно по 40 ГиБ. Ресурсу нужно 64 ГиБ на одном узле. Делить его или превышать бюджет нельзя. Что следует из этих условий?
03Бюджеты A/B/C после служебного запаса — 112/112/48 ГиБ. Обязательные сервисы требуют 200 ГиБ. Сколько суммарной памяти не хватит при потере A?
04Выбирают стратегию, которая учитывает ёмкость при допуске и стремится занять меньше узлов. Какой режим описан в руководстве RHEL 9.0?
05В одной системе учёта у B свободны 8 CPU-единиц и 32 ГиБ, у C — 4 CPU-единицы и 64 ГиБ. Ресурсу нужны 6 CPU-единиц и 48 ГиБ на одном узле. При учёте ёмкости кто подходит?
06NodeUtilization заполнил сведения в CIB. Что именно можно считать результатом этого шага по руководству RHEL 9.0?

Следующий шаг

Сформулируйте задачу и уточните требования к своей системе.

Подготовить состав проекта

Откроется черновик вопроса. Отправьте его, когда будете готовы.

Проверяемая база

Источники курса

Ссылки приведены один раз для всего курса, чтобы не мешать чтению каждого тезиса.

  • Официальная документация

    Red Hat Enterprise Linux 9.0 Configuring and managing high availability clusters

    Red Hat · Red Hat Enterprise Linux 9.0

    Проверены 1.2.1–1.2.2, 10.2–10.5 и таблица 23.1. Страницы с fencing/quorum и no-quorum-policy просмотрены изображением; сведения ограничены RHEL 9.0.

    Открыть первоисточник

Delect.ru — информационный справочник: сведения о ценах, наличии и брендах формируются из данных витрины для анализа и сравнения. Наличие по данным витрины лучше дополнительно уточнять у выбранного поставщика; перед закупкой обязательно ставьте резервы. Сервис не является посредником при сделке и не сторона договора; коммерческие условия согласуются напрямую с выбранным дистрибьютором. Обозначения брендов приводятся для идентификации предложений.

Сообщить об ошибке

Опишите проблему — постараемся исправить как можно скорее.

Спасибо!

Получили ваше сообщение.
Подтвердите действие