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.
- WordPress escalonável
- Como hospedar um WordPress escalável e otimizado para o Azure em minutos
- Implantar um aplicativo da Web do MVC de Ultra Alta Disponibilidade no Microsoft Azure - Parte 1
- Implantar um aplicativo da Web do MVC de Ultra Alta Disponibilidade no Microsoft Azure - Parte 2
- Nova oferta "escalável" do Wordpress no Azure
- WordPress de classe empresarial no Azure App Service
- Como executar o WordPress de grau empresarial sites nos sites do Azure