Доступность, совместимость и пределы

Opfield разделяет доступность управления и доступность самих сервисов. При отказе контура управления нельзя выполнять и авторизовать новые изменения, но уже применённая на хостах инфраструктура не должна останавливаться.

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

Что продолжает работать при отказе

Отказ	Что обычно продолжает работать	Что недоступно или не гарантируется
Приложение Opfield недоступно, Relay работает	nginx обслуживает применённую конфигурацию; Containers и базы данных продолжают работать; Relay продолжают допускать новые соединения Secure Links и ссылок баз данных по последней подписанной политике в течение срока её аренды (по умолчанию 72 часа); политики Availability в режиме аренды продолжают переключать нагрузку; публичная страница состояния отдаётся из кэша ноды Ingress	UI, API, изменения желаемого состояния, новые и изменённые Routes и ссылки, отзыв маршрутов, новые управляемые операции и переключение Availability силами Opfield
Хост Opfield недоступен, локальный Relay расположен там же	публичные Routes и рабочие нагрузки, не зависящие от Relay, продолжают работать на своих хостах; ссылки, которые используют и Relay на другом хосте, продолжают работать через него, и Availability в режиме аренды переключает нагрузку через такие Relay	локальный Relay также недоступен; управление нодами теряется, а ссылки, которые обслуживает только локальный Relay, обрываются
Недоступен один внешний Relay	рабочие нагрузки продолжают работать; другие готовые участники помогают только там, где это предусмотрено размещением и назначениями	сеансы, назначенные только отказавшему участнику, могут переподключиться или завершиться; до восстановления и перераспределения доступная ёмкость ниже
Нет доступного Relay	локальные рабочие нагрузки и напрямую обслуживаемый публичный трафик могут продолжать работать	управление нодами и новые приватные связи не работают; сохранение существующих потоков через Relay не гарантируется
Недоступна одна управляемая нода	ресурсы на остальных нодах продолжают работать; политика Availability в режиме аренды переносит слоты ноды на других кандидатов примерно за 45 секунд — с Opfield или без него	ресурсы отказавшей ноды недоступны или показывают устаревшее состояние; Opfield не должен изменять их по старому снимку; при переключении силами Opfield для замены нужен работающий Opfield
Обычное истечение ключа, переход на более низкий тариф, отзыв или деактивация	в течение льготного периода (для отзыва, переноса и деактивации его нет) — всё; после него — существующие рабочие нагрузки, контур данных, данные, резервное копирование по расписанию, а также просмотр, мониторинг и удаление существующих платных ресурсов	создание платных ресурсов и изменение их конфигурации; пересылка в SIEM и токены внешнего доступа к реестру приостанавливаются до продления; см. Понижение и истечение
Служба лицензирования недоступна	Opfield, рабочие нагрузки и платные функции продолжают работать; ранее подтверждённый платный ключ остаётся действительным 100 дней после последнего подписанного состояния лицензии	активация ключа и обновление установки, у которой есть или был платный тариф (установка Community без ключа обновляется); через 100 дней — правила обычного истечения после льготного периода
Действительный платный ключ, но коммерческое ядро отсутствует или отклонено	существующая инфраструктура и функции Community продолжают работать	платные функции отображаются как неготовые, пока не выполнится Enable paid features

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

Доступность рабочих нагрузок

Workload Availability (HA) доступна на Business и Enterprise. Она поддерживает 2–32 реплики или один обслуживающий экземпляр с заменой для Containers, Deployments и целых Compose Projects без монтирований. Когда каждый Docker-узел, узел Ingress и Relay нагрузки работает на релизе с переключением на уровне данных, узлы сами заменяют потерянного держателя, даже пока Opfield недоступен, а отрезанный узел сам останавливает свою копию. Иначе нужное число размещений на подходящих доступных узлах восстанавливает Opfield, и для этого нужен исправный контур управления. В обоих случаях нужны свободная ёмкость, артефакты и зависимости; ни один из способов не обеспечивает HA самого Opfield, nginx, баз данных или хранилищ.

Риск локального Relay

В каждой установке есть локальный Relay. Если Opfield и Relay находятся на одном хосте, потеря этого хоста одновременно убирает управление и транспорт для Secure Links и сеансов управляемых нод.

Если приватные подключения должны переживать потерю хоста Opfield, добавьте внешние Relay в независимых зонах отказа и проверьте доступ к ним со всех нужных нод. Тогда Opfield размещает каждую Secure Link хотя бы на одном Relay вне хоста Opfield, доступном её нодам, а Settings → Relay предупреждает о ссылках, которые зависят от хоста Opfield, потому что их ноды не могут достучаться ни до одного другого Relay. Второй контейнер Relay на том же сервере, firewall, источнике питания или сетевом пути не повышает отказоустойчивость.

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

Совместимость версий

Рассматривайте Opfield, Relay, управляемые демоны и версии их протоколов как единый проверенный комплект релиза.

• Используйте версии, опубликованные вместе в метаданных релиза и поддерживаемом установщике.
• Обновляйте участников Relay Pool по одной зоне отказа.
• Сначала обновите показательные ноды и проверьте свежие возможности, инвентарь и реальную операцию.
• Не считайте произвольные старые и новые демоны совместимыми только потому, что они установили TCP-соединение.
• Храните прежние одобренные образы и соответствующую резервную копию до окончания наблюдения.
• Не откатывайтесь через миграцию базы данных без явной поддержки в заметках к релизу и согласованной точки восстановления.

Переключению на уровне данных нужен один и тот же релиз у всех участников нагрузки: политика переходит в него, только когда все они проработали на нём 2 минуты, и выходит из него, если нода Ingress или Relay остаётся устаревшей 2 минуты. См. Обновления и разные версии.

Сейчас Opfield не публикует универсальную долгосрочную матрицу всех исторических комбинаций компонентов. Если вам нужен длительный период смешанных версий, проверьте конкретную комбинацию во время пилота и зафиксируйте её как ограничение своей установки.

Нагрузка и проверенные пределы

Единого полезного максимума для нод, Routes, рабочих нагрузок, сборок, баз данных или одновременных приватных потоков нет. Ёмкость зависит от ресурсов хоста, частоты операций, срока хранения данных, размера полезной нагрузки, размещения Relay, сборок и внешних провайдеров.

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

• задержку API Opfield и фоновых очередей;
• соединения PostgreSQL, задержку, рост хранилища и время резервного копирования;
• память Redis и состояние очередей;
• соединения, память, пропускную способность, переподключение и распределение Relay;
• объём и свежесть отчётов нод;
• параллельность сборок, размеры артефактов и давление на диск;
• рост логов, аудита, метрик и артефактов Pages;
• время восстановления после перезапуска каждого общего компонента.

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

Решение о рабочей эксплуатации

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