Service Fabric クラスターのプライマリノードタイプをスケールアップする

[アーティクル]
10/15/2024

この記事では、最小限のダウンタイムで Service Fabric クラスターのプライマリノードタイプをスケールアップする方法について説明します。 SKU のインプレイスアップグレードは、Service Fabric クラスターノードではサポートされていません。このような操作には、データと可用性の損失が伴う可能性があるためです。 Service Fabric ノードタイプをスケールアップする際の、最も安全性と信頼性が高く推奨される方法は、次を行うことです。

アップグレードされた (または変更された) 仮想マシンスケールセットの SKU および構成を使用する新しいノードタイプを Service Fabric クラスターに追加します。この手順では、スケールセットの新しいロードバランサー、サブネット、およびパブリック IP の設定も必要になります。
元のスケールセットとアップグレードしたスケールセットの両方が並行して実行したら、システムサービス (またはステートフルサービスのレプリカ) が新しいスケールセットに移行するように、一度に 1 つずつ元のノードインスタンスを無効にします。
クラスターと新しいノードが正常であることを確認してから、削除したノードの元のスケールセット (および関連リソース) とノードの状態を削除します。

以下で、、5 つのノードを含む 1 つのスケールセットを使用する、シルバー持続性が設定されたサンプルクラスターのプライマリノードタイプ VM の VM サイズとオペレーティングシステムを更新するプロセスについて説明します。プライマリノードタイプを次のようにアップグレードします。

VM サイズ Standard_D2_V2 から Standard D4_V2 へ、および
VM のオペレーティングシステムを 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"

Note

新しい 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 の場所を設定します。

Note

指定されたリソースグループは既に存在し、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

新しいクラスターに接続して正常性状態を確認する

クラスターに接続し、そのノードの 5 つすべてが正常であることを確認します (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 参照の取得と、クラスターに新しいプライマリノードタイプを追加する更新したテンプレートのデプロイを進めることができます。

Note

元のノードタイプ、スケールセット、ロードバランサー、パブリック IP、および元のプライマリノードタイプのサブネットと重複しない名前を使用するようにしてください。これらのリソースは、このプロセスの後の手順で削除するためです。

既存の仮想ネットワーク内に新しいサブネットを作成する

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

一意の domainNameLabel を持つ新しいパブリック 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')))]"
]

(アップグレードされた VM および OS SKU を使用して) 新しい仮想マシンスケールセットを作成する

ノードの種類の参照

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

VM の SKU

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

OS SKU

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

Linux クラスターで OS SKU を変更する場合

Windows クラスターでは、プロパティ vmImage の値は "Windows" ですが、Linux クラスターの同プロパティの値は使用される OS イメージの名前です。例: - Ubuntu20_04 (最新の vm イメージ名を使用)。

そのため、Linux クラスターで VM イメージ (OS SKU) を変更する場合は、Service Fabric クラスターリソースの vmImage 設定も更新します。

#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 portal を使用することです。必要なもの:

クラスター証明書の Key Vault URL。 Azure portal の Key Vault で、 [証明書]>目的の証明書>[シークレット識別子] を選択します。
```
$certUrlValue="https://sftestupgradegroup.vault.azure.net/secrets/sftestupgradegroup20200309235308/dac0e7b7f9d4414984ccaa72bfb2ea39"
```
クラスター証明書の拇印。 (初期クラスターに接続して、その正常性状態を確認している場合は、既にこの証明書を持っている可能性があります)。Azure portal で同じ証明書ブレード ([証明書]>目的の証明書) から、X.509 SHA-1 の拇印 (16 進数) をコピーします。
```
$thumb = "BB796AA33BD9767E7DA27FE5182CF8FDEE714A70"
```

Key Vault のリソース ID。 Azure portal の Key Vault から、 [プロパティ]>[リソース ID] を選択します。

$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

Note

新しいスケールセットへのシードノードの移行が完了するまでしばらく時間がかかります。データの整合性を確保するため、一度に変更できるシードノードは 1 つだけです。各シードノードの変更には、クラスターの更新が必要であるため、シードノードの交換には、2 回のクラスターのアップグレード (ノードの追加と削除のために 1 回ずつ) が必要です。このサンプルシナリオで 5 つのシードノードをアップグレードすると、10 回のクラスターのアップグレードが発生します。

新しいスケールセットへのシードノードの移行を監視するには、Service Fabric Explorer を使用します。元のノードタイプ (nt0vm) のノードはすべて [Is Seed Node] (シードノードです) 列が 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 を使用して、元のスケールセットのノードの [Disabling](無効化中) から [Disabled](無効) 状態への進行状況を監視します。

無効なノードの状態を示す Service Fabric Explorer

シルバーおよびゴールド持続性の場合、一部のノードは [Disabled](無効) 状態になりますが、その他は [Disabling](無効化中) 状態のまま残ることがあります。 Service Fabric Explorer で、[Disabling](無効化中) 状態のノードの [詳細] タブを確認してください。種類が EnsurePartitionQuorem (インフラストラクチャサービスパーティションのクォーラムを確保する) の "安全性チェックの保留中" が表示されている場合は、続行しても安全です。

'EnsurePartitionQuorum' という種類の安全性チェックの保留中が表示されている場合は、データの停止と、'無効化' 状態で停止しているノードの削除を進めることができます。

クラスターがブロンズ持続性の場合は、すべてのノードが [Disabled](無効) 状態になるまで待ちます。

無効化されたノードでデータを停止する

ここで、無効化されたノードでデータを停止できます。

# 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 名も更新します。

Note

Standard SKU のパブリック IP およびロードバランサーを既に使用している場合、この手順は省略可能です。この場合は、同じロードバランサーで複数のスケールセットやノードタイプを使用できます。

次のコマンドを実行します。$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) である 5 つのノードのみがすべて [OK] の正常性状態の値で表示されるはずです。クラスターの正常性状態には、引き続き [エラー] が表示されます。次に、最新の変更内容と再デプロイを反映するようにテンプレートを更新することで、それを修復します。

新しくスケールアップされたプライマリノードタイプを反映するようにデプロイテンプレートを更新する

この手順に必要な変更は、Step3-CleanupOriginalPrimaryNodeType.json テンプレートファイルで既に行われています。以降のセクションで、これらのテンプレートの変更について詳しく説明します。必要に応じて、説明をスキップし、更新されたテンプレートのデプロイを進めて、このチュートリアルを完了することができます。

クラスター管理エンドポイントを更新する

(vmNodeType0Name を vmNodeType1Name で更新することで) 新しい IP を参照するようにデプロイテンプレートのクラスター managementEndpoint を更新します。

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

既存のエラーを無視するように正常性ポリシーを構成する

シルバー以上の持続性クラスターの場合のみ、テンプレート内のクラスターリソースを更新し、以下に示すように、クラスターリソースのプロパティの下に applicationDeltaHealthPolicies を追加することで fabric:/System のアプリケーションの正常性を無視するように正常性ポリシーを構成します。以下のポリシーでは既存のエラーが無視されますが、新しい正常性エラーは許容されません。

"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

Note

この手順にはしばらく時間がかかります (通常は最大 2 時間)。

このアップグレードでは InfrastructureService に対する設定が変更されるため、ノードの再起動が必要になります。この場合、forceRestart は無視されます。パラメーター upgradeReplicaSetCheckTimeout には、パーティションが (まだ安全な状態でない場合に) 安全な状態になるまで Service Fabric が待機する最大時間を指定します。ノード上のすべてのパーティションが安全性チェックに合格すると、Service Fabric はそのノードでアップグレードを進めます。パラメーター upgradeTimeout の値は 6 時間に短縮できますが、最大の安全確保のために 12 時間とする必要があります。

デプロイが完了したら、Azure portal で、Service Fabric リソースの状態が [準備完了] であることを確認します。新しい Service Fabric Explorer エンドポイントに接続できること、クラスターの正常性状態が [OK] であること、デプロイされたすべてのアプリケーションが正常に機能することを確認します。

これで、クラスターのプライマリノードタイプが垂直方向にスケーリングされました。

次のステップ

クラスターにノードタイプを追加する方法について学習します。
アプリケーションのスケーラビリティについて学習します。
Azure クラスターをスケールインまたはスケールアウトします。
fluent Azure コンピューティング SDK を使用して Azure クラスターをプログラムでスケーリングします。
スタンドアロンクラスターのスケールインまたはスケールアウトします。

次の方法で共有

Service Fabric クラスターのプライマリノードタイプをスケールアップする

テストクラスターをセットアップする

自己署名証明書を生成してクラスターをデプロイする

既存の証明書を使用してクラスターをデプロイする

新しいクラスターに接続して正常性状態を確認する

アップグレードしたスケールセットを使用して新しいプライマリノードタイプをデプロイする

アップグレードしたスケールセットでクラスターテンプレートを更新する

既存の仮想ネットワーク内に新しいサブネットを作成する

一意の domainNameLabel を持つ新しいパブリック IP を作成する

パブリック IP 用の新しいロードバランサーを作成する

(アップグレードされた VM および OS SKU を使用して) 新しい仮想マシンスケールセットを作成する

Linux クラスターで OS SKU を変更する場合

クラスターに新しいプライマリノードタイプを追加する

Key Vault 参照を取得する

更新したテンプレートをデプロイする

シードノードを新しいノードタイプに移行する

元のノードタイプからプライマリのマークを解除する

元のノードタイプのスケールセット内のノードを無効にする

無効化されたノードでデータを停止する

元のノードタイプを削除し、そのリソースをクリーンアップする

元のスケールセットを削除する

元の IP およびロードバランサーリソースを削除する

元のノードタイプからノードの状態を削除する

新しくスケールアップされたプライマリノードタイプを反映するようにデプロイテンプレートを更新する

クラスター管理エンドポイントを更新する

元のノードタイプの参照を削除する

既存のエラーを無視するように正常性ポリシーを構成する

元のノードタイプのサポートリソースを削除する

完成したテンプレートをデプロイする

次のステップ

フィードバック

その他のリソース

次の方法で共有

Service Fabric クラスターのプライマリ ノード タイプをスケールアップする

テスト クラスターをセットアップする

自己署名証明書を生成してクラスターをデプロイする

既存の証明書を使用してクラスターをデプロイする

新しいクラスターに接続して正常性状態を確認する

アップグレードしたスケール セットを使用して新しいプライマリ ノード タイプをデプロイする

アップグレードしたスケール セットでクラスター テンプレートを更新する

既存の仮想ネットワーク内に新しいサブネットを作成する

一意の domainNameLabel を持つ新しいパブリック IP を作成する

パブリック IP 用の新しいロード バランサーを作成する

(アップグレードされた VM および OS SKU を使用して) 新しい仮想マシン スケール セットを作成する

Linux クラスターで OS SKU を変更する場合

クラスターに新しいプライマリ ノード タイプを追加する

Key Vault 参照を取得する

更新したテンプレートをデプロイする

シード ノードを新しいノード タイプに移行する

元のノード タイプからプライマリのマークを解除する

元のノー ド タイプのスケール セット内のノードを無効にする

無効化されたノードでデータを停止する

元のノード タイプを削除し、そのリソースをクリーンアップする

元のスケール セットを削除する

元の IP およびロード バランサー リソースを削除する

元のノード タイプからノードの状態を削除する

新しくスケールアップされたプライマリ ノード タイプを反映するようにデプロイ テンプレートを更新する

クラスター管理エンドポイントを更新する

元のノード タイプの参照を削除する

既存のエラーを無視するように正常性ポリシーを構成する

元のノード タイプのサポート リソースを削除する

完成したテンプレートをデプロイする

次のステップ

フィードバック

その他のリソース

Service Fabric クラスターのプライマリノードタイプをスケールアップする

テストクラスターをセットアップする

アップグレードしたスケールセットを使用して新しいプライマリノードタイプをデプロイする

アップグレードしたスケールセットでクラスターテンプレートを更新する

パブリック IP 用の新しいロードバランサーを作成する

(アップグレードされた VM および OS SKU を使用して) 新しい仮想マシンスケールセットを作成する

クラスターに新しいプライマリノードタイプを追加する

シードノードを新しいノードタイプに移行する

元のノードタイプからプライマリのマークを解除する

元のノードタイプのスケールセット内のノードを無効にする

元のノードタイプを削除し、そのリソースをクリーンアップする

元のスケールセットを削除する

元の IP およびロードバランサーリソースを削除する

元のノードタイプからノードの状態を削除する

新しくスケールアップされたプライマリノードタイプを反映するようにデプロイテンプレートを更新する

元のノードタイプの参照を削除する

元のノードタイプのサポートリソースを削除する