Availability Zones をまたがる Azure Service Fabric クラスターのデプロイ

[アーティクル]
11/21/2024

Azure の Availability Zones は高可用性を備えたサービスで、アプリケーションとデータをデータセンターの障害から保護します。可用性ゾーンは、Azure リージョン内に独立した電源、冷却手段、ネットワークを備えた一意の物理的な場所です。

複数の Availability Zones にまたがるクラスターをサポートするために、Azure Service Fabric では、次の記事で説明する 2 つの構成方法が用意されています。 Availability Zones は一部のリージョンでのみ使用できます。詳細については、「Azure のリージョンと Availability Zones」を参照してください。

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

可用性ゾーンをまたいでプライマリノードタイプを拡張する場合のトポロジ

注意

可用性ゾーンをまたいでプライマリノードタイプを拡張する利点が実際に得られるのは 3 つのゾーンの場合だけであり、2 つの場合は得られません。

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

Note

仮想マシンスケールセットの単一の配置グループプロパティを true に設定する必要があります。

次のサンプルノードリストには、ゾーンにまたがる仮想マシンスケールセット内の FD と UD の形式が示されています。

ゾーンにまたがる仮想マシンスケールセット内の FD と UD の形式のサンプルノードリストを示すスクリーンショット。

ゾーン間でのサービスレプリカの分布

サービスが可用性ゾーンにまたがるノードタイプにデプロイされている場合は、レプリカは別々のゾーンに分かれるように配置されます。これらの各ノードタイプのノードに関する障害ドメインは、ゾーン情報 (つまり、FD = fd:/zone1/1 など) で構成されます。たとえば、5 つのレプリカまたはサービスインスタンスの場合、分布は 2-2-1 となり、ランタイムはゾーン間での均等な分布を試みます。

ユーザーサービスレプリカの構成

可用性ゾーンにまたがるノードタイプにデプロイされたステートフルユーザーサービスは、たとえばレプリカ数のターゲット値が 9 で、最小値が 5 になるように構成する必要があります。この構成では、1 つのゾーンがダウンした場合でも、6 つのレプリカが他の 2 つのゾーンで稼働するため、サービスを機能させることができます。このシナリオでのアプリケーションのアップグレードも成功します。

クラスター ReliabilityLevel

この値は、クラスター内のシードノード数とシステムサービスのレプリカサイズを定義します。可用性ゾーン間のセットアップでは、ゾーンの回復性を有効にするためにゾーン間に分散されるノードの数が多くなります。

ReliabilityLevel 値を高くすると、存在するシードノードとシステムサービスレプリカが多くなり、ゾーン間で均等に分散されます。この結果、ゾーンが失敗した場合でも、クラスターとシステムサービスに影響が及ばなくなります。 ReliabilityLevel = Platinum (推奨) では、クラスター内のゾーン間にまたがる 9 つのシードノードがあり、各ゾーンに 3 つのシードが含まれます。

ゾーンダウンシナリオ

ゾーンがダウンすると、すべてのゾーンとそのゾーンのサービスレプリカがダウン状態として表示されます。残りのゾーンにレプリカが含まれるため、サービスは応答し続けます。プライマリレプリカは、機能しているゾーンにフェールオーバーします。ターゲットレプリカ数にまだ到達しておらず、仮想マシン (VM) の数がまだターゲットレプリカの最小サイズを上回っているため、サービスは警告状態で表示されます。

Service Fabric ロードバランサーにより、ターゲットレプリカの数と一致するように、作業ゾーンでレプリカが起動されます。この時点で、サービスは正常と表示されます。ダウンしたゾーンが復帰すると、ロードバランサーによってすべてのサービスレプリカがゾーンに均等に分散されます。

今後の最適化

信頼性の高いインフラストラクチャの更新を提供するために、Service Fabric では、仮想マシンスケールセットの持続性を少なくともシルバーに設定する必要があります。これにより、基になる仮想マシンスケールセットと Service Fabric ランタイムが、信頼性の高い更新を提供できるようになります。また、各ゾーンに少なくとも 5 つの VM が必要です。この要件を緩和して、プライマリノードタイプと非プライマリノードタイプでそれぞれゾーンごとに 3 つの VM と 2 つの VM にする準備を進めています。
以下のすべての構成と今後の作業により、お客様にインプレース移行が提供され、新しい nodeTypes を追加して古い nodeTypes を廃止することによって、新しい構成を使用するように同じクラスターをアップグレードできます。

ネットワーク要件

パブリック IP とロードバランサーのリソース

仮想マシンスケールセットリソースに対して zones プロパティを有効にするには、その仮想マシンスケールセットで参照されるロードバランサーと IP リソースの両方で、Standard SKU が使用されることが必要になります。 SKU プロパティを使わずに IP リソースを作成すると、Availability Zones をサポートしない Basic SKU が作成されます。 Standard SKU ロードバランサーでは、既定で外部からのすべてのトラフィックがブロックされます。外部トラフィックを許可するには、NSG をサブネットにデプロイします。

{
  "apiVersion": "2018-11-01",
  "type": "Microsoft.Network/publicIPAddresses",
  "name": "[concat('LB','-', parameters('clusterName')]",
  "location": "[parameters('computeLocation')]",
  "sku": {
    "name": "Standard"
  }
}

{
  "apiVersion": "2018-11-01",
  "type": "Microsoft.Network/loadBalancers",
  "name": "[concat('LB','-', parameters('clusterName')]",
  "location": "[parameters('computeLocation')]",
  "dependsOn": [
    "[concat('Microsoft.Network/networkSecurityGroups/', concat('nsg', parameters('subnet0Name')))]"
  ],
  "properties": {
    "addressSpace": {
      "addressPrefixes": [
        "[parameters('addressPrefix')]"
      ]
    },
    "subnets": [
      {
        "name": "[parameters('subnet0Name')]",
        "properties": {
          "addressPrefix": "[parameters('subnet0Prefix')]",
          "networkSecurityGroup": {
            "id": "[resourceId('Microsoft.Network/networkSecurityGroups', concat('nsg', parameters('subnet0Name')))]"
          }
        }
      }
    ]
  },
  "sku": {
    "name": "Standard"
  }
}

Note

パブリック IP リソースで SKU のインプレース変更を行うことはできません。 Basic SKU を使っている既存のリソースから移行する場合は、この記事の移行に関するセクションをご覧ください。

仮想マシンスケールセットの NAT 規則

ロードバランサーの受信ネットワークアドレス変換 (NAT) 規則は、仮想マシンスケールセットの NAT プールと一致している必要があります。各仮想マシンスケールセットに一意のインバウンド NAT プールが必要です。

{
  "inboundNatPools": [
    {
      "name": "LoadBalancerBEAddressNatPool0",
      "properties": {
        "backendPort": "3389",
        "frontendIPConfiguration": {
          "id": "[variables('lbIPConfig0')]"
        },
        "frontendPortRangeEnd": "50999",
        "frontendPortRangeStart": "50000",
        "protocol": "tcp"
      }
    },
    {
      "name": "LoadBalancerBEAddressNatPool1",
      "properties": {
        "backendPort": "3389",
        "frontendIPConfiguration": {
          "id": "[variables('lbIPConfig0')]"
        },
        "frontendPortRangeEnd": "51999",
        "frontendPortRangeStart": "51000",
        "protocol": "tcp"
      }
    },
    {
      "name": "LoadBalancerBEAddressNatPool2",
      "properties": {
        "backendPort": "3389",
        "frontendIPConfiguration": {
          "id": "[variables('lbIPConfig0')]"
        },
        "frontendPortRangeEnd": "52999",
        "frontendPortRangeStart": "52000",
        "protocol": "tcp"
      }
    }
  ]
}

Standard SKU ロードバランサーのアウトバウンド規則

Standard SKU パブリック IP では、Basic SKU の使用時と比べて、アウトバウンド接続に新しい機能と異なる動作が導入されています。 Standard SKU を操作しているときにアウトバウンド接続が必要な場合は、Standard SKU パブリック IP アドレスまたは Standard SKU ロードバランサーで明示的に定義する必要があります。詳細については、「アウトバウンド接続に送信元ネットワークアドレス変換 (SNAT) を使用する」と「Azure Load Balancer の概要」を参照してください。

Note

標準テンプレートでは、既定ですべてのアウトバウンドトラフィックを許可する NSG が参照されます。インバウンドトラフィックは、Service Fabric 管理操作に必要なポートに制限されます。 NSG 規則は、要件に合わせて変更できます。

重要

Standard SKU ロードバランサーを使用する Service Fabric クラスター内の各ノードタイプには、ポート 443 での送信トラフィックを許可する規則が必要です。これは、クラスターのセットアップを完了するために必要です。この規則がないデプロイは失敗します。

1. 単一の仮想マシンスケールセットで、複数の Availability Zones を有効にする

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

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

Azure 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 (リージョンごとに 5 つ) が必要です。
ブロンズの持続性を備えた仮想マシンスケールセットにまたがる可用性ゾーンには、少なくとも 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 つだけであるということです。
Standard SKU IP リソースと NSG を使うノードタイプからの移行: 前に説明したものと同じ手順に従って行います。ただし、新しい IP と NSG リソースを追加する必要はありません。同じリソースを新しいノードタイプで再利用できます。

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

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

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

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

次の図には、Azure Service Fabric 可用性ゾーンのアーキテクチャが示されています。

Azure 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 を使用してクラスターから Availability Zones に移行する

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

次の方法で共有

Availability Zones をまたがる Azure Service Fabric クラスターのデプロイ

可用性ゾーンをまたいでプライマリノードタイプを拡張する場合のトポロジ

ゾーン間でのサービスレプリカの分布

ユーザーサービスレプリカの構成

クラスター ReliabilityLevel

ゾーンダウンシナリオ

今後の最適化

ネットワーク要件

パブリック IP とロードバランサーのリソース

仮想マシンスケールセットの NAT 規則

Standard SKU ロードバランサーのアウトバウンド規則

1. 単一の仮想マシンスケールセットで、複数の Availability Zones を有効にする

仮想マシンスケールセットでのゾーンの構成

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

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

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

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

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

Basic SKU IP を使用してクラスターから Availability Zones に移行する

フィードバック

その他のリソース

次の方法で共有

Availability Zones をまたがる Azure Service Fabric クラスターのデプロイ

可用性ゾーンをまたいでプライマリ ノード タイプを拡張する場合のトポロジ

ゾーン間でのサービス レプリカの分布

ユーザー サービス レプリカの構成

クラスター ReliabilityLevel

ゾーンダウン シナリオ

今後の最適化

ネットワーク要件

パブリック IP とロード バランサーのリソース

仮想マシン スケール セットの NAT 規則

Standard SKU ロード バランサーのアウトバウンド規則

1. 単一の仮想マシン スケール セットで、複数の Availability Zones を有効にする

仮想マシン スケール セットでのゾーンの構成

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

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

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

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

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

Basic SKU IP を使用してクラスターから Availability Zones に移行する

フィードバック

その他のリソース

可用性ゾーンをまたいでプライマリノードタイプを拡張する場合のトポロジ

ゾーン間でのサービスレプリカの分布

ユーザーサービスレプリカの構成

ゾーンダウンシナリオ

パブリック IP とロードバランサーのリソース

仮想マシンスケールセットの NAT 規則

Standard SKU ロードバランサーのアウトバウンド規則

1. 単一の仮想マシンスケールセットで、複数の Availability Zones を有効にする

仮想マシンスケールセットでのゾーンの構成

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

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

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

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

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