1

We have a few Azure VMSS deployments in our subscription, created over the course of a couple years. The earlier one we created, we can scale up to about 50 instances, but the one created a month ago is unable to scale past 15 instances. When trying to do so, I get:

Failed to update autoscale configuration for 't0'. {
  "error": {
    "details": [],
    "code": "InboundNatPoolFrontendPortRangeSmallerThanRequestedPorts",
    "message": "The frontend port range for the inboundNATpool /subscriptions/a48dea64-5847-4d79-aaa6-036530430809/resourceGroups/int-aowappcompat/providers/Microsoft.Network/loadBalancers/LB-int-aowappcompat-t0/inboundNatPools/EtwListenerNatPool-qs8az5dmgu is smaller than the requested number of ports 28 in VM scale set /subscriptions/a48dea64-5847-4d79-aaa6-036530430809/resourceGroups/INT-AOWAPPCOMPAT/providers/Microsoft.Compute/virtualMachineScaleSets/t0."
  }
}.

I've tried to find an answer to how to fix this, but there's virtually nothing out there for InboundNatPoolFrontendPortRangeSmallerThanRequestedPorts except for an unhelpful StackOverflow answer. We've gone through the ARM template as well as all the various UIs for the load balancers, public ip addresses, etc as well as diff'd the old and new ARM templates trying to find the source of the disparity, with no luck. Unfortunately, I'm not a networking whiz, so my knowledge here is fairly shallow.

UPDATE: Here's a relevant (maybe?) from my template:

            "inboundNatPools": [{
                    "name": "LoadBalancerBEAddressNatPool",
                    "properties": {
                        "backendPort": "3389",
                        "frontendIPConfiguration": {
                            "id": "[variables('lbIPConfig0')]"
                        },
                        "frontendPortRangeEnd": "4500",
                        "frontendPortRangeStart": "3389",
                        "protocol": "tcp"
                    }
                }
            ]

I believe this is not a duplicate of the referenced question, as my problem doesn't seem to be an issue with the port range being too small. As you can see from the snippet, the range covers 1111 ports, and I can't even scale to 16 instances. Similarly, comments about overprovisioning don't seem relevant either, as with 1111 ports, I should be able to 16 instances without issue. Of course there may be something I'm not understanding here.

Any tips? Thanks!

UnionP
  • 1,251
  • 13
  • 26
  • Possible duplicate of [Failed to update autoscale configuration. (Azure scale set)](https://stackoverflow.com/questions/47240074/failed-to-update-autoscale-configuration-azure-scale-set) – Hannel Sep 07 '19 at 05:13
  • are you using internal load balancer? – 4c74356b41 Sep 07 '19 at 06:56
  • I'm not sure @4c74356b41, I'm using whatever the default was when setting up a new SF cluster. They're just listed as "Load balancer" in the resource group – UnionP Sep 09 '19 at 17:59

1 Answers1

0

Scale sets currently default to overprovisioning VMs. I also face the same issue. To avoid this, you could wait for the VM instance status to reach a successfully provisioned running status when you manually scale out. Also, you should do not exceed quota limits of Core in your subscription.

enter image description here

Nancy
  • 26,865
  • 3
  • 18
  • 34
  • I just read about overprovisioning, but I'm having trouble understanding how it relates to my issue. Could you elaborate please? It seems like it's just a mechanism to improve scaling speed by temporarily bringing more online than necessary – UnionP Sep 09 '19 at 17:58
  • 1
    I agree and remove it. Just like the [answer](https://stackoverflow.com/questions/47240074/failed-to-update-autoscale-configuration-azure-scale-set), you need to have enough NAT rules to serve the extra VMs when overprovisioning on. I suppose this might be the cause to need more nat rules. For me, the message is temporarily when I initial a VMSS including basic LB then scale it out quickly on the Azure portal. After I waited for more time to get all VM instance running, the error did not happen. But today, I could not reproduce it, It looks like some temporarily provisioning error on Azure. – Nancy Sep 10 '19 at 09:20