I'm looking into creating a HA Linux machine for my client's website. What are the main options I have, or a place/article where I can find out more?
I would LOVE if it was a single-image, too, so that existing software would just work.
Any help appreciated.
Thanks!
You have many options. Which ones you can use depend on how your website is coded.
Tightly Coupled, Single State
This web-site can only run one instance because of... reasons. Running two in parallel would be an extremely bad idea for some reason. It's pretty uncommon to be this kind of site.
CAP Theorem: Consistency over the whole system is paramount, not at all partition-tolerant, which makes availability the prime engineering goal.
Tightly Coupled, Single State Per Session
This web-site only runs right when users are interacting with the same website all the time. If they hit the wrong server, things can go wrong.
CAP Theorem: User-sessions need strict consistency, but the system doesn't need it. Somewhat partition tolerant since lost sessions during a failure is still a degradation of service, but the system as a whole will survive.
Loosely Coupled, State Doesn't Matter
The most scalable option, sites of this type keep session-state in the database tier if state is kept at all. Hit the wrong server, doesn't matter since the webserver just hits the database for state.
CAP Theorem: User-sessions are happy with loose consistency, partition tolerance is very high, which means availability is paramount.
Single-State is by far the hardest to make HA which is why sites are almost never coded for it. It requires one and only one database or file-set and one and only one webserver, with replication or volume-passing between the HA server members so another one can pick it up once the first server dies. The engineering is tricky enough it's usually easier to recode the site into a Single State Per Session application where the problem is a lot easier.
But if you have no choice, your single main option is clustering like heartbeat. Get a group of servers together, configure file and database replication, and set failover rules. Not easy.
Single System Image is not viable for websites as the difficulty in creating a both performant and available system is very high. SSI systems have a lot of engineering behind them to ensure a single IPC space and strict system-level consistency, which tends to make web-serving really, really slow. It is best used for systems that require that level of integration between physical nodes, and web-serving isn't such a system. Its partition tolerance is really, really bad which makes SSI a bad HA solution. It is not a short-cut to HA. You'll be better served with a cluster.
Single State Per Session is usually handled by creating multiple web-servers and fronting them with a load-balancer such as haproxy, AWS Elastic Load Balancer (elb), or a hardware system like F5 BigIP. They're configured with sticky-sessions where each user-session is fed to a single server. When one dies, the others take over; any user with a session on the down box gets restarted and that's life. Code your site so such session interruption doesn't corrupt things.
State Doesn't Matter is handled the same way as single-state-per-session, but the key difference is the lack of sticky-sessions. The load-balancers are configured to feed each request to any server in the pool, and the webservers feed state from the database on a request-by-request basis. When one server dies, no one notices.
