次の方法で共有


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

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

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

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

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

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

Note

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

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

前提条件

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

必須:

推奨:

  • クラスター 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 つまでです。 それよりも多いものは現在、サポートされていません。

ヒント

sfZonalUpgradeModeHierarchical に設定するか、省略することをお勧めします。 デプロイは、VM のゾーン分布に従い、影響を与えるレプリカやインスタンスの数を減らして、それらの安全性を高めます。 デプロイ速度を優先する場合、またはステートレス ワークロードだけが、複数の可用性ゾーンを含むノード タイプで実行される場合は、sfZonalUpgradeModeParallel に設定します。 これにより、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 非マネージド クラスターがある場合に使用する必要があります。 既存の非マネージド クラスターに Basic SKU リソースがある場合は、下に Basic SKU の移行オプションが表示されます。

既存の 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 クラスター リソース内でプライマリ ノード タイプとしてマークされます。

  1. まず、既存の Azure Resource Manager テンプレートに新しいリソースを追加します。 これらのリソースには次が含まれます。

    • Standard SKU を使用したパブリック IP リソース
    • Standard SKU を使用したロード バランサー リソース
    • 仮想マシン スケール セットをデプロイするサブネットによって参照されている NSG
    • プライマリとしてマークされた 3 つのノード タイプ
      • 各ノード タイプは異なるゾーンに配置されているその独自の仮想マシン スケール セットにマップされている必要があります。
      • 各仮想マシン スケール セットには少なくとも 5 つのノード (Silver 耐久性) が必要です。

    これらのリソースの例については、サンプル テンプレートを参照してください。

    New-AzureRmResourceGroupDeployment `
        -ResourceGroupName $ResourceGroupName `
        -TemplateFile $Template `
        -TemplateParameterFile $Parameters
    
  2. リソースのデプロイが完了したら、元のクラスターから、プライマリ ノード タイプのノードを無効にできます。 ノードを無効にすると、システム サービスが、前にデプロイした新しいプライマリ ノード タイプに移行されます。

    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
    }
    
  3. ノードをすべて無効にすると、ゾーンに分散されたプライマリ ノード タイプで、システム サービスが実行されます。 その後、無効にしたノードをクラスターから削除できます。 ノードを削除したら、元の 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
    
  4. 次に、デプロイした Resource Manager テンプレートから、これらのリソースへの参照を削除します。

  5. 最後に、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

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

次のステップ