Existem dois aspectos para sua pergunta:
- Como você mantém dados / arquivos sincronizados em várias instâncias
- Como você cria novos nós que seguem as mesmas 'regras'?
Sincronização:
A instalação de um plug-in do Wordpress faz alterações nos arquivos e no banco de dados. Portanto, para imitar as alterações em todos os seus servidores, você precisará modificar os arquivos e bancos de dados de cada instância. A implementação específica dependerá do fato de todas as suas instâncias serem idênticas (ou seja, todas executam um servidor Web e um servidor de banco de dados) ou se você executar servidores da Web e servidores de banco de dados em instâncias diferentes.
Provavelmente, um bom argumento deve ser feito para executar uma instância com seu servidor da Web (e, em seguida, escalonar automaticamente essa instância) e outra instância com seu servidor de banco de dados (por exemplo, link ). É claro que, assim que você faz o balanceamento automático dos bancos de dados, você se depara com a questão de manter os dados consistentes em todas as instâncias.
Sincronizando arquivos: A solução mais simples para sincronizar os dados é usar o rsync. Você pode tê-lo executado periodicamente (via cron), ou pode acioná-lo usando o incron, o que permitirá que ele seja executado quando o conteúdo dos diretórios mudar. Outra opção lsyncd que usa o inotify para monitorar as alterações em um diretório e acionar o rsync.
Outra abordagem para a sincronização de arquivos é usar sistemas de arquivos de rede / distribuídos / em cluster. Por exemplo, você pode usar o Gluster para manter replicado (várias cópias) e / ou distribuído (espalhado).
Você provavelmente também desejará compartilhar suas sessões PHP entre seus nós.
Sincronizando bancos de dados: Indiscutivelmente, manter os arquivos em sincronia é a parte fácil. Manter os bancos de dados em sincronia é mais um desafio. Quando usado com um número variável de nós, a dificuldade aumenta.
- A solução mais simples é apenas ter seus bancos de dados em uma instância separada.
- A replicação é a solução comum - mas manter um nó mestre quando você não está certo de qual instância será finalizada é um problema. Se você estiver usando uma estrutura de configuração, poderá ter mais facilidade em controlar isso. Usar algo como "marcapasso" (do Linux-HA) também pode ajudar nessa frente. Ou apenas mantenha o nó mestre fora do grupo de escalonamento automático (mas isso tornaria um ponto único de falha).
- O cluster MySQL tem alguma promessa, mas não sei se o WordPress será executado no NDBCluster (também requer um nó de gerenciamento).
- Existem algumas afirmações de que o MySQL está sendo executado em um sistema de arquivos compartilhado (especificamente o Gluster) - pode funcionar, mas eu não acreditava muito nele.
Eu recomendaria usar uma instância separada do MySQL e um dos scripts baseados em rsync (provavelmente lsyncd) para manter os arquivos em sincronia. Autoscale seus servidores da Web e provavelmente levará algum tempo até que você precise se preocupar com o servidor de banco de dados. Se você fizer o escalonamento automático do banco de dados, mantenha o nó mestre fora do grupo e dimensione os escravos.
Implantação:
Nesta frente, você pode querer pequenas diferenças em cada nó (por exemplo, um mestre, um escravo, etc). Frameworks (como mencionado na resposta de voretaq7) seria o caminho a seguir. De muitas maneiras, quanto melhor sua implementação, menos necessidade você terá para o escalonamento automático. Uma configuração pode incluir o Corosync e o Pacemaker para monitorar o estado de cada nó e os serviços executados nele - para escolher um nó mestre e, em seguida, para executar um script para dimensionar seu cluster conforme necessário.