Como executar o WordPress em 2 VMs para alta disponibilidade

10

O Microsoft Azure exige que os aplicativos utilizem duas instâncias em vários datacenters para atingir o SLA de "alta disponibilidade" e garantir que seus sites não sejam interrompidos para manutenção de rotina. Eles até informam quais pares de data centers nunca farão manutenção ao mesmo tempo.

Tudo isso é bom, mas como você faria isso facilmente na prática para um aplicativo como o WordPress com um banco de dados MySQL na mesma VM? Eu não sou estranho para balanceamento de carga entre duas VMs, mas a configuração de replicação de banco de dados me escapa. Não queremos duas versões dos dados que podem ficar fora de sincronia. A replicação do MySQL parece requerer uma configuração mestre-escravo que não conseguiria sincronizar as mudanças no banco de dados mestre se um usuário acessasse a instância do escravo.

Estou apenas entendendo mal este conceito? Qualquer ajuda é muito apreciada!

    
por Yaron 13.07.2015 / 21:35

1 resposta

9

The Bad News: A principal base de código aberto do Wordpress faz algumas suposições sobre a execução em um único servidor (wp-content, uploads de usuários e biblioteca de mídia, para citar alguns)

A boa notícia: praticamente todos os provedores de nuvem (incluindo o Azure) têm abstrações que permitem contornar essas limitações de design.

Fundamentalmente, você estará abordando as seguintes preocupações:

  • Balanceamento de carga de tráfego entre dois (ou mais) servidores front-end Wordpress / app "front-end". Não é muito difícil, pois o Wordpress é MAIOR stateless, a menos que você esteja permitindo que os usuários façam login nos sites. Isso é feito por meio de uma combinação de DNS e balanceadores de carga. Você precisará de suporte para 2 IPs para seus servidores de aplicativos - 1 conjunto se conectará à sub-rede que pode ser roteada pela Internet (embora esperançosamente protegido por um firewall não descrito abaixo) e os outros dois estarão em uma sub-rede DIFERENTE isolada de a outra rede e contém as Instâncias do Servidor de Banco de Dados, mas o esquema básico é como:
                     /-- (10.0.0.1 - eth0) wp1.domain.com (10.0.1.1 - eth2)
(Public IP) wp.domain.com          
                     \-- (10.0.0.2 - eth1) wp2.domain.com (10.0.1.2 - eth3)
  • Gerenciando sessões SE você está permitindo que os usuários façam login nos sites. Em caso afirmativo, você precisará garantir que, ao fazer o login no servidor 1, todas as suas solicitações futuras sejam roteadas para esse servidor (sessões fixas) ou que não importa qual servidor elas acessam, pois as sessões são gerenciadas por meio de outro mecanismo (via Cluster de Sessão do Servidor Zend , por exemplo).

  • Gerenciando logins de administrador SE você permitir que alguns usuários efetuem login no back-end para gerenciar conteúdo (semelhante ao acima).

  • Escolhendo o sistema de banco de dados que também é altamente disponível. Não adianta ter dois servidores front-end se a falha do seu banco de dados derrubar todo o sistema. Você precisará alavancar a replicação Master / Slave do MySQL via ClearDB ou modifique o WordPress via plugin para aproveitar o SQL Server para que você possa usar seu sistemas de cluster nativos . Isso significa que você precisa de pelo menos 4 VMs se quiser gerenciar a camada de banco de dados por conta própria (2 x App e 2 x DB). Veja como isso pode parecer:


               /-- wp1.domain.com (10.0.1.1)\---/(10.0.1.3) db1.domain.com (10.0.2.3)\
         wp.domain.com                        X                                      |           
               \-- wp2.domain.com (10.0.1.2)/---\(10.0.1.4) db2.domain.com (10.0.2.3)/

  • OBSERVAÇÃO - para garantir um failover confiável & Para proteger a segurança do sistema, uma sub-rede de TERCEIRA rede é geralmente usada para conectar os dois nós do banco de dados entre si através de um canal privado separado das outras redes de comunicação que os servidores de aplicativos usam para conversar com o banco de dados & os servidores de aplicativos usam para se comunicar com o mundo exterior.

  • Ativando o pool de conexões para maximizar o desempenho e a confiabilidade das conexões com o banco de dados do seu servidor de aplicativos.

  • Aproveitando um plug-in de armazenamento em cache como o W3 Total Cache ou o Super Cache para minimizar a carga nos servidores front-end.

Os guias a seguir oferecem detalhes sobre como você pode abordar cada um dos desafios acima. Há várias maneiras de lidar com cada uma no Azure, portanto, você decide como deve atacar cada desafio e, em seguida, lida com as restrições que cada uma dessas opções impõe à medida que você sobe e desce a pilha.

por Bryan 'BJ' Hoffpauir Jr. 20.07.2015 / 20:23