Организации, предъявляющие самые высокие требования к времени безотказной работы, должны быть способны выдерживать более значительные сбои, например, потерю всей зоны доступности (AZ). Хотя инициализация кластера Kubernetes, охватывающего несколько зон доступности (AZ), является несложной задачей для управляемых облачных провайдеров, существуют дополнительные административные требования, которые необходимо учитывать на этапах развертывания, настройки и эксплуатации программного обеспечения ArcGIS Enterprise on Kubernetes.
В следующих разделах описываются соображения, которые необходимо принять во внимание, и требования, которые должны быть выполнены перед настройкой организации, ожидаемые последствия потери функциональности в AZ и то, как администратор может проверить работоспособность базовой системы после восстановления функциональности в этой AZ.
Как минимум, кластер Kubernetes, в котором развернуто приложение, должен отвечать следующим требованиям:
- Группы рабочих узлов охватывают не менее трех зон доступности (AZ).
- Имеется достаточная мощность рабочих узлов для восстановления баланса всех рабочих нагрузок в двух AZ во время простоя.
Развертывание и настройка
При развертывании ArcGIS Enterprise on Kubernetes в кластере с несколькими AZ наличие рабочих нагрузок с отслеживанием состояния означает, что при использовании блочных устройств хранения существует зависимость соответствующих дисков от AZ.
Чтобы соответствующие реплики каждого StatefulSet были распределены по соответствующей топологии, в файл свойств развертывания введено новое свойство K8S_AVAILABILITY_TOPOLOGY_KEY, которое необходимо обновить перед запуском скрипта развертывания. Обновление этого свойства до значения, отличного от kubernetes.io/hostname, приведет к появлению спецификации topologySpreadConstraint в наборах StatefulSet, которая гарантирует, что у нас не будет неравного баланса или реплик в какой-либо одной AZ. Ключом к метке узла AZ у большинства облачных провайдеров является topology.kubernetes.io/zone.
При настройке организации, чтобы гарантировать максимальную доступность, настройте организацию с использованием архитектурного профиля повышенной доступности. Это единственный профиль, который гарантирует адекватное покрытие всех рабочих нагрузок с отслеживанием состояния в случае отказа AZ.
Даже при использовании архитектурного профиля повышенной доступности существует ряд развертываний, которые остаются на уровне одной реплики, поскольку они сильно различаются в зависимости от требований конкретной организации. Рассмотрите следующие варианты развертывания для масштабирования выше одной реплики, чтобы дополнительно сократить время простоя:
- arcgis-enterprise-apps
- arcgis-enterprise-manager
- arcgis-enterprise-portal
- arcgis-enterprise-web-style-app
- arcgis-help
- arcgis-javascript-api
- arcgis-service-api
- arcgis-service-lifecycle-manager
- arcgis-featureserver-webhook-processor
- arcgis-gpserver-webhook-processor
Все перечисленные выше развертывания, кроме arcgis-enterprise-web-style-app, требуют меньшего времени для перезапуска после потери AZ по сравнению с процессом восстановления работоспособности реляционного хранилища данных. Масштабирование на дополнительную реплику всех перечисленных развертываний добавляет примерно 1 дополнительный CPU и 0,5 Гбайта дополнительной оперативной памяти к общему количеству запросов к пространству имен и 5 дополнительных CPU и 2,5 Гбайта дополнительной оперативной памяти к общему количеству ограничений пространства имен.
При публикации сервисов настройте для всех выделенных сервисов запуск как минимум двух модулей, чтобы исключить перерывы в работе при перепланировании. Масштабируйте развертывания общего экземпляра как минимум до двух реплик для той же цели.
Последствия потери зоны доступности
Значение и последствия потери AZ различаются в зависимости от того, какие облачные сервисы затронуты. Потеря конкретного сервиса, например вычислительного или хранилища, может оказать существенное влияние на выполняемые рабочие нагрузки, в то время как другие сетевые сбои, такие как разрешение DNS или резкое увеличение задержки, могут повлиять на взаимодействие микросервисов друг с другом.
Во время аварийного восстановления реляционного хранилища для некоторых функций, таких как вход в систему, редактирование размещенных сервисов объектов и загрузка размещенных слоев, может быть на короткое время снижена производительность. Когда резервный экземпляр будет переведен в основной, все функциональные возможности организации должны вернуться в стабильное состояние.
Верификация работоспособности организации
Администраторы могут использовать интегрированные отчеты по проверке работоспособности, чтобы оценить работоспособность своего сайта. Они также могут проанализировать рабочую нагрузку пространства имен на предмет проблем с запуском модулей и других трудностей, которые могут возникать.
При отключении зоны доступности
Если при использовании блочного хранилища для PV зона доступности (AZ) будет потеряна, то модули statefulset не смогут быть перепланированы в другие AZ из-за требований к сходству томов.
Для тех хранилищ данных, которым это необходимо, поддерживается кворум, чтобы соответствующие сервисы могли функционировать в состоянии пониженной производительности. Поскольку реляционное хранилище является основным компонентом, от которого зависят несколько других сервисов, режим ожидания можно сбросить с помощью Admin API. Это приведет к удалению набора statefulset и связанного с ним PVC и созданию нового набора statefulset. Это позволяет резервному экземпляру повторно синхронизироваться с основным после появления в одной из оставшихся AZ.
После отключения зоны доступности
Если в AZ, где произошел сбой, восстановлены сервисы, перезапустите соответствующие рабочие нагрузки, которые находились в состоянии ожидания, что можно подтвердить с помощью Kubernetes API.
Если сервисы не удается восстановить в существующей AZ, убедитесь, что в кластере осталось как минимум три AZ. Если это не так, расширьте кластер на дополнительную AZ. После этого создайте резервную копию, выполните деинсталляцию и повторную установку, а затем выполните операцию восстановления из резервной копии.