Embora seja possível implementar uma grade de dados sobre milhares de Java virtual machines, pode-se considerar a divisão a grade de dados em unidades ou pods para aumentar a confiabilidade e facilidade de teste de sua configuração. Um pod é um grupo de servidores que está executando o mesmo conjunto de aplicativos.
Testes verificaram que o eXtreme Scale pode adicionar para mais de 1000 JVMs. Tais testes incentivam a construção de aplicativos para implementar grades de dados únicas em um grande número de caixas. Isso pode ser feito, porém não é recomendado por várias razões:
A divisão da grade de dados do aplicativo em pods (unidades) é uma opção mais confiável. Um pod é um grupo de servidores que executa uma pilha de aplicativos homogêneos. Os pods podem ser de qualquer tamanho, mas o ideal é que eles consistam em cerca de 20 servidores físicos. Em vez de ter 500 servidores físicos em uma grade de dados única, é possível ter 25 pods de 20 servidores físicos. Uma única versão de uma pilha de aplicativos deve ser executada em um determinado pod, mas diferentes pods podem ter suas próprias versões de uma pilha de aplicativos.
Um pod é uma unidade de implementação de tamanho conveniente para testes. Em vez de ter centenas de servidores para testes, é mais prático ter 20 servidores. Nesse caso, você ainda está testando a mesma configuração que teria em uma produção. A produção utiliza grades com um tamanho máximo de 20 servidores, constituindo um pod. É possível fazer testes de tensão de um único pod e determinar sua capacidade, número de usuários, quantidade de dados e rendimento da transação. Isso facilita o planejamento e segue o padrão de escala previsível a um custo previsível.
Em casos diferentes, o pod não precisa ter necessariamente 20 servidores. O propósito do tamanho do pod são os testes práticos. Um tamanho de pod deve ser pequeno o bastante para que se encontrar problemas na produção, a fração de transações afetadas seja tolerável.
Idealmente, qualquer erro causa impacto em um único pod. Um erro teria impacto em apenas quatro por cento das transações do aplicativo em vez de 100 por cento. Além disso, os upgrades são mais fáceis porque podem ser lançados por um pod por vez. Como resultado, se um upgrade para um pod criar problemas, o usuário poderá alternar esse pod de volta para o nível anterior. Os upgrades incluem quaisquer mudanças no aplicativo, na pilha de aplicativos ou nas atualizações do sistema. Enquanto possível, os upgrades só devem alterar um único elemento da pilha por vez para tornar o diagnóstico do problema mais preciso.
Para implementar um ambiente com pods, você precisa de uma camada de roteamento acima dos pods compatíveis com versões anteriores e posteriores, caso os pods sofram upgrades de software. Além disso, você deve criar um diretório que inclua informações sobre qual pod contém dados. É possível usar outra grade de dados do eXtreme Scale para isso com um banco de dados por trás dele (de preferência usando o cenário write-behind). Isso gera uma solução de duas camadas. A camada 1 é o diretório e é utilizado para localizar qual pod trata uma transação específica. A camada 2 é composta pelos próprios pods. Quando a camada 1 identifica um pod, a configuração roteia cada transação para o servidor correto no pod, que geralmente é o servidor contendo a partição para os dados utilizados pela transação. Opcionalmente, você também pode utilizar um cache local na camada 1 para diminuir o impacto associado à consulta do pod correto.
O uso dos pods é um pouco mais complexo do que ter uma grade de dados única, mas as melhorias operacionais, de teste e de confiabilidade tornam esse uso uma parte crucial dos testes de escalabilidade.