このブラウザーはサポートされなくなりました。
Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
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 クラスターをスケールアウトして、次の手順を実行する必要があります。
所定の位置で高速ネットワークを有効にするとダウンタイムが発生するため、既存のクラスターで高速ネットワークを有効にするためには、インフラストラクチャのスケール アウトが必要です。可用性セット内のすべての仮想マシンは、任意の既存 NIC で高速ネットワークを有効にする前に停止し、割り当てを解除する必要があるためです。
Service Fabric クラスターは、「Service Fabric のネットワーク パターン」で概要が説明されている手順に従って、既存の仮想ネットワークにデプロイできます。
クラスターの受信および送信トラフィックを制限するには、ノードの種類に対してネットワーク セキュリティ グループ (NSG) を使用することをお勧めします。 NSG で、必要なポートが開かれていることを確認します。
Service Fabric システム サービスを含むプライマリのノードの種類は、外部ロード バランサーを介して公開する必要はなく、内部ロード バランサーによって公開できます
お使いのクラスターには静的パブリック IP アドレスを使用します。
次に説明するルールは、典型的な構成における推奨最小限のものです。 また、省略可能な規則が不要な場合のために、運用クラスターに必須の規則を記載しています。 ネットワーク ピアリングや Azure Bastion のようなジャンプボックスの概念による完全なセキュリティ ロックダウンが可能です。 必須のポートを開かなかったり、IP/URL を許可しなかったりすると、クラスターの適切な動作が妨げられ、サポートされない可能性があります。
| Priority | 名前 | [ポート] | プロトコル | ソース | Destination (公開先) | アクション | Mandatory |
|---|---|---|---|---|---|---|---|
| 3900 | Azure portal | 19080 | TCP | ServiceFabric | Any | Allow | はい |
| 3910 | クライアント API | 19000 | TCP | インターネット | Any | Allow | いいえ |
| 3920 | SFX + クライアント API | 19080 | TCP | インターネット | Any | Allow | いいえ |
| 3930 | クラスター | 1025-1027 | TCP | VirtualNetwork | Any | Allow | はい |
| 3940 | エフェメラル | 49152-65534 | TCP | VirtualNetwork | Any | Allow | はい |
| 3950 | Application | 20000-30000 | TCP | VirtualNetwork | Any | Allow | はい |
| 3960 | RDP | 3389 | TCP | インターネット | Any | 拒否 | いいえ |
| 3970 | SSH | 22 | TCP | インターネット | Any | 拒否 | いいえ |
| 3980 | カスタム エンドポイント | 443 | TCP | インターネット | Any | 拒否 | いいえ |
受信セキュリティ規則に関する詳細:
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 が必要な場合。
カスタム エンドポイント。 アプリケーションでインターネット アクセス可能なエンドポイントを有効にする例。
注意
インターネットをソースとするほとんどの規則では、既知のネットワークに制限することを検討してください (理想的には、CIDR ブロックで定義します)。
| Priority | 名前 | [ポート] | プロトコル | ソース | Destination (公開先) | アクション | Mandatory |
|---|---|---|---|---|---|---|---|
| 4010 | リソース プロバイダー | 443 | TCP | Any | ServiceFabric | Allow | はい |
| 4020 | バイナリのダウンロード | 443 | TCP | Any | AzureFrontDoor.FirstParty | Allow | はい |
送信セキュリティ規則に関する詳細:
リソース プロバイダー。 ARM デプロイなどの管理操作や、シード ノードの選択やプライマリ ノードの種類のアップグレードのような必須の操作を受け取るための、UpgradeService と Service Fabric リソース プロバイダー間の接続。
バイナリのダウンロード。 バイナリの取得にアドレス download.microsoft.com を使用しているアップグレード サービス。このリレーションシップは、セットアップ、再イメージ化、およびランタイム アップグレードに必要です。 "内部専用" ロード バランサーのシナリオでは、ポート 443 での送信トラフィックを許可する規則を指定して、追加の外部ロード バランサーを追加する必要があります。 必要に応じて、セットアップが成功した後でこのポートをブロックできますが、その場合、アップグレード パッケージをノードに配布するか、短時間だけポートを開く必要があり、後で手動アップグレードが必要になります。
Azure Firewall と共に NSG フロー ログとトラフィック分析を使って、接続の問題を追跡します。 Service Fabric と NSG の ARM テンプレートは、始めるのに適した例です。
注意
ノード間の通信を確保するため、既定のネットワーク セキュリティ規則を上書きしないようにする必要があります。 ネットワーク セキュリティ グループ - しくみ。 もう 1 つ例を挙げると、証明書失効リスト チェックを実行するには、ポート 80 での送信接続が必要です。
追加のシナリオはすべて Azure サービス タグでカバーできます。
Azure DevOps (サービス タグ: AzureCloud) の従来の PowerShell タスクでは、クラスターへのクライアント API アクセスが必要です。たとえば、アプリケーションのデプロイや運用タスクです。 これは、ARM アプリケーション リソースを含む ARM テンプレートのみのアプローチ には適用されません。
| Priority | 名前 | [ポート] | プロトコル | ソース | Destination (公開先) | アクション | 方向 |
|---|---|---|---|---|---|---|---|
| 3915 | Azure DevOps | 19000 | TCP | AzureCloud | Any | Allow | 受信 |
Windowsオペレーティングシステムにパッチを適用するためのベストプラクティスは、OSディスクを自動OSイメージアップグレードに置き換えることです。追加のルールは必要ありません。 パッチオーケストレーションアプリケーションは、Windows Updateがオペレーティングシステムパッチを適用するVM内アップグレードを管理しています。これには、更新バイナリをダウンロードするためにダウンロードセンター（サービスタグ：AzureUpdateDelivery）にアクセスする必要があります。
| Priority | 名前 | [ポート] | プロトコル | ソース | Destination (公開先) | アクション | 方向 |
|---|---|---|---|---|---|---|---|
| 4015 | Windows の更新プログラム | 443 | TCP | Any | AzureUpdateDelivery | Allow | 送信 |
Azure API Management (サービスタグ: ApiManagement) の統合には、クラスターからエンドポイント情報を照会するためのクライアント API アクセスが必要です。
| Priority | 名前 | [ポート] | プロトコル | ソース | Destination (公開先) | アクション | 方向 |
|---|---|---|---|---|---|---|---|
| 3920 | API Management | 19080 | TCP | ApiManagement | Any | Allow | 受信 |
Windows コンテナー ワークロードを実行するには、Open ネットワーク モードを使用してサービス間の通信を容易にします。
Traefik や Service Fabric リバース プロキシなどのリバース プロキシを使用して、80 や 443 などの一般的なアプリケーション ポートを公開します。
Azure クラウド ストレージからベース レイヤーをプルできない、インターネットから物理的に隔離されたエアギャップ マシン上でホストされている Windows コンテナーでは、Docker デーモンの --allow-nondistributable-artifacts フラグを使用して、外部レイヤーの動作を上書きします。
トレーニング
モジュール
Azure Kubernetes Service (AKS) と AKS ハイブリッドで実行されている Windows コンテナーにネットワークの概念を適用する - Training
Azure Kubernetes Service (AKS) と AKS ハイブリッドで実行されている Windows コンテナーに関して、実際の問題を解決するのに役立つネットワークの概念について説明します。
認定資格
Microsoft Certified: Azure Network Engineer Associate - Certifications
Azure ネットワーク インフラストラクチャ、負荷分散トラフィック、ネットワーク ルーティングなどの設計、実装、メンテナンスのデモを行います。
ドキュメント
Azure Service Fabric のネットワーク パターン - Azure Service Fabric
Service Fabric の一般的なネットワーク パターンと、Azure のネットワーク機能を使用してクラスターを作成する方法について説明します。
Service Fabric マネージド クラスターのネットワーク設定を構成する - Azure Service Fabric
NSG ルール、RDP ポート アクセス、負荷分散規則などに関して Service Fabric マネージド クラスターを構成する方法について説明します。
Azure Service Fabric セキュリティに関するベスト プラクティス - Azure Service Fabric
Azure Service Fabric クラスターとアプリケーションを安全に保つためのベストプラクティスと設計上の考慮事項。