Nossa aplicação PHP consiste em um único servidor web que receberá arquivos de clientes e executará uma análise intensiva da CPU neles. No momento, a análise de um único upload de usuário pode levar 3 segundos para concluir e levar 100% da CPU. Isso faz com que nossa capacidade de sistema seja de 1/3 solicitações por segundo.
A exigência da minha equipe é aumentar a capacidade sem muita reengenharia de código. Uma possível solução seria configurar um balanceador de carga na frente de vários servidores executando o mesmo aplicativo, conectando-se a um banco de dados comum. O problema é que a análise gera arquivos no disco.
Um balanceador de carga aumentaria a capacidade, mas os arquivos não estarão disponíveis entre os servidores para que as solicitações subsequentes do cliente possam falhar. Estamos hospedados na Rackspace, existe uma maneira de configurar algum tipo de armazenamento "comum" para todos os servidores, sem ter que reescrever nosso código de persistência de arquivos? O código atual depende de fopens simples, etc. Quais são as nossas opções?
GlusterFS fornecerá uma exportação completa do sistema de arquivos POSIX que pode ser montada como a maioria dos outros sistemas de arquivos locais. Ele será replicado para um grau configurado para redundância e, de outra forma, só extrairá dados sob solicitação. Desde que cada servidor esteja configurado de modo que os arquivos criados tenham caminhos exclusivos, mesmo em situações cegas, você deve estar em um bom local.
Por que você não monta o Cloud Files em cada servidor usando o CloudFuse?
Você pode usar os arquivos em nuvem como seu sistema de arquivos comum. Não é ideal para o trabalho pesado I.O mas por apenas dizer e ler, ocasionalmente, funciona bem, mais você pode então servir o arquivo de um CDN
Quais solicitações subseqüentes precisarão acessar o arquivo? Apenas o único usuário dentro dessa sessão de login, o mesmo usuário para sempre ou alguém? Se for uma das duas primeiras opções, o balanceador de carga poderá ajudar.
Eu acredito que a Rackspace ofereça um serviço de balanceamento de carga baseado em F5 BIG-IP . A persistência da sessão (envio de usuários de volta ao mesmo servidor para toda a sessão) deve ser uma opção no serviço de balanceamento de carga. Suponho que você esteja falando sobre o tráfego HTTP e, nesse caso, o balanceador de carga pode injetar um cookie na sessão e usá-lo para garantir que o cliente volte ao mesmo servidor em que reside o arquivo processado (um cookie de sessão ou um horário limitada).
Não sei se a Rackspace permite que os clientes usem o iRules da F5, mas, se o fizerem, você poderá até mesmo lidar com o terceiro caso fazendo com que o balanceador de carga determine qual servidor está hospedando o arquivo.
Se os arquivos nunca entrarem no banco de dados, então sim, você precisará de um único sistema de arquivos usado por todos os cabeçotes da web. Se os arquivos forem usados apenas durante a sessão do usuário (a sessão que carrega o arquivo), você poderá usar o stickyness de origem-ip ou de sessão no balanceador de carga para resolver o problema sem precisar de um único sistema de arquivos.
Todos os balanceadores de carga suportam vários métodos de aderência. O balanceador de carga F5 é ótimo, mas a rackspace também vende o brocado, que é muito menos $.
Se você precisar acessar um único sistema de arquivos, isso envolverá algum retrabalho, e há várias maneiras de resolvê-lo (por exemplo, um dos cabeçotes da web pode ser o sistema de arquivos ou o servidor db ou um novo sistema dedicado, ou um sistema de armazenamento em nuvem da rackspace, AWS ou outros).
hth!