Масштабирование кластеров Azure Service Fabric

  • Статья

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

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

Свертывание и развертывание (горизонтальное масштабирование)

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

  • Преимущества: теоретически бесконечные возможности масштабирования. Если приложение предназначено для обеспечения масштабируемости, можно увеличивать размер без ограничений путем добавления дополнительных узлов. Инструментарий в облачных средах позволяет легко добавлять и удалять узлы, поэтому можно легко изменить емкость и платить только за используемые ресурсы.
  • Недостатки: приложения должны быть предназначены для масштабируемости. В связи с этим может также потребоваться дополнительная работа с архитектурой для баз данных приложений и обеспечения сохраняемости. Однако надежные коллекции в службах Service Fabric с отслеживанием состояния значительно упрощают масштабирование данных приложения.

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

При масштабировании кластера Azure учитывайте следующие рекомендации:

  • Типы первичного узла, выполняющие производственные рабочие нагрузки, должны всегда иметь пять или более узлов.
  • Типы вторичного узла, выполняющие производственные рабочие нагрузки с отслеживанием состояния, должны всегда иметь пять или более узлов.
  • Типы вторичного узла, выполняющие производственные рабочие нагрузки без отслеживания состояния, должны всегда иметь два или больше узлов.
  • Любой тип узла с уровнем устойчивости Gold или Silver всегда должен иметь пять или более узлов.
  • Не удаляйте случайные экземпляры виртуальных машин или узлов из типа узла. Всегда используйте функцию горизонтального уменьшения масштаба масштабируемого набора виртуальных машин. Удаление случайных экземпляров виртуальных машин может отрицательно сказаться на возможности системы распределять нагрузку.
  • При использовании правил автоматического масштабирования настройте такие правила, чтобы уменьшение масштаба (удаление экземпляров виртуальной машины) выполнялось по одному узлу за раз. Одновременно уменьшать масштаб более одного экземпляра небезопасно.

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

Программное масштабирование

В большинстве сценариев масштабирование кластера вручную или с помощью правил автомасштабирования — это оптимальное решение. В более сложных сценариях такие подходы неприемлемы. К их потенциальным недостаткам относятся следующие:

  • При масштабировании вручную необходимо войти в систему и явным образом запросить операции масштабирования. Если операции масштабирования нужно выполнять часто или в непредвиденные моменты, этот подход может оказаться не лучшим решением.
  • Если правила автомасштабирования удаляют экземпляр из масштабируемого набора виртуальных машин, они не удаляют автоматически сведения об этом узле из связанного кластера Service Fabric, за исключением случаев, когда тип узла имеет уровень устойчивости Silver или Gold. Правила автомасштабирования работают на уровне масштабируемого набора (а не на уровне Service Fabric), поэтому они могут удалять узлы Service Fabric без корректного завершения их работы. При таком грубом удалении узла остается фантомное состояние узла Service Fabric после операций уменьшения масштаба. Ответственное лицо (или служба) должно время от времени очищать состояние удаленных узлов из кластера Service Fabric.
  • Тип узла с уровнем надежности Gold или Silver автоматически очищает удаленные узлы, поэтому дополнительная очистка не требуется.
  • Правила автомасштабирования поддерживают многие метрики, но их число все еще ограниченно. Если в вашем сценарии требуется масштабирование на основе метрики, которой нет в этом наборе, правила автомасштабирования могут оказаться не самым подходящим вариантом.

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

Существуют API-интерфейсы Azure, позволяющие приложениям программно управлять масштабируемыми наборами виртуальных машин и кластерами Service Fabric. Если существующие параметры автомасштабирования не выполняются для вашего сценария, эти API-интерфейсы позволяют реализовать настраиваемую логику масштабирования.

Один из способов реализации этой "самодельной" функции автомасштабирования заключается в добавлении новой службы без отслеживания состояния в приложение Service Fabric для управления масштабированием. Создание собственной службы масштабирования обеспечивает максимальный уровень контроля и настройки через поведение масштабирования приложения. Это может быть полезно для сценариев, требующих точного контроля над временем или способом масштабирования приложения. Однако такой способ контроля обычно увеличивает сложность кода. Для использования такого подхода нужен собственный нестандартный код масштабирования. В рамках метода RunAsync службы набор триггеров может определить, требуется ли масштабирование (включая проверку таких параметров, как максимальный размер кластера и время ожидания следующей операции масштабирования).

API-интерфейс, использующийся для взаимодействий в масштабируемом наборе виртуальных машин (для проверки и изменения текущего количества экземпляров виртуальных машин), является свободной библиотекой вычислений для управления Azure. Свободная библиотека вычислений предоставляет простой в использовании API-интерфейс для взаимодействия с масштабируемыми наборами виртуальных машин. Для взаимодействия с кластером Service Fabric используется класс System.Fabric.FabricClient.

Код масштабирования не должен выполняться как служба в кластере, который нужно масштабировать. Как IAzure, так и FabricClient могут удаленно подключаться к связанным ресурсам Azure, поэтому службой масштабирования вполне может быть консольное приложение или служба Windows, которая выполняется за пределами приложения Service Fabric.

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

Увеличение и уменьшение масштаба (вертикальное масштабирование)

При таком масштабировании изменяются ресурсы (ЦП, память и хранилище) узлов кластера.

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

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

При масштабировании кластера Azure учитывайте следующие рекомендации:

  • При уменьшении масштаба типа первичного узла никогда не следует задавать значение ниже, чем допускается уровнем надежности.

Процесс вертикального масштабирования типа узла отличается в зависимости от типа узла: вторичный или первичный.

Масштабирование типов вторичных узлов

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

Масштабирование типа первичного узла

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

Если это невозможно, создайте кластер и восстановите состояние приложения (если это применимо) из старого кластера. Не нужно восстанавливать состояния службы системы, так как при развертывании приложений в новом кластере они будут созданы заново. Если приложения в кластере выполнялись без отслеживания состояния, достаточно развернуть их в новом кластере. Восстановление выполнять не нужно.

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