увеличение или уменьшение масштаба кластера;
Предупреждение
Прочтите этот раздел, прежде чем выполнять масштабирование
Масштабирование вычислительных ресурсов источника рабочей нагрузки вашего приложения требует преднамеренного планирования. Для разворачивания рабочей среды почти всегда требуется больше часа, поэтому необходимо знать уровень рабочей нагрузки и ее бизнес-контекст. Если вы никогда раньше этого не делали, рекомендуется прочитать и разобраться с рекомендациями по планированию загрузки кластера Service Fabric, прежде чем продолжить чтение оставшейся части этого документа. Эта рекомендация заключается в том, чтобы избежать непреднамеренных проблем с LiveSite, а также рекомендуется успешно протестировать операции, которые вы решите выполнить в нерабочей среде. В любое время вы можете сообщить о производственных проблемах или запросить платную поддержку Azure. В этой статье описываются операции масштабирования для инженеров, выделенных для выполнения этих операций, которые обладают соответствующим контекстом, но вы должны понять, какие операции подходят для вашего случая использования, и принять решение. Здесь речь идет о ресурсах для масштабирования (ЦП, хранилище, память), выборе направления масштабирования (вертикальное или горизонтальное) и операций для выполнения (шаблоны развертывания ресурсов, портал, PowerShell/CLI).
Примечание
Для взаимодействия с Azure рекомендуется использовать модуль Azure Az PowerShell. Чтобы начать работу, см. статью Установка Azure PowerShell. Дополнительные сведения см. в статье Перенос Azure PowerShell с AzureRM на Az.
Масштабирование кластера Service Fabric с помощью правил автомасштабирования или вручную
Наборы масштабирования виртуальных машин относятся к вычислительным ресурсам Azure. Их можно использовать для развертывания коллекции виртуальных машин и управления ею как набором. Каждый тип узла, определенный в кластере Service Fabric, настроен как отдельный набор масштабирования виртуальных машин. Каждый тип узла поддерживает возможность независимого масштабирования, имеет разные наборы открытых портов и собственные метрики емкости. Дополнительные сведения см. в этом документе Типы узлов Service Fabric. Так как типы узлов Service Fabric в вашем кластере состоят из масштабируемых наборов виртуальных машин на сервере, для каждого типа узлов или масштабируемого набора необходимо настроить правила автомасштабирования.
Примечание
Ваша подписка должна включать в себя достаточное количество ядер для добавления виртуальных машин IaaS, которые войдут в состав этого кластера. В настоящее время проверка модели не предусмотрена, поэтому в случае, если лимиты квоты будут нарушены, во время развертывания произойдет сбой.
Примечание
Если вы используете образ ОС Windows со включенной ролью Hyper-V, то есть эта виртуальная машина будет использовать вложенную виртуализацию, метрика доступной памяти будет недоступна, так как драйвер динамической памяти на виртуальной машине будет находиться в остановленном состоянии.
Выбор типа узла или масштабируемого набора виртуальных машин для масштабирования
Сейчас настроить правила автомасштабирования для масштабируемых наборов виртуальных машин с помощью портала для создания кластера Service Fabric нельзя, поэтому мы используем Azure PowerShell (версии 1.0 или более поздней), чтобы получить список типов узлов и добавить к ним правила автомасштабирования.
Чтобы получить список масштабируемых наборов виртуальных машин в составе кластера, выполните следующие командлеты:
Get-AzResource -ResourceGroupName <RGname> -ResourceType Microsoft.Compute/VirtualMachineScaleSets
Get-AzVmss -ResourceGroupName <RGname> -VMScaleSetName <virtual machine scale set name>
Настройка правил автомасштабирования для типа узла или масштабируемого набора виртуальных машин
Если кластер содержит несколько типов узлов, то эту процедуру необходимо выполнить для каждого типа узла или масштабируемого набора виртуальных машин, который нужно масштабировать. Перед настройкой автомасштабирования обратите внимание на необходимое количество узлов. Минимальное количество узлов, необходимое для основного типа узлов, зависит от выбранного уровня надежности. См. дополнительные сведения об уровнях надежности.
Примечание
Уменьшение масштаба типа основного узла до уровня ниже минимального приведет к нестабильности или выходу кластера из строя. Это может вызвать потерю данных в приложениях или системных службах.
В настоящее время функция автомасштабирования не зависит от уровня нагрузки, который приложения сообщают Service Fabric. В связи с этим автомасштабирование регулируется исключительно счетчиками производительности, которые отправляются каждым экземпляром масштабируемого набора виртуальных машин.
Настройте автомасштабирование для каждого масштабируемого набора виртуальных машин согласно этим инструкциям.
Примечание
Если тип узла имеет уровень устойчивости Gold или Silver, то в сценарии уменьшения масштаба необходимо вызывать командлет Remove-ServiceFabricNodeState с именем соответствующего узла. Для уровня устойчивости Bronze не рекомендуется выполнять масштабирование более одного узла за раз.
Добавление виртуальных машин к типу узла или в масштабируемый набор виртуальных машин вручную
При развертывании вы добавляете дополнительные экземпляры виртуальных машин в масштабируемый набор. Эти экземпляры становятся узлами, которые использует Service Fabric. Службе Service Fabric известно, когда в масштабируемый набор добавляются экземпляры (путем развертывания), и она реагирует автоматически.
Примечание
Добавление виртуальных машин занимает некоторое время, поэтому не ожидайте, что они будут добавлены мгновенно. Планируйте добавления емкости и учитывайте, что прежде чем емкость виртуальной машины станет доступна для размещения реплик или экземпляров службы, пройдет не меньше 10 минут.
Добавление виртуальных машин с помощью шаблона
Выберите пример из коллекции шаблонов быстрого запуска и следуйте прилагающимся инструкциям, чтобы изменить количество виртуальных машин по каждому типу узла.
Добавление виртуальных машин с помощью PowerShell или команд интерфейса командной строки
Следующий код получает масштабируемый набор по имени и увеличивает значение емкости масштабируемого набора на 1.
$scaleset = Get-AzVmss -ResourceGroupName SFCLUSTERTUTORIALGROUP -VMScaleSetName nt1vm
$scaleset.Sku.Capacity += 1
Update-AzVmss -ResourceGroupName $scaleset.ResourceGroupName -VMScaleSetName $scaleset.Name -VirtualMachineScaleSet $scaleset
Этот код задает значение 6 для емкости.
# Get the name of the node with
az vmss list-instances -n nt1vm -g sfclustertutorialgroup --query [*].name
# Use the name to scale
az vmss scale -g sfclustertutorialgroup -n nt1vm --new-capacity 6
Удаление виртуальных машин из типа узла или масштабируемого набора виртуальных машин вручную
При масштабировании типа узла вы удаляете экземпляры виртуальных машин из масштабируемого набора. Если тип узла является уровнем устойчивости Bronze, Service Fabric не знает, что произошло, и сообщает, что узел отсутствовал. Затем Service Fabric сообщает о неработоспособном состоянии кластера. Чтобы предотвратить это неправильное состояние, необходимо явно удалить узел из кластера и удалить состояние узла.
Системные службы Service Fabric запускаются в кластере на узле основного типа. При масштабировании запрещается уменьшать количество экземпляров в типе основного узла ниже значения, которое гарантирует соответствующий уровень надежности.
Для службы с отслеживанием состояния необходимо определенное количество узлов, которые постоянно доступны и работают, чтобы поддерживать доступность этой службы и сохранять ее состояние. Требуется как минимум количество узлов, равное количеству целевых наборов реплик секции или службы.
Удаление узла Service Fabric
Действия по удалению состояния узла вручную применяются только к типам узлов с уровнем устойчивости Bronze. Для уровней устойчивости Silver и Gold эти действия платформа выполняет для вас автоматически. Дополнительные сведения об устойчивости см. в разделе Характеристики устойчивости кластера.
Примечание
Обеспечьте как минимум пять узлов для любого масштабируемого набора виртуальных машин с уровнем устойчивости Gold или Silver. Кластер будет переходить в состояние ошибки, если масштаб меньше этого порогового значения, и потребуется вручную очистить удаленные узлы.
Чтобы обеспечить равномерное распределение узлов кластера между доменами сбоя и обновления, включив тем самым их сбалансированное использование, необходимо сначала удалить последний созданный узел. Другими словами, необходимо удалить узлы в порядке, обратном порядку их создания. Последний созданный узел — это узел с максимальным значением свойства virtual machine scale set InstanceId. В примерах кода ниже возвращается последний созданный узел.
Get-ServiceFabricNode | Sort-Object NodeInstanceId -Descending | Select-Object -First 1
sfctl node list --query "sort_by(items[*], &name)[-1]"
Кластеру Service Fabric необходимо сообщить, что этот узел будет удален. Для этого нужно выполнить три шага:
Отключить узел, чтобы он больше не использовался для репликации данных.
PowerShell:Disable-ServiceFabricNode
sfctl:sfctl node disableОстановить узел, после чего работа среды выполнения Service Fabric будет полностью завершена и ваше приложение получит запрос на завершение.
PowerShell:Start-ServiceFabricNodeTransition -Stop
sfctl:sfctl node transition --node-transition-type StopУдалить узел из кластера.
PowerShell:Remove-ServiceFabricNodeState
sfctl:sfctl node remove-state
После применения этих шагов узел можно удалить из масштабируемого набора. Если вы используете любой уровень устойчивости, кроме Bronze, эти шаги будут выполнены, когда экземпляр масштабируемого набора будет удален.
Следующий блок кода получает последний созданный узел, отключает, останавливает и удаляет его из кластера.
#### After you've connected.....
# Get the node that was created last
$node = Get-ServiceFabricNode | Sort-Object { $_.NodeName.Substring($_.NodeName.LastIndexOf('_') + 1) } -Descending | Select-Object -First 1
# Node details for the disable/stop process
$nodename = $node.NodeName
$nodeid = $node.NodeInstanceId
$loopTimeout = 10
# Run disable logic
Disable-ServiceFabricNode -NodeName $nodename -Intent RemoveNode -TimeoutSec 300 -Force
$state = Get-ServiceFabricNode | Where-Object NodeName -eq $nodename | Select-Object -ExpandProperty NodeStatus
while (($state -ne [System.Fabric.Query.NodeStatus]::Disabled) -and ($loopTimeout -ne 0))
{
Start-Sleep 5
$loopTimeout -= 1
$state = Get-ServiceFabricNode | Where-Object NodeName -eq $nodename | Select-Object -ExpandProperty NodeStatus
Write-Host "Checking state... $state found"
}
# Exit if the node was unable to be disabled
if ($state -ne [System.Fabric.Query.NodeStatus]::Disabled)
{
Write-Error "Disable failed with state $state"
}
else
{
# Stop node
$stopid = New-Guid
Start-ServiceFabricNodeTransition -Stop -OperationId $stopid -NodeName $nodename -NodeInstanceId $nodeid -StopDurationInSeconds 300
$state = (Get-ServiceFabricNodeTransitionProgress -OperationId $stopid).State
$loopTimeout = 10
# Watch the transaction
while (($state -eq [System.Fabric.TestCommandProgressState]::Running) -and ($loopTimeout -ne 0))
{
Start-Sleep 5
$state = (Get-ServiceFabricNodeTransitionProgress -OperationId $stopid).State
Write-Host "Checking state... $state found"
}
if ($state -ne [System.Fabric.TestCommandProgressState]::Completed)
{
Write-Error "Stop transaction failed with $state"
}
else
{
# Remove the node from the cluster
Remove-ServiceFabricNodeState -NodeName $nodename -TimeoutSec 300 -Force
}
}
В коде sfctl ниже следующая команда используется для получения значений имени узла последнего созданного узла: sfctl node list --query "sort_by(items[*], &name)[-1].name"
# Inform the node that it is going to be removed
sfctl node disable --node-name _nt1vm_5 --deactivation-intent 4 -t 300
# Stop the node using a random guid as our operation id
sfctl node transition --node-instance-id 131541348482680775 --node-name _nt1vm_5 --node-transition-type Stop --operation-id c17bb4c5-9f6c-4eef-950f-3d03e1fef6fc --stop-duration-in-seconds 14400 -t 300
# Remove the node from the cluster
sfctl node remove-state --node-name _nt1vm_5
Совет
Используйте следующие запросы sfctl, чтобы проверить состояние каждого шага.
Проверка состояния деактивацииsfctl node list --query "sort_by(items[*], &name)[-1].nodeDeactivationInfo"
Проверка состояния остановкиsfctl node list --query "sort_by(items[*], &name)[-1].isStopped"
Свертывание масштабируемого набора
Теперь, когда узел Service Fabric удален из кластера, можно свернуть масштабируемый набор виртуальных машин. В приведенном ниже примере емкость масштабируемого набора уменьшается на 1.
$scaleset = Get-AzVmss -ResourceGroupName SFCLUSTERTUTORIALGROUP -VMScaleSetName nt1vm
$scaleset.Sku.Capacity -= 1
Update-AzVmss -ResourceGroupName SFCLUSTERTUTORIALGROUP -VMScaleSetName nt1vm -VirtualMachineScaleSet $scaleset
Этот код задает значение 5 для емкости.
# Get the name of the node with
az vmss list-instances -n nt1vm -g sfclustertutorialgroup --query [*].name
# Use the name to scale
az vmss scale -g sfclustertutorialgroup -n nt1vm --new-capacity 5
Возможные варианты поведения в обозревателе Service Fabric
При горизонтальном масштабировании кластера в Service Fabric Explorer отражается количество узлов (экземпляров масштабируемых наборов виртуальных машин), которые входят в состав кластера. Тем не менее при уменьшении масштаба кластера удаленный узел или экземпляр виртуальной машины будет отображаться как неработоспособный, если не вызвать командлет Remove-ServiceFabricNodeState с именем соответствующего узла.
Вот как объясняется это поведение.
Узлы, указанные в Service Fabric Explorer, отражают то, что системным службам Service Fabric (в частности FM) известно о числе узлов в кластере. При уменьшении масштабируемого набора виртуальных машин виртуальная машина удаляется, но системная служба диспетчера отработки отказов по-прежнему считает, что узел (который был сопоставлен с удаленной виртуальной машиной) вернется. В связи с этим Service Fabric Explorer продолжает отображать этот узел (хотя состояние работоспособности может быть ошибочным или неизвестным).
Проверить удаление узла при удалении виртуальной машины можно двумя способами:
- Выбрать уровень надежности Gold или Silver для типов узлов в кластере — это обеспечит интеграцию инфраструктуры. При масштабировании узлы будут автоматически удалены из состояния системных служб (FM). Дополнительные сведения об уровнях надежности см. здесь.
Примечание
Обеспечьте как минимум пять узлов для любого масштабируемого набора виртуальных машин с уровнем устойчивости Gold или Silver. Кластер будет переходить в состояние ошибки, если масштаб меньше этого порогового значения, и потребуется вручную очистить удаленные узлы.
- После уменьшения масштаба экземпляра виртуальной машины необходимо вызвать командлет Remove-ServiceFabricNodeState.
Примечание
Для кластеров Service Fabric требуется определенное число работающих узлов для поддержания доступности и сохранения состояния. Это называется поддержанием кворума. Поэтому обычно не рекомендуется завершать работу всех компьютеров в кластере, пока не будет выполнено полное резервное копирование состояния, так как это может быть небезопасно.
Дальнейшие действия
Дополнительные сведения о планировании емкости кластера, обновлении кластера и секционировании служб см. в следующих статьях: