Развёртывание кластеров VictoriaMetrics и VictoriaLogs

В этой инструкции рассматривается развёртывание отказоустойчивых кластеров VictoriaMetrics и VictoriaLogs средствами Геном.

Подсистема мониторинга может использовать для хранения метрик внешние серверы VictoriaMetrics и VictoriaLogs. Если вы планируете использовать это решение, разверните подсистему мониторинга в конфигурации для одного узла, а затем выполните переключение, следуя инструкции Смена сервера VictoriaMetrics.

Для развёртывания обоих кластеров может использоваться одна группа узлов. В этом случае доступ к мастерам выполняется через один и тот же VIP.

Если каждый кластер развёртывается на своей группе узлов, доступ к мастеру каждого кластера выполняется через собственный VIP.

Для управления VIP используется служба keepalived.

В этой инструкции в качестве примера рассматривается развёртывание кластеров на узлах со следующими параметрами:

Таблица 1. Оба кластера на одной группе узлов
IP-адрес	Доменное имя	Описание
`192.168.0.11`	`vl-vm-1.example.com`	Узлы общей группы
`192.168.0.12`	`vl-vm-2.example.com`
`192.168.0.13`	`vl-vm-3.example.com`
`192.168.0.14`	`vl-vm.example.com`	VIP, указывающий на мастеры обоих кластеров

Таблица 2. Каждый кластер на своей группе узлов
IP-адрес	Доменное имя	Описание
`192.168.0.11`	`vl-1.example.com`	Узлы кластера VictoriaLogs
`192.168.0.12`	`vl-2.example.com`
`192.168.0.13`	`vl-3.example.com`
`192.168.0.14`	`vl.example.com`	VIP, указывающий на мастер кластера VictoriaLogs
`192.168.0.15`	`vm-1.example.com`	Узлы кластера VictoriaMetrics
`192.168.0.16`	`vm-2.example.com`
`192.168.0.17`	`vm-3.example.com`
`192.168.0.18`	`vm.example.com`	VIP, указывающий на мастер кластера VictoriaMetrics

Сеть

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

Подготовка к работе

Выберите один из узлов будущего кластера и используйте его в качестве установочного узла. Все описанные далее действия выполняйте на нём.
Загрузите на установочный узел архив ansible-ha-victoria-cluster-37.tar.gz.
Распакуйте загруженный архив:
```
tar xvfz ansible-ha-victoria-cluster-37.tar.gz
```
Запустите скрипт создания виртуального окружения:
```
sh ansible-ha-victoria-cluster-37/venv/activate_venv.sh
```
Активируйте виртуальное окружение:
source /opt/skala-r/vision/server/vision_ansible_venv/bin/activate
Об успешной активации свидетельствует изменившееся приглашение интерпретатора командной строки, например:
(vision_ansible_venv) [root@server ~]#
Далее все команды, связанные с выполнением плейбуков Ansible, выполняйте в активном виртуальном окружении.
Перейдите в директорию с распакованными файлами архива ansible-ha-victoria-cluster-37.tar.gz:
cd ansible-ha-victoria-cluster-37/
Далее имена файлов и директорий указываются относительно этой директории.

Создайте инвентари Ansible.

К описанию каждого узла добавьте поле hostname, в значении которого укажите полное доменное имя узла (FQDN). Плейбук использует его при генерации сертификатов и их ключей.

Если оба кластера развёртываются на одной группе узлов, достаточно одного файла. Далее для него используется имя inventory.yml.

Пример заполнения инвентаря inventory.yml

---
all:
  hosts:
    vl-vm-1.example.com:
      ansible_host: 192.168.0.11
      hostname: vl-vm-1.example.com
    vl-vm-2.example.com:
      ansible_host: 192.168.0.12
      hostname: vl-vm-2.example.com
    vl-vm-3.example.com:
      ansible_host: 192.168.0.13
      hostname: vl-vm-3.example.com
  vars:
    cluster_vip: 192.168.0.14
    ansible_user: "<user>"
    ansible_ssh_pass: "<password>"
    ansible_become_user: "<become_user>"
    ansible_become_pass: "<become_password>"

Если каждый кластер развёртывается на своей группе узлов, создайте два файла. Далее для них используются имена inventory-vmetrics.yml и inventory-vlogs.yml соответственно.

Пример заполнения инвентаря inventory-vlogs.yml

---
all:
  hosts:
    vl-1.example.com:
      ansible_host: 192.168.0.11
      hostname: vl-1.example.com
    vl-2.example.com:
      ansible_host: 192.168.0.12
      hostname: vl-2.example.com
    vl-3.example.com:
      ansible_host: 192.168.0.13
      hostname: vl-3.example.com
  vars:
    cluster_vip: 192.168.0.14
    ansible_user: "<user>"
    ansible_ssh_pass: "<password>"
    ansible_become_user: "<become_user>"
    ansible_become_pass: "<become_password>"

Пример заполнения инвентаря inventory-vmetrics.yml

---
all:
  hosts:
    vm-1.example.com:
      ansible_host: 192.168.0.15
      hostname: vm-1.example.com
    vm-2.example.com:
      ansible_host: 192.168.0.16
      hostname: vm-2.example.com
    vm-3.example.com:
      ansible_host: 192.168.0.17
      hostname: vm-3.example.com
  vars:
    cluster_vip: 192.168.0.18
    ansible_user: "<user>"
    ansible_ssh_pass: "<password>"
    ansible_become_user: "<become_user>"
    ansible_become_pass: "<become_password>"

Развёртывание VictoriaLogs и VictoriaMetrics

Для развёртывания кластеров VictoriaLogs и VictoriaMetrics используйте плейбуки playbooks/cluster-vl/deploy.yml и playbooks/cluster-vm/deploy.yml соответственно.

В команде запуска укажите путь к файлу нужного инвентаря:

Развёртывание на одной группе узлов:

ansible-playbook -i inventory.yml playbooks/cluster-vl/deploy.yml
ansible-playbook -i inventory.yml playbooks/cluster-vm/deploy.yml

.Развёртывание на разных группах узлов:

ansible-playbook -i inventory-vlogs.yml    playbooks/cluster-vl/deploy.yml
ansible-playbook -i inventory-vmetrics.yml playbooks/cluster-vm/deploy.yml

keepalived

keepalived отслеживает состояние мастеров VictoriaMetrics и VictoriaLogs. Если мастер выходит из строя, keepalived перемещает Virtual IP на новый мастер.

Параметры развёртывания keepalived зависят от того, развёртываются VictoriaMetrics и VictoriaLogs на одной группе узлов или на разных.

Одна группа узлов

Если оба кластера развёртываются на одной группе узлов:

Файл playbooks/cluster-vip/group_vars/all/keepalived.yml заполните следующим образом:

---
keepalived_virtual_router_id: 50
keepalived_virtual_status_command: "/bin/bash -c '/sbin/systemctl is-active --quiet vmauth.service && /sbin/systemctl is-active --quiet vlauth.service

Запустите развёртывание, указав путь к файлу общего инвентаря:
```
ansible-playbook \
   -i inventory.yml \
   playbooks/cluster-vip/deploy.yml
```

Разные группы узлов

Если VictoriaMetrics и VictoriaLogs развёртываются на разных группах узлов:

Файл playbooks/cluster-vip/group_vars/all/keepalived.yml заполните следующим образом:

---
keepalived_virtual_router_id: 50
keepalived_virtual_status_command: "/bin/bash -c '/sbin/systemctl is-active --quiet vlauth.service'"

Запустите развёртывание keepalived на узлах кластера VictoriaLogs:
```
ansible-playbook \
   -i inventory-vlogs.yml \
   playbooks/cluster-vip/deploy.yml
```

Измените содержимое файла playbooks/cluster-vip/group_vars/all/keepalived.yml:

---
keepalived_virtual_router_id: 100
keepalived_virtual_status_command: "/bin/bash -c '/sbin/systemctl is-active --quiet vmauth.service'"

Запустите развёртывание keepalived на узлах кластера VictoriaMetrics:
```
ansible-playbook \
   -i inventory-vmetrics.yml \
   playbooks/cluster-vip/deploy.yml
```
Деактивируйте виртуальное окружение:
```
deactivate
```

Секреты

В результате выполнения плейбуков в директории playbooks/tmp/secrets/ формируются файлы корневых сертификатов, сертификатов и их ключей, а также файлы с паролями.

Сохраните файлы из директории playbooks/tmp/secrets/ в надёжном месте!

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

CAVictoriaExternal.crt — корневой сертификат для внешних подключений к серверу.
<vip>_external_client.crt — сертификат для внешних подключений к серверу.
<vip>_external_client.key — ключ сертификата для внешних подключений к серверу.
<vip>_global_basic_auth_password — пароль BasicAuth для внутренних подключений между компонентами кластера.
<vip>_keepalived_auth_password — пароль keepalived, используемый для авторизации между узлами.
<vip>_vmauth_external_user_password — пароль для внешних подключений vision_core и других компонентов подсистемы мониторинга к vlauth и vmauth.
<hostname>_vmauth_server.crt — сертификаты для серверов vlauth и vmauth, обрабатывающих внешние подключения.
<hostname>_vmauth_server.key — ключи сертификатов для серверов vlauth и vmauth, обрабатывающих внешние подключения.
CAVictoriaInternal.crt — корневой сертификат для внутренних подключений между компонентами кластера.
<hostname>_vmauth_client.crt — сертификаты для подключения vlauth и vmauth в качестве клиентов.
<hostname>_vmauth_client.key — ключи сертификатов для подключения vlauth и vmauth в качестве клиентов.
<hostname>_vinsert.crt — сертификаты для подключения vlinsert в качестве клиента.
<hostname>_vinsert.key — ключи сертификатов для подключения vlinsert в качестве клиента.
<hostname>_vselect.crt — сертификаты для подключения vselect в качестве клиента.
<hostname>_vselect.key — ключи сертификатов для подключения vselect в качестве клиента.
<hostname>_vstorage.crt — сертификаты для подключения vstorage в качестве клиента.
<hostname>_vstorage.key — ключи сертификатов для подключения vstorage в качестве клиента.

Проверка корректности

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

<vip> — VIP, указанный в файле inventory.yml в значении параметра all.vars.cluster_vip.
<user> — имя пользователя vlauth или vmauth. По умолчанию в VictoriaLogs и VictoriaMetrics создаётся пользователь vision.
<password> — пароль для доступа к vlauth или vmauth. Используйте значение из файла playbooks/tmp/secrets/<vip>_vmauth_external_user_password.
<port> — порт для подключения:
- 8427 — VictoriaMetrics.
- 9427 — VictoriaLogs.

Статусы служб и журналы работы

Убедитесь, что на узлах кластера корректно работают все необходимые службы, а журналы не содержат сообщений об ошибках:

Проверьте статусы служб VictoriaMetrics и VictoriaLogs:

Таблица 3. Названия служб VictoriaLogs и VictoriaMetrics
VictoriaLogs	VictoriaMetrics
`vlauth.service`	`vmauth.service`
`vlinsert.service`	`vminsert.service`
`vlselect.service`	`vmselect.service`
`vlstorage.service`	`vmstorage.service`

Проверьте статус службы keepalived.service на всех узлах.
Чтобы убедиться в отсутствии ошибок в журналах работы компонентов кластера, следуйте соответствующей инструкции:
- Смена сервера VictoriaLogs.
- Смена сервера VictoriaMetrics.

Состояние хранилища

Проверьте статус хранилищ:

VictoriaMetrics:
Пример запроса
curl -v \ --cacert playbooks/tmp/secrets/CAVictoriaExternal.crt \ -u <user>:<password> \ "https://<vip>:8427/-/healthy"
Ответ должен обладать следующими свойствами:
- HTTP Status Code: 200 OK.
- Body: VictoriaMetrics is Healthy.
VictoriaLogs:
Пример запроса
curl -v \ --cacert playbooks/tmp/secrets/CAVictoriaExternal.crt \ -u <user>:<password> \ "https://<vip>:9427/-/healthy"
Ответ должен обладать следующими свойствами:
- HTTP Status Code: 200 OK.
- Body: VictoriaLogs is Healthy.

Запись лога в vlinsert через vlauth

Запрос:

curl -v -X POST \
  -H "Content-Type: application/stream+json" \
  --cacert playbooks/tmp/secrets/CAVictoriaExternal.crt \
  -u <user>:<password> \
  --data-binary @- \
 "https://<vip>:9427/insert/jsonline?_stream_fields=app_name&_time_field=date&_msg_field=log.message" <<EOF
{ "log": { "level": "info", "message": "hello world" }, "date": "0", "app_name": "test" }
{ "log": { "level": "error", "message": "oh no!" }, "date": "0", "app_name": "test" }
EOF

Ответ должен обладать следующими свойствами:

HTTP Status Code: 200 OK.
Body: отсутствует.

Запись метрики в vminsert через vmauth

Запрос:

curl -v \
  --cacert playbooks/tmp/secrets/CAVictoriaExternal.crt \
  -u <user>:<password> \
  --data-binary 'up{test="vminsert_curl"} 1' \
  "https://<vip>:8427/api/v1/import/prometheus"

Ответ должен обладать следующими свойствами:

HTTP Status Code: 204 No Content.
Body: отсутствует.

Чтение лога из vlselect через vlauth

Запрос:

curl -v \
  --cacert playbooks/tmp/secrets/CAVictoriaExternal.crt \
  -u <user>:<password> \
  "https://<vip>:9427/select/logsql/query?query=*"

Ответ должен обладать следующими свойствами:

HTTP Status Code: 200 OK.
Body: отсутствует или содержит корректный JSON с данными.

Чтение метрик из vmselect через vmauth

Запрос:

curl -v \
  --cacert <ca_cert> \
  -u <user>:<password> \
  "https://<vip>:8427/api/v1/query?query=up"

Ответ должен обладать следующими свойствами:

HTTP Status Code: 200 OK.
Body: содержит поле status со значением success.

Доступ к интерфейсу VMUI через браузер

vlauth и vmauth проксируют доступ к интерфейсу VMUI с помощью запросов, которые обрабатывают компоненты vlselect и vmselect соответственно. Для проверки работоспособности перейдите по ссылкам:

```
https://<vip>:8427/vmui
```
```
https://<vip>:9427/vmui
```

В обоих случаях для авторизации используйте имя пользователя vision и пароль, указанный в файле `playbooks/tmp/secrets/<vip>_vmauth_external_user_password.

Успешная авторизация в веб-интерфейсе кластеров и отсутствие сообщений об ошибках свидетельствуют о корректной работе сервисов.

Перемещение VIP

Перемещение VIP позволяет убедиться в корректности работы службы keepalived.

Перемещение при остановке keepalived

Найдите узел с VIP:
```
ip -br a
```
Подключитесь к узлу с VIP и остановите службу keepalived:
```
systemctl stop keepalived.service
```
Убедитесь, что VIP переместился на другой узел.
Повторяйте шаги 1—3 до тех пор, пока VIP не будет перемещён на нужный узел.
Запустите службу keepalived на всех узлах кластера:
```
systemctl start keepalived.service
```

Перемещение при остановке vlauth

Найдите узел с VIP:
```
ip -br a
```
Подключитесь к узлу с VIP и остановите службу vlauth:
```
systemctl stop vlauth.service
```
Убедитесь, что VIP переместился на другой узел.
Повторяйте шаги 1—3 до тех пор, пока служба vlauth не будет остановлена на всех узлах.
Найдите узел без VIP:
```
ip -br a
```
Запустите службу vlauth:
```
systemctl start vlauth.service
```
Убедитесь, что VIP перемещён на узел с работающей службой vlauth.

На перемещение VIP может потребоваться несколько секунд.
Запустите службу vlauth на всех остальных узлах кластера.

Перемещение при остановке vmauth

Найдите узел с VIP:
```
ip -br a
```
Подключитесь к узлу с VIP и остановите службу vmauth:
```
systemctl stop vmauth.service
```
Убедитесь, что VIP переместился на другой узел.
Повторяйте шаги 1—3 до тех пор, пока служба vmauth не будет остановлена на всех узлах.
Найдите узел без VIP:
```
ip -br a
```
Запустите службу vmauth:
```
systemctl start vmauth.service
```
Убедитесь, что VIP перемещён на узел с работающей службой vmauth.

На перемещение VIP может потребоваться несколько секунд.
Запустите службу vmauth на всех остальных узлах кластера.