1

quick question about how high availability cluster works. If i were not mistaken, If I setup 3 high availability servers, all traffic will only be processed on single server right? then if the first server died then it goes to the second server? or do they have a load balancer to distributes the workload equally to all of the server?

1 Answer 1

0

Intro

You can set it up the way you want.

The HAProxy software can be used as the load balancer. You can also use ningx. I would suggest you don't use Apache to do load balancing. It's not well design for such. You can also get a preset load balancer from most clouds.

Load Balancers

One limit with a load balancer: if that piece of hardware fails, you may have a powerful set of systems behind, it will be useless.

So in most cases you want at least two load balancers if you want to make sure to always be available.

On my end, I'm creating a system called Snap! Websites which ultimately will load balance all its front ends automatically (i.e. the load balancer will be incorporated.) It's not yet implemented, but the idea is that requests arrive on any computer and if the computer is already overloaded, it will forward the request to another front end computer. The huge advantage here is that all the front ends have to die before you lose all services.

Backends

With a load balancer setup, the other computers, the ones actually running your services, can then be setup as backends. One advantage here is that you may be able to get better security (i.e. only port 80/443 open between front and backend).

Without any load balancers, the services run on the front end and that means all the ports opened on those front end will give hackers a chance to attack your system.

3 Computers, no Load Balancers, how does that even work?

Since your websites is going to have one URL, having 3 computers would not really help if your URL always returns the same IP address. To make this work, you need to setup your DNS to return those three addresses. It's simple, just enter the same address three times and change the IP.

Here is an example for 'www' with 6 servers:

www   60 IN A 10.0.0.1
www   60 IN A 10.0.0.2
www   60 IN A 10.0.0.3
www   60 IN A 10.0.0.4
www   60 IN A 10.0.0.5
www   60 IN A 10.0.0.6

This is going to use a cheap round robin mechanism. This means it is not going to check whether a server is very busy or not. It will just send the next IP whenever a computer requests the DNS.

An important fact about these IPs, I put 60 as the cache duration. This is heavier on the DNS, but that means the user has to get a new IP every minute. This ensures that the computers are rotated. Although in most cases a browser is likely to keep the same IP address for way more than 1 minute (from my experience). I think that's not the browser that decides, or it just caches the IP for the time you are using that one website. If you close the window they may do a new lookup. In any event, that is cheap and works well, but if you can have a load balancer, it's much better.

Bottlenecks

Also you want to watch out for bottlenecks.

If your application makes use of a MySQL or PostgreSQL database and you put 10 front end computers but only one database computer, that's going to be your bottleneck. Querying the database is going to be slow if you are servicing 1,000 requests on each 10 front end... that's 10,000 hits to one computer running the database and that's probably the slowest part in your entire app.

There are two main resolutions for data: use a system such as Cassandra or make your MySQL/PostgreSQL databases run on multiple machines (it's doable, I've not tried it yet but I work with a company that has PostgreSQL distributed.)

With a system such as Cassandra, all the data is distributed among all the computers used to run the database. With a system such as MySQL/PostgreSQL, they break down the data per table in general. So some tables may still be slow. That being said, in newer versions, they may have much better solutions. I'm a little behind on SQL parallelization.

There are other problems in a cluster that need to be thought carefully. For example, if you try to change some data from multiple computers, you probably need a lock. An SQL database has such, if you use a BEGIN + INSERT/UPDATE + COMMIT, you'll be good. Otherwise you're likely to mess your data up. A solution to avoid problems is to use a cluster lock (Zookeeper offers such). Your app. locks, then does the transaction, and finally unlocks. Then you'll enter the world of: what if the lock times out before the SQL transaction is applied. Fun fun fun...

1
  • wow! I set out to find copper but i found gold! thanks a lot man Sep 9, 2019 at 5:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.