I want to know if there's a way commonly used for prod environments where if I reach the 125 instances limit for SKU v2, I can keep scaling, or at least I can keep the performance. I tried looking at Azure docs but they don't seem to address this problem at all.
You could setup multiple App Gateways to expand your number of instances and load balance them using Azure Traffic Manger. A reference architecture shows multiple regions but Traffic Manager can be used for resources in the same region. I don't know your backend architecture so this may or may not work.
Related
I am having difficulty understanding Azure Availability sets, specifically, what exactly i need to to do ensure my app running on my vm is utilizing Availability sets to be more available.
Lets say i am creating an application that runs on a single VM and i want to make it more resistant to hardware failure.
Option 1:
I create an Availability Set with 2 fault domains and then create a VM on this Availability set.
Is that it?
If there is a hardware failure on the rack hosting my VM, does azure now take care of ensuring the VM stays up and running?
Option 2:
i have to have two servers Vm1 & Vm2, both in the availability set but one on fault domain 1, one on fault domain 2.
i have to then set up a cluster of sorts for my application. In this case the availability set is simply allowing me to be sure that the two servers in my cluster are not on the same hardware, but the plumbing to ensure the application can take advantage of two servers and is highly available is still down to me.
Is option 1 or option 2 the correct way in which Availability Sets work in relation to fault domains?
Appreciate any clarity that can be provided.
Azure deals with hardware failure in two ways, Availability Sets and Availability Zones. AS is all about making sure that your app does not go down even if hardware failure happens within a Data center aka Zone itself. AZs are all about making sure your app does not go down even if the whole data center aka Zone is down. More details here.
Now to understand best practices around availability take a look at the best practices, specifically for VMs can be found here.
A Single VM instance is defined as follows, reference:
"Single Instance" is defined as any single Microsoft Azure Virtual Machine that either is not deployed in an Availability Set or has only one instance deployed in an Availability Set.
So one VM in or not in an availability set does not make any difference, for this you need at least two VMs and which are in an AS using FDs and UDs so Azure will take care of this by making sure that both VMs are running on separate Hardware to avoid your app going down.
One VM in an Availability set is nearly as good as a VM with no Availability set.
If you are placing two or more VMs in an AS and those are identical then you can add a load balancer to distribute traffic.
You can also use AS without a Load balancer if you are not interested in traffic distribution. One scenario can be where you want to switch to a secondary VM only when primary is unavailable.
Also, do understand it is not required to have identical VMs in an AS.
Virtual machine scale set is a good option if you are looking for a high availability solution with VMs.
We have a standard 3 tier web application that need to be migrated into cloud (more of VM based lift and shift instead of cloud native at this point).
Wondering which factors should I consider to make a decision if Azure Scale Set or Azure Availability Set should be used for Web and Application tiers.
Probably answer to questions like:
Can availability set autoscale like Scale set?
Any overhead of using either option for a simple web application?
Will both need load balancer in front of them ?
Might help to take a decision.
Any suggestions please?
You can refer to the N-tier architecture on virtual machines. Each of tier consists of two or more VMs, placed in an availability set or VM scale set. The load balancer is used to distribute requests across the VMs in a tier. Each tier is also placed inside its own subnet, and add NSG rules to restrict access to each tier and route tables to individual tiers.
For your questions:
No, The main difference is that a Scale Set have Identical VMs which makes it easy to add or remove VMs from the set whereas an Availability Set does not require them to be identical. An availability set is spread across fault domains that shared a set of hardware components, which means when you have more than one VM in different fault domains in a set it reduces the chances of losing all your VMs in event of a hardware failure in the host or rack. A regional (non-zonal) scale set uses placement groups, which act as an implicit availability set with five fault domains and five update domains. Refer to this question.
It's recommended to use VM Scale Sets for autoscaling. VMSS can automatically create and integrate with the Azure load balancer or Application Gateway.
Yes, both need Azure LB in front of them.
Generally speaking, both scenarios do not offer any way to magically make this happen, so you are kinda forced to use webapps if you want minimum overhead.
yes it can, but you need to prestage vms
yeah, you need to configure vms and for vmss you need automation so that scaling can happen automatically
yes, both will need a load balancer (web apps - not).
But your app might not work with webapps, so you are kinda forced to use vms or vmsses
Here is my situation.
I have a project hosted on Google Cloud, more specifically GAE (NodeJS) and Firestore.
I have a queue stored on Firestore that it could be up to 30 - 40k entries.
Each entry is basically an object with which I'll have to make an api call to an external service.
That external service allows only 10 requests/s for one IP.
At the moment I take batches of 10 and make for each one an api call, but it's to slow.
I already tried to instantiate multiple instances of the GAE service, but I still hit the limitation ( the instances use the same ip ?! ).
Another option would be to move the making of the api call in a Cloud Function and hit it there, but I think that I would bet the same outcome as with the GAE instances.
So, what do you think ?
Many thanks!
In my opinion, the requests per second per IP limit is put in place to throttle the overall amount of incoming requests and gaming this rule may cause issue to that service. The best way to handle this situation is either to get a paid subscription or to discuss the issue directly with the service provider.
Regarding the App Engine instances and IP addresses the short answer is:
No, GAE instances don't have their own dynamic IPs.
For more reference you can confirm it in the FAQ for App Engine:
App Engine does not currently provide a way to map static IP addresses to an application. In order to optimize the network path between an end user and an App Engine application, end users on different ISPs or geographic locations might use different IP addresses to access the same App Engine application. DNS might return different IP addresses to access App Engine over time or from different network locations.
tcptraceroute to a google service shows one of these points:
lga34s14-in-f14.1e100.net
According to the description of Google Edge Network:
Our Edge Points of Presence (PoPs) are where we connect Google's network to the rest of the internet via peering. We are present on over 90 internet exchanges and at over 100 interconnection facilities around the world.
To sum it up: your application should exit the Google's network from the Edge Point closest to it's target it would make sense that it's always the same point with the same IP and from the amount of the services and the client applications GCP hosts you can expect a reverse proxy being used by Google.
Azure classic Cloud Services come with a built-in load balancer that allows a fast VIP swap from production to staging, and vice versa. What equivalent is provided by Azure Resource Manager? I can use DNS, but then I have the TTL delay.
I want the fast swap because my back-end servers are stateful and cannot process the same data in both staging and production without overwriting each other. In my current system, out-of-date connections (e.g. because of HTTP keep-alive) are rejected and a reload is forced, forcing fresh connections.
I guess I might be able to do it using Azure Application Gateway, but it is not listed as one of its features.
You can do VIP swap in ARM with 2 Azure load balancers by disassociating the public IPs, then reassigning them. It's not a fast deployment slot swap like you can do with cloud services however, as can take a minute to disassociate both IP addresses (you could speed this up by doing it in parallel), and based on your question you've already looked at this approach, but documenting it here as an option. There are some notes on this approach here: https://msftstack.wordpress.com/2017/02/24/vip-swap-blue-green-deployment-in-azure-resource-manager/
In Azure resource manager, there are three ways, Azure Load Balancer(layer 4), Application Gateway(layer 7) and Traffic Manager(DNS level). I think you can use Load Balancer in you scenario.
The following table helps understanding the difference between Load Balancer and Application Gateway:
I know that with the Premium tier, I could have up to 50 instances to put my web app on in Azure. If I needed to go beyond this, like 75 instances, what would be the most appropriate way to do this?
Maybe two different app service plans, different web app endpoints load balanced by Traffic Manager?
Thanks!
A Hosting Plan is simply a geographical collection of web servers. With in that hosting plan you can have 'x' number of servers (depending on the SKU)
The machines in a Hosting Plan will be split across fault and update domains. So that a server rack dying, or an upgrade rollout won't take out all of the servers in the hosting plan.
However what this doesn't protect you against is geographically scaled issues. If you have a hosting plan in West Europe and the West Europe region suffers an outage. At that point you could lose your entire deployment.
This is where them being a geographical collection of servers becomes an important characteristic. If you create a number of hosting plans in a number of regions, not only will you have local redundancy against fault and update outages but you will also gain redundancy against geographical outages.
Obviously if you need 500 servers, there is nothing stopping you creating 10 premium SKU hosting plans and deploying them all to the West Europe region and creating some sort of round robin DNS load balancing solution.
But the better solution is to share them across regions. Creating a hierarchy of traffic manager profiles to share the load amongst them. With the right automation you can have some regions coming on and off line as your load increases / decreases.
Personally, unless I have specifically required premium features (Biztalk etc) my preference has always been to simply deploy more service plans. It is far more cost effective.