Поделиться через

Контрольный список готовности рабочей среды

  • Статья

Готовы ли ваше приложение и кластер к приему рабочего трафика? Запуск и тестирование приложения и кластера не обязательно означает, что они готовы к перемещению в рабочую среду. Обеспечьте бесперебойную работу приложения и кластера, выполнив следующий контрольный список. Мы настоятельно рекомендуем выполнить все его пункты. Разумеется, вы можете использовать альтернативные решения для какого-либо пункта (например, собственные платформы диагностики).

Предварительные требования для рабочей среды

  1. Рекомендации по работе с Azure Service Fabric: проектирование приложений, безопасность, работа в сети, планирование и масштабирование ресурсов, инфраструктура как код и мониторинг и диагностика.
  2. Настройте параметры FabricTransport, если вы используете модель программирования Reliable Actors и нуждаетесь в безопасном взаимодействии между службами.
  3. Для кластеров с более чем 20 ядрами или 10 узлами создайте выделенный тип основного узла для системных служб. Добавьте ограничения размещения, чтобы зарезервировать тип основного узла для системных служб.
  4. Используйте номер SKU D2v2 или выше для типа основного узла. Рекомендуется выбрать номер SKU с емкостью диска по меньшей мере 50 ГБ.
  5. Рабочие кластеры должны быть защищены. Примером настройки безопасного кластера может послужить этот шаблон кластера. Используйте общие имена сертификатов и старайтесь не использовать самозаверяющие сертификаты.
  6. Добавьте ограничения ресурсов для контейнеров и служб таким образом, чтобы они не занимали более 75 % ресурсов узла.
  7. Изучите и задайте уровень устойчивости. Уровень устойчивости Silver или выше рекомендуется использовать для типов узлов, на которых выполняются рабочие нагрузки с отслеживанием состояния. Он является необходимым для рабочей среды.
  8. Изучите и выберите уровень надежности типа узла. Для рабочей среды рекомендуется использовать уровень надежности Silver или более высокий.
  9. Протестируйте загрузку и масштабирование своих рабочих нагрузок, чтобы определить требования к емкости кластера.
  10. Службы и приложения отслеживаются, также создаются и сохраняются журналы приложений. При этом могут создаваться оповещения. Пример приведен в разделах Добавление ведения журнала в приложение Service Fabric и Мониторинг контейнеров с помощью журналов Log Analytics.
  11. Для мониторинга кластера используются оповещения (например, посредством журналов Log Analytics).
  12. Для мониторинга базовой инфраструктуры масштабируемого набора виртуальных машин также используются оповещения (например, посредством журналов Log Analytics).
  13. В кластере всегда есть основные и дополнительные сертификаты (то есть вы не будете заблокированы).
  14. Используйте разные кластеры для среды разработки, промежуточной среды и рабочей среды.
  15. Обновления приложений и обновления кластера следует сначала проверить на кластерах разработки и промежуточных кластерах.
  16. Отключите автоматические обновления на рабочих кластерах и включите их на кластерах разработки и промежуточных кластерах (при необходимости можно выполнить откат).
  17. Установите целевую точку восстановления (RPO) для службы, а также настройте процесс аварийного восстановления и протестируйте его.
  18. Запланируйте масштабирование кластера вручную или программным способом.
  19. Запланируйте установку исправлений на узлах кластера.
  20. Установите конвейер CI/CD, чтобы последние внесенные изменения постоянно проверялись. Например, можно использовать Azure DevOps или Jenkins.
  21. Выполните нагрузочное тестирование кластеров разработки и промежуточных кластеров с помощью службы анализа сбоев и вызовите управляемый хаос.
  22. Запланируйте масштабирование приложений.

Если вы используете модель программирования Reliable Services или Reliable Actors в Service Fabric, необходимо выполнить следующие пункты.

  1. Обновляйте приложения во время локальной разработки, чтобы убедиться, что код службы учитывает маркер отмены в методе RunAsync и закрывает пользовательские прослушиватели связи.
  2. Избегайте типичных проблем при использовании Reliable Collections.
  3. Отслеживайте счетчики производительности памяти среды CLR .NET при выполнении нагрузочных тестов. Кроме того, проверяйте наличие высокой частоты сбора мусора или неконтролируемого увеличения размера кучи.
  4. Храните автономные резервные копии Reliable Services и Reliable Actors и проверьте процесс восстановления.
  5. Количество экземпляров виртуальной машины основного NodeType в идеале должно быть равным минимальному значению для уровня надежности кластеров; условия, при которых уместно превышать минимальный уровень: временно при вертикальном масштабировании номера SKU масштабируемого набора виртуальных машин основных NodeType.

Дополнительные рекомендации

Хотя выше перечислены достаточные предварительные требования для переноса в рабочую среду, следует также рассмотреть следующие пункты.

  1. Подключите модель работоспособности Service Fabric, чтобы расширить встроенные возможности оценки работоспособности и создания отчетов.
  2. Разверните пользовательскую службу наблюдения, которая отслеживает приложение и сообщает о загрузке для балансировки ресурсов.

Следующие шаги