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

Статья
08/25/2024

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

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

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

размер виртуальной машины будет изменен со Standard_D2_V2 на Standard_D4_V2;
Из операционной системы виртуальной машины Windows Server 2019 Datacenter в Windows Server 2022 Datacenter.

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

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

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

Пошаговые шаблоны развертывания Azure, которые мы будем использовать для выполнения этого примера сценария обновления, доступны на сайте GitHub.

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

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

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

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

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

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

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

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

# 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"

Примечание.

Перед выполнением команды для развертывания нового кластера Service Fabric убедитесь, что на локальном компьютере существует расположение certOutputFolder.

Затем разверните тестовый кластер Service Fabric.

# 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. Для этого необходимо получить ссылки на Key Vault и отпечаток сертификата.

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

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

Примечание.

Указанная группа ресурсов должна уже существовать и находиться в том же регионе, что и Key Vault.

$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

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

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

# Connect to the cluster
$clusterName = "sftestupgrade.southcentralus.cloudapp.azure.com:19000"
$thumb = "BB796AA33BD9767E7DA27FE5182CF8FDEE714A70"

Connect-ServiceFabricCluster `
    -ConnectionEndpoint $clusterName `
    -KeepAliveIntervalInSec 10 `
    -X509Credential `
    -ServerCertThumbprint $thumb  `
    -FindType FindByThumbprint `
    -FindValue $thumb `
    -StoreLocation CurrentUser `
    -StoreName My

# Check cluster health
Get-ServiceFabricClusterHealth

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

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

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

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

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

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

Примечание.

Убедитесь, что вы используете имена, уникальные из исходного типа узла, масштабируемого набора, подсистемы балансировки нагрузки, общедоступного IP-адреса и подсети исходного типа первичного узла, так как эти ресурсы удаляются на более позднем этапе процесса.

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

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

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

{
    "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"
}

SKU ОС

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

Если вы изменяете номер SKU ОС в кластере Linux

В кластере Windows значение для vmImage свойства — "Windows", а значение того же свойства для кластера Linux — имя используемого образа ОС. Например, Ubuntu20_04(используйте последнее имя образа виртуальной машины).

Таким образом, если вы изменяете образ виртуальной машины (SKU ОС) в кластере Linux, обновите параметр vmImage в ресурсе кластера Service Fabric, а также.

#Update the property vmImage with the required OS name in your ARM template
{
    "vmImage": "[parameter(newVmImageName]”
}

Примечание. Пример newVmImageName: Ubuntu20_04

Вы также можете обновить ресурс кластера с помощью следующей команды PowerShell:

# Update cluster vmImage to target OS. This registers the SF runtime package type that is supplied for upgrades.
Update-AzServiceFabricVmImage -ResourceGroupName $resourceGroup -ClusterName $clusterName -VmImage Ubuntu20_04

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

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

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

"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": true,
"reverseProxyEndpointPort": "[variables('nt0reverseProxyEndpointPort')]",
"vmInstanceCount": "[parameters('nt1InstanceCount')]"

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

Получение ссылок Key Vault

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

URL-адрес сертификата кластера в хранилище ключей. В хранилище Key Vault на портале Azure выберите Сертификаты>нужный вам сертификат>Идентификатор секрета:
```
$certUrlValue="https://sftestupgradegroup.vault.azure.net/secrets/sftestupgradegroup20200309235308/dac0e7b7f9d4414984ccaa72bfb2ea39"
```
Отпечаток сертификата кластера. (Возможно, у вас уже есть сертификат, если вы подключились к исходному кластеру, чтобы проверить состояние работоспособности.) В той же колонке сертификатов>(сертификаты, необходимые сертификаты) в портал Azure скопируйте отпечаток SHA-509 SHA-1 (в шестнадцатеричном виде):
```
$thumb = "BB796AA33BD9767E7DA27FE5182CF8FDEE714A70"
```
Идентификатор ресурса для хранилища ключей. В хранилище Key Vault на портале Azure выберите Свойства>Идентификатор ресурса:
```
$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

Миграция начальных узлов на новый тип

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

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

Сначала удалите обозначение isPrimary в шаблоне для исходного типа узла.

{
    "isPrimary": false,
}

Затем разверните измененный шаблон. Это развертывание инициирует миграцию начальных узлов в новый масштабируемый набор.

$templateFilePath = "C:\Step2-UnmarkOriginalPrimaryNodeType.json"

New-AzResourceGroupDeployment `
    -ResourceGroupName $resourceGroupName `
    -TemplateFile $templateFilePath `
    -TemplateParameterFile $parameterFilePath `
    -CertificateThumbprint $thumb `
    -CertificateUrlValue $certUrlValue `
    -SourceVaultValue $sourceVaultValue `
    -Verbose

Примечание.

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

Для отслеживания переноса начальных узлов в новый масштабируемый набор используйте Service Fabric Explorer. Узлы исходного типа узла (nt0vm) должны иметь значение false в столбце "Начальный узел ", а те из нового типа узла (nt1vm) должны иметь значение true.

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

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

# 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.

Состояние отключенных узлов в Service Fabric Explorer

При уровнях устойчивости Silver и Gold некоторые узлы переходят в отключенное состояние, пока другие могут оставаться в состоянии Отключение. В Service Fabric Explorer проверьте вкладку сведений для узлов в состоянии отключения. Если они отображают ожидающую проверку безопасности типа EnsurePartitionQuorem (обеспечивая кворум для секций служб инфраструктуры), то это безопасно.

Для узлов в состоянии

Если кластер относится к уровню устойчивости Bronze, дождитесь, пока все узлы перейдут в состояние Отключено.

Отключение обработки данных на отключенных узлах

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

# 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-имя.

Примечание.

Этот шаг является необязательным, если уже используются общедоступный IP-адрес и подсистема балансировки нагрузки SKU уровня Стандартный. В этом случае в одной подсистеме балансировки нагрузки может быть несколько масштабируемых наборов или типов узлов.

Выполните следующие команды, изменив значение $lbname.

# 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"

$oldPrimaryPublicIP = Get-AzPublicIpAddress -Name $oldPublicIpName  -ResourceGroupName $resourceGroupName
$primaryDNSName = $oldPrimaryPublicIP.DnsSettings.DomainNameLabel
$primaryDNSFqdn = $oldPrimaryPublicIP.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 = $primaryDNSName
$PublicIP.DnsSettings.Fqdn = $primaryDNSFqdn
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 в шаблоне развертывания:

"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": true,
"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

Примечание.

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

В результате этого обновления изменятся параметры для InfrastructureService, в связи с чем потребуется перезагрузка узла. В данном случае значение параметра forceRestart игнорируется. Параметр upgradeReplicaSetCheckTimeout задает максимальное время, в течение которого Service Fabric ожидает перехода секции в безопасное состояние, если она еще не находится в нем. После завершения проверок безопасности для всех секций на узле Service Fabric начинает обновление на этом узле. Значение параметра upgradeTimeout можно уменьшить до 6 часов, однако для максимальной безопасности следует использовать значение 12 часов.

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

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

Следующие шаги

Узнайте, как добавить тип узла в кластер.
Дополнительные сведения об обновлениях приложений.
Руководство. Масштабирование кластера Service Fabric
Масштабируйте кластер Azure программно, используя свободный пакет SDK для вычислений Azure.
Увеличение и уменьшение масштаба автономного кластера.

Поделиться через

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

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

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

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

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

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

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

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

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

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

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

Если вы изменяете номер SKU ОС в кластере Linux

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

Получение ссылок Key Vault

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

Миграция начальных узлов на новый тип

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

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

Отключение обработки данных на отключенных узлах

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

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

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

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

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

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

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

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

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

Развертывание окончательной версии шаблона

Следующие шаги

Обратная связь

Дополнительные ресурсы