I tried to dig on MSDN but could not get concrete statement for which is the best load balancing method.
could someone please share some light on which of the below are best option for given scenario:
Performance
Failover
Round Robin.
Scenario:
x Web Roleshosted on Large VM on single data center.
Requirement:
must be 100% up 24x7.
Thank you.
First: Do you really want to offer a 100% uptime SLA for your customers, when Azure itself doesn't offer 100% in its SLA's?
That said: Traffic Manager only load-balances your compute, not your storage. So if you're trying to increase uptime by having a set of backup compute nodes running in another data center, you need to think about data access speed and cost:
With round robin, you'll now have distributed traffic across multiple data centers, guaranteed, and constantly. And if your data is in a single data center (which is a good idea to have data in a single System of Record, unless you have replication logic all taken care of), some of your users are going to see increased latency as the nodes separated from your data are going to be requesting data across many miles (potentially between continents). Plus, data egress has a $$$ cost to it.
With performance, your users are directed toward the data center which offers them the lowest latency. Again, this now means traffic across multiple data centers, with the same issues as round robin.
With failover, you now have all traffic going to one data center, with another designated as your failover data center (so it's for High Availability). In the event you have an outage in the primary data center, you'd now have a failover data center to rely on. This may help justify the added latency and cost, as you'd only experience this latency+cost when your primary app location becomes unavailable for some reason.
So: If you're going for the high availability route, to help approach the 100% availability mark, I'm guessing you'd be best off with the failover model.
Traffic manager comes into picture only when your application is deployed across multiple cloud services within same data center or in different data centers. If your application is hosted in a single cloud service (with multiple instances of course) , then the instances are load balanced using Round Robin pattern. This is the default load balancing pattern and comes to you without any extra charge.
You can read more about traffic manager here: https://azure.microsoft.com/en-us/documentation/articles/traffic-manager-overview/
As per my guess there can not be comparison which is best load balancing method of Azure Traffic manager. All of them have unique advantages and vary depending on the requirement of application. Most common scenario is to use performance load balancing option with azure traffic manager. But as Gaurav said, you will have to have your cloud service application hosted on more than one cloud services. If you wish to implement performance load balancing then here is the link to get you started - http://sanganakauthority.blogspot.com/2014/06/performance-load-balancing-using-azure.html
Related
The Consumption Plan for Azure Functions is quite ideal, with its pleasant pricing and automatic scaling. However, I haven't found much information about High Availability with such a plan.
Let's consider a scenario. Imagine that, based on the load, there is currently one instance of the function app running. Then there is a problem in that data center. The consumption plan only scales out based on load. I can find no guarantees that a new instance will be added in this scenario, let alone that downtime will be prevented.
I'm aware that we could use Azure Front Door, with two separate function apps behind it. However, it appears that we must manage those function apps separately. That is a hassle. Swapping slots twice, remembering to change app settings in two places... That's no good.
What I'd like to achieve is something like Azure SQL in its Premium or Business-Critical tier, preferably with zone-redundant configuration. The diagram here shows how that works: https://learn.microsoft.com/en-us/azure/sql-database/sql-database-high-availability#zone-redundant-configuration
In simple terms, there is a primary replica with automatic failover to a secondary replica in the same data center, and also automatic failover to secondary replicas in two different data centers within the availability zone.
Notice how there is no manual management of the secondary replicas, since they are simply replicated from the primary.
How much of this can we achieve with Azure Functions, and how?
I'm a bit confused by Azure price calculator. In particular it doesn't explain the bandwidth pricing.
I'm considering Azure for a restful api that is going to use blobs for most data storage together with a sql server database for a subset that is easier to manage with a relational approach.
In this application a lot of data will enter the system through the ReST api, but a small fraction will be exposed to the clients (mainly as summary reports). Still the total bandwidth required should be in the order of 50 GiB/mo.
In the Azure's pricing page related to data transfer I see the pricing is only related to outgoing data, but I cannot figure how this relates to a ReST api that will be hosted in Azure App Service.
I mean, it could just mean that I'm going to pay for the bandwidth consumed by HTTPS responses (and not by HTTPS requests), but it seems a bit hard to estimate what this pricing is going to be.
Within a given region, there are no transfer costs at all. You mentioned using App Service, blobs, and SQL Database. As long as those services are within a single region, there are zero bandwidth costs as data flows between them and any other service within that region.
Bandwidth is billed specifically for outbound transfer. So, essentially you're metered for all data leaving a given region.
If you look at the page Data Transfers Pricing Details
Data Transfers refer to data moving in and out of Azure data centres other than those explicitly covered by the Content Delivery Network or ExpressRoute pricing.
Inbound data transfers
(i.e. data going into Azure data centres): Free
Outbound data transfer prices are set at a sliding scale depending on location and bandwidth used.
inbound traffic is free so the data coming in can be removed from the equation. Outbound is not free, and you saw the pricing page.
Data transfer is everything that is going out from every operation you execute.
And it is hard to estimate the traffic pricing - i would recommend to register the Azure trial and test it for a month and see how it is going. Because your data is not only what is returned, there is a lot of payloads coming with that.
But if you estimate 10 GB/month of outbound traffic, then it will start from $0.087 per GB starting from fifth GB (because first 5 are free). There are different regions described at the pricing page as well, so you should apply the pricing according to the region where your website is.
I'm seeing a definite non-round-robin load-balancing pattern in Azure's load balancer for my cloud role. Most of the requests are going to the 1st instance of the two-instance of my Web-Api worker role setup.
How can I ensure that Azure's LB distributes requests equally?
Note the first screenshot from CloudMonix's dashboard contains CPU Utilization for 1st instance (60-65% sustained average) and 2nd screenshot contains CPU utilization for 2nd instance (2-5% sustained average)
This is consistent across many different times I've looked into this.
Both of the instances are the same, only listen to many http requests and process them.
There actually is a way of configuring the loadBalancerDistribution for a Cloud Service in the .csdef file. The flaw is documentation updates :-(
Please look at this article: https://azure.microsoft.com/en-us/blog/azure-load-balancer-new-distribution-mode/
The value of LoadBalancerDistribution can be sourceIP for 2-tuple affinity, sourceIPProtocol for 3-tuple affinity or none (for no affinity. i.e. 5-tuple)
I'll look in to getting the schema article updated to reflect this.
As for the load distribution - if you have not specifically chosen the 2- or 3-tuple algorithm, you should be running with the 5-tuple.
You can use https://resources.azure.com to look at the current configuration.
I know that CPU is a reflection of load, but the load balancer balances based on network sessions, so please ensure that the CPU load and distribution of network sessions correlate. In your situation I would be surprised if they do not - just a reminder.
Please look at this article to ensure you are not running with keep-alives: Extremely uneven cloud service load-balancing with Azure
I've definitely had the same question in the past, but have noticed that over a sustained period (a few days or more) that the requests are balanced between the instances. From my personal research you cannot configure the load balancing on azure cloud services. Here is a document describing the service definition file, and I would imagine that if it was configurable, it would be in there.
However, you can configure the load balancer more explicitly using Azure Resource Manager.
We are in the process of moving our current IAAS solution over to azure where we host asp.net LOB web applications in IIS with an SQL Server backend.
I’m looking into availability sets. I stumbled upon this article at: http://michaelwasham.com/windows-azure-powershell-reference-guide/understanding_configuring_availability_sets_powershell/
This seems like how we want to setup our deployment on Azure where the “Web Servers” are our virtual machines. My question relates to how we setup our virtual machines. Currently we have about 200 separate hosted customers on our IAAS solution which means 200 separate web applications in IIS. With a highly available deployment should the Virtual machines be exact replica’s of each other i.e. 200 customers on box 1 and that again on box 2. Or should we spread them over multiple boxes i.e. 0-50 customers on box 1, 50-100 customers on box 2 and so on.
I cant see how the 2nd option spread would work in a highly available set because if 1 box goes down than all the customers on it go down with it?
Little confused, hoping someone has got advice on this?
Thanks
It would be best to duplicate everything, the azure load balancer (layer 4 balancer) ensures that load is spread across listening endpoints evenly and randomly, so you cannot know which server will answer a request, hence you must have the same configuration on both boxes. Here is some info on the Azure load balancer which you might find interesting, link
Also put them into an availability set so if one of the vm dies for some reason or during updates (which can happen from time to time with vms) you can be sure that at least one of your vms will always be online. You may need more than two vms, it really depends on the amount of traffic each of your clients generate and the load that that creates. But do have atleast two vms.
Just a side note if you haven't used Azure before; it may take you a bit of time to get the cost per vm right over time, but remember to use the schedule to scale up and down to reduce costs and anticipate load on your vms. Also having 4 smaller vms is better than 2 larger vms from a failure point of view and ultimately cost the same over a month. If one large vm dies, you've lost 50% of your capacity to serve your clients, where as if you lost one smaller vm you've only lost 25%.
I am working on a project whereby the web site (all components are hosted in Azure) will have both US and international users. We are using Blob and Table storage for 99% of the data. What I do not understand is how to setup global instances, including multiple tables, etc, and keep everything in sync. Say a user logs into the site from France, how can I ensure they will always hit the same data center (which implies the same Storage instance)? If they hit a different storage instance, their data will not be there and/or stale.
Both Compute and Storage are affinitized to a specific data center. There's no global compute or global storage deployment concept.
Having said that: You'll typically host your human-facing app (e.g. web app) in a single data center. Usually, latency between browser and server is not much of an issue if only a relatively-small quantity of data is moving between the two. The majority of bandwidth is typically between web server and app servers and/or database instances. And in Azure, data doesn't necessarily need to be colocated in the same data center as the web app (though it's the ideal scenario from latency + egress bandwidth cost perspective).
If you want Compute in multiple data centers, you'd need to have a higher-level mechanism doing some type of load balancing for you (such as Azure's Traffic Manager). However, even with Traffic Manager's "closest" setting, you're not really guaranteed that a user in France will hit the W. Europe vs. N. Europe data center. You'd always have to plan for a visitor hitting any data center. This is why it's much simpler to deal with Compute in a single data center.
Regarding data: If your Compute is in a single data center, there's no need (other than disaster recovery) to write data to multiple data centers. If you do decide to deploy Compute to multiple data centers, you'll need your own method for syncing data. For Azure blobs & table storage, you can consider some type of command pattern (e.g. CQRS) where your operations are queue driven. This allows you to process each queued data operation against multiple storage accounts across different data centers.
Now, you might have data sovereignty issues, where data must reside in a specific data center for specific customers, based on their geo. Again, you'll need to implement this in the app layer. One thought on this is to affinitize a user with a particular data center when they get set up (and just store the data center mapping in a single database along with your web tier). At this point, when a visitor logs in, you can easily look up their correct data center and, within their browsing session, access their data from the specific data center.