Configuración de la red para clústeres administrados de Service Fabric

Los clústeres administrados de Service Fabric se crean con una configuración de red predeterminada. Esta configuración consta de una Azure Load Balancer con una dirección IP pública, una red virtual con una subred asignada y un grupo de seguridad de red configurado para la funcionalidad esencial del clúster. También se aplican reglas de NSG opcionales, como permitir todo el tráfico saliente de manera predeterminada, que están pensadas para facilitar la configuración del cliente. En este documento se explica cómo modificar las siguientes opciones de configuración de red, entre otras cosas:

• Administración de reglas de grupos de seguridad de red
• Administración del acceso RDP
• Administración de la configuración del equilibrador de carga
• Habilitación de la dirección IP pública
• Habilitación de IPv6
• Traer su propia red virtual
• Traer su propio equilibrador de carga
• Habilitación de la redes aceleradas
• Configuración de subredes auxiliares

Administración de reglas de grupos de seguridad de red

Orientaciones sobre las reglas del grupo de seguridad de red

Tenga en cuenta estas consideraciones al crear nuevas reglas del grupo de seguridad de red para el clúster administrado.

• Los clústeres administrados de Service Fabric reservan el intervalo de prioridad de la regla de grupo de seguridad de red del 0 al 999 para la funcionalidad esencial. No se pueden crear reglas de grupos de seguridad de red personalizadas con un valor de prioridad inferior a 1000.
• Los clústeres administrados de Service Fabric reservan el intervalo de prioridad de 3001 a 4000 para crear reglas de grupo de seguridad de red opcionales. Estas reglas se agregan automáticamente para que las configuraciones sean rápidas y sencillas. Para invalidar estas reglas puede agregar reglas de grupo de seguridad de red personalizadas en el intervalo de prioridad de 1000 a 3000.
• Las reglas de grupo de seguridad de red personalizadas deben tener una prioridad en el intervalo de 1000 a 3000.

Aplicación de las reglas de grupo de seguridad de red

Los clústeres administrados de Service Fabric le permiten asignar reglas de grupo de seguridad de red directamente en el recurso de clúster de la plantilla de implementación.

Use la propiedad networkSecurityRules del recurso Microsoft.ServiceFabric/managedclusters (versión 2021-05-01 o posterior) para asignar reglas de grupo de seguridad de red. Por ejemplo:

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

Reglas predeterminadas y opcionales de ClientConnection y HttpGatewayConnection

Regla de grupo de seguridad de red: SFMC_AllowServiceFabricGatewayToSFRP

Se agrega una regla de grupo de seguridad de red predeterminada para permitir que el proveedor de recursos de Service Fabric tenga acceso a los puertos clientConnectionPort y httpGatewayConnectionPort del clúster. Esta regla permite el acceso a los puertos a través de la etiqueta de servicio ServiceFabric.

Nota:

Esta regla se agrega siempre y no se puede invalidar.

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

Regla de grupo de seguridad de red: SFMC_AllowServiceFabricGatewayPorts

Esta regla opcional permite a los clientes acceder a SFX, conectarse al clúster mediante PowerShell y usar puntos de conexión de API de clúster de Service Fabric desde Internet abriendo los puertos LB para clientConnectionPort y httpGatewayPort.

Nota:

Esta regla no se agregará si hay una regla personalizada con los mismos valores de acceso, dirección y protocolo para el mismo puerto. Puede invalidar esta regla con reglas de grupo de seguridad de red personalizadas.

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

Permitir el acceso a los puertos RDP desde Internet

Los clústeres administrados de Service Fabric no permiten el acceso entrante a los puertos RDP desde Internet de forma predeterminada. Para abrir el acceso entrante a los puertos RDP desde Internet, establezca la siguiente propiedad en un recurso de clúster administrado de Service Fabric.

"allowRDPAccess": true

Cuando la propiedad allowRDPAccess se establece en true, se agrega la siguiente regla de NSG a la implementación del clúster.

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

Los clústeres administrados de Service Fabric crean automáticamente reglas NAT de entrada para cada instancia de un tipo de nodo. Para buscar las asignaciones de puertos para llegar a instancias específicas (nodos de clúster), siga estos pasos:

Use Azure Portal para buscar el clúster administrado creado por las reglas NAT de entrada para Protocolo de Escritorio remoto (RDP).

1. Vaya al grupo de recursos de clúster administrado dentro de la suscripción cuyo nombre tiene el siguiente formato: SFC_{cluster-id}

2. Seleccione el equilibrador de carga para el clúster con el siguiente formato: LB-{cluster-name}

3. En la página de su equilibrador de carga, seleccione Reglas NAT de entrada. Revise las reglas NAT de entrada para confirmar la asignación de puerto front-end de entrada a puerto de destino para un nodo.

   La siguiente captura de pantalla muestra las reglas NAT de entrada para tres tipos de nodos:

   

   De forma predeterminada, para los clústeres de Windows, el puerto de front-end está en el intervalo de 50000 y superiores, y el puerto de destino es el puerto 3389, que se asigna al servicio RDP en el nodo de destino.

   Nota:

   Si usa la característica BYOLB y desea RDP, debe configurar un grupo NAT por separado para hacerlo. Esto no creará automáticamente ninguna regla NAT para esos tipos de nodo.

4. Conéctese de forma remota al nodo específico (instancia del conjunto de escalado). Puede usar el nombre de usuario y la contraseña que estableció cuando creó el clúster u otras credenciales que haya configurado.

La siguiente captura de pantalla muestra cómo usar Conexión a Escritorio remoto para conectarse al nodo de aplicaciones (instancia 0) en un clúster Windows:

Modificación de la configuración predeterminada del equilibrador de carga

Puertos del equilibrador de carga

Los clústeres administrados de Service Fabric crean una regla de grupo de seguridad de red en el intervalo de prioridad predeterminado de todos los puertos del equilibrador de carga (LB) configurados en la sección "loadBalancingRules" en las propiedades de ManagedCluster. Esta regla abre los puertos del equilibrador de carga para el tráfico entrante desde Internet.

Nota:

Esta regla se agrega en el intervalo de prioridad opcional y se puede invalidar mediante la adición de reglas de grupo de seguridad de red personalizadas.

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

Sondeos del equilibrador de carga

Los clústeres administrados de Service Fabric crean automáticamente sondeos del equilibrador de carga para los puertos de Fabric Gateway y para todos los puertos configurados en la sección loadBalancingRules de las propiedades del clúster administrado.

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

Habilitación de la dirección IP pública

Nota:

Actualmente, solo se admite IPv4 público.

Los nodos de clústeres administrados de Service Fabric no necesitan sus propias direcciones IP públicas para la comunicación. Sin embargo, algunos escenarios pueden requerir que un nodo tenga su propia dirección IP pública para comunicarse con Internet y los servicios de Azure orientados al público. Por ejemplo:

• Los juegos, en los que se necesita una consola para tener una conexión directa a una máquina virtual en la nube, que esté realizando el procesamiento físico de los juegos.
• Las máquinas virtuales que necesitan realizar conexiones externas entre sí a través de regiones en una base de datos distribuida.

Para más información acerca de las conexiones salientes en Azure, consulte Comprender las conexiones salientes en Azure.

La dirección IP pública solo se puede habilitar en los tipos de nodo secundario, ya que los tipos de nodo principal están reservados para los servicios del sistema de Service Fabric. Siga los pasos descritos en la sección Traiga su propio equilibrador de carga de este artículo para crear un tipo de nodo secundario para el clúster administrado.

Azure asigna dinámicamente direcciones IP disponibles.

Nota:

La habilitación de la dirección IP pública solo se admite a través de la plantilla de ARM.

En los pasos siguientes se describe cómo habilitar la dirección IP pública en el nodo.

1. Descargue la plantilla de ARM.

2. Para cada tipo de nodo de la plantilla, agregue enableNodePublicIP a la plantilla de 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. Implemente la plantilla de ARM.

4. Compruebe que tiene una dirección IP pública en los nodos mediante la ejecución del siguiente comando de PowerShell:

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

   El comando se genera en 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"
       }
     }
   ]
   

Habilitación de IPv6

Los clústeres administrados no habilitan IPv6 de forma predeterminada. Esta característica habilita la funcionalidad IPv4/IPv6 de pila doble completa desde el front-end de Equilibrador de carga a los recursos de back-end. Los cambios realizados en la configuración del equilibrador de carga del clúster administrado o las reglas de NSG afectan al enrutamiento IPv4 e IPv6.

Nota:

Esta configuración no está disponible en el portal y no se puede cambiar una vez creado el clúster.

• El valor de apiVersion del recurso de clúster administrado de Service Fabric debe ser 2022-01-01 o posterior.

1. Establezca la siguiente propiedad en un recurso de clúster administrado de Service Fabric.

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

2. Implemente el clúster administrado habilitado para IPv6. Personalice la plantilla de ejemplo según lo necesite o cree la suya propia. En el ejemplo siguiente, creamos un grupo de recursos denominado MyResourceGroup en westus e implementamos un clúster con esta característica habilitada.

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

   Tras la implementación, los recursos y la red virtual del clúster serán de doble pila. Como resultado, el equilibrador de carga de front-end de clústeres tiene una dirección DNS única creada, por ejemplo, mycluster-ipv6.southcentralus.cloudapp.azure.com que está asociada a una dirección IPv6 pública en las direcciones IPv6 de Azure Load Balancer e IPv6 privadas en las máquinas virtuales.

Traer su propia red virtual

Esta característica permite a los clientes usar una red virtual existente especificando una subred dedicada en la que el clúster administrado implementa sus recursos. Esto puede ser útil si ya tiene una red virtual configurada y una subred con directivas de seguridad relacionadas y enrutamiento de tráfico que desea usar. Tras implementar en una red virtual existente, es fácil usar e incorporar otras características de red como Azure ExpressRoute, Azure VPN Gateway, un grupo de seguridad de red y emparejamiento de redes virtuales. También puede traer su propia instancia de Azure Load Balancer si es necesario.

Nota:

Al usar BYOVNET, los recursos de clúster administrados se implementarán en una subred.

Nota:

Esta configuración no se puede cambiar una vez creado el clúster, y el clúster administrado asignará un grupo de seguridad de red a la subred proporcionada. No invalide la asignación del grupo de seguridad de red o el tráfico podría interrumpirse.

Para traer su propia red virtual:

1. Obtenga el servicio Id de su suscripción de la aplicación de proveedor de recursos de Service Fabric.

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

   Nota:

   Asegúrese de que se encuentra en la suscripción correcta; el identificador de la entidad de seguridad cambia si la suscripción está en otro inquilino.

   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
   

   Anote el identificador de la salida anterior como principalId para usarlo en un paso posterior.

   El nombre de la definición de roles	Id. de definición de roles
   Colaborador de la red	4d97b98b-1d4f-4787-a291-c67834d212e7

   Anote los valores de propiedad Role definition name y Role definition ID para usarlos en un paso posterior.

2. Agregue una asignación de roles a la aplicación de proveedor de recursos de Service Fabric. Agregar una asignación de roles es una acción única aislada. Para agregar el rol, ejecute los siguientes comandos de PowerShell o configure una plantilla de Azure Resource Manager (ARM) como se detalla a continuación.

   En los siguientes pasos, vamos a empezar con una red virtual existente denominada ExistingRG-vnet en el grupo de recursos ExistingRG. La subred recibe un nombre predeterminado.

   Obtenga la información necesaria de la red virtual existente.

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

   Anote el siguiente nombre de subred y el valor de propiedad Id que se devuelve en la sección Subnets de la respuesta para usarlos en pasos posteriores.

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

   Ejecute el siguiente comando de PowerShell usando el identificador de entidad de seguridad, el nombre de definición de rol del paso 2 y el ámbito de asignación Id obtenidos anteriormente:

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

   También puede agregar la asignación de roles usando una plantilla de Azure Resource Manager (ARM) configurada con los valores adecuados de principalId, roleDefinitionId y vnetNamesubnetName:

      "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 debe ser un GUID. Si vuelve a implementar una plantilla que incluya esta asignación de roles, asegúrese de que el GUID es el mismo que el que usó originalmente. Se recomienda ejecutar este recurso aislado o quitarlo de la plantilla de clúster tras la implementación, ya que solo debe crearse una vez.

   Este es un ejemplo completo Plantilla de Azure Resource Manager (ARM) que crea una subred de red virtual y realiza la asignación de roles puede usar para este paso.

3. Configure la propiedad subnetId para la implementación del clúster después de configurar el rol como se muestra aquí:

• El valor de apiVersion del recurso de clúster administrado de Service Fabric debe ser 2022-01-01 o posterior.

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

  Consulte el traiga su propia plantilla de ejemplo de clúster de red virtual o personalice su propia.

4. Implemente la plantilla de Azure Resource Manager (ARM) de clúster administrado que ha configurado.

   En el siguiente ejemplo, crearemos un grupo de recursos llamado MyResourceGroup en westus e implementaremos un clúster con esta característica habilitada.

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

   Cuando traiga su propia subred de red virtual, el proveedor de recursos todavía crea y administra el punto de conexión público, pero en la subred configurada. La característica no permite especificar la dirección IP pública ni reutilizar la dirección IP estática en Azure Load Balancer. Puede traer su propia instancia de Azure Load Balancer, ya sea junto con esta característica o de forma aislada, si necesita esos u otros escenarios de equilibrador de carga que no se admiten de forma nativa.

   Cuando se crea el clúster, se crea un grupo de seguridad de red en el grupo de recursos administrado para la subred de nivel de clúster predeterminado. Cuando se crea un tipo de nodo, se coloca en esta subred y hereda automáticamente las reglas del grupo de seguridad de red, a menos que use subredes de nivel de tipo de nodo.

   Traiga su propia red virtual también admite subredes de nivel de tipo de nodo, que permiten colocar tipos de nodo en subredes independientes, lo que proporciona flexibilidad para varias configuraciones y configuraciones de red.

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

   Para usar subredes de nivel de tipo de nodo, especifique "useCustomVnet": true en la definición del clúster administrado. Cuando "useCustomVnet" se establece en true, no se crea una subred de clúster predeterminada. Al usar subredes de nivel de tipo de nodo, subnetId se convierte en una propiedad necesaria en la definición de tipo de nodo.

   Importante

   Al usar subredes de nivel de tipo de nodo, debe asignar un grupo de seguridad de red a la subred de tipo de nodo antes de la creación del tipo de nodo. El grupo de seguridad de red debe incluir la regla de entrada necesaria SFMC_AllowServiceFabricGatewayToSFRP o se produce un error en la creación del tipo de nodo.

Traiga su propia instancia de Azure Load Balancer

Los clústeres administrados crean una instancia pública de Standard Load Balancer de Azure y un nombre de dominio completo con una dirección IP pública estática en los tipos de nodo principal y secundario. Traer su propio equilibrador de carga permite usar una instancia existente de Azure Load Balancer en los tipos de nodo secundarios para el tráfico entrante y saliente. Si trae su propia instancia de Azure Load Balancer, puede hacer lo siguiente:

• Usar una dirección IP estática de Load Balancer configurada previamente para el tráfico público o privado
• Asignar una instancia de Load Balancer a un tipo de nodo específico
• Configurar reglas de grupo de seguridad de red por tipo de nodo, ya que cada tipo de nodo se implementa en su propia subred
• Mantener las directivas y los controles existentes que pueda tener implementados
• Configurar un equilibrador de carga solo interno y usar el equilibrador de carga predeterminado para el tráfico externo

Nota:

Al usar BYOVNET, los recursos de clúster administrados se implementarán en una subred con un NSG independientemente de los equilibradores de carga configurados adicionales.

Nota:

No puede pasar del equilibrador de carga predeterminado a uno personalizado después de la implementación de un tipo de nodo, pero puede modificar la configuración personalizada del equilibrador de carga tras la implementación, si está habilitada.

Requisitos de la característica

• Se admiten tipos de SKU estándar y básicas de Azure Load Balancer.
• Debe tener grupos de NAT y back-end configurados en la instancia de Azure Load Balancer
• Debe habilitar la conectividad saliente mediante un equilibrador de carga público proporcionado o el equilibrador de carga público predeterminado

Estos son un par de escenarios de ejemplo en los que los clientes pueden hacer uso de esto:

En este ejemplo, un cliente quiere enrutar el tráfico a dos tipos de nodo a través de una instancia de Azure Load Balancer existente configurada con una dirección IP estática.

En este ejemplo, un cliente quiere enrutar el tráfico a través de instancias de Azure Load Balancer existentes como ayuda para administrar el flujo de tráfico a sus aplicaciones que se encuentran en tipos de nodo independientes. Cuando se configura como en este ejemplo, cada tipo de nodo está detrás de su propio NSG administrado.

En este ejemplo, un cliente quiere enrutar el tráfico a través de instancias internas existentes de Azure Load Balancer. Esto le ayuda a administrar el flujo de tráfico a sus aplicaciones independientemente de que residan en tipos de nodo independientes. Cuando se configura como en este ejemplo, cada tipo de nodo está detrás de su propio NSG administrado y usa el equilibrador de carga predeterminado para el tráfico externo.

Para configurar con su propio equilibrador de carga:

1. Obtenga el servicio Id de su suscripción de la aplicación de proveedor de recursos de Service Fabric:

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

   Nota:

   Asegúrese de que se encuentra en la suscripción correcta; el identificador de la entidad de seguridad cambia si la suscripción está en otro inquilino.

   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
   

   Anote el identificador de la salida anterior como principalId para usarlo en un paso posterior.

   El nombre de la definición de roles	Id. de definición de roles
   Colaborador de la red	4d97b98b-1d4f-4787-a291-c67834d212e7

   Anote los valores de propiedad Role definition name y Role definition ID para usarlos en un paso posterior.

2. Agregue una asignación de roles a la aplicación de proveedor de recursos de Service Fabric. Agregar una asignación de roles es una acción única aislada. Para agregar el rol, ejecute los siguientes comandos de PowerShell o configure una plantilla de Azure Resource Manager (ARM) como se detalla a continuación.

   En los siguientes pasos, empezaremos con un equilibrador de carga existente denominado Existing-LoadBalancer1 en el grupo de recursos Existing-RG.

   Obtenga la información de la propiedad Id necesaria de la instancia de Azure Load Balancer existente.

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

   Anote el siguiente Id, que usaremos en el siguiente paso:

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

   Ejecute el siguiente comando de PowerShell usando el identificador de entidad de seguridad, el nombre de definición de rol del paso 2 y el ámbito de asignación Id que acabamos de obtener:

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

   También puede agregar la asignación de roles mediante una plantilla de Azure Resource Manager (ARM) configurada con los valores adecuados de 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 debe ser un GUID. Si vuelve a implementar una plantilla que incluya esta asignación de roles, asegúrese de que el GUID es el mismo que el que usó originalmente. Se recomienda ejecutar este recurso aislado o quitarlo de la plantilla de clúster tras la implementación, ya que solo debe crearse una vez.

   Vea esta plantilla de ejemplo para crear un equilibrador de carga público y asignar un rol.

3. Configure la conectividad saliente necesaria en el tipo de nodo. Debe configurar un equilibrador de carga público para proporcionar conectividad saliente o usar el equilibrador de carga público predeterminado.

   Establezca outboundRules para configurar un equilibrador de carga público a fin de proporcionar conectividad saliente. Vea la plantilla de Azure Resource Manager (ARM) de ejemplo para crear un equilibrador de carga y asignar un rol

   O BIEN

   Para configurar el tipo de nodo para usar el equilibrador de carga predeterminado, establezca lo siguiente en la plantilla:

   • El valor de apiVersion del recurso de clúster administrado de Service Fabric debe ser 2022-01-01 o posterior.

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

4. Opcionalmente, configure un puerto de aplicación de entrada y un sondeo relacionado en la instancia de Azure Load Balancer. Vea la plantilla de Azure Resource Manager (ARM) de ejemplo para traer su propio equilibrador de carga a fin de obtener un ejemplo

5. Opcionalmente, configure las reglas de grupo de seguridad de red del clúster administrado aplicadas al tipo de nodo para permitir cualquier tráfico necesario que se haya configurado en la instancia de Azure Load Balancer o el tráfico se bloqueará. Vea la plantilla de Azure Resource Manager (ARM) de ejemplo para traer su propio equilibrador de carga a fin de obtener un ejemplo sobre la configuración de una regla de NSG entrante. En la plantilla, busque la propiedad networkSecurityRules.

6. Implemente la plantilla de ARM del clúster administrado configurada. Para este paso se usa la plantilla de Azure Resource Manager (ARM) de ejemplo para traer su propio equilibrador de carga

   A continuación se crea un grupo de recursos de nombre MyResourceGroup en westus y se implementa un clúster mediante un equilibrador de carga existente.

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

   Después de la implementación, el tipo de nodo secundario se configura para usar el equilibrador de carga especificado para el tráfico entrante y saliente. Los puntos de conexión de puerta de enlace y la conexión de cliente de Service Fabric seguirán apuntando al DNS público de la dirección IP estática del tipo de nodo principal del clúster administrado.

Habilitar Accelerated Networking

Las redes aceleradas permiten la virtualización de E/S de raíz única (SR-IOV) en una máquina virtual del conjunto de escalado de máquinas virtuales que es el recurso subyacente de los tipos de nodo. Esta ruta de acceso de alto rendimiento omite el host de la ruta de acceso de datos, lo que reduce la latencia, la inestabilidad y el uso de CPU de las cargas de trabajo de red más exigentes. Los tipos de nodo de clúster administrado de Service Fabric se pueden aprovisionar con redes aceleradas en SKU de máquina virtual compatibles. Vea estas limitaciones y restricciones para conocer consideraciones adicionales.

• Tenga en cuenta que las redes aceleradas se admiten en la mayoría de los tamaños de instancia de uso general y optimizados para proceso con dos o más CPU virtuales. En instancias que admiten hyperthreading, las redes aceleradas se admiten en instancias de máquina virtual con cuatro o más vCPU.

Habilite las redes aceleradas mediante la declaración de la propiedad enableAcceleratedNetworking en la plantilla de Resource Manager como se muestra a continuación:

• El valor de apiVersion del recurso de clúster administrado de Service Fabric debe ser 2022-01-01 o posterior.

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

Para habilitar las redes aceleradas en un clúster de Service Fabric existente, primero debe escalar horizontalmente un clúster de Service Fabric mediante la adición de un nuevo tipo de nodo y hacer lo siguiente:

1. Aprovisionar un tipo de nodo con redes aceleradas habilitadas
2. Migrar los servicios y su estado al tipo de nodo aprovisionado con redes aceleradas habilitadas

Para habilitar las redes aceleradas en un clúster existente, es necesario escalar horizontalmente la infraestructura dado que si se habilitan tal y como está, se produciría tiempo de inactividad puesto que todas las máquinas virtuales de un conjunto de disponibilidad se tendrían que detener y desasignar antes de habilitarlas en una NIC existente.

Configuración de subredes auxiliares

Las subredes auxiliares ofrecen la posibilidad de crear subredes administradas adicionales sin un tipo de nodo para admitir escenarios como el servicio Private Link y hosts bastión.

Configure subredes auxiliares mediante la declaración de la propiedad auxiliarySubnets y los parámetros necesarios en la plantilla de Resource Manager como se muestra a continuación:

• El valor de apiVersion del recurso de clúster administrado de Service Fabric debe ser 2022-01-01 o posterior.

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

Vea la lista completa de parámetros disponibles

Pasos siguientes

Opciones de configuración del clúster administrado de Service FabricIntroducción a los clústeres administrados de Service Fabric