Высокая доступность с узлами приложения

Как это работает

Высокая доступность позволяет запускать продакшн одной базы Odoo сразу на нескольких серверах. Если один сервер перестаёт отвечать, посетители направляются на остальные.

Кластер состоит из проектов с одинаковым кодом:

• Основной проект: проект, продакшн-инстанс которого запускает Odoo и базу данных. Его база данных открыта для узлов приложения и ни для кого больше.
• Узлы приложения: другие проекты, каждый на своём продакшн-сервере, продакшн-инстанс которых запускает только Odoo и использует базу данных основного проекта.

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

Сама база данных по-прежнему работает на одном сервере, сервере основного проекта. Узлы приложения дают резервирование на стороне Odoo; если сервер основного проекта падает, сайт падает вместе с ним.

Перед началом

• Одинаковый код: все проекты кластера должны использовать один и тот же репозиторий, ветку по умолчанию, версию и редакцию Odoo. Если включена Time Machine, закреплённые коммиты тоже должны совпадать.
• Разные серверы: у каждого узла приложения должен быть свой продакшн-сервер, отличный от сервера основного проекта и от серверов других узлов.
• Прокси Cloudflare: распределение трафика между узлами сейчас работает для серверов, на которых включён прокси Cloudflare. Используйте серверы в одном регионе, так как каждая страница, которую отдаёт узел приложения, обращается к базе данных основного проекта.
• Общий filestore: каждый сервер кластера должен монтировать одно и то же общее хранилище для filestore Odoo. Без него вложение, загруженное через один узел, отсутствует на остальных, а посетитель, попавший на другой узел, разлогинивается. Обратитесь в поддержку, если нужна помощь с настройкой.
• Подключения к базе данных: каждый узел приложения открывает собственные подключения к базе данных основного проекта. По мере добавления узлов увеличивайте max_connections в разделе Конфигурация PostgreSQL продакшн-инстанса основного проекта, на вкладке Настройки его консоли.

Настройки высокой доступности находятся в Настройках проекта, на вкладке Дополнительно, в карточке Высокая доступность. Вам нужно право изменять настройки проекта.

Настройка основного проекта

Откройте проект, который будет работать с базой данных, перейдите в Настройки проекта > Дополнительно и в карточке Высокая доступность установите Роль в значение Основной (приложение + база данных). Нажмите Применить и подтвердите.

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

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

Добавление узла приложения

Создайте проект для узла как обычно: тот же репозиторий и ветка по умолчанию, та же версия и редакция и собственный продакшн-сервер. Удалите все его staging- и dev-инстансы: узел приложения работает только в продакшне, а ветки staging и разработки живут в основном проекте.

Затем откройте Настройки проекта > Дополнительно узла, установите Роль в значение Узел приложения (использует базу основного), выберите основной проект в поле Источник базы данных, нажмите Применить и подтвердите. Предлагаются только основные проекты из того же воркспейса с тем же кодом.

Узел запускается не сразу. Сначала сервер основного проекта должен его допустить, это происходит при следующей проверке, обычно в течение пяти минут. До этого карточка показывает "Ожидаем, пока основной проект разрешит этот узел", а узел запускается сам, как только получит разрешение. Через несколько минут после того, как он начнёт отвечать, на него начинают поступать посетители.

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

Что меняется на узле приложения

• У его продакшн-инстанса нет собственной базы данных. Её настройки управляются CICDoo и не могут быть изменены в конфигурации Odoo инстанса.
• Запланированные задачи (cron в Odoo) выполняются только на основном проекте.
• Резервные копии делаются на основном проекте. Создавайте и восстанавливайте резервные копии базы данных кластера из основного проекта.
• Push в ветку узла приложения сам по себе ничего не делает. Кластер обновляется из основного проекта.

Деплой обновлений

Делайте push в ветку основного проекта как обычно. Затем CICDoo обновляет весь кластер по порядку:

1. Каждый узел приложения останавливается.
2. Обновляется основной проект, включая обновление модулей, пока никакой другой сервер не использует базу данных.
3. Каждый узел приложения запускается снова с новым кодом.

Каждый шаг можно отслеживать на вкладке Очередь инстанса, на котором он выполняется. Если обновление основного проекта не удалось, узлы приложения не запускаются снова, а их записи в очереди объясняют причину. Устраните проблему и выполните деплой ещё раз.

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

Выход из кластера

Чтобы убрать узел приложения, верните его Роль в значение Отдельно (своя база данных) и нажмите Применить. Его продакшн-инстанс останавливается, потому что собственная база данных не содержит данных кластера. Восстановите в неё резервную копию, прежде чем запускать его снова.

Основной проект нельзя изменить, пока у него есть узлы приложения. Сначала уберите узлы.

Устранение неполадок

• Узел всё ждёт разрешения: проверьте, что продакшн-инстанс основного проекта запущен и его сервер в сети. После назначения основным проект должен один раз перезапуститься, прежде чем будет допущен хоть один узел.
• Узел запускается, но Odoo не поднимается: откройте логи узла. Сообщение о том, что база данных основного проекта не инициализирована, означает, что основной проект ещё не завершил первый запуск.
• Загрузки или входы не сохраняются при переходе посетителя между узлами: серверы не используют общий filestore. См. раздел "Перед началом" выше.

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