Umbraco Azure Load Balancing Setup
s
Probably missing something obvious - I've been through the documentation https://docs.umbraco.com/umbraco-cms/v/10.latest-lts/fundamentals/setup/server-setup/load-balancing/azure-web-apps I've made the necessary changes to app settings, added a class to set the server role, configured my logs to go to an Azure table. I think I'm ready to release and setup on Azure and test load balancing. The missing piece of my knowledge is - do I need to put an Azure Load Balancer (public) in front of the two(+) web apps (one a scheduled publisher master, the other subscribers). From what I can see the Umbraco documentation just references the Azure docs here so I guess I follow best practice there? If anyone has any pointers they'd be greatly appreciated. As is usual with Azure, I am faced with lots of unfamiliar options (Routing preference MS network or Internet?). Regional or global etc etc?! Is there a handy guide anywhere to help me through these woods?
m
depends if you are wanting to use the scheduled publisher as a front end server too? If you don't then no need to balance the two servers.. just setup the subscriber to autoscale with min 2 instances say?
then it's just admin.domain.com for the publisher and domain.com for your autoscaling subscriber?
If you want more control over traffic loading, or redundancy across 2 app service plans/regions for explicit subscribers then (or maybe using the publisher as a lower traffic frontend) for that we've gone with azure front door.
but it's a but of a faff.. and you do have to go to two app serviceplans to get appservices on different clusters, if you are hosting more than one domain in umbraco, as you can't duplicate a custom domain across multiple appservices in the same app service plan (cluster)
another approach could also be to use deployment slots for your multiple subscribers.. but that seems to be using that mechanism out of scope.. and would require front door or az load balancer, and prob the same caveat for mulitple custom domains. Though I do like the idea of it keeping all your servers together under the production appsevice.. and you can control traffic loading to some extent, and actually hit a explicit subscriber box.. all things that I think you leave to MS when (auto)scaling out. 🤔
One other thing that loadbalancer/frontdoor bring more control over your healthy instances and taking out of rotation if unhealthy.. again I think that is just automated with (auto)scaling out
s
Definitely want the publisher to be handling traffic. Other wise it's an expensive cms node 🙂 So it looks like az load balancer is the way to go?
I really need to book myself on the course. However the next one is well too late to fix my immediate problem.
OK - I think the penny is dropping here. So it's very easy to leave the admin web app doing it's thing and have the subscribers autoscale to, say CPU useage. I was expecting to set up a load balancer but looking at the Azure autoscaling - it makes sense just to let the subscribers handle the traffic and auto scale. For my client (it's a charity) they have a busy month - then for the rest of the year I think we can fall back down to a single instance. The main problem I've had is Azure deciding to restart the web app so a few minutes of unavailability. I'm hoping this will remove that - load hasn't really been an issue. So for their critical period I'll add the LB subscribers - have 1-2 instances based on auto scale rules and see how we get on. Thanks for the pointers MIke - helped the mist clear. I'd disappeared down a rabbit hole of wanthing a LB in front of my web apps!
3 Views