Service Fabric クラスターの非プライマリ ノード タイプをスケールアップする
この記事では、最小限のダウンタイムで Service Fabric クラスターの非プライマリ ノード タイプをスケールアップする方法について説明します。 SKU のインプレイス アップグレードは、Service Fabric クラスター ノードではサポートされていません。このような操作には、データと可用性の損失が伴う可能性があるためです。 Service Fabric ノード タイプをスケールアップする際の、最も安全性と信頼性が高く推奨される方法は、次を行うことです。
アップグレードされた (または変更された) 仮想マシン スケール セットの SKU および構成を使用する新しいノード タイプを Service Fabric クラスターに追加します。 この手順では、スケール セットの新しいロード バランサー、サブネット、およびパブリック IP の設定も必要になります。
元のスケール セットとアップグレードされたスケール セットの両方が並行して実行されたら、アプリケーションの配置制約を新しいノード タイプに設定することによってワークロードを移行します。
クラスターが正常であることを確認してから、削除したノードの元のスケール セット (および関連リソース) とノードの状態を削除します。
以下で、5 つのノードを含みセカンダリ ノード タイプとして使用される 1 つのスケール セットを使用する、シルバー持続性が設定されたサンプル クラスターの非プライマリ ノード タイプ VM の VM サイズとオペレーティング システムを更新するプロセスについて説明します。 Service Fabric システム サービスを使用するプライマリ ノード タイプは変更されません。 非プライマリ ノード タイプを次のようにアップグレードします。
- VM サイズ Standard_D2_V2 から Standard D4_V2 へ、および
- VM のオペレーティング システムを Windows Server 2019 Datacenter から Windows Server 2022 Datacenter に。
警告
運用クラスターでこの手順を実行する前に、サンプル テンプレートを調べて、テスト クラスターに対してプロセスを検証することをお勧めします。
クラスターの状態が異常な場合は、非プライマリ ノード タイプのスケールアップ手順を試行しないでください。クラスターがさらに不安定になります。 「Service Fabric クラスターのプライマリ ノード タイプをスケールアップする」ガイドで使用されているステップバイステップの 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: false
) としてマークされます。 プライマリ ノード タイプをスケールアップする場合は、「Service Fabric クラスターのプライマリ ノード タイプをスケールアップする」を参照してください。 次のセクションで作成されるリソースは、最終的にはクラスター内の新しいノード タイプになり、元のノード タイプのリソースは削除されます。
アップグレードしたスケール セットでクラスター テンプレートを更新する
ここでは、新しいノード タイプとサポート リソースを追加するための、元のクラスター デプロイ テンプレートのセクションごとの変更点を示します。
この手順に必要な変更のほとんどは、Step1-AddPrimaryNodeType.json テンプレート ファイルで既に行われています。 ただし、テンプレート ファイルが非プライマリ ノード タイプに対して機能するように、追加の変更を行う必要があります。 これらの変更については、以降のセクションで詳しく説明します。また、変更が必要な場合には注意喚起が行われます。
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')]"
}
また、ワークロードに必要な追加の拡張機能を確実に含めるようにしてください。
クラスターに新しい非プライマリ ノード タイプを追加する
新しいノード タイプ (vmNodeType1Name) に独自の名前、サブネット、IP、ロード バランサー、およびスケール セットを設定したので、元のノード タイプの他のすべての変数 (nt0applicationEndPort
、nt0applicationStartPort
、nt0fabricTcpGatewayPort
など) を再利用できます。
既存のテンプレート ファイルで、「Service Fabric クラスターのプライマリ ノード タイプをスケールアップする」ガイドの isPrimary
パラメーターは true
に設定されています。 非プライマリ ノード タイプでは、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 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
ワークロードを新しいノード タイプに移行する
すべてのアプリケーションが新しいノード タイプに移行し、正常な状態になるまで待ちます。
元のノー ド タイプのスケール セット内のノードを無効にする
すべてのシード ノードが新しいスケール セットに移行されたら、元のスケール セットのノードを無効にできます。
# 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](無効) 状態への進行状況を監視します。 すべてのノードが 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"
$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) である 5 つのノードのみがすべて [OK] の正常性状態の値で表示されるはずです。 次に、最新の変更内容と再デプロイを反映するようにテンプレートを更新することで、それを修復します。
新しくスケールアップされた非プライマリ ノード タイプを反映するようにデプロイ テンプレートを更新する
この手順に必要な変更のほとんどは、Step3-CleanupOriginalPrimaryNodeType.json テンプレート ファイルで既に行われています。 ただし、テンプレート ファイルが非プライマリ ノード タイプに対して機能するように、追加の変更を行う必要があります。 これらの変更については、以降のセクションで詳しく説明します。また、変更が必要な場合には注意喚起が行われます。
クラスター管理エンドポイントを更新する
(vmNodeType0Name を vmNodeType1Name で更新することで) 新しい IP を参照するようにデプロイ テンプレートのクラスター managementEndpoint
を更新します。
"managementEndpoint": "[concat('https://',reference(concat(variables('lbIPName'),'-',variables('vmNodeType1Name'))).dnsSettings.fqdn,':',variables('nt0fabricHttpGatewayPort'))]",
元のノード タイプの参照を削除する
デプロイ テンプレート内の Service Fabric リソースから元のノード タイプの参照を削除します。
既存のテンプレート ファイルで、「Service Fabric クラスターのプライマリ ノード タイプをスケールアップする」ガイドの isPrimary
パラメーターは true
に設定されています。 非プライマリ ノード タイプでは、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')]"
既存のエラーを無視するように正常性ポリシーを構成する
シルバー以上の持続性クラスターの場合のみ、テンプレート内のクラスター リソースを更新し、以下に示すように、クラスター リソースのプロパティの下に 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 クラスターをプログラムでスケーリングします。
- スタンドアロン クラスターのスケールインまたはスケールアウトします。