Pacemaker Ha: Сетевые Подключения И Динамическое Распределение Ресурсов Кластера

Узлы кластера очень зависят от их физического соединения.

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

Поэтому многое зависит от того, как вы соединяетесь между узлами и настраиваете размещение ресурсов.

Для примера я буду рассматривать кластер, состоящий из двух узлов.

Один узел будет находиться в активном состоянии, а другой — в состоянии «горячего резерва».

Наш кластер будет обслуживать внутреннюю частную сеть и содержать следующие ресурсы кластера: сервер Mysql и VIP-сервер Mysql. На двух узлах Mysql будет запущен сервер с репликацией Master-Master. Однако вся работа будет выполняться только с одним экземпляром через виртуальный IP-адрес.

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

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



Pacemaker HA: сетевые подключения и динамическое распределение ресурсов кластера

рис.

1 диаграмма Классстера Главное, на что следует обратить внимание при проектировании любого кластера, — это резервирование сетевого соединения между узлами кластера.

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

Их можно объединить путем объединения в один интерфейс или просто использовать два разных интерфейса в конфигурации Heartbeat или CoroSync. При проектировании нового кластера я бы рекомендовал использовать corosync не только потому, что разработка Heartbeat потихоньку поворачивает в сторону пейсмейкера и corosync, но и потому, что он имеет более гибкие настройки для работы с несколькими интерфейсами и может использовать их параллельно или в режиме «активный и запасной».

" режим " Несоблюдение правил резервирования или выделения отдельных сетевых интерфейсов может привести к ситуации «раздвоения мозга».

Что, в принципе, не сулит ничего хорошего.

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

Т.

к.

наш кластер состоит из двух нод - то у нас проблемы с кворумом.

А точнее, полное его отсутствие, что еще раз намекает на необходимость резервного соединения между узлами.

Хватит теории, перейдем к практике.

Задаем поведение нод в случае отсутствия кворума: Теги: #Системное администрирование #кластер #crm #ha #ping #pacemaker #corosync #pingd

Вместе с данным постом часто просматривают: