Service Fabric クラスターを可用性ゾーンのサポートに移行する

[アーティクル]
04/28/2024

このガイドでは、Service Fabric クラスターを可用性ゾーンのサポートなしから可用性のサポートありに移行する方法について説明します。移行のさまざまなオプションについて紹介します。可用性ゾーン間で分散された Service Fabric クラスターでは、クラスター状態の高可用性が確保されます。

マネージドクラスターと非マネージドクラスターの両方を移行できます。この記事では、この両方について説明します。

非マネージドクラスターの場合は、次の 2 つの異なるシナリオについて説明します。

Standard SKU ロードバランサーと IP リソースを使用したクラスターの移行。この構成では、新しいリソースを作成しなくても可用性ゾーンがサポートされます。
Basic SKU ロードバランサーと IP リソースを使用したクラスターの移行。この構成は可用性ゾーンをサポートしていないため、新しいリソースを作成する必要があります。

Service Fabric クラスターシナリオの各ヘッダーの下にある適切なセクションを参照してください。

Note

可用性ゾーンをまたいでプライマリノードタイプを拡張する利点が得られるのは 3 つのゾーンの場合だけであり、2 つの場合は得られません。これは、マネージドクラスターと非マネージドクラスターの両方に当てはまります。

サンプルテンプレートは、Service Fabric クロス可用性ゾーンテンプレートに関するページで入手できます。

前提条件

Service Fabric の管理対象クラスター

必須:

Standard SKU クラスター。
リージョン内の 3 つの可用性ゾーン。

推奨:

クラスター SKU は Standard である必要があります。
最適な回復性を得るには、プライマリノードタイプに少なくとも 9 つのノードが必要ですが、サポートされる最小数は 6 つです。
最適な回復性を得るには、セカンダリノードタイプに少なくとも 6 つのノードが必要ですが、サポートされる最小数は 3 つです。

Service Fabric の非マネージドクラスター

必須: N/A。

推奨:

Platinum に設定されたクラスター信頼性レベル。
Standard SKU を使用した単一のパブリック IP リソース。
Standard SKU を使用した単一のロードバランサーリソース。
仮想マシンスケールセットをデプロイするサブネットで参照されているネットワークセキュリティグループ (NSG)。

既存の Standard SKU ロードバランサーと IP リソース

既存の必要なリソースがあることを前提としているため、このシナリオの前提条件はありません。

Basic SKU ロードバランサーと IP リソース

Standard SKU を使用する新しいロードバランサー。既存の Basic SKU ロードバランサーとは異なります。
Standard SKU を使用する新しい IP リソース。既存の Basic SKU IP リソースとは異なります。

Note

既存のリソースを Basic SKU から Standard SKU にアップグレードすることはできないため、新しいリソースが必要です。

ダウンタイムの要件

Service Fabric マネージドクラスター

ゾーン回復性がある構成に移行すると、ロードバランサーを介した外部接続が一時的に失われることがありますが、クラスターの正常性に影響はありません。外部接続の損失は、ゾーン障害に対する回復性があるネットワークにするために、新しいパブリック IP を作成する必要がある場合に発生します。必要に応じて移行の計画を立ててください。

Service Fabric の非管理対象クラスター

Service Fabric 非マネージドクラスターの移行のダウンタイムは、クラスター内の VM とアップグレードドメイン (UD) の数によって大きく異なります。 UD は、アップグレードがクラスター内の VM にプッシュされる順序を決定する VM の論理的なグループです。ダウンタイムは、クラスター内の UD のアップグレードタスクの処理方法を処理するクラスターのアップグレードモードによっても影響を受けます。アップグレードモードを制御する sfZonalUpgradeMode プロパティについては、次のセクションで詳しく説明します。

Service Fabric マネージドクラスターの移行

「Service Fabric マネージドクラスターをゾーン対応に移行する」の手順に従います。

Service Fabric 非マネージドクラスターの移行オプション

移行オプション 1: 単一の仮想マシンスケールセットで、複数の可用性ゾーンを有効にする

このオプションを使用するタイミング

このソリューションでは、同じノードタイプの 3 つの Availability Zones にまたがらせることができます。これは、単一の仮想マシンスケールセットを維持しながら、すべての可用性ゾーンにデプロイできるため、推奨されるデプロイトポロジです。

完全なサンプルテンプレートは GitHub で入手できます。

このオプションは、移行する Standard SKU ロードバランサーと IP リソースを含む既存の Service Fabric 非マネージドクラスターがある場合に使用する必要があります。既存の非マネージドクラスターに Basic SKU リソースがある場合は、下に Basic SKU の移行オプションが表示されます。

既存の Standard SKU ロードバランサーと IP リソースを使用して Service Fabric 非マネージドクラスターを移行する方法

仮想マシンスケールセットでゾーンを有効にする:

仮仮想マシンスケールセットリソースには、次の 3 つの値を含めます。

最初の値は、zones プロパティであり、仮想マシンスケールセットにある可用性ゾーンを指定します。
2 つ目の値は、singlePlacementGroup プロパティであり、true に設定する必要があります。 3 つの可用性ゾーンにまたがるスケールセットは、singlePlacementGroup = true でも最大 300 の VM に拡張できます。
3 つ目の値は、zoneBalance です。これを指定すると、厳密なゾーンバランシングが確実に行われます。この値は true である必要があります。これにより、ゾーン間での VM の分散が不均衡になることがなくなるので、あるゾーンがダウンしたときに、他の 2 つのゾーンに十分な VM が確保され、クラスターは実行し続けられます。

VM の分散が不均衡なクラスターの場合、ゾーンがダウンしたときに中断される可能性があります。そのゾーンにほとんどの VM が含まれている可能性があるためです。ゾーン間で VM の分散が不均衡になっていると、サービス配置の問題が発生したり、インフラストラクチャの更新がスタックしたりすることもあります。 zoneBalancing の詳細を確認します。

FaultDomain および UpgradeDomain のオーバーライドを構成する必要はありません。

{
  "apiVersion": "2018-10-01",
  "type": "Microsoft.Compute/virtualMachineScaleSets",
  "name": "[parameters('vmNodeType1Name')]",
  "location": "[parameters('computeLocation')]",
  "zones": [ "1", "2", "3" ],
  "properties": {
    "singlePlacementGroup": true,
    "zoneBalance": true
  }
}

Note

Service Fabric クラスターには少なくとも 1 つのプライマリノードタイプが必要です。プライマリノードタイプの持続性レベルは、シルバー以上である必要があります。
仮想マシンスケールセット間にまたがる可用性ゾーンは、持続性レベルに関係なく、少なくとも 3 つの可用性ゾーンで構成する必要があります。
シルバー以上の持続性を備えた仮想マシンスケールセットにまたがる可用性ゾーンには、少なくとも 15 の VM が必要です。
ブロンズの持続性を備えた仮想マシンスケールセットにまたがる可用性ゾーンには、少なくとも 6 個の VM が必要です。

Service Fabric ノードタイプでの複数ゾーンのサポートを有効にする

複数の可用性ゾーンをサポートするために、Service Fabric ノードタイプを有効にする必要があります。

最初の値は multipleAvailabilityZones であり、ノードタイプには true に設定する必要があります。
2 番目の値は sfZonalUpgradeMode であり、省略可能です。可用性ゾーンが複数あるノードタイプがクラスター内に既に存在する場合、このプロパティを変更することはできません。このプロパティは、UD 内の VM の論理グループ化を制御します。
- この値が Parallel に設定されている場合: ノードタイプ下の VM は UD にグループ化され、5 つの UD のゾーン情報は無視されます。この設定により、すべてのゾーンにまたがる UD が同時にアップグレードされます。このデプロイモードはアップグレードの場合は高速ですが、更新プログラムを一度に 1 ゾーンずつ適用する必要があるとしている SDP のガイドラインに沿っていないので、お勧めできません。
- この値が省略されているか、Hierarchical に設定されている場合: VM は、最大 15 の UD でのゾーン分布を反映するようにグループ化されます。 3 つのゾーンそれぞれに 5 つの UD が含められます。これにより、ゾーンは一度に 1 つずつ更新され、最初のゾーン内で 5 つの UD が完了した後にのみ、次のゾーンに移ります。この更新プロセスにより、クラスターとユーザーアプリケーションにとって安全性が高まります。
このプロパティは、Service Fabric アプリケーションおよびコードアップグレードのアップグレード動作を定義するだけです。基になる仮想マシンスケールセットのアップグレードは、引き続きすべての可用性ゾーンで並列に実行されます。このプロパティは、複数のゾーンが有効になっていないノードタイプの UD 分布には影響しません。
3番目の値は vmssZonalUpgradeMode で省略可能、いつでも更新できます。このプロパティは、仮想マシンスケールセットが複数の Availability Zones で並列または順次発生するように定義します。
- この値が Parallel に設定されている場合、すべてのスケールセットの更新はすべてのゾーンで並行して行われます。このデプロイモードはアップグレードの場合は高速ですが、更新プログラムを一度に 1 ゾーンずつ適用する必要があるとしている SDP のガイドラインに沿っていないので、お勧めできません。
- この値が省略されているか、Hierarchical に設定されている場合、ゾーンは一度に 1 つずつ更新され、最初のゾーン内で 5 つの UD が完了した後にのみ、次のゾーンに移るようになっています。この更新プロセスにより、クラスターとユーザーアプリケーションにとって安全性が高まります。

重要

Service Fabric クラスターリソース API バージョンは、2020-12-01-preview 以降である必要があります。

クラスターコードバージョンは、少なくとも 8.1.321 以降である必要があります。

{
  "apiVersion": "2020-12-01-preview",
  "type": "Microsoft.ServiceFabric/clusters",
  "name": "[parameters('clusterName')]",
  "location": "[parameters('clusterLocation')]",
  "dependsOn": [
    "[concat('Microsoft.Storage/storageAccounts/', parameters('supportLogStorageAccountName'))]"
  ],
  "properties": {
    "reliabilityLevel": "Platinum",
    "sfZonalUpgradeMode": "Hierarchical",
    "vmssZonalUpgradeMode": "Parallel",
    "nodeTypes": [
      {
        "name": "[parameters('vmNodeType0Name')]",
        "multipleAvailabilityZones": true
      }
    ]
  }
}

Note

パブリック IP とロードバランサーリソースでは、この記事で既に説明したように、Standard SKU を使用する必要があります。
ノードタイプの multipleAvailabilityZones プロパティは、このノードタイプが作成されている場合にのみ定義でき、後から変更することはできません。既存のノードタイプをこのプロパティで構成することはできません。
sfZonalUpgradeMode を省略した場合、または Hierarchical に設定した場合、クラスター内のアップグレードドメインが増えるので、クラスターとアプリケーションのデプロイ速度が低下します。 15 のアップグレードドメインに必要なアップグレード時間が取れるようにアップグレードポリシーのタイムアウトを適切に調整することが重要です。アプリとクラスターの両方のアップグレードポリシーを更新して、デプロイが Azure Resource Service のデプロイ制限時間 (12 時間) を超えないようにする必要があります。つまり、15 の UD の場合、デプロイには 12 時間を超えないようにする必要があります (つまり、それぞれの UD に対して 40 分を超えないようにする必要があります)。
1 ゾーンダウンシナリオでクラスターが存続できるようにするには、クラスターの信頼性レベルを Platinum に設定します。
multipleAvailabilityZones を持つ nodetype の DurabilityLevel のアップグレードはサポートされていません。代わりに、より持続性が高い新しいノードタイプを作成してください。
SF でサポートされている AvailabilityZone は 3 つまでです。それよりも多いものは現在、サポートされていません。

ヒント

sfZonalUpgradeMode を Hierarchical に設定するか、省略することをお勧めします。デプロイは、VM のゾーン分布に従い、影響を与えるレプリカやインスタンスの数を減らして、それらの安全性を高めます。デプロイ速度を優先する場合、またはステートレスワークロードだけが、複数の可用性ゾーンを含むノードタイプで実行される場合は、sfZonalUpgradeMode を Parallel に設定します。これにより、UD ウォークがすべての可用性ゾーンで並列に実行されます。

複数の可用性ゾーンを持つノードタイプに移行する

すべての移行シナリオで、複数の可用性ゾーンをサポートする新しいノードタイプを追加する必要があります。既存のノードタイプを移行して複数のゾーンをサポートすることはできません。「Service Fabric クラスターのプライマリノードタイプをスケールアップする」の記事には、新しいノードタイプと、新しいノードタイプに必要なその他のリソース (IP やロードバランサーのリソースなど) を追加する詳細な手順が記載されています。その記事には、複数の可用性ゾーンを持つ新しいノードタイプがクラスターに追加された後、既存のノードタイプをインベントリから削除する方法も記載されています。

基本的なロードバランサーと IP リソースを使用するノードタイプからの移行: このプロセスは、可用性ゾーンごとに 1 つのノードタイプを使用するソリューションに関する以下のサブセクションで説明しています。

新しいノードタイプの場合、唯一の違いは、可用性ゾーンごとに 1 つではなく、すべての可用性ゾーンに対して仮想マシンスケールセットが 1 つ、ノードタイプが 1 つだけであるということです。
NSG とともに Standard SKU ロードバランサーと IP リソースを使用するノードタイプからの移行: 前述のものと同じ手順に従います。ただし、新しいロードバランサー、IP、NSG のリソースを追加する必要はありません。同じリソースを新しいノードタイプで再利用できます。

問題が発生した場合は、サポートにお問い合わせください。

移行オプション 2: 1 つの仮想マシンスケールセットを各ゾーンに固定することでゾーンをデプロイする

このオプションを使用するタイミング

これは、現在一般提供されている構成です。

Service Fabric クラスターを可用性ゾーン間にまたがらせるには、リージョンでサポートされている各可用性ゾーンにプライマリノードタイプを作成する必要があります。これにより、各プライマリノードタイプ間にシードノードが均等に分散されます。

プライマリノードタイプの推奨されるトポロジでは、以下が必要です。

プライマリとしてマークされた 3 つのノードタイプ
- 各ノードタイプは異なるゾーンに配置されているその独自の仮想マシンスケールセットにマップされている必要があります。
- 各仮想マシンスケールセットには少なくとも 5 つのノード (Silver 耐久性) が必要です。

既存の Standard SKU ロードバランサーと IP リソースを使用して Service Fabric 非マネージドクラスターを移行する方法

仮想マシンスケールセットでゾーンを有効にする

ゾーンを有効にするには、仮想マシンスケールセットで、仮想マシンスケールセットリソースに次の 3 つの値を含めます。

最初の値は、zones プロパティであり、仮想マシンスケールセットをデプロイする可用性ゾーンを指定します。
2 つ目の値は、singlePlacementGroup プロパティであり、true に設定する必要があります。
3 つ目の値は、Service Fabric 仮想マシンスケールセット拡張機能の faultDomainOverride プロパティです。このプロパティには、この仮想マシンスケールセットを配置するゾーンのみを含める必要があります。例: "faultDomainOverride": "az1". Azure Service Fabric クラスターにはクロスリージョンのサポートがないため、すべての仮想マシンスケールセットリソースを同じリージョンに配置する必要があります。

{
  "apiVersion": "2018-10-01",
  "type": "Microsoft.Compute/virtualMachineScaleSets",
  "name": "[parameters('vmNodeType1Name')]",
  "location": "[parameters('computeLocation')]",
  "zones": [
    "1"
  ],
  "properties": {
    "singlePlacementGroup": true
  },
  "virtualMachineProfile": {
    "extensionProfile": {
      "extensions": [
        {
          "name": "[concat(parameters('vmNodeType1Name'),'_ServiceFabricNode')]",
          "properties": {
            "type": "ServiceFabricNode",
            "autoUpgradeMinorVersion": false,
            "publisher": "Microsoft.Azure.ServiceFabric",
            "settings": {
              "clusterEndpoint": "[reference(parameters('clusterName')).clusterEndpoint]",
              "nodeTypeRef": "[parameters('vmNodeType1Name')]",
              "dataPath": "D:\\\\SvcFab",
              "durabilityLevel": "Silver",
              "certificate": {
                "thumbprint": "[parameters('certificateThumbprint')]",
                "x509StoreName": "[parameters('certificateStoreValue')]"
              },
              "systemLogUploadSettings": {
                "Enabled": true
              },
              "faultDomainOverride": "az1"
            },
            "typeHandlerVersion": "1.0"
          }
        }
      ]
    }
  }
}

Service Fabric クラスターリソースで複数のプライマリノードタイプを有効にする

クラスターリソースで 1 つまたは複数のノードタイプをプライマリとして設定するには、isPrimary プロパティを true に設定します。可用性ゾーンにまたがって Service Fabric クラスターをデプロイする場合、個別のゾーンに 3 つのノードタイプが必要です。

{
  "reliabilityLevel": "Platinum",
  "nodeTypes": [
    {
      "name": "[parameters('vmNodeType0Name')]",
      "applicationPorts": {
        "endPort": "[parameters('nt0applicationEndPort')]",
        "startPort": "[parameters('nt0applicationStartPort')]"
      },
      "clientConnectionEndpointPort": "[parameters('nt0fabricTcpGatewayPort')]",
      "durabilityLevel": "Silver",
      "ephemeralPorts": {
        "endPort": "[parameters('nt0ephemeralEndPort')]",
        "startPort": "[parameters('nt0ephemeralStartPort')]"
      },
      "httpGatewayEndpointPort": "[parameters('nt0fabricHttpGatewayPort')]",
      "isPrimary": true,
      "vmInstanceCount": "[parameters('nt0InstanceCount')]"
    },
    {
      "name": "[parameters('vmNodeType1Name')]",
      "applicationPorts": {
        "endPort": "[parameters('nt1applicationEndPort')]",
        "startPort": "[parameters('nt1applicationStartPort')]"
      },
      "clientConnectionEndpointPort": "[parameters('nt1fabricTcpGatewayPort')]",
      "durabilityLevel": "Silver",
      "ephemeralPorts": {
        "endPort": "[parameters('nt1ephemeralEndPort')]",
        "startPort": "[parameters('nt1ephemeralStartPort')]"
      },
      "httpGatewayEndpointPort": "[parameters('nt1fabricHttpGatewayPort')]",
      "isPrimary": true,
      "vmInstanceCount": "[parameters('nt1InstanceCount')]"
    },
    {
      "name": "[parameters('vmNodeType2Name')]",
      "applicationPorts": {
        "endPort": "[parameters('nt2applicationEndPort')]",
        "startPort": "[parameters('nt2applicationStartPort')]"
      },
      "clientConnectionEndpointPort": "[parameters('nt2fabricTcpGatewayPort')]",
      "durabilityLevel": "Silver",
      "ephemeralPorts": {
        "endPort": "[parameters('nt2ephemeralEndPort')]",
        "startPort": "[parameters('nt2ephemeralStartPort')]"
      },
      "httpGatewayEndpointPort": "[parameters('nt2fabricHttpGatewayPort')]",
      "isPrimary": true,
      "vmInstanceCount": "[parameters('nt2InstanceCount')]"
    }
  ]
}

問題が発生した場合は、サポートにお問い合わせください。

移行オプション: Basic SKU ロードバランサーと IP リソースを使用して Service Fabric 非マネージドクラスター

このオプションを使用するタイミング

このオプションは、移行する Basic SKU ロードバランサーと IP リソースを含む既存の Service Fabric 非マネージドクラスターがある場合に使用する必要があります。既存の非マネージドクラスターに Standard SKU リソースがある場合は、上に移行オプションが表示されます。非マネージドクラスターをまだ作成していないが、AZ 対応にすることがわかっている場合は、Standard SKU リソースを使用して作成します。

Basic SKU ロードバランサーと IP リソースを使用して Service Fabric 非マネージドクラスターを移行する方法

Basic SKU でロードバランサーと IP を使用しているクラスターを移行するには、まず Standard SKU を使用したまったく新しいロードバランサーと IP リソースを作成する必要があります。これらのリソースを更新することはできません。

使用する新しいクロス可用性ゾーンノードタイプで新しいロードバランサーと IP を参照します。前述の例では、3 つの新しい仮想マシンスケールセットのリソースがゾーン 1、2、3 に追加されています。これらの仮想マシンスケールセットは、新しく作成されたロードバランサーと IP を参照し、Service Fabric クラスターリソース内でプライマリノードタイプとしてマークされます。

まず、既存の Azure Resource Manager テンプレートに新しいリソースを追加します。これらのリソースには次が含まれます。
- Standard SKU を使用したパブリック IP リソース
- Standard SKU を使用したロードバランサーリソース
- 仮想マシンスケールセットをデプロイするサブネットによって参照されている NSG
- プライマリとしてマークされた 3 つのノードタイプ
  - 各ノードタイプは異なるゾーンに配置されているその独自の仮想マシンスケールセットにマップされている必要があります。
  - 各仮想マシンスケールセットには少なくとも 5 つのノード (Silver 耐久性) が必要です。
これらのリソースの例については、サンプルテンプレートを参照してください。
```
New-AzureRmResourceGroupDeployment `
    -ResourceGroupName $ResourceGroupName `
    -TemplateFile $Template `
    -TemplateParameterFile $Parameters
```

リソースのデプロイが完了したら、元のクラスターから、プライマリノードタイプのノードを無効にできます。ノードを無効にすると、システムサービスが、前にデプロイした新しいプライマリノードタイプに移行されます。

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

Write-Host "Connected to cluster"

$nodeNames = @("_nt0_0", "_nt0_1", "_nt0_2", "_nt0_3", "_nt0_4")

Write-Host "Disabling nodes..."
foreach($name in $nodeNames) {
    Disable-ServiceFabricNode -NodeName $name -Intent RemoveNode -Force
}

ノードをすべて無効にすると、ゾーンに分散されたプライマリノードタイプで、システムサービスが実行されます。その後、無効にしたノードをクラスターから削除できます。ノードを削除したら、元の IP、ロードバランサー、仮想マシンスケールセットリソースを削除できます。

foreach($name in $nodeNames){
    # Remove the node from the cluster
    Remove-ServiceFabricNodeState -NodeName $name -TimeoutSec 300 -Force
    Write-Host "Removed node state for node $name"
}

$scaleSetName="nt0"
Remove-AzureRmVmss -ResourceGroupName $groupname -VMScaleSetName $scaleSetName -Force

$lbname="LB-cluster-nt0"
$oldPublicIpName="LBIP-cluster-0"
$newPublicIpName="LBIP-cluster-1"

Remove-AzureRmLoadBalancer -Name $lbname -ResourceGroupName $groupname -Force
Remove-AzureRmPublicIpAddress -Name $oldPublicIpName -ResourceGroupName $groupname -Force

次に、デプロイした Resource Manager テンプレートから、これらのリソースへの参照を削除します。
最後に、DNS 名とパブリック IP を更新します。

$oldprimaryPublicIP = Get-AzureRmPublicIpAddress -Name $oldPublicIpName  -ResourceGroupName $groupname
$primaryDNSName = $oldprimaryPublicIP.DnsSettings.DomainNameLabel
$primaryDNSFqdn = $oldprimaryPublicIP.DnsSettings.Fqdn

Remove-AzureRmLoadBalancer -Name $lbname -ResourceGroupName $groupname -Force
Remove-AzureRmPublicIpAddress -Name $oldPublicIpName -ResourceGroupName $groupname -Force

$PublicIP = Get-AzureRmPublicIpAddress -Name $newPublicIpName  -ResourceGroupName $groupname
$PublicIP.DnsSettings.DomainNameLabel = $primaryDNSName
$PublicIP.DnsSettings.Fqdn = $primaryDNSFqdn
Set-AzureRmPublicIpAddress -PublicIpAddress $PublicIP

問題が発生した場合は、サポートにお問い合わせください。

次の方法で共有

Service Fabric クラスターを可用性ゾーンのサポートに移行する

前提条件

Service Fabric の管理対象クラスター

Service Fabric の非マネージドクラスター

既存の Standard SKU ロードバランサーと IP リソース

Basic SKU ロードバランサーと IP リソース

ダウンタイムの要件

Service Fabric マネージドクラスター

Service Fabric の非管理対象クラスター

Service Fabric マネージドクラスターの移行

Service Fabric 非マネージドクラスターの移行オプション

移行オプション 1: 単一の仮想マシンスケールセットで、複数の可用性ゾーンを有効にする

このオプションを使用するタイミング

既存の Standard SKU ロードバランサーと IP リソースを使用して Service Fabric 非マネージドクラスターを移行する方法

Service Fabric ノードタイプでの複数ゾーンのサポートを有効にする

複数の可用性ゾーンを持つノードタイプに移行する

移行オプション 2: 1 つの仮想マシンスケールセットを各ゾーンに固定することでゾーンをデプロイする

このオプションを使用するタイミング

既存の Standard SKU ロードバランサーと IP リソースを使用して Service Fabric 非マネージドクラスターを移行する方法

仮想マシンスケールセットでゾーンを有効にする

Service Fabric クラスターリソースで複数のプライマリノードタイプを有効にする

移行オプション: Basic SKU ロードバランサーと IP リソースを使用して Service Fabric 非マネージドクラスター

このオプションを使用するタイミング

Basic SKU ロードバランサーと IP リソースを使用して Service Fabric 非マネージドクラスターを移行する方法

次のステップ

フィードバック

その他のリソース

次の方法で共有

Service Fabric クラスターを可用性ゾーンのサポートに移行する

前提条件

Service Fabric の管理対象クラスター

Service Fabric の非マネージド クラスター

既存の Standard SKU ロード バランサーと IP リソース

Basic SKU ロード バランサーと IP リソース

ダウンタイムの要件

Service Fabric マネージド クラスター

Service Fabric の非管理対象クラスター

Service Fabric マネージド クラスターの移行

Service Fabric 非マネージド クラスターの移行オプション

移行オプション 1: 単一の仮想マシン スケール セットで、複数の可用性ゾーンを有効にする

このオプションを使用するタイミング

既存の Standard SKU ロード バランサーと IP リソースを使用して Service Fabric 非マネージド クラスターを移行する方法

Service Fabric ノード タイプでの複数ゾーンのサポートを有効にする

複数の可用性ゾーンを持つノード タイプに移行する

移行オプション 2: 1 つの仮想マシン スケール セットを各ゾーンに固定することでゾーンをデプロイする

このオプションを使用するタイミング

既存の Standard SKU ロード バランサーと IP リソースを使用して Service Fabric 非マネージド クラスターを移行する方法

仮想マシン スケール セットでゾーンを有効にする

Service Fabric クラスター リソースで複数のプライマリ ノード タイプを有効にする

移行オプション: Basic SKU ロード バランサーと IP リソースを使用して Service Fabric 非マネージド クラスター

このオプションを使用するタイミング

Basic SKU ロード バランサーと IP リソースを使用して Service Fabric 非マネージド クラスターを移行する方法

次のステップ

フィードバック

その他のリソース

Service Fabric の非マネージドクラスター

既存の Standard SKU ロードバランサーと IP リソース

Basic SKU ロードバランサーと IP リソース

Service Fabric マネージドクラスター

Service Fabric マネージドクラスターの移行

Service Fabric 非マネージドクラスターの移行オプション

移行オプション 1: 単一の仮想マシンスケールセットで、複数の可用性ゾーンを有効にする

既存の Standard SKU ロードバランサーと IP リソースを使用して Service Fabric 非マネージドクラスターを移行する方法

Service Fabric ノードタイプでの複数ゾーンのサポートを有効にする

複数の可用性ゾーンを持つノードタイプに移行する

移行オプション 2: 1 つの仮想マシンスケールセットを各ゾーンに固定することでゾーンをデプロイする

既存の Standard SKU ロードバランサーと IP リソースを使用して Service Fabric 非マネージドクラスターを移行する方法

仮想マシンスケールセットでゾーンを有効にする

Service Fabric クラスターリソースで複数のプライマリノードタイプを有効にする

移行オプション: Basic SKU ロードバランサーと IP リソースを使用して Service Fabric 非マネージドクラスター

Basic SKU ロードバランサーと IP リソースを使用して Service Fabric 非マネージドクラスターを移行する方法