Рекомендации по планированию загрузки кластера Service Fabric
Планирование емкости кластера важно для каждой рабочей среды Service Fabric. Обязательно учесть следующее.
Начальное число и свойства типов узлов кластера
Уровень устойчивости каждого типа узла, который определяет привилегии виртуальной машины Service Fabric в инфраструктуре Azure.
Уровень надежности кластера, который определяет стабильность системных служб Service Fabric и общей функции кластера.
В этой статье подробно рассматриваются важные моменты для каждой из этих областей.
Начальное число и свойства типов узлов кластера
Тип узла определяет размер, количество и свойства набора узлов (виртуальных машин) в кластере. Каждый тип узла, определенный в кластере Service Fabric, сопоставляется c масштабируемым набором виртуальных машин.
Так как каждый тип узла — это отдельный масштабируемый набор, он поддерживает возможность независимого увеличения или уменьшения масштаба, имеет разные наборы открытых портов и собственные метрики емкости. Дополнительные сведения о связи между типами узлов и масштабируемыми наборами виртуальных машин см. в статье Типы узлов кластера Service Fabric.
Для каждого кластера требуется один Тип первичного узла, который запускает важные системные службы, предоставляющие возможности платформы Service Fabric. Хотя для запуска приложений можно также использовать типы первичных узлов, рекомендуется выделить их исключительно под запуск системных служб.
Типы узлов, отличные отprimary, можно использовать для определения ролей приложений (таких как интерфейсные и внутренние службы) и физической изоляции служб в кластере. Кластеры Service Fabric могут иметь ноль или более типов узлов, отличных отprimary.
В шаблоне Azure Resource Manager основной тип узла настраивается с помощью атрибута isPrimary в определении типа узла. Полный список свойств типа узла см. в Объекте NodeTypeDescription. Например, откройте любой файл AzureDeploy.json в примерах кластера Service Fabric и найдите на странице поиск по объекту nodeTypes.
Рекомендации относительно планирования типов узлов
Количество начальных типов узлов зависит от цели кластера и приложений и служб, работающих на нем. Оцените следующие вопросы.
Есть ли у вашего приложения несколько служб, среди которых есть службы, которые должны быть общедоступными или доступными из Интернета?
Типичные приложения содержат интерфейсную службу шлюза, которая получает входные данные от клиента, и одну или несколько внутренних служб, взаимодействующих с интерфейсными службами, с отдельной сетью между интерфейсными службами и службами серверной части. В таких случаях обычно требуется три типа узлов: один тип первичного узла и два типа узлов, отличных отprimary (по одному для передней и серверной службы).
У служб (составляющих приложение) различные требования к инфраструктуре, например одной из них необходимо больше ОЗУ или тактов центрального процессора?
Часто интерфейсная служба может выполняться на виртуальных машинах меньшего размера (например, 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 только для нагрузок без учета состояния. Для рабочих нагрузок рекомендуется использовать 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) со следующими параметрами:
- По крайней мере 2 ядра.
- Не менее 50 ГБ локального SSD. Однако для некоторых рабочих нагрузок, таких как запущенные контейнеры Windows, требуются более крупные диски.
По умолчанию для локального диска SSD настроен объем 64 ГБ. Размер можно настроить в параметре MaxDiskQuotaInMB раздела диагностики параметров кластера.
Инструкции по регулировке параметров кластера, размещенного в Azure, см. в статье Обновление конфигурации кластера в Azure.
Инструкции по регулировке параметров изолированного кластера, размещенного в Windows, см. в статье Обновление конфигурации изолированного кластера.
При выборе других размеров виртуальных машин для рабочих нагрузок учитывайте следующие ограничения.
- Размеры частичных или отдельных ядер виртуальных машин, таких как Standard A0, не поддерживаются.
- Размеры виртуальных машин серии A не поддерживаются по соображениям производительности.
- Низкоприоритетные виртуальные машины не поддерживаются.
- Номера SKU с возможностью ускорения серии B не поддерживаются.
Тип первичного узла
Для рабочих нагрузок в Azure требуется как минимум пять первичных узлов (экземпляров виртуальных машин) и уровень надежности Silver. Рекомендуется назначать первичные узлы кластеров системным службам и использовать ограничения расположения при развертывании приложения на вторичные узлы.
Тестовые рабочие нагрузки в Azure могут запускать как минимум один или три основных узла. Чтобы настроить кластер одного узла, убедитесь, что reliabilityLevel параметр опущен в шаблоне Resource Manager (указание пустого строкового значения недостаточно reliabilityLevel ). Если одноузловой кластер настраивается через портал Azure, то конфигурация задается автоматически.
Предупреждение
Кластеры с одним узлом выполняются с специальной конфигурацией без надежности и где горизонтальное масштабирование не поддерживается.
Типы узлов, отличных отprimary
Минимальное количество узлов для типа узла, отличного от типа узла, зависят от конкретного уровня устойчивости типа узла. Необходимо спланировать количество узлов (и уровень устойчивости) в зависимости от числа реплик приложений или служб, которые вы хотите запустить для типа узла, и в зависимости от того, с отслеживанием состояния или без него производится Рабочая нагрузка. Помните, что количество виртуальных машин в типе узла можно увеличить или уменьшить в любое время после развертывания кластера.
Рабочие нагрузки с отслеживанием состояния
Для рабочих нагрузок с отслеживанием состояния, использующих надежные коллекции Service Fabric или надежных субъектов, рекомендуется использовать минимальное и целевое число реплик, равное пяти. Это означает, что в стабильном состоянии в каждом домене сбоя и домене обновления будет по реплике (из набора реплик). Используйте уровень надежности, заданный для системных служб, в качестве руководства по количеству реплик, используемых для служб с отслеживанием состояния.
Рабочие нагрузки без отслеживания состояния
Для рабочих нагрузок без отслеживания состояния минимальный поддерживаемый тип узла без отслеживания состояния составляет три для поддержания кворума, однако рекомендуется использовать размер типа узла 5.
Следующие шаги
Перед настройкой кластера проверьте Not Allowed политики обновления кластера, чтобы устранить необходимость повторного создания кластера позже из-за неизменяемых параметров конфигурации системы.
Дополнительные сведения о планировании кластеров см. в следующих статьях.