You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

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


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

Создаем и запускаем сервис:

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



  • No labels