Service Fabric クラスターの容量計画に関する考慮事項

クラスターの容量計画は、どの Service Fabric 運用環境にとっても重要です。 主な考慮事項は次のとおりです。

• クラスターのノード タイプに関する初期の数とプロパティ

• Azure インフラストラクチャ内での Service Fabric の VM の権限を決定する、各ノード タイプの持続性レベル

• クラスターの信頼性レベル。これにより、Service Fabric システム サービスとクラスター機能全体の安定性が決まります

この記事では、これらの各領域について、重要な意思決定のポイントを順次説明します。

クラスターのノード タイプに関する初期の数とプロパティ

ノード タイプにより、クラスター内の一連のノード (仮想マシン) のサイズ、数、およびプロパティが定義されます。 Service Fabric クラスターで定義されているすべてのノード タイプは、仮想マシン スケール セットにマップされます。

各ノード タイプは異なるスケール セットであるため、個別にスケールアップまたはスケールダウン可能で、異なるポートのセットを開いたり、異なる容量メトリックを設けたりすることができます。 ノード タイプと仮想マシン スケール セットの間の関係について詳しくは、Service Fabric クラスターのノード タイプに関するページを参照してください。

各クラスターには、Service Fabric プラットフォームの機能を提供する重要なシステム サービスを実行する、プライマリ ノード タイプが 1 つ必要です。 アプリケーションを実行するためにプライマリ ノード タイプを使用することもできますが、このタイプはシステム サービスの実行専用にすることが推奨されます。

非プライマリ ノード タイプを使用すると、アプリケーション ロール ("フロントエンド" サービスや "バックエンド" サービスなど) を定義し、クラスター内でサービスを物理的に分離することができます。 Service Fabric クラスターには、0 個以上の非プライマリ ノードタイプを作成できます。

プライマリ ノード タイプは、Azure Resource Manager のデプロイ テンプレートで、ノード タイプの定義の下にある isPrimary 属性を使用して構成されます。 ノード タイプのプロパティの完全な一覧については、「NodeTypeDescription オブジェクト」を参照してください。 使用例については、Service Fabric クラスター サンプルでいずれかの AzureDeploy.json ファイルを開き、 [ページ内の検索] で nodeTypes オブジェクトを検索します。

ノード タイプの計画に関する考慮事項

ノード タイプの初期数は、クラスターの目的と、そのクラスターで実行されるアプリケーションとサービスによって異なります。 次の質問について考えてみましょう。

• アプリケーションに複数のサービスがあるか、また、そのいずれかを一般に公開したりインターネットに接続したりする必要があるか。

  典型的なアプリケーションには、クライアントからの入力を受信する 1 つのフロントエンド ゲートウェイ サービスと、そのフロントエンド サービスと通信する 1 つ以上のバックエンド サービスが含まれていて、フロントエンド サービスとバックエンド サービスの間に別個のネットワークが存在します。 このような場合には、一般に、1 つのプライマリ ノード タイプと、2 つの非プライマリ ノード タイプ (フロントエンド サービス用とバックエンド サービス用にそれぞれ 1 つ) という 3 つのノード タイプが必要です。

• アプリケーションを構成するサービスに、インフラストラクチャに関して異なるニーズがあるか (より多くの RAM が必要、より高速な CPU サイクルが必要など)。

  フロントエンド サービスは、多くの場合、インターネットに対してポートを開いた、より小さな VM (D2 のようなサイズの VM) で実行できます。 計算負荷が高いバックエンド サービスは、インターネットには接続していない、より大きな VM (D4、D6、D15 のようなサイズの VM) で実行する必要がある場合があります。 これらのサービスに対して異なるノード タイプを定義すると、基になっている Service Fabric VM をより効率的かつ安全に使用することができ、それらを個別にスケーリングできるようになります。 必要になるリソースの量を見積もることの詳細については、「Service Fabric アプリケーションの容量計画」を参照してください

• いずれかのアプリケーション サービスを、100 ノードを超えてスケールアウトする必要が生じるか。

  1 つのノード タイプでは、Service Fabric アプリケーションの仮想マシン スケール セット 1 つあたり 100 ノードを超えて、信頼性高くスケーリングすることができません。 100 を超えるノードを実行するには、追加の仮想マシン スケール セット (したがって追加のノード タイプ) が必要です。

• クラスターが複数の Availability Zones にまたがることになるか。

  Service Fabric では、特定のゾーンに固定されるノード タイプをデプロイすることによって、Availability Zones にまたがるクラスターをサポートし、アプリケーションの高可用性を確保します。 Availability Zones には追加のノード タイプの計画が必要で、最小要件を満たす必要があります。 詳しくは、Availability Zones をまたがる Azure Service Fabric クラスターのプライマリ ノードのタイプのトポロジに関する記事をご覧ください。

クラスターの最初の作成でノード タイプの数とプロパティを決定するときには、いったんクラスターをデプロイすれば、(プライマリ以外の) ノード タイプをいつでも追加、変更、または削除できることを念頭に置いてください。 実行中のクラスターでも、プライマリ ノード タイプはスケールアップまたはスケールダウンできます。ただし、そのためには、新しいノード タイプを作成し、ワークロードを移動してから、元のプライマリ ノード タイプを削除する必要があります。

ノード タイプのプロパティに関するその他の考慮事項は、持続性レベルです。これにより、Azure インフラストラクチャ内でノード タイプの VM が持つ権限が決まります。 次に説明するように、クラスターのために選択した VM のサイズと、個々のノード タイプに割り当てたインスタンス数を参考にすると、ノード タイプごとに適切な耐久性レベルを決定する助けになります。

クラスターの持続性の特徴

持続性レベルによって、Service Fabric VM が、基になる Azure インフラストラクチャで持つ権限を指定します。 この権限によって、Service Fabric は、Service Fabric のシステム サービスやステートフル サービスのクォーラム要件に影響を与える VM レベルのインフラストラクチャ要求 (再起動、再イメージ化、移行など) を一時停止できます。

次の表に、Service Fabric の耐久性サービス レベル、それらの要件、提供される内容を示します。

ブロンズ

ブロンズ の持続性で実行されているノード タイプは、権限を取得しません。 つまり、ステートレス ワークロードに影響をするインフラストラクチャ ジョブが停止されたり延期されたりすることはありません。 ブロンズ の持続性は、ステートレス ワークロードだけを実行するノード タイプに対して使用します。 運用環境のワークロードの場合は、Silver 以上が実行されていることをお勧めします。

Silver と Gold

Silver または Gold の持続性は、頻繁なスケールイン (VM インスタンス数の削減) が予想されるステートフル サービスをホストするすべてのノード タイプに対して使用します。また、プロセスの簡略化を重視してデプロイ操作の延期や容量の縮小が必要な場合に使用します。 スケールアウトのシナリオは、耐久性サービス レベルの選択には影響しません。

長所

• スケールイン操作に必要な手順の数が減少します (ノードの非アクティブ化と Remove-ServiceFabricNodeState が自動的に呼び出されます)。
• インプレースの VM サイズ変更操作や Azure インフラストラクチャ操作によるデータ損失のリスクが軽減されます。

短所

• 仮想マシン スケール セットやその他の関連する Azure リソースへのデプロイが、タイムアウトになったり遅れたりする可能性があり、クラスター内やインフラストラクチャ レベルの問題によって完全にブロックされる可能性があります。
• Azure インフラストラクチャの操作中に自動化されたノードの非アクティブ化によりレプリカ ライフサイクル イベント (プライマリ スワップなど) の数が増えます。
• Azure プラットフォーム ソフトウェアまたはハードウェア メンテナンス アクティビティが発生している期間中は、ノードの稼働を停止します。 これらのアクティビティの最中は、ノードのステータスが [無効化中] や [無効] と表示されます。 これにより、一時的にクラスターの容量が削減されますが、クラスターまたはアプリケーションの可用性に影響はありません。

ノード タイプの持続性が Silver と Gold の場合のベストプラクティス

以下の推奨事項に従って、持続性が Silver または Gold であるノード タイプを管理します。

• クラスターとアプリケーションを常に正常な状態に維持し、アプリケーションが適切なタイミングですべてのサービス レプリカのライフサイクル イベント (ビルドのレプリカが停止するなど) に応答することを確認します。
• VM サイズの変更 (スケールアップ/ダウン) を行うためには、より安全な方法を採用します。 仮想マシン スケール セットの VM サイズを変更する場合は、慎重な計画と注意が必要とされます。 詳細については、Service Fabric ノード タイプのスケールアップに関するページを参照してください
• 持続性レベルが Gold または Silver である任意の仮想マシン スケール セットのノードを最小数である 5 つ保持します。 このしきい値を超えてスケールインした場合には、クラスターがエラー状態になり、削除されたノードの状態 (Remove-ServiceFabricNodeState) を手動でクリーンアップする必要があります。
• 持続性レベルが Silver または Gold の各仮想マシン スケール セットは、Service Fabric クラスター内の独自のノード タイプにマップする必要があります。 複数の仮想マシン スケール セットを 1 つのノード タイプにマッピングすると、Service Fabric クラスターと Azure インフラストラクチャ間の連携が正常に動作しなくなります。
• VM インスタンスをランダムに削除せず、仮想マシン スケール セットのスケール イン機能を常に使用してください。 ランダムな VM インスタンスを削除すると、アップグレード ドメインと障害ドメインにわたって散在する VM インスタンスで不均衡が生じる可能性があります。 この不均衡は、サービス インスタンス/サービス レプリカ間で適切に負荷分散を行うシステムの機能に悪影響を及ぼす場合があります。
• 自動スケーリングを使用する場合は、スケールイン (VM インスタンスの削除) 操作が一度に 1 ノードでのみ実行されるようにルールを設定します。 一度に複数のインスタンスをスケールインすることは安全ではありません。
• プライマリ ノード タイプで VM の削除または割り当て解除を行う場合は、割り当てられる VM の数を、その信頼性レベルで必要な数未満まで減らさないようにします。 これらの操作は、持続性レベルが Silver または Gold のスケール セットでは無期限にブロックされます。

持続性レベルの変更

一定の制約のもとでは、ノード タイプの持続性レベルを調整できます。

• 持続性レベルが Silver または Gold のノード タイプは、ブロンズ にダウングレードできません。
• 持続性レベルが Gold のノード タイプを Silver にダウングレードすることはサポートされていません。
• ブロンズからシルバーまたはゴールドにアップグレードすると、数時間がかかる場合があります。
• 持続性レベルを変更する場合は、必ず、仮想マシン スケール セット リソースの Service Fabric 拡張機能の構成と、Service Fabric クラスター リソースのノード タイプ定義の両方で、レベルを更新してください。 これらの値は一致している必要があります。

容量計画時の別の考慮事項は、クラスターの信頼性レベルです。次のセクションで説明するように、これによって、システム サービスとクラスター全体の安定性が決まります。

クラスターの信頼性の特徴

クラスターの信頼性レベルにより、クラスターのプライマリ ノード タイプで実行されるシステム サービス レプリカの数が決定されます。 レプリカが増えるほど、システム サービス (したがって全体としてのクラスター) の信頼性が高まります。

信頼性レベルは、以下のプランから選ぶことができます。

• Platinum - システム サービスは、9 個のレプリカ セット数をターゲットにして実行されます
• Gold - システム サービスは、7 個のレプリカ セット数をターゲットにして実行されます
• Silver - システム サービスは、5 個のレプリカ セット数をターゲットにして実行されます
• ブロンズ - システム サービスは、3 個のレプリカ セット数をターゲットにして実行されます

以下に、信頼性レベルを選択するときの推奨事項を示します。 シード ノードの数も、信頼性レベルのノードの最小数に設定されます。

クラスターのサイズ (すべてのノード タイプの VM インスタンスの総数) を増減するときには、クラスターの信頼性のレベルを別のレベルに更新することを検討してください。 クラスターの信頼性レベルを変更すると、システム サービスのレプリカ セット数を変更するために必要なクラスターのアップグレードが開始されます。 ノードの追加など、クラスターにさらに変更を行う場合は、このアップグレードが完了してからにしてください。 アップグレードの進行状況を監視するには、Service Fabric Explorer を使用するか、Get-ServiceFabricClusterUpgrade を実行します。

信頼性に関する容量計画

クラスターの容量ニーズは、具体的なワークロードと信頼性の要件によって決まります。 このセクションでは、容量計画を始めるのに役立つ一般的なガイダンスを提供します。

仮想マシンのサイズ設定

運用環境のワークロードでは、次の条件を満たす VM サイズ (SKU) をお勧めします。

• 2 コア以上。
• 50 GB 以上のローカル SSD。 ただし、Windows コンテナーを実行するワークロードなどの一部のワークロードでは、より大きなディスクが必要です。

既定では、ローカル SSD は 64 GB に構成されています。 このサイズは、クラスター設定の [診断] セクションの MaxDiskQuotaInMB 設定で構成することができます。

Azure でホストされているクラスターの設定を調整する方法については、Azure のクラスター構成のアップグレードに関する記事を参照してください

Windows でホストされているスタンドアロン クラスターのクラスター設定を調整する方法については、「スタンドアロン クラスターの構成をアップグレードする」を参照してください

運用環境のワークロード用にその他の VM サイズを選択する場合は、以下の制約に留意してください。

• Standard A0 のような、部分的/シングル コアの VM サイズはサポートされていません。
• "A シリーズ" VM サイズは、パフォーマンス上の理由でサポートされていません。
• 優先度の低い VM はサポートされていません。
• B シリーズのバースト可能 SKU はサポートされていません。

プライマリ ノード タイプ

Azure の運用環境ワークロードには、少なくとも 5 つのプライマリ ノード (VM インスタンス) と、Silver の信頼性レベルが必要です。 クラスターのプライマリ ノード タイプをシステム サービス専用にし、配置制約を利用してアプリケーションをセカンダリ ノード タイプにデプロイすることをお勧めします。

Azure のテスト ワークロードでは、少なくとも 1 つまたは 3 つのプライマリ ノードを実行できます。 1 つのノード クラスターを構成するには、Resource Manager テンプレートで reliabilityLevel 設定が省略されていることを確認してください (reliabilityLevel に空の文字列値を指定しても十分ではありません)。 Azure portal で 1 つのノード クラスター設定を行った場合、この構成は自動的に行われます。

非プライマリ ノード タイプ

非プライマリ ノード タイプのノードの最小数は、ノード タイプの実際の持続性レベルによって異なります。 ノードの数 (と持続性レベル) は、そのノード タイプに対して実行するアプリケーションやサービスのレプリカの数に基づいて、ワークロードがステートフルであるかステートレスであるかに応じて計画する必要があります。 クラスターをデプロイした後で、いつでも各ノード タイプの VM の数を増減できることを覚えておいてください。

ステートフル ワークロード

Service Fabric のリライアブル コレクションまたはリライアブル アクターを使用するステートフルな運用環境ワークロードの場合は、レプリカの最小数とターゲット数を 5 にすることをお勧めします。 こうすることで、安定状態では、各障害ドメインとアップグレード ドメインに (1 つのレプリカ セットから) 1 つのレプリカが配置されることになります。 一般に、ステートフル サービス用に使用するレプリカ数の基準としては、システム サービスに設定する信頼性レベルを使用します。

ステートレス ワークロード

ステートレスな運用環境ワークロードの場合、クォーラムを維持するためにサポートされる最小限の非プライマリ ノード タイプ サイズは 3 です。ただし、ノード タイプ サイズは 5 にすることが推奨されます。

次のステップ

後でクラスターを再作成する必要を軽減するために、クラスターの構成前に Not Allowed のクラスター アップグレード ポリシーを確認します。再作成しないとシステム構成設定は変更できないためです。

クラスターの計画の詳細については、以下を参照してください。

• コンピューティングの計画とスケーリング
• Service Fabric アプリケーションの容量計画
• ディザスター リカバリー計画