our app is hosted in Azure VM scale set and it has 80 and 8080 endpoints,
80 must be public and 8080 must be private.
Obvious way to achieve this is to use one public and one private load balancer.
Is it possible in Azure VM scale set?
According to this it is.
https://heranonazure.wordpress.com/2017/08/30/vmss-behind-both-internal-and-external-load-balancer/
However, I have attached my VMSS to 2 load balancers, 1 internal and 1 external. It does work just fine, but you do get a warning saying that 1 backend address pool has been removed....however I can still access resources via both load balancers. Whether this persists after any maintenance or scaling of the VMSS remains to be seen.
I would say on the Basic SKU LoadBalancer it is NOT supported even though you can get it to work to some degree.
The Standard load balancer may well be different, however that is still in preview.
Related
We are moving a workflow of our business to Azure. I currently have two VMs as an HA pair behind an internal load balancer in the North Central US Region as my production environment. I have mirrored this architecture in the South Central US Region for disaster recovery purposes. A vendor recommended I place an Azure Traffic Manager in front of the ILBs for automatic failover, but it appears that I cannot spec ILBs as endpoints for ATM. (For clarity, all connections to these ILBs are through VPNs.)
Our current plan is to put the IPs for both ILBs in a custom-built appliance placed on-prem, and the failover would happen on that appliance. However, it would greatly simplify things if we could present a single IP to that appliance, and let the failover happen in Azure instead.
Is there an Azure product or service, or perhaps more appropriate architecture that would allow for a single IP to be presented to the customer, but allow for automatic failover across regions?
It seems that you could configure an application gateway with an internal load balancer (ILB) endpoint. In this case, you will have a private frontend IP configuration for an Application Gateway. The APPGW will be deployed in a dedicated subnet, it will exist on the same VNet with your internal backend VMs. Please note in this case you can directly add the private VMs as the backends instead of internal load balancer frontend IP address because of private APPGW itself is an internal load balancer.
Moreover, APPGW also could configure a public frontend IP configuration, if so, you can configure the APPGW public frontend IP as the endpoints of the Azure traffic manager.
Hope this could help you.
I want to load-balance my VM scale set in a VNet. My requirements are that:
I do not want public IP accessibility and
I do need https health probes.
While both Azure load balancers (in either basic or standard sku) seem to be capable of balancing also internal traffic, only the standard sku offers https health probes.
When trying to add the VM scale set to the backend pool, I cannot select it, it's not found by the wizard. Both scale set and internal standard sku load balancer are within the same region, VNet, and resource group.
It appears I'm having the same issue as someone here, only with a scale set instead of an availability set.
There is a tooltip stating
Only VMs in region with standard SKU public or no public IP can be
attached to this loadbalancer. A backend pool can only contain
resources from one virtual network. Create a new backend pool to add
resources from a different virtual network.
So I am confused, my internal load balancer is using only private addresses, so the criterion of "with standard SKU public or no public IP" should be met. Also I note, that the tooltip does only explicitly state VMs, not VM scale set. However, I refuse to believe that the standard sku of LB should lacking features compared to the basic sku (I do have it working with a scale set and internal basic LB, albeit without https health probes).
Am I missing something here? I do realise that there's still the "Azure Application Gateway", however I think it's overly complex to set-up and overkill for my scenario. I only want internal load balancing of a scale set with https health probes. And I am starting to think that this is not possible.
Kind regards, baouss
It seems a restriction that you could not select the scale set as the backend for a standard SKU load balancer on the Azure portal. The document states that
One key aspect is the scope of the virtual network for the resource.
While Basic Load Balancer exists within the scope of an availability
set, a Standard Load Balancer is fully integrated with the scope of a
virtual network and all virtual network concepts apply.
So we only could select the eligible VMs in the virtual network as the backend pool for a Standard Load Balancer.
Wait for confirmation from Azure team: VM scale set does not work with internal standard SKU Azure load balancer backend pool
As you mentioned, currently, you could use Application Gateway with health probe Https. If not, you may create a VM scale set and choose a load balancing option--- load balancer. This will automatically associate a public standard SKU load balancer for your scale set.
Say I deploy an API, the database etc. to a t2.micro EC2 instance to serve traffic for the period of prototyping and beta testing. Let's say the domain pointing to the API is api.exampleapp.com.
Now traffic begins to grow beyond the instance's limits and we deploy the API to a bunch of instances that we want to stand behind a load balancer. After setting the fleet up, how do we make api.exampleapp.com point now to the load balancer's IP address so that traffic is served by the newly launched instances without any downtime? Is this possible at all? Or with minimal downtime? Or is this approach of starting up with a new API itself faulty?
I assume you either don't need auto-scaling or have it already configured.
start the LB and attach your first EC2 to it. The instance still work, can be directly accessible via its IP (thus, accessible from the World).
check the LB hostname, try to access the instance using LB, make sure it works
switch DNS to the LB using either CNAME or ALIAS record type (if ALIAS is supported by your DNS server)
add another instances to the LB.
Done!
Let's say I have 20 servers at Amazon AWS and I also have AWS ELB setup for these servers. I heard that HAProxy is reliable and fast TCP/HTTP Load Balancer, so question is:
do I need to have HAProxy installed in each EC2 instances while I have AWS ELB?
What is the benefit of having both ELB and Haproxy at the same time?
Thanks
There are a few scenarios where people chose their own load balancing solution like HAProxy than ELB:
Financial transactions: ELB is an opaque service. Logs are not provided. So if you are missing transactions, you won't know if ELB dropped them or not.
Doesn't work well with traffic spikes: ELBs scaling takes at least 5 minutes. If your application traffic is doubling every 5-10 minutes, it will do well. But if it is at a constant rate and you will get a spike all of a sudden, then you will have problems with ELB.
ELBs can be slower than running your own Loadbalancing: In my environment, I got 15% performance boost by using HAProxy/Nginx (for SSL termination) instead. It was roughly 30ms per call, but keep in mind I was using SSL so I use CPU power.
ELBs only do round-robin load balancing and HAProxy has a lot more.
HAProxy also has ton more configurations that ELB does not support. It depends if one needs them for their application.
In one suite of applications, I have both running. ELB->haproxy->A suite of apps. In my case the following occurs:
ELB translates HTTPS to http
HAproxy targets to the app servers based on path
The app servers run in plain old http
The upside to this is that I can move around the apps without changing their URLs
The downside is that ELB isn't a fixed IP address so if you need to point to it from an IP adress instead of a cname you can't do it.
Short answer: No you don't need HAProxy. Go with an ELB.
tldr;
Yes HAProxy is powerful and tested.
First of all, you would need to have a separate EC2 HAProxy instance (as opposed to having HAProxy installed on every EC2 instance you need to balance). In essence an ELB is equivalent to an EC2 instance loaded with some kind of load balancing software.
Second, having both ELBs and HAProxy balancing instances in your environment is a rare use case. You might come to a point that you need more fine grained access and the ability to configure more on your load balancers. It purely depends on what you're doing and what problems an ELB might be giving you. Google to read through possible use cases.
I'm using an ELB and Haproxy behind.
When a customer uses my webservices from a unique IP, ELB redirects all his requests to the same hosts. It doesn't scale. (I supposed it's a hash from the src ip or something like that).
The haproxy has another balancer algorithm.
I keep the ELB for HA (1 haproxy / availability zone). And each haproxy instance redispatchs to region zone backend servers
We have two webservers running with nginx + php5-fpm configuration (native php sessions on a memdisk)
The webservers are using different subdomains and load-balancing is somehow satisfied.
Now we want to use the same domain address for these servers and even newer ones with the exact same configuration.
Installing an nginx in front of these web servers does not sound as a good idea since there are many file uploads to these web servers and the datatraffic passing through the loadbalancer for each upload would cause unnecessary traffic. Round robin DNS solution needs sessions shared in memcache, redis or db. This is also what we do not like because we keep too much data in sessions and very fine with it in our memdisks on local.
Are there any other configurations that fit to our needs?
The data will need to go through some networking appliance or other. This can be an application loadbalancer like Nginx, a software network loadbalancer like LVS, a hardware loadbalancer or, if DNS roundrobin is used, you still need to route the traffic through a switch.
If you are not satisfied with the performance of Nginx, check out LVS or consider buying a hardware loadbalancer. We saw really good performance through LVS (Linux Virtual Server) at the webhosting company where I used to work, so there's still much you can do with software.
Do some research. Set up an Nginx or LVS loadbalancer and benchmark it. Imitate your usual traffic patterns and check how it performs.