Как настроить кластер высокой доступности (HAE) в SUSE Linux 15

В этом пошаговом руководстве для начинающих описывается создание базового двух узлового кластера в режиме активный/пассивный с использованием SUSE Linux Enterprise High Availability (SLE HA) 15. Используются поддерживаемые скрипты начальной загрузки CRM Shell: инициализация первого узла с помощью команды `cd` crm cluster init, добавление второго с помощью команды `cd` crm cluster join, проверка членства и тестирование запланированного переключения на резервный виртуальный IP-адрес управления. Примеры соответствуют документации SUSE SLE HA 15 SP7, опубликованной 24 сентября 2026 года; подсказки могут различаться в зависимости от пакета обновлений, оборудования и платформы.

В неофициальной терминологии «HAE» часто используется для обозначения расширения высокой доступности. В текущей документации SUSE оно называется SUSE Linux Enterprise High Availability, или SLE HA. Эта процедура обеспечивает рабочую основу кластера и доступ к управлению Hawk2. Она не обеспечивает автоматически высокую доступность приложения, базы данных или их данных; для них необходимы собственные ресурсы Pacemaker, проектирование хранилища и тестирование, специфичное для конкретной рабочей нагрузки.

Приведённые ниже иллюстрации терминала и экрана Hawk2 показывают типичные виды интерфейсов, а не снимки экрана работающей системы. Имена и адреса приведены в качестве примеров. Замените их значениями из вашей сети.

Что будет делать этот кластер?

Кластер — это группа серверов, называемых узлами , которые координируют свои действия для обеспечения работы выбранных служб. Corosync обрабатывает членство узлов и обмен сообщениями в кластере. Pacemaker, менеджер ресурсов кластера, определяет, где должны работать управляемые ресурсы, и реагирует на сбои. Ресурс — это служба или адрес, который Pacemaker может запускать, останавливать, отслеживать и перемещать.

В этом пошаговом руководстве узел aliceи узел bobобразуют двух узловой кластер. Плавающий управляющий IP-адрес предоставляет администраторам стабильный адрес для Hawk2, веб-интерфейса SUSE. Если один узел переведен в режим ожидания, Pacemaker может переместить этот IP-адрес на другой узел. Для производственного двух узлового кластера SUSE рекомендует добавить QDevice/QNetd для принятия решений о кворуме и требует использования механизма изоляции узлов.

Что нужно подготовить перед установкой?

• Поддерживаются две системы SUSE Linux Enterprise Server 15, работающие с одним и тем же пакетом обновлений и архитектурой процессора, с правами root или соответствующей привилегированной учетной записью sudo.
• Действующая регистрация в SUSE и разрешение на использование SLE HA на каждом узле. Шаблон расширений и пакетов должен соответствовать пакету обновлений SLES и архитектуре.
• Статические адреса узлов, разрешение рабочих имен, синхронизированные часы и надежное сетевое соединение кластера. Тщательно выбирайте необходимый интерфейс Corosync; в производственных проектах полезны отдельные или резервные пути.
• План изоляции. Изолирование (STONITH, «Выстрелить в голову другому узлу») принудительно изолирует или перезагружает узел, который может быть неисправен, предотвращая запись данных в общие данные с обеих сторон разделенной сети. В поддерживаемом кластере функция изоляции должна быть включена.
• При использовании SBD (STONITH Block Device) необходимо установить подходящий сторожевой таймер на каждом узле и правильно спроектировать общую блочную память со стабильным путем к устройству. Для производственной среды предпочтительнее использовать аппаратный сторожевой таймер. Если вместо него используется физический ограничитель питания, настройте и протестируйте поддерживаемое устройство STONITH.
• Для двух узлов, если вы планируете настраивать их через процесс начальной загрузки, перед инициализацией следует запланировать использование свидетеля QDevice/QNetd. Свидетель помогает кластеру определить, какая сторона имеет кворум при потере связи.

Не следует рассматривать лабораторную конфигурацию как готовую к использованию в производственной среде. Системные требования SUSE SLE HA 15 SP7 предусматривают использование механизма изоляции, а в руководстве по установке рекомендуется протестировать конфигурацию с двумя или тремя узлами, прежде чем расширять ее.

Шаг 1: Установите расширение SLE HA и соответствующие пакеты.

Если SLE HA не был выбран во время установки SLES, включите расширение на каждом узле. Для зарегистрированного хоста x86_64 SLES 15 SP7 используется следующий шаблон, описанный в документации:

SUSEConnect -p sle-ha/15.7/x86_64 -r ADDITIONAL_REGCODE
zypper install -t pattern ha_sles

Замените ADDITIONAL_REGCODEна регистрационный код SLE HA. Используйте идентификатор продукта активации, соответствующий вашему пакету обновлений и архитектуре; не копируйте пример SP7 в другой пакет обновлений SLES 15. Выполните команду package-pattern на обоих узлах. В документации SUSE этот ha_slesшаблон описывается как набор пакетов, используемых для настройки и управления кластером.

Шаг 2: Подготовьте имена, время и данные для доступа к сети.

Присвойте обоим узлам стабильные имена хостов и статические основные IP-адреса. Убедитесь, что каждый узел может разрешить имя другого как по короткому, так и по полному имени. В рекомендациях SUSE по настройке рекомендуется указывать имена членов кластера при /etc/hostsнеобходимости, поскольку сбои разрешения имен могут нарушить внутреннюю связь. Например, адаптируйте подобные записи к вашей DNS-системе и плану адресации:

10.20.0.11 alice.example.net alice
10.20.0.12 bob.example.net bob

Синхронизируйте оба часа с источником NTP вне кластера и поддерживайте согласованность их часовых поясов. Chrony — это реализация NTP по умолчанию в SLES 15. Проверьте подключение к сети, которую вы планируете использовать для Corosync. Скрипты начальной загрузки могут открыть порты брандмауэра, необходимые для связи кластера, но убедитесь, что брандмауэры вашего хоста и сети разрешают трафик, необходимый для выбранной вами топологии. В процессе начальной загрузки по умолчанию используется одноадресная передача; документированный порт Corosync по умолчанию — 5405.

Шаг 3: Инициализируйте первый узел.

На устройстве aliceвыполните команду bootstrap от имени root:

crm cluster init --name demo-ha

Перед принятием запросов внимательно ознакомьтесь с подсказками. Выберите интерфейс и сетевой адрес, предназначенные для Corosync, затем подтвердите порт. Скрипт проверяет синхронизацию времени и доступность сторожевого таймера, а также может подготовить SSH-ключи и соответствующую конфигурацию кластера. Он спрашивает, нужно ли настраивать SBD, виртуальный IP-адрес администрирования Hawk2 и QDevice/QNetd. Для SBD требуется, чтобы сторожевой таймер и общее устройство уже были готовы. Если вы настраиваете QDevice на этом этапе начальной загрузки, сначала подготовьте сервер QNetd. Скрипт создает работающий одноузловой кластер; bobна этом этапе он не добавляет узлы.

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

Шаг 4: Присоединитесь ко второму узлу.

После инициализации первого узла войдите в систему bobи выполните следующую команду:

crm cluster join

Следуйте подсказке, чтобы определить существующий узел кластера alice. Если для первого узла вы использовали учетную запись sudo, а не root, в документации SUSE указано -c, например, следующее:

sudo crm cluster join -c USER@alice

Скрипт подключения копирует конфигурацию Corosync, настраивает SSH и Csync2, переводит текущую машину в режим онлайн в качестве узла кластера и запускает службу, необходимую для Hawk2. Не инициализируйте обе машины независимо; второй узел должен присоединиться к кластеру, созданному первым.

Шаг 5: Убедитесь, что оба узла находятся в сети.

С любого из узлов проверьте сводку кластера:

crm status

Найдите оба имени узла в каталоге Onlineи раздел кластера с кворумом. Перед продолжением проверьте наличие неудачных действий или отключенных узлов. Вы также можете войти в Hawk2, используя административный VIP-адрес, выбранный во время инициализации, обычно по адресу https://ADMIN-VIP:7630/. Предупреждение о сертификате при первом посещении может появиться, если используется самоподписанный сертификат; вместо того, чтобы игнорировать неизвестный сертификат в производственной среде, проверьте сведения о сертификате у администратора кластера.

Шаг 6: Защитите учетную запись управления.

Процедура начальной загрузки создает haclusterучетную запись для Hawk2. В руководстве по настройке SUSE указан пароль по умолчанию во время базовой настройки, поэтому измените его сразу же, прежде чем оставлять систему в доступе:

passwd hacluster

Используйте уникальный надежный пароль и соблюдайте политику учетных данных вашей организации. Ограничьте доступ к сети управления Hawk2, установите доверенные сертификаты по мере необходимости и не предоставляйте прямой доступ к интерфейсу управления из общедоступного интернета.

Шаг 7: Безопасная проверка запланированного переключения на резервный сервер.

Тест планового резервирования проверяет, может ли виртуальный IP-адрес управления перемещаться, если один из узлов намеренно исключается из распределения ресурсов. Перед тестированием убедитесь, что оба узла исправны, в кластере есть кворум, и у вас есть доступ к консоли или внеполосный доступ на случай непредвиденных ситуаций. С клиента в той же сети постоянно пингуйте виртуальный IP-адрес управления, например:

ping 10.20.0.20

В Hawk2 откройте узел, на котором в данный момент размещен административный IP-адрес, и выберите «Режим ожидания» (Standby ). Затем проверьте «Статус» (Status) > «Ресурсы» (Resources) . В кратком руководстве SUSE описано перемещение плавающего ресурса на другой узел во время выполнения пинга. После завершения теста верните узел в рабочее состояние, используя соответствующее действие Hawk2, убедитесь, что оба узла находятся в сети, и проверьте, находится ли ресурс в ожидаемом месте.

Что доказывает этот тест, а что нет?

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

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

Распространенные ошибки, которых следует избегать

• Пропуск проверки безопасности: кластер без работающего STONITH не может безопасно разрешить проблему разделения мозга и не соответствует требованиям поддержки SUSE.
• Если предположить, что два узла могут принимать решения самостоятельно: планируйте использование QDevice/QNetd для кластера с четным числом узлов, особенно для кластера из двух узлов.
• При использовании нестабильной или несовпадающей идентификации узлов: используйте статические адреса, согласованные имена хостов, прямое и обратное разрешение имен и синхронизированное время.
• Повторное использование неправильной сети: выберите нужный интерфейс Corosync и проверьте политику брандмауэра для всех сетевых путей.
• Предположим, кластер автоматически защищает приложение: кластер может управлять только теми ресурсами, которые были настроены и протестированы.
• Начальная загрузка называется «готовой к работе в производственной среде»: быстрый старт — это базовая настройка. Готовность к работе в производственной среде требует проведения тестов восстановления, специфичных для конкретной рабочей нагрузки, проверки изоляции, мониторинга, процедур резервного копирования и восстановления, а также документированных операций.

Официальные справочные материалы SUSE

• Краткое руководство по установке и настройке SLE HA 15 SP7
• Системные требования и рекомендации SLE HA 15 SP7
• Обзор установки SLE HA 15 SP7
• Защита от хранения SLE HA 15 SP7 и SBD