Corosync что это
Перейти к содержимому

Corosync что это

  • автор:

Что такое corosync

Обновлено и опубликовано

Опубликовано: 26.07.2017

программный продукт, позволяющий реализовать кластер серверов. Его основное назначение — знать и передавать состояние всех участников кластера.

В основе работы заложены следующие функции:

  • Отслеживание состояния приложений.
  • Оповещение приложений о смене активной ноды кластера.
  • Отправка одинаковых сообщений процессам на всех узлах кластера.
  • Предоставление доступа к базе данных с конфигурацией и статистикой, а также отправка уведомлений о ее изменениях.

Пример реализации кластера — Corosync + Stonith + Pacemaker. Последний также вместо Corosync может использовать Heartbeat.

Подробнее о corosync на Википедии

Встречается в статьях

Инструкции:

  1. Установка и настройка отказоустойчивого кластера Pacemaker
  2. Как установить и настроить систему виртуализации Proxmox VE

Кластер pacemaker/corosync без валидола

Представьте ситуацию. Субботний вечер. Вы — администратор PostgreSQL, после тяжелой трудовой недели уехали на дачу за 200 км от любимой работы и чувствуете себя прекрасно… Пока Ваш покой не нарушает смс от системы мониторинга Zabbix. Произошел сбой на сервере СУБД, база данных с текущего момента недоступна. На решение проблемы отводится короткое время. И Вам ничего не остается, как с тяжелым сердцем оседлать служебный гироскутер и мчаться на работу. Увы!

А ведь могло быть по-другому. Вам приходит смс от системы мониторинга, что произошел сбой на одном из серверов. Но СУБД продолжает работать, поскольку отказоустойчивый кластер PostgreSQL отработал потерю одного узла и продолжает функционировать. Нет надобности срочно ехать на работу и восстанавливать сервер БД. Выяснение причин сбоя и работы по восстановлению спокойно переносятся на рабочий понедельник.

Как бы то ни было, стоит подумать о технологиях отказоустойчивы кластеров с СУБД PostgreSQL. Мы расскажем о построении отказоустойчивого кластера СУБД PostgreSQL с помощью программного обеспечения Pacemaker&Corosync.

Отказоустойчивый кластер СУБД PostgreSQL на основе Pacemaker

Сегодня в ИТ-системах уровня «business critical» спрос на широкую функциональность отходит на второй план. На первое место выходит спрос на надежность ИТ-систем. Для отказоустойчивости приходится вводить избыточность компонентов системы. Ими управляет специальное программное обеспечение.

Примером такого программного обеспечения является Pacemaker – решение компании ClusterLabs, позволяющее организовать отказоустойчивый кластер (ОУК). Работает Pacemaker под управлением широкого спектра операционных Unix-систем – RHEL, CentOS, Debian, Ubuntu.

Это программное обеспечение не создавали специально для работы с PostgreSQL или других СУБД. Сфера применения Pacemaker&Corosync значительно шире. Есть специализированные решения, заточенные под PostgreSQL, например multimaster, входящий в состав Postgres Pro Enterprise (компания Postgres Professional), или Patroni (компания Zalando). Но рассматриваемый в статье кластер PostgreSQL на основе Pacemaker/Corosync, достаточно популярен и подходит по соотношению простоты и надежности к стоимости владения для немалого числа ситуаций. Все зависит от конкретных задач. Сравнение решений не входит в задачи этой статьи.

Итак: Pacemaker — мозг и по совместительству менеджер ресурсов кластера. Его главная задача — достижение максимальной доступности ресурсов, которыми он управляет, и защита их от сбоев.

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

Для того, чтобы стало понятно, как устроен и работает Pacemaker, давайте рассмотрим, что у него внутри и из чего он состоит.

Итак, перейдем к сущностям Pacemaker.

Рисунок 1. Сущности pacemaker – узлы кластера

Первая и самая важная сущность – это узлы кластера. Узел (нода, node ) кластера представляет собой физический сервер или виртуальную машину с установленным Pacemaker.

Узлы, предназначенные для предоставления одинаковых сервисов, должны иметь одинаковую конфигурацию софта. То есть, если ресурс postgresql предполагается запускать на узлах node1, node2 , и он расположен в нестандартных путях установки, то на этих узлах должны быть одинаковые конфигурационные файлы, пути установки PostgreSQL, и конечно же, одинаковая версия PostgreSQL.

Следующая важная группа сущностей Pacemaker – ресурсы кластера. Вообще для Pacemaker ресурс — это скрипт, написанный на любом языке. Обычно эти скрипты пишутся на bash , но ничто не мешает писать их на Perl, Python, C или даже на PHP . Скрипт управляет сервисами в операционной системе. Главное требование к скриптам — уметь выполнять 3 действия: start, stop, monitor и делиться некоторой метаинформацией.

  • IP адрес;
  • сервис, запускаемый в операционной системе;
  • блочное устройство
  • файловая система;
  • другие.

Атрибут priority — приоритет ресурса, который учитывается, если узел исчерпал лимит по количеству активных ресурсов (по умолчанию 0). Если узлы кластера не одинаковы по производительности или доступности, то можно увеличить приоритет одного из узлов, чтобы он был активным всегда, когда работает.

Атрибут resource-stickiness — липкость ресурса (по умолчанию 0). Липкость (stickiness) указывает на то, насколько ресурс «хочет» оставаться там, где он есть сейчас. Например, после сбоя узла его ресурсы переходят на другие узлы (точнее — стартуют на других узлах), а после восстановления работоспособности сбойного узла, ресурсы могут вернуться к нему или не вернуться, и это поведение как раз и описывается параметром липкость.

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

Поскольку по умолчанию липкость всех ресурсов 0, то Pacemaker сам располагает ресурсы на узлах «оптимально» на свое усмотрение.

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

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

Атрибут migration-threshold — сколько отказов должно произойти, чтобы Pacemaker решил, что узел непригоден для данного ресурса и перенёс (мигрировал) его на другой узел. По умолчанию также этот параметр равен 0, т. е. при любом количестве отказов автоматического переноса ресурсов не будет происходить.

Но, с точки зрения отказоустойчивости, правильно выставить этот параметр в 1, чтобы при первом же сбое Pacemaker перемещал ресурс на другой узел.

Атрибут failure-timeout — количество секунд после сбоя, до истечения которых Pacemaker считает, что отказа не произошло, и не предпринимает ничего, в частности, не перемещает ресурсы. По умолчанию, равен 0.

  • block — установить опцию unmanaged, то есть деактивировать
  • stop_only — остановить на всех узлах
  • stop_start — остановить на всех узлах и запустить только на одном (значение по-умолчанию).

При возникновении отказа на основном узле, Pacemaker «перемещает» ресурсы на другой узел (на самом деле, Pacemaker останавливает ресурсы на сбойнувшем узле и запускает ресурсы на другом). Процесс «перемещения» ресурсов на другой узел происходит быстро и незаметно для конечного клиента.

Группы ресурсов

Ресурсы можно объединять в группы — списки ресурсов, которые должны запускаться в определенном порядке, останавливаться в обратном порядке и исполняться на одном узле.Все ресурсы группы запускаются на одном узле и запускаются последовательно, согласно порядку в группе. Но нужно учитывать, что при сбое одного из ресурсов группы, вся группа переместится на другой узел.

При выключении какого-либо ресурса группы, все последующие ресурсы группы тоже выключатся. Например, ресурс PostgreSQL, имеющий тип pgsql, и ресурс Virtual-IP, имеющий тип IPaddr2, могут быть объединены в группу.

Последовательность запуска в этой группе такая – сначала запускается PostgreSQL, и при его успешном запуске вслед за ним запускается ресурс Virtual-IP.

Кворум (quorum)

Что такое кворум? Говорят, что кластер имеет кворум при достаточном количестве «живых» узлов кластера. Достаточность количества «живых» узлов определяется по формуле ниже.
n > N/2, где n – количество живых узлов, N – общее количество узлов в кластере.

Как видно из простой формулы, кластер с кворумом – это когда количество «живых» узлов, больше половины общего количества узлов в кластере.

Рисунок 2 – Отказоустойчивый кластер с кворумом

Как вы, наверное, понимаете, в кластере, состоящем из двух узлов, при сбое на одном из 2-х узлов не будет кворума. По умолчанию, если нет кворума, Pacemaker останавливает ресурсы.

Чтобы этого избежать, нужно при настройке Pacemaker указать ему, чтобы наличие или отсутствие кворума не учитывалось. Делается это с помощью опции no-quorum-policy=ignore.

Архитектура Pacemaker

Архитектура Pacemaker представляет собой три уровня:

Рисунок 3 – Уровни Pacemaker

  • Кластеронезависимый уровень – ресурсы и агенты. На этом уровне располагаются сами ресурсы и их скрипты. На рисунке обозначен зеленым цветом.
  • Менеджер ресурсов (Pacemaker), это «мозг» кластера. Он реагирует на события, происходящие в кластере: отказ или присоединение узлов, ресурсов, переход узлов в сервисный режим и другие административные действия. На рисунке обозначен синим цветом.
  • Информационный уровень (Corosync) — на этом уровне осуществляется сетевое взаимодействие узлов, т.е. передача сервисных команд (запуск/остановка ресурсов, узлов и т.д.), обмен информацией о полноте состава кластера ( quorum ) и т.д. На рисунке он обозначен красным.

Что нужно для работы Pacemaker?

  • Синхронизация времени между узлами в кластере
  • Разрешение имен узлов в кластере
  • Стабильность сетевых подключений
  • Наличие у узлов кластера функции управления питанием/перезагрузкой с помощью IPMI(ILO) для организации «фенсинга» (fencing – изоляция) узла.
  • Разрешение прохождения трафика по протоколам и портам

Синхронизация времени – нужно, чтобы все узлы имели одно и то же время, обычно это реализуется установкой в локальной сети сервера времени ( ntpd ).

Разрешение имен – реализуется установкой в локальной сети сервера DNS. Если нет возможности установить сервер DNS, нужно на всех узлах кластера внести записи в файл /etc/hosts с именами хостов и IP-адресами.

Стабильность сетевых соединений. Необходимо избавиться от ложных срабатываний. Представьте, что у вас нестабильная локальная сеть, в которой каждые 5-10 секунд происходит потеря линка между узлами кластера и коммутатором. В таком случае, Pacemaker будет считать сбоем пропадание линка более, чем на 5 секунд. Пропал линк, ваши ресурсы «переехали». Потом линк восстановился. Но Pacemaker уже считает узел в кластере «сбойнувшим», он уже «перенес» ресурсы на другой узел. При следующем сбое, Pacemaker «перенесет» ресурсы на следующий узел, и так далее, пока не закончатся все узлы, и возникнет отказ в обслуживании. Таким образом, из-за ложных срабатываний весь кластер может перестать функционировать.

Наличие у узлов кластера функции управления питанием/перезагрузкой с помощью IPMI (ILO) для организации «фенсинга». Необходимо для того, чтобы при сбое узла изолировать его от остальных узлов. «Фенсинг» исключает ситуацию возникновения split-brain (когда появляются одновременно два узла, выполняющих роль Мастера СУБД PostgreSQL).

Разрешение прохождения трафика по протоколам и портам. Это важное требование, потому что в различных организациях службы безопасности часто устанавливают ограничения на прохождение трафика между подсетями или ограничения на уровне коммутаторов.

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

Таблица 1 – Перечень протоколов и портов, необходимых для функционирования ОУК

В таблице приведены данные для случая отказоустойчивого кластера из 3-х узлов – node1, node2, node3 . Также подразумевается, что узлы кластера и интерфейсы управления питанием узлов (IPMI) находятся в разных подсетях.

Как видно из таблицы, необходимо обеспечить не только доступность соседних узлов в локальной сети, но и доступность узлов в сети IPMI.

Особенности использования виртуальных машин для ОУК

  • fsync. Отказоустойчивость СУБД PostgreSQL очень сильно завязана на возможность синхронизировать запись в постоянное хранилище (диск) и корректное функционирование этого механизма. Разные гипервизоры по-разному реализуют кеширование дисковых операций, некоторые не обеспечивают своевременного сброса данных из кеша в систему хранения.
  • realtime corosync. Процесс corosync в ОУК на основе Pacemaker отвечает за обнаружение сбоев узлов кластера. Для того, чтобы он корректно функционировал, нужно, чтобы ОС гарантированно планировала его исполнение на процессоре (ОС выделяет процессорное время). В связи с этим этот процесс имеет приоритет RT ( realtime ). В виртуализированной ОС нет возможности гарантировать такое планирование процессов, что приводит к ложным срабатываниям кластерного ПО.
  • фенсинг. В виртуализированной среде механизм фенсинга ( fencing ) усложняется и становится многоуровневым: на первом уровне нужно реализовать выключение виртуальной машины через гипервизор, а на втором — выключение всего гипервизора (второй уровень срабатывает, когда на первом уровне фенсинга корректно не отработал). К сожалению, у некоторых гипервизоров нет возможности фенсинга. Рекомендуем не использовать виртуальные машины при построении ОУК.

Особенности использования PostgreSQL для ОУК

  • Pacemaker при запуске кластера с PostgreSQL размещает файл блокировки LOCK.PSQL на узле с мастером СУБД. Обычно этот файл размещается в директории /var/lib/pgsql/tmp . Это делается с той целью, чтобы при сбое на Мастере запретить в дальнейшем автоматический запуск PostgreSQL. Таким образом, после сбоя на Мастере всегда требуется вмешательство администратора БД для устранения причин сбоя.
  • Поскольку в ОУК используется стандартная схема PostgreSQL Master-Slave, то при определенных сбоях возможна ситуация возникновения двух Мастеров – т.н. split-brain. Например, сбой Потеря сетевой связности между каким-либо из узлов и остальными узлами (о всех видах сбоев см. далее). Во избежание этой ситуации необходимо выполнение двух важных условий при построении отказоустойчивых кластеров:
    • наличие кворума в ОУК. Это означает, что в кластере должно быть не менее 3-х узлов. Причем, необязательно все три узла должны быть с СУБД, достаточно на двух узлах иметь Мастер и Реплику, а третий узел выступает в роли «голосующего».
    • Наличие устройств фенсинга на узлах с СУБД. При возникновении сбоя устройства «фенсинга» изолируют сбойнувший узел – посылают команду на выключение питания или перезагрузку ( poweroff или hard-reset ).
    sudo pcs resource create PostgreSQL pgsql pgctl="/usr/pgsql-9.6/bin/pg_ctl" \ psql="/usr/pgsql-9.6/bin/psql" pgdata="/var/lib/pgsql/9.6/data/" \ rep_mode="sync" node_list=" pgsql01 pgsql02 pgsql03" restore_command="cp /var/lib/pgsql/9.6/pg_archive/%f %p" \ primary_conninfo_opt="keepalives_idle=60 keepalives_interval=5 keepalives_count=5" master_ip="10.3.3.3" restart_on_promote='false' 

    Команды управления Pacemaker

    • sudo pcs cluster auth node1 node2 node3 -u hacluster -p ‘пароль‘
    • Запуск кластера на всех узлах
    • sudo pcs cluster start —all
    • sudo pcs cluster start
    • sudo pcs cluster stop
    • sudo crm_mon -Afr
    • sudo pcs resource cleanup

    Мониторинг состояния кластера с помощью crm_mon

    У Pacemaker есть встроенная утилита мониторинга состояния кластера. Системный администратор может с помощью нее видеть, что происходит в кластере, какие ресурсы на каких узлах расположены в настоящее время.

    • sudo crm_mon –Afr

    Рисунок 4 – Мониторинг состояния кластера с помощью команды crm_mon

    pgsql-status
    PRI – состояние мастера
    HS:sync – синхронная реплика
    HS:async – асинхронная реплика
    HS:alone – реплика не может подключится к мастеру
    STOP – PostgreSQL остановлен
    pgsql-data-status
    LATEST – состояние, присущее мастеру. Данный узел является мастером.
    STREAMING:SYNC/ASYNC – показывает состояние репликации и тип репликации (SYNC/ASYNC)
    DISCONNECT – реплика не может подключиться к мастеру. Обычно такое бывает, когда нет соединения от реплики к мастеру.
    pgsql-master-baseline
    Показывает линию времени. Линия времени меняется каждый раз после выполнения команды promote на узле-реплике. После этого СУБД начинает новый отсчет времени.

    Виды сбоев на узлах кластера

    • Сбой по питанию на текущем мастере или на реплике. Сбой питания, когда пропадает питание и сервер выключается. Это может быть как Мастер, так и одна из Реплик.
    • Сбой процесса PostgreSQL. Сбой основного процесса PostgreSQL – система может завершить аварийно процесс postgres по разным причинам, например, нехватка памяти, либо недостаточное количество файловых дескрипторов, либо превышено максимальное число открытых файлов.
    • Потеря сетевой связности между каким-либо из узлов и остальными узлами. Это сетевая недоступность какого-либо узла. Например, её причиной может быть выход из строя сетевой карты, либо порта коммутатора.
    • Сбой процесса Pacemaker/Corosync. Сбой процесса Corosync/pacemaker аналогично сбою процесса PostgreSQL.

    Виды планового обслуживания ОУК

    • Выведение из эксплуатации Мастера или Реплики для плановых работ нужно в следующих случаях:
      • замена вышедшего из строя оборудования (не приведшего к сбою);
      • апгрейд оборудования;
      • обновление софта;
      • другие случаи.

      Важно! Прежде чем производить смену ролей или вывод Мастера из эксплуатации, необходимо с помощью команды #crm_mon –Afr убедиться, что в кластере присутствует синхронная реплика. И роль Мастера назначается всегда синхронной реплике.

      Поскольку цель этой и так не короткой статьи – познакомить вас с одним из решений по отказоустойчивости СУБД PostgreSQL, вопросы установки, настройки и команды конфигурирования отказоустойчивого кластера не рассматриваются.

      Автор статьи — Игорь Косенков, инженер Postgres Professional.
      Рисунок — Наталья Лёвшина
      .

      Corosync что это

      Product SiteDocumentation Site

      ⁠Глава 54. Отказоустойчивый кластер (High Availability) на основе Pacemaker

      Pacemaker — менеджер ресурсов кластера (Cluster Resource Manager), задачей которого является достижение максимальной доступности управляемых им ресурсов и защита их от сбоев как на уровне самих ресурсов, так и на уровне целых узлов кластера. Ключевые особенности Pacemaker:

      обнаружение и восстановление сбоев на уровне узлов и сервисов;
      возможность гарантировать целостность данных путем ограждения неисправных узлов;
      поддержка одного или нескольких узлов на кластер;

      поддержка нескольких стандартов интерфейса ресурсов (все, что может быть написано сценарием, может быть кластеризовано);

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

      поддерживает расширенные типы ресурсов: клоны (когда ресурс запущен на множестве узлов) и дополнительные состояния (master/slave и подобное);

      единые инструменты управления кластером с поддержкой сценариев.
      Архитектура Pacemaker представляет собой три уровня:

      кластеронезависимый уровень — на этом уровне располагаются ресурсы и их скрипты, которыми они управляются и локальный демон, который скрывает от других уровней различия в стандартах, использованных в скриптах;

      менеджер ресурсов (Pacemaker) — реагирует на события, происходящие в кластере: отказ или присоединение узлов, ресурсов, переход узлов в сервисный режим и другие административные действия. Pacemaker, исходя из сложившейся ситуации, делает расчет наиболее оптимального состояния кластера и дает команды на выполнение действий для достижения этого состояния (остановка/перенос ресурсов или узлов);

      информационный уровень (Corosync) — на этом уровне осуществляется сетевое взаимодействие узлов, т.е. передача сервисных команд (запуск/остановка ресурсов, узлов и т.д.), обмен информацией о полноте состава кластера (quorum) и т.д.

      Узел (node) кластера представляет собой физический сервер или виртуальную машину с установленным Pacemaker. Узлы, предназначенные для предоставления одинаковых сервисов, должны иметь одинаковую конфигурацию.

      Ресурсы, с точки зрения кластера, это все используемые сущности — сервисы, службы, точки монтирования, тома и разделы. При создании ресурса потребуется задать его класс, тип, провайдера и собственно имя с дополнительными параметрами. Ресурсы поддерживают множество дополнительных параметров: привязку к узлу (resource-stickiness), роли по умолчанию (started, stoped, master) и т.д. Есть возможности по созданию групп ресурсов, клонов (работающих на нескольких узлах) и т.п.

      Связи определяют привязку ресурсов к узлу (location), порядок запуска ресурсов (ordering) и совместное их проживание на узле (colocation).

      Corosync что это

      Product SiteDocumentation Site

      ⁠54.2. Установка кластерного ПО и создание кластера

      Для управления кластером Pacemaker можно использовать утилиты pcs или crm (пакет crmsh).
      Установить на всех узлах необходимые пакеты:

      # apt-get install corosync resource-agents pacemaker pcs 

      Примечание

      Данные пакеты не входят в состав ISO-образа дистрибутива, их можно установить из репозитория p9. О добавлении репозиториев с использованием графических приложений вы можете почитать в разделе Добавление репозиториев.

      Примечание

      Пакет resource-agent — содержит агенты ресурсов (набор скриптов) кластера, соответствующие спецификации Open Cluster Framework (OCF), используемые для взаимодействия с различными службами в среде высокой доступности, управляемой менеджером ресурсов Pacemaker. Если есть необходимость управлять дополнительными ресурсами, следует установить недостающий пакет resource-agents-*:

      $ apt-cache search resource-agents* 

      Пакет pcs (pacemaker/corosync configuration system) — утилита для управления, настройки и мониторинга кластера. Управляется как через командную строку, так и через веб-интерфейс.

      При установке Pacemaker автоматически будет создан пользователь hacluster. Для использования pcs , а также для доступа в веб-интерфейс нужно задать пароль пользователю hacluster (одинаковый на всех узлах):

      # passwd hacluster 

      Запустить и добавить в автозагрузку службу pcsd:

      # systemctl enable --now pcsd 

      Настроить аутентификацию (на одном узле):

      # pcs host auth node01 node02 node03 -u hacluster Password: node02: Authorized node01: Authorized node03: Authorized

      После этого кластером можно управлять с одного узла.
      Создать кластер:

      # pcs cluster setup newcluster node01 node02 node03 Destroying cluster on hosts: 'node01', 'node02', 'node03'. node03: Successfully destroyed cluster node01: Successfully destroyed cluster node02: Successfully destroyed cluster Requesting remove 'pcsd settings' from 'node01', 'node02', 'node03' node01: successful removal of the file 'pcsd settings' node03: successful removal of the file 'pcsd settings' node02: successful removal of the file 'pcsd settings' Sending 'corosync authkey', 'pacemaker authkey' to 'node01', 'node02', 'node03' node01: successful distribution of the file 'corosync authkey' node01: successful distribution of the file 'pacemaker authkey' node03: successful distribution of the file 'corosync authkey' node03: successful distribution of the file 'pacemaker authkey' node02: successful distribution of the file 'corosync authkey' node02: successful distribution of the file 'pacemaker authkey' Sending 'corosync.conf' to 'node01', 'node02', 'node03' node01: successful distribution of the file 'corosync.conf' node02: successful distribution of the file 'corosync.conf' node03: successful distribution of the file 'corosync.conf' Cluster has been successfully set up.

      Запустить кластер:

      # pcs cluster start --all node02: Starting Cluster. node03: Starting Cluster. node01: Starting Cluster.

      Настройка автоматического включения кластера при загрузке:

      # pcs cluster enable --all node01: Cluster Enabled node02: Cluster Enabled node03: Cluster Enabled

      Проверка состояния кластера:

      # pcs status cluster Cluster Status: Cluster Summary: * Stack: corosync * Current DC: node02 (version 2.0.3-alt2-4b1f869f0) - partition with quorum * Last updated: Thu Jan 28 13:26:38 2021 * Last change: Thu Jan 28 13:27:05 2021 by hacluster via crmd on node02 * 3 nodes configured * 0 resource instances configured Node List: * Online: [ node01 node02 node03 ] PCSD Status: node01: Online node02: Online node03: Online

      Проверка синхронизации узлов кластера:

      # corosync-cmapctl | grep members runtime.members.1.config_version (u64) = 0 runtime.members.1.ip (str) = r(0) ip(192.168.0.113) runtime.members.1.join_count (u32) = 1 runtime.members.1.status (str) = joined runtime.members.2.config_version (u64) = 0 runtime.members.2.ip (str) = r(0) ip(192.168.0.145) runtime.members.2.join_count (u32) = 1 runtime.members.2.status (str) = joined runtime.members.3.config_version (u64) = 0 runtime.members.3.ip (str) = r(0) ip(192.168.0.132) runtime.members.3.join_count (u32) = 1 runtime.members.3.status (str) = joined

      Веб-интерфейс управления кластером по адресу https://<имя-компьютера>:2224 (в качестве имени компьютера можно использовать имя или IP-адрес одного из узлов в кластере). Потребуется пройти аутентификацию (логин и пароль учётной записи hacluster):

      Аутентификация в веб-интерфейсе управления кластером

      После входа в систему на главной странице отображается страница «Управление кластерами». На этой странице перечислены кластеры, которые в настоящее время находятся под управлением веб-интерфейса. При выборе кластера отображается информация о кластере:

      Веб-интерфейс управления кластером

      Примечание

      Чтобы добавить существующий кластер в веб-интерфейс, необходимо нажать кнопку Add Existing и в открывшемся окне ввести имя или IP-адрес любого узла в кластере:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *