I have an Nginx server installed at my RHEL7 GCE host configured as a caching reverse proxy server, distributing traffic to two non-GCE webservers. I'd like to replace Nginx with native GCE features, which seems to be the HTTP/S Load Balancing features. But the GCE load balancing seems designed to distribute traffic to only other GCE instances. And I don't know whether GCE can cache what it's reverse proxying.
My non-GCE webservers are across a VPN configured with the GCE host as an endpoint. The two webservers are actually listening at the same IP address but different ports. I'd like to access them by https://gce-host.com/this -> https://non-gce-host.com:80 and https://gce-host.com/that -> https://non-gce-host.com:81 .
I'd also like to consider the other Nginx features, like access control.
Is the native GCE featureset a reasonable replacement for the Nginx caching reverse proxy server? Or should I stick with Nginx?
HTTP(S) load balancing does not support non-GCE hosts nor ACLs at this point.
If you'd still like to benefit from the global footprint and caching of Google's HTTP(S) frontend infrastructure, you can of course use Cloud CDN in conjunction with a very lightweight, non-caching reverse proxy.
The benefit here would be that you get caching close to the user - as such, the nginx proxy on GCE does not have to perform caching itself, possibly reducing the necessary machine size as it would only be shuffling bits back and forth to your origin server and performing ACL checks.
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.
Given a local, multi-tenant dev environment (Win7 Ultimate) where host entries resolve to localhost and requests to multiple local hosts are made on :80 (etc), what's a sane way to proxy requests to either IIS (listening locally on an arbitrary static port) or another backend (i.e. a VBox VM listening on :80 on one of its own interfaces)? Basically, what's the simplest way to balance between different web servers on a FQDN/hostname basis from a common address?
As far as I can tell, ARR seems like it might be a little much config-wise, so I'm hoping to do something a la nginx/HAProxy/Pound/etc where proxying can be configured per the Host HTTP header.
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.
We usually blacklist IPs address with iptables. But in Amazon EC2, if a connection goes through the Elastic Load Balancer, the remote address will be replaced by the load balancer's address, rendering iptables useless. In the case for HTTP, apparently the only way to find out the real remote address is to look at the HTTP header HTTP_X_FORWARDED_FOR. To me, blocking IPs at the web application level is not an effective way.
What is the best practice to defend against DoS attack in this scenario?
In this article, someone suggested that we can replace Elastic Load Balancer with HAProxy. However, there are certain disadvantages in doing this, and I'm trying to see if there is any better alternatives.
I think you have described all the current options. You may want to chime in on some of the AWS forum threads to vote for a solution - the Amazon engineers and management are open to suggestions for ELB improvements.
If you deploy your ELB and instances using VPC instead of EC2-classic, you can use Security Groups and Network ACLs to restrict access to the ELB.
http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/USVPC_ApplySG.html
It's common to run an application server behind a reverse proxy. Your reverse proxy is layer you can use to add DoS protection before traffic gets to your application server. For Nginx, you can look at the rate limiting module as something that could help.
You could set up an EC2 host and run haproxy there by yourself (that's what Amazon is using anyways!). Then you can apply your iptables-filters on that system.
Here's a tool I made for those looking to use Fail2Ban on aws with apache, ELB, and ACL: https://github.com/anthonymartin/aws-acl-fail2ban