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

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

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

Масштабирование внутрь и наружу, или горизонтальное масштабирование

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

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

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

Удаление узлов может инициировать несколько обновлений. Некоторые узлы помечены тегом IsSeedNode=”true” и могут быть идентифицированы путем запроса манифеста кластера с помощью Get-ServiceFabricClusterManifest. Удаление таких узлов может занять больше времени, чем других, так как в таких сценариях основные узлы должны быть перемещены. Кластер должен поддерживать не менее трех узлов типа первичного узла.

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

Рекомендуется не снизить количество узлов ниже размера кластера уровня надежности для кластера. Это будет препятствовать репликации системных служб Service Fabric в кластере и дестабилизировать или, возможно, уничтожить кластер.

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

  • Замена первичных узлов должна выполняться один узел после другого, а не удалять, а затем добавлять в пакеты.
  • Перед удалением типа узла проверьте наличие узлов, ссылающихся на тип узла. Удалите эти узлы перед удалением соответствующего типа узла. После удаления всех соответствующих узлов можно удалить NodeType из конфигурации кластера и начать обновление конфигурации с помощью Start-ServiceFabricClusterConfigurationUpgrade.

Дополнительные сведения см. в статье о масштабировании автономного кластера.

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

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

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

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

  • Last updated on