Deploy a Service Fabric managed cluster with a subnet per NodeType

Service Fabric managed clusters now supports different subnets per NodeType in a Bring-Your-Own-Virtual-Network scenario. With different subnets per NodeType, customers can have specific applications deployed to specific subnets and utilize traffic management via Network Security Group (NSG) rules. Customers can expect increased network isolation for their deployments through this configuration. This feature works on both primary and secondary NodeTypes.

Configure your managed cluster's network properly for your scenario. You can use subnets per NodeType in a Bring-Your-Own-Virtual-Network scenario. You can additionally bring your own Azure Load Balancer, if necessary. Following the appropriate steps for your cluster:

• Bring-Your-Own-Virtual-Network scenario
• Bring-Your-Own-Azure-Load-Balancer scenario

You need to configure the rules of the NSG on the subnet to allow connections from Service Fabric Resource Provider (SFRP). Specifically, SFMC_AllowServiceFabricGatewayToSFRP and SFMC_AllowServiceFabricGatewayToLB must be allowed.

The SFMC_AllowServiceFabricGatewayToSFRP NSG rule should take the following form:

The SFMC_AllowServiceFabricGatewayToLB NSG rule should take the following form:

For ARM template formatting of NSG rules, see the NSG rule: SFMC_AllowServiceFabricGatewayToSFRP section of Configure network settings for Service Fabric managed clusters as an example.

Subnet per NodeType only works for Service Fabric API version 2022-10-01 preview or later.

• For existing clusters in a Bring-Your-Own-Virtual-Network configuration with a subnetId specified, enabling subnet per NodeType overrides the existing value for the current NodeType.
• For new clusters, customers need to specify useCustomVNet : true at the cluster level. This setting indicates that the cluster uses Bring-Your-Own-Virtual-Network but that the subnet is specified at the NodeType level. For such clusters, a virtual network isn't created in the managed resource group. For such clusters, the subnetId property is required for NodeTypes.

When you create a new NodeType, you need to modify your ARM template with the new subnetId property.

{
  "apiVersion": "2022-10-01-preview",
  "type": "Microsoft.ServiceFabric/managedclusters/nodetypes",
  "name": "[concat(parameters('clusterName'), '/', parameters('nodeTypeName'))]",
  "location": "[parameters('clusterLocation')]",
  "dependsOn": [
    "[concat('Microsoft.ServiceFabric/managedclusters/', parameters('clusterName'))]"
  ],
  "properties": {
    "isPrimary": false,
    "subnetId": "[parameters('nodeTypeSubnetId')]",
    "dataDiskSizeGB": "[parameters('dataDiskSizeGB')]",
    "vmImagePublisher": "[parameters('vmImagePublisher')]",
    "vmImageOffer": "[parameters('vmImageOffer')]",
    "vmImageSku": "[parameters('vmImageSku')]",
    "vmImageVersion": "[parameters('vmImageVersion')]",
    "vmSize": "[parameters('vmSize')]",
    "vmInstanceCount": "[parameters('vmInstanceCount')]"
  }
}