How to make a failover LAMP cluster for highly loaded WEB applications?

Question

linux

Username, how would you make a failover LAMP cluster for high-load WEB applications? Perhaps you will advise what to read, poke your nose, so to speak.

Answer 1

ruhighload.com
https://blog.selectel.ru/balansirovka-nagruzki-osn...

Answer 2

I wouldn't use AMP at all, from LAMP! Would use nginzx/redis/python/java/go/mongodb/elasticsearch/go/scala everywhere else.
And of course, it all depends on the hands!

Answer 3

First of all, change Apache to Nginx
If you can still squeeze some performance out of php and mysql, then a priori it won’t work out of apache
After you can already think about changing the database to postgresql/mongodb/rethinkdb/elasticsearch (depending on the data model)
Well, at the same time and the execution platform can be changed to a faster one.
The performance of 1 such server with direct hands will be on a par with a cluster of 10 LAMPs, if this is not enough, then the questions "how to make a cluster" will in theory not arise

Answer 4

how would you make a failover LAMP cluster for highly loaded WEB applications?

about performance
1) we write load tests
2) we run them and look for bottlenecks and think what to do with it
3) we eliminate the bottleneck
4) we repeat steps 2 and 3 until we get numbers acceptable for our application (well, then there is something that would satisfy our expectations in terms of loads, by the way, this should also be estimated in advance, taking into account the uneven distribution of users, etc.).
Regarding reliability:
looking for a single point of failure. well, that is, if we have a database, then it should be two in case one server fails. And there should also be a balancer on top that scatters requests. And in order to avoid the probability that the balancer will also fail - a balancer at the DNS level.
well, that is, you should not have something that will be a critical place in the system. Everything should be duplicated in case of a fall.

Answer 5

First level. DynDNS + a couple of Frontend servers + a couple of Backend servers.
If the main Front server fails, we redirect all traffic to the second one. In case of failure of one Backend, we redirect all traffic ...
Well, here you need to understand that these should be different physical servers and the frontend + backend bundle should not be in the same room, with a different bundle. In order to avoid the risk of flooding chtoli :)
There is a similar option, but with virtualization. During an accident on the main link, a container with a backup is automatically launched.
As you understand, everything should be automated, even switching ip addresses to DynDNS in this case, you do not have to break at 4 o'clock in the morning and understand the cause of the accident.