Изоляция восстановленного экземпляра платформы

Изоляция восстановленного экземпляра платформы#

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

Сразу после завершения восстановления выполните следующие действия в порядке убывания срочности:

  1. Отключите синхронизацию записи исходного кластера в базе данных Automation Dashboard (см. Запись кластера в базе данных Automation Dashboard). Окно самое короткое. Первый цикл синхронизации наступает на ближайшей 5-минутной границе после старта пода Automation Dashboard и перезаписывает восстановленные данные.

  2. Для экземпляров платформы с внешними узлами плоскости исполнения отключите внешние узлы в восстановленном экземпляре платформы (см. Внешние узлы плоскости исполнения) до выполнения первого задания по восстановленным расписаниям.

  3. Удалите записи сервисных узлов исходного экземпляра платформы из базы данных шлюза (см. Сервисные узлы шлюза платформы).

Очереди Event-Driven Automation изолируются автоматически (см. Очереди Event-Driven Automation).

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

Запись кластера в базе данных Automation Dashboard#

В восстановленной базе данных Automation Dashboard (панель аналитики) сохраняется запись Cluster исходного экземпляра платформы вместе с включенным расписанием синхронизации (каждые 5 минут). Запись Cluster описывает подключенный к Automation Dashboard экземпляр платформы, данные которого он собирает. Automation Dashboard не помечает одну из записей как собственную. Диспетчер синхронизирует каждую запись с включенным расписанием, в том числе запись исходного экземпляра платформы. Если адрес исходного экземпляра платформы достижим, восстановленный Automation Dashboard в первые же минуты начнет синхронизацию с ним, то есть добавит объекты, появившиеся после создания резервной копии, и удалит из восстановленной базы данных объекты, исчезнувшие на исходном экземпляре платформы. Восстановленные данные будут перезаписаны из исходного экземпляра. Кроме того, Automation Dashboard автоматически заново регистрирует кластеры, когда адрес нового шлюза достижим. Записи, не попавшие в новый список кластеров, удаляются из базы данных каскадом со всеми связанными данными.

При корневом восстановлении (ресурсом AstraAutomationRestore) дочерний ресурс DashboardRestore создает оператор, и отключить запуск пода Automation Dashboard нельзя. Под запускается задолго до перехода корневого ресурса в состояние Successful=True, поэтому при достижимом адресе исходного экземпляра первый цикл синхронизации, как правило, успевает пройти до завершения восстановления. Выполните просмотр записей и отключение синхронизации сразу после появления пода Automation Dashboard в выводе kubectl get pods, не дожидаясь завершения корневого восстановления. Затем проверьте, прошел ли цикл синхронизации: записи в таблице scheduler_syncjob с cluster_id записи исходного экземпляра означают выполненный цикл. Если цикл прошел, восстановленные данные Automation Dashboard уже перезаписаны. В этом случае восстановите его базу данных повторно отдельным ресурсом DashboardRestore с отключенным запуском пода и отключите синхронизацию до восстановления реплик, как описано ниже.

Для отключения синхронизации выполните следующие действия:

  1. Получите список записей Cluster и расписаний синхронизации (запись исходного экземпляра платформы опознается по адресу):

    kubectl -n astra-automation exec <dashboard>-postgres-15-0 -- bash -c 'psql -U $POSTGRES_USER -d $POSTGRES_DB \
  -c "SELECT id, protocol, address, port, aap_version FROM clusters_cluster;" \
  -c "SELECT id, cluster_id, name, enabled, next_run FROM scheduler_syncschedule;"'

    Здесь:

    • <dashboard> – название ресурса Dashboard восстановленного экземпляра платформы, обычно <deployment>-dashboard;

    • <deployment> – название восстановленного экземпляра платформы.

  2. Отключите синхронизацию записи исходного экземпляра платформы (данные записи при этом сохраняются):

    kubectl -n astra-automation exec <dashboard>-postgres-15-0 -- bash -c 'psql -U $POSTGRES_USER -d $POSTGRES_DB \
  -c "UPDATE scheduler_syncschedule SET enabled = false WHERE cluster_id = <id>;"'

    Здесь:

    • <id> – идентификатор записи исходного экземпляра платформы из выходных сообщений первой команды.

  3. Проверьте результат: включенное расписание (enabled = t) должно быть только у записи восстановленного кластера, ее адрес указывает на восстановленный экземпляр платформы, а новые записи в таблице scheduler_syncjob создаются только с ее cluster_id.

При восстановлении компонента Automation Dashboard отдельным ресурсом DashboardRestore (вне корневого восстановления) его под можно не запускать до очистки. Задайте это в его манифесте spec_overrides: {dashboard: {replicas: 0}}, выполните шаги выше, затем восстановите реплики командой kubectl patch dashboard <dashboard> --type=merge -p '{"spec":{"dashboard":{"replicas":1}}}'.

Полное удаление записи исходного кластера выполняется только средствами Django, так как прямой SQL-запрос DELETE отклоняется по внешним ключам:

kubectl -n astra-automation exec <dashboard-pod> -c dashboard -- bash -c \
  'cd /code/src/backend && /venv/bin/python manage.py shell -c \
   "from backend.apps.clusters.models import Cluster; print(Cluster.objects.get(pk=<id>).delete())"'

Здесь:

  • <dashboard-pod> – название пода Automation Dashboard восстановленного экземпляра платформы.

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

Automation Dashboard после восстановления имеет следующие особенности:

  • Выделенное название узла Automation Dashboard (dashboard.hostname) при восстановлении сбрасывается. Унаследованный адрес конфликтовал бы с ingress и обратным вызовом OAuth работающего Automation Dashboard исходного экземпляра платформы. Automation Dashboard восстановленного экземпляра платформы использует адрес из его поля public_base_url. При необходимости задайте новое выделенное название узла после восстановления в секции spec ресурса AstraAutomation.

  • Авторизация Automation Dashboard не зависит от исходного экземпляра платформы. При восстановлении Automation Dashboard получает собственную регистрацию OAuth от своего экземпляра платформы.

  • Параметры базы данных Automation Dashboard задавайте в поле spec.dashboard.database ресурса AstraAutomation, а не правкой ресурса Dashboard напрямую. Корневой оператор управляет ресурсом Dashboard. Прямые правки будут вытеснены при очередном согласовании ресурсов.

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

Внешние узлы плоскости исполнения#

Применение плоскости исполнения с внешними узлами требует учета ее особенностей при резервном копировании и восстановлении.

Резервная копия включает параметры регистрации узлов (в базе данных Automation Controller) и криптографический контур сети Mesh. Секреты <name>-receptor-ca и <name>-receptor-work-signing восстанавливаются штатно.

Здесь:

  • <name> – название ресурса Automation Controller восстановленного экземпляра платформы.

Так как эти секреты совпадают с исходными, контроллер восстановленного экземпляра платформы строит ту же конфигурацию Receptor, что у исходного, и при восстановлении рядом с работающим исходным автоматически входит в ту же сеть Mesh. Внешние узлы отображаются в нем в состоянии Ready и обслуживают оба экземпляра платформы одновременно. Задания, запущенные в восстановленном экземпляре платформы, включая пробное задание из контрольного списка и задания по восстановленным расписаниям, выполнятся на рабочих узлах исходного экземпляра платформы.

Отдельный Mesh Ingress для восстановленного экземпляра платформы не защищает от этого. Связность определяется записями восстановленной базы данных, а контроллер подключается к узлам с peers_from_control_nodes: true напрямую, минуя Mesh Ingress. Остановить контроллер масштабированием в ноль количества реплик нельзя, так как оператор возвращает реплики на ближайшем цикле согласования ресурсов.

Отключение внешних узлов#

Перед проверками отключите внешние узлы в восстановленном экземпляре платформы. Изменение затрагивает только базу данных восстановленного экземпляра платформы и не влияет на работу узлов с исходным. Отключение выполняется через REST API контроллера той же трансляцией порта, что и при проверке данных (см. Проверка восстановленных данных), так чтобы запросы направлялись в нужный экземпляр:

# Трансляция порта к сервису контроллера восстановленного экземпляра платформы
kubectl -n astra-automation port-forward svc/aa-restored-controller-service 18080:80 &
PASS=$(kubectl -n astra-automation get secret <admin-password-secret> \
  -o jsonpath='{.data.password}' | base64 -d)

# Список внешних узлов (все, кроме управляющих)
curl -s -u "admin:$PASS" \
  "http://localhost:18080/api/v2/instances/?not__node_type=control" \
  | python3 -c 'import json,sys; [print(i["id"], i["hostname"], i["node_type"], "enabled="+str(i["enabled"])) for i in json.load(sys.stdin)["results"]]'

# Отключение каждого внешнего узла по его идентификатору
for id in <ids>; do
  curl -s -X PATCH -u "admin:$PASS" -H "Content-Type: application/json" \
    -d '{"enabled": false}' "http://localhost:18080/api/v2/instances/${id}/"
done

Здесь:

  • <admin-password-secret> – секрет *-admin-password контроллера восстановленного экземпляра платформы;

  • <ids> – идентификаторы внешних узлов из выходных сообщений первой команды.

Отключенный узел не принимает задания от восстановленного экземпляра платформы, но соединения сети Mesh сохраняются. Для полного разрыва соединений выведите узлы из эксплуатации в восстановленном экземпляре платформы запросом PATCH {"node_state": "deprovisioning"} к тому же ресурсу. Запись удаляется из базы данных восстановленного экземпляра, и конфигурация Receptor контроллера создается заново без этих узлов.

Пробное задание в восстановленном экземпляре платформы выполняйте в контейнерной группе кластера (default). Отключение внешних узлов не влияет на нее.

Восстановление в другом кластере или взамен утраченной платформы#

При восстановлении в другом кластере или взамен утраченной платформы адрес Mesh Ingress меняется. Узлы, устанавливающие соединение с платформой самостоятельно (peers_from_control_nodes: false), продолжают обращаться по прежнему адресу и отображаются в восстановленном экземпляре платформы как недоступные. Такие узлы переподключают по процедуре подключения внешних узлов (см. Топология в кластере Kubernetes) повторным запуском сценария подключения либо повторной выгрузкой установочного пакета, уже с новым адресом. Восстановленный экземпляр платформы подключает напрямую узлы, соединение с которыми устанавливает плоскость управления (peers_from_control_nodes: true), если их прежние адреса достижимы по сети. Они окажутся общими с исходным экземпляром платформы. При работающем исходном экземпляре платформы отключите их, как описано выше.

Сервисные узлы шлюза платформы#

Дамп базы данных шлюза содержит записи сервисных узлов исходного экземпляра платформы. Это адреса компонентов, между которыми шлюз распределяет запросы. Оператор нового экземпляра платформы регистрирует в тех же кластерах сервисов собственные узлы, но не удаляет записи исходного экземпляра платформы. В результате шлюз восстановленного экземпляра платформы распределяет запросы /api/*, /token, /v2/, /pulp между компонентами исходного и восстановленного экземпляров платформы примерно поровну. Это приводит к следующим последствиям:

  • проверка восстановленных данных дает ложные результаты, так как часть ответов приходит от исходного экземпляра платформы, и объект то отсутствует в ответах, то появляется снова;

  • импорт контента Private Automation Hub периодически завершается ошибкой The provided Bearer token is invalid – токен, выданный реестром одного экземпляра платформы, отклоняется реестром другого;

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

Удаляйте записи исходного экземпляра платформы через REST API шлюза. В отличие от изменения базы данных напрямую, запрос проходит валидацию и попадает в журнал аудита. Выполняйте запросы изнутри пода шлюза восстановленного экземпляра платформы (контейнер api, порт 8000). Так они гарантированно попадают в нужный экземпляр.

Для удаления записей выполните следующие действия:

  1. Получите список зарегистрированных сервисных узлов:

    NS=astra-automation
NEW=aa-restored

# Пароль администратора после восстановления совпадает с паролем исходного экземпляра платформы
PW=$(kubectl -n $NS get secret <admin-password-secret> \
  -o jsonpath='{.data.password}' | base64 -d)

kubectl -n $NS exec deploy/${NEW}-gateway -c api -- \
  curl -s -u "admin:$PW" "http://localhost:8000/api/gateway/v1/service_nodes/"

    Здесь:

    • NEW – название восстановленного экземпляра платформы;

    • <admin-password-secret> – секрет *-admin-password шлюза восстановленного экземпляра платформы.

    Ответ возвращается в формате JSON. В нем присутствуют записи обоих экземпляров платформы, и записи исходного опознаются по названиям его компонентов. Пример записей в сокращенном виде:

    2 Node controller - ac-demo ac-demo-service cluster: 2
3 Node galaxy - pah-demo pah-demo-web-svc cluster: 3
...
6 Node controller - aa-restored-controller aa-restored-controller-service cluster: 2
7 Node galaxy - aa-restored-hub aa-restored-hub-web-svc cluster: 3

  2. Удалите каждую запись исходного экземпляра платформы по ее идентификатору:

    for id in 2 3 4 5; do
  kubectl -n $NS exec deploy/${NEW}-gateway -c api -- \
    curl -s -X DELETE -u "admin:$PW" "http://localhost:8000/api/gateway/v1/service_nodes/${id}/"
done

    Не удаляйте запись типа GATEWAY с адресом 0.0.0.0, так как это собственный узел шлюза восстановленного экземпляра платформы.

  3. Перезапустите поды шлюза, чтобы прочитать заново маршруты:

    kubectl -n $NS rollout restart deployment ${NEW}-gateway

Если импорт контента Private Automation Hub завершился ошибкой до очистки, оператор пересоздает задание Kubernetes на импортирование в очередном цикле согласования ресурсов. Если задание не создается заново, удалите его вручную, после чего оператор создаст новое:

kubectl -n $NS get jobs | grep importer
kubectl -n $NS delete job <hub-name>-importer-<hash>

Здесь:

  • <hub-name> – название ресурса Private Automation Hub восстановленного экземпляра платформы;

  • <hash> – суффикс из названия существующего задания (из выходных сообщений первой команды).

Очереди Event-Driven Automation#

Восстановленный экземпляр платформы использует собственный Redis. Очереди задач Event-Driven Automation изолированы, а обработчики восстановленного экземпляра платформы не перехватывают задачи исходного.

Во время процедуры восстановления существует короткое окно (до нескольких минут), при котором Event-Driven Automation восстановленного экземпляра платформы еще связан с Redis исходного. Оно длится до развертывания ресурса AstraAutomation и первого согласования ресурсов. Окно закрывается автоматически, вмешательства не требуется.

Для проверки изоляции выполните в Redis исходного экземпляра платформы команду SMEMBERS eda-rq:workers. В списке должны присутствовать только обработчики самого исходного экземпляра платформы. Ключи очередей Event-Driven Automation находятся под префиксом eda-rq:. Команда с префиксом rq: вернет ошибку NOPERM, а не пустой список. Список управления доступом Redis ограничивает пользователя eda шаблоном ~eda-rq:*.