Когда регион выходит из строя, возникает вопрос о том, что происходит с незавершенной работой. Реинжиниринг процессов с учетом возможностей ИИ — это задача на ближайшие несколько лет, и предел того, насколько далеко предприятие сможет в этом продвинуться, редко кроется в качестве моделей или поддержке коннекторов. Он зависит от того, насколько вы можете доверять лежащей в основе платформе при отказе региона.
Процессы, которые больше всего заслуживают реинжиниринга, — это обычно те, которые бизнес не может позволить себе остановить даже на полдня: платежи, урегулирование претензий, расчеты по сделкам, выполнение заказов. Перенос их на платформу агентной оркестрации — это решение, касающееся как отказоустойчивости, так и функциональных возможностей.
Camunda 8.10 представляет кластеры с поддержкой зон, восстановление после сбоев СУБД и две проверенные многорегиональные эталонные архитектуры для локальных развертываний. Эти дополнения помогают командам платформ распределять рабочие нагрузки по регионам и восстанавливать вторичные данные после сбоя базы данных. Развертывания также могут быть построены на основе заданных требований к доступности и потере данных.
Изменение, которое имеет наибольшее значение для вашего бюджета потери данных, — это принцип работы восстановления после сбоев СУБД. Поскольку движок может повторно отправлять отсутствующие записи во вторичное хранилище из собственного первичного хранилища, повышенная в статусе база данных, которая отставала во время сбоя, больше не приводит к потере данных процессов. Таким образом, вы можете достичь целевой точки восстановления (RPO) равной 0 для всего кластера оркестрации даже при асинхронной репликации реляционной базы данных. Ранее эта гарантия требовала синхронной репликации со всеми вытекающими из этого задержками и затратами.
Наряду с этим, размещение с учетом регионов делает распределение реплик явным, а новые шаблоны для Kubernetes и AWS ECS описывают, как настраивать и эксплуатировать эти возможности в разных регионах.
Размещение разделов с учетом регионов
Отказоустойчивость начинается с того, где хранятся ваши данные. Запуск брокеров в нескольких регионах — это лишь часть проектирования: реплики разделов также должны быть распределены так, чтобы кластер мог безопасно восстановиться при недоступности региона.
В Camunda 8.10 операторы могут назначать зону каждому брокеру Zeebe для идентификации его региона, зоны доступности или локального дата-центра. Движок использует эти метки для распределения реплик разделов по настроенным группам, снижая зависимость от ручной настройки размещения при изменении топологии кластера.
Для соответствующим образом настроенного трехрегионального развертывания такое распределение позволяет выжившим регионам сохранять кворум (большинство реплик разделов, необходимых для безопасного продолжения обработки) после потери одного региона. Лидерство подчиняется статическому приоритету для каждой зоны.
Это дает операторам явный способ выразить топологию развертывания и согласовать размещение реплик с требованиями к восстановлению. Оно не выполняет автоматическое перераспределение реплик во время регионального сбоя и не перенаправляет экземпляры процессов в предпочтительный регион.
Camunda 8.10 также добавляет API для изменения конфигурации зон на лету, что значительно упрощает процедуру переключения, восстановления после сбоя или возврата в исходное состояние; например, повторное добавление зоны после восстановления региона.
Восстановление после сбоев СУБД во время непрерывной работы движка
Camunda 8.10 добавляет определенное поведение восстановления для глобальных реляционных баз данных, используемых в качестве вторичного хранилища. Это охватывает как временную недоступность базы данных, так и потерю записей из-за асинхронной репликации вторичного хранилища во время сбоя.
Когда активная конечная точка базы данных становится недоступной, экспорт приостанавливается и возобновляется при восстановлении соединения. Если в повышенной базе данных отсутствуют записи (например, потому что асинхронная репликация не успела завершиться до сбоя), движок восстанавливает эти записи из первичного хранилища и восстанавливает состояние вторичной базы данных.
Движок продолжает обработку, пока вторичное хранилище восстанавливается. Это отделяет выполнение процессов от восстановления базы данных, хотя приложения и запросы, зависящие от вторичного хранилища, могут оставаться недоступными или отображать устаревшие данные до завершения восстановления.
Регион C находится в аварийном состоянии, и его брокер недоступен. Регионы A и B по-прежнему содержат большинство реплик разделов, поэтому обработка продолжается без Региона C.
Для баз данных с нативной межрегиональной репликацией, таких как Aurora Global Database, операторы могут настроить экспорт в единую логическую конечную точку базы данных вместо поддержки отдельных конфигураций экспортеров для каждого региона.
Эта возможность применима ко всем поддерживаемым моделям развертывания, предоставляя командам единый механизм восстановления независимо от того, запускают ли они Camunda в Kubernetes, ECS или на другой поддерживаемой платформе.
Новые многорегиональные эталонные архитектуры
Чтобы помочь командам применить эти возможности на практике, Camunda 8.10 добавляет проверенные эталонные архитектуры для тререгиональных (или более) развертываний в Kubernetes и двурегиональных в AWS ECS. Каждая из них объединяет рекомендуемую топологию с примерами конфигурации и операционными рекомендациями, предоставляя поддерживаемую отправную точку для реализации и тестирования восстановления.
Трехрегиональный Kubernetes
Новая архитектура Kubernetes объединяет растянутый кластер Zeebe в трех регионах с многорегиональной глобальной СУБД для вторичного хранилища. Zeebe, движок автоматизации процессов, лежащий в основе Camunda, не имеет центрального координатора. Брокеры образуют одноранговый кластер, и каждый раздел переключается на другую реплику при выходе из строя узла его лидера, если большинство реплик этого раздела выживает. Этот релиз распространяет такую отказоустойчивость на регионы.
Размещение с учетом регионов распределяет реплики первичного хранилища так, чтобы движок мог поддерживать кворум после потери одного региона. Вторичное хранилище использует синхронную или асинхронную репликацию в зависимости от выбранной базы данных и требований к восстановлению.
Документация включает архитектурные диаграммы, примеры манифестов Terraform и Kubernetes, а также руководства на случай потери одного региона, сетевых разрывов между регионами и сбоев СУБД в одном регионе. В ней также объясняется, как поведение кворума предотвращает разделение мозга (split-brain).
Для команд, которым необходимо поддерживать доступность движка во время регионального сбоя, этот шаблон предоставляет проверенный дизайн и воспроизводимую основу для учений по восстановлению.
Двурегиональный AWS ECS
Новая архитектура ECS/Fargate запускает кластер оркестрации и коннекторы в двух регионах AWS, а Aurora Global Database обеспечивает вторичное хранилище.
Двурегиональное развертывание AWS ECS. Регион A запускает первичный кластер оркестрации и коннекторы. Aurora Global Database реплицирует данные между двумя регионами, а при сбое происходит переключение на конечную точку Региона B с целевым временем восстановления больше нуля.
Руководство объединяет рекомендуемую топологию, конфигурацию экспортера, пиринг VPC и сетевые параметры Transit Gateway, а также пошаговые процедуры переключения при сбое и возврата в исходное состояние. Команды, стандартизирующие работу на ECS, могут использовать его для реализации регионального восстановления без необходимости проектировать и проверять взаимодействие каждого компонента с нуля.
Двурегиональная архитектура сохраняет данные процессов во время регионального восстановления с RPO, равным 0. Восстановление связано с простоем, поэтому его целевое время восстановления (RTO) остается больше нуля.
Выберите топологию, которая соответствует вашим требованиям к восстановлению
Эти две архитектуры ориентированы на разные требования к доступности. RPO описывает допустимую потерю данных; RTO описывает допустимое время простоя.
Сохранение данных процессов с прерыванием работы во время восстановления
Два региона поддерживают RPO = 0 при RTO > 0.
Поддержание доступности движка при сбое региона
Для RTO = 0 требуется как минимум три региона с размещением реплик, настроенным для сохранения кворума.
Эти целевые показатели описывают восстановление движка. Доступность приложения от начала до конца также зависит от вторичного хранилища и других служб, используемых вашими процессами. Поэтому репликацию и аварийное переключение базы данных следует тестировать вместе с восстановлением движка в рамках одной и той же операционной тренировки.
Почему это важно для глобальной реорганизации процессов (Great Process Re-Engineering)
Camunda оркеструет агентов извне — как участников сквозного процесса, так и изнутри — с помощью обязательных шагов между рассуждениями агента и его действиями. Прежде чем агент переведет деньги, процесс может потребовать проверки политик или одобрения человека.
Реорганизация процесса вокруг ИИ переносит координационную работу, которую раньше выполняли люди, на саму платформу. Агенты принимают решения, системы действуют, и ни одна команда больше не ведет процесс вручную при возникновении сбоев. Платформа становится несущим элементом бизнес-операций так, как это не было свойственно прежним средствам автоматизации. Camunda объединяет детерминированные шаги с фиксированными правилами и динамические решения агентов, где требуется суждение.
Это меняет требования, которые следует предъявлять к платформе, прежде чем доверять ей свои самые ценные процессы. Важно не только то, что могут ее агенты, но и то, как ведет себя лежащая под ними платформа при сбое региона в середине процесса: сохраняется ли состояние процесса, продолжает ли движок работу и следует ли восстановление задокументированной процедуре, а не импровизации.
Размещение с учетом регионов, восстановление при сбое РСУБД и проверенные многорегиональные архитектуры — это то, как Camunda отвечает на данный вопрос. Они также объясняют, почему список процессов, которые предприятие может ответственно реорганизовать, становится длиннее. Доверие к платформе, а не какая-то отдельная функция, определяет, какую часть глобальной реорганизации процессов организации действительно удается реализовать.
Начало работы с Camunda 8.10
Эти возможности и эталонные архитектуры доступны в Camunda 8.10 Self-Managed. Существующие развертывания могут оценить метки топологии и конфигурацию восстановления РСУБД в рамках своего обновления; развертывания без меток топологии сохраняют прежнее поведение размещения.
Если вы расширяете однорегиональное развертывание, начните с эталонной архитектуры для вашей платформы и требований к восстановлению. Если вы уже работаете в нескольких регионах, используйте новые рекомендации для проверки распределения реплик, аварийного переключения базы данных и процедур восстановления по отношению к вашему текущему проекту.
Ознакомьтесь с уровнями устойчивости для нескольких регионов, чтобы спланировать развертывание и проверить восстановление на ваших собственных рабочих нагрузках. Camunda — это корпоративная платформа для агентной оркестрации.
