Типовой сценарий отказоустойчивой кластеризации серверов системы WNAM, применявшийся с 2015 года, имел одну фундаментальную проблему: формирование кластера серверов системы WNAM требовало создания кластерной конфигурации СУБД MongoDB. В свою очередь, кластер СУБД MongoDB требует, как минимум, трёх узлов (серверов) в своём составе. При запуске кластера в единственном центре обработки данных (ЦОД) заказчика с разнесением виртуальных машин между физическими хостами виртуализации можно добиться приемлемого уровня отказоустойчивости системы.

Однако, при необходимости разнесения кластера системы WNAM на несколько ЦОД возникает следующее: в случае выхода из строя одного из ЦОД либо пропадания каналов связи между ними, кластерный сценарий СУБД MongoDB приводит к тому, что в каждом из ЦОД остается половина, или менее, узлов кластера. Механизм выбора PRRIMARY-узла кластера не может найти решения, и вся БД оказывается в режиме STANDBY, т.е. доступна только для чтения. Это делает всю систему WNAM, активно использующую БД в режиме записи, фактически неработоспособной.

Конфигурация с двумя или более узлами в разных ЦОД, каждый из которых должен иметь возможность временной изолированной работы, востребована в сценариях корпоративной авторизации по протоколу 802.1х. В связи с этим в середине 2023 года в систему WNAM был добавлен альтернативный механизм формирования кластера, предусматривающий:

  • в каждом узле (ЦОД) кластера работает независимая (standalone) или реплицируемая локально (кластерная, из трех серверов) СУБД MongoDB;
  • в каждом узле кластера сервер (сервера) системы WNAM работает только с локальной СУБД MongoDB;
  • в каждом узле кластера на сервер (серверах) системы WNAM работает брокер обмена сообщений кластера Kafka;
  • все узлы кластера и все кластеры между собой связаны через брокер Kafka, который является единственным средством синхронизации данных.

В отличие от кластера СУБД MongoDB в кластере Kafka сохраняется работоспособность при временной изоляции узла. Лог накапливающихся изменений буферизуется и накатывается на остальные узлы кластера при возобновлении связи. Репликация данных обеспечивается отправкой сервисом системы WNAM сообщений об измененных объектах в кластере Kafka. Репликация является двухсторонней. Поддерживается возможность определения и разрешения конфликтов.

Если система WNAM установлена из готового образа (OVF), то брокер Kafka уже установлен в /opt/kafka и предварительно частично настроен. Остаётся только настроить IP-адреса узлов.

Если система WNAM установлена вручную на собственный сервер, то необходимо установить кластер Kafka, пользуясь следующей инструкций: https://kifarunix.com/install-apache-kafka-on-debian/ . Установку необходимо вести в каталоге /opt/kafka.

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

  • 172.16.135.10
  • 10.241.200.123
  • 10.241.200.124

Если требуется два сервера Kafka, они могут находиться как в одной IP-сети, так и в разных.

Пример конфигурационного файла /opt/kafka/config/kraft/server.properties для сервера 172.16.135.10:

process.roles=broker,controller
# укажите идентификатор этого узла. у каждого из узлов кластера он свой, используйте числа 1,2,3 и т.д.
node.id=1
# укажите все узлы, с их уникальными идентификаторами
controller.quorum.voters=1@172.16.135.10:9093,2@10.241.200.123:9093,3@10.241.200.124:9093
# укажите адрес этого узла
listeners=PLAINTEXT://172.16.135.10:9092,CONTROLLER://172.16.135.10:9093
inter.broker.listener.name=PLAINTEXT
# укажите адрес этого узла
advertised.listeners=PLAINTEXT://172.16.135.10:9092
controller.listener.names=CONTROLLER
listener.security.protocol.map=CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT,SSL:SSL,SASL_PLAINTEXT:SASL_PLAINTEXT,SASL_SSL:SASL_SSL
num.network.threads=3
num.io.threads=8
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
socket.request.max.bytes=104857600
log.dirs=/opt/kafka/kraft-combined-logs
num.partitions=1
num.recovery.threads.per.data.dir=1
# укажите число серверов в кластере
offsets.topic.replication.factor=3
# укажите число серверов в кластере
transaction.state.log.replication.factor=3
transaction.state.log.min.isr=1
#
# Параметры влияющие на потребление дискового пространства, а также на объем и время хранимых данных 
# Количество часов хранения файла журнала перед его удалением (в часах), по умолчанию 168
log.retention.hours=72

# Политика хранения журналов, основанная на размере. Сегменты удаляются из журнала до тех пор, пока оставшиеся сегменты не опустятся ниже log.retention.bytes.
# Функционирует независимо от log.retention.hours. Значение по умолчанию -1
log.retention.bytes=1073741824

# Максимальный размер файла сегмента журнала. Когда этот размер будет достигнут, будет создан новый сегмент журнала. По умолчанию 1073741824
log.segment.bytes=268435456
# Интервал, с которым проверяются сегменты журнала на предмет возможности их удаления в соответствии с политиками хранения
log.retention.check.interval.ms=300000





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

Сформировать ключ можно следующей командой:

/opt/kafka/bin/kafka-storage.sh random-uuid
RiS_KRIffedSfMurdVxTDKw

Далее следует установить сформированный ключ на каждом из серверов:

/opt/kafka/bin/kafka-storage.sh format -t RiS_KRIffedSfMurdVxTDKw -c /opt/kafka/config/kraft/server.properties

Ключ RiS_KRIffedSfMurdVxTDKw (или тот, который сформировали) должен быть один и тот же для всех серверов кластера

Следует обратить внимание, что в параметре

controller.quorum.voters=1@172.16.135.10:9093,2@10.241.200.123:9093,3@10.241.200.124:9093

числа перед @ это node.id, которые должны быть прописаны одинаково в конфигурациях на всех серверах кластера.

Далее необходимо создать юнит-файл сервиса Kafka и запустить его. Пример файла сервиса /lib/systemd/system/kafka.service :

[Unit]
Requires=network.target remote-fs.target
After=network.target remote-fs.target

[Service]
Type=simple
User=wnam
ExecStart=/opt/kafka/bin/kafka-server-start.sh /opt/kafka/config/kraft/server.properties
ExecStop=/opt/kafka/bin/kafka-server-stop.sh
TimeoutSec=30
Restart=always
RestartSec=20s

[Install]
WantedBy=multi-user.target

Также для уменьшения объёма логирования сервиса Kafka, необходимо отредактировать конфигурационный файл /opt/kafka/config/log4j.properties заменив в нём INFO, TRACE и DEBUG на WARN.
Проще всего это сделать при помощи sed:

sed -r -i 's/(INFO|TRACE|DEBUG)/WARN/g' /opt/kafka/config/log4j.properties

Поскольку служба kafka запускается от пользователя wnam, следует изменить права на папку /opt/kafka

chown -R wnam:wnam /opt/kafka

Команда для создания и запуска сервиса:

systemctl enable kafka
systemctl start kafka
systemctl status kafka

Для включения системы WNAM в работу кластера следует внести необходимые правки в конфигурационный файл /home/wnam/application.yaml:

netams:
 wnam:
  cluster:
    # optional, default false. Использовать kafka
    kafka_enabled: true 
    # optional default false, отвечает за синхронизацию данных, между разными кластерами wnam, если true синхронизируются все коллекции, если false только конфигурационные параметры 
    full_sync: true 
    # optional, default 1 количество реплик (серверов) в кластере kafka
    replicas: 3 
    # optional, default true. Пытаться выбрать лидера в kafka при падении брокеров kafka
    unclean_election: true 
    # optional, default empty. Если master, то все задачи выполняются на этом сервере.
    role: master 
    # optional, default 'true'. Использовать локальный кэш. Может быть true или false, отключать кэш следует только в конфигурации когда нет кафки и больше одного сервера wnam
    use_cache: true 
    # optional, default false. Показывает кнопку для принудительного запуска синхронизации одного узла кластера с другого
    show_sync: true
 
spring:
 # применяется если kafka_enabled = true
 kafka:
  bootstrap-servers: 172.16.135.10:9092,10.241.200.123:9092,10.241.200.124:9092

После внесенных правок следует перезапустить систему WNAM:

systemctl restart wnam

Если всё правильно настроено, то в интерфейсе администратора системы WNAM появится раздел "Конфигурация" → "Кластер WNAM", в котором будут отображены все ваши узлы кластера, их состояние и т.п.



  • No labels