Важно: Данный раздел актуален для Платформы данных в Публичном облаке и On-Premise.
Примечание: Непосредственно операции по подготовке к созданию и созданию кластера описаны в документации к RT.ClusterManager. Данные о порядке создания компонент и по распределению сервисов компонент по нодам, описанные в данном документе, относятся к операциям описанным в п. 8.4.1 и п. 8.4.2 документа “RT.ClusterManager. Руководство администратора”.
Предлагаемая конфигурация кластеров, создаваемых на основании плагина «RT.StreamingNiFi», состоит из 3 нод, принадлежащих одному провайдеру, и отдельного сервера для установки RT.ClusterManager, который не входит в состав кластера:
В данном описании ноды – сервера (хосты) на базе операционных систем семейства Linux, которые будут включены в кластер.
Важно: При развёртывании стандартного кластера необходимо строго придерживаться порядка установки компонентов, указанного в таблицах ниже. В иных случаях существует возможность частично откорректировать распределение.
Примечание: В RT.ClusterManager версии 2.Х-ХХ был изменен дизайн и терминология, поменялись местами термины “Компонент” и “Сервис”. Так в RT.ClusterManager версии 1.Х-ХХ: Zookeeper, HDFS … были сервисами, и входящие в них элементы программного обеспечения которые привязывались к нодам назывались компонентами, а в RT.ClusterManager версии 2.Х-ХХ: Zookeeper, HDFS … стали компонентами, и входящие в них элементы программного обеспечения которые привязываются к нодам называются сервисами. В данном документе используется терминология RT.ClusterManager версии 2.Х-ХХ.
В следующей таблице представлен порядок распределения по нодам компонентов и их сервисов на основании плагина «RT.StreamingNiFi»:
Важно: При установке, придерживайтесь порядка компонент, указанных в таблицах.
№ | Компонент | Назначение | Распределение сервисов по нодам |
---|---|---|---|
1 | zookeeper |
Программная служба для координации распределенных систем. Проверка статуса - см. п. 3.1 |
server - m-1, m-2, m-3 |
2 | nifi |
Автоматизация обмена данными между программными системам. Проверка статус - см. п. 3.2 |
nifi - m-1 (или любое количество) |
Для проверки статуса zookeeper на каждом хосте, на котором установлен сервис zookeeper server можно воспользоваться командой:
/usr/lib/zookeeper/bin/zkServer.sh status
При корректно работающем сервисе в выводе должен быть упомянут путь до файла конфигурации, используемый сетевой порт, сетевой адрес/имя, статус SSL и режим работы сервиса (Mode: leader или follower. На одном хосте должен быть режим – leader, на остальных – follower) :
???
При установке с керберезированного кластера требется наличие TLS сертификатов. Понадобится:
- CA ключ (1 экзмпляр)
- CA сертификат (1 экзмпляр)
- TLS ключ для сервера (1 * кол. серверов nifi)
- TLS сертификат для сервера (1 * кол. серверов nifi)
Сертификаты можно генерировать и на стороне Windows server, так и на стороне Linux сервер
В продакшен среде возможно уже будет свой корневой сервер сертификации и корневой сертификат делать не нужно (нужно тогда связаться с его владельцем и получить дальнейшие инструкции от него. Далее описан метод изготовления самозаверенных сертификатов на Linux
1. Корневой сертификат
Создаём закрытый ключ длинной 2048
openssl genrsa -out ca.pem 2048
Создаём сертификат самоподписанного ключа
openssl req -x509 -sha256 -new -nodes -key ca.pem -days 3650 -out ca-cert.pem \
-subj "/C=RU/ST='Irkutskaya Oblast'/L=Irkutsk/O=ACLTelekom/OU=IT/CN=server_name"
2. Сертификаты нод (серверов nifi)
# Создаём зашифрованный запрос на выпуск сертификата - CSR (Certificate Signing Request)
openssl req -newkey rsa:2048 -nodes -days 3650 \
-keyout server-key.pem \
-out server-req.pem \
-subj "/C=RU/ST='Irkutskaya Oblast'/L=Irkutsk/O=ACLTelekom/OU=IT/CN=server_name"
Создаём из CSR, ключа сервера и CA сертификат ноды
openssl x509 -req -days 3650 -set_serial 01 \
-in server-req.pem \
-out server-cert.pem \
-CA cacert.pem \
-CAkey ca.pem