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.
Related
I am really new to nginx API and I never done API configuration as well.
I configured Ngnix as a load balancer in which I need to set weight for my backend server. base on my CPU utilization I decided to set my weight.
The thing is I don't have any issue getting server utilization but I need patch my server weight to nginx via API
Help me how to configure API
Note: I am getting server utilization periodically. to nginx I have to change server weight dynamically. it has to happen atomically.
The ability to modify an Nginx configuration on the fly like this is, unfortunately, a feature that's only available in the commercial Nginx Plus variety. (E.g., this tutorial.)
As far as I'm aware, the only way to reconfigure the vanilla open source Nginx is to modify the configuration files and either do a reload or a reboot of the service.
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.
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 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
What is the preferred way of deploying a compojure/sinatra applications? I have multiple sites running on the host so i can't run jetty/mongrel on port 80. How should i handle multiple sites/applications running at the same host?
Use a web server such as Apache that runs on port 80 and use virtual hosts to direct the traffic to the right app server. So basically you would run each application server (jetty/mongrel, etc.) on a different port and then in each virtual host would have a different configuration to use something like mod proxy to forward the traffic to the app server. You could use a different web server such as lighttpd or nginx. For the sinatra app you could also look at Phusion Passenger, a.k.a mod rails, a.k.a mod rack, which theoretically works with any rack app, although I've only used it with Rails.
If you look into it some more you'll find that there are various schemes for forwarding traffic to the app server from a web server, but the basic mechanism for doing this kind of thing always boils down to having a web server that listens on port 80 that uses name-based virtual hosts to then forward the traffic to the appropriate app.
I've been doing this kind of thing with various standalone servers (e.g., AllegroServe) for years. I've found the best approach to be:
Run each server on a different, non-privileged port (such as 8080)
Run pound (or Nginx etc.) on 80, configured to map requests to each application.
Pound is great, and the configurations end up very simple (unlike Nginx). It will also do SSL fronting and HTTP sanitization for you, which takes the burden off your application.
Use passenger! http://modrails.com - it is a plugin for apache and nginx that lets you (very) easily run a ruby app as a virtual host