Перейти до основного вмісту

Налаштування та запуск кластера

інформація

💰 Функція доступна за підпискою Yucca Enterprise

Вступ

У цьому посібнику описано, як налаштувати кластер Yucca з 3 вузлів. Знадобиться встановлена Yucca та Postgres, оскільки в режимі кластера можлива робота лише з цією БД. А також ліцензія на потрібну кількість вузлів.

Запуск

Для запуску Yucca в режимі кластера потрібно увімкнути сам режим і позначити адреси, за якими сервери спілкуватимуться один з одним. Нам знадобиться визначити наступні параметри:

  • --cluster=true - Вмикає режим кластера.
  • --cluster-advertise-address=127.0.0.1:9941 - вказує, за якою адресою учасники кластера можуть звертатися до цього сервера.
  • --cluster-listen-address=:9941 - який порт потрібно слухати для звернень учасників кластера.
примітка

Параметри також можна визначити як через конфігураційний файл, так і через змінні оточення

Для прикладу я запущу все локально на 1 комп'ютері, у робочому середовищі передбачається, що це різні фізичні сервери. Зазначу, що при роботі на 1 вузлі у серверів обов'язково має відрізнятися state_dir, у цьому каталозі створиться файл cluster_node_id, який міститиме унікальний ідентифікатор сервера в кластері. Не видаляйте і не змінюйте цей файл. За цим номером сервер ідентифікує себе в кластері, якщо його видалити, сервер спробує додатися до кластера як новий вузол, і всі раніше налаштовані камери буде проігноровано. У разі перенесення вузла кластера на інше обладнання обов'язково перенесіть і цей файл.

Запустимо перший вузол Yucca в кластері:

/opt/yucca/yucca server \
--data-dir=/opt/yucca/data/cluster/data1 \
--database-type="postgres" \
--telemetry=false \
--smtp-server=false \
--cluster=true \
--cluster-advertise-address=127.0.0.1:9941 \
--cluster-listen-address=0.0.0.0:9941 \
--log-level=debug \
--web.listen-address=0.0.0.0:9911

Другий інстанс Yucca в кластері:

/opt/yucca/yucca server \
--data-dir=/opt/yucca/data/cluster/data2 \
--database-type="postgres" \
--telemetry=false \
--smtp-server=false \
--cluster=true \
--cluster-advertise-address=127.0.0.1:9942 \
--cluster-listen-address=0.0.0.0:9942 \
--log-level=debug \
--web.listen-address=0.0.0.0:9912

Третій інстанс Yucca в кластері:

/opt/yucca/yucca server \
--data-dir=/opt/yucca/data/cluster/data3 \
--database-type="postgres" \
--telemetry=false \
--smtp-server=false \
--cluster=true \
--cluster-advertise-address=127.0.0.1:9943 \
--cluster-listen-address=0.0.0.0:9943 \
--log-level=debug \
--web.listen-address=0.0.0.0:9913

Далі відкриваємо інтерфейс усіх 3 серверів. Ми побачимо сторінку ініціалізації бази на одному з серверів, тому, який зміг стати лідером. Лідер – це особлива роль сервера в кластері, він відповідає за безліч операцій і статуси в кластері, хоча при цьому є таким самим учасником, теж розміщує камери тощо. Якщо поточний лідер раптом стане недоступний, його місце негайно займе хтось інший. Так у кластері завжди є лідер. Усі інші вузли є учасниками або претендентами і чекають, коли лідер дозволить їм вступити в кластер.

init1

Після ініціалізації додаємо ліцензію:

примітка

Зверніть увагу, що я вказав ліцензію з кластером на 2 вузли, при цьому запустив 3 вузли

license1

Лідер також стежить за квотами. Якщо у вас за ліцензією квота на 2 вузли в кластері, і ви спробуєте додати 3-й, новий вузол перебуватиме в статусі претендента на вступ до кластера, але не зможе вступити до нього.

cluster1

Лідер перевіряє квоти не тільки на старті, а й у процесі роботи. Наприклад, якщо ви застосуєте ліцензію з квотою на 10 вузлів, все налаштуєте, а потім застосуєте ліцензію з квотою на 3 вузли, то, побачивши це, лідер зіллє (виведе з обслуговування) зайві вузли. Вибір зайвих вузлів відбувається випадковим чином.