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

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

1. Добавьте новый тип узла в кластер Service Fabric, используя обновленный (или измененный) SKU масштабируемого набора виртуальных машин и его конфигурацию. Этот шаг также включает настройку нового балансировщика нагрузки, подсети и общедоступного IP-адреса для масштабируемого набора.

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

3. Убедитесь, что кластер находится в рабочем состоянии, затем удалите исходный набор масштабирования (и связанные ресурсы), а также состояние узлов для удаленных узлов.

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

• От размера виртуальной машины Standard_D2_V2 до уровня "Стандартный" D4_V2 и
• Из операционной системы виртуальной машины Windows Server 2019 Datacenter в Windows Server 2022 Datacenter.

Настройка тестового кластера

Давайте настроим начальный тестовый кластер Service Fabric. Сначала скачайте примеры шаблонов Azure Resource Manager, которые мы будем использовать для выполнения этого сценария.

Затем войдите в учетную запись Azure.

# Sign in to your Azure account
Login-AzAccount -SubscriptionId "<subscription ID>"

Затем откройте файлparameters.json и обновите значение для clusterName на уникальное значение (в Azure).

Следующие команды помогут вам создать новый самозаверяющий сертификат и развернуть тестовый кластер. Если у вас уже есть сертификат, который вы хотите использовать, перейдите к разделу "Использовать существующий сертификат для развертывания кластера".

Создание самозаверяющего сертификата и развертывание кластера

Сначала назначьте переменные, необходимые для развертывания кластера Service Fabric. Настройте значения для resourceGroupName, и certSubjectNameparameterFilePathtemplateFilePath для конкретной учетной записи и среды:

# Assign deployment variables
$resourceGroupName = "sftestupgradegroup"
$certOutputFolder = "c:\certificates"
$certPassword = "Password!1" | ConvertTo-SecureString -AsPlainText -Force
$certSubjectName = "sftestupgrade.southcentralus.cloudapp.azure.com"
$parameterFilePath = "C:\parameters.json"
$templateFilePath = "C:\Initial-TestClusterSetup.json"

# Deploy the initial test cluster
New-AzServiceFabricCluster `
    -ResourceGroupName $resourceGroupName `
    -CertificateOutputFolder $certOutputFolder `
    -CertificatePassword $certPassword `
    -CertificateSubjectName $certSubjectName `
    -TemplateFile $templateFilePath `
    -ParameterFile $parameterFilePath

После завершения развертывания найдите PFX-файл ($certPfx) на локальном компьютере и импортируйте его в хранилище сертификатов:

cd c:\certificates
$certPfx = ".\sftestupgradegroup20200312121003.pfx"
Import-PfxCertificate `
     -FilePath $certPfx `
     -CertStoreLocation Cert:\CurrentUser\My `
     -Password (ConvertTo-SecureString Password!1 -AsPlainText -Force)

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

Использование существующего сертификата для развертывания кластера

Кроме того, для развертывания тестового кластера можно использовать существующий сертификат Azure Key Vault. Для этого вам нужно будет obtain references to your Key Vault и отпечаток сертификата.

# Key Vault variables
$certUrlValue = "https://sftestupgradegroup.vault.azure.net/secrets/sftestupgradegroup20200309235308/dac0e7b7f9d4414984ccaa72bfb2ea39"
$sourceVaultValue = "/subscriptions/########-####-####-####-############/resourceGroups/sftestupgradegroup/providers/Microsoft.KeyVault/vaults/sftestupgradegroup"
$thumb = "AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00"

Затем укажите имя группы ресурсов для кластера и задайте расположения templateFilePath и parameterFilePath.

$resourceGroupName = "sftestupgradegroup"
$templateFilePath = "C:\Initial-TestClusterSetup.json"
$parameterFilePath = "C:\parameters.json"

Наконец, выполните следующую команду, чтобы развернуть начальный тестовый кластер:

# Deploy the initial test cluster
New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

Подключение к новому кластеру и проверка состояния работоспособности

Подключитесь к кластеру и убедитесь, что все пять его узлов работоспособны (замените clusterNamethumb переменные собственными значениями):

# Connect to the cluster
$clusterName = "sftestupgrade.southcentralus.cloudapp.azure.com:19000"
$thumb = "AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00"
Connect-ServiceFabricCluster `
    -ConnectionEndpoint $clusterName `
    -KeepAliveIntervalInSec 10 `
    -X509Credential `
    -ServerCertThumbprint $thumb  `
    -FindType FindByThumbprint `
    -FindValue $thumb `
    -StoreLocation CurrentUser `
    -StoreName My
# Check cluster health
Get-ServiceFabricClusterHealth

С этим мы готовы начать процедуру обновления.

Развертывание нового вторичного типа узла с обновленным набором масштабирования

Чтобы обновить (вертикально масштабировать) тип узла, сначала необходимо развернуть новый тип узла, поддерживаемый новым масштабируемым набором и вспомогательными ресурсами. Новый масштабируемый набор будет помечен как второстепенный (isPrimary: false), так же как и исходный масштабируемый набор. Если вы хотите увеличить тип первичного узла, см. Масштабирование типа первичного узла кластера Service Fabric. Ресурсы, созданные в следующем разделе, в конечном итоге станут новым типом узла в кластере, а исходные ресурсы типа узла будут удалены.

Обновите шаблон кластера вместе с обновленным набором масштаба

Вот построчные изменения в исходном шаблоне развертывания кластера для добавления нового типа узла и поддерживающих ресурсов.

Большинство необходимых изменений для этого шага уже внесены для вас в файл шаблона Step1-AddPrimaryNodeType.json. Однако необходимо внести дополнительное изменение, чтобы файл шаблона работал для типов узлов, отличных от основных. Следующие разделы подробно объяснят эти изменения, и будет указано, когда необходимо внести изменения.

Создание новой подсети в существующей виртуальной сети

{
    "name": "[variables('subnet1Name')]",
    "properties": {
        "addressPrefix": "[variables('subnet1Prefix')]"
    }
}

Создайте новый публичный IP-адрес с уникальной меткой домена.

{
    "apiVersion": "[variables('publicIPApiVersion')]",
    "type": "Microsoft.Network/publicIPAddresses",
    "name": "[concat(variables('lbIPName'),'-',variables('vmNodeType1Name'))]",
    "location": "[variables('computeLocation')]",
    "properties": {
        "dnsSettings": {
            "domainNameLabel": "[concat(variables('dnsName'),'-','nt1')]"
        },
        "publicIPAllocationMethod": "Dynamic"
    },
    "tags": {
        "resourceType": "Service Fabric",
        "clusterName": "[parameters('clusterName')]"
    }
}

Создание подсистемы балансировки нагрузки для общедоступного IP-адреса

"dependsOn": [
    "[concat('Microsoft.Network/publicIPAddresses/',concat(variables('lbIPName'),'-',variables('vmNodeType1Name')))]"
]

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

Тип узла

"nodeTypeRef": "[variables('vmNodeType1Name')]"

SKU для виртуальной машины

"sku": {
    "name": "[parameters('vmNodeType1Size')]",
    "capacity": "[parameters('nt1InstanceCount')]",
    "tier": "Standard"
}

Артикул ОС

"imageReference": {
    "publisher": "[parameters('vmImagePublisher1')]",
    "offer": "[parameters('vmImageOffer1')]",
    "sku": "[parameters('vmImageSku1')]",
    "version": "[parameters('vmImageVersion1')]"
}

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

Добавление нового неосновного типа узла в кластер

Теперь, когда новый тип узла (vmNodeType1Name) имеет собственное имя, подсеть, IP, балансировщик нагрузки и набор масштабирования, он может повторно использовать все остальные переменные из оригинального типа узла (такие как nt0applicationEndPort, nt0applicationStartPort, и nt0fabricTcpGatewayPort).

В существующем шаблонном файле параметр isPrimary установлен на true для руководства Масштабирование типа основных узлов кластера Service Fabric. Измените isPrimary на false для вашего типа узла, который не является основным.

"name": "[variables('vmNodeType1Name')]",
"applicationPorts": {
    "endPort": "[variables('nt0applicationEndPort')]",
    "startPort": "[variables('nt0applicationStartPort')]"
},
"clientConnectionEndpointPort": "[variables('nt0fabricTcpGatewayPort')]",
"durabilityLevel": "Bronze",
"ephemeralPorts": {
    "endPort": "[variables('nt0ephemeralEndPort')]",
    "startPort": "[variables('nt0ephemeralStartPort')]"
},
"httpGatewayEndpointPort": "[variables('nt0fabricHttpGatewayPort')]",
"isPrimary": false,
"reverseProxyEndpointPort": "[variables('nt0reverseProxyEndpointPort')]",
"vmInstanceCount": "[parameters('nt1InstanceCount')]"

После реализации всех изменений в файлах шаблонов и параметров перейдите к следующему разделу, чтобы получить ссылки на key vault и разверните обновления в кластере.

Получите ссылки на ваш Key Vault

Чтобы развернуть обновленную конфигурацию, вам потребуется несколько ссылок на сертификат кластера, хранящийся в Key Vault. Самый простой способ найти эти значения — на портале Azure. Вам потребуется:

• URL-адрес хранилища ключей сертификата кластера. На портале Azure в Key Vault выберите "Сертификаты>", чтобы выбрать нужный> сертификата:

  $certUrlValue="https://sftestupgradegroup.vault.azure.net/secrets/sftestupgradegroup20200309235308/dac0e7b7f9d4414984ccaa72bfb2ea39"
  

• Отпечаток сертификата вашего кластера. (Вероятно, у вас это уже есть, если вы подключились к первоначальному кластеру, чтобы проверить его состояние.) Из того же раздела сертификатов (Сертификаты>Ваш желаемый сертификат) в портале Azure, скопируйте X.509 SHA-1 отпечаток сертификата (в шестнадцатеричном виде):

  $thumb = "AA11BB22CC33DD44EE55FF66AA77BB88CC99DD00"
  

• Идентификатор ресурса хранилища ключей. На портале Azure в Key Vault выберите свойства>идентификатор ресурса:

  $sourceVaultValue = "/subscriptions/########-####-####-####-############/resourceGroups/sftestupgradegroup/providers/Microsoft.KeyVault/vaults/sftestupgradegroup"
  

Развертывание обновленного шаблона

Настройте templateFilePath по мере необходимости и выполните следующую команду:

# Deploy the new node type and its resources
$templateFilePath = "C:\Step1-AddPrimaryNodeType.json"
New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

После завершения развертывания проверьте работоспособность кластера и убедитесь, что все узлы обоих типов узлов работоспособны.

Get-ServiceFabricClusterHealth

Перенесите рабочие нагрузки на новый тип узла.

Подождите, пока все приложения не будут перемещены на новый тип узла и станут здоровыми.

Отключите узлы в исходном наборе масштабируемости типа узлов

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

# Disable the nodes in the original scale set.
$nodeType = "nt0vm"
$nodes = Get-ServiceFabricNode
Write-Host "Disabling nodes..."
foreach($node in $nodes)
{
  if ($node.NodeType -eq $nodeType)
  {
    $node.NodeName
    Disable-ServiceFabricNode -Intent RemoveNode -NodeName $node.NodeName -Force
  }
}

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

Остановка данных на отключенных узлах

Теперь можно остановить данные на отключенных узлах.

# Stop data on the disabled nodes.
foreach($node in $nodes)
{
  if ($node.NodeType -eq $nodeType)
  {
    $node.NodeName
    Start-ServiceFabricNodeTransition -Stop -OperationId (New-Guid) -NodeInstanceId $node.NodeInstanceId -NodeName $node.NodeName -StopDurationInSeconds 10000
  }
}

Удаление исходного типа узла и очистка ресурсов

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

Удалить исходный масштабируемый набор

Сначала удалите базовый масштабируемый набор типа узла.

$scaleSetName = "nt0vm"
$scaleSetResourceType = "Microsoft.Compute/virtualMachineScaleSets"
Remove-AzResource -ResourceName $scaleSetName -ResourceType $scaleSetResourceType -ResourceGroupName $resourceGroupName -Force

Удалите исходные ресурсы IP-адресов и балансировщика нагрузки.

Теперь вы можете удалить исходный IP-адрес и ресурсы подсистемы балансировки нагрузки. На этом этапе вы также обновите имя DNS.

# Delete the original IP and load balancer resources
$lbName = "LB-sftestupgrade-nt0vm"
$lbResourceType = "Microsoft.Network/loadBalancers"
$ipResourceType = "Microsoft.Network/publicIPAddresses"
$oldPublicIpName = "PublicIP-LB-FE-nt0vm"
$newPublicIpName = "PublicIP-LB-FE-nt1vm"
$oldPublicIP = Get-AzPublicIpAddress -Name $oldPublicIpName  -ResourceGroupName $resourceGroupName
$nonPrimaryDNSName = $oldNonPrimaryPublicIP.DnsSettings.DomainNameLabel
$nonPrimaryDNSFqdn = $oldNonPrimaryPublicIP.DnsSettings.Fqdn
Remove-AzResource -ResourceName $lbName -ResourceType $lbResourceType -ResourceGroupName $resourceGroupName -Force
Remove-AzResource -ResourceName $oldPublicIpName -ResourceType $ipResourceType -ResourceGroupName $resourceGroupName -Force
$PublicIP = Get-AzPublicIpAddress -Name $newPublicIpName  -ResourceGroupName $resourceGroupName
$PublicIP.DnsSettings.DomainNameLabel = $nonPrimaryDNSName
$PublicIP.DnsSettings.Fqdn = $nonPrimaryDNSFqdn
Set-AzPublicIpAddress -PublicIpAddress $PublicIP

Удаление состояния узла из исходного типа узла

Исходные узлы типа узла теперь будут отображать ошибку для состояния работоспособности. Удалите состояние их узла из кластера.

# Remove state of the obsolete nodes from the cluster
$nodeType = "nt0vm"
$nodes = Get-ServiceFabricNode
Write-Host "Removing node state..."
foreach($node in $nodes)
{
  if ($node.NodeType -eq $nodeType)
  {
    $node.NodeName
    Remove-ServiceFabricNodeState -NodeName $node.NodeName -Force
  }
}

Теперь Service Fabric Explorer должен отражать только пять узлов нового типа узла (nt1vm), все с значениями состояния работоспособности ОК. Мы исправим следующее, обновив шаблон, чтобы отразить последние изменения и повторное развертывание.

Обновите шаблон развертывания, чтобы отразить недавно масштабированный неосновной тип узла.

Большинство необходимых изменений для этого шага уже внесено для вас в шаблонный файл Step3-CleanupOriginalPrimaryNodeType.json. Однако необходимо внести дополнительное изменение, чтобы файл шаблона работал для неосновных типов узлов. Следующие разделы подробно объяснят эти изменения, и будет указано, когда необходимо внести изменения.

Обновление конечной точки управления кластерами

Обновите кластер managementEndpoint в шаблоне развертывания, чтобы ссылаться на новый IP-адрес (обновив vmNodeType0Name с vmNodeType1Name).

  "managementEndpoint": "[concat('https://',reference(concat(variables('lbIPName'),'-',variables('vmNodeType1Name'))).dnsSettings.fqdn,':',variables('nt0fabricHttpGatewayPort'))]",

Удаление ссылки на исходный тип узла

Удалите ссылку на исходный тип узла из ресурса Service Fabric в шаблоне развертывания.

В существующем шаблонном файле параметр isPrimary установлен на true для руководства Масштабирование типа основных узлов кластера Service Fabric. Измените isPrimary на false для типа узла, который не является основным:

"name": "[variables('vmNodeType0Name')]",
"applicationPorts": {
    "endPort": "[variables('nt0applicationEndPort')]",
    "startPort": "[variables('nt0applicationStartPort')]"
},
"clientConnectionEndpointPort": "[variables('nt0fabricTcpGatewayPort')]",
"durabilityLevel": "Bronze",
"ephemeralPorts": {
    "endPort": "[variables('nt0ephemeralEndPort')]",
    "startPort": "[variables('nt0ephemeralStartPort')]"
},
"httpGatewayEndpointPort": "[variables('nt0fabricHttpGatewayPort')]",
"isPrimary": false,
"reverseProxyEndpointPort": "[variables('nt0reverseProxyEndpointPort')]",
"vmInstanceCount": "[parameters('nt0InstanceCount')]"

Настройте политики здоровья для игнорирования существующих ошибок

Только для кластеров Silver и более высокого уровня устойчивости обновите ресурс кластера в шаблоне и настройте политики работоспособности, чтобы игнорировать fabric:/System состояние приложений, добавив applicationDeltaHealthPolicies в свойства ресурсов кластера, как указано ниже. Следующая политика будет игнорировать существующие ошибки, но не разрешать новые ошибки, связанные со здоровьем.

"upgradeDescription":  
{ 
 "forceRestart": false, 
 "upgradeReplicaSetCheckTimeout": "10675199.02:48:05.4775807", 
 "healthCheckWaitDuration": "00:05:00", 
 "healthCheckStableDuration": "00:05:00", 
 "healthCheckRetryTimeout": "00:45:00", 
 "upgradeTimeout": "12:00:00", 
 "upgradeDomainTimeout": "02:00:00", 
 "healthPolicy": { 
   "maxPercentUnhealthyNodes": 100, 
   "maxPercentUnhealthyApplications": 100 
 }, 
 "deltaHealthPolicy":  
 { 
   "maxPercentDeltaUnhealthyNodes": 0, 
   "maxPercentUpgradeDomainDeltaUnhealthyNodes": 0, 
   "maxPercentDeltaUnhealthyApplications": 0, 
   "applicationDeltaHealthPolicies":  
   { 
       "fabric:/System":  
       { 
           "defaultServiceTypeDeltaHealthPolicy":  
           { 
                   "maxPercentDeltaUnhealthyServices": 0 
           } 
       } 
   } 
 } 
}

Удаление вспомогательных ресурсов для исходного типа узла

Удалите все остальные ресурсы, связанные с исходным типом узла из шаблона ARM и файла параметров. Удалите следующее:

    "vmImagePublisher": {
      "value": "MicrosoftWindowsServer"
    },
    "vmImageOffer": {
      "value": "WindowsServer"
    },
    "vmImageSku": {
      "value": "2019-Datacenter"
    },
    "vmImageVersion": {
      "value": "latest"
    },

Развертывание завершенного шаблона

Наконец, разверните измененный шаблон Azure Resource Manager.

# Deploy the updated template file
$templateFilePath = "C:\Step3-CleanupOriginalPrimaryNodeType"
New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

После завершения развертывания убедитесь, что состояние ресурса Service Fabric готово на портале Azure. Убедитесь, что вы можете получить доступ к новой конечной точке Service Fabric Explorer, состояние работоспособности кластера— ОК, и все развернутые приложения работают правильно.

Вы вертикально масштабировали тип второстепенного узла кластера!

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

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