Масштабирование кластеров 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, используемое для взаимодействия масштабируемого набора виртуальных машин (как для проверки текущего количества экземпляров виртуальных машин, так и для его изменения) — это библиотека Fluent Azure Management Compute. Библиотека плавных вычислений предоставляет удобный API для взаимодействия с масштабируемыми наборами виртуальных машин. Для взаимодействия с самим кластером Service Fabric используйте System.Fabric.FabricClient.

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

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

Масштабирование вверх и вниз или вертикальное масштабирование

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

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

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

При масштабировании кластера Azure помните следующее руководство.

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

Процесс масштабирования типа узла вверх или вниз отличается в зависимости от того, является ли он не первичным или первичным типом узла.

Масштабирование типов узлов, не являющихся первичными

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

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

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

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

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

  • Last updated on