Você tem muitas opções. Quais deles você pode usar dependem de como seu site é codificado.
Estado único acoplado
Este site só pode executar uma instância por causa de ... razões. Correr dois em paralelo seria uma péssima ideia por algum motivo. É bastante incomum ser esse tipo de site.
Teorema do CAP : A consistência sobre todo o sistema é primordial, não é tolerante a particionamento, o que torna a disponibilidade o principal meta de engenharia.
Estado único por sessão, totalmente acoplado
Este site só funciona quando os usuários estão interagindo com o mesmo site o tempo todo. Se eles acertarem o servidor errado, as coisas podem dar errado.
Teorema do CAP: As sessões do usuário precisam de consistência estrita, mas o sistema não precisa disso. Um pouco tolerante a partições desde sessões perdidas durante uma falha ainda é uma degradação de serviço, mas o sistema como um todo sobreviverá.
Ligadamente acoplado, estado não importa
A opção mais escalável, os sites desse tipo mantêm o estado da sessão na camada do banco de dados, se o estado for mantido. Acertar o servidor errado, não importa, já que o servidor apenas atinge o estado do banco de dados.
Teorema do CAP: As sessões do usuário são felizes com consistência solta, a tolerância da partição é muito alta, o que significa que a disponibilidade é fundamental.
Single-state é de longe o mais difícil de fazer HA, e é por isso que os sites quase nunca são codificados para isso. Ele requer um e apenas um banco de dados ou conjunto de arquivos e um e apenas um servidor da Web, com replicação ou passagem de volume entre os membros do servidor HA para que outro possa pegá-lo assim que o primeiro servidor morrer. A engenharia é complicada o suficiente, geralmente é mais fácil para recodificar o site em um aplicativo Single State Per Session, onde o problema é muito mais fácil.
Mas, se você não tem escolha, sua única opção principal é agrupar como heartbeat . Obtenha um grupo de servidores juntos, configure a replicação de arquivos e bancos de dados e defina regras de failover. Não é fácil.
Imagem de Sistema Único não é viável para sites, pois a dificuldade em criar um sistema de desempenho e disponibilidade é muito alta. Os sistemas SSI têm muita engenharia por trás deles para garantir um único espaço IPC e uma consistência estrita no nível do sistema, o que tende a tornar a web realmente muito lenta. É melhor usado para sistemas que exigem esse nível de integração entre nós físicos, e o serviço da Web não é um sistema desse tipo. Sua tolerância à partição é muito, muito ruim, o que torna a SSI uma má solução de HA. Não é um atalho para o HA. Você será melhor servido com um cluster.
O Single State Per Session geralmente é tratado pela criação de vários servidores Web e pela sua frente com um balanceador de carga, como haproxy , AWS Balanceador de carga elástico ( elb ), ou um sistema de hardware como o F5 BigIP. Eles estão configurados com sessões aderentes , onde cada usuário sessão é alimentada para um único servidor. Quando alguém morre, os outros assumem; qualquer usuário com uma sessão na caixa é reiniciado e isso é vida. Codifique seu site para que a interrupção da sessão não corrompa as coisas.
O estado não importa é tratado da mesma forma que o estado único por sessão, mas a principal diferença é a falta de sessões persistentes. Os balanceadores de carga são configurados para alimentar cada solicitação para qualquer servidor no pool, e os servidores da Web alimentam o estado do banco de dados com base em solicitação por solicitação. Quando um servidor morre, ninguém percebe.