Рекомендации по планированию загрузки кластера Service Fabric

Планирование емкости кластера важно для каждой рабочей среды Service Fabric. Обязательно учесть следующее.

  • Начальное число и свойства типов узлов кластера

  • Уровень устойчивости каждого типа узла, который определяет привилегии виртуальной машины Service Fabric в инфраструктуре Azure.

  • Уровень надежности кластера, который определяет стабильность системных служб Service Fabric и общей функции кластера.

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

Начальное число и свойства типов узлов кластера

Тип узла определяет размер, количество и свойства набора узлов (виртуальных машин) в кластере. Каждый тип узла, определенный в кластере Service Fabric, сопоставляется c масштабируемым набором виртуальных машин.

Так как каждый тип узла — это отдельный масштабируемый набор, он поддерживает возможность независимого увеличения или уменьшения масштаба, имеет разные наборы открытых портов и собственные метрики емкости. Дополнительные сведения о связи между типами узлов и масштабируемыми наборами виртуальных машин см. в статье Типы узлов кластера Service Fabric.

Для каждого кластера требуется один Тип первичного узла, который запускает важные системные службы, предоставляющие возможности платформы Service Fabric. Хотя для запуска приложений можно также использовать типы первичных узлов, рекомендуется выделить их исключительно под запуск системных служб.

Непрямые типы узлов можно использовать для определения ролей приложений (таких как интерфейсные и внутренние службы) и физической изоляции служб в кластере. Кластеры Service Fabric могут иметь ноль или несколько типов узлов, не являющихся привилегированные.

В шаблоне Azure Resource Manager основной тип узла настраивается с помощью атрибута isPrimary в определении типа узла. Полный список свойств типа узла см. в Объекте NodeTypeDescription. Например, откройте любой файл AzureDeploy.json в примерах кластера Service Fabric и найдите на странице поиск по объекту nodeTypes.

Рекомендации относительно планирования типов узлов

Количество начальных типов узлов зависит от назначения кластера, приложений и служб, работающих в нем. Ответьте на следующие вопросы.

  • Есть ли у вашего приложения несколько служб, среди которых есть службы, которые должны быть общедоступными или доступными из Интернета?

    Типичные приложения содержат интерфейсную службу шлюза, которая получает входные данные от клиента, и одну или несколько внутренних служб, взаимодействующих с интерфейсными службами, с отдельной сетью между интерфейсными службами и службами серверной части. В таких случаях обычно требуется три типа узлов: один основной тип узла и два нестандартного типа узлов (по одному для передней и внутренней службы).

  • У служб (составляющих приложение) различные требования к инфраструктуре, например одному необходимо больше ОЗУ или тактов центрального процессора?

    Часто интерфейсная служба может выполняться на виртуальных машинах меньшего размера (например, D2) с портами, открытыми для доступа через Интернет. Ресурсоемкие с вычислительными вычислениями внутренние службы могут потребоваться для работы на более крупных виртуальных машинах (с виртуальными машинами таких размеров, как D4, D6, D15), которые не поддерживают доступ к Интернету. Определение различных типов узлов для этих служб позволяет повысить эффективность и безопасность использования базовых виртуальных машин Service Fabric и дает им возможность масштабироваться независимо друг от друга. Дополнительные сведения об оценке необходимого объема ресурсов см. в разделе Планирование емкости для приложений Service Fabric.

  • Потребуется ли любой из ваших служб приложений масштабироваться за пределами 100 узлов?

    Один тип узла не может надежно масштабировать свыше 100 узлов на каждый масштабируемый набор виртуальных машин для приложений Service Fabric. Для запуска более 100 узлов требуются дополнительные масштабируемые наборы виртуальных машин (и, следовательно, дополнительные типы узлов).

  • Будет ли кластер распределяться по Зонам доступности?

    Service Fabric поддерживает кластеры, охватывающие несколько Зон доступности, развертывая типы узлов, которые закреплены в конкретных зонах, что обеспечивает высокую доступность приложений. Зоны доступности требуют планирования дополнительного типа узла и соблюдения минимальных требований. Дополнительные сведения см. в статье Топология для распределения типов первичных узлов по зонам доступности.

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

Следующее важное свойство типа узла — уровень устойчивости, который определяет привилегии виртуальных машин типа узла в инфраструктуре Azure. Используйте размер виртуальных машин, выбранных для кластера, и число экземпляров, назначаемое для отдельных типов узлов, чтобы определить соответствующий уровень устойчивости для каждого типа узла, как описано далее.

Характеристики устойчивости кластера

Уровень устойчивости определяет привилегии виртуальных машин Service Fabric с базовой инфраструктурой Azure. Эта привилегия позволяет Service Fabric приостановить любой запрос инфраструктуры на уровне виртуальной машины (например, перезагрузку, переcоздание образа или перенос виртуальной машины), который влияет на требования к кворуму, установленные для системных служб Service Fabric и ваших служб с отслеживанием состояния.

Важно!

Уровень устойчивости задается для каждого типа узла. Если заданного уровня нет, будет использоваться Бронзовый уровень. Рабочие нагрузки требуют уровня устойчивости "Silver" или "Gold", чтобы избежать потери данных по запросам инфраструктуры на уровне виртуальной машины.

В следующей таблице перечислены уровни устойчивости Service Fabric, их требования и аффордансы.

Уровень устойчивости Необходимое минимальное количество виртуальных машин Поддерживаемые размеры виртуальных машин Изменения, вносимые в масштабируемый набор виртуальных машин Обновления и обслуживание, инициированные Azure
Золотая 5 Полные размеры узлов, выделенные для одного клиента — доступные размеры виртуальных машин Можно отложить до утверждения кластером Service Fabric Можно приостановить на 2 часа для обновления домена, чтобы предоставить репликам дополнительное время на восстановление после сбоев, произошедших ранее
Серебряная 5 Виртуальные машины с одним ядром или более, оснащенные локальным диском SSD по крайней мере на 50 ГБ Можно отложить до утверждения кластером Service Fabric Не может быть отложен на какой-либо значительный период времени
Бронзовая 1 Виртуальные машины с локальным SSD по крайней мере на 50 ГБ Не будет задержано кластером Service Fabric Не может быть отложен на какой-либо значительный период времени

Примечание

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

Предупреждение

При использовании уровня устойчивости "бронзовый" автоматическое обновление образа ОС недоступно. Так как Приложение для оркестрации исправлений (предназначенное только для кластеров, не размещаемых в Azure) для уровней устойчивости "серебряный" и выше не рекомендуется, вам остается единственный вариант — настроить автоматическое обновление Windows для доменов обновления Service Fabric.

Важно!

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

Бронзовая

Типы узлов, выполняющиеся с устойчивостью Bronze, не получают привилегий. Это означает, что задания инфраструктуры, которые влияют на рабочие нагрузки с отслеживанием состояния, не будут остановлены или отложены. Используйте уровень устойчивости Bronze только для нагрузок без учета состояния. Для рабочих нагрузок рекомендуется использовать Silver или более высокий уровень.

Silver и Gold

Используйте уровни устойчивости Silver или Gold для всех типов узлов со службами с отслеживанием состояния, предполагающими частое масштабирование, если вы хотите отложить операции развертывания и уменьшить емкость за счет упрощения процесса. Сценарии горизонтального увеличения масштаба не должны влиять на выбор уровня устойчивости.

Преимущества

  • Сокращение обязательных действий в операции свертывания (т. е. деактивация узла и Remove-ServiceFabricNodeState вызываются автоматически).
  • Снижается риск потери данных из-за операций изменения размера виртуальной машины на месте и операций инфраструктуры Azure.

Недостатки

  • Развертывания в масштабируемый набор виртуальных машин и другие связанные ресурсы Azure могут быть задержаны, отложены или полностью заблокированы из-за проблем в кластере или на уровне инфраструктуры.
  • Увеличивается число событий жизненного цикла реплики (например, переключений первичного узла) из-за автоматизированной деактивации узлов во время операций инфраструктуры Azure.
  • Узлы становятся недоступны в периоды обновления программного обеспечения платформы Azure или обслуживания оборудования. Во время этих операций вы можете видеть узлы в состоянии "Идет отключение" или "Отключено". Это временно снижает емкость кластера, но не влияет на доступность кластера или приложений.

Рекомендации для типов узлов категории Silver и Gold

Следуйте приведенным ниже рекомендациям по управлению типами узлов с уровнями устойчивости Silver или Gold

  • Поддерживайте постоянную работоспособность кластера и приложений и проверяйте, своевременно ли реагируют приложения на все события жизненного цикла реплики службы (например, задержку сборки реплики).
  • Используйте более безопасные способы изменения размера виртуальной машины (масштабирования). Изменение размера виртуальной машины из масштабируемого набора виртуальных машин требует тщательного планирования и осторожности. Дополнительные сведения см. в статье Масштабирование типа узла Service Fabric.
  • Обеспечьте как минимум пять узлов для любого масштабируемого набора виртуальных машин с уровнем устойчивости Gold или Silver. Кластер перейдет в состояние ошибки при масштабировании ниже этого порогового значения, и вам потребуется вручную очистить состояние (Remove-ServiceFabricNodeState) для удаленных узлов.
  • Каждый масштабируемый набор виртуальных машин с уровнем устойчивости Silver или Gold должен быть сопоставлен с собственным типом узла в кластере Service Fabric. Сопоставление нескольких масштабируемых наборов виртуальных машин в одном типе узла сделает невозможным координацию между кластером Service Fabric и инфраструктурой Azure.
  • Не удаляйте случайные экземпляры виртуальных машин. Всегда используйте масштабирование масштабируемого набора виртуальных машин в компоненте . Удаление случайных экземпляров виртуальной машины может нарушить баланс в распределении экземпляров виртуальной машины в домене обновления и домене сбоя. Этот дисбаланс может негативно повлиять на возможность системы правильно распределять нагрузку между экземплярами служб или репликами служб.
  • При использовании автомасштабирования установите правила таким образом, чтобы горизонтальное уменьшение масштаба (удаление экземпляров виртуальной машины) выполнялось одновременно только на одном узле. Масштабирование в нескольких экземплярах за раз небезопасно.
  • При удалении или отмене выделения виртуальных машин на типе основного узла никогда не следует уменьшать количество выделенных виртуальных машин до уровня ниже требований уровня надежности. Эти операции будут заблокированы на неограниченное время в масштабируемом наборе с уровнем устойчивости Silver или Gold.

Изменение уровней надежности

В некоторых ограничениях можно настроить уровень устойчивости типа узла:

  • Для типов узлов Silver или Gold нельзя изменить уровни устойчивости на Bronze
  • Понижение уровня узлов с уровнем устойчивости Gold до Silver не поддерживается.
  • Обновление с Bronze до Silver или Gold может занять несколько часов.
  • Изменяя уровень устойчивости, не забудьте обновить его в конфигурации расширения Service Fabric в ресурсе масштабируемого набора виртуальных машин и определении типа узла в ресурсе кластера Service Fabric. Эти значения должны совпадать.

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

Характеристики надежности кластера

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

Важно!

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

Уровень надежности может принимать следующие значения:

  • Platinum: запуск системных служб с целевым набором из 9 реплик.
  • Gold: запуск системных служб с целевым набором из 7 реплик.
  • Silver: запуск системных служб с целевым набором из 5 реплик.
  • Bronze: запуск системных служб с целевым набором из 3 реплик.

Ниже приведена рекомендация по выбору уровня надежности. Число начальных узлов также задается равным минимальному количеству узлов для уровня надежности.

Количество узлов Уровень надежности
1 Не указывайте reliabilityLevel параметр: система вычисляет его.
3 Бронзовая
5 или 6 Серебряная
7 или 8 Золотая
9 и более Platinum

При увеличении или уменьшении размера кластера (суммы экземпляров виртуальных машин во всех типах узлов) необходимо изменить уровень надежности кластера с одного на другой. Это активирует обновления кластера, необходимые для изменения числа реплик системных служб. Подождите, пока обновление не будет завершено, прежде чем вносить другие изменения в кластер, например добавлять узлы. Ход выполнения обновления можно отслеживать в Service Fabric Explorer или с помощью командлета Get-ServiceFabricClusterUpgrade.

Планирование емкости для обеспечения надежности

Требования к емкости кластера определяются конкретной рабочей нагрузкой и требованиями к надежности. В этом разделе приводятся общие рекомендации по началу работы с планированием ресурсов.

Размеры виртуальных машин

Для производственных рабочих нагрузок рекомендуемый размер виртуальной машины (SKU) — стандартный D2_V2 (или эквивалентный) с локальным SSD минимум на 50 ГБ, 2 ядра и 4 Гб памяти. Рекомендуется использовать не менее 50 ГБ локального SSD, однако для некоторых рабочих нагрузок (таких как работающие контейнеры Windows) потребуются диски большей емкости.

По умолчанию для локального диска SSD настроен объем 64 ГБ. Размер можно настроить в параметре MaxDiskQuotaInMB раздела Диагностика параметров кластера.

Инструкции по регулировке параметров кластера, размещенного в Azure, см. в статье Обновление конфигурации кластера в Azure.

Инструкции по регулировке параметров изолированного кластера, размещенного в Windows, см. в статье Обновление конфигурации изолированного кластера.

При выборе других размеров виртуальных машин для рабочих нагрузок учитывайте следующие ограничения.

  • Частичные и одноядерные виртуальные машины, такие как стандартный A0, не поддерживаются.
  • Серия A Размеры виртуальных машин не поддерживаются по соображениям производительности.
  • Низкоприоритетные виртуальные машины не поддерживаются.
  • Номера SKU с поддержкой ускорения серии B не поддерживаются.

Тип первичного узла

Для рабочих нагрузок в Azure требуется как минимум пять первичных узлов (экземпляров виртуальных машин) и уровень надежности Silver. Рекомендуется назначать первичные узлы кластеров системным службам и использовать ограничения расположения при развертывании приложения на вторичные узлы.

Тестовые рабочие нагрузки в Azure могут запускать как минимум один или три основных узла. Чтобы настроить кластер с одним узлом, убедитесь, что reliabilityLevel параметр не указан в шаблоне Resource Manager (достаточно указать пустое строковое значение для reliabilityLevel ). Если одноузловой кластер настраивается через портал Azure, то конфигурация задается автоматически.

Предупреждение

Кластеры с одним узлом выполняются со специальной конфигурацией без надежности, где горизонтальное масштабирование не поддерживается.

типы узлов, не являющиеся привилегированные

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

Рабочие нагрузки с отслеживанием состояния

Для рабочих нагрузок с отслеживанием состояния, использующих надежные коллекции Service Fabric или надежных субъектов, рекомендуется использовать минимальное и целевое число реплик, равное пяти. Это означает, что в стабильном состоянии в каждом домене сбоя и домене обновления будет по реплике (из набора реплик). Используйте уровень надежности, заданный для системных служб, в качестве руководства по количеству реплик, используемых для служб с отслеживанием состояния.

Рабочие нагрузки без отслеживания состояния

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

Дальнейшие действия

Перед настройкой кластера проверьте Not Allowedполитики обновления кластера, чтобы устранить необходимость повторного создания кластера позже из-за неизменяемых параметров конфигурации системы.

Дополнительные сведения о планировании кластеров см. в следующих статьях.