Как мы разворачиваем ClickHouse-кластер через Arenadata: практический гайд для DevOps

Привет, Хабр! Меня зовут Никита Ивкин, я — ведущий DevOps-инженер РТЛабс, работаю с инфраструктурой Госуслуг. Сегодня я покажу один из наших реальных сценариев: как мы разворачиваем ClickHouse через Arenadata, почему выбрали именно такую топологию и какие нюансы появляются между кнопкой Install и действительно рабочим кластером. Мы разберём причины выбора такой схемы, увидим, где ADCM действительно упрощает эксплуатацию, какие мелочи всплывают вокруг SSH и Ansible и почему после успешного Install хост всё ещё может выглядеть «жёлтым». В конце — проверки со стороны самого ClickHouse и несколько вещей, которыми мы дополнили кластер уже после раскатки.

Что такое Arenadata и какую задачу она решает

В этой статье речь не про «ещё одну базу данных». В нашем сценарии Arenadata — это связка ADQM и ADCM: ADQM предоставляет ClickHouse как аналитический движок, а Arenadata Cluster Manager (ADCM) отвечает за развёртывание и дальнейшее управление кластером.

К Arenadata мы пришли не потому, что хотелось добавить ещё один GUI. Одним из драйверов было импортозамещение: исторически в корпоративной аналитике широко использовался Greenplum — MPP-СУБД для хранения и обработки больших объёмов данных. При переходе на отечественный стек мы стали использовать решения Arenadata. Но сама «боль перехода» была шире простой замены одной СУБД на другую: вместе с новым продуктом нужно было заново собрать понятную операционную модель — как одинаково разворачивать кластеры в нескольких контурах, фиксировать версии и параметры, проводить обновления и не превращать каждый новый кластер в отдельный snowflake.

В прежнем стеке часть эксплуатационных процедур сильнее была завязана на конкретный продукт и отдельные runbook/Ansible-сценарии. С ADCM мы получили единый жизненный цикл объектов: hosts → services → components → configuration → mapping → action. Ansible при этом никуда не исчез: bundle всё также может выполнять Ansible-задачи, но теперь запуск, конфигурация и состояние привязаны к объектам кластера и видны из одной точки.

Если упростить, то ADCM — это централизованный менеджер для data-сервисов. Через Web UI или API в нём описываются хосты, сервисы, конфигурация и размещение компонентов; bundle задаёт доступные параметры и действия. На целевых хостах ADCM выполняет предусмотренные bundle операции, в том числе через Ansible-задачи.

Если хочется посмотреть механику глубже: официальная документация ADCM и архитектура ADQM.

Практический смысл не в том, чтобы заменить знание ClickHouse красивым интерфейсом. Он в воспроизводимости: одна и та же схема развёртывания, централизованная конфигурация, понятное размещение ролей и повторяемые изменения. Чем больше кластеров и серверов, тем заметнее эта ценность.

Для уже существующей инфраструктуры ADCM можно использовать без создания новых виртуальных машин: готовые on-premises-хосты подключаются через SSH hostprovider. Для автоматизации доступны API и bundle — пакеты, в которых описаны состав продукта, конфигурация и логика операций.

Дальше под «Arenadata» я буду иметь в виду именно ADQM + ADCM. Остальные продукты экосистемы в этот сценарий не входят.

Почему здесь вообще нужен ADCM

ClickHouse можно нормально эксплуатировать и без ADCM: устанавливать пакетами, раскатывать Ansible-ролями, хранить конфигурацию в Git и собирать вокруг этого собственный CI/CD. Для небольшой инфраструктуры этого может быть достаточно, сам по себе ADCM не делает ClickHouse быстрее или отказоустойчивее.

Но когда задача превращается из «поставить один кластер» в «одинаково разворачивать и сопровождать несколько контуров», появляется отдельный слой операционной сложности: хосты и роли, версии компонентов, параметры, обновления, повторные действия и текущее состояние. ADCM забирает именно эту механику.

В нашем случае инфраструктура уже существует и живёт по своим процессам: серверы выдаются и готовятся вне ADCM, сеть и доступы согласуются заранее, диски и ОС тоже появляются до начала установки ADQM. Поэтому нам не нужен инструмент, который создаёт или удаляет ВМ. Нам нужен слой, который получает уже подготовленный on-premises-хост, знает его роль в кластере и воспроизводимо раскатывает на него нужный компонент. Отсюда и выбор SSH hostprovider.

Почему не «просто Ansible»? Мы Ansible не выбрасывали. Для нас разница в том, где живёт жизненный цикл кластера. В чистой схеме роли, inventory, версии и состояние нужно собирать вокруг себя самостоятельно; в ADCM это связано с конкретными hosts/services/components и действиями bundle. Для одного кластера разница небольшая, для нескольких контуров она становится заметнее.

Ниже — конкретный путь от пяти подготовленных серверов до кластера с двумя ClickHouse Server и отдельным кворумом из трёх ClickHouse Keeper. Это минимальная демонстрационная топология: её задача — показать механику развёртывания, а не быть универсальным production-шаблоном.

Что будем собирать

Исходная схема простая: 5 серверов уже созданы и имеют необходимую сетевую связанность. На этом контуре у нас ALT SP Server 10.2.2; все 5 адресов находятся в одном внутреннем сегменте 192.168.1.0/24. ADCM подключается к хостам по SSH, а два ClickHouse Server и три Keeper общаются между собой внутри этого сегмента. CPU/RAM и sizing дисков здесь намеренно не привожу: это уже функция конкретной нагрузки, а не механики развёртывания через ADCM.

Дисклеймер: IP-адреса и имена хостов используемые в статье вымышлены. Реальные данные инфраструктуры не используются.

ch_tm:
  hosts:
    сlickserver01.rtlabs: 192.168.1.11
    сlickserver02.rtlabs: 192.168.1.12
    сlickkeeper01.rtlabs: 192.168.1.13
    сlickkeeper02.rtlabs: 192.168.1.14
    сlickkeeper03.rtlabs: 192.168.1.15
Логическая схема:

ADCM
  |
  +-- SSH/22 --> 192.168.1.0/24
                 |-- сlickserver01.rtlabs 192.168.1.11 ClickHouse Server
                 |-- сlickserver02.rtlabs 192.168.1.12 ClickHouse Server
                 |-- сlickkeeper01.rtlabs 192.168.1.13 ClickHouse Keeper
                 |-- сlickkeeper02.rtlabs 192.168.1.14 ClickHouse Keeper
                 `-- сlickkeeper03.rtlabs 192.168.1.15 ClickHouse Keeper

На схеме ролей это выглядит так:

clickserver01 и clickserver02 — ClickHouse Server / ADQMDB;

clickkeeper01–03 — ClickHouse Keeper;

ADCM — точка, из которой описываем конфигурацию и запускаем установку.

Здесь важное слово — «подготовленные». ADCM не заменяет базовую инфраструктурную подготовку. К моменту, когда хост появляется в ADCM, на нём уже должна быть поддерживаемая ОС, рабочие FQDN/DNS и синхронизация времени, смонтированы нужные файловые системы, открыт сетевой доступ до соседних узлов и репозиториев, а для ADCM подготовлен SSH-пользователь с нужной sudo-политикой. То есть ADCM устанавливает и сопровождает продуктовый кластер, но не должен внезапно выяснять в середине Install, что на одном сервере нет места, не резолвится имя или закрыт нужный маршрут.

Перед стартом проверьте:

— версия ОС поддерживается выбранной версией bundle;

— FQDN/DNS работают стабильно, между узлами есть необходимая сетевая связанность;

— на хостах настроена синхронизация времени;

— подготовлены диски, каталоги и права на них; ёмкости достаточно под данные и логи;

— ADCM имеет SSH-доступ к целевым машинам, а пользователь — права, необходимые для действий bundle;

— ADCM установлен, нужные bundle загружены, а используемые пакетные репозитории доступны с целевых хостов.

Мониторинг, резервное копирование, sizing дисков и production-hardening в этой статье подробно не разбираю: здесь фокус именно на воспроизводимом развёртывании кластера через ADCM.

Шаг 1. Создаём каркас кластера

Начинаем с раздела Clusters. В ADCM кластер создаётся на базе загруженного product bundle. Bundle описывает доступные сервисы, компоненты, параметры конфигурации и действия для конкретной версии продукта. На этом этапе ClickHouse на серверах ещё не устанавливается — мы создаём объект кластера и выбираем его версию.

Нажимаем Create cluster, выбираем ADQM, нужную версию bundle, задаём имя и описание.

После создания кластер появляется в списке в состоянии created. Это его «скелет»: объект уже существует в ADCM, но на целевых хостах пока ничего не установлено.

Шаг 2. Добавляем существующие серверы через SSH hostprovider

Следующая задача — добавить в ADCM наши 5 машин. Поскольку серверы уже существуют и управляются вне Arenadata, используем SSH hostprovider. Для нас это сознательное разделение ответственности: жизненный цикл ВМ, сеть и диски остаются в инфраструктурном контуре, а ADCM получает право выполнять на готовом хосте только те операции, которые нужны для развёртывания и сопровождения продукта.

Подробно про действия и параметры: SSH hostprovider в документации Arenadata.

В разделе Hosts создаём первый хост и привязываем его к нашему кластеру.

После создания хост появляется в списке. Сам факт появления записи ещё не означает, что на сервере уже установлен ClickHouse: пока ADCM знает, какой это хост и к какому кластеру он относится.

Шаг 3. Настраиваем SSH-подключение

Открываем конфигурацию созданного хоста и задаём параметры, которые ADCM будет использовать во время установки и последующих операций. В нашем сценарии — аутентификация по SSH-ключу.

Минимально нужны пользователь, адрес сервера, порт и приватный SSH-ключ. Пароль в таком сценарии не требуется. Соответствующий публичный ключ должен быть разрешён на целевой машине, а пользователь — иметь права, необходимые для действий bundle.

Из практики. Если хост уже появился в ADCM, это ещё не значит, что с него можно начинать Install. Я всегда отдельно прогоняю Check connection и смотрю Jobs с подробным выводом. На этой же группе серверов мы однажды поймали характерную мелочь: Ansible автоматически выбрал /usr/bin/python2.7 на Keeper-ноде, хотя Python 3 тоже был установлен. Такие несовпадения не всегда ломают раскатку сразу, но потом дают очень неочевидные ошибки модулей. Поэтому версия Python и фактически выбранный Ansible-интерпретатор у нас теперь входят в pre-flight.

Для production это отдельная точка безопасности: хранение и ротация приватного ключа, доступ к нему и sudo-политика пользователя должны соответствовать требованиям вашего контура. Здесь показываю механику подключения, а не универсальную модель управления секретами.

Повторяем операцию для остальных четырёх серверов. В результате в ADCM должны быть видны все 5 хостов.

На overview кластера они пока отображаются без работающих сервисов — это ожидаемо: мы только описали инфраструктуру, но ещё не выполнили раскатку.

Шаг 4. Добавляем ADQMDB и ClickHouse Keeper

Переходим на вкладку Services. Для этой топологии нужны два сервиса: ADQMDB и ClickHouse Keeper.

ADQMDB — сервис базы данных ClickHouse в составе ADQM. ClickHouse Keeper отвечает за координацию репликации и распределённых DDL-операций; пользовательские запросы к данным он не обрабатывает. Keeper выносим на отдельные три хоста, чтобы отделить координацию от ресурсов узлов базы.

Шаг 5. Настраиваем ClickHouse Keeper

Начнём с Keeper. В нашем случае большую часть параметров мы сознательно оставляем стандартной, а меняем только пути хранения coordination log, snapshots и обычного log path. Причина довольно приземлённая: сервисные данные и логи у нас не должны бесконтрольно расти на системном разделе. Предсказуемые отдельные каталоги проще мониторить, включать в процедуры резервирования и чистить по понятным правилам. Для самого запуска Keeper эти нестандартные пути необязательны, это наша эксплуатационная договорённость.

Журнал координации хранит последовательность изменений, а snapshots позволяют восстановить состояние без полного проигрывания истории. Для production пути нужно выбирать с учётом дисковой схемы, резервирования, свободного места и мониторинга — значения со скриншота не стоит копировать механически.

Что мы специально не тюним на старте. Таймауты, параметры Raft и другие низкоуровневые настройки Keeper легко начать «оптимизировать» просто потому, что они есть в форме. Мы начинаем с дефолтов bundle и меняем их только при наличии измеримой причины — по метрикам, логам или результатам нагрузочных/отказных тестов.

Шаг 6. Настраиваем ClickHouse Server

Теперь переходим к ADQMDB. В bundle видны два компонента: ClickHouse Server и JDBC Bridge. В нашем кластере JDBC Bridge не нужен: ClickHouse не должен ходить из запросов во внешние СУБД через JDBC, поэтому отдельный процесс здесь только увеличил бы число компонентов, которые нужно обновлять и мониторить. Bridge имеет смысл, когда в запросах используются внешние JDBC-источники через соответствующую table function или engine. В документации Arenadata отдельно отмечено, что при использовании JDBC Bridge его следует ставить на все хосты, где установлен ClickHouse Server.

См. пример работы с ClickHouse JDBC Bridge.

Для ClickHouse Server включаем режим Advanced — часть параметров скрыта по умолчанию, а нам понадобится настройка топологии и coordination system.

Топология: один shard, две replicas

В Cluster configuration задаём имя кластера и описываем его топологию. В нашем примере используются две реплики ClickHouse Server. Это означает, что обе машины входят в один логический shard как replicas. Оставшиеся три сервера в эту секцию не добавляем: они предназначены для Keeper.

Топология зависит от нагрузки и требований к отказоустойчивости. В нашем сценарии на первом этапе важнее было получить простую отказоустойчивую пару, чем сразу добавлять горизонтальное шардирование, поэтому оставляем 1 shard × 2 replicas. Это не «правильная схема ClickHouse вообще»: если объём данных или нагрузка потребуют масштабирования по шардам, это будет отдельное архитектурное решение, а не ещё один переключатель в ADCM.

Coordination system: выделенный ClickHouse Keeper

В параметре Coordination system выбираем Clickhouse_keeper (allocated). Тем самым говорим ADQMDB использовать отдельный сервис Clickhousekeeper, который мы добавили в этот же кластер. Keeper будет использоваться для координации репликации и выполнения distributed DDL.

Плюс такого варианта в ADCM в том, что связь между сервисами описывается на уровне кластера. Нам не приходится вручную собирать отдельный список Keeper-узлов в каждом месте конфигурации: после mapping ADCM знает, где размещён coordination service. Но цена удобства тоже есть. Во-первых, появляются три отдельные Keeper-ноды, которые нужно мониторить и сопровождать. Во-вторых, конфигурация сильнее завязана на bundle и mapping: ручная правка сгенерированных конфигов вне ADCM создаёт drift и при следующем действии может быть перезаписана. Поэтому при диагностике мы смотрим и на желаемую конфигурацию в ADCM, и на то, что реально сгенерировано на хосте.

LDAP — только если он действительно нужен

Следующий блок — LDAP. Универсальной конфигурации здесь нет: адреса каталогов, bind-пользователь, search base, TLS и правила сопоставления зависят от вашей инфраструктуры. Поэтому этот фрагмент — место интеграции, а не готовый шаблон.

Если LDAP в вашем контуре не используется, этот шаг можно пропустить. Если используется, значения должны соответствовать корпоративной схеме каталогов и требованиям безопасности.

Логирование и пользовательские политики

Далее настраиваем Log settings. На показанном стенде включено достаточно подробное логирование — это удобно при вводе кластера в эксплуатацию и диагностике. В production такой уровень детализации нужно выбирать осознанно: системные логи и таблицы ClickHouse могут заметно расходовать место.

Наш подход к логированию. На вводе кластера в эксплуатацию мы предпочитаем иметь больше диагностических данных, чем меньше: первые ошибки обычно проще поймать по полному контексту. Но после стабилизации обязательно возвращаемся к retention/TTL и объёму системных таблиц — подробное логирование без контроля очень быстро превращается из помощника в потребителя диска.

После этого задаём Default user and policy settings и дополнительные default_profile_settings. В нашем примере часть флагов включена, чтобы разрешить управление доступом и необходимыми сущностями через ClickHouse. Права default-пользователя, управление пользователями и именованными коллекциями должны соответствовать вашей модели доступа, копировать эти значения как «рекомендуемые» не стоит.

Advanced configuration parameters

Последний изменяемый блок в ADQMDB — Advanced configuration parameters. Сюда попадают параметры ClickHouse, которые не вынесены в отдельные поля основной формы bundle. Это удобная точка расширения, но одновременно самое простое место получить конфигурацию, которую трудно сопровождать.

Правило простое: добавляем сюда только параметры, назначение которых понимаем и которые действительно нужны конкретному кластеру. Я намеренно не превращаю этот раздел в набор «рекомендуемых тюнингов»: такие значения зависят от версии ClickHouse, профиля нагрузки и требований проекта.

Полный список параметров для конкретной версии лучше сверять с ADQM configuration reference.

Практический принцип. Каждый параметр, который мы уводим в Advanced configuration parameters, автоматически становится частью нашего upgrade debt. Рядом с нестандартным значением должно быть понятно, зачем оно появилось и как проверить, что оно всё ещё нужно после обновления ClickHouse или bundle. Иначе через полгода получается коллекция «магических» настроек, которые никто не решается удалить.

Шаг 7. Маппим компоненты на хосты

Конфигурация сервисов готова, осталось определить, где именно они будут работать. На вкладке Mapping назначаем ClickHouse Server на два хоста clickserver01 и clickserver02, а ClickHouse Keeper Server — на три clickkeeper-хоста.

Для Keeper принципиален нечётный размер кворума. Три узла — минимальная типичная отказоустойчивая схема: потеря одного участника не лишает кворум большинства. В нашем случае Keeper и ClickHouse Server не смешиваем на одних машинах ещё и из-за профиля нагрузки: тяжёлые SELECT, merges или фоновые операции на ClickHouse не должны конкурировать с координационным сервисом за CPU, I/O и память. При меньшем масштабе роли можно совмещать, но это уже осознанный компромисс между стоимостью инфраструктуры и изоляцией критичного сервиса.

Шаг 8. Проверяем схему и запускаем Install

Перед установкой ещё раз смотрим overview: сервисы созданы, хосты добавлены, компоненты распределены. До нажатия Install полезно проверить SSH-доступ, DNS/FQDN, сетевую связанность, диски и права пользователя. Большинство неприятных ошибок дешевле поймать здесь, чем в середине раскатки.

Если blocking concerns нет и конфигурация валидна, возвращаемся к кластеру и запускаем Install.

Дальше ADCM выполняет предусмотренные bundle действия на целевых серверах: устанавливает необходимые пакеты, формирует конфигурацию и запускает компоненты в соответствии с mapping. В результате из 5 подготовленных машин получаем описанный кластер без ручной установки ClickHouse и Keeper на каждом сервере.

Куда смотреть, если Install «завис». Первое место не overview, а Jobs конкретного action. Там видно, на каком хосте и на какой задаче остановился bundle; с Verbose обычно быстро отделяется проблема продукта от SSH, репозитория, прав или ОС. Это банальный совет, но он экономит больше времени, чем повторное нажатие Install «на удачу».

После завершения Install возвращаемся на overview кластера и проверяем состояние сервисов и хостов. Если все компоненты и хосты отображаются зелёным, кластер успешно развёрнут и готов к работе.

После первой успешной раскатки у нас был момент, который визуально выглядел почти как инцидент: Install завершился, ClickHouse работал, а хост в ADCM всё равно оставался жёлтым. Причина оказалась не в ClickHouse. В ADCM зелёная точка у хоста означает, что установлен statuschecker и от хоста регулярно приходят heartbeat-сигналы; жёлтая может означать, что statuschecker просто не установлен. Statuschecker — это небольшой демон, который позволяет ADCM регулярно получать состояние хоста и установленных на нём сервисов/компонентов. Поэтому для такого хоста открываем Actions → Install statuschecker, затем повторно проверяем connection и уже после этого разбираемся с компонентами, если статус не нормализовался.

Это поведение описано и в документации ADCM по Hosts/statuschecker.

Проверяем результат не только в ADCM

Зелёный статус в UI — хороший первый сигнал, но состояние кластера лучше подтвердить со стороны самого ClickHouse. Ниже — минимальные проверки, которые соответствуют нашей топологии.

Сначала проверяем, что ClickHouse видит обе реплики кластера:

SELECT
    cluster,
    shard_num,
    replica_num,
    host_name,
    host_address
FROM system.clusters
WHERE cluster = 'ch_tm'
ORDER BY shard_num, replica_num;

Для схемы 1 shard × 2 replicas здесь ожидаем две записи в одном shard с разными replica_num.

Проверяем, что ClickHouse может обратиться к coordination service:

SELECT *
FROM system.zookeeper
WHERE path = '/'
LIMIT 10;

После создания тестовой ReplicatedMergeTree полезно посмотреть состояние репликации:

SELECT
    database,
    table,
    is_leader,
    is_readonly,
    absolute_delay,
    queue_size
FROM system.replicas
ORDER BY database, table;

И отдельно проверяем distributed DDL через ON CLUSTER:

CREATE DATABASE IF NOT EXISTS habr_check ON CLUSTER ch_tm;

SELECT name
FROM system.databases
WHERE name = 'habr_check';

DROP DATABASE habr_check ON CLUSTER ch_tm;

Эти команды не заменяют полноценный acceptance-check, но быстро показывают, что топология, Keeper и ON CLUSTER работают не только на уровне статуса в ADCM.

Что проверить после установки

На кнопке Install работа DevOps-инженера не заканчивается. После базовых CLI-проверок фиксируем итоговый checklist:

• оба ClickHouse Server и все три ClickHouse Keeper находятся в ожидаемом состоянии в ADCM;

• Keeper собрал кворум, а ClickHouse Server видит coordination service;

• топология кластера соответствует ожидаемой в system.clusters;

• на тестовой ReplicatedMergeTree репликация работает, очередь не зависает, данные появляются на обеих репликах;

• distributed DDL выполняется через ON CLUSTER;

• настроены мониторинг, алерты, ротация логов и резервное копирование согласно требованиям проекта.

Для production отказоустойчивость нужно проверять до появления реальной нагрузки или в согласованное окно: останавливаем одну Keeper-ноду и убеждаемся, что кворум сохраняется; отдельно проверяем поведение при недоступности одной ClickHouse replica. На уже работающем проде «просто остановить ClickHouse ради проверки» — хороший способ получить настоящий инцидент, поэтому такие тесты мы не делаем спонтанно. Важно смотреть не только на статус сервисов, но и на запросы, очереди репликации и клиентское поведение в момент отказа.

Что в итоге даёт Arenadata в таком сценарии

Сам ClickHouse от использования ADCM не становится другой СУБД. Ценность здесь эксплуатационная: вместо набора отдельных ручных действий кластер описывается через понятные сущности hosts → services → components → configuration → mapping, после чего установка выполняется из одной точки.

Первый такой кластер можно с тем же успехом поднять Ansible-ролью. Выигрыш ADCM становится заметнее при повторении: второй и последующие контуры собираются по той же модели, а у команды есть единое место, где видно, какой компонент где должен находиться и с какой конфигурацией.

При этом ADCM не отменяет необходимость понимать ClickHouse. Всё так же нужно осознанно проектировать shards и replicas, выбирать схему Keeper, настраивать доступ, диски, лимиты, мониторинг и резервное копирование. GUI автоматизирует механику, но архитектурные решения за инженера не принимает.

Есть и обратная сторона: появляется дополнительный управляющий слой, а жизненный цикл кластера частично зависит от возможностей конкретного bundle. Чем больше нестандартных настроек уходит в Advanced configuration parameters, тем важнее документировать их и проверять совместимость при обновлениях. Это не минус сам по себе, а часть инженерного компромисса.

Что было после Install. На реальном контуре этим работа не закончилась. Для клиентского доступа мы добавили отдельную HA-обвязку с VIP на Keepalived перед двумя ClickHouse-нодами, а для наблюдаемости — ClickHouse exporter и стандартный node exporter. Это сознательно не включено в пошаговую часть статьи: ADCM решает развёртывание продуктового кластера, а единая точка входа, мониторинг, алерты и эксплуатационные runbook — следующий слой системы.

Следующий логичный шаг для нас — меньше ручных acceptance-check после раскатки: собрать SQL-smoke-тесты, проверку Keeper/репликации и базовые инфраструктурные проверки в один повторяемый post-install сценарий, а перед обновлением bundle прогонять его как регрессионный чек. Тогда статья из «как поставить» превращается в более полезную схему «как поставить и доказать, что после изменений всё осталось рабочим».

Заключение

Мы прошли весь путь от пяти подготовленных серверов до кластера из двух ClickHouse Server и трёх ClickHouse Keeper: добавили хосты через SSH hostprovider, настроили сервисы, описали topology и coordination system, распределили компоненты по машинам, запустили Install и проверили результат уже из ClickHouse.

Если свести подход к одной мысли: полезна не сама кнопка Install. Важнее, что до её нажатия схема кластера уже явно описана в одном месте, а после установки её можно проверить теми же техническими критериями, которыми мы проверяли бы кластер, собранный вручную. Именно это делает развёртывание повторяемым и удобным для дальнейшей эксплуатации.

Буду рад ответить на ваши вопросы, пишите их в комментариях.