#Підготовка

Перед розгортанням кластерного застосунку необхідно виконати наступні підготовчі кроки.

#Ліцензія на комерційні плагіни

Для роботи застосунку NocoBase у кластерному режимі потрібна підтримка наступних плагінів:

Перш за все, переконайтеся, що ви отримали ліцензії на вищезазначені плагіни (ви можете придбати відповідні ліцензії через платформу комерційних плагінів).

#Системні компоненти

Інші системні компоненти, окрім самого екземпляра застосунку, можуть бути обрані персоналом з експлуатації відповідно до потреб команди.

#База даних

Оскільки поточний кластерний режим орієнтований лише на екземпляри застосунків, база даних тимчасово підтримує лише один вузол. Якщо у вас є архітектура бази даних типу master-slave, вам потрібно реалізувати її самостійно за допомогою проміжного програмного забезпечення та забезпечити її прозорість для застосунку NocoBase.

#Проміжне програмне забезпечення

Кластерний режим NocoBase покладається на певне проміжне програмне забезпечення для забезпечення зв'язку та координації між кластерами, включаючи:

• Кеш: Використовує розподілене кешування на основі Redis для підвищення швидкості доступу до даних.
• Синхронні сигнали: Використовує функцію Redis stream для передачі синхронних сигналів між кластерами.
• Черга повідомлень: Використовує чергу повідомлень на основі Redis або RabbitMQ для асинхронної обробки повідомлень.
• Розподілене блокування: Використовує розподілене блокування на основі Redis для забезпечення безпечного доступу до спільних ресурсів у кластері.

Коли всі компоненти проміжного програмного забезпечення використовують Redis, ви можете запустити єдиний сервіс Redis у внутрішній мережі кластера (або Kubernetes). Також можна увімкнути окремий сервіс Redis для кожної функції (кеш, синхронні сигнали, черга повідомлень та розподілене блокування).

Рекомендації щодо версій

• Redis: >=8.0 або версія redis-stack, що включає функцію Bloom Filter.
• RabbitMQ: >=4.0

#Спільне сховище

NocoBase використовує каталог storage для зберігання системних файлів. У багатонодовому режимі слід монтувати хмарний диск (або NFS) для підтримки спільного доступу між кількома вузлами. В іншому випадку локальне сховище не буде автоматично синхронізуватися, і система не зможе працювати належним чином.

При розгортанні за допомогою Kubernetes зверніться до розділу Розгортання Kubernetes: Спільне сховище.

#Балансування навантаження

Кластерний режим вимагає балансувальника навантаження для розподілу запитів, а також для перевірки стану та відмовостійкості екземплярів застосунків. Цю частину слід обирати та налаштовувати відповідно до операційних потреб команди.

Наприклад, для самостійно налаштованого Nginx додайте наступний вміст до файлу конфігурації:

upstream myapp {
    # ip_hash; # Може використовуватися для підтримки сесії. Якщо увімкнуто, запити від одного клієнта завжди надсилаються на той самий бекенд-сервер.
    server 172.31.0.1:13000; # Внутрішній вузол 1
    server 172.31.0.2:13000; # Внутрішній вузол 2
    server 172.31.0.3:13000; # Внутрішній вузол 3
}

server {
    listen 80;

    location / {
        # Використовуйте визначений upstream для балансування навантаження
        proxy_pass http://myapp;
        # ... інші конфігурації
    }
}

Це означає, що запити проксуються та розподіляються на різні серверні вузли для обробки.

Щодо проміжного програмного забезпечення для балансування навантаження, що надається іншими постачальниками хмарних послуг, зверніться до документації з конфігурації, наданої відповідним постачальником.

#Налаштування змінних середовища

Усі вузли в кластері повинні використовувати однакову конфігурацію змінних середовища. Окрім базових змінних середовища NocoBase, необхідно також налаштувати наступні змінні середовища, пов'язані з проміжним програмним забезпеченням.

#Багатоядерний режим

Коли застосунок працює на багатоядерному вузлі, ви можете увімкнути багатоядерний режим вузла:

# Увімкнути багатоядерний режим PM2
# CLUSTER_MODE=max # За замовчуванням вимкнено, потребує ручного налаштування

Якщо ви розгортаєте поди застосунків у Kubernetes, ви можете ігнорувати цю конфігурацію та контролювати кількість екземплярів застосунків за допомогою кількості реплік подів.

#Кеш

# Адаптер кешу, у кластерному режимі має бути встановлений на redis (за замовчуванням – в пам'яті)
CACHE_DEFAULT_STORE=redis

# URL-адреса підключення адаптера кешу Redis, потребує заповнення
CACHE_REDIS_URL=

#Синхронні сигнали

# URL-адреса підключення адаптера синхронізації Redis, за замовчуванням – redis://localhost:6379/0, якщо не вказано
PUBSUB_ADAPTER_REDIS_URL=

#Розподілене блокування

# Адаптер блокування, у кластерному режимі має бути встановлений на redis (за замовчуванням – локальне блокування в пам'яті)
LOCK_ADAPTER_DEFAULT=redis

# URL-адреса підключення адаптера блокування Redis, за замовчуванням – redis://localhost:6379/0, якщо не вказано
LOCK_ADAPTER_REDIS_URL=

#Черга повідомлень

# Увімкнути Redis як адаптер черги повідомлень, за замовчуванням – адаптер в пам'яті, якщо не вказано
QUEUE_ADAPTER=redis
# URL-адреса підключення адаптера черги повідомлень Redis, за замовчуванням – redis://localhost:6379/0, якщо не вказано
QUEUE_ADAPTER_REDIS_URL=

#Розподільник Worker ID

Деякі системні колекції в NocoBase використовують глобально унікальні ідентифікатори як первинні ключі. Щоб запобігти конфліктам первинних ключів у кластері, кожен екземпляр застосунку повинен отримати унікальний Worker ID через Розподільник Worker ID. Поточний діапазон Worker ID становить 0–31, що означає, що кожен застосунок може одночасно працювати до 32 вузлів. Детальніше про дизайн глобального унікального ID дивіться тут: @nocobase/snowflake-id

# URL-адреса підключення Redis для Розподільника Worker ID.
# Якщо не вказано, буде призначено випадковий Worker ID.
REDIS_URL=

CACHE_REDIS_URL=redis://localhost:6379/0
PUBSUB_ADAPTER_REDIS_URL=redis://localhost:6379/1
LOCK_ADAPTER_REDIS_URL=redis://localhost:6379/2
QUEUE_ADAPTER_REDIS_URL=redis://localhost:6379/3
REDIS_URL=redis://localhost:6379/4

Якщо ви використовуєте Kubernetes для керування кластером, ви можете налаштувати вищезгадані змінні середовища в ConfigMap або Secret. Додаткову інформацію можна знайти в розділі Розгортання Kubernetes.

Після завершення всіх вищезазначених підготовчих робіт ви можете перейти до Експлуатації, щоб продовжити керування екземплярами застосунків.