Резервные копии выполняются каждый час: в Elasticsearch или OpenSearch через внешний триггер, такой как Kubernetes CronJob, и в РСУБД через внутренний планировщик кластера оркестрации. Последний бэкап завершился в 1:00 UTC, а следующий запустится в 2:00. В 2:00 UTC оператор запускает пакетную операцию для очистки старых тестовых экземпляров. Фильтр указан неверно, и за считанные минуты удаляются тысячи экземпляров производственных процессов, к которым никогда не следовало прикасаться. Удаление нельзя отменить, и кластер реплицировал его на каждый брокер, точно так, как и задумывалось. Единственная копия этих экземпляров находится в резервных копиях, и группа реагирования на инциденты принимает решение восстановить данные из них.
То, насколько успешно пройдет этот процесс, зависит от решений, принятых задолго до 2:00 UTC. Захватил ли бэкап основное и вторичное хранилища в согласованной точке? Проверял ли кто-нибудь процедуру восстановления на практике?
Описанная ночная сцена состоит из двух частей: резервное копирование и восстановление. В каждой части рассказывается о том, что изменилось в Camunda 8.9 и 8.10 и как выполнять эти операции сегодня.
Что поставлено на карту
Описанный выше инцидент объясняет, почему резервное копирование и восстановление представляют собой дисциплину, отличную от обеспечения высокой доступности. Высокая доступность позволяет корректно спроектированному кластеру справляться с ожидаемыми сбоями, такими как перезапущенный контейнер, вышедший из строя брокер или потеря зоны доступности. Резервное копирование и восстановление устраняют сбои, которые работающий кластер не может поглотить: логическое повреждение, случайное удаление, ошибку оператора или потерю инфраструктуры, превышающую допустимый предел отказоустойчивости кластера.
Ставки возрастают по мере того, как ИИ-агенты начинают совершать реальные действия в продакшене. Неудачное удаление может стереть запись о том, какое решение принял агент, поэтому восстановление должно сработать именно в ту ночь, когда оно понадобится.
Любой план восстановления сводится к двум показателям:
- Целевая точка восстановления (RPO) — это объем недавних данных, потеря которых допустима для организации.
- Целевое время восстановления (RTO) — это время, в течение которого сервис может быть недоступен.
Их легко перепутать. Резервное копирование каждые четыре часа не может обеспечить RPO в 15 минут. Но частота бэкапов ничего не говорит об RTO. Если подготовка инфраструктуры, восстановление базы данных, восстановление разделов среды выполнения и проверка бизнес-состояния в сумме занимают три часа, ваше RTO составляет три часа. Частота резервного копирования ограничивает точку восстановления. Вся операционная процедура определяет время восстановления.
Где Camunda хранит свое состояние
Camunda не хранит все релевантные состояния в одном месте. Полное восстановление может включать в себя:
- Первичное хранилище, в котором содержится авторитетное состояние среды выполнения кластера оркестрации: экземпляры процессов, задачи, таймеры, переменные, развертывания и состояние разделов.
- Вторичное хранилище, в котором содержатся данные, используемые API запросов и приложениями (Operate, Tasklist, Optimize). В зависимости от развертывания это может быть Elasticsearch, OpenSearch или реляционная база данных.
Кластер оркестрации сохраняет первичное хранилище с помощью резервной копии среды выполнения: по одному бэкапу на каждый раздел, записываемому в хранилище блочных бэкапов. Дисковые снимки каждого отдельного брокера не могут заменить его. Брокеры работают независимо друг от друга, поэтому независимые снимки дисков не синхронизируются между разделами. Резервные копии среды выполнения создаются через кластер, чтобы снимки всех разделов были согласованы. Подробнее читайте в нашей прошлой статье о горячих бэкапах Zeebe.
Однако успешной выгрузки или создания снимка базы данных недостаточно. Точка восстановления должна быть согласованной между уровнями хранения, и то, как Camunda этого добивается, зависит от бэкенда вторичного хранилища.
Elasticsearch и OpenSearch используют согласованную точку восстановления
В случае с Elasticsearch или OpenSearch восстанавливаемый бэкап представляет собой скоординированный набор артефактов: бэкап среды выполнения, охватывающий каждый раздел, и бэкап истории приложений. Каждый артефакт в наборе имеет один и тот же целочисленный ID резервной копии, предоставляемый оператором.
Общий ID определяет, какие артефакты принадлежат к одной и той же точке восстановления. Если восстановить первичное хранилище по одному ID, а вторичное — по другому, кластер окажется в несогласованном состоянии: в приложениях отобразятся экземпляры, о которых среда выполнения ничего не знает, или будут отсутствовать те, которые она все еще выполняет.
РСУБД отделяет первичное хранилище от базы данных
Если в качестве вторичного хранилища используется реляционная база данных, резервные копии первичного хранилища и базы данных создаются независимо друг от друга, каждая по собственному расписанию. Во время восстановления Camunda сопоставляет выбранный бэкап среды выполнения с точкой восстановления базы данных. Операторам не нужно координировать общий ID или делать оба снимка в один и тот же момент времени. Ваш администратор баз данных или оператор выполняет резервное копирование и восстановление базы данных с помощью собственных инструментов, независимо от кластера оркестрации. Это восстановление также охватывает данные приложений.
Разница заключается в базе данных. Механизмы резервного копирования реляционных баз данных поддерживают восстановление на определенный момент времени (point-in-time recovery). Снимки Elasticsearch и OpenSearch не поддерживают его, поэтому согласованность должна обеспечиваться в момент создания бэкапа с помощью общего ID.
В таблице ниже суммированы различия, имеющие значение для работы.
Координация бэкапов
Резервные копии должны тщательно координироваться с помощью ID бэкапа
Первичное хранилище и база данных резервируются независимо друг от друга
ID бэкапа
Предоставляется оператором
Генерируется кластером
Плановое и непрерывное резервное копирование
Встроенное планирование нецелесообразно (нет восстановления на определенный момент времени)
Поддерживается
Выбор точки восстановления
Согласованный ID бэкапа
ID бэкапа или точка во времени
Создание бэкапа
Восстановление начинается не в 2:00 UTC, когда все ломается. Оно начинается задолго до этого — с подготовки. Для бэкапов требуется расписание. Кто-то должен знать, где они хранятся и у кого есть к ним доступ. Сбои должны вовремя замечаться. Кроме того, команда должна хотя бы раз отработать процедуру восстановления на практике. Восстановление ровно настолько надежно, насколько надежна резервная копия, с которой оно начинается, и предшествующая ему подготовка.
Старый подход
До версии 8.9 строительные блоки для согласованных бэкапов существовали, но их эксплуатация требовала ручной работы.
В нашем примере бэкап в 1:00 UTC создавался с помощью Kubernetes CronJob. Он обращался к API управления — расширению Spring Boot Actuator на порту 9600, которое не входило в публичный API, поэтому задание обращалось к нему через kubectl port-forward или kubectl exec. Оно генерировало ID резервной копии и передавало его на каждом шаге. Ничто не удаляло бэкапы за прошлый месяц, если только кто-то не написал для этого еще одно задание.
Каждый компонент приходилось создавать самостоятельно. А затем обеспечивать его безопасность и работоспособность.
Camunda 8.9 удешевляет точки восстановления
Версия Camunda 8.9 сосредоточена на аспекте резервного копирования. Политика хранения применяется ко всем бэкендам, а остальные улучшения относятся к кластерам на базе РСУБД:
- Управление сроком хранения бэкапов периодически удаляет резервные копии среды выполнения, которые выходят за рамки настроенного периода хранения.
- Плановые бэкапы (РСУБД) переносят расписание резервного копирования непосредственно в сам кластер оркестрации. Внешние задания cron больше не нужны, а метрики и журналы аудита охватывают каждый запланированный запуск. Существующие команды резервного копирования продолжают работать.
- Непрерывные бэкапы (РСУБД) позволяют кластеру оркестрации непрерывно создавать контрольные точки, предоставляя диапазон точек восстановления вместо горстки разрозненных ID резервных копий.
- Независимые бэкапы (РСУБД) позволяют защищать среду выполнения и базу данных независимо друг от друга, а Camunda сопоставляет их во время восстановления.
- Выбор точки восстановления на основе времени (RDBMS) позволяет восстановиться на определенную метку времени. Camunda выбирает ближайшую доступную контрольную точку.
Для развертываний RDBMS целевое время восстановления (RPO) теперь определяется расписанием, управляемым кластером, и непрерывными контрольными точками, а не частотой запуска внешнего задания.
Сам процесс восстановления в версии 8.9 не меняется. Это произойдет позже в Camunda 8.10, где восстановление станет API-операцией.
Планирование резервного копирования
Начните с бизнес-требований и проектируйте расписание и хранилище на их основе. Политика резервного копирования должна фиксировать целевые показатели RPO и RTO, частоту резервного копирования, окно хранения и т. д.
Прежде чем что-либо автоматизировать, настройте хранилища и репозитории для резервных копий и убедитесь, что они доступны и защищены. В документации по резервному копированию и восстановлению описаны все необходимые предварительные требования.
Резервное копирование Elasticsearch и OpenSearch
В Elasticsearch и OpenSearch вы координируете резервное копирование самостоятельно. С помощью API кластера оркестрации Camunda 8.10 вы переводите экспорт в режим мягкой паузы (soft-pause), выполняете резервное копирование вторичного хранилища Elasticsearch (или OpenSearch), затем среды выполнения под тем же идентификатором резервной копии и возобновляете экспорт. На схеме ниже показан каждый шаг, соответствующая конечная точка и создаваемые артефакты. Вместе они формируют единую точку восстановления.
Запросы на резервное копирование являются асинхронными, поэтому опрашивайте состояние резервной копии, чтобы узнать, когда она завершится. Возобновляйте экспорт, даже если один из шагов завершился неудачей. В противном случае неудачное резервное копирование оставит экспорт в режиме мягкой паузы, пока диски брокера не переполнятся. В руководстве по резервному копированию Elasticsearch описана полная процедура и детали запросов.
Резервное копирование RDBMS
Для развертываний RDBMS не нужно ничего писать в скриптах или запускать вручную. Кластер оркестрации выполняет собственные запланированные и непрерывные резервные копии, а встроенные средства резервного копирования или восстановления на момент времени защищают базу данных вторичного хранилища. Ваша задача смещается от запуска резервных копий к наблюдению за ними.
Два окна восстановления должны быть синхронизированы. Время считается восстанавливаемым, если оно покрывается как окном восстановления базы данных на момент времени, так и сохраненными резервными копиями среды выполнения. Если кластер оркестрации хранит резервные копии за семь дней, а база данных — за три дня восстановления на момент времени, у вас есть три дня для восстановления, а не семь. Установите оба периода хранения так, чтобы они охватывали один и тот же интервал.
Сторона кластера оркестрации для этого окна определяется состоянием резервной копии среды выполнения (GET /v2/backups/runtime/state), которое возвращает диапазоны резервных копий для каждого раздела. Среда выполнения может восстановиться до любой точки, где эти диапазоны перекрываются.
В руководстве по резервному копированию RDBMS содержится более подробная информация.
Мониторинг точек восстановления, а не заданий
Для любого бэкенда настройте оповещения как о возрасте самой новой завершенной точки восстановления, так и об ошибках. Оповещение «Нет завершенной точки восстановления новее, чем порог RPO» позволяет обнаружить то, что не видит оповещение об ошибке: внешний планировщик, который перестал работать, расписание резервного копирования, которое было изменено или отключено, или резервную копию, застрявшую в состоянии IN_PROGRESS, которая никогда не сообщает об ошибке. В RDBMS, где нет вашего собственного задания, которое могло бы завершиться с ошибкой, это оповещение и диапазоны резервных копий являются вашими основными сигналами.
Наряду с возрастом отслеживайте длительность резервного копирования, дату и длительность последнего успешного упражнения по восстановлению, а также, в зависимости от бэкенда, рост диска брокера во время окна мягкой паузы или длину окна восстановления базы данных.
В Camunda 8.10 состояние резервного копирования и каждый шаг восстановления являются API-вызовами с явными результатами, поэтому процесс восстановления наблюдаем, а не скрыт в логах брокера.
Восстановление кластера
Вернемся к инциденту. Сейчас чуть больше 2 часов ночи, и пакетная операция остановлена.
Старый способ
До версии 8.10 восстановление было автономной операцией. Дежурный инженер открывает руководство и начинает с вопроса: была ли завершена ночная резервная копия? Нет способа проверить, можно ли ее успешно восстановить, не пройдя всю процедуру целиком.
Затем следует сама процедура. Масштабирование брокеров вниз. Редактирование значений Helm для добавления init-контейнера восстановления с правильным идентификатором резервной копии. Восстановление вторичного хранилища из соответствующих снимков. Масштабирование брокеров обратно вверх и наблюдение за тем, как каждый из них восстанавливает свои разделы. Прогресс виден в логах брокера и состояниях подов, поэтому инженер просматривает логи десятка подов, чтобы решить, сработало ли это.
Эта процедура все еще работает и доступна. Но каждый шаг — это место, где в руководстве может что-то пойти не так, и каждый шаг выполняется под давлением посреди ночи.
Camunda 8.10 делает восстановление API-операцией
Camunda 8.10 переносит сторону восстановления на REST API кластера оркестрации. Резервное копирование, управление экспортом и восстановление становятся обычными API-операциями с той же аутентификацией и авторизацией, что и остальной API, отдельными разрешениями для каждого и без необходимости доступа к порту управления.
Само восстановление теперь выполняется на месте, внутри работающего кластера. Вместо остановки брокеров и запуска приложения восстановления на каждом из них, вы переводите кластер в режим восстановления, где брокеры перестают обрабатывать данные, но запросы резервного копирования остаются доступными, а затем запрашиваете восстановление. Кластер удаляет локальные данные каждого раздела, восстанавливает их из выбранной резервной копии и переключает брокеров обратно в состояние PROCESSING.
Каждый запрос возвращает changeId, поэтому прогресс отслеживается через API, а не через логи брокера.
«На месте» не означает отсутствие простоя. Пока разделы находятся в режиме восстановления, они ничего не обрабатывают. Что убирает версия 8.10, так это работу по перезапуску и повторному развертыванию, связанную с восстановлением. Само окно восстановления остается.
Выбор точки восстановления
Теперь руководителю инцидента нужно выбрать точку восстановления, и здесь важен бэкенд. В Elasticsearch самая новая точка восстановления — это резервная копия в 01:00, и час работы потерян. В кластере на базе RDBMS непрерывные контрольные точки позволяют руководителю восстановиться на 01:58, за две минуты до начала удаления, поэтому потеряно две минуты работы. Запланированная резервная копия в 2 часа ночи по UTC завершается после этой контрольной точки, что делает ее допустимой целью восстановления. В любом случае, выбор точки восстановления также определяет, какая работа будет выполнена дважды: каждое задание, завершенное после нее, станет активным снова, и ваши воркеры подхватят его во второй раз.
С версией 8.10 ничего не нужно масштабировать вниз или редактировать в чарте Helm. Восстановление состоит из пяти шагов, а окно простоя длится с момента входа в режим восстановления на шаге 1 до конца шага 4.
Пока кластер находится в режиме восстановления, вы также можете выполнить пробный запуск восстановления (POST /v2/restore?dryRun=true), чтобы сначала проверить его. Пробный запуск проверяет, что содержимое резервной копии действительно, не применяя его к разделам.
В документации по резервному копированию и восстановлению описаны полная процедура и детали запросов.
Восстановление Camunda не отматывает назад остальной мир. Каждое задание, завершенное между точкой восстановления и инцидентом, снова становится активным, и воркеры повторят его побочные эффекты. Платеж может уйти дважды. Электронное письмо может быть отправлено снова. Партнерская система будет вызвана во второй раз. Будет ли это безвредно, зависит от идемпотентности ваших воркеров. Проверьте это на учениях, чтобы сверка не преподнесла сюрпризов.
Инфраструктура, сообщающая о нормальном состоянии, — это лишь малая часть процесса восстановления. Однако бизнес восстанавливается только тогда, когда все сопутствующие системы приходят к согласию относительно того, какая работа должна выполняться дальше.
Сохранение контроля за людьми
Старая процедура содержала примерно столько же шагов. Проблема заключалась в том, что люди совершали ошибки или выполняли правильные действия в неправильном порядке под давлением. В версии 8.10 каждый шаг представляет собой вызов API, который проверяет запрос и сообщает о его результате, поэтому нет необходимости вносить правки в Helm, в которых можно ошибиться, и нет логов, которые нужно отслеживать, чтобы понять, сработало ли всё. Вы можете выполнять шаги вручную из своего руководства по инцидентам (runbook). Оставьте за людьми два решения: утверждение точки восстановления и открытие бизнес-трафика после завершения сверки. Всё остальное — механическая работа.
От руководства к тренировкам
Представьте себе снова инцидент в 2 часа ночи по UTC, но с командой, которая уже делала это раньше. До версии 8.10 восстановление означало остановку брокеров, изменение конфигурации развертывания и чтение логов, поэтому большинство команд просто документировали процесс, но никогда его не запускали. Теперь каждый шаг — это вызов API с четким результатом, а состояние резервной копии и её диапазоны можно прочитать в любое время. Это делает репетиции доступными:
- Проверяйте окно восстановления по расписанию, чтобы разрыв обнаружился во вторник днем, а не во время инцидента.
- Выполняйте полное восстановление, включая пробный запуск, на промежуточном (staging) кластере, используя те же шаги, что и в рабочей среде, и записывайте точку восстановления, changeId и время, затраченное на каждую фазу. Ваш RTO становится измеримым показателем.
- Сравнивайте результаты тренировок с течением времени, чтобы заметить тенденцию замедления восстановления по мере роста объема данных.
Когда наступает 2 часа ночи по UTC, команда уже знает, что делать. Они репетировали это на прошлой неделе и проверили точку восстановления сегодня утром.
Углубление знаний
Если вы хотите узнать больше об этой теме, ознакомьтесь с приведенными ниже ссылками для углубления своих знаний:
