Condividi tramite

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

  • Articolo

I cluster gestiti di Service Fabric vengono creati con una configurazione di rete predefinita. Questa configurazione è costituita da un servizio di bilanciamento del carico di Azure con un indirizzo IP pubblico, una rete virtuale con una subnet allocata e un gruppo di sicurezza di rete configurato per le funzionalità essenziali del cluster. Esistono anche regole del gruppo di sicurezza di rete facoltative applicate, ad esempio consentendo tutto il traffico in uscita per impostazione predefinita, che consente di semplificare la configurazione dei clienti. Questo documento illustra come modificare le opzioni di configurazione di rete seguenti e altro ancora:

Gestire le regole del gruppo di sicurezza di rete

Linee guida per le 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 del gruppo di sicurezza di rete compreso tra 0 e 999 per le 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à da 3001 a 4000 per la creazione di regole del gruppo di sicurezza di rete facoltative. Queste regole vengono aggiunte automaticamente per semplificare e semplificare le configurazioni. È possibile eseguire l'override di queste regole aggiungendo regole del gruppo di sicurezza di rete personalizzate nell'intervallo di priorità da 1000 a 3000.
  • Le regole del gruppo di sicurezza di rete personalizzate devono avere una priorità compresa tra 1000 e 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": [
      "..."
    ]
  }
}

Regole predefinite e facoltative di ClientConnection e HttpGatewayConnection

Regola del gruppo di sicurezza di rete: SFMC_AllowServiceFabricGatewayToSFRP

Viene aggiunta una regola del gruppo di sicurezza di rete predefinita per consentire al provider di risorse di Service Fabric di accedere al client del clusterConnectionPort e httpGatewayConnectionPort. Questa regola consente l'accesso alle porte tramite il tag ServiceFabricdel servizio .

Nota

Questa regola viene sempre aggiunta e non può essere sottoposta 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 del gruppo di sicurezza di rete: SFMC_AllowServiceFabricGatewayPorts

Questa regola facoltativa consente ai clienti di accedere a SFX, connettersi al cluster tramite PowerShell e usare gli endpoint API del 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 abilitano 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 del gruppo di sicurezza di rete seguente viene 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-{nome-cluster}

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

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

    Regole NAT in ingresso

    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 usare 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.

Lo screenshot seguente mostra l'uso di Connessione Desktop remoto per connettersi al nodo delle app (Istanza 0) in un cluster Di Windows:

Connessione Desktop remoto

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 del gruppo di sicurezza di rete nell'intervallo di priorità predefinito per tutte le porte di bilanciamento del carico (LB) 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à facoltativo e può essere sostituita aggiungendo regole del gruppo 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 i propri indirizzi IP pubblici per la comunicazione. Tuttavia, alcuni scenari possono richiedere a un nodo di avere un proprio indirizzo IP pubblico per comunicare con i servizi Internet e pubblici di Azure. Ad esempio:

  • Giochi, in cui una console deve stabilire una connessione diretta a una macchina virtuale cloud che esegue l'elaborazione della fisica del gioco.
  • Macchine virtuali che devono stabilire connessioni esterne l'una all'altra 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 nodo secondario, perché i tipi di nodo primario sono riservati per i 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'indirizzo 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 arm.

  4. Verificare di disporre di 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

    Il comando restituisce l'output 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

I cluster gestiti non abilitano IPv6 per impostazione predefinita. Questa funzionalità abilita la funzionalità IPv4/IPv6 dual stack completa dal front-end di Load Balancer alle risorse back-end. Tutte le modifiche apportate alla configurazione del servizio di bilanciamento del carico del cluster gestito o alle regole del gruppo di sicurezza di rete influiscono sul routing IPv4 e IPv6.

Nota

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

  • La versione API della risorsa 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 creare un modello personalizzato. Nell'esempio seguente viene creato un gruppo di risorse denominato MyResourceGroup in westus e viene 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, la rete virtuale e le risorse dei cluster saranno dual stack. Di conseguenza, il servizio di bilanciamento del carico front-end dei cluster ha un indirizzo DNS univoco creato, ad esempio, mycluster-ipv6.southcentralus.cloudapp.azure.com associato a un indirizzo IPv6 pubblico negli indirizzi IPv6 di Azure Load Balancer e IPv6 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 il cluster gestito distribuisce le risorse. Ciò può essere utile se si dispone già di una rete virtuale e una subnet configurate con i criteri di sicurezza correlati e il routing del traffico 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. È anche possibile usare il servizio di bilanciamento del carico di Azure, se necessario.

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 fornita. 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 Un 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 e Id il valore della proprietà della subnet 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 di Id 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, roleDefinitionIdvnetName, e 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 includendo questa assegnazione di ruolo, assicurarsi che il GUID corrisponda a quello usato in origine. È consigliabile eseguire questa risorsa isolata o rimuoverla dal modello di cluster dopo la distribuzione perché deve essere creata una sola volta.

    Ecco un modello di Azure Resource Manager (ARM) di esempio completo 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:

  • La versione API della risorsa cluster gestito 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 virtual network cluster o personalizzare i propri.

  1. 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 una subnet di rete virtuale personalizzata, l'endpoint pubblico viene comunque creato e gestito dal provider di risorse, ma nella subnet configurata. La funzionalità non consente di specificare l'ip pubblico/usare nuovamente l'ip statico in Azure Load Balancer. È possibile usare Azure Load Balancer in combinazione con questa funzionalità o autonomamente se sono necessari gli scenari o altri scenari di bilanciamento del carico non supportati in modo nativo.

    Viene creato il cluster, viene creato un gruppo di sicurezza di rete nel gruppo di risorse gestite per la subnet predefinita a livello di cluster. Quando viene creato un tipo di nodo, viene inserito in questa subnet e eredita automaticamente le regole del gruppo di sicurezza di rete, a meno che non si usino subnet a livello di nodo.

    Bring Your Own Virtual Network supporta anche subnet a livello di nodo, che consentono di inserire i tipi di nodo in subnet separate, offrendo flessibilità per varie configurazioni e configurazioni di rete.

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

    Per usare le subnet a livello di tipo di nodo, specificare "useCustomVnet": true nella definizione del cluster gestito. Quando "useCustomVnet" è impostato su true, non viene creata una subnet del cluster predefinita. Quando si usano subnet a livello di tipo di nodo, subnetId diventa una proprietà obbligatoria nella definizione del tipo di nodo.

    Importante

    Quando si usano subnet a livello di tipo di nodo, è necessario assegnare un gruppo di sicurezza di rete alla subnet del tipo di nodo prima della creazione del tipo di nodo. Il gruppo di sicurezza di rete deve includere la regola in ingresso necessaria SFMC_AllowServiceFabricGatewayToSFRP o la creazione del tipo di nodo non riesce.

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'istanza di Azure Load Balancer esistente per i tipi di nodo secondari per il traffico in ingresso e in uscita. Quando si bring your own Azure Load Balancer, è possibile:

  • Usare un indirizzo IP statico di Load Balancer preconfigurato per il traffico privato o pubblico
  • Eseguire il mapping di un servizio di bilanciamento del carico 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 configurati aggiuntivi.

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 personalizzata del servizio di bilanciamento del carico dopo la distribuzione, se abilitata.

Requisiti per le funzionalità

  • Il tipo azure Load Balancer dello SKU Standard è supportato
  • È necessario avere pool BACK-end e NAT configurati in 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'istanza di Azure Load Balancer esistente configurata con un indirizzo IP statico esistente a due tipi di nodo.

Bring Your Own Load Balancer example 1 (Bring Your Own Load Balancer example 1)

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 di traffico alle applicazioni in modo indipendente che si trovano 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.

Esempio di Bring Your Own Load Balancer 2

In questo esempio, un cliente vuole instradare il traffico attraverso i servizi di bilanciamento del carico interni esistenti. In questo modo è possibile gestire il flusso di traffico verso le applicazioni in modo indipendente che si dividono 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.

Esempio di Bring Your Own Load Balancer 3

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 Un 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 sulle proprietà necessarie Id da 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 di Id 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 includendo questa assegnazione di ruolo, assicurarsi che il GUID corrisponda a quello usato in origine. È consigliabile eseguire questa risorsa isolata o rimuoverla 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 connettività in uscita o usare il servizio di bilanciamento del carico pubblico predefinito.

    Configurare outboundRules 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 ruolo

    OPPURE

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

    • La versione API della risorsa cluster gestito 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 in 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 in Azure Load Balancer o il traffico verrà bloccato. Per un esempio di configurazione della regola 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 verrà 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 l'uso del 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 di 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ù esigenti. È 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 dell'istanza 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 la enableAcceleratedNetworking proprietà nel modello di Resource Manager come indicato di seguito:

  • La versione API della risorsa cluster gestito 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, è necessario prima 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 offrono la possibilità 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:

  • La versione API della risorsa cluster gestito 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 opzionidi configurazione del cluster gestito di Service Fabric