クラスターのデプロイを計画および準備する

[アーティクル]
06/01/2023

運用環境クラスターのデプロイの計画と準備は非常に重要です。考慮すべき要因が数多くあります。この記事では、クラスターのデプロイを準備する手順について説明します。

ベストプラクティス情報を読む

Azure Service Fabric アプリケーションとクラスターを正常に管理するために、実行することを強くお勧めする操作があります。この操作によって運用環境の信頼性を最適化します。詳細については、「Azure Service Fabric のアプリケーションとクラスターに関するベストプラクティス」を参照してください。

クラスターの OS を選択する

Service Fabric を使用すると、Windows Server または Linux を実行するすべての VM またはコンピューター上に Service Fabric クラスターを作成できます。クラスターをデプロイする前に、OS を選択する必要があります。Windows または Linux。クラスター内のすべてのノード (仮想マシン) が同じ OS を実行するため、同じクラスター内で Windows VM と Linux VM を混在させることはできません。

容量計画

容量計画は、運用環境へのデプロイにおいて重要なステップとなります。ここでは、そのプロセスの一環として考慮すべき事柄の一部を取り上げます。

クラスターのノードタイプの初期数
ノードタイプごとの特性 (サイズ、インスタンス数、プライマリ/非プライマリ、インターネット接続、VM 数など)
クラスターの信頼性と耐久性の特徴

ノードタイプの初期数を選択する

最初に、作成するクラスターの使用目的について考えておく必要があります。このクラスターにどのような種類のアプリケーションを展開する予定があるでしょうか。アプリケーションに複数のサービスが存在するか、またその中に、外部に公開 (インターネットに接続) しなければならないサービスはあるか。アプリケーションの構成要素として、インフラストラクチャニーズの異なる複数のサービスが存在するか (大容量の RAM が必要、高い CPU 処理能力が必要など)。 Service Fabric クラスターは、複数のノードタイプ (1 つのプライマリノードタイプと 1 つ以上の非プライマリノードタイプ) で構成できます。ノードタイプはそれぞれ 1 つの仮想マシンスケールセットに対応付けられます。各ノードの種類は、個別にスケールアップまたはスケールダウンすることができ、さまざまなセットのポートを開き、異なる容量のメトリックスを持つことができます。ノードのプロパティと配置の制約は、特定のサービスを特定のノードタイプに制約するように設定できます。詳細については、Service Fabric クラスターの容量計画に関する記事を参照してください。

各ノードタイプのノードプロパティを選択する

ノードタイプは、関連付けられたスケールセット内の VM の VM SKU、数、プロパティを定義します。

各ノードタイプの最小 VM サイズは、そのノードタイプに選択した耐久性レベルによって決まります。 VM SKU を選択する前に、将来別の VM SKU が必要になると判断される場合は、必ず、垂直スケーリングに必要な手順を理解してください。

プライマリノードタイプの最低 VM 数は、選択した信頼性レベルによって決まります。

プライマリノードタイプ、非プライマリノードタイプのステートフルワークロード、非プライマリノードタイプのステートレスワークロードに関する最小推奨事項を参照してください。

最小ノード数を超える数は、このノードタイプで実行するアプリケーション/サービスのレプリカ数に基づいて決定する必要があります。「Service Fabric アプリケーションの容量計画」をご覧いただくと、アプリケーションの実行に必要なリソースを見積もるのに役立ちます。変化するアプリケーションのワークロードに合わせて調整するために、後でいつでもクラスターをスケールアップまたはスケールダウンできます。

仮想マシンスケールセットにエフェメラル OS ディスクを使用する

"エフェメラル OS ディスク" は、ローカル仮想マシン (VM) 上に作成されるストレージであり、リモート Azure Storage には保存されません。エフェメラル OS ディスクは、従来の永続 OS ディスクと比べて、次のような特徴を持っているため、すべての Service Fabric ノードの種類 (プライマリとセカンダリ) で推奨されます。

OS ディスクへの読み取り/書き込み待機時間が短縮される
ノード管理操作を素早くリセット/再イメージ化できる
全体的なコストが削減される (ディスクは無料であり、追加のストレージコストは発生しません)

エフェメラル OS ディスクは特定の Service Fabric の機能ではなく、Service Fabric ノードの種類にマップされる Azure "仮想マシンスケールセット" の機能です。これらを Service Fabric で使用するには、クラスターの Azure Resource Manager テンプレートで次のものが必要です。

ノードの種類で、エフェメラル OS ディスクに対してサポートされている Azure VM サイズが指定されており、その VM サイズに、OS ディスクサイズをサポートするのに十分なキャッシュサイズが含まれていることを確認します (下記の「注意」を参照)。次に例を示します。
```
"vmNodeType1Size": {
    "type": "string",
    "defaultValue": "Standard_DS3_v2"
```
Note

VM 自体の OS ディスクサイズ以上のキャッシュを持つ VM サイズを選択してください。そうしないと、(最初は受け入れられても、) Azure のデプロイでエラーが発生する可能性があります。
2018-06-01 以降の仮想マシンスケールセットのバージョン (vmssApiVersion) を指定してください。
```
"variables": {
    "vmssApiVersion": "2018-06-01",
```

デプロイテンプレートの [virtual machine scale set](仮想マシンスケールセット) セクションで、diffDiskSettings に対して Local オプションを指定します。

"apiVersion": "[variables('vmssApiVersion')]",
"type": "Microsoft.Compute/virtualMachineScaleSets",
    "virtualMachineProfile": {
        "storageProfile": {
            "osDisk": {
                    "caching": "ReadOnly",
                    "createOption": "FromImage",
                    "diffDiskSettings": {
                        "option": "Local"
                    },
            }
        }
    }

Note

OS ディスクは、OS のアップグレード時に失われるため、ユーザーアプリケーションは OS ディスクに依存関係、ファイル、成果物を持つことはできません。

Note

エフェメラルディスクを使用するために、エフェメラルではない既存のディスク VMSS をインプレースアップグレードすることはできません。移行するには、ユーザーは、エフェメラルディスクを含む新しい nodeType を追加して、ワークロードをその新しい nodeType に移動させ、既存の nodeType を削除する必要があります。

詳細およびその他の構成オプションについては、「Azure VM のエフェメラル OS ディスク」を参照してください。

クラスターの耐久性レベルと信頼性レベルを選択する

耐久性レベルは、ご利用の VM が、基になる Azure インフラストラクチャに対して持つ特権をシステムに表明する目的で使用します。プライマリノードタイプでは、Service Fabric がこの特権を使って、システムサービスやステートフルサービスのクォーラム要件に影響を及ぼす、VM レベルのインフラストラクチャ要求 (VM の再起動、VM の再イメージ化、VM の移行など) を一時停止させることができます。非プライマリノードタイプの場合も、Service Fabric がこの特権の下で、ステートフルサービスのクォーラム要件に影響を及ぼす、VM レベルのインフラストラクチャ要求 (VM の再起動、VM の再イメージ化、VM の移行など) を一時停止させることができます。各レベルの利点、およびどのレベルをどの時点で使用するかについての推奨事項については、「クラスターの耐久性の特徴」を参照してください。

信頼性レベルは、クラスターのプライマリノードタイプで実行するシステムサービスのレプリカ数を設定する目的で使用します。レプリカ数が増えるほど、クラスター内のシステムサービスの信頼性が上がります。各レベルの利点、およびどのレベルをどの時点で使用するかについての推奨事項については、「クラスターの信頼性の特徴」を参照してください。

リバースプロキシおよび/または DNS を有効にする

クラスター内の各ノードは同じローカルネットワーク上にあるため、クラスター内で相互接続しているサービスは、通常、他のサービスのエンドポイントに直接アクセスできます。サービス間の接続を容易にするために、Service Fabric には追加サービスとしてDNS サービスとリバースプロキシサービスが用意されています。クラスターをデプロイするときに両方のサービスを有効にできます。

コンテナー化されたサービスなど多くのサービスには既存の URL 名が含まれるため、標準の DNS プロトコル (Naming Service プロトコルではなく) を使用してこれらを解決できます。これは特にアプリケーションの移行 (リフトアンドシフト) シナリオで便利です。まさにこれが、DNS サービスの役割です。 DNS 名をサービス名にマップして、エンドポイントの IP アドレスを解決できます。

リバースプロキシは、HTTP エンドポイント (HTTPS を含む) を公開するクラスター内のサービスを処理します。リバースプロキシは、特定の URI 形式を提供することによって他のサービスの呼び出しを大幅に簡略化します。リバースプロキシは、あるサービスが別のサービスと通信するために必要な解決、接続、再試行の各ステップも処理します。

ディザスターリカバリーの準備

高可用性を実現するうえで欠かせないのは、サービスがあらゆる種類の障害を切り抜けられるようにすることです。これは、計画外の障害や、制御できない障害に関しては特に重要です。ディザスターリカバリーの準備に関する記事では、正しくモデル化および管理されていない場合に、災害につながる可能性がある一般的な障害モードをいくつか取り上げて説明します。さらに、災害が発生した場合の軽減策や対処方法についても解説します。

運用環境の準備状況チェックリスト

お使いのアプリケーションとクラスターは、運用環境のトラフィックに対応する準備ができていますか。クラスターを運用環境にデプロイする前に、「運用環境の準備状況チェックリスト」の項目を実行してください。このチェックリストの項目を実行して、アプリケーションとクラスターの円滑な稼働を維持してください。運用環境に移行する前に、これらの項目すべてをチェック済みにすることを強くお勧めします。

クラスターのデプロイを計画および準備する

ベストプラクティス情報を読む

クラスターの OS を選択する

容量計画

ノードタイプの初期数を選択する

各ノードタイプのノードプロパティを選択する

仮想マシンスケールセットにエフェメラル OS ディスクを使用する

クラスターの耐久性レベルと信頼性レベルを選択する

リバースプロキシおよび/または DNS を有効にする

ディザスターリカバリーの準備

運用環境の準備状況チェックリスト

次のステップ

その他のリソース

クラスターのデプロイを計画および準備する

ベスト プラクティス情報を読む

クラスターの OS を選択する

容量計画

ノード タイプの初期数を選択する

各ノード タイプのノード プロパティを選択する

仮想マシン スケール セットにエフェメラル OS ディスクを使用する

クラスターの耐久性レベルと信頼性レベルを選択する

リバース プロキシおよび/または DNS を有効にする

ディザスター リカバリーの準備

運用環境の準備状況チェックリスト

次のステップ

その他のリソース

ベストプラクティス情報を読む

ノードタイプの初期数を選択する

各ノードタイプのノードプロパティを選択する

仮想マシンスケールセットにエフェメラル OS ディスクを使用する

リバースプロキシおよび/または DNS を有効にする

ディザスターリカバリーの準備