Подготовка к установке основного экземпляра системы

В данном разделе описаны подготовительные действия, которые необходимо выполнить перед запуском установщика основного экземпляра системы.

Подготовка состоит из следующих этапов:

  1. Выбор машины для запуска установщика.

  2. Настройка доступа к кластеру Kubernetes с машины, на которой запускается установщик системы.

  3. Настройка доступа к системе по доменному имени.

  4. Настройка SSH-доступа с машины, на которой запускается установщик системы, к worker-узлам кластера.

  5. Применение дополнительных настроек, если узлы кластера работают под управлением ОС Альт Сервер или Альт СП Сервер.

  6. Добавление TLS-сертификатов для шифрования трафика ClickHouse в кластере Kubernetes.

    Данный этап необходимо выполнять, только если:

    • вы планируете устанавливать ClickHouse в кластере Kubernetes, а не в выделенном кластере;

    • необходимо включить шифрование трафика между системой и ClickHouse, используя для этого заранее созданные TLS-сертификаты.

  7. Настройка физических путей (physicalPath) дисков ClickHouse для корректного расчета метрик дискового пространства, занятого базами данных и хранилищами событий.

  8. Скачивание архива с файлами для установки и проверка его целостности.

  9. Создание дополнительных объектов StorageClass, если в кластере будет использоваться провайдер хранилища (storage provider) local-path-provisioner.

Выбор машины для запуска установщика

Определите машину, на которой будет запущен установщик основного экземпляра системы. Установщик может запускаться как на одном из master-узлов кластера Kubernetes, так и на машине администратора, имеющей сетевой доступ к кластеру.

Настройка доступа к кластеру Kubernetes

На машине, с которой будет выполняться установка, должны быть соблюдены следующие требования:

  1. Установлена утилита ansible.

  2. В системных переменных окружения указан путь к файлу kubeconfig.

    • Linux

    • Windows

    В ОС Linux путь к файлу kubeconfig по умолчанию — $HOME/.kube/config. Вы можете изменить его с помощью переменной окружения KUBECONFIG:

    export KUBECONFIG=<path_to_confg>

    Здесь:

    • <path_to_config> — путь к файлу kubeconfig.

    В ОС Windows путь к файлу kubeconfig по умолчанию — $%USERPROFILE%\.kube\config. Вы можете изменить его с помощью переменной окружения KUBECONFIG:

    $env:KUBECONFIG = <path_to_confg>

    Здесь:

    • <path_to_config> — путь к файлу kubeconfig.

Проверить доступ к кластеру можно, выполнив следующую команду:

kubectl get nodes

Если доступ к кластеру есть, отобразится список узлов кластера, например:

NAME                     STATUS   ROLES           AGE    VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE
master01.company.local   Ready    control-plane   140d   v1.26.3   10.10.10.1    <none>        RED OS MUROM (7.3.2)
worker01.company.local   Ready    <none>          140d   v1.26.3   10.10.10.2    <none>        RED OS MUROM (7.3.2)
worker02.company.local   Ready    <none>          140d   v1.26.3   10.10.10.3    <none>        RED OS MUROM (7.3.2)
worker03.company.local   Ready    <none>          140d   v1.26.3   10.10.10.4    <none>        RED OS MUROM (7.3.2)

Настройка доступа к системе по доменному имени

Если система будет установлена в кластер из одного узла, пропустите данный этап. На этапе Web access установки системы укажите полное доменное имя (FQDN) виртуальной машины, на которой функционирует кластер.

Если система будет установлена в кластер из нескольких узлов, в качестве доменного имени нельзя использовать FQDN master-узла кластера. Используйте доменное имя, не занятое ни одним другим сервисом.

Cоздайте A-запись на DNS-сервере вашей организации. Она позволит ассоциировать доменное имя, по которому будет доступна система, с IP-адресом, зарезервированным для использования кластером системы. Запросы, поступающие на этот адрес, будут перенаправляться на сервисы кластера балансировщиком MetalLB и контроллером ingress-nginx, входящими в пакет установки системы.

Доменное имя должно удовлетворять следующим требованиям:

  • Допустимые символы: a—​z, 0—​9, -, ..

  • Имя не должно начинаться и заканчиваться дефисом или точкой.

Пример допустимого доменного имени: evo.company.local.

  • Диапазон IP-адресов, зарезервированных для системы, и ее доменное имя потребуется указать на этапе Web access установки системы.

  • Инструкция по созданию A-записи приведена для DNS-сервера на базе Windows Server. Для выполнения настройки на другом DNS-сервере обратитесь к официальной документации его производителя.

Чтобы настроить сетевой доступ к кластеру системы:

  1. Запросите у сетевых инженеров IP-адрес, который будет зарезервирован для использования кластером системы. Убедитесь, что этот адрес доступен для обращений из внешних сетей.

  2. Добавьте исключение в диспетчере DHCP, чтобы адрес не мог быть динамически назначен другим хостам в сети:

    1. Откройте диспетчер DHCP. Например, это можно сделать, выполнив команду:

      dhcpmgmt.msc

    2. Выберите область адресов, соответствующих подсети, в которую входит зарезервированный адрес.

    3. Откройте контекстное меню пула адресов области и выберите опцию Диапазон исключения.

    4. В открывшемся окне укажите зарезервированный адрес и нажмите на кнопку Добавить.

  3. Добавьте A-запись в диспетчере DNS:

    1. Откройте диспетчер DNS. Например, это можно сделать, выполнив команду:

      dnsmgmt.msc

    2. Выберите необходимую зону прямого просмотра.

    3. Откройте контекстное меню зоны и выберите опцию Создать узел (А или АААА).

    4. В открывшемся окне укажите доменное имя и IP-адрес, который будет с ним ассоциирован.

    5. Чтобы обеспечить возможность преобразования IP-адреса в доменное имя, установите флажок Создать соответствующую PTR-запись.

    6. Нажмите на кнопку Добавить узел.

  4. Если требуется, добавьте CNAME-запись для обращения к специфическим службам кластера, например:

    grafana.rvision.company.local

    Чтобы добавить CNAME-запись:

    1. Откройте контекстное меню той же зоны, в которой создана A-запись, и выберите опцию Создать псевдоним (CNAME).

    2. В открывшемся окне укажите псевдоним и доменное имя системы.

    3. При необходимости измените время существования (TTL) псевдонима.

  5. Убедитесь, что преобразование доменного имени в IP-адрес и обратно выполняется успешно. Для этого:

    1. Откройте терминал на вашем сервере.

    2. Выполните команды:

      nslookup <system_domain_name>
nslookup <system_ip>

      Здесь:

      • <system_domain_name> — доменное имя системы, используемое в A-записи.

      • <system_ip> — IP-адрес системы, используемый в A-записи.

      Обе эти команды должны возвращать доменное имя и IP-адрес системы. Если преобразование доменного имени в IP-адрес или обратно не выполняется, проверьте корректность A-записи, повторно выполнив шаги инструкции.

Настройка SSH-доступа к worker-узлам кластера

Для загрузки образов контейнеров на worker-узлы установщик использует Ansible. Необходимо настроить SSH-доступ с машины, на которой запускается установщик системы, до worker-узлов под единой учетной записью. Поддерживается доступ по ключам или паролю.

Если на master-узле кластера установлена ОС Альт Сервер или Альт СП Сервер и планируется доступ по паролю, установите утилиту sshpass на master-узле:

sudo apt-get install sshpass

Для настройки SSH-доступа выполните следующие действия на каждом worker-узле кластера:

  1. Пользователю, от имени которого будет установлен кластер, необходимо выдать права суперпользователя (root). Для этого добавьте следующую строку в файл /etc/sudoers:

    <user> ALL=(ALL:ALL) NOPASSWD: ALL

    Здесь:

    • <user> — пользователь, от имени которого будет установлен кластер.

  2. Настройте SSH-доступ по паролю или по ключу:

    • Если планируется доступ по паролю:

      1. Установите пакет sshpass:

        • РЕД ОС

        • Альт Сервер, Альт СП Сервер, Astra Linux

        sudo dnf install sshpass
        sudo apt-get install sshpass

      2. Проверьте возможность подключения к узлу по SSH:

        ssh <user>@<fqdn>

        Здесь:

        • <user> — пользователь, от имени которого будет установлен кластер.

        • <fqdn> — полное доменное имя (FQDN) текущего узла.

          Чтобы узнать FQDN текущего узла, выполните команду:

          hostname -f

    • Если планируется доступ по ключу:

      1. Проверьте возможность подключения к узлу по SSH:

        ssh <user>@<fqdn>

        Здесь:

        • <user> — пользователь, от имени которого будет установлен кластер.

        • <fqdn> — полное доменное имя (FQDN) текущего узла.

          Чтобы узнать FQDN текущего узла, выполните команду:

          hostname -f

      2. Если подключение по SSH-ключу не настроено, сгенерируйте ключи и добавьте открытый ключ на узел:

        ssh-keygen
ssh-copy-id <user>@<fqdn>

        Здесь:

        • <user> — пользователь, от имени которого будет установлен кластер.

        • <fqdn> — полное доменное имя (FQDN) текущего узла.

Дополнительные настройки для Альт Сервер и Альт СП Сервер

Если узлы кластера работают под управлением ОС Альт Сервер или Альт СП Сервер, выполните следующие действия на master-узле:

  1. Установите коллекцию ansible.posix:

    ansible-galaxy collection install ansible.posix

  2. Скачайте пакеты libnewt52 и newt52 из репозитория Альт:

    wget http://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/x86_64/RPMS.classic/libnewt52-0.52.24-alt1.x86_64.rpm
wget http://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/x86_64/RPMS.classic/newt52-0.52.24-alt1.x86_64.rpm

  3. Установите пакеты libnewt52 и newt52:

    rpm -i libnewt52-0.52.24-alt1.x86_64.rpm
rpm -i newt52-0.52.24-alt1.x86_64.rpm

  4. Расширьте системную переменную PATH, чтобы утилиты, расположенные в каталоге <setup_dir>/r-vision/common/bin, были доступны из любой директории без указания полного пути:

    export PATH="$PATH:<setup_dir>/r-vision/common/bin"

    Здесь:

    • <setup_dir> — каталог, в который будет установлена система. По умолчанию: /opt.

Добавление TLS-сертификатов для шифрования трафика ClickHouse в кластере Kubernetes

Данный этап необходимо выполнять, только если:

  • вы планируете устанавливать ClickHouse в кластере Kubernetes, а не в выделенном кластере;

  • необходимо включить шифрование трафика между системой и ClickHouse, используя для этого заранее созданные TLS-сертификаты.

Разместите следующие файлы на машине, на которой будет запущен установщик системы:

Имя файла Назначение

ca.crt

Корневой сертификат доверенного центра сертификации.

tls.crt

TLS-сертификат сервера.

tls.key

Приватный ключ TLS-сертификата сервера.

В поле SAN (Subject Alternative Name) генерируемых TLS-сертификатов необходимо указать следующие имена:

  • DNS: *.clickhouse.<namespace>.svc.cluster.local;

  • DNS: clickhouse.<namespace>.svc.cluster.local;

  • DNS: *.clickhouse-headless.<namespace>.svc.cluster.local;

  • DNS: clickhouse-headless.<namespace>.svc.cluster.local;

  • DNS: clickhouse.

Здесь:

  • <namespace> — название пространства имен, которое будет указано на этапе Kubernetes cluster namespace to install установки системы.

Абсолютные пути к вышеуказанным файлам потребуется ввести на этапе ClickHouse setup установки системы.

Настройка физических путей (physicalPath) для дисков ClickHouse

Для корректного расчета и отображения метрик дискового пространства, занимаемого базами данных и хранилищами событий, необходимо создать конфигурационный файл, описывающий, какие диски ClickHouse используют общее дисковое пространство, а какие — раздельное.

Логика расчета метрики HDD

Приведенная ниже логика корректна, в случае если в вашей инсталляции ClickHouse не настроены шардирование и репликация (имеются один шард и одна реплика). Алгоритм расчета занятого и общего объема на дисках ClickHouse будет доработан в последующих версиях системы.

Логика расчета занятого и общего объема на дисках (HDD) зависит от физического пути, указанного для дисков ClickHouse:

  • Среди всех дисков, расположенных по одному физическому пути, в расчете показателя HDD участвует только первый диск.

  • Для каждого отличающегося физического пути показатель HDD суммируется.

Пример расчета метрики HDD при расположении дисков по разным физическим путям

Пусть тома базы данных событий расположены на следующих дисках:

  • Том hot_volume:

    • Диск hot_disk_A, физический путь — hot_disk_path_1.

    • Диск hot_disk_B, физический путь — hot_disk_path_1.

    • Диск hot_disk_C, физический путь — hot_disk_path_2.

  • Том cold_volume:

    • Диск cold_disk_A, физический путь — cold_disk_path_1.

    • Диск cold_disk_B, физический путь — cold_disk_path_1.

В таком случае для расчета метрики HDD будут просуммированы метрики следующих дисков:

  • hot_disk_A, поскольку это первый диск, находящийся по физическому пути hot_disk_path_1.

  • hot_disk_C, поскольку это единственный диск, находящийся по физическому пути hot_disk_path_2.

  • cold_disk_A, поскольку это первый диск, находящийся по физическому пути cold_disk_path_1.

Настройка конфигурационного файла для физических путей

  • Физический путь (physicalPath) — это виртуальная метка, обозначающая общий пул дискового пространства, а не путь, который использует СУБД ClickHouse. Она требуется только для корректного расчета метрики свободного места для баз данных и хранилищ событий и не влияет на логику работы ClickHouse.

  • Если указать одну и ту же метку для дисков ClickHouse, которые фактически используют раздельное дисковое пространство, либо разные метки для дисков с общим пространством, расчет метрики будет некорректным.

Процесс настройки конфигурационного файла для физических путей зависит от варианта установки ClickHouse:

  • ClickHouse в выделенном кластере

  • ClickHouse в кластере Kubernetes

  1. Определите пути, по которым хранятся данные дисков ClickHouse. Для этого:

    1. Подключитесь к любому узлу кластера ClickHouse.

    2. Перейдите в поддиректорию config.d в директории установки сервера ClickHouse.

    3. Откройте файл параметров кластера config.xml.

      Список путей, по которым находятся диски, находится внутри тега <storage_configuration>. Например:

      <storage_configuration>
    <disks>
        <default>
            <path>/var/lib/clickhouse/default/</path>
        </default>
        <hot_disk_1>
            <path>/var/lib/clickhouse/hot-1/</path>
        </hot_disk_1>
        <cold_disk_1>
            <path>/var/lib/clickhouse/cold-1/</path>
        </cold_disk_1>
    </disks>
</storage_configuration>

      В данном примере диски ClickHouse расположены по путям /var/lib/clickhouse/default/, /var/lib/clickhouse/hot-1/ и /var/lib/clickhouse/cold-1/.

    4. Выполните в терминале узла кластера ClickHouse следующую команду:

      df -h <clickhouse_paths>

      Здесь:

      • <clickhouse_paths> — пути к директориям, в которых расположены диски ClickHouse, через пробел, например: /var/lib/clickhouse/default/ /var/lib/clickhouse/hot-1/ /var/lib/clickhouse/cold-1/.

    5. В выводе команды сравните значения в столбце Filesystem. Если значение Filesystem совпадает для нескольких путей, соответствующие диски ClickHouse используют общее дисковое пространство. Если значения различаются — пространство раздельное. Пример вывода:

      Filesystem                Size  Used  Avail  Use%  Mounted on
/dev/sda0                 500G  200G   300G   40%  /var/lib/clickhouse/default/
/dev/mapper/vg0-hot       500G  250G   250G   50%  /var/lib/clickhouse/hot-1/
/dev/mapper/vg0-hot       500G  250G   250G   50%  /var/lib/clickhouse/cold-1/

      В данном примере диск default расположен на отдельном устройстве /dev/sda0, а диски hot_disk_1 и cold_disk_1 — на общем логическом томе LVM /dev/mapper/vg0-hot, используя общее дисковое пространство.

      Дисковое пространство считается общим при совпадении значений в столбце Filesystem вне зависимости от типа этого дискового пространства: например, блочное устройство /dev/sda0 и логический том LVM /dev/mapper/vg0-hot образуют по одному дисковому пространству.

  2. Сопоставьте каждому дисковому пространству идентификатор его физического пути — произвольный краткий идентификатор, содержащий латинские буквы, цифры и символы подчеркивания.

    Например, можно использовать такие идентификаторы, как sda0 и vg0.

    Использование косой черты (/) и обратной косой черты (\) не допускается, поскольку может привести к некорректному распознаванию идентификаторов.

  3. Создайте файл в формате JSON, содержащий массив объектов дисков Clickhouse и их идентификаторов физического пути. Каждый из объектов должен иметь следующий формат:

    { "name": "<disk_name>", "physicalPath": "<physical_path_id>" }

    Здесь:

    • <disk_name> — имя диска ClickHouse, например: default или hot_disk_1.

    • <physical_path_id> — идентификатор физического пути, определенный на предыдущем шаге, например: sda0 или vg0.

      Пример файла конфигурации физических путей
      [
    { "name": "default", "physicalPath": "sda0" },
    { "name": "hot_disk_1", "physicalPath": "vg0" },
    { "name": "cold_disk_1", "physicalPath": "vg0" }
]

  4. Укажите путь к созданному конфигурационному файлу в качестве значения переменной STREAMS_CLICKHOUSE_DISKS_CONFIG в файле конфигурации с переменными окружения для установщика системы.

При установке ClickHouse в кластере Kubernetes автоматически создаются диски default, cold_disk_1 и hot_disk_1.

Расположение дисков ClickHouse на узлах кластера Kubernetes зависит от способа организации хранилища в кластере. Например, если в кластере установлен провайдер хранилища local-path-provisioner, с высокой вероятностью все диски ClickHouse будут использовать общее дисковое пространство, однако это следует подтвердить, обратившись к администратору инфраструктуры кластера.

Определив расположение дисков, вы можете создать конфигурационный файл следующим образом:

  1. Сопоставьте каждому дисковому пространству идентификатор его физического пути — произвольный краткий идентификатор, содержащий латинские буквы, цифры и символы подчеркивания.

    Например, можно использовать такие идентификаторы, как sda0 и vg0.

    Использование косой черты (/) и обратной косой черты (\) не допускается, поскольку может привести к некорректному распознаванию идентификаторов.

  2. Создайте файл в формате JSON, содержащий массив объектов дисков Clickhouse и их идентификаторов физического пути. Каждый из объектов должен иметь следующий формат:

    { "name": "<disk_name>", "physicalPath": "<physical_path_id>" }

    Здесь:

    • <disk_name> — имя диска ClickHouse, например: default или hot_disk_1.

    • <physical_path_id> — идентификатор физического пути, определенный на предыдущем шаге, например: sda0 или vg0.

      Пример файла конфигурации физических путей
      [
    { "name": "default", "physicalPath": "sda0" },
    { "name": "hot_disk_1", "physicalPath": "vg0" },
    { "name": "cold_disk_1", "physicalPath": "vg0" }
]

  3. Укажите путь к созданному конфигурационному файлу в качестве значения переменной STREAMS_CLICKHOUSE_DISKS_CONFIG в файле конфигурации с переменными окружения для установщика системы.

Загрузка пакетов экспертизы

Если у вас имеются пакеты элементов экспертизы с расширением .roc, загрузите их в каталог, где находится установщик. Вы сможете указать их:

Эти пакеты экспертизы будут импортированы в систему по завершении установки.

Получение дистрибутива

Скачайте архив с установочными файлами evo.platform_<version>.run и проверьте его контрольную сумму. Ссылка на дистрибутив предоставляется по запросу в службу поддержки по адресу support@rvision.ru.

# Получение дистрибутива.
curl -O https://files.rvision.ru/platform/<random_part>/evo.platform_<version>.run

# Получение контрольной суммы.
curl -O https://files.rvision.ru/platform/<random_part>/evo.platform_<version>.run.sha256

# Проверка контрольной суммы.
sha256sum -c evo.platform_<version>.run.sha256

# При успешной проверке контрольной суммы будет выведено следующее сообщение.
evo.platform_<version>.run: OK

# При нарушении контрольной суммы будет выведено следующее сообщение.
evo.platform_<version>.run: FAILED

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

Необходимо убедиться, что скачивание run-файла дистрибутива было полностью завершено, и повторно проверить контрольную сумму.

При подтверждении нарушения контрольной суммы следует сообщить в техническую поддержку по адресу support@rvision.ru.

Создание дополнительных объектов StorageClass для local-path-provisioner

Если до начала установки системы в кластере не будет установлен провайдер хранилища (storage provider), то вместе с системой устанавливается провайдер local-path-provisioner. Он не поддерживает ограничение размера постоянных томов (Persistent Volumes), что может привести к неработоспособности узлов кластера в случае их переполнения.

Если вы будете использовать провайдер local-path-provisioner, то перед установкой системы рекомендуется создать дополнительные объекты StorageClass для ее компонентов. Для этого выполните следующие действия:

  1. Создайте логические диски для хранения данных компонентов. На каждом диске необходимо выделять объем дискового пространства не меньше, чем указано в столбце Минимальное свободное пространство, ГБ таблицы.

    Вы можете создать логические диски не для всех, а только для некоторых компонентов, однако в таком случае не исключается взаимное влияние на производительность компонентов, данные которых хранятся на одном и том же диске.
    В таблице приведен минимальный допустимый объем свободного пространства. Для точной оценки необходимого объема для вашей инсталляции обратитесь в службу поддержки по адресу support@rvision.ru.
    Компонент кластера Минимальное свободное пространство, ГБ

    ClickHouse

    30

    PostgreSQL

    8

    NATS Main

    60

    NATS Space

    30

    Prometheus

    15

    Loki

    30

    Остальные компоненты

    20

  2. Запустите установщик в режиме распаковки, выполнив следующую команду:

    ACTION_MODE=unpack ./evo.platform_<version>.run

    В результате распаковки чарт провайдера local-path-provisioner будет находиться в каталоге /opt/r-vision/infra/helm/local-path-provisioner.

  3. Установите чарт с настройками по умолчанию, выполнив следующую команду:

    /opt/r-vision/common/bin/helm upgrade -i local-path-provisioner /opt/r-vision/infra/helm/local-path-provisioner \
  --namespace local-path-provisioner \
  --create-namespace

    После установки в кластере будет доступен только один объект StorageClass типа cluster.local/local-path-provisioner.

  4. Чтобы добавить конфигурации для объектов StorageClass всех компонентов кластера, создайте файл патча. Для этого выполните команду ниже, отредактировав файл под параметры вашей инсталляции.

    В примере ниже приведен файл патча только для ClickHouse (local-path-clickhouse) и условного быстрого StorageClass (local-path-fast). Для остальных компонентов кластера, данные которых требуется хранить в томах отдельных объектов StorageClass, вам необходимо дополнить файл самостоятельно в соответствии с параметрами вашей инсталляции. 
    cat << EOF > patch.yaml
data:
  config.json: |
   {
      "storageClassConfigs": {
        "local-path": {
          "nodePathMap": [
            {
              "node": "DEFAULT_PATH_FOR_NON_LISTED_NODES",
              "paths": ["/opt/local-path-provisioner"]
            }
          ]
        },
        "local-path-clickhouse": {
          "nodePathMap": [
            {
              "node": "DEFAULT_PATH_FOR_NON_LISTED_NODES",
              "paths": ["/data/clickhouse"]
            }
          ]
        },
        "local-path-fast": {
          "nodePathMap": [
            {
              "node": "test-worker01.k8s.dev.rvision.local",
              "paths": ["/data/fast"]
            },
            {
              "node": "test-worker02.k8s.dev.rvision.local",
              "paths": ["/data/fast"]
            }
          ]
        }
      }
    }
EOF

  5. Примените патч, выполнив следующую команду:

    kubectl patch configmap local-path-config -n local-path-provisioner --patch-file patch.yaml

  6. Создайте объекты StorageClass, выполнив следующую команду для каждого из них:

    cat << EOF | kubectl apply -f -
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: <storage_class_name>
provisioner: cluster.local/local-path-provisioner
volumeBindingMode: WaitForFirstConsumer
reclaimPolicy: Delete
EOF

    Здесь:

    • <storage_class_name> — имя объекта StorageClass, например, local-path-clickhouse.

Вы можете вывести список созданных объектов StorageClass, выполнив следующую команду:

kubectl get sc

Была ли полезна эта страница?

+7 (499) 755 55 70 sales@rvision.ru

О компании Пользовательское соглашение Политика cookies

Обратная связь