Cada edição de Inovações dentro do alcance apresenta novas informações e discussões sobre tópicos relacionados a tecnologias emergentes, tanto do ponto de vista do desenvolvedor como do praticante, mais observações por trás dos bastidores dos produtos IBM® Os painéis do WebSphere® de ponta.

Dando sentido ao jargão

Uma coisa que temos muito no segmento de mercado de software corporativo é jargão. Impressionante por vezes, o jargão é necessário para expandir o vocabulário usado para descrever as soluções e ferramentas disponíveis para solucionar um conjunto de problemas de negócios cada vez mais crescente. Sem essa expansão, muitos desses conceitos não se desenvolveriam. Um conceito para o qual estamos tentando dar um significado muito específico é o uso do termo elástica para descrever uma solução corporativa.

É fácil cair na armadilha de usar a ideia de elasticidade para determinar um ponto sobre o objetivo configurado para uma determinada solução. Em sua forma mais simples, uma solução pode ser elástica simplesmente permitindo que mais recursos sejam incluídos ou removidos sem colocar o sistema off-line. Para poder criar um padrão mais alto e mais útil, gostaria de propor um objetivo mais ambicioso de uma definição específica.

Elasticidade em um sistema ou componente de um sistema (usarei software como um exemplo, já que trabalho com o IBM WebSphere eXtreme Scale todos os dias) sugere três graus de liberdade específicos:

• Ajuste de escala sem limitação razoável
• Tolerância a falhas e autorregeneração
• Simplicidade administrativa.

Agora, antes de rotular isso como jargão ou conceitos vazios, permita-me dar algum sentido a essas ideias.

Ajuste de escala sem limitação razoável

Não devemos esperar muita controvérsia com relação à ideia de um sistema elástico pode ter ajuste de escala para cima e para baixo sem um efeito significativo na disponibilidade do sistema durante essas operações. No entanto, acredito que também devemos esperar que o próprio sistema não posicione qualquer restrição real em um cenário de ajuste de escala para cima razoável. Com isso, quero dizer que a infraestrutura em si deve ter uma arquitetura que permita o crescimento continuado do sistema e disponibilize novos recursos com pouco ou nenhum gasto adicional. Isso sugere a possibilidade de ajuste de escala linear verdadeiro.

Abordamos o conceito de elasticidade no within WebSphere eXtreme Scale considerando os efeitos de grades extremamente grandes em cada aspecto o produto. Alguns exemplos podem ilustrar isso muito bem:

• Primeiro, a arquitetura da infraestrutura de associação de grade em si é dividida em componentes de problemas de escala menores solúveis e que podem ser contidos. Em vez de reunir milhares de servidores em um único grupo principal, o serviço de catálogo (um processo administrativo que trata da estrutura da grade) divide os membros em grupos de 20. Cada um desses grupos individuais executa então um algoritmo de visualização de associação que envolve pulsação, que tem um registro de controle comprovado e compartilha função com o IBM WebSphere Application Server. Um "líder" eleito desse grupo menor mantém o serviço de catálogo atualizado com relação ao status do grupo, que então precisa somente permanecer em contato com 1/20 do total de membros da grade.
• Outro exemplo é as interações dos clientes com a própria grade. Uma questão que surge frequentemente é o possível gargalo que um único processo administrativo fornece, como o serviço de catálogo. Os serviços de catálogo podem ser duplicados e armazenados em cluster, também, mas isso é simplesmente para redundância. A verdade é que um único serviço de catálogo pode realmente tratar das necessidades de um número praticamente ilimitado de clientes, pois esses clientes interagem com o serviço de catálogo somente uma vez para autoinicialização na grade. Nessa interação, o serviço de catálogo retorna informações sobre a grade, incluindo um mapa de roteamento completo que define o local de todas as partições da grade e o espaço chave associado para cada. Após isso, os clientes interagem diretamente com as partições e até mesmo mantêm essa tabela de roteamento atualizada por meio de interações do subcanal durante o processo de transação normal. O serviço de catálogo fia então livre para focar sua atenção em simplesmente gerenciar o balanço e a associação da grade à medida que recursos são incluídos e removidos.

Com abordagens como essas, fomos capazes de ajustar a escala de uma grade forma efetiva para um tamanho arbitrariamente grande. Nos laboratórios, obtivemos uma grade de 1.500 contêineres sem nenhuma diferença real no desempenho percebido. Após isso, nós simplesmente ficamos sem tempo para seguir adiante, mas não há nenhuma limitação específica ou razoável para esse ajuste de escala. Esse é um fator importante para considerar verdadeiramente uma solução como sendo elástica.

É importante saber que isso não sugere que CADA implementação de uma infraestrutura elástica fornecerá ao aplicativo em geral ajuste de escala linear à medida que recursos forem incluídos. Ainda há considerações referentes à lógica e aos negócios que estão sendo conduzidos nessa infraestrutura e se eles empregam ou não fundamentos escaláveis de processamento extremo de transações. Com relação a isso, o próprio aplicativo corporativo também deve ter características elásticas. Uma infraestrutura elástica deve, no entanto, fornecer a infraestrutura para atingir efetivamente esses objetivos.

Tolerância a falhas e autorregeneração

Se você for esperar que um implementador confie que sua solução tenha ajuste de escala indefinidamente, você deve tolerar também os eventos que ocorrem com maior probabilidade e frequência à medida que um sistema cresce, como a inclusão ou perda de nós devido a manutenção ou falha, falhas e mudanças de rede, etc. Com mais recursos vêm uma maior chance de falha e um sistema elástico deve ser capaz de superar essas falhas de maneira previsível e eficiente, ao mesmo tempo em que retorna novamente a um estado de tolerância a falhas, se possível.

Continuando com nosso exemplo de grade de dados do WebSphere eXtreme Scale, à medida que você aumenta para grades de centenas ou milhares de processos de contêineres, a perda ou manutenção de um desses processos é cada vez mais provável. Por meio de replicação -- que é uma competência principal do WebSphere eXtreme Scale e ofertas de grade de dados na memória semelhantes -- esses eventos podem ser tolerados. Não somente isso, mas como o posicionamento e a migração dos dados é completamente transparente atrás da "caixa preta" das APIs do cliente do WebSphere eXtreme Scale, uma nova réplica é criada automaticamente e a tolerância a falhas é novamente atingida.

Elasticidade precisa ter esse anexo conceitual para ser verdadeiramente útil à medida que as implementações crescem e tornam-se mais complexas.

Simplicidade administrativa

Necessidades especializadas referentes à administração e manutenção de um sistema podem ser sutis ao se considerar o significado de uma infraestrutura elástica. No entanto, semelhante ao requisito de tolerância a falhas à medida que os sistemas crescem e tornam-se mais complexos, você também deve considerar a capacidade do implementador em executar tarefas administrativas comuns.

O conceito chave aqui é que a configuração e a manutenção de cada nó devem ser idênticas ou muito minimamente diferentes. Você não deve esperar que o implementador forneça uma lista de todas as máquinas ou processos membros para o sistema operar. Deve haver algum nível de descoberta e gerenciamento automáticos baseados em um conjunto comum de artefatos de configuração.

No caso do WebSphere eXtreme Scale, a abordagem é bem direta. As informações de configuração focam a estrutura e as características da própria grade, não em quaisquer detalhes dos processos membros específicos. Por exemplo, você configura em quantas partições dividir os dados e como essas partições devem ser replicadas. Dadas essas informações, o WebSphere eXtreme Scale mapeia isso para os membros da grade disponíveis e aplica as políticas determinadas na configuração. O mesmo conjunto exato de artefatos de configuração é fornecido a cada membro da grade quando iniciado e os detalhes do local desse membro no mundo da grade é gerenciado e determinado automaticamente.

Essa filosofia é aplicada por todo o espectro de administração e manutenção, com cada interação projetada para separar os detalhes a grade física da estrutura lógica das construções da grade.

Podemos encontrar muitos outros exemplos disso, como o desacoplamento de posicionamento de réplica por meio do uso da abstração de zona ou a capacidade de atualizar o nível de código da grade real sem colocar a grade em si off-line. O conceito chave é que tarefas administrativas devem ter uma complexidade constante à medida que o sistema sofre ajuste de escala de expansão para fora ou, pelo menos, o mais constante possível. A partir disso, é possível ver como software elástico e hardware elástico (ou seja, implementações de virtualização e nuvem) podem, de forma apropriada, se combinar para fornecerem um novo nível de liberdade às soluções corporativas.

Voltar para parte superior

Em aprovação de jargão

É provavelmente seguro dizer que mesmo nossas tecnologias base mais disseminadas na computação começaram como algum tipo de jargão. Nós simplesmente precisamos lutar para definir o significado e o propósito útil ao incluir um novo conceito ou objetivo definido em nosso vocabulário. Dessa maneira, acredito que esteja claro que elasticidade em soluções corporativas pode ser um conceito de valor quando claramente definido e considerado para conclusões lógicas. Temos tentado de forma consistente relacionar significado concreto e útil quando falamos sobre o WebSphere eXtreme Scale como uma grade de dados elástica e lutaremos por continuar afazer isso à medida que aplicamos esses conceitos a outras soluções projetadas para criar infraestruturas verdadeiramente flexíveis.

Recursos

Aprender

• WebSphere eXtreme Scale product information
  
  
• WebSphere eXtreme Scale Information Center
  
  
• WebSphere no IBM developerWorks
  
  

Obter produtos e tecnologias

• IBM developerWorks Download de teste do WebSphere eXtreme Scale
  
  

Discutir

• WebSphere eXtreme Scale XTP Development Community
  
  

Sobre o autor

Robert Wisniewski é Engenheiro de Software que está se especializando em desempenho e escalabilidade. Ele trabalhou anteriormente no desempenho do WebSphere Applications Server por 7 anos focando todas as áreas do produto, de EJB/JPA a computação autônoma e design de referência. Seu cargo atual como Divulgador Técnico volta o foco dessa experiência sobre cenários de clientes e o aplicativo de estratégias XTP no mundo real.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Dando sentido ao jargão
• Em aprovação de jargão
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais