Ampliação de Unidades ou Pods

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.

Implementando uma Grade de Dados Única Grande

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:

  1. Questões de orçamento: Na realidade, seu ambiente não pode testar uma grade de dados de 1000 servidores. Entretanto, ele pode testar uma grade muito menor, por motivos de orçamento, de modo que não é necessário comprar duas vezes o hardware, principalmente para um número tão grande de servidores.
  2. Versões de aplicativo diferentes: Exibir um grande número de caixas para cada encadeamento de teste não é considerado prático. O risco é que você não esteja testando os mesmos fatores que estaria em um ambiente de produção.
  3. Perda de dados: A execução de um banco de dados em um único disco rígido não é confiável. Qualquer problema com o disco rígido faz você perder dados. A execução de um aplicativo em crescimento em uma grade de dados única é semelhante. Você provavelmente terá erros em seu ambiente e em seus aplicativos. Portanto, colocar todos os dados em um único sistema grande muitas vezes levará à perda de grandes quantidades de dados.

Dividindo a Grade de Dados

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.

Geralmente, uma pilha de aplicativos considera os níveis dos seguintes componentes.
  • Sistema Operacional
  • Hardware
  • JVM
  • WebSphere eXtreme Scale versão
  • Aplicativo
  • Outros componentes necessários

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.

Configurando um Ambiente Baseado em Pod

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.