#Подготовка

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

#Коммерческая лицензия на плагины

Для работы приложения 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 используют глобально уникальные ID в качестве первичных ключей. Чтобы избежать конфликтов первичных ключей в кластере, каждый экземпляр приложения должен получить уникальный 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.

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