ネットワーク

Azure Service Fabric のクラスターを作成し、管理するときには、ノードとアプリケーションにネットワーク接続を提供します。 ネットワーク リソースには、IP アドレス範囲、仮想ネットワーク、ロード バランサー、およびネットワーク セキュリティ グループが含まれます。 この記事では、これらのリソースのベスト プラクティスについて学習します。

Azure の「Service Fabric のネットワーク パターン」を調べ直して、次の機能を使用するクラスターの作成方法を学びます。既存の仮想ネットワークまたはサブネット、静的パブリック IP アドレス、内部専用ロード バランサー、内部および外部ロード バランサー。

インフラストラクチャ ネットワーク

Resource Manager テンプレートで enableAcceleratedNetworking プロパティを宣言することにより、高速ネットワークでの仮想マシンのパフォーマンスを最大にします。高速ネットワークを有効にする、仮想マシン スケール セットの NetworkInterfaceConfigurations のスニペットを次に示します。

"networkInterfaceConfigurations": [
  {
    "name": "[concat(variables('nicName'), '-0')]",
    "properties": {
      "enableAcceleratedNetworking": true,
      "ipConfigurations": [
        {
        <snip>
        }
      ],
      "primary": true
    }
  }
]

Service Fabric クラスターは、高速ネットワークを導入した Linux と高速ネットワークを導入した Windows でプロビジョニングできます。

高速ネットワークは、Azure 仮想マシン シリーズの次の SKU でサポートされています。D/DSv2、D/DSv3、E/ESv3、F/FS、FSv2、Ms/Mms。 高速ネットワークのテストは、Service Fabric Windows クラスターについては 2019 年 1 月 23 日に Standard_DS8_v3 SKU を使用して、Service Fabric Linux クラスターについては 2019 年 1 月 29 日に Standard_DS12_v2 を使用して、問題なく行われました。 高速ネットワークには 4 つ以上の vCPU が必要であることに注意してください。

既存の Service Fabric クラスターで高速ネットワークを有効にするには、最初に仮想マシン スケール セットを追加することで Service Fabric クラスターをスケールアウトして、次の手順を実行する必要があります。

1. 高速ネットワークを有効にして 1 つの NodeType をプロビジョニングします
2. 高速ネットワークを有効にしてプロビジョニングした NodeType に、サービスとその状態を移行します

所定の位置で高速ネットワークを有効にするとダウンタイムが発生するため、既存のクラスターで高速ネットワークを有効にするためには、インフラストラクチャのスケール アウトが必要です。可用性セット内のすべての仮想マシンは、任意の既存 NIC で高速ネットワークを有効にする前に停止し、割り当てを解除する必要があるためです。

クラスター ネットワーク

• Service Fabric クラスターは、「Service Fabric のネットワーク パターン」で概要が説明されている手順に従って、既存の仮想ネットワークにデプロイできます。

• クラスターの受信および送信トラフィックを制限するには、ノードの種類に対してネットワーク セキュリティ グループ (NSG) を使用することをお勧めします。 NSG で、必要なポートが開かれていることを確認します。

• Service Fabric システム サービスを含むプライマリのノードの種類は、外部ロード バランサーを介して公開する必要はなく、内部ロード バランサーによって公開できます

• お使いのクラスターには静的パブリック IP アドレスを使用します。

ネットワーク セキュリティの規則

次に説明するルールは、典型的な構成における推奨最小限のものです。 また、省略可能な規則が不要な場合のために、運用クラスターに必須の規則を記載しています。 ネットワーク ピアリングや Azure Bastion のようなジャンプボックスの概念による完全なセキュリティ ロックダウンが可能です。 必須のポートを開かなかったり、IP/URL を許可しなかったりすると、クラスターの適切な動作が妨げられ、サポートされない可能性があります。

着信

受信セキュリティ規則に関する詳細:

• Azure Portal このポートは、クラスターに関する情報のクエリを実行し、Azure 管理ポータルに表示する際に Service Fabric リソース プロバイダーによって使われます。 Service Fabric リソース プロバイダーからこのポートにアクセスできない場合、"ノードが見つかりません" や "UpgradeServiceNotReachable" といったメッセージが Azure portal に表示され、ノードとアプリケーションの一覧には何も表示されません。 つまり、Azure の管理ポータルにクラスターが表示されるようにするには、ロード バランサーでパブリック IP アドレスが公開されており、NSG で受信 19080 トラフィックが許可されている必要があります。 このポートは、より高い信頼性を保証するための Service Fabric リソース プロバイダーからの拡張管理操作に推奨されます。

• クライアント API。 PowerShell に使われる API のクライアント接続エンドポイント。

• SFX + クライアント API。 このポートは、Service Fabric Explorer からクラスターを参照して管理するために使われます。 同様に、REST/PowerShell (Microsoft.ServiceFabric.PowerShell.Http)/CLI/.NET などの一般的な API でも使われます。

• クラスター。 ノード間通信を使用します。

• エフェメラル。 Service Fabric がこれらのポートの一部をアプリケーション ポートとして使用し、残りは OS に使用できます。 また、この範囲が OS にある既存の範囲にマップされるため、ここのサンプルで指定した範囲はあらゆる用途に使用できます。 開始ポートと終了ポートの差は 255 以上にしてください。 この範囲は OS と共有されるため、この差が小さすぎると競合が発生する場合があります。 構成されている動的ポート範囲を確認するには、netsh int ipv4 show dynamicport tcp を実行します。 これらのポートは、Linux クラスターの場合は必要ありません。

• アプリケーション。 アプリケーション ポートの範囲は、アプリケーションのエンドポイント要求に対応できるように十分な大きさにする必要があります。 この範囲は、マシン上の動的なポートの範囲 (つまり、構成で設定されている ephemeralPorts の範囲) とは排他的である必要があります。 Service Fabric では、新しいポートが必要なときはこれらのポートが常に使用され、ノード上でこれらのポートに対してファイアウォールを開く処理が行われます。

• RDP。 省略可能。ジャンプボックスのシナリオでインターネットまたは VirtualNetwork から RDP が必要な場合。

• SSH。 省略可能。ジャンプボックスのシナリオでインターネットまたは VirtualNetwork から SSH が必要な場合。

• カスタム エンドポイント。 アプリケーションでインターネット アクセス可能なエンドポイントを有効にする例。

送信

送信セキュリティ規則に関する詳細:

• リソース プロバイダー。 ARM デプロイなどの管理操作や、シード ノードの選択やプライマリ ノードの種類のアップグレードのような必須の操作を受け取るための、UpgradeService と Service Fabric リソース プロバイダー間の接続。

• バイナリのダウンロード。 バイナリの取得にアドレス download.microsoft.com を使用しているアップグレード サービス。このリレーションシップは、セットアップ、再イメージ化、およびランタイム アップグレードに必要です。 "内部専用" ロード バランサーのシナリオでは、ポート 443 での送信トラフィックを許可する規則を指定して、追加の外部ロード バランサーを追加する必要があります。 必要に応じて、セットアップが成功した後でこのポートをブロックできますが、その場合、アップグレード パッケージをノードに配布するか、短時間だけポートを開く必要があり、後で手動アップグレードが必要になります。

Azure Firewall と共に NSG フロー ログとトラフィック分析を使って、接続の問題を追跡します。 Service Fabric と NSG の ARM テンプレートは、始めるのに適した例です。

追加のルールを必要とする一般的なシナリオ

追加のシナリオはすべて Azure サービス タグでカバーできます。

Azure DevOps

Azure DevOps (サービス タグ: AzureCloud) の従来の PowerShell タスクでは、クラスターへのクライアント API アクセスが必要です。たとえば、アプリケーションのデプロイや運用タスクです。 これは、ARM アプリケーション リソースを含む ARM テンプレートのみのアプローチ には適用されません。

Windows の更新

Windowsオペレーティングシステムにパッチを適用するためのベストプラクティスは、OSディスクを自動OSイメージアップグレードに置き換えることです。追加のルールは必要ありません。 パッチオーケストレーションアプリケーションは、Windows Updateがオペレーティングシステムパッチを適用するVM内アップグレードを管理しています。これには、更新バイナリをダウンロードするためにダウンロードセンター（サービスタグ：AzureUpdateDelivery）にアクセスする必要があります。

API Management

Azure API Management (サービスタグ: ApiManagement) の統合には、クラスターからエンドポイント情報を照会するためのクライアント API アクセスが必要です。

アプリケーション ネットワーク

• Windows コンテナー ワークロードを実行するには、Open ネットワーク モードを使用してサービス間の通信を容易にします。

• Traefik や Service Fabric リバース プロキシなどのリバース プロキシを使用して、80 や 443 などの一般的なアプリケーション ポートを公開します。

• Azure クラウド ストレージからベース レイヤーをプルできない、インターネットから物理的に隔離されたエアギャップ マシン上でホストされている Windows コンテナーでは、Docker デーモンの --allow-nondistributable-artifacts フラグを使用して、外部レイヤーの動作を上書きします。

次のステップ

• Windows Server を実行している VM またはコンピューター上にクラスターを作成する:Windows Server 用の Service Fabric クラスターの作成
• Linux を実行している VM またはコンピューター上にクラスターを作成する:Linux クラスターの作成
• Service Fabric のサポート オプションについて学びます。