Page History

Типовой сценарий отказоустойчивой кластеризации серверов системы 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в кластере 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

После настройки конфигурационных файлов на каждом сервере вы должны необходимо инициализировать кластер 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

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

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

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

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 
 
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", в котором вы увидите будут отображены все ваши узлы кластера, их состояние и т.п.

...