次の方法で共有

Service Fabric マネージド クラスターのネットワーク設定を構成する

  • [アーティクル]

Service Fabric マネージド クラスターは、既定のネットワーク構成を使用して作成されます。 この構成は、パブリック IP を使用する Azure Load Balancer、1 つのサブネットが割り当てられた仮想ネットワーク、基本的なクラスター機能用に構成された NSG から成ります。 また、お客様による構成を容易にすることを目的としてすべての送信トラフィックを既定で許可するなどの、オプションの NSG ルールも適用されます。 このドキュメントでは、次のようなネットワーク構成オプションを変更する方法について説明します。

NSG ルールの管理

NSG ルールのガイダンス

マネージド クラスター用に新しい NSG ルールを作成するときは、次の点に注意してください。

  • NSG ルールの 0 から 999 の優先順位範囲は、Service Fabric マネージド クラスターにより必須機能用に予約されています。 優先順位の値が 1000 未満のカスタム NSG ルールは作成できません。
  • 3001 から 4000 の優先順位範囲は、Service Fabric マネージド クラスターによりオプションの NSG ルールの作成用に予約されています。 これらのルールは、すばやく簡単に構成できるように自動的に追加されます。 1000 から 3000 の優先順位範囲でカスタム NSG ルールを追加することにより、これらのルールを上書きできます。
  • カスタム NSG ルールは、1000 から 3000 の範囲内の優先順位にする必要があります。

NSG ルールを適用する

Service Fabric マネージド クラスターを使用すると、展開テンプレートのクラスター リソース内で NSG ルールを直接割り当てることができます。

NSG ルールを割り当てるには、Microsoft.ServiceFabric/managedclusters リソース (バージョン 2021-05-01 以降) の networkSecurityRules プロパティを使用します。 次に例を示します。

{
  "apiVersion": "2021-05-01",
  "type": "Microsoft.ServiceFabric/managedclusters",
  "properties": {
    "networkSecurityRules": [
      {
        "name": "AllowCustomers",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "Internet",
        "destinationAddressPrefix": "*",
        "destinationPortRange": "33000-33499",
        "access": "Allow",
        "priority": 2001,
        "direction": "Inbound"
      },
      {
        "name": "AllowARM",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "AzureResourceManager",
        "destinationAddressPrefix": "*",
        "destinationPortRange": "33500-33699",
        "access": "Allow",
        "priority": 2002,
        "direction": "Inbound"
      },
      {
        "name": "DenyCustomers",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "Internet",
        "destinationAddressPrefix": "*",
        "destinationPortRange": "33700-33799",
        "access": "Deny",
        "priority": 2003,
        "direction": "Outbound"
      },
      {
        "name": "DenyRDP",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "*",
        "destinationAddressPrefix": "VirtualNetwork",
        "destinationPortRange": "3389",
        "access": "Deny",
        "priority": 2004,
        "direction": "Inbound",
        "description": "Override for optional SFMC_AllowRdpPort rule. This is required in tests to avoid Sev2 incident for security policy violation."
      }
    ],
    "fabricSettings": [
      "..."
    ]
  }
}

ClientConnection と HttpGatewayConnection の既定およびオプションの規則

NSG ルール: SFMC_AllowServiceFabricGatewayToSFRP

既定の NSG ルールが追加され、Service Fabric リソース プロバイダーはクラスターの clientConnectionPort と httpGatewayConnectionPort にアクセスできるようになります。 この規則により、サービス タグ ServiceFabric を通したポートへのアクセスが許可されます。

Note

このルールは常に追加され、オーバーライドすることはできません。

{
    "name": "SFMC_AllowServiceFabricGatewayToSFRP",
    "type": "Microsoft.Network/networkSecurityGroups/securityRules",
    "properties": {
        "description": "This is required rule to allow SFRP to connect to the cluster. This rule can't be overridden.",
        "protocol": "TCP",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "ServiceFabric",
        "destinationAddressPrefix": "VirtualNetwork",
        "access": "Allow",
        "priority": 500,
        "direction": "Inbound",
        "sourcePortRanges": [],
        "destinationPortRanges": [
            "19000",
            "19080"
        ]
    }
}

NSG ルール: SFMC_AllowServiceFabricGatewayPorts

このオプションのルールを使用することで、お客様は、SFX にアクセスしたり、PowerShell を使用してクラスターに接続したり、clientConnectionPort と httpGatewayPort の LB ポートを開いてインターネットから Service Fabric クラスター API エンドポイントを使用したりできます。

Note

同じポートに同じアクセス、方向、プロトコルの値を持つカスタム ルールがある場合、このルールは追加されません。 このルールは、カスタム NSG ルールでオーバーライドできます。

{
    "name": "SFMC_AllowServiceFabricGatewayPorts",
    "type": "Microsoft.Network/networkSecurityGroups/securityRules",
    "properties": {
        "description": "Optional rule to open SF cluster gateway ports. To override add a custom NSG rule for gateway ports in priority range 1000-3000.",
        "protocol": "tcp",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "*",
        "destinationAddressPrefix": "VirtualNetwork",
        "access": "Allow",
        "priority": 3001,
        "direction": "Inbound",
        "sourcePortRanges": [],
        "destinationPortRanges": [
            "19000",
            "19080"
        ]
    }
}

インターネットから RDP ポートへのアクセスを有効にする

Service Fabric マネージド クラスターを使用して、インターネットから RDP ポートへの受信アクセスを既定で有効にすることはできません。 Service Fabric マネージド クラスター リソースで次のプロパティを設定することにより、インターネットから RDP ポートへの受信アクセスを開くことができます。

"allowRDPAccess": true

allowRDPAccess プロパティを true に設定すると、次の NSG 規則がクラスター デプロイに追加されます。

{
    "name": "SFMC_AllowRdpPort",
    "type": "Microsoft.Network/networkSecurityGroups/securityRules",
    "properties": {
        "description": "Optional rule to open RDP ports.",
        "protocol": "tcp",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "*",
        "destinationAddressPrefix": "VirtualNetwork",
        "access": "Allow",
        "priority": 3002,
        "direction": "Inbound",
        "sourcePortRanges": [],
        "destinationPortRange": "3389"
    }
}

Service Fabric マネージド クラスターにより、ノード タイプのインスタンスごとにインバウンド NAT 規則が自動的に作成されます。 特定のインスタンス (クラスター ノード) に到達するためのポート マッピングを見つけるには、次の手順のようにします。

Azure portal を使用して、リモート デスクトップ プロトコル (RDP) 用にマネージド クラスターで作成されたインバウンド NAT 規則を見つけます。

  1. サブスクリプション内にある、SFC_{cluster-id} という形式の名前が付けられたマネージド クラスター リソース グループに移動します

  2. そのクラスターに対する、LB-{cluster-name} という形式のロード バランサーを選択します

  3. ロード バランサーのページで、インバウンド NAT 規則を選択します。 インバウンド NAT 規則を調べて、ノードでのインバウンド フロントエンド ポートからターゲット ポートへのマッピングを確認します。

    次のスクリーンショットでは、3 つの異なるノード タイプに対するインバウンド NAT 規則が示されています。

    受信 NAT 規則

    既定では、Windows クラスターの場合、フロントエンド ポートは 50000 以上の範囲で、ターゲット ポートはポート 3389 であり、ターゲット ノードの RDP サービスにマップされます。

    Note

    BYOLB 機能を使用していて、RDP が必要な場合は、NAT プールをそのように個別に構成する必要があります。 これによって、これらのノード タイプに対して NAT 規則が自動的に作成されることはありません。

  4. 特定のノード (スケール セット インスタンス) にリモート接続します。 クラスターまたはその他の構成した資格情報を作成したときに設定したユーザー名とパスワードを使用することができます。

次のスクリーンショットでは、リモート デスクトップ接続を使用した、Windows クラスター内のアプリ (インスタンス 0) ノードへの接続が示されています。

リモート デスクトップ接続

既定のロード バランサー構成を変更する

ロード バランサーのポート

Service Fabric マネージド クラスターにより、ManagedCluster プロパティの loadBalancingRules セクションで構成されているすべてのロード バランサー (LB) ポートに対する NSG ルールが、既定の優先順位範囲に作成されます。 このルールにより、インターネットからの受信トラフィック用に LB ポートが開かれます。

Note

このルールは、オプションの優先順位範囲に追加され、カスタム NSG ルールを追加することによってオーバーライドできます。

{
    "name": "SFMC_AllowLoadBalancedPorts",
    "type": "Microsoft.Network/networkSecurityGroups/securityRules",
    "properties": {
        "description": "Optional rule to open LB ports",
        "protocol": "*",
        "sourcePortRange": "*",
        "sourceAddressPrefix": "*",
        "destinationAddressPrefix": "VirtualNetwork",
        "access": "Allow",
        "priority": 3003,
        "direction": "Inbound",
        "sourcePortRanges": [],
        "destinationPortRanges": [
        "80", "8080", "4343"
        ]
    }
}

ロード バランサーのプローブ

Service Fabric マネージド クラスターにより、ファブリック ゲートウェイのポート用、およびマネージド クラスターのプロパティの loadBalancingRules セクションで構成されているすべてのポート用のロード バランサー プローブが、自動的に作成されます。

{
  "value": [
    {
        "name": "FabricTcpGateway",
        "properties": {
            "provisioningState": "Succeeded",
            "protocol": "Tcp",
            "port": 19000,
            "intervalInSeconds": 5,
            "numberOfProbes": 2,
            "loadBalancingRules": [
                {
                    "id": "<>"
                }
            ]
        },
        "type": "Microsoft.Network/loadBalancers/probes"
    },
    {
        "name": "FabricHttpGateway",
        "properties": {
            "provisioningState": "Succeeded",
            "protocol": "Tcp",
            "port": 19080,
            "intervalInSeconds": 5,
            "numberOfProbes": 2,
            "loadBalancingRules": [
                {
                    "id": "<>"
                }
            ]
        },
        "type": "Microsoft.Network/loadBalancers/probes"
    },
    {
        "name": "probe1_tcp_8080",
        "properties": {
            "provisioningState": "Succeeded",
            "protocol": "Tcp",
            "port": 8080,
            "intervalInSeconds": 5,
            "numberOfProbes": 2,
            "loadBalancingRules": [
            {
                "id": "<>"
            }
        ]
      },
      "type": "Microsoft.Network/loadBalancers/probes"
    }
  ]
}

パブリック IP を有効にする

Note

現在、パブリック IPv4 のみがサポートされています。

Service Fabric マネージド クラスター ノードは、通信用に独自のパブリック IP アドレスを必要としません。 ただし、一部のシナリオでは、インターネットおよび公開 Azure サービスと通信するために、ノードに独自のパブリック IP アドレスが必要になる場合があります。 次に例を示します。

  • ゲームで、ゲームの物理処理を行っているクラウド仮想マシンにコンソールが直接接続する必要がある場合です。
  • 分散データベース内のリージョン間で相互に外部接続を行う必要がある仮想マシン。

Azure での送信接続の詳細については、送信用接続の詳細に関するページを参照してください。

プライマリ ノード タイプは Service Fabric システム サービス用に予約されているため、パブリック IP はセカンダリ ノード タイプでのみ有効にできます。 この記事の「独自のロード バランサーの導入」セクションの手順に従って、マネージド クラスターのセカンダリ ノード タイプを作成します。

Azure は、使用可能な IP アドレスを動的に割り当てます。

Note

パブリック IP の有効化は、ARM テンプレートを介してのみサポートされます。

次の手順では、ノードでパブリック IP を有効にする方法について説明します。

  1. ARM テンプレートをダウンロードします。

  2. テンプレート内のノード タイプごとに、ARM テンプレートに enableNodePublicIP を追加します。

    {
    "name": "<secondary_node_type_name>", 
    "apiVersion": "2023-02-01-preview", 
    "properties": { 
        "isPrimary" : false, 
        "vmImageResourceId": "/subscriptions/<your_subscription_id>/resourceGroups/<your_resource_group>/providers/Microsoft.Compute/images/<your_custom_image>", 
        "vmSize": "Standard_D2", 
        "vmInstanceCount": 5, 
        "dataDiskSizeGB": 100, 
        "enableNodePublicIP": true 
    }
}

  3. ARM テンプレートをデプロイします。

  4. 次の PowerShell コマンドを実行して、ノードにパブリック IP があることを確認します。

    az vmss list-instance-public-ips -g MC_MyResourceGroup2_MyManagedCluster_eastus -n YourVirtualMachineScaleSetName

    コマンドは JSON 形式で出力されます。

    [
  {
    "etag": "etag_0",
    "id": "<id_0/name>",
    "idleTimeoutInMinutes": 15,
    "ipAddress": "<ip_address_0>",
    "ipConfiguration": {
      "id": "<configuration_id_0>",
      "resourceGroup": "<your_resource_group>"
    },
    "ipTags": [],
    "name": "<name>",
    "provisioningState": "Succeeded",
    "publicIPAddressVersion": "IPv4",
    "publicIPAllocationMethod": "Static",
    "resourceGroup": "<your_resource_group>",
    "resourceGuid": "resource_guid_0",
    "sku": {
      "name": "Standard"
    }
  },
  {
    "etag": "etag_1",
    "id": "/<id_1/name>",
    "idleTimeoutInMinutes": 15,
    "ipAddress": "<ip_address_1>",
    "ipConfiguration": {
      "id": "<configuration_id_1>",
      "resourceGroup": "<your_resource_group>"
    },
    "ipTags": [],
    "name": "<name>",
    "provisioningState": "Succeeded",
    "publicIPAddressVersion": "IPv4",
    "publicIPAllocationMethod": "Static",
    "resourceGroup": "<your_resource_group>",
    "resourceGuid": "resource_guid_1",
    "sku": {
      "name": "Standard"
    }
  },
  {
    "etag": "etag_2",
    "id": "<id_2/name>",
    "idleTimeoutInMinutes": 15,
    "ipAddress": "<ip_address_2>",
    "ipConfiguration": {
      "id": "<configuration_id_2>",
      "resourceGroup": "<your_resource_group>"
    },
    "ipTags": [],
    "name": "<name>",
    "provisioningState": "Succeeded",
    "publicIPAddressVersion": "IPv4",
    "publicIPAllocationMethod": "Static",
    "resourceGroup": "<your_resource_group>",
    "resourceGuid": "resource_guid_2",
    "sku": {
      "name": "Standard"
    }
  }
]

IPv6 を有効にする

マネージド クラスターは、既定では IPv6 を有効にしません。 この機能により、ロード バランサー フロントエンドからバックエンド リソースへの完全なデュアル スタック IPv4/IPv6 機能が実現されます。 マネージド クラスターのロード バランサー構成または NSG 規則に加えた変更はすべて、IPv4 と IPv6 の両方のルーティングに影響します。

Note

この設定はポータルでは使用できず、クラスターの作成後に変更することはできません。

  • Service Fabric マネージド クラスター リソースの apiVersion は、2022-01-01 以降である必要があります。

  1. Service Fabric マネージド クラスター リソースで次のプロパティを設定します。

        "resources": [
         {
         "apiVersion": "[variables('sfApiVersion')]",
         "type": "Microsoft.ServiceFabric/managedclusters",
         ...
         "properties": {
             "enableIpv6": true
             },
         }
    ]

  2. IPv6 対応マネージド クラスターをデプロイします。 必要に応じてサンプル テンプレートをカスタマイズするか、独自のものを構築します。 次の例では、westus 内に MyResourceGroup という名前のリソース グループを作成し、この機能が有効なクラスターをデプロイします。

     New-AzResourceGroup -Name MyResourceGroup -Location westus
 New-AzResourceGroupDeployment -Name deployment -ResourceGroupName MyResourceGroup -TemplateFile AzureDeploy.json

    デプロイ後、クラスターの仮想ネットワークとリソースはデュアル スタックになります。 その結果、クラスターのフロントエンド ロード バランサーには、Azure Load Balancer のパブリック IPv6 アドレスと VM 上のプライベート IPv6 アドレスに関連付けられた、一意の DNS アドレス (たとえば mycluster-ipv6.southcentralus.cloudapp.azure.com) が作成されます。

Bring Your Own Virtual Network

この機能によって、利用者はマネージド クラスターがリソースをデプロイする先となる専用サブネットを指定することで、既存の仮想ネットワークを使用できます。 これは、使用したい関連セキュリティ ポリシーとトラフィック ルーティングが構成済みの仮想ネットワークとサブネットが既にある場合に便利です。 既存の仮想ネットワークへのデプロイ後、Azure ExpressRoute、Azure VPN Gateway、ネットワーク セキュリティ グループ、仮想ネットワーク ピアリングなどの他のネットワーク機能を簡単に使用したり組み込んだりできます。 また、必要に応じて Bring Your Own Azure Load Balancer も使用できます。

Note

BYOVNET を使用した場合、マネージド クラスター リソースは 1 つのサブネットにデプロイされます。

Note

クラスターが作成され、マネージド クラスターにより指定のサブネットに NSG が割り当てられた後では、この設定は変更できません。 NSG の割り当てをオーバーライドしないでください。そうしないとトラフィックが中断するおそれがあります。

Bring Your Own Virtual Network を使用するには:

  1. Service Fabric リソース プロバイダー アプリケーションのサブスクリプションからサービスの Id を取得します。

    Login-AzAccount
Select-AzSubscription -SubscriptionId <SubId>
Get-AzADServicePrincipal -DisplayName "Azure Service Fabric Resource Provider"

    Note

    正しいサブスクリプションを使用していることを確認します。サブスクリプションが別のテナントにある場合は、プリンシパル ID が変わります。

    ServicePrincipalNames : {74cb6831-0dbb-4be1-8206-fd4df301cdc2}
ApplicationId         : 74cb6831-0dbb-4be1-8206-fd4df301cdc2
ObjectType            : ServicePrincipal
DisplayName           : Azure Service Fabric Resource Provider
Id                    : 00000000-0000-0000-0000-000000000000

    後の手順で使用するため、上記の出力の Id を principalId としてメモしておきます

    ロール定義名 ロール定義 ID
    Network Contributor 4d97b98b-1d4f-4787-a291-c67834d212e7

    Role definition name と Role definition ID のプロパティ値は後の手順で使用するので、メモしておいてください

  2. Service Fabric リソース プロバイダー アプリケーションにロールの割り当てを追加します。 ロールの割り当ての追加は、1 回限りの操作です。 ロールを追加するには、次の PowerShell コマンドを実行するか、以下に示す Azure Resource Manager (ARM) テンプレートを構成します。

    以下の手順では、ExistingRG リソース グループにある ExistingRG-vnet という名前の既存の仮想ネットワークを使用します。 サブネットの名前は "default" です。

    既存の仮想ネットワークから必要情報を取得します。

    Login-AzAccount
Select-AzSubscription -SubscriptionId <SubId>
Get-AzVirtualNetwork -Name ExistingRG-vnet -ResourceGroupName ExistingRG

    後の手順で使用するため、応答の Subnets セクションから返される次のサブネット名と Id プロパティ値をメモしておきます。

    Subnets:[
{
...
"Id": "/subscriptions/<subscriptionId>/resourceGroups/Existing-RG/providers/Microsoft.Network/virtualNetworks/ExistingRG-vnet/subnets/default"
}]

    プリンシパル ID、手順 2 のロール定義名、および上記で取得した割り当てスコープ Id を使用して、次の PowerShell コマンドを実行します。

    New-AzRoleAssignment -PrincipalId 00000000-0000-0000-0000-000000000000 -RoleDefinitionName "Network Contributor" -Scope "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/virtualNetworks/<vnetName>/subnets/<subnetName>"

    または、principalId、roleDefinitionId、vnetName、および subnetName に適切な値が構成された Azure Resource Manager (ARM) テンプレートを使用して、ロールの割り当てを追加することもできます。

       "type": "Microsoft.Authorization/roleAssignments",
   "apiVersion": "2020-04-01-preview",
   "name": "[parameters('VNetRoleAssignmentID')]",
   "scope": "[concat('Microsoft.Network/virtualNetworks/', parameters('vnetName'), '/subnets/', parameters('subnetName'))]",
   "dependsOn": [
     "[concat('Microsoft.Network/virtualNetworks/', parameters('vnetName'))]"
   ],
   "properties": {
     "roleDefinitionId": "[concat('/subscriptions/', subscription().subscriptionId, '/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7')]",
     "principalId": "00000000-0000-0000-0000-000000000000"
   }

    Note

    VNetRoleAssignmentID は GUID である必要があります。 このロールの割り当てを含むテンプレートを再びデプロイする場合は、GUID が最初に使用したものと同じであることを確認します。 作成が必要なのは 1 回だけなので、これを分離して実行するか、デプロイ後にクラスター テンプレートからこのリソースを削除することをお勧めします。

    こちらのリンク先に、この手順に使用できる仮想ネットワーク サブネットを作成してロールの割り当てを行う Azure Resource Manager (ARM) テンプレートの完全なサンプルがあります。

  3. 次に示すように、ロールを設定した後で、クラスター デプロイの subnetId プロパティを構成します。

  1. 構成したマネージド クラスターの Azure Resource Manager (ARM) テンプレートをデプロイします。

    次の例では、westus に MyResourceGroup という名前のリソース グループを作成し、この機能を有効にしたクラスターをデプロイします。

     New-AzResourceGroup -Name MyResourceGroup -Location westus
 New-AzResourceGroupDeployment -Name deployment -ResourceGroupName MyResourceGroup -TemplateFile AzureDeploy.json

    独自の仮想ネットワーク サブネットを使用する場合でも、パブリック エンドポイントはリソース プロバイダーによって作成および管理されますが、構成されたサブネット内に配置されるようになります。 この機能を使用して Azure Load Balancer でパブリック IP を指定することや静的 IP を再利用することはできません。 Bring Your Own Azure Load Balancer は、この機能と組み合わせて使用するか、ネイティブでサポートされていないそれらまたは他のロード バランサー シナリオを必要とする場合は、単独で使用できます。

    クラスターが作成されると、既定のクラスター レベル サブネット用のマネージド リソース グループ内にネットワーク セキュリティ グループが作成されます。 あるノード タイプが作成されると、それはこのサブネット内に配置され、ノード タイプ レベル サブネットを使用しない限りは、ネットワーク セキュリティ グループの規則を自動的に継承します。

    独自の仮想ネットワークの使用では、ノード タイプ レベル サブネットもサポートされており、これにより、さまざまなノード タイプを別々のサブネットに配置できるため、さまざまなネットワーク構成とセットアップを柔軟に実現することができます。

    "resources": [
  {
    "apiVersion": "[variables('sfApiVersion')]",
    "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
    ...
    },
    "properties": {
      "subnetId": "subnetId",
      ...
    }
]

    ノード タイプ レベル サブネットを使用するには、マネージド クラスター定義で "useCustomVnet": true を指定します。 "useCustomVnet" が true に設定されている場合、既定のクラスター サブネットは作成されません。 ノード タイプ レベル サブネットを使用する場合、subnetId はノード タイプ定義内の必須プロパティになります。

    重要

    ノード タイプ レベル サブネットを使用する場合は、ノード タイプの作成前に、ネットワーク セキュリティ グループをノード タイプ サブネットに割り当てる必要があります。 そのネットワーク セキュリティ グループには、必須のインバウンド規則である SFMC_AllowServiceFabricGatewayToSFRP を含める必要があります。これを行わないと、ノード タイプの作成が失敗します。

Azure Load Balancer の持ち込み

マネージド クラスターで、プライマリとセカンダリの両方のノード タイプ用に、静的パブリック IP を使用して Azure のパブリック Standard Load Balancer と完全修飾のドメイン名が作成されます。 Bring Your Own Load Balancer を使用すると、受信トラフィックと送信トラフィックの両方向けに既存の Azure Load Balancer をセカンダリ ノード タイプに使用することができます。 Bring Your Own Azure Load Balancer を使用すると、次のことができます。

  • プライベートまたはパブリックのトラフィック用に事前構成済みの Load Balancer の静的 IP アドレスを使用する
  • ロード バランサーを特定のノード タイプにマップする
  • 各ノード タイプは独自のサブネットにデプロイされるので、ノード タイプごとにネットワーク セキュリティ グループの規則を構成します
  • 既存のポリシーとコントロール (適用されている場合) を維持する
  • 内部専用ロード バランサーを構成し、既定のロード バランサーは外部トラフィック用に使用します

Note

BYOVNET を使用すると、ロード バランサーを追加で構成した場合でも、マネージド クラスターリソースは 1 つの NSG を備えた 1 つのサブネットにデプロイされます。

Note

ノード タイプのデプロイ後に既定のロード バランサーからカスタムのそれに切り替えすることはできませんが、有効にした場合は、デプロイ後にカスタム ロード バランサーの構成を変更できます。

機能の要件

  • Standard SKU の Azure Load Balancer の種類がサポートされています
  • バックエンドおよび NAT プールが Azure Load Balancer に構成されている必要があります。
  • 用意されたパブリック ロード バランサーまたは既定のパブリック ロード バランサーを使用して、送信接続を有効にする必要があります

これを使用したお客様のシナリオの例を次に示します。

この例では、お客様は、既存の静的 IP アドレスが構成された既存の Azure ロード バランサーを介して、トラフィックを 2 つのノード タイプにルーティングしたいと考えています。

Bring Your Own Load Balancer の例 1

この例では、お客様は既存の Azure ロード バランサーを使用してトラフィックをルーティングし、個別のノード タイプで動作するアプリケーションへのトラフィック フローを個別に管理したいと考えています。 この例のように設定すると、各ノード タイプは、独自のマネージド NSG の背後に置かれます。

Bring Your Own Load Balancer の例 2

この例では、顧客は既存の内部 Azure Load Balancer を介してトラフィックをルーティングしたいと考えています。 これにより、個別のノード タイプで動作するアプリケーションへのトラフィック フローを個別に管理できます。 この例のように設定すると、各ノード タイプは独自のマネージド NSG の背後に配置され、外部トラフィックに既定のロード バランサーが使用されます。

Bring Your Own Load Balancer の例 3

独自のロード バランサーを使用して構成するには:

  1. Service Fabric リソース プロバイダー アプリケーションのサブスクリプションからサービス Id を取得します。

    Login-AzAccount
Select-AzSubscription -SubscriptionId <SubId>
Get-AzADServicePrincipal -DisplayName "Azure Service Fabric Resource Provider"

    Note

    正しいサブスクリプションを使用していることを確認します。サブスクリプションが別のテナントにある場合は、プリンシパル ID が変わります。

    ServicePrincipalNames : {74cb6831-0dbb-4be1-8206-fd4df301cdc2}
ApplicationId         : 74cb6831-0dbb-4be1-8206-fd4df301cdc2
ObjectType            : ServicePrincipal
DisplayName           : Azure Service Fabric Resource Provider
Id                    : 00000000-0000-0000-0000-000000000000

    後の手順で使用するため、上記の出力の Id を principalId としてメモしておきます

    ロール定義名 ロール定義 ID
    Network Contributor 4d97b98b-1d4f-4787-a291-c67834d212e7

    Role definition name と Role definition ID のプロパティ値は後の手順で使用するので、メモしておいてください

  2. Service Fabric リソース プロバイダー アプリケーションにロールの割り当てを追加します。 ロールの割り当ての追加は、1 回限りの操作です。 ロールを追加するには、次の PowerShell コマンドを実行するか、以下に示す Azure Resource Manager (ARM) テンプレートを構成します。

    以下の手順では、Existing-RG リソース グループにある Existing-LoadBalancer1 という名前の既存のロード バランサーを使用します。

    既存の Azure ロード バランサーから必須の Id プロパティの情報を取得します。

    Login-AzAccount
Select-AzSubscription -SubscriptionId <SubId>
Get-AzLoadBalancer -Name "Existing-LoadBalancer1" -ResourceGroupName "Existing-RG"

    次の手順で使用する、次の Id をメモします。

    {
...
"Id": "/subscriptions/<subscriptionId>/resourceGroups/Existing-RG/providers/Microsoft.Network/loadBalancers/Existing-LoadBalancer1"
}

    プリンシパル ID、手順 2 のロール定義名、および今取得した割り当てスコープ Id を使用して、次の PowerShell コマンドを実行します。

    New-AzRoleAssignment -PrincipalId 00000000-0000-0000-0000-000000000000 -RoleDefinitionName "Network Contributor" -Scope "/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/loadBalancers/<LoadBalancerName>"

    または、principalId、roleDefinitionIdに適切な値が構成された Azure Resource Manager (ARM) テンプレートを使用して、ロールの割り当てを追加することもできます。

       "type": "Microsoft.Authorization/roleAssignments",
   "apiVersion": "2020-04-01-preview",
   "name": "[parameters('loadBalancerRoleAssignmentID')]",
   "scope": "[concat('Microsoft.Network/loadBalancers/', variables('lbName'))]",
   "dependsOn": [
     "[concat('Microsoft.Network/loadBalancers/', variables('lbName'))]"
   ],
   "properties": {
     "roleDefinitionId": "[concat('/subscriptions/', subscription().subscriptionId, '/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7')]",
     "principalId": "00000000-0000-0000-0000-000000000000"
   }

    Note

    loadBalancerRoleAssignmentID は GUID である必要があります。 このロールの割り当てを含むテンプレートを再びデプロイする場合は、GUID が最初に使用したものと同じであることを確認します。 作成が必要なのは 1 回だけなので、これを分離して実行するか、デプロイ後にクラスター テンプレートからこのリソースを削除することをお勧めします。

    パブリック ロード バランサーを作成しロールを割り当てるテンプレートの例をご覧ください。

  3. ノード タイプに必要な送信接続を構成します。 送信接続を提供するか、既定のパブリック ロード バランサーを使用するには、パブリック ロード バランサーを構成する必要があります。

    outboundRules を構成して送信接続を提供するパブリック ロード バランサーを構成します。ロード バランサーを作成してロールを割り当てる Azure Resource Manager (ARM) テンプレートのサンプルをご覧ください。

    OR

    既定のロード バランサーを使用するノード タイプを構成するには、お使いのテンプレートで次を設定します。

    • Service Fabric マネージド クラスター リソースの apiVersion は、2022-01-01 以降である必要があります。
     "resources": [
   {
   "apiVersion": "[variables('sfApiVersion')]",
   "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
   "properties": {
       "isPrimary": false,
       "useDefaultPublicLoadBalancer": true
       }
   }
 ]

  4. 必要に応じて、既存の Azure ロード バランサーで受信アプリケーション ポートと関連プローブを構成します。 例については、Bring Your Own Load Balancer の Azure Resource Manager (ARM) テンプレートのサンプルをご覧ください。

  5. 必要に応じて、ノード タイプに適用されるマネージド クラスター NSG ルールを構成し、Azure ロード バランサーで構成した必要なトラフィックを許可します。そうしないと、トラフィックがブロックされます。 インバウンド NSG の構成の例については、Bring Your Own Load Balancer の Azure Resource Manager (ARM) テンプレートのサンプルを参照してください。 テンプレートで networkSecurityRules プロパティを検索します。

  6. 構成済みのマネージド クラスター ARM テンプレートをデプロイします。この手順では、Bring Your Own Load Balancer の Azure Resource Manager (ARM) テンプレートのサンプルを使用します。

    westus に MyResourceGroup というリソース グループを作成し、既存のロードバランサーを使用してクラスターをデプロイする方法を次に示します。

     New-AzResourceGroup -Name MyResourceGroup -Location westus
 New-AzResourceGroupDeployment -Name deployment -ResourceGroupName MyResourceGroup -TemplateFile AzureDeploy.json

    デプロイ後、受信と送信のトラフィック用に指定されたロード バランサーを使用するようにセカンダリ ノード タイプが構成されます。 Service Fabric のクライアント接続およびゲートウェイ エンドポイントは、マネージド クラスターのプライマリ ノード タイプの静的 IP アドレスのパブリック DNS を引き続き指します。

Accelerated Networking の有効化

高速ネットワークを使用すると、ノード タイプの基になるリソースである仮想マシン スケール セット VM に対して、単一ルート I/O 仮想化 (SR-IOV) が可能になります。 この高パフォーマンスのパスによってデータ パスからホストがバイパスされ、最も要求の厳しいネットワーク ワークロードで、待機時間、ジッター、CPU 使用率が低下します。 Service Fabric マネージド クラスター ノード タイプは、サポートされている VM SKU で、高速ネットワークを使用してプロビジョニングすることができます。 その他の考慮事項については、これらの「制限と制約」を参照してください。

  • 高速ネットワークは、2 つ以上の vCPU を持つ、コンピューティングに最適化された汎用のインスタンス サイズのほとんどでサポートされています。 ハイパースレッディングをサポートするインスタンスでは、4 以上の vCPU を持つ VM インスタンスで高速ネットワークがサポートされています。

次に示すように、Resource Manager テンプレートでenableAcceleratedNetworking プロパティを宣言して高速ネットワークを有効にします。

  • Service Fabric マネージド クラスター リソースの apiVersion は、2022-01-01 以降である必要があります。
   {
   "apiVersion": "[variables('sfApiVersion')]",
   "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
   ...
   "properties": {
       ...
       "enableAcceleratedNetworking": true,
       ...
   }

既存の Service Fabric クラスターで高速ネットワークを有効にするには、最初に新しいノード タイプを追加し、次を実行して Service Fabric クラスターをスケール アウトする必要があります。

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

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

補助サブネットを構成する

補助サブネットにより、Private Link や bastion ホストなどのシナリオをサポートするノード タイプなしで、追加のマネージド サブネットを作成することができます。

次に示すように、Resource Manager テンプレートで auxiliarySubnets プロパティと必要なパラメーターを宣言して補助サブネットを構成します。

  • Service Fabric マネージド クラスター リソースの apiVersion は、2022-01-01 以降である必要があります。
    "resources": [
        {
            "apiVersion": "[variables('sfApiVersion')]",
            "type": "Microsoft.ServiceFabric/managedclusters",
              "properties": {
                "auxiliarySubnets": [
                  {
                  "name" : "mysubnet",
                  "enableIpv6" : "true"
                  }
                ]
              }
        }
    ]

使用可能なパラメーターの完全なリストを参照してください。

次のステップ

Service Fabric マネージド クラスターの構成オプションService Fabric マネージド クラスターの概要