Configurer les paramètres réseau pour les clusters Service Fabric managés

Les clusters Service Fabric managés sont créés avec une configuration réseau par défaut. Cette configuration se compose d'un Azure Load Balancer avec une adresse IP publique, d'un réseau virtuel avec un sous-réseau alloué et d'un NSG configuré pour les fonctionnalités de cluster essentielles. Il existe également des règles de groupe de sécurité réseau facultatives, telles que l’autorisation de tout le trafic sortant par défaut, destinées à faciliter la configuration du client. Ce document explique comment modifier les options de configuration réseau suivantes, et bien plus encore :

• Gérer les règles de groupe de sécurité réseau
• Gérer l’accès RDP
• Gérer la configuration de l’équilibreur de charge
• Activer l'IP publique
• Activer IPv6
• Apporter votre propre réseau virtuel
• Apporter votre propre équilibreur de charge
• Activer la mise en réseau accélérée
• Configurer des sous-réseaux auxiliaires

Gérer les règles de groupe de sécurité réseau

Instructions relatives aux règles de groupe de sécurité réseau

Tenez compte de ces considérations lors de la création de règles de groupe de sécurité réseau (NSG, Network Security Group) pour votre cluster géré.

• Les clusters Service Fabric gérés réservent la plage de priorités de 0 à 999 aux fonctionnalités essentielles des règles NSG. Vous ne pouvez pas créer de règles NSG personnalisées avec une valeur de priorité inférieure à 1 000.
• Les clusters Service Fabric gérés réservent la plage de priorités de 3 001 à 4 000 à la création de règles NSG facultatives. Ces règles sont ajoutées automatiquement pour faciliter et accélérer la configuration. Vous pouvez les remplacer en ajoutant des règles NSG personnalisées dans la plage de priorités comprise entre 1 000 et 3 000.
• Les règles NSG personnalisées doivent avoir une priorité comprise entre 1 000 et 3 000.

Application de règles NSG

Les clusters Service Fabric gérés vous permettent d’affecter des règles NSG directement dans la ressource de cluster de votre modèle de déploiement.

Utilisez la propriété networkSecurityRules de votre ressource Microsoft.ServiceFabric/managedclusters (version 2021-05-01 ou ultérieure) pour affecter des règles NSG. Par exemple :

{
  "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 et HttpGatewayConnection par défaut, et règles facultatives

Règle NSG : SFMC_AllowServiceFabricGatewayToSFRP

Une règle NSG par défaut est ajoutée pour permettre au fournisseur de ressources Service Fabric d’accéder aux ports clientConnectionPort et httpGatewayConnectionPort du cluster. Elle autorise l’accès aux ports par l’intermédiaire de l’étiquette de service « ServiceFabric ».

Notes

Cette règle est toujours ajoutée et ne peut pas être remplacée.

{
    "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"
        ]
    }
}

Règle NSG : SFMC_AllowServiceFabricGatewayPorts

Cette règle facultative permet aux clients d’accéder à SFX, de se connecter au cluster à l’aide de PowerShell et d’utiliser les points de terminaison de l’API du cluster Service Fabric à partir d’Internet en ouvrant les ports d’équilibrage de charge pour clientConnectionPort et httpGatewayPort.

Notes

Cette règle ne sera pas ajoutée s'il existe une règle personnalisée avec les mêmes valeurs d'accès, de direction et de protocole pour le même port. Vous pouvez remplacer cette règle par des règles NSG personnalisées.

{
    "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"
        ]
    }
}

Activer l’accès aux ports RDP à partir d’Internet

Les clusters gérés Service Fabric n'activent pas l'accès entrant aux ports RDP à partir d'Internet par défaut. Vous pouvez ouvrir l’accès entrant aux ports RDP à partir d’Internet en définissant la propriété suivante sur une ressource de cluster géré par Service Fabric.

"allowRDPAccess": true

Lorsque la propriété allowRDPAccess est définie sur true, la règle NSG suivante est ajoutée au déploiement de cluster.

{
    "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"
    }
}

Les clusters Service Fabric gérés créent automatiquement des règles NAT de trafic entrant pour chaque instance dans un type de nœud. Pour rechercher les mappages de port permettant d’atteindre des instances spécifiques (nœuds de cluster), procédez comme suit :

À l’aide du portail Azure, recherchez les règles NAT de trafic entrant créées par le cluster géré pour le protocole RDP (Remote Desktop Protocol).

1. Accédez au groupe de ressources du cluster géré dans votre abonnement, nommé au format suivant : SFC_{cluster-id}.

2. Sélectionnez l’équilibreur de charge pour le cluster avec le format suivant : LB-{cluster-name}.

3. Sur la page de votre équilibreur de charge, sélectionnez Règles NAT de trafic entrant. Examinez les règles NAT de trafic entrant pour confirmer le mappage du port frontend du trafic entrant au port cible pour un nœud.

   La capture d’écran suivante montre les règles NAT de trafic entrant pour trois différents types de nœuds :

   

   Par défaut, pour les clusters Windows, le port frontend se trouve dans la plage 50000 et plus et le port cible est le port 3389, qui correspond au service RDP sur le nœud cible.

   Notes

   Si vous utilisez la fonctionnalité BYOLB et que vous souhaitez utiliser le protocole RDP, vous devez configurer un pool NAT séparément. Cela ne crée pas automatiquement de règles NAT pour ces types de nœuds.

4. Connectez-vous à distance au nœud (instance de groupe identique) spécifique. Vous pouvez utiliser le nom d’utilisateur et le mot de passe que vous avez définis lors de la création du cluster ou de toutes autres informations d’identification que vous avez configurées.

La capture d’écran suivante illustre l’utilisation de Remote Desktop Connection pour se connecter au nœud d’applications (Instance 0) dans un cluster Windows :

Modifier la configuration par défaut de l’équilibreur de charge

Ports d’équilibreur de charge

Les clusters Service Fabric gérés créent une règle NSG dans la plage de priorités par défaut pour tous les ports d’équilibrage de charge configurés dans la section « loadBalancingRules » sous les propriétés ManagedCluster. Cette règle ouvre les ports d’équilibrage de charge pour le trafic entrant à partir d’Internet.

Notes

Cette règle est ajoutée dans la plage de priorités facultative et peut être remplacée en ajoutant des règles NSG personnalisées.

{
    "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"
        ]
    }
}

Sondes d’équilibreur de charge

Les clusters gérés par Service Fabric créent automatiquement des sondes d’équilibreur de charge pour les ports de passerelle de la structure, ainsi que tous les ports configurés dans la section loadBalancingRules des propriétés du cluster géré.

{
  "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"
    }
  ]
}

Activer l'IP publique

Notes

Actuellement, seul l'IPv4 public est pris en charge.

Les nœuds de cluster gérés Service Fabric n'ont pas besoin de leurs propres adresses IP publiques pour la communication. Cependant, certains scénarios peuvent nécessiter qu'un nœud ait sa propre adresse IP publique pour communiquer avec Internet et les services Azure publics. Par exemple :

• Jeux, où une console doit établir une connexion directe à une machine virtuelle cloud qui effectue le traitement physique du jeu.
• Machines virtuelles qui doivent établir des connexions externes les unes avec les autres à travers les régions d'une base de données distribuée.

Pour plus d’informations sur les connexions sortantes dans Azure, consultez Comprendre les connexions sortantes dans Azure.

L'adresse IP publique ne peut être activée que sur les types de nœuds secondaires, car les types de nœuds principaux sont réservés aux services système Service Fabric. Suivez les étapes de la section Apportez votre propre équilibreur de charge de cet article pour créer un type de nœud secondaire pour votre cluster géré.

Azure attribue dynamiquement les adresses IP disponibles.

Notes

L'activation de l'adresse IP publique n'est prise en charge que via le modèle ARM.

Les étapes suivantes décrivent l'activation de l'adresse IP publique sur votre nœud.

1. Téléchargez votre modèle ARM.

2. Pour chaque type de nœud dans le modèle, ajoutez enableNodePublicIP au modèle ARM :

   {
       "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. Déployez votre modèle ARM.

4. Vérifiez que vous disposez d'une adresse IP publique sur vos nœuds en exécutant la commande PowerShell suivante :

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

   La commande sort au format 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"
       }
     }
   ]
   

Activer IPv6

Les clusters gérés n'activent pas IPv6 par défaut. Cette fonctionnalité active la capacité IPv4/IPv6 double pile complète de routage du serveur frontal de l’équilibreur de charge aux ressources principales. Toutes les modifications que vous apportez à la configuration de l’équilibreur de charge du cluster géré ou aux règles de groupe de sécurité réseau affectent le routage IPv4 et IPv6.

Notes

Ce paramètre n'est pas disponible dans le portail et ne peut pas être modifié une fois le cluster créé.

• L’apiVersion de la ressource de cluster managé Service Fabric doit être 2022-01-01 ou ultérieure.

1. Définissez la propriété suivante sur une ressource de cluster géré par Service Fabric.

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

2. Déployez votre cluster géré avec IPv6. Personnalisez l’exemple de modèle en fonction des besoins ou créez votre propre modèle. Dans l’exemple suivant, nous allons créer un groupe de ressources nommé MyResourceGroup dans westus, et déployer un cluster avec cette fonctionnalité activée.

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

   Après déploiement, le réseau virtuel et les ressources de votre cluster sont à double pile. Par conséquent, l’équilibreur de charge frontal du cluster a une adresse DNS unique créée, par exemple mycluster-ipv6.southcentralus.cloudapp.azure.com, qui est associée à une adresse IPv6 publique sur Azure Load Balancer, et à des adresses IPv6 privées sur les machines virtuelles.

Apporter votre propre réseau virtuel

Cette fonctionnalité permet aux clients d’utiliser un réseau virtuel existant en spécifiant un sous-réseau dédié dans lequel le cluster géré déploiera ses ressources. Cela peut être utile si vous disposez déjà d’un réseau virtuel et d’un sous-réseau configurés avec des stratégies de sécurité et un routage du trafic associés que vous souhaitez utiliser. Après avoir opéré le déploiement sur un réseau virtuel existant, il est facile d’utiliser ou d’intégrer d’autres fonctionnalités de mise en réseau telles qu’Azure ExpressRoute, une passerelle VPN Azure, un groupe de sécurité réseau et un appairage de réseaux virtuels. En outre, vous pouvez apporter votre propre Azure Load Balancer, si nécessaire.

Notes

Lorsque vous utilisez BYOVNET, les ressources de cluster gérées sont déployées dans un sous-réseau.

Notes

Ce paramètre ne peut pas être modifié une fois le cluster créé et le cluster géré attribuera un NSG au sous-réseau fourni. Ne remplacez pas l'affectation NSG, sinon le trafic risque d'être interrompu.

Pour apporter votre propre réseau virtuel :

1. Obtenez l’Id de service de votre abonnement pour votre application fournisseur de ressources Service Fabric.

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

   Notes

   Vérifiez que vous êtes bien dans le bon abonnement. L’ID du principal ne sera pas le même si l’abonnement se trouve dans un autre locataire.

   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
   

   Notez l’ID de la sortie précédente comme principalId. Vous allez l’utiliser dans une étape ultérieure.

   Nom de la définition de rôle	ID de définition de rôle
   Contributeur de réseau	4d97b98b-1d4f-4787-a291-c67834d212e7

   Notez les valeurs de propriété Role definition name et Role definition ID. Vous allez les utiliser dans une étape ultérieure.

2. Ajoutez une attribution de rôle à l’application fournisseur de ressources Service Fabric. L’ajout d’une attribution de rôle est une action ponctuelle. Pour ajouter le rôle, exécutez les commandes PowerShell suivantes ou configurez un modèle Azure Resource Manager (ARM) comme indiqué ci-dessous.

   Dans les étapes suivantes, nous commençons avec un réseau virtuel existant nommé ExistingRG-vnet dans le groupe de ressources ExistingRG. Le sous-réseau est nommé default.

   Obtenez les informations requises du réseau virtuel existant.

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

   Notez le nom de sous-réseau suivant et la valeur de propriété Id retournée dans la section Subnets de la réponse. Vous allez les utiliser dans une étape ultérieure.

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

   Exécutez la commande PowerShell suivante en utilisant l’ID de principal, le nom de définition de rôle de l’étape 2 et l’étendue d’affectation Id obtenue ci-dessus :

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

   Vous pouvez également ajouter l’attribution de rôle à l’aide d’un modèle Azure Resource Manager (ARM) configuré avec les valeurs appropriées pour principalId, roleDefinitionId, vnetName et subnetName :

      "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"
      }
   

   Notes

   VNetRoleAssignmentID doit être un GUID. Si vous redéployez un modèle incluant cette attribution de rôle, vérifiez que le GUID est celui utilisé à l’origine. Nous vous suggérons d’exécuter ceci de façon isolée ou de supprimer cette ressource du modèle de cluster après le déploiement, car elle ne doit être créée qu’une seule fois.

   Voici un exemple complet de modèle Azure Resource Manager (ARM) qui crée un sous-réseau virtuel et effectue une attribution de rôle que vous pouvez utiliser pour cette étape.

3. Configurez la propriété subnetId pour le déploiement de cluster une fois le rôle configuré comme ci-dessous :

• L’apiVersion de la ressource de cluster managé Service Fabric doit être 2022-01-01 ou ultérieure.

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

  Consultez l’exemple de modèle Apporter votre propre cluster de réseau virtuel ou personnalisez votre propre cluster.

4. Déployez le modèle Azure Resource Manager (ARM) de cluster géré configuré.

   Dans l’exemple suivant, nous allons créer un groupe de ressources nommé MyResourceGroup dans westus, et déployer un cluster avec cette fonctionnalité activée.

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

   Lorsque vous apportez votre propre sous-réseau de réseau virtuel, le point de terminaison public est toujours créé et géré par le fournisseur de ressources, mais dans le sous-réseau configuré. La fonctionnalité ne vous permet pas de spécifier l'adresse IP publique/réutiliser l'adresse IP statique sur Azure Load Balancer. Vous pouvez apporter votre propre Azure Load Balancer de concert avec cette fonctionnalité ou seul si vous avez besoin de ces scénarios ou d’autres scénarios d’équilibreur de charge qui ne sont pas pris en charge en mode natif.

Apporter votre propre Azure Load Balancer

Les clusters gérés créent un Azure Load Balancer public Standard Load Balancer et un nom de domaine complet avec une adresse IP publique statique pour les types de nœuds principal et secondaires. Le fait d’apporter votre propre équilibreur de charge vous permet d’utiliser un Azure Load Balancer existant pour les types de nœuds secondaires pour le trafic entrant et sortant. Lorsque vous apportez votre propre Azure Load Balancer, vous pouvez :

• Utiliser une adresse IP statique Load Balancer préconfigurée pour le trafic privé ou public
• Mapper un équilibreur de charge à un type de nœud spécifique
• Configurer des règles de groupe de sécurité réseau par type de nœud, car chaque type de nœud est déployé dans son propre sous-réseau
• Maintenir les stratégies et contrôles existants que vous avez peut-être mis en place
• Configurer un équilibreur de charge interne uniquement et utiliser l’équilibreur de charge par défaut pour le trafic externe

Notes

Lorsque vous utilisez BYOVNET, les ressources de cluster gérées sont déployées dans un sous-réseau avec un NSG, indépendamment des équilibreurs de charge configurés supplémentaires.

Notes

Vous ne pouvez pas passer de l’équilibreur de charge par défaut à un autre après le déploiement d’un type de nœud, mais vous pouvez modifier la configuration d’équilibrage de charge personnalisée après le déploiement si elle est activée.

Exigences concernant les fonctionnalités

• Les types d’Azure Load Balancer de référence (SKU) De base et Standard sont pris en charge
• Des pools principal et NAT doivent être configurés sur l’Azure Load Balancer.
• Vous devez activer la connectivité sortante à l’aide d’un équilibreur de charge public fourni ou de l’équilibreur de charge public par défaut.

Voici quelques exemples de scénarios pour lesquels les clients peuvent utiliser ceci :

Dans cet exemple, un client souhaite router le trafic via un Azure Load Balancer existant configuré avec une adresse IP statique existante vers deux types de nœuds.

Dans cet exemple, un client souhaite acheminer le trafic via des équilibreurs de charge Azure existants afin de faciliter la gestion du flux de trafic de manière indépendante vers ses applications résidant sur des types de nœuds distincts. En cas de configuration comme dans cet exemple, chaque type de nœud se trouve derrière son propre groupe de sécurité réseau.

Dans cet exemple, un client souhaite router le trafic via des équilibreurs de charge Azure internes existants. Cela lui permet de gérer le flux de trafic vers ses applications indépendamment qui résident sur des types de nœuds distincts. En cas de configuration comme dans cet exemple, chaque type de nœud se trouve derrière son propre groupe de sécurité réseau géré et utilise l’équilibreur de charge par défaut pour le trafic externe.

Pour une configuration avec votre propre équilibreur de charge :

1. Obtenez le service Id de votre abonnement pour l’application fournisseur de ressources Service Fabric :

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

   Notes

   Vérifiez que vous êtes bien dans le bon abonnement. L’ID du principal ne sera pas le même si l’abonnement se trouve dans un autre locataire.

   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
   

   Notez l’ID de la sortie précédente comme principalId. Vous allez l’utiliser dans une étape ultérieure.

   Nom de la définition de rôle	ID de définition de rôle
   Contributeur de réseau	4d97b98b-1d4f-4787-a291-c67834d212e7

   Notez les valeurs de propriété Role definition name et Role definition ID. Vous allez les utiliser dans une étape ultérieure.

2. Ajoutez une attribution de rôle à l’application fournisseur de ressources Service Fabric. L’ajout d’une attribution de rôle est une action ponctuelle. Pour ajouter le rôle, exécutez les commandes PowerShell suivantes ou configurez un modèle Azure Resource Manager (ARM) comme indiqué ci-dessous.

   Dans les étapes suivantes, nous allons commencer avec un équilibreur de charge existant nommé Existing-LoadBalancer1, dans le groupe de ressources Existing-RG.

   Obtenez les informations de propriété Id requises à partir de l’Azure Load Balancer existant.

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

   Notez l’Id suivant que vous allez utiliser à l’étape suivante :

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

   Exécutez la commande PowerShell suivante en utilisant l’ID de principal, le nom de définition de rôle de l’étape 2 et l’étendue d’affectation Id que vous venez d’obtenir :

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

   Vous pouvez également ajouter l’attribution de rôle à l’aide d’un modèle Azure Resource Manager (ARM) configuré avec les valeurs appropriées pour principalId, roleDefinitionId :

      "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"
      }
   

   Notes

   loadBalancerRoleAssignmentID doit être un GUID. Si vous redéployez un modèle incluant cette attribution de rôle, vérifiez que le GUID est celui utilisé à l’origine. Nous vous suggérons d’exécuter ceci de façon isolée ou de supprimer cette ressource du modèle de cluster après le déploiement, car elle ne doit être créée qu’une seule fois.

   Consultez cet exemple de modèle pour créer un équilibreur de charge public et attribuer un rôle.

3. Configurez la connectivité sortante requise pour le type de nœud. Vous devez configurer un équilibreur de charge public pour fournir une connectivité sortante ou utiliser l’équilibreur de charge public par défaut.

   Configurez outboundRules pour configurer un équilibreur de charge public pour fournir une connectivité sortante. Consultez le modèle de création d’équilibrage de charge et d’attribution de rôle Azure Resource Manager (ARM)

   OR

   Pour configurer le type de nœud afin d’utiliser l’équilibreur de charge par défaut, définissez ce qui suit dans votre modèle :

   • L’apiVersion de la ressource de cluster managé Service Fabric doit être 2022-01-01 ou ultérieure.

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

4. Configurez éventuellement un port d’application entrant et une sonde associée sur votre Azure Load Balancer existant. Pour un exemple, consultez le modèle Azure Resource Manager (ARM) Apporter votre propre équilibreur de charge.

5. Configurez éventuellement les règles de groupe de sécurité réseau de cluster géré appliquées au type de nœud pour autoriser tout trafic requis que vous avez configuré sur l’Azure Load Balancer. Autrement, le trafic sera bloqué. Pour un exemple de configuration de règle de groupe de sécurité réseau entrant, consultez le modèle Azure Resource Manager (ARM) Apporter votre propre équilibreur de charge. Dans le modèle, recherchez la propriété networkSecurityRules.

6. Déployer le modèle ARM de cluster géré configuré Pour cette étape, nous allons utiliser l’exemple de modèle Azure Resource Manager (ARM) Apporter votre propre équilibrage de charge

   La commande suivante permet de créer un groupe de ressources appelé MyResourceGroup dans westus et de déployer un cluster à l’aide d’un équilibreur de charge existant.

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

   Après le déploiement, le type de nœud secondaire est configuré pour utiliser l’équilibreur de charge spécifié pour le trafic entrant et sortant. La connexion client Service Fabric et les points de terminaison de passerelle pointent toujours vers le DNS public de l’adresse IP statique du type de nœud principal de cluster géré.

Activer la mise en réseau accélérée

Les performances réseau accélérées permettent la virtualisation d’entrée/sortie à racine unique (SR-IOV) sur une machine virtuelle de groupe de machines virtuelles identiques qui est la ressource sous-jacente pour les types de nœuds. Cette voie hautement performante court-circuite l’hôte à partir du chemin d’accès aux données, ce qui réduit la latence, l’instabilité et l’utilisation du processeur pour les charges de travail réseau les plus exigeantes. Les types de nœuds de clusters gérés Service Fabric peuvent être provisionnés avec des performances réseau accélérées sur les références SKU de machine virtuelle prises en charge. Reportez-vous à ces limitations et contraintes pour des considérations supplémentaires.

• Notez que les performances réseau accélérées sont prises en charge dans la plupart des instances d’usage général et optimisées pour le calcul (2 processeurs virtuels ou plus). Dans des instances qui acceptent l’hyperthreading, la mise en réseau accélérée est prise en charge dans des instances de machine virtuelle comptant au minimum 4 processeurs virtuels.

Activez les performances réseau accélérées en déclarant la propriété enableAcceleratedNetworking dans votre modèle Resource Manager comme suit :

• L’apiVersion de la ressource de cluster managé Service Fabric doit être 2022-01-01 ou ultérieure.

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

Pour activer les performances réseau accélérées sur un cluster Service Fabric existant, vous devez d’abord mettre à l’échelle ce cluster en ajoutant un type de nœud et effectuer ce qui suit :

1. Provisionner un type de nœud avec activation des performances réseau accélérées
2. Migrer vos services et leur état vers le type de nœud provisionné avec performances réseau accélérées activées

La mise à l’échelle de l’infrastructure est requise pour activer la mise en réseau accélérée sur un cluster existant. En effet, l'activation de la mise en réseau accélérée peut entraîner un temps d’arrêt, car elle implique que toutes les machines virtuelles d'un groupe à haute disponibilité soient arrêtées et libérées avant d'activer la mise en réseau accélérée sur une carte réseau existante.

Configurer des sous-réseaux auxiliaires

Les sous-réseaux auxiliaires permettent de créer des sous-réseaux gérés supplémentaires sans type de nœud pour prendre en charge des scénarios tels que le service Private Link et les hôtes bastion.

Configurez des sous-réseaux auxiliaires en déclarant la propriété auxiliarySubnets et les paramètres requis dans votre modèle Resource Manager comme suit :

• L’apiVersion de la ressource de cluster managé Service Fabric doit être 2022-01-01 ou ultérieure.

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

Voir la liste complète des paramètres disponibles

Étapes suivantes

Options de configuration de cluster géré Service FabricVue d’ensemble des clusters gérés Service Fabric