8. Дополнительные возможности
Инструкции данного раздела не выполняются в рамках первичной установки компонентов «Витрины данных НСУД».
Необходимость выполнения действий данного раздела определяется в процессе эксплуатации программы.
8.1. Установки опциональных приложений
Сервера сбора, хранения и индексирования логов устанавливаются независимо от наличия или отсутствия других приложений. Конкретные средства логирования и мониторинга не входят в состав данного решения и выбираются в соответствии с требованиями конкретного ведомства.
Обязательно необходимо установить, как минимум один из серверов базы данных ADB (Greenplum), ADQM (Clickhouse) или ADG (Tarantool).
Обязательно нужно установить, как минимум одно программное обеспечение для работы со СМЭВ. Это может быть либо СМЭВ3-адаптер либо группа приложений состоящих из ПОДД-адаптер, Агент ПОДД, База данных ПОДД-адаптера «MariaDB» и Диспетчер сообщений для ПОДД «Kafka» (ADSP).
Агент ПОДД и Диспетчер сообщений для ПОДД «Kafka» (ADSP) не входят в состав данного решения и устанавливаются отдельно, согласно соответствующей документации.
8.2. Логирование
Логи частей приложения могут быть найдены на соответствующих серверах, по относительным путям, описанным ниже (см. tab_gost_spg_8):
Наименование |
Относительный путь |
|---|---|
ClickHouse Server |
/var/log/clickhouse-server/clickhouse-server.log /var/log/clickhouse-server/clickhouse-server.err.log |
Greenplum Server |
/var/log/greenplum-server/greenplum-server.log /var/log/greenplum-server/greenplum-server.err.log |
Tarantool |
/var/log/tarantool-server/tarantool-server.log /var/log/tarantool-server/tarantool-server.err.log |
Apache Kafka |
/usr/lib/kafka/logs/*.log |
ПОДД-адаптер |
/opt/podd-migration/logs/application.log /opt/podd-adapter/logs/application.log |
СМЭВ3-адаптер |
/opt/smev3-adapter/logs/application.log |
ETL |
/opt/Airflow/logs /opt/spark/logs /opt/hadoop/logs |
REST-адаптер |
/opt/rest/logs |
8.3. Обновление
8.3.1. Менеджер кластера ADCM
Чтобы обновить ADCM вы должны сделать следующее:
Загрузить новый образ в докер:
docker pull arenadata/:term:`ADCM`:latest
Остановить и удалить текущий контейнер:
docker stop :term:`ADCM` docker rm :term:`ADCM`
Создать новый:
docker create --name :term:`ADCM` -p 8000:8000 -v /opt/:term:`ADCM`:/:term:`ADCM`/data arenadata/:term:`ADCM`:latest
8.3.2. ADQM
Для обновления кластера ADQM при помощи ADCM необходимо выполнить следующие действия:
Загрузить новый
bundle. Для этого следует на вкладке BUNDLES в правом верхем углу нажать кнопку Upload bundles и выбрать файл с новым ``bundle``ADQM (см.image43).
Загрузка нового бандла
На вкладке CLUSTERS найти необходимый кластер ADQM и нажать кнопку Upgrade. При этом появляются доступные для обновления версии (см.
image44).
Доступные для обновления версии
Выбрав необходимую версию, убедиться, что она обновлена (см.
image45).
Версия обновлена
Зайти в обновленный кластер и выполнить RESTарт (см.
image46).
RESTарт кластера
8.3.3. Диспетчер сообщений ADS
Обновление кластера ADS доступно с версии 1.4.11
ADCM предоставляет возможность обновления существующего кластера ADS.
Процесс обновления состоит из двух последовательных шагов:
Обновление бандла;
Обновление кластера.
В текущей версии доступно обновление кластеров как версий 1.3.X, так и 1.4.X
8.3.3.1. Обновление бандла
Для обновления бандла необходимо:
Загрузить бандл ADS новой версии. После его загрузки на вкладке Clusters в строке кластера с более старой версией бандла в колонке Upgrade появляется пиктограмма, указывающая на возможность обновления (см.
image47).
Доступно обновление бандла
Нажать на пиктограмму в колонке Upgrade и выбрать доступную требуемую версию из списка (см.
image48).
Доступные обновления
В открывшемся диалоговом окне подтвердить действие, после чего кластер меняет состояние на
upgrade from 1.3.Xилиupgrade from 1.4.Xв зависимости от установленной версии бандла (см.image49).
Изменение состояния кластера после обновления
Примечание
Если заданные по умолчанию настройки сервисов Zookeeper, Kafka изменены, то их необходимо скопировать и сохранить прежде, чем приступить к обновлению конфигураций сервисов.
В частности, это касается файлов nifi.properties, zoo.cfg и server.properties сервиcов Nifi, Zookeeper и Kafka соответственно
8.3.3.2. Обновление кластера
После завершения операции Upgrade Configs в кластере становится доступным действие Upgrade. Данная операция применяет новые настройки, полученные на предыдущем шаге, и обновляет пакеты всех сервисов до указанных версий.
В поле Actions для обновляемого кластера нажать на пиктограмму и выбрать действие Upgrade (см.
image50).
Обновление пакетов сервисов
Подтвердить действие в открывшемся диалоговом окне нажатием кнопки Run.
После успешного завершения операции Upgrade кластеру присваивается состояние installed.
Если заданные по умолчанию настройки сервисов были изменены перед обновлением, то после операции Upgrade Configs необходимо выполнить действия для соответствующих сервисов:
Перейти к настройкам сервиса Zookeeper, проверить раздел zoo.cfg и при необходимости внести сохраненные ранее изменения;
Перейти к настройкам сервиса Kafka, проверить разделы Main и server.properties и при необходимости внести сохраненные ранее изменения;
8.3.4. ADB
ADCM предоставляет возможность обновления бандла существующего кластера ADB.
8.3.4.1. Обновление с изменением версии ADB
Для обновления необходимо:
Загрузить
bundleADB новой версии(см. п. 3.2.6 Установка ADB). После загрузки на вкладке Clusters в строке кластера с более старой версией бандла появится пиктограмма, указывающая на возможность обновления (см.image51).
Доступно обновление бандла
Нажать на появившуюся пиктограмму и выбрать действие Upgrade to <версия бандла> (см.
image52).
Upgrade to
Подтвердить действие в открывшемся диалоговом окне (см.
image53). После подтверждения кластер ADB меняет состояние сrunningнаready to upgrade.
Запрос на подтверждение действия
В поле Actions для обновляемого кластера нажать на пиктограмму и выбрать действие Upgrade (см.
image54).
Upgrade
Подтвердить действие в открывшемся диалоговом окне (см.
image55).
Запрос на подтверждение действия
8.3.4.2. Обновление PXF версии 3х
В состав бандла ADB, начиная с версии 5.17, входит сервис, позволяющий установить PXF версии 5x через ADCM.
Если в работающем кластере ADB ранее уже был установлен PXF версии 3x в сборке Arenadata, существует возможность его обновления до версии 5x через ADCM. Для этого необходимо:
Добавить сервис PXF в кластер (см. п. 3.2.6 Установка ADB).
Разместить компоненты сервиса PXF на хостах.
В поле
Actionsв строке сервиса PXF нажать на пиктограмму и выбрать действие Remove HAWQ PXF (legacy). В результате этого действия в кластере удаляется PXF версии*3x*с сохранением всех конфигурационных файлов. Это делает возможным установку PXF версии*5x*из бандла ADB (см.image56).
Remove HAWQ PXF (legacy)
Примечание
Корректность выполнения данного действия гарантируется только для PXF версии 3x в сборке Arenadata
Подтвердить действие в открывшемся диалоговом окне (см.
image57).
Запрос на подтверждение действия
Дождаться успешного завершения действия Clean (см.
image58).
Действие Clean успешно завершено
Выполнить установку сервиса PXF.
В случае если PXF в кластере отсутствует, установка производится без дополнительного действия Remove HAWQ PXF (legacy), описанного в пунктах 3-5.
8.3.5. ADG
Обновление ПО ADG осуществляется согласно документации на СУБД Tarantool (https://www.tarantool.io/en/doc/latest/book/admin/upgrades/ ).
8.4. Управление размером кластеров СУБД
8.4.1. Управление размером кластера ADB
8.4.1.1. Расширение кластера
Если кластер ADB разворачивается с помощью ADCM, часть действий по расширению кластера выполняется автоматически. После выполнения планирования нового аппаратного обеспечения необходимо добавить записи для новых хостов в выбранный кластер в интерфейсе ADCM, используя кнопку Add hosts на вкладке Hosts. Кроме того, необходимо выполнить инициализацию каждого хоста, если того требует провайдер хостов.
Когда хосты будут доступны для подключения по ssh для менеджера кластеров, необходимо запустить действие Expand кластера. В появившемся диалоге (см. image59) необходимо указать следующие параметры:
Reboot new servers after installation– возможна ли перезагрузка серверов, на которые добавляются новые компоненты. Перезагрузка требуется для применения значения некоторых параметров, изменяемых в процессе установки. Сервера будет необходимо перезагрузить позднее вручную, если это невозможно сделать в процессе расширения;Additional primary segments count– количество сегментов, которые необходимо добавить на хосты в кластере. Например, если в исходной конфигурации указано два сегмента на хост и в этом поле задано два дополнительных сегмента, в результате на уже существующие в кластере хосты будет добавлено по два сегмента, на новые – четыре. Если увеличение количества сегментов не требуется, оставьте значение по умолчанию –0.
Параметры расширения кластера
Для перехода к следующей странице конфигурации нажать кнопку Next и распределить компонент ADB Segment сервиса ADB по добавляемым хостам
(см. image60). Если используются сервисы PXF, Chrony, Monitoring Clinets, их компоненты также необходимо разместить на добавляемых хостах для корректного функционирования. Затем необходимо запустить расширение кластера кнопкой Run.
Распределение компонентов сервиса ADB по новым хостам
В процессе расширения кластера новые хосты инициализируются в соответствии с настройками сервиса ADB аналогично существующим хостам. Если при создании кластера запрашивается монтирование блочных устройств для создания каталогов с данными, на хостах должны присутствовать дисковые устройства с такими же именами
На первом шаге между новыми узлами и существующими производится обмен ssh-ключами, на добавленные хосты устанавливаются необходимые пакеты и производится их настройка. Затем генерируется схема для расширения кластера в зависимости от количества добавляемых хостов и использования зеркалирования. Если количество новых хостов в кластере больше числа сегментов на хост в используемой конфигурации, применяется spread-зеркалирование, иначе – group. На основе созданного файла схемы производится подготовка кластера к расширению. В случае успешного завершения подготовки кластер переводится в состояние expanding, и возврат предыдущей конфигурации становится невозможен.
На этом этапе возможна настройка порядка перераспределения таблиц, как указано в разделе Ранжирование таблиц для перераспределения.
В состоянии expanding для кластера становится доступно действие Redistribute, в процессе выполнения которого производится перераспределение таблиц. Для действия необходимо указать длительность сеанса в формате: ЧЧ:ММ:СС.
В случае если перераспределение успешно завершается до истечения указанного времени, схема расширения очищается и кластер переводится в состоянии running. Иначе становится доступен повторный запуск действия Redistribute для продолжения прерванного процесса.
8.4.1.2. Ранжирование таблиц для перераспределения
Порядком перераспределения таблиц можно управлять. Для этого необходимо скорректировать значения рангов таблиц в схеме расширения для определения приоритетов часто используемых таблиц и минимизации влияния на производительность. Доступное свободное место на диске может сказываться на ранжировании таблиц.
Для ранжирования таблиц с целью их последующего перераспределения необходимо подключиться к базе данных ADB с помощью PSQL или другого поддерживаемого клиента и обновить файл gpexpand.status_detail с помощью следующих команд:
=> UPDATE gpexpand.status_detail SET rank=1 WHERE fq_name = 'public.lineitem';
=> UPDATE gpexpand.status_detail SET rank=2 WHERE fq_name = 'public.orders';
В примере команды понижают приоритет всех таблиц до 10, а затем присваивают ранг 1 для lineitem и ранг 2 для orders. В результате сначала перераспределяется lineitem, затем orders, а далее все другие таблицы из файла gpexpand.status_detail.
Для исключения таблицы из перераспределения следует удалить ее из файла gpexpand.status_detail.
8.4.1.3. Перераспределение таблиц с помощью gpexpand
Перераспределение таблиц с помощью утилиты gpexpand осуществляется следующим образом:
Выполнить вход на мастер хост базы данных пользователем, который будет запускать ADB, например,
gpadmin.Запустить утилиту gpexpand. Можно использовать опцию
-dили-eдля определения периода времени сеанса расширения. Например, для запуска утилиты на срок до60часов, выполните следующую команду:*$ gpexpand -d 60:00:00*
Утилита перераспределяет таблицы до тех пор, пока последняя таблица в схеме не завершится, или пока не будет достигнут период указанной длительности (или не будет достигнуто установленное время окончания). Утилита gpexpand обновляет статус и время сессии в файле gpexpand.status при запуске и завершении перераспределения.
8.4.1.4. Мониторинг перераспределения таблиц
Во время процесса перераспределения таблицы можно запросить схему расширения. В представлении gpexpand.expansion_progress содержится текущая сводка хода выполнения, включая предполагаемую скорость перераспределения таблицы и расчетное время до завершения операции. Для информации о статусе таблицы необходимо запросить gpexpand.status_detail.
После завершения перераспределения первой таблицы gpexpand.expansion_progress выполняет предварительный подсчет и обновляет оценку по скорости перераспределения всех таблиц. Расчеты
перезапускаются каждый раз при инициализации сеанса перераспределения таблицы с помощью gpexpand. Для мониторинга прогресса необходимо
подключиться к базе данных ADB с помощью PSQL или другого поддерживаемого клиента и выполнить запрос gpexpand.expansion_progress с помощью следующей команды:
*=# SELECT \* FROM gpexpand.expansion_progress;*
* name | value*
*------------------------------+-----------------------*
* Bytes Left | 5534842880*
* Bytes Done | 142475264*
* Estimated Expansion Rate | 680.75667095996092 MB/s*
* Estimated Time to Completion | 00:01:01.008047*
* Tables Expanded | 4*
* Tables Left | 4*
*(6 rows)*
В таблице gpexpand.status_detail хранится информация о каждой таблице в схеме: статусы, время последнего обновления и дополнительные сведения. Для просмотра статуса таблицы необходимо подключиться к базе данных ADB с помощью PSQL или другого поддерживаемого клиента и выполнить запрос gpexpand.status_detail:
*=> SELECT status, expansion_started, source_bytes FROM*
*gpexpand.status_detail WHERE fq_name = 'public.sales';*
* status | expansion_started | source_bytes*
*-----------+----------------------------+--------------*
* COMPLETED | 2017-02-20 10:54:10.043869 | 4929748992*
*(1 row)*
8.4.1.5. Удаление временной схемы расширения
Для выполнения очередной операции расширения в системе ADB сначала необходимо удалить существующую схему расширения.
После завершения и проверки операции расширения схему расширения можно безопасно удалить. Для этого необходимо выполнить следующий порядок действий:
Выполнить вход на мастер хост базы данных пользователем, который будет запускать ADB, например,
gpadmin.Запустить утилиту gpexpand с параметром
-c.
Например:
*$ gpexpand -c*
*$*
При этом в некоторых системах требуется дважды нажать клавишу Enter.
8.4.1.6. Сжатие кластеров
В утилите ADCM выключается хост, балансировщик автоматически перераспределяет нагрузку по другим хостам. Выполняется проверка работоспособности СУБД Greenplum. При этом возможно некоторое падение производительности.
8.4.2. Управление размером кластера ADG
8.4.2.1. Расширение кластера
Подробная инструкция по управлению кластером Tarantool приведена в документации Tarantool (https://www.tarantool.io/ru/doc/latest/book/cartridge/cartridge_admin/#changing-the-cluster-topology).
При добавлении нового развернутого экземпляра в новый или уже существующий набор реплик:
Кластер валидирует обновление конфигурации, проверяя доступность нового экземпляра с помощью модуля membership.
Модуль membership работает по протоколу UDP и может производить операции до вызова функции box.cfg.
Внимание
Все узлы в кластере должны быть рабочими, чтобы валидация была пройдена.
Новый экземпляр ожидает, пока другой экземпляр в кластере не получит обновление конфигурации (оповещение реализовано с помощью того же модуля membership). На этом шаге у нового экземпляра еще нет своего UUID.
Как только новый экземпляр понимает, что кластер знает о нем, экземпляр вызывает функцию
box.cfgи начинает работу.
Оптимальная стратегия подключения новых узлов к кластеру состоит в том, чтобы развертывать новые экземпляры в наборе реплик с нулевым весом для каждого экземпляра, а затем увеличивать вес. Как только вес обновится и все узлы кластера получат уведомление об изменении конфигурации, сегменты начинают мигрировать на новые узлы.
Чтобы добавить в кластер новые узлы, выполните следующие действия:
Разверните новые экземпляры Tarantool, как описано в разделе по установке ADG.
Если новые узлы не появились в веб-интерфейсе, нажмите Probe server (Найти сервер) и укажите их URI вручную (см.
image61).
Поиск сервера
Если узел доступен, он появится в списке.
В веб-интерфейсе создайте новый набор реплик с одним из новых экземпляров. Для этого выполните следующие действия:
Нажмите Configure (Настроить) рядом с ненастроенным сервером.
Отметьте флажками необходимые роли.
Нажмите Create replica set (Создать набор реплик).
Для экземпляров vshard-storage, вес по умолчанию становится равным 0 после начальной загрузки vshard, которая происходит во время первоначального развертывания кластера. Вы также можете сделать это следующим образом:
Добавьте дополнительные экземпляры к существующему набору реплик. Для этого выполните следующие действия:
Нажмите Configure (Настроить) рядом с ненастроенным сервером.
Нажмите на вкладку Join replica set (Присоединиться к набору реплик).
Выберите набор реплик и нажмите Join replica set.
При необходимости повторите действия для других экземпляров, чтобы достичь необходимого уровня резервирования.
При развертывании нового набора реплик vshard-storage заполните необходимую информацию:
Нажмите Edit (Изменить) рядом с необходимым набором реплик.
Увеличьте его вес и нажмите Save (Сохранить), чтобы начать балансировку данных.
8.4.2.2. Балансировка данных
Балансировка (решардинг) запускается через определенные промежутки времени и при добавлении в кластер нового набора реплик с весом, отличным от нуля.
Самый удобный способ мониторинга процесса балансировки заключается в том, чтобы отслеживать количество активных сегментов на узлах хранения. Сначала в новом наборе реплик 0 активных сегментов. Через некоторое время фоновый процесс балансировки начинает переносить сегменты из других наборов реплик в новый. Балансировка продолжается до тех пор, пока данные не будут распределены равномерно по всем наборам реплик.
Чтобы отслеживать текущее количество сегментов, подключитесь к любому экземпляру Tarantool через административную консоль и выполните команду:
COPY
tarantool> vshard.storage.info().bucket
---
- receiving: 0
active: 1000
total: 1000
garbage: 0
sending: 0
...
Количество сегментов может увеличиваться или уменьшаться в зависимости от того, переносит ли балансировщик сегменты в узел хранения или из него.
8.4.2.3. Отключение наборов реплик
Под отключением всего набора реплик (например, для технического обслуживания) подразумевается перемещение всех его сегментов в другие наборы реплик.
Чтобы отключить набор реплик, выполните следующие действия:
Нажмите Edit рядом с необходимым набором реплик.
Укажите
0как значение веса и нажмите Save (см.image62).
Указание веса
Подождите, пока процесс балансировки не завершит перенос всех сегментов набора.
8.4.2.4. Исключение экземпляров
После того, как экземпляр будет исключен из кластера, он никогда не сможет снова участвовать в кластере, поскольку ни один экземпляр не будет принимать его.
Чтобы исключить экземпляр из кластера, нажмите … рядом с ним, затем нажмите Expel server (Исключить сервер) и Expel (см. image63).
Исключение экземпляра
Есть два ограничения:
Нельзя исключить
лидера, если у него есть реплика. Сначала передайте рольлидера.Нельзя исключить
vshard-хранилище, если оно хранит сегменты.
Установите значение веса на 0 и дождитесь завершения ребалансировки.
8.4.3. Управление размером кластера ADQM
8.4.3.1. Предварительные действия
Для расширения кластера ADQM посредством ADCM необходимо добавить новые хосты в кластер (см. image64).
Кластер с двумя хостами
Есть кластер с двумя хостами и необходимо его расширить. Для этого выполните следующие действия:
В правом верхнем углу следует нажмите кнопку Add hosts.
Откроется список возможных для добавления хостов (см.
image65).
Список возможных для добавления хостов
3. В результате добавления нового хоста он появляется в списке кластера
(см. image66).
Результат добавления нового хоста
8.4.3.2. Расширение
Для выполнения операции расширения необходимо выполнить следующие действия:
На вкладке Services открыть конфигурацию сервиса ADQM DB.
Найти пункт Default cluster topology (см.
image67).
Топология по умолчанию
Затем необходимо изменить топологию, добавив в нее новые хосты (см.
image68).
Добавление новых хостов в топологию
После этого на вкладке Services для сервиса ADQM DB в выпадающем меню Actions выбирать действие expand (см.
image69).
Выбор действия expand
При этом открывается экранная форма с текущим распределением сервисов на хостах (см. image70).
Текущее распределение сервисов на хостах
5. Далее для расширения следует выполнить клик на кнопке ClickHouse Server, а потом выбрать хосты, на которые необходимо его доставить
(см. image71).
Перераспределение хостов
По завершению перераспределения хостов необходимо нажать кнопку Run. В результате действия начинается процесс расширения, наблюдать который можно в списке запущенных задач.