As más notícias: A principal base de código-fonte aberto do Wordpress faz algumas suposições sobre a execução em um único servidor (conteúdo wp, upload de usuários e biblioteca de mídia, para citar alguns)
As boas notícias: praticamente todos os provedores de nuvem (incluindo o Azure) têm abstrações que permitem solucionar essas limitações de design.
Fundamentalmente, você abordará as seguintes preocupações:
- Balanceamento de carga de tráfego entre dois (ou mais) servidores web / de aplicativos Wordpress "front-end". Não é muito difícil, uma vez que o Wordpress é MAIS apátrida, a menos que você permita que os usuários acessem os 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 - um conjunto se conectará à sub-rede que pode ser roteada via Internet (embora esperemos que esteja protegida 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 é o seguinte:
/ - (10.0.0.1 - eth0) wp1.domínio.com (10.0.1.1 - eth2)
(IP público) wp.domínio.com
\ - (10.0.0.2 - eth1) wp2.domínio.com (10.0.1.2 - eth3)
Gerenciando sessões SE você estiver permitindo que os usuários acessem os sites. Nesse caso, será necessário garantir, quando eles fizerem login no servidor 1, que todas as suas solicitações futuras sejam roteadas para esse servidor (sessões permanentes) ou que não importa qual servidor eles acessam porque as sessões são gerenciadas por algum outro mecanismo (via clustering de sessões do Zend Server , por exemplo).
Gerenciamento de logins de administrador SE você estiver permitindo que alguns usuários acessem o back-end para gerenciar o 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 o travamento do banco de dados derrubar todo o sistema. Você precisará alavancar a replicação Master / Slave do MySQL via ClearDB ou modificar o WordPress via plug-in para alavancar o SQL Server para poder usar seus sistemas de cluster nativos . Isso significa que você precisará de pelo menos 4 VMs se quiser gerenciar a camada de banco de dados (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.domínio.com X |
\ - wp2.domain.com (10.0.1.2) / --- \ (10.0.1.4) db2.domain.com (10.0.2.3) /
NOTA - para garantir um failover confiável e proteger a segurança do sistema, geralmente é usada uma sub-rede de rede TERCEIRA para conectar os dois nós do banco de dados através de um canal privado separado das outras redes de comunicação com as quais os servidores de aplicativos usam para conversar. o banco de dados e os servidores de aplicativos usam para se comunicar com o mundo exterior.
Habilitando o Pool de conexões para maximizar o desempenho e a confiabilidade das conexões com o banco de dados do servidor de aplicativos.
Aproveitando um plug-in de 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 lidar com cada um dos desafios acima. Existem várias maneiras de lidar com cada uma delas no Azure; portanto, você decide como deseja atacar cada desafio e, em seguida, lida com as restrições que cada uma dessas opções impõe enquanto você trabalha para cima e para baixo na pilha.