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

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

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

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

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

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

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

Необязательные рекомендации

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

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

Дальнейшие шаги