#Восстановление после катастрофы для глобального кластера

#Обзор

Это решение предназначено для сценариев восстановления после катастрофы, связанных с кластером global. Кластер global служит управляющей плоскостью платформы и отвечает за управление другими кластерами. Для обеспечения непрерывной доступности платформы при сбое кластера global это решение развертывает два кластера global: основной кластер (Primary Cluster) и резервный кластер (Standby Cluster).

Механизм восстановления после катастрофы основан на синхронизации данных etcd в реальном времени с основного кластера на резервный. Если основной кластер становится недоступен из-за сбоя, сервисы могут быстро переключиться на резервный кластер.

#Поддерживаемые сценарии катастроф

• Неисправимый системный сбой основного кластера, делающий его непригодным к работе;
• Сбой физических или виртуальных машин, на которых размещён основной кластер, что делает его недоступным;
• Сбой сети в месте расположения основного кластера, приводящий к прерыванию сервиса;

#Неподдерживаемые сценарии катастроф

• Сбои приложений, развернутых внутри кластера global;
• Потеря данных, вызванная сбоями системы хранения (вне области синхронизации etcd);

Роли Primary Cluster и Standby Cluster относительны: кластер, который в данный момент обслуживает платформу, является основным (DNS указывает на него), а резервный — резервным. После переключения роли меняются местами.

#Примечания

• Это решение синхронизирует только данные etcd кластера global; данные реестра, chartmuseum и других компонентов не включены;

• Для удобства устранения неполадок и управления рекомендуется называть узлы в стиле standby-global-m1, чтобы указывать, к какому кластеру принадлежит узел (Primary или Standby).

• Восстановление данных приложений внутри кластера не поддерживается;

• Для надежной синхронизации etcd требуется стабильное сетевое соединение между двумя кластерами;

• Если кластеры основаны на гетерогенных архитектурах (например, x86 и ARM), используйте пакет установки с поддержкой двух архитектур;

• Следующие пространства имён исключены из синхронизации etcd. Если в них создаются ресурсы, пользователям необходимо выполнять их резервное копирование вручную:

  cpaas-system
  cert-manager
  default
  global-credentials
  cpaas-system-global-credentials
  kube-ovn
  kube-public
  kube-system
  nsx-system
  cpaas-solution
  kube-node-lease
  kubevirt
  nativestor-system
  operators

• Если оба кластера используют встроенные реестры образов, контейнерные образы необходимо загружать отдельно в каждый из них;

• Если в основном кластере развернут DevOps Eventing v3 (knative-operator) и его экземпляры, те же компоненты должны быть предварительно развернуты в резервном кластере.

#Обзор процесса

1. Подготовить единое доменное имя для доступа к платформе;
2. Направить домен на VIP основного кластера и установить Primary Cluster;
3. Временно переключить DNS на резервный VIP для установки Standby Cluster;
4. Скопировать ключ шифрования ETCD основного кластера на узлы, которые впоследствии станут управляющими узлами резервного кластера;
5. Установить и включить плагин синхронизации etcd;
6. Проверить статус синхронизации и выполнять регулярные проверки;
7. В случае сбоя переключить DNS на резервный кластер для завершения восстановления после катастрофы.

#Требуемые ресурсы

• Единое доменное имя, которое будет Platform Access Address, а также TLS-сертификат и приватный ключ для обслуживания HTTPS на этом домене;

• Выделенный виртуальный IP-адрес для каждого кластера — один для Primary Cluster и другой для Standby Cluster;

  • Предварительно настроить балансировщик нагрузки для маршрутизации TCP-трафика на порты 80, 443, 6443, 2379 и 11443 на управляющие узлы за соответствующим VIP.

#Процедура

#Шаг 1: Установка основного кластера

Обратитесь к следующей документации для завершения установки:

• Подготовка к установке
• Установка

#Шаг 2: Установка резервного кластера

1. Временно направьте доменное имя на VIP резервного кластера;

2. Войдите на первый управляющий узел Primary Cluster и скопируйте конфигурацию шифрования etcd на все управляющие узлы резервного кластера:

   # Предположим, что управляющие узлы основного кластера: 1.1.1.1, 2.2.2.2 и 3.3.3.3
   # а управляющие узлы резервного кластера: 4.4.4.4, 5.5.5.5 и 6.6.6.6
   for i in 4.4.4.4 5.5.5.5 6.6.6.6  # Замените IP-адреса на управляющие узлы резервного кластера
   do
     ssh "<user>@$i" "sudo mkdir -p /etc/kubernetes/"
     scp /etc/kubernetes/encryption-provider.conf "<user>@$i:/tmp/encryption-provider.conf"
     ssh "<user>@$i" "sudo install -o root -g root -m 600 /tmp/encryption-provider.conf /etc/kubernetes/encryption-provider.conf && rm -f /tmp/encryption-provider.conf"
   done

3. Установите резервный кластер так же, как и основной

Обратитесь к следующей документации для завершения установки:

• Подготовка к установке
• Установка

#Шаг 3: Включение синхронизации etcd

1. При необходимости настройте балансировщик нагрузки для перенаправления порта 2379 на управляющие узлы соответствующего кластера. Поддерживается ТОЛЬКО TCP-режим; перенаправление на уровне L7 не поддерживается.

   INFO

   Перенаправление портов через балансировщик нагрузки не обязательно. Если из резервного кластера доступен прямой доступ к активному глобальному кластеру, укажите адреса etcd через Active Global Cluster ETCD Endpoints.

2. Зайдите в веб-консоль резервного глобального кластера по его VIP и переключитесь в режим Administrator;

3. Перейдите в Marketplace > Cluster Plugins, выберите кластер global;

4. Найдите etcd Synchronizer, нажмите Install, настройте параметры:

   • Если порт 2379 не перенаправляется через балансировщик, необходимо корректно указать Active Global Cluster ETCD Endpoints;
   • Используйте значение по умолчанию для Data Check Interval;
   • Оставьте переключатель Print detail logs выключенным, если не требуется отладка.

Проверьте, что Pod синхронизации запущен в резервном кластере:

kubectl get po -n cpaas-system -l app=etcd-sync
kubectl logs -n cpaas-system $(kubectl get po -n cpaas-system -l app=etcd-sync --no-headers | head -1) | grep -i "Start Sync update"

Когда появится сообщение “Start Sync update”, пересоздайте один из pod-ов для повторного запуска синхронизации ресурсов с зависимостями ownerReference:

kubectl delete po -n cpaas-system $(kubectl get po -n cpaas-system -l app=etcd-sync --no-headers | head -1)

Проверьте статус синхронизации:

mirror_svc=$(kubectl get svc -n cpaas-system etcd-sync-monitor -o jsonpath='{.spec.clusterIP}')
ipv6_regex="^[0-9a-fA-F:]+$"
if [[ $mirror_svc =~ $ipv6_regex ]]; then
  export mirror_new_svc="[$mirror_svc]"
else
  export mirror_new_svc=$mirror_svc
fi
curl $mirror_new_svc/check

Объяснение вывода:

• LOCAL ETCD missed keys: Ключи есть в основном кластере, но отсутствуют в резервном. Часто вызвано GC из-за порядка ресурсов при синхронизации. Перезапустите один Pod etcd-sync для исправления;
• LOCAL ETCD surplus keys: Лишние ключи есть только в резервном кластере. Перед удалением этих ключей из резервного кластера согласуйте с командой эксплуатации.

Если установлены следующие компоненты, перезапустите их сервисы:

• Log Storage для Elasticsearch:

  kubectl delete po -n cpaas-system -l service_name=cpaas-elasticsearch

• Monitoring для VictoriaMetrics:

  kubectl delete po -n cpaas-system -l 'service_name in (alertmanager,vmselect,vminsert)'

#Процесс восстановления после катастрофы

1. При необходимости перезапустите Elasticsearch в резервном кластере:

   # Скопируйте installer/res/packaged-scripts/for-upgrade/ensure-asm-template.sh в /root:
   # НЕ пропускайте этот шаг
   
   # при необходимости переключитесь на пользователя root
   sudo -i
   
   # проверьте, установлен ли Log Storage для Elasticsearch в глобальном кластере
   _es_pods=$(kubectl get po -n cpaas-system | grep cpaas-elasticsearch | awk '{print $1}')
   if [[ -n "${_es_pods}" ]]; then
       # Если скрипт вернул ошибку 401, перезапустите Elasticsearch
       # затем выполните скрипт для повторной проверки кластера
       bash /root/ensure-asm-template.sh
   
       # Перезапустите Elasticsearch
       xargs -r -t -- kubectl delete po -n cpaas-system <<< "${_es_pods}"
   fi

2. Проверьте согласованность данных в резервном кластере (та же проверка, что и в Шаге 3);

3. Удалите плагин синхронизации etcd;

4. Уберите перенаправление порта 2379 с обоих VIP;

5. Переключите DNS домена платформы на резервный VIP, который теперь становится основным кластером;

6. Проверьте разрешение DNS:

   kubectl exec -it -n cpaas-system deployments/sentry -- nslookup <platform access domain>
   # Если разрешение некорректно, перезапустите Pod-ы coredns и повторяйте до успеха

7. Очистите кэш браузера и зайдите на страницу платформы, чтобы убедиться, что она отражает бывший резервный кластер;

8. Перезапустите следующие сервисы (если установлены):

   • Log Storage для Elasticsearch:

     kubectl delete po -n cpaas-system -l service_name=cpaas-elasticsearch

   • Monitoring для VictoriaMetrics:

     kubectl delete po -n cpaas-system -l 'service_name in (alertmanager,vmselect,vminsert)'

   • cluster-transformer:

     kubectl delete po -n cpaas-system -l service_name=cluster-transformer

9. Если рабочие кластеры отправляют данные мониторинга в основной, перезапустите warlock в рабочем кластере:

   kubectl delete po -n cpaas-system -l service_name=warlock

10. На исходном основном кластере повторите шаги из раздела Включение синхронизации etcd, чтобы преобразовать его в новый резервный кластер.

#Регулярные проверки

Регулярно проверяйте статус синхронизации в резервном кластере:

curl $(kubectl get svc -n cpaas-system etcd-sync-monitor -o jsonpath='{.spec.clusterIP}')/check

Если обнаружены отсутствующие или лишние ключи, следуйте инструкциям в выводе для их устранения.

#Загрузка пакетов

Подробности по подкоманде violet push см. в разделе Upload Packages.