Настройка серверов для активно-резервного элемента

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

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

Настраиваемая система будет состоять из следующих серверов:

• Два основных узла, которые будут выполнять обычные функции одного сервера AggreGate.

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

Запустите три сервера AggreGate. Для удобства они будут называться Координатор кластера, Основной узел A и Основной узел B.

Для всех трех серверов запишите следующую информацию, которая потребуется для добавления их в кластер:

• IP-адрес сервера AggreGate.

• Порт, через который можно получить доступ к серверу AggreGate.

• Логин и пароль для пользователя admin.

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

Для всех серверов отметьте свойство Включен для Горизонтального кластера в Опциях глобальной конфигурации.

В разделе Первичные узлы настройте свойства Адрес, Порт, Логин и Пароль для Горизонтального кластера, используя значения, указывающие на подключение к серверу Координатора кластера .

Перезапустите Основные узлы, чтобы значения Идентификатора сервера вступили в силу.

В первичном узле A создайте виртуальное устройство или другое устройство с именем virtual, в результате чего появится контекстный путь users.admin.devices.virtual. Текущий контекст будет использоваться для иллюстрации того, как ресурсы распределяются Координатором кластера.

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

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

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

Дополнительные свойства этой группы позволяют указать базы данных для Кэша координатора и Хранилища координатора. Параметры по умолчанию достаточны для большинства случаев использования и для данного руководства.

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

После завершения перезапуска откройте контекстное меню плагина Координатор кластера на сервере Координатор кластера.

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

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

Чтобы убедиться, что Основные узлы были добавлены в Координатор кластера, откройте таблицу Основные узлы в плагине Координатор кластера.

В таблице должны появиться оба Основных узла с указанием IP-адреса.

Из контекстного меню плагина Координатор кластера вызовите функцию Просмотр статуса и убедитесь, что отображается подробная информация о каждом первичном узле.

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

Предположим, что уникальным идентификатором Основного узла A является строка "primaryNodeAIdentifier".

Предположим, что контекстный путь выделяемого ресурса содержит строку "devices.virtual".

Добавьте одну строку в таблицу " Правила распределения" со следующими данными:

С помощью этого Правила распределения все ресурсы с контекстным путем, содержащим строку "devices.virtual", будут выделены первичному узлу A.

Из контекстного меню плагина Координатора кластера вызовите функцию Сканировать Ресурсы для регистрации ресурсов в хранилище Координатора кластера. Чтобы ресурс был зарегистрирован, он должен соответствовать хотя бы одному из правил распределения.

Чтобы посмотреть, как Координатор кластера управляет отказавшим сервером, выключите сервер с Основным узлом A.

Ресурс устройства, который находился на первичном узле A, имеет контекстный путь users.admin.devices.virtual, поэтому условие выделения возвращает True, когда Координатор кластера оценивает этот ресурс.

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

Войдите в основной узел B и перейдите к ресурсу, который был выделен для основного узла A, в данном случае к устройству с контекстным путем users.admin.devices.virtual.

Перезапустите первичный узел A и проверьте оба узла. Ресурс должен быть перераспределен обратно на первичный узел A и удален с первичного узла B.