Imagine that you need to configure Load Balancer (LB) to handle requests from outside to multiple scale sets , virtual machines or internal LB needs to be added in addition to external LBs. You configure VMs, scale sets, load balancer(s), backend pool and define load balancing rule. The following example shows an excerpt from the arm template:
####
"loadBalancingRules": [
{
"name": "[variables('lbInternalName')]",
"properties": {
"frontendIPConfiguration": {
"id": "[variables('lbInternalFrontEndId')]"
},
"backendAddressPool": {
"id": "[variables('lbInternalBackEndPoolId')]"
},
"protocol": "Tcp",
"frontendPort": 80,
"backendPort": 80,
"enableFloatingIP": false,
"idleTimeoutInMinutes": 5,
"probe": {
"id": "[variables('lbInternalProbeId')]"
}
}
}
],
####
What can go wrong? Pay attention to the Load Balancer SKU.
You deployment/configuration may fail with the following errrors:
- Network <..> associated with different availability set <…>
- Network Interface and Load Balancer are in different availability sets
And, if you are trying to configure scale sets with multiple load balancers:
- Different basic sku and standard sku load balancer or public Ip resources in VMSS is not allowed
So, if your goal is to associate multiple scale sets with a load balancer, the load balancer must be Standard. Only Standard LB allows you to have multiple endpoints in a backend pool. Also, make sure you are not mixing the LB SKUs. It happens often when int and ext LBs are in use.
UseIT | Roman Levchenko 