ti-enxame.com

Como executar o WordPress em duas VMs para alta disponibilidade

O Microsoft Azure exige que os aplicativos utilizem duas instâncias em vários datacenters para atingir sua "alta disponibilidade" SLA 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.

Isso é tudo muito bem, 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 poderiam 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.

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

11
Yaron

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:

  • Load Balancing tráfego entre dois (ou mais) "front-end" Wordpress web/servidores de aplicativos. 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) 
 (IP público) 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 acessem os sites. Em caso afirmativo, será necessário garantir que, quando eles fizerem 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 acessem, pois as sessões são gerenciadas por meio de outro mecanismo (via Zuster Server Session Clustering , por exemplo).

  • Gerenciando Logons de Admin Se você estiver permitindo 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 está altamente disponível. Não adianta ter dois servidores front-end se o seu banco de dados deixar o sistema inteiro para baixo. Você precisará alavancar a replicação MySQL Master/Slave via ClearDB ou modificar o WordPress via plugin para aproveitar o SQL Server para que você possa usar seus 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)/
 
  • NOTE- para garantir um failover confiável e proteger a segurança do sistema, uma sub-rede THIRD é geralmente usada para conectar os dois nós do banco de dados entre si por meio de um canal privado separado das outras redes de comunicação. que os servidores de aplicativos usam para conversar com o banco de dados e os servidores de aplicativos usam para se comunicar com o mundo externo.

  • 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, cabe a você decidir como deseja atacar cada desafio e lidar com as restrições que cada uma dessas escolhas impõe à medida que você sobe e desce a pilha.

10
Bryan 'BJ' Hoffpauir Jr.