Configurare le impostazioni di rete per i cluster gestiti di Service Fabric

I cluster gestiti di Service Fabric vengono creati con una configurazione di rete predefinita. Questa configurazione è costituita da un Azure Load Balancer con un ip pubblico, una rete virtuale con una subnet allocata e un gruppo di sicurezza di rete configurato per la funzionalità del cluster essenziale. Esistono anche regole del gruppo di sicurezza di rete facoltative applicate, ad esempio consentendo tutto il traffico in uscita per impostazione predefinita, che è destinato a semplificare la configurazione del cliente. Questo documento illustra come modificare le opzioni di configurazione di rete seguenti e altro ancora:

• Gestire le regole del gruppo di sicurezza di rete
• Gestire l'accesso RDP
• Gestire Load Balancer configurazione
• Abilitare l'INDIRIZZO IP pubblico
• Abilitare IPv6
• Portare la propria rete virtuale
• Portare il servizio di bilanciamento del carico personalizzato
• Abilitare la rete accelerata
• Configurare subnet ausiliarie

Gestire le regole del gruppo di sicurezza di rete

Linee guida sulle regole del gruppo di sicurezza di rete

Tenere presente queste considerazioni quando si creano nuove regole del gruppo di sicurezza di rete per il cluster gestito.

• I cluster gestiti di Service Fabric riservano l'intervallo di priorità della regola NSG da 0 a 999 per funzionalità essenziali. Non è possibile creare regole del gruppo di sicurezza di rete personalizzate con un valore di priorità inferiore a 1000.
• I cluster gestiti di Service Fabric riservano l'intervallo di priorità 3001 a 4000 per la creazione di regole di sicurezza di rete facoltative. Queste regole vengono aggiunte automaticamente per semplificare e velocizzare le configurazioni. È possibile eseguire l'override di queste regole aggiungendo regole del gruppo di sicurezza di rete personalizzate nell'intervallo di priorità 1000 a 3000.
• Le regole del gruppo di sicurezza di rete personalizzate devono avere una priorità all'interno dell'intervallo da 1000 a 3000.

Applicare le regole del gruppo di sicurezza di rete

I cluster gestiti di Service Fabric consentono di assegnare regole del gruppo di sicurezza di rete direttamente all'interno della risorsa cluster del modello di distribuzione.

Usare la proprietà networkSecurityRules della risorsa Microsoft.ServiceFabric/managedclusters (versione 2021-05-01 o successiva) per assegnare regole del gruppo di sicurezza di rete. Ad esempio:

{
  "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 e HttpGatewayConnection predefinite e regole facoltative

Regola NSG: SFMC_AllowServiceFabricGatewayToSFRP

Viene aggiunta una regola NSG predefinita per consentire al provider di risorse di Service Fabric di accedere al clientConnectionPort del cluster e httpGatewayConnectionPort. Questa regola consente l'accesso alle porte tramite il tag di servizio 'ServiceFabric'.

Nota

Questa regola viene sempre aggiunta e non può essere sottoposto a override.

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

Regola NSG: SFMC_AllowServiceFabricGatewayPorts

Questa regola facoltativa consente ai clienti di accedere a SFX, connettersi al cluster usando PowerShell e usare endpoint API cluster di Service Fabric da Internet aprendo porte LB per clientConnectionPort e httpGatewayPort.

Nota

Questa regola non verrà aggiunta se è presente una regola personalizzata con gli stessi valori di accesso, direzione e protocollo per la stessa porta. È possibile eseguire l'override di questa regola con regole del gruppo di sicurezza di rete personalizzate.

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

Abilitare l'accesso alle porte RDP da Internet

I cluster gestiti di Service Fabric non consentono l'accesso in ingresso alle porte RDP da Internet per impostazione predefinita. È possibile aprire l'accesso in ingresso alle porte RDP da Internet impostando la proprietà seguente in una risorsa cluster gestita di Service Fabric.

"allowRDPAccess": true

Quando la proprietà allowRDPAccess è impostata su true, la regola NSG seguente verrà aggiunta alla distribuzione del 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"
    }
}

I cluster gestiti di Service Fabric creano automaticamente regole NAT in ingresso per ogni istanza in un tipo di nodo. Per trovare i mapping delle porte per raggiungere istanze specifiche (nodi del cluster) seguire questa procedura:

Usando portale di Azure, individuare il cluster gestito creato regole NAT in ingresso per Remote Desktop Protocol (RDP).

1. Passare al gruppo di risorse del cluster gestito all'interno della sottoscrizione denominata con il formato seguente: SFC_{cluster-id}

2. Selezionare il servizio di bilanciamento del carico per il cluster con il formato seguente: LB-{cluster-name}

3. Nella pagina del servizio di bilanciamento del carico selezionare Regole NAT in ingresso. Esaminare le regole NAT in ingresso per confermare la porta front-end in ingresso per il mapping delle porte di destinazione per un nodo.

   Lo screenshot seguente mostra le regole NAT in ingresso per tre tipi di nodo diversi:

   

   Per impostazione predefinita, per i cluster Windows, la porta front-end si trova nell'intervallo 50000 e superiore e la porta di destinazione è la porta 3389, che esegue il mapping al servizio RDP nel nodo di destinazione.

   Nota

   Se si usa la funzionalità BYOLB e si vuole RDP, è necessario configurare un pool NAT separatamente a tale scopo. In questo modo non verranno create automaticamente regole NAT per tali tipi di nodo.

4. Connettersi in remoto allo specifico nodo (istanza del set di scalabilità). È possibile usare il nome utente e la password impostati durante la creazione del cluster o eventuali altre credenziali configurate.

La schermata seguente mostra l'uso della connessione Desktop remoto per connettersi al nodo app (Istanza 0) in un cluster Windows:

Modificare la configurazione predefinita del servizio di bilanciamento del carico

Porte del servizio di bilanciamento del carico

I cluster gestiti di Service Fabric creano una regola NSG nell'intervallo di priorità predefinito per tutte le porte di bilanciamento del carico configurate nella sezione "loadBalancingRules" in Proprietà ManagedCluster . Questa regola apre le porte LB per il traffico in ingresso da Internet.

Nota

Questa regola viene aggiunta nell'intervallo di priorità facoltativa e può essere sostituita aggiungendo regole di sicurezza di rete personalizzate.

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

Probe del servizio di bilanciamento del carico

I cluster gestiti di Service Fabric creano automaticamente probe di bilanciamento del carico per le porte del gateway di infrastruttura e tutte le porte configurate nella loadBalancingRules sezione delle proprietà del cluster gestito.

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

Abilitare l'INDIRIZZO IP pubblico

Nota

Attualmente è supportato solo IPv4 pubblico.

I nodi del cluster gestito di Service Fabric non richiedono indirizzi IP pubblici per la comunicazione. Tuttavia, alcuni scenari possono richiedere a un nodo di avere il proprio indirizzo IP pubblico per comunicare con Internet e servizi di Azure con connessione pubblica. Ad esempio:

• Gioco, dove una console deve creare una connessione diretta a una macchina virtuale cloud che esegue l'elaborazione fisica del gioco.
• Macchine virtuali che devono effettuare connessioni esterne tra loro tra aree in un database distribuito.

Per altre informazioni sulle connessioni in uscita, vedere Informazioni sulle connessioni in uscita in Azure.

L'INDIRIZZO IP pubblico può essere abilitato solo nei tipi di nodi secondari, perché i tipi di nodo primario sono riservati ai servizi di sistema di Service Fabric. Seguire la procedura descritta nella sezione Bring your own load balancer di questo articolo per creare un tipo di nodo secondario per il cluster gestito.

Azure assegna in modo dinamico gli indirizzi IP disponibili.

Nota

L'abilitazione dell'IP pubblico è supportata solo tramite il modello di Resource Manager.

I passaggi seguenti descrivono l'abilitazione dell'INDIRIZZO IP pubblico nel nodo.

1. Scaricare il modello di Resource Manager.

2. Per ogni tipo di nodo nel modello, aggiungere enableNodePublicIP al modello di Resource Manager:

   {
       "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. Deloy il modello di Resource Manager.

4. Verificare di avere un indirizzo IP pubblico nei nodi eseguendo il comando di PowerShell seguente:

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

   I comandi vengono restituiti in formato 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"
       }
     }
   ]
   

Abilitare IPv6

Per impostazione predefinita, i cluster gestiti non abilitano IPv6. Questa funzionalità abiliterà la funzionalità IPv4/IPv6 full stack dalla Load Balancer front-end alle risorse back-end. Le modifiche apportate alla configurazione del servizio di bilanciamento del carico del cluster gestito o alle regole del gruppo di sicurezza di rete influiscono sia sul routing IPv4 che su IPv6.

Nota

Questa impostazione non è disponibile nel portale e non può essere modificata dopo la creazione del cluster.

• L'api api api del cluster gestito di Service Fabric deve essere 2022-01-01 o successiva.

1. Impostare la proprietà seguente in una risorsa cluster gestita di Service Fabric.

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

2. Distribuire il cluster gestito abilitato per IPv6. Personalizzare il modello di esempio in base alle esigenze o compilare il proprio. Nell'esempio seguente verrà creato un gruppo di risorse chiamato MyResourceGroup in westus e distribuito un cluster con questa funzionalità abilitata.

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

   Dopo la distribuzione, le risorse e la rete virtuale dei cluster saranno dual stack. Di conseguenza, il servizio di bilanciamento del carico front-end dei cluster avrà un indirizzo DNS univoco creato, ad esempio, mycluster-ipv6.southcentralus.cloudapp.azure.com associato a un indirizzo IPv6 pubblico negli indirizzi IPv6 Azure Load Balancer e privati nelle macchine virtuali.

Bring Your Own Virtual Network

Questa funzionalità consente ai clienti di usare una rete virtuale esistente specificando una subnet dedicata in cui verrà distribuito il cluster gestito. Ciò può essere utile se si dispone già di una rete virtuale e una subnet configurate con i criteri di sicurezza e il routing del traffico correlati che si vuole usare. Dopo la distribuzione in una rete virtuale esistente, è facile usare o incorporare altre funzionalità di rete, ad esempio Azure ExpressRoute, Azure Gateway VPN, un gruppo di sicurezza di rete e il peering di rete virtuale. Se necessario, è anche possibile usare il servizio di bilanciamento del carico di Azure personalizzato.

Nota

Quando si usa BYOVNET, le risorse del cluster gestito verranno distribuite in una subnet.

Nota

Questa impostazione non può essere modificata dopo la creazione del cluster e il cluster gestito assegnerà un gruppo di sicurezza di rete alla subnet specificata. Non eseguire l'override dell'assegnazione del gruppo di sicurezza di rete o il traffico potrebbe interrompersi.

Per usare una rete virtuale personalizzata:

1. Ottenere il servizio Id dalla sottoscrizione per l'applicazione del provider di risorse di Service Fabric.

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

   Nota

   Assicurarsi di essere nella sottoscrizione corretta, l'ID entità cambierà se la sottoscrizione si trova in un tenant diverso.

   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
   

   Prendere nota dell'ID dell'output precedente come principalId da usare in un passaggio successivo

   Nome definizione ruolo	ID di definizione del ruolo
   Collaboratore di rete	4d97b98b-1d4f-4787-a291-c67834d212e7

   Prendere nota dei valori delle Role definition name proprietà e Role definition ID da usare in un passaggio successivo

2. Aggiungere un'assegnazione di ruolo all'applicazione Provider di risorse di Service Fabric. L'aggiunta di un'assegnazione di ruolo è un'azione una sola volta. Per aggiungere il ruolo, eseguire i comandi di PowerShell seguenti o configurare un modello di Azure Resource Manager (ARM) come descritto di seguito.

   Nei passaggi seguenti si inizia con una rete virtuale esistente denominata ExistingRG-vnet, nel gruppo di risorse ExistingRG. Il nome della subnet è quello predefinito.

   Ottenere le informazioni necessarie dalla rete virtuale esistente.

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

   Si noti il nome della subnet e Id il valore della proprietà seguenti restituiti dalla Subnets sezione nella risposta che verrà usata nei passaggi successivi.

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

   Eseguire il comando di PowerShell seguente usando l'ID entità, il nome della definizione del ruolo del passaggio 2 e l'ambito Id di assegnazione ottenuto in precedenza:

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

   In alternativa, è possibile aggiungere l'assegnazione di ruolo usando un modello di Azure Resource Manager (ARM) configurato con i valori appropriati per principalId, roleDefinitionId, vnetNamee 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"
      }
   

   Nota

   VNetRoleAssignmentID deve essere un GUID. Se si distribuisce di nuovo un modello con questa assegnazione di ruolo, assicurarsi che il GUID sia uguale a quello usato in origine. È consigliabile eseguire questa risorsa isolata o rimuovere questa risorsa dal modello di cluster dopo la distribuzione perché deve essere creata una sola volta.

   Ecco un modello di Esempio completo di Azure Resource Manager (ARM) che crea una subnet di rete virtuale ed esegue l'assegnazione di ruolo che è possibile usare per questo passaggio.

3. Configurare la subnetId proprietà per la distribuzione del cluster dopo la configurazione del ruolo, come illustrato di seguito:

• L'api api della risorsa cluster gestita di Service Fabric deve essere 2022-01-01 o successiva.

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

  Vedere il modello di esempio Bring Your Own VNet cluster (Bring Your Own VNet Cluster) o personalizzare il proprio.

4. Distribuire il modello di Azure Resource Manager (ARM) del cluster gestito configurato.

   Nell'esempio seguente si creerà un gruppo di risorse denominato MyResourceGroup in westus e si distribuirà un cluster con questa funzionalità abilitata.

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

   Quando si usa la subnet della rete virtuale personalizzata, l'endpoint pubblico viene ancora creato e gestito dal provider di risorse, ma nella subnet configurata. La funzionalità non consente di specificare l'ip pubblico/riutilizzare l'ip statico nel Azure Load Balancer. È possibile usare i propri Azure Load Balancer insieme a questa funzionalità o da solo se sono necessari scenari di bilanciamento del carico o altri scenari di bilanciamento del carico non supportati in modo nativo.

Bring your own Azure Load Balancer

I cluster gestiti creano un Load Balancer Standard pubblico di Azure e un nome di dominio completo con un indirizzo IP pubblico statico per i tipi di nodo primario e secondario. Bring Your Own Load Balancer consente di usare un Azure Load Balancer esistente per i tipi di nodo secondari per il traffico in ingresso e in uscita. Quando si porta il proprio Azure Load Balancer, è possibile:

• Usare un indirizzo IP statico Load Balancer preconfigurato per il traffico privato o pubblico
• Eseguire il mapping di un Load Balancer a un tipo di nodo specifico
• Configurare le regole del gruppo di sicurezza di rete per ogni tipo di nodo perché ogni tipo di nodo viene distribuito nella propria subnet
• Mantenere i criteri e i controlli esistenti che potrebbero essere presenti
• Configurare un servizio di bilanciamento del carico solo interno e usare il servizio di bilanciamento del carico predefinito per il traffico esterno

Nota

Quando si usa BYOVNET, le risorse del cluster gestito verranno distribuite in una subnet con un gruppo di sicurezza di rete indipendentemente dai servizi di bilanciamento del carico aggiuntivi configurati.

Nota

Non è possibile passare dal servizio di bilanciamento del carico predefinito a uno personalizzato dopo la distribuzione di un tipo di nodo, ma è possibile modificare la configurazione del servizio di bilanciamento del carico personalizzata dopo la distribuzione, se abilitata.

Requisiti delle funzionalità

• Sono supportati i tipi Azure Load Balancer SKU Basic e Standard
• È necessario avere pool BACK-end e NAT configurati nel Azure Load Balancer
• È necessario abilitare la connettività in uscita usando un servizio di bilanciamento del carico pubblico fornito o il servizio di bilanciamento del carico pubblico predefinito

Ecco un paio di scenari di esempio per cui i clienti possono usarlo:

In questo esempio, un cliente vuole instradare il traffico attraverso un Azure Load Balancer esistente configurato con un indirizzo IP statico esistente a due tipi di nodo.

In questo esempio, un cliente vuole instradare il traffico attraverso i servizi di bilanciamento del carico di Azure esistenti per aiutarli a gestire il flusso del traffico verso le applicazioni in modo indipendente che si trovano in tipi di nodo distinti. Quando si configura come questo esempio, ogni tipo di nodo si trova dietro il proprio gruppo di sicurezza di rete gestito.

In questo esempio, un cliente vuole instradare il traffico attraverso i servizi di bilanciamento del carico di Azure interni esistenti. In questo modo è possibile gestire il flusso di traffico verso le applicazioni in modo indipendente che risiedono in tipi di nodo separati. Quando si configura come questo esempio, ogni tipo di nodo si trova dietro il proprio gruppo di sicurezza di rete gestito e usa il servizio di bilanciamento del carico predefinito per il traffico esterno.

Per configurare con il servizio di bilanciamento del carico:

1. Ottenere il servizio Id dalla sottoscrizione per l'applicazione del provider di risorse di Service Fabric:

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

   Nota

   Assicurarsi di essere nella sottoscrizione corretta, l'ID entità cambierà se la sottoscrizione si trova in un tenant diverso.

   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
   

   Prendere nota dell'ID dell'output precedente come principalId da usare in un passaggio successivo

   Nome definizione ruolo	ID di definizione del ruolo
   Collaboratore di rete	4d97b98b-1d4f-4787-a291-c67834d212e7

   Prendere nota dei valori delle Role definition name proprietà e Role definition ID da usare in un passaggio successivo

2. Aggiungere un'assegnazione di ruolo all'applicazione Provider di risorse di Service Fabric. L'aggiunta di un'assegnazione di ruolo è un'azione una sola volta. Per aggiungere il ruolo, eseguire i comandi di PowerShell seguenti o configurare un modello di Azure Resource Manager (ARM) come descritto di seguito.

   Nei passaggi seguenti si inizia con un servizio di bilanciamento del carico esistente denominato Existing-LoadBalancer1, nel gruppo di risorse Existing-RG.

   Ottenere le informazioni necessarie Id sulla proprietà dal Azure Load Balancer esistente.

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

   Si noti quanto segue Id che verrà usato nel passaggio successivo:

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

   Eseguire il comando di PowerShell seguente usando l'ID entità, il nome della definizione del ruolo del passaggio 2 e l'ambito Id di assegnazione appena ottenuto:

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

   In alternativa, è possibile aggiungere l'assegnazione di ruolo usando un modello di Azure Resource Manager (ARM) configurato con i valori appropriati per 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"
      }
   

   Nota

   loadBalancerRoleAssignmentID deve essere un GUID. Se si distribuisce di nuovo un modello con questa assegnazione di ruolo, assicurarsi che il GUID sia uguale a quello usato in origine. È consigliabile eseguire questa risorsa isolata o rimuovere questa risorsa dal modello di cluster dopo la distribuzione perché deve essere creata una sola volta.

   Vedere questo modello di esempio per creare un servizio di bilanciamento del carico pubblico e assegnare un ruolo.

3. Configurare la connettività in uscita necessaria per il tipo di nodo. È necessario configurare un servizio di bilanciamento del carico pubblico per fornire la connettività in uscita o usare il servizio di bilanciamento del carico pubblico predefinito.

   Configurare per configurare un servizio di bilanciamento del carico pubblico per fornire la connettività in uscita Vedere il modello creare il servizio di bilanciamento del carico e assegnare un modello di Azure Resource Manager (ARM) di esempio di ruolooutboundRules

   OR

   Per configurare il tipo di nodo per l'uso del servizio di bilanciamento del carico predefinito, impostare quanto segue nel modello:

   • L'api api della risorsa cluster gestita di Service Fabric deve essere 2022-01-01 o successiva.

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

4. Facoltativamente, configurare una porta dell'applicazione in ingresso e un probe correlato nel Azure Load Balancer esistente. Per un esempio, vedere il modello bring your own load balancer di Azure Resource Manager (ARM)

5. Facoltativamente, configurare le regole del gruppo di sicurezza di rete del cluster gestito applicate al tipo di nodo per consentire il traffico necessario configurato nel Azure Load Balancer o il traffico verrà bloccato. Per un esempio di configurazione delle regole del gruppo di sicurezza di rete in ingresso, vedere il modello bring your own load balancer di Azure Resource Manager (ARM). Nel modello cercare la networkSecurityRules proprietà .

6. Distribuire il modello arm del cluster gestito configurato Per questo passaggio si userà il modello bring your own load balancer di Azure Resource Manager (ARM)

   Di seguito viene creato un gruppo di risorse denominato MyResourceGroup in westus e distribuito un cluster usando un servizio di bilanciamento del carico esistente.

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

   Dopo la distribuzione, il tipo di nodo secondario è configurato per usare il servizio di bilanciamento del carico specificato per il traffico in ingresso e in uscita. La connessione client di Service Fabric e gli endpoint del gateway punteranno comunque al DNS pubblico del tipo di nodo primario del cluster gestito indirizzo IP statico.

Abilitare Rete accelerata

La rete accelerata consente la virtualizzazione I/O radice singola (SR-IOV) a una macchina virtuale del set di scalabilità di macchine virtuali che rappresenta la risorsa sottostante per i tipi di nodo. Questo percorso ad alte prestazioni ignora l'host dal percorso dati, riducendo così la latenza, il jitter e l'utilizzo della CPU per i carichi di lavoro di rete più impegnativi. È possibile effettuare il provisioning dei tipi di nodi del cluster gestito di Service Fabric con rete accelerata in SKU di macchine virtuali supportati. Fare riferimento a queste limitazioni e vincoli per considerazioni aggiuntive.

• Si noti che la rete accelerata è supportata nella maggior parte delle dimensioni di istanze per utilizzo generico e ottimizzate per il calcolo con 2 o più vCPU. Nelle istanze che supportano l'hyperthreading, la Rete accelerata è supportata nelle istanze di macchine virtuali con 4 o più vCPU.

Abilitare la rete accelerata dichiarando enableAcceleratedNetworking la proprietà nel modello di Resource Manager come indicato di seguito:

• L'api api della risorsa cluster gestita di Service Fabric deve essere 2022-01-01 o successiva.

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

Per abilitare la rete accelerata in un cluster di Service Fabric esistente, è prima necessario ridimensionare un cluster di Service Fabric aggiungendo un nuovo tipo di nodo ed eseguire le operazioni seguenti:

1. Effettuare il provisioning di un tipo di nodo con rete accelerata abilitata
2. Eseguire la migrazione dei servizi e del relativo stato al tipo di nodo di cui è stato effettuato il provisioning con rete accelerata abilitata

Per abilitare la rete accelerata in un cluster esistente è necessario ridimensionare l'infrastruttura perché l'abilitazione della rete accelerata genera tempi di inattività, in quanto è necessario arrestare e deallocare tutte le macchine virtuali presenti in un set di disponibilità prima di abilitare la rete accelerata in qualsiasi interfaccia di rete esistente.

Configurare le subnet ausiliarie

Le subnet ausiliarie consentono di creare subnet gestite aggiuntive senza un tipo di nodo per scenari di supporto, ad esempio collegamento privato Service e Bastion Hosts.

Configurare le subnet ausiliarie dichiarando auxiliarySubnets la proprietà e i parametri obbligatori nel modello di Resource Manager come indicato di seguito:

• L'api api della risorsa cluster gestita di Service Fabric deve essere 2022-01-01 o successiva.

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

Vedere l'elenco completo dei parametri disponibili

Passaggi successivi

Panoramica delle opzioni di configurazione del cluster gestito di Service Fabric