Развертывание кластера Azure Service Fabric с типами узлов без отслеживания состояния
Типы узлов Service Fabric изначально предполагают, что в какой-то момент на узлах могут быть размещены службы с отслеживанием состояния. Типы узлов без отслеживания состояния меняют это предположение для типа узла, позволяя тем самым типу узла использовать другие функции, такие как более быстрые операции масштабирования, поддержку автоматического обновления ОС на бронзовом уровне устойчивости и масштабирование до более чем 100 узлов в одном масштабируемом наборе виртуальных машин.
- Основные типы узлов нельзя настроить на работу без отслеживания состояния
- Типы узлов без отслеживания состояния поддерживаются только с бронзовыми уровнями устойчивости.
- Типы узлов без отслеживания состояния поддерживаются только в среде выполнения Service Fabric версии 7.1.409 и выше.
Примеры шаблонов доступны на странице шаблонов типов узлов Service Fabric без отслеживания состояния.
Включение типов узлов без отслеживания состояния в кластере Service Fabric
Чтобы задать один или несколько типов узлов в качестве узлов без отслеживания состояния в ресурсе кластера, задайте для свойства isStateless значение true. При развертывании кластера Service Fabric с типами узлов без отслеживания состояния не забывайте, что в ресурсе кластера должен быть по крайней мере один основной тип узла.
- Значением apiVersion для ресурса кластера Service Fabric должно быть "2020-12-01-preview" или выше.
{
"nodeTypes": [
{
"name": "[parameters('vmNodeType0Name')]",
"applicationPorts": {
"endPort": "[parameters('nt0applicationEndPort')]",
"startPort": "[parameters('nt0applicationStartPort')]"
},
"clientConnectionEndpointPort": "[parameters('nt0fabricTcpGatewayPort')]",
"durabilityLevel": "Silver",
"ephemeralPorts": {
"endPort": "[parameters('nt0ephemeralEndPort')]",
"startPort": "[parameters('nt0ephemeralStartPort')]"
},
"httpGatewayEndpointPort": "[parameters('nt0fabricHttpGatewayPort')]",
"isPrimary": true,
"isStateless": false, // Primary Node Types cannot be stateless
"vmInstanceCount": "[parameters('nt0InstanceCount')]"
},
{
"name": "[parameters('vmNodeType1Name')]",
"applicationPorts": {
"endPort": "[parameters('nt1applicationEndPort')]",
"startPort": "[parameters('nt1applicationStartPort')]"
},
"clientConnectionEndpointPort": "[parameters('nt1fabricTcpGatewayPort')]",
"durabilityLevel": "Bronze",
"ephemeralPorts": {
"endPort": "[parameters('nt1ephemeralEndPort')]",
"startPort": "[parameters('nt1ephemeralStartPort')]"
},
"httpGatewayEndpointPort": "[parameters('nt1fabricHttpGatewayPort')]",
"isPrimary": false,
"isStateless": true,
"vmInstanceCount": "[parameters('nt1InstanceCount')]"
}
],
}
Настройка масштабируемого набора виртуальных машин для типов узлов без отслеживания состояния
Чтобы включить типы узлов без отслеживания состояния, необходимо настроить базовый ресурс масштабируемого набора виртуальных машин следующим образом.
- Свойство singlePlacementGroup должно иметь значение false, если требуется масштабировать боле 100 виртуальных машин.
- Для параметра upgradePolicy масштабируемого набора нужно установить значение Rolling.
- Для режима обновления Rolling (последовательный) необходимо настроить расширение "Работоспособность приложения" или "Пробы работоспособности". Дополнительные сведения о настройке проб работоспособности или расширения состояния приложения можно найти в этом документе doc. Настройте пробы работоспособности с помощью стандартной конфигурации для типов узлов без состояния, как предложено ниже. После развертывания приложений для типа узла можно изменить порты расширения проб работоспособности для отслеживания фактического состояния приложения.
Примечание
При использовании автомасштабирования с типами узлов без отслеживания состояния после масштабирования состояние узла не очищается автоматически. Для очистки состояния отключенных во время автомасштабирования узлов, рекомендуется использовать вспомогательное приложение для автомасштабирования Service Fabric.
{
"apiVersion": "2019-03-01",
"type": "Microsoft.Compute/virtualMachineScaleSets",
"name": "[parameters('vmNodeType1Name')]",
"location": "[parameters('computeLocation')]",
"properties": {
"overprovision": "[variables('overProvision')]",
"upgradePolicy": {
"mode": "Rolling",
"automaticOSUpgradePolicy": {
"enableAutomaticOSUpgrade": true
}
},
"platformFaultDomainCount": 5
},
"virtualMachineProfile": {
"extensionProfile": {
"extensions": [
{
"name": "[concat(parameters('vmNodeType1Name'),'_ServiceFabricNode')]",
"properties": {
"type": "ServiceFabricNode",
"autoUpgradeMinorVersion": false,
"publisher": "Microsoft.Azure.ServiceFabric",
"settings": {
"clusterEndpoint": "[reference(parameters('clusterName')).clusterEndpoint]",
"nodeTypeRef": "[parameters('vmNodeType1Name')]",
"dataPath": "D:\\\\SvcFab",
"durabilityLevel": "Bronze",
"certificate": {
"thumbprint": "[parameters('certificateThumbprint')]",
"x509StoreName": "[parameters('certificateStoreValue')]"
},
"systemLogUploadSettings": {
"Enabled": true
},
},
"typeHandlerVersion": "1.1"
}
},
{
"type": "extensions",
"name": "HealthExtension",
"properties": {
"publisher": "Microsoft.ManagedServices",
"type": "ApplicationHealthWindows",
"autoUpgradeMinorVersion": true,
"typeHandlerVersion": "1.0",
"settings": {
"protocol": "tcp",
"port": "19000"
}
}
},
]
}
Настройка типов узлов без отслеживания состояния с несколькими Зонами доступности
Сведения о настройке типа узла без отслеживания состояния, охватывающего несколько зон доступности, см. в этой документации, кроме того, следует учитывать с несколько изменений:
- Задайте singlePlacementGroup : false, если требуется включить несколько групп размещения.
- Задайте значение upgradePolicy равным Rolling и добавьте расширение работоспособности приложения и пробы работоспособности, как упоминалось выше.
- Задайте platformFaultDomainCount: 5 для масштабируемого набора виртуальных машин.
Для справки ознакомьтесь с шаблоном для настройки типов узлов без отслеживания состояния с несколькими Зонами доступности.
Требования к сети
Ресурс общедоступного IP-адреса и службы Load Balancer
Чтобы включить масштабирование до более 100 виртуальных машин в ресурсе масштабируемого набора виртуальных машин, как ресурс подсистемы балансировки нагрузки, так и ресурс IP-адреса, на которые ссылается этот масштабируемый набор виртуальных машин, должны использовать SKU категории Стандартный. При создании ресурса подсистемы балансировки нагрузки или ресурса IP-адреса без свойства SKU будет создан SKU категории "Базовый", который не поддерживает масштабирование более 100 виртуальных машин. Подсистема балансировки нагрузки с SKU категории "Стандартный" по умолчанию блокирует весь трафик извне. Чтобы разрешить внешний трафик, необходимо развернуть в подсети группу безопасности сети (NSG).
{
"apiVersion": "2018-11-01",
"type": "Microsoft.Network/publicIPAddresses",
"name": "[concat('LB','-', parameters('clusterName')]",
"location": "[parameters('computeLocation')]",
"sku": {
"name": "Standard"
}
}
{
"apiVersion": "2018-11-01",
"type": "Microsoft.Network/loadBalancers",
"name": "[concat('LB','-', parameters('clusterName')]",
"location": "[parameters('computeLocation')]",
"dependsOn": [
"[concat('Microsoft.Network/networkSecurityGroups/', concat('nsg', parameters('subnet0Name')))]"
],
"properties": {
"addressSpace": {
"addressPrefixes": [
"[parameters('addressPrefix')]"
]
},
"subnets": [
{
"name": "[parameters('subnet0Name')]",
"properties": {
"addressPrefix": "[parameters('subnet0Prefix')]",
"networkSecurityGroup": {
"id": "[resourceId('Microsoft.Network/networkSecurityGroups', concat('nsg', parameters('subnet0Name')))]"
}
}
}
]
},
"sku": {
"name": "Standard"
}
}
Примечание
Изменить SKU на месте в ресурсах общедоступного IP-адреса и балансировщика нагрузки невозможно.
Правила NAT для масштабируемого набора виртуальных машин
Правила NAT для входящего трафика подсистемы балансировки нагрузки должны соответствовать пулам NAT из масштабируемого набора виртуальных машин. Каждый масштабируемый набор виртуальных машин должен иметь уникальный пул NAT для входящего трафика.
{
"inboundNatPools": [
{
"name": "LoadBalancerBEAddressNatPool0",
"properties": {
"backendPort": "3389",
"frontendIPConfiguration": {
"id": "[variables('lbIPConfig0')]"
},
"frontendPortRangeEnd": "50999",
"frontendPortRangeStart": "50000",
"protocol": "tcp"
}
},
{
"name": "LoadBalancerBEAddressNatPool1",
"properties": {
"backendPort": "3389",
"frontendIPConfiguration": {
"id": "[variables('lbIPConfig0')]"
},
"frontendPortRangeEnd": "51999",
"frontendPortRangeStart": "51000",
"protocol": "tcp"
}
},
{
"name": "LoadBalancerBEAddressNatPool2",
"properties": {
"backendPort": "3389",
"frontendIPConfiguration": {
"id": "[variables('lbIPConfig0')]"
},
"frontendPortRangeEnd": "52999",
"frontendPortRangeStart": "52000",
"protocol": "tcp"
}
}
]
}
Исходящие правила для балансировщика нагрузки со стандартным SKU
Балансировщик нагрузки категории "Стандартный" и общедоступный IP-адрес категории "Стандартный" вводят новые возможности и различные расширения функциональности для исходящего подключения по сравнению с базовыми SKU. Если вам требуется исходящее подключение при работе с номерами SKU категории "Стандартный", вы должны явно определить это подключение с использованием общедоступных IP-адресов категории "Стандартный" или общедоступного Load Balancer категории "Стандартный". Дополнительные сведения см. в статьях Исходящие подключения и Стандартный балансировщик нагрузки Azure.
Примечание
Стандартный шаблон ссылается на NSG, которая разрешает по умолчанию весь исходящий трафик. Входящий трафик огранен портами, необходимыми для операций управления Service Fabric. Правила NSG можно изменить в соответствии с вашими требованиями.
Примечание
Любой кластер Service Fabric, использующий SLB со стандартным SKU, должен обеспечить для каждого типа узла правило, разрешающее исходящий трафик через порт 443. Это необходимо для завершения установки кластера, и любое развертывание без такого правила завершится неудачей.
Переход на использование типов узлов без отслеживания состояния в кластере
Для всех сценариев миграции необходимо добавить новый тип узла без отслеживания состояния. Существующий тип узла нельзя перенести в режим "только без отслеживания состояния".
Чтобы выполнить миграцию кластера, в котором использовались Load Balancer и IP-адрес с SKU категории "Базовый", сначала необходимо создать полностью новый ресурс Load Balancer и IP-адреса, используя SKU категории "Стандартный". Обновить эти ресурсы на месте невозможно.
Ссылки на новые Load Balancer и IP-адрес должны содержаться в новых типах узлов без отслеживания состояния, которые планируется использовать. В приведенном выше примере добавляются новые ресурсы масштабируемого набора виртуальных машин, которые будут использоваться для типов узлов без отслеживания состояния. Эти масштабируемые наборы виртуальных машин ссылаются на только что созданные Load Balancer и IP-адрес и помечены как типы узлов без отслеживания состояния в ресурсе кластера Service Fabric.
Для начала необходимо добавить новые ресурсы в существующий шаблон Resource Manager. К этим ресурсам относятся:
- Ресурс общедоступного IP-адреса с использованием стандартного SKU.
- Ресурс балансировщика нагрузки с использованием стандартного SKU.
- Группа безопасности сети, на которую ссылается подсеть, где развертываются масштабируемые наборы виртуальных машин.
После завершения развертывания ресурсов можно приступить к отключению узлов в типе узла, который необходимо удалить из исходного кластера.
Дальнейшие действия
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по