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

В этой статье описывается, как увеличить тип основного узла кластера 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, и 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"

Примечание.

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

Затем разверните тестовый кластер 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 = "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: true), как и исходный масштабируемый набор. Если вы хотите увеличить масштаб типа узла, отличного от первичного, см. статью "Масштабирование кластера Service Fabric, отличного от первичного типа узла". Ресурсы, созданные в следующем разделе, в конечном итоге станут новым типом основного узла в кластере, а исходные ресурсы типа основного узла удаляются.

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

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

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

Примечание.

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

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

{
    "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')]"
}

Если вы изменяете номер 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, и nt0applicationStartPortnt0fabricTcpGatewayPort):

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

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

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

Снять пометку исходного типа узла как основного

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

{
    "isPrimary": false,
}

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

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

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

Примечание.

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

Используйте 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 проверьте вкладку "Сведения" узлов в состоянии отключения. Если они отображают ожидающую проверку безопасности типа EnsurePartitionQuorum (обеспечивая кворум для разделов службы инфраструктуры), то можно безопасно продолжать.

Вы можете продолжить остановку обработки данных и удаление узлов, застрявших в состоянии

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

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

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

# 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 часов.

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

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

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

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

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

Были ли сведения на этой странице полезными?

Last updated on 2024-08-25

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Снять пометку исходного типа узла как основного

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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