O que é uma boa solução para várias instalações de software grandes?

4

Eu executei várias instâncias por máquina de um serviço de código fechado grande (~ 10GB) no linux. Existe uma solução para que, de alguma forma, os arquivos comuns entre as instalações não ocupem muito espaço? (quase todas as instalações são comuns a todas as instalações). Pensei em criar uma árvore de hardlink grande, mas cada instalação executa seu próprio atualizador automático, para que as coisas acabem inconsistentes.

    
por PerilousApricot 16.10.2011 / 22:38

3 respostas

1

Parece que você precisa de um sistema de arquivos com suporte à deduplicação.

Se não houver sistemas de arquivos nativos com suporte a dedup, você poderia considerar hospedar seus dados via NFS e colocá-los no ZFS, portanto, cada nova cópia não ocupará tanto espaço adicional.

    
por 17.10.2011 / 01:12
1

Isso depende quase inteiramente de como seu software é arquitetado. Supondo que você tenha acesso ao código-fonte e aos programadores por trás do programa, você poderia conversar com os desenvolvedores e ver se há uma maneira de compartilhar dados comuns. Mas se cada programa está usando seu próprio banco de dados ou algo assim, você está sem sorte.

Caso contrário, você poderia armazenar os dados em algum tipo de NAS ou SAN e manter as informações comuns em um local comum.

Se o programa não for feito para isso, eu definitivamente não arrisco isso. Você corromperá as coisas e criará mais problemas para você.

    
por 16.10.2011 / 23:28
0

Eu tenho um aplicativo que acho que pode ser semelhante.

Eu executo ~ 30 instâncias de um aplicativo específico, cada uma sendo executada em sua própria VM no vsphere. Cada servidor compartilha o mesmo arquivo vmdk para o armazenamento de dados do aplicativo (~ 12 GB) que é configurado como independente / não persistente (o que faz com que os dados sejam persistentes somente durante reinicializações e não em encerramentos). links simbólicos estão no local apontando o aplicativo para os arquivos de dados no volume não persistente. O estado da aplicação e os dados que precisamos ser persistentes são gravados em outro volume separado.

Quando uma atualização é lançada no conjunto de dados e assumindo que não podemos encerrar as VMs (ou não temos uma janela de manutenção), simplesmente enviamos a atualização para o armazenamento não persistente, pois as alterações não são persistentes e vm-specific (pelo menos até o próximo desligamento). E durante a próxima janela de mudança disponível, podemos finalmente atualizar o backing vmdk.

Nós fizemos isso ao vivo algumas vezes no dev com discos hot-removed / hot-add com a VM nunca indo para baixo, mas isso provavelmente não é algo que poderíamos fazer na produção.

Obviamente, isso só funciona se você tiver alguma forma de virtualizar seu aplicativo e alguma maneira de controlar como o seu aplicativo é atualizado.

    
por 18.10.2011 / 06:25

Tags