Azure app service scale out and changes in application gateway - azure

I am using azure application gateway and azure app service. I have enabled scale out in app service. I have added app service private ip address to application gateway, Will it changes during scale out ? Will it created another app service or the service itself handle the load balancing?

A scale-out operation is comparable to making several copies of your website and adding load balancing to divide the load among them. There is no need to configure load balancing separately when scale out appear in Azure app since this is already provided by the platform
In azure app service scale out as increasing number of instances, the more number of instances the application will able to process the user request very smoothly and you need to worry about the load balancing azure will take care of load distributing among the instances
when number of scaled-out instances actions in single ip address if the last app in a resource group and region combination has been altered, deleted, the deployment unit is recreated it may change.
For your Reference :
How IP addresses work in App Service

Related

How does Azure Service Plan load-balance traffic with different apps

I am trying to understand better how Azure App Service Plan (ASP) load-balances the traffic when multiple/different App Services are deployed in it.
Let's assume my ASP is made of 2 nodes (VMs or instances) and I deploy 2 apps (total 4 app instances running) and with following URL:
https://app1.azurewebsites.net
https://app2.azurewebsites.net
I know that there are ASP front-ends acting as load balancers. So here if I understand correctly it is like when I have a web-server hosting different web-sites and address distinction is based on virtual hostnames (which are the URL above). Right?
App Service is a multitenant service, so it uses the host header in the request to route the request to the correct endpoint. The default domain name of App Services, *.azurewebsites.net (say, contoso.azurewebsites.net), is different from the application gateway's domain name (say, contoso.com). ref.1
When using App Service, you can scale your apps by scaling the App Service plan they run on. When multiple apps are run in the same App Service plan, each scaled-out instance runs all the apps in the plan.
Apps are allocated to available App Service plan using a best effort approach for an even distribution across instances. While an even distribution is not guaranteed, the platform will make sure that two instances of the same app will not be hosted on the same App Service plan instance.
The platform does not rely on metrics to decide on worker allocation. Applications are rebalanced only when instances are added or removed from the App Service plan.
You can also now do Per-app scaling, which can be enabled at the App Service plan level to allow for scaling an app independently from the App Service plan that hosts it. This way, an App Service plan can be scaled to 10 instances, but an app can be set to use only five. ref.2

Geo-distributed Azure App's vs One-region

I'm using Azure App Service to setup my website. I have 2 Azure App Service instances and 2 Azure SQL.
1 App Service instance is in the Central US and 1 App Service instance Central India. 1 SQL instance is in the Central US and the other is in Central India.
I use Traffic Manager to route traffic to either region.
What confuses me is that, when I access the Indian server directly the page seems to load at pretty much the same speed as the server in the US.
And both seem to load relatively quickly. Around 250-350ms each to load a page with no styling that performs one database query.
Does this mean that deploying in multiple regions is overkill? Would I be better deploying a larger instance in a single region?
A multi-region architecture can provide higher availability than deploying to a single region.
If a regional outage affects the primary region, you can use Traffic Manager to fail over to the secondary region.
This architecture can also help if an individual subsystem of the application fails.
Also, when you configure you Traffic Manager, create a health probe endpoint that reports the overall health of the application and use this endpoint for the health probe.
The endpoint should check critical dependencies such as the App Service apps, storage queue, and SQL Database.
Otherwise, the probe might report a healthy endpoint when critical parts of the application are actually failing.
For more details, you could refer to this article.

can we use load balancer on a two app services in azure

I am creating a network with 2 app services, containing 2 slots each
I know the load balancers are designed to work with VM's, but I am wondering if it is possible to place a load balencer on these 2 app services to balance the load between them, Is it possible to do so??
When you Scale your Web App you add instances of your current pricing tier and Azure deploys your Web App package to each of them.
There's a Load Balancer over all your instances, so, traffic is automatically load balanced between them. You shouldn't need a Virtual Machine for this and you don't need to configure any extra Traffic Manager.
You may want to refer: scale your app in Azure App Service for more details.
but I am wondering if it is possible to place a load balencer on
these 2 app services to balance the load between them, Is it possible
to do so??
According to your description, maybe you are looking for Azure application gateway(layer 7).
Azure application gateway works at the application layer (Layer 7 in the OSI network reference stack). It acts as a reverse-proxy service, terminating the client connection and forwarding requests to back-end endpoints.
Azure application gateway support HTTP, HTTPS and Websockets.
Here is the features offered by each service:
More information about Application gateway, please refer to this article.
Maybe little late but I guess this what you are looking at
Scale Out- A scale out operation is the equivalent of creating multiple copies of your web site and adding a load balancer to distribute the demand between them. When you scale out a web site in Windows Azure Web Sites there is no need to configure load balancing separately since this is already provided by the platform.
https://azure.microsoft.com/en-us/blog/scaling-up-and-scaling-out-in-windows-azure-web-sites/

Azure Webapps not failover when instance fails

We deployed a Node.js Azure Web App and defined a minimum of 2 instances (for scalability and high-availability).
It seems like the LB is balancing the load between the instances, but it doesn't react on instance error (crash) and seems to insist balancing the load between all the instances including the one which crashed.
Is there a way to set a fail-over mechanism for high-availability?
The load balancer used by Azure App Service will continue to send requests to individual web servers as long as the underlying virtual machines are up and running.
To workaround the issue you are running into, you can try configuring the "auto-heal" feature. If the scenario is that the app gets "stuck" in a permanently broken state, auto-heal rules can be configured to automatically restart the app.
More details on auto-heal here:
Auto-heal for Azure Web Sites

how does a client know where a WCF endpoint is when it calls a windows azure WCF service

for ex you have:
2 instances of a worker role, 2 instances of a web role.
the worker role calls a WCF service on the web role. If I have only one web role, it knows it's addressand all is fine. But if I have 2 web roles, how do they accomplish load ballance, how does the worker role know which instance of the web role to call to?
Load balancing in general works by having a separate piece of hardware that acts as the designated target for the service that is being balanced. As each new request arrives it is then simply forwarded to one of the actual target machines that provide this service implementation.
In your particular case the load balancer will be the single public endpoint for your web roles. DNS lookups or direct IP addressing will result in requests arriving at the load balancer machine and not directly to any of the web roles. The balancer then forwards the request to one of the two web role instances that are known by the load balancer.
One of the advantages of this approach is that you can quickly start new web role instances if you anticipate a spike in traffic. All Azure needs to do is inform the load balancer those new instances are available and they will immediately start accepting new requests. Likewise you can scale back the number of instances. Because the load balancer itself is not being restarted it means your service is not disrupted.
You can find more detailed information at...
Cisco Definition
Wikipedia
DevCentral
Windows Azure load balances Web Roles automatically, you don't have to do anything.
If you need to address specific web role instances, I would suggest you reconsider your architecture, specifically look at using shared state via the SQL Server session state provider, or look at the appfabric cache provider in the training kit labs.

Resources