Topologias de Alta Disponibilidade para IBM PureApplication System

Uma pergunta frequente dos clientes sobre IBM® PureApplication System é "Como ele pode ser configurado para alta disponibilidade?". Este artigo oferece uma visão geral e recomendações sobre esse tópico.

Kyle Brown, Distinguished Engineer, IBM  

Kyle BrownKyle Brown é Distinguished Engineer em IBM Software Services for WebSphere e especialista em SOA e tecnologias emergentes. Kyle oferece serviços de consultoria, ensino e instrução para SOA, tópicos orientados a objeto e tecnologias J2EE para clientes Fortune 500. É coautor de Java Programming with IBM WebSphere e Persistence in the Enterprise. Também é palestrante em diversas conferências sobre SOA, Enterprise Java, design OO e padrões de design.


nível de autor Profissional do
        developerWorks

Andre Tost, Senior Technical Staff Member, IBM

Andre TostAndre Tost trabalha como Senior Technical Staff Member na organização IBM WebSphere, onde ajudou clientes da IBM a estabelecer arquiteturas orientadas a serviço nos últimos oito anos. No momento, sua prioridade especial são plataformas de computação em nuvem e sistemas de especialista integrados. Antes de sua designação atual, passou mais de dez anos em várias funções de consultoria, desenvolvimento e arquitetura na IBM. Trabalhou com grandes organizações de TI em todo o globo em SOA e BPM e foi arquiteto chefe de muitos grandes projetos de TI, especificamente em torno do padrão de barramento de serviço corporativo. Ele iniciou sua carreira na IBM como desenvolvedor de C++ e Java e ainda gosta de criar código.


nível de autor Master do
        developerWorks

Rohith Ashok, Senior Technical Staff Member, IBM

Photo: Rohith AshokRohith Ashok trabalha no IBM Software Group como Lead Architect de PureApplication System e da família de produtos PureSystems. Antes de focar em sistemas integrados, Rohith trabalhou no IBM Workload Deployer e WebSphere Cloudburst Appliance. Rohith trabalhou por dez anos em tudo desde zSeries a sistemas Power e sistemas altamente integrados. Nas horas de folga, Rohith gosta de estar com sua família e de assistir à tecnologia evoluindo na vida cotidiana.



20/Jul/2012

Introdução

Uma das perguntas mais frequente que ouvimos dos clientes sobre IBM PureApplication System é "Como ele pode ser configurado para alta disponibilidade?". Este artigo oferece uma breve introdução ao tópico com recomendações. Observe que não cobriremos questões relacionadas a disponibilidade contínua neste artigo. Essas questões são mais complexas e serão abordadas separadamente. Além disso, estamos considerando apenas casos de alta disponibilidade (HA) envolvendo sistemas virtuais criados em cima do WebSphere® Application Server (doravante chamado de Application Server) e DB2®. Os casos de HA para aplicativos virtuais (especialmente casos entre racks) e outras opções de middleware IBM, como WebSphere MQ e WebSphere Message Broker, serão discutidos em artigos futuros.

Observe que este é um artigo introdutório que descreve soluções de alto nível para os problemas descritos. Um conjunto de artigos futuros fornecerá exemplos detalhados para obter os níveis de disponibilidade descritos neste artigo.


Alta disponibilidade

Há dois mecanismos diferentes para alta disponibilidade que iremos considerar. O primeiro tipo são mecanismos dentro do rack, que são integrados no firmware e hardware do PureApplication System. O próprio ambiente de gerenciamento também é redundante dentro do rack, pois cada dispositivo PureApplication System contém dois nós de gerenciamento, sendo um backup do outro.

PureApplication System foi projetado cuidadosamente para não conter um ponto único de falha em cada um dos racks. Portanto, ao considerar um sistema virtual WebSphere e DB2 com mais de um membro de cluster WebSphere Application Server executando inteiramente dentro do rack, você está protegido contra falha por um único hardware (um nó de cálculo, uma unidade de disco rígido ou mesmo um interruptor top of rack [TOR]) devido à redundância integrada no rack. Caso um nó de cálculo falhe, o próprio plug-in WebSphere HTTP Server percebe isso devido ao desaparecimento da JVM que estava em execução nele, e todo o tráfego é redirecionado de forma contínua para outros membros do cluster.

PureApplication System percebe que o nó de cálculo está inativo e move a máquina virtual para outro nó de cálculo no mesmo grupo de nuvens, que será por fim integrado novamente ao cluster pelo plug-in e voltará a aceitar tráfego. Da mesma forma, caso haja um sistema DB2 HA/DR totalmente dentro do quadro e o banco de dados principal falhar, o sistema começa imediatamente a direcionar solicitações para o banco de dados de backup. Por fim, os algoritmos de colocação do PureApplication System são inteligentes o suficiente para que, na maioria dos casos, o programa tente ao máximo não colocar dois membros do cluster em um único nó de cálculo, se isso for permitido pela disponibilidade de recursos de cálculo e pela configuração do grupo de nuvens.

Esses mecanismos podem provavelmente cuidar de 90% das necessidades de failover. No entanto, embora isso seja muito, não é o suficiente para a definição de "HA" de alguns de nossos clientes. Eles estão pensando especificamente em mecanismos entre racks, ou seja, o que fazer em situações em que o rack inteiro é submetido a alguma falha catastrófica (por exemplo, quando um cano em uma porta resfriada a água quebra e joga água em todo o rack)? Também nesse caso é possível aproveitar os recursos padrão do WebSphere, DB2 e IBM Workload Deployer para fornecer esse nível de alta disponibilidade.

O que podemos fazer é usar primeiro padrões normatizados de DB2 HADR para configurar um banco de dados principal em um rack, com banco de dados de backup em outro rack. Isso permite lidar com solicitações do banco de dados mesmo em caso de falha do banco de dados principal, devido a uma falha de hardware dentro do rack (falha de um nó de cálculo) ou falha do rack inteiro (o exemplo do cano quebrado). Da mesma forma, é possível aproveitar os mecanismos tradicionais de HA no Application Server para fornecer dois mecanismos diferentes de failover. É possível criar instâncias do Application Server no "segundo" rack e federá-las para o Deployment Manager (DMgr) no "primeiro" rack, ou criar duas células separadas (uma por rack) e gerenciar a distribuição de carga (por exemplo, com um dispositivo externo DataPower usando os recursos de balanceamento de carga de Otimização de Aplicativos) entre as células fora do rack. Todos esses mecanismos exigem algum nível de intervenção manual do administrador do PureApplication System que está criando o sistema. O grau de intervenção manual necessária varia entre os componentes.

Há dois cenários diferentes a examinar:

  1. O primeiro é dentro do datacenter, quando estamos tentando fornecer HA em dois (ou talvez mais) racks do PureApplication System.
  2. O segundo é entre dois datacenters separados geograficamente.

Dentro do datacenter

No primeiro cenário, estamos protegendo contra a falha de todo um único PureApplication System. Dada a redundância de todos os componentes dentro do rack, esse evento é muito improvável. No entanto, há outros motivos pelos quais isso pode ser útil, como casos em que pode haver surtos de tráfego maiores do que um único rack pode suportar (mesmo um rack de alto desempenho). A Figura 1 mostra a configuração do sistema final que deve ser atingida.

Figura 1. Configuração de HA dentro de um DC com uma única célula compartilhada
Configuração de HA dentro de um DC com uma única célula compartilhada

Nesse cenário (chamado de modelo de "célula única"), começamos criando um padrão de sistema virtual que define uma célula que consiste em um DMgr, nós de IBM HTTP Server (IHS) e nós de WebSphere Application Server no primeiro rack (IPAS A na Figura 1). Em seguida, criamos um segundo padrão de sistema virtual no IPAS Rack B que contém apenas os nós de IHS e nós do WebSphere Application Server que são depois associados manualmente à célula criada anteriormente. Isso define que o limite da célula cruza ambas as máquinas, como mostra a Figura 1. Da mesma forma, criamos um padrão de sistema virtual para o nó HADR DB2 principal em IPAS A e um segundo padrão de sistema virtual para o nó HADR DB2 secundário em IPAS B. Observe que, para que isso aconteça, é necessário configurar um balanceador de carga externo para que ele esteja ciente de todas as instâncias de IHS nos dois racks. Também é necessário considerar o gerenciamento de sessão HTTP nos dois racks. O caso mais simples nessa abordagem é ativar a persistência de sessão do banco de dados para o banco de dados compartilhado.

Nessa configuração, você agora tolera uma falha completa em qualquer um dos racks. Caso o Rack A falhe, as instâncias do IHS e nós do WebSphere Application Server no Rack B continuam a aceitar solicitações do balanceador de carga externo e o HADR DB2 secundário assume no lugar do nó principal com falha. A única função perdida é a capacidade de implementar mudanças nos membros do cluster no Rack B, já que o DMgr não está mais disponível. Se o Rack B falhar, o Rack A continuará funcionando normalmente, aceitando solicitações do balanceador de carga externo como de costume.

Entre dois datacenters

Casos em que dois racks PureApplication System estão separados geograficamente são um pouco mais complicados. Nesse cenário (que chamaremos de modelo de "célula dupla"), é necessário criar ao menos duas células diferentes usando um banco de dados compartilhado, como mostra a Figura 2.

É possível usar replicação de sessão HTTP entre duas células por meio de banco de dados compartilhado, mas isso raramente é feito. Na maioria dos casos, a afinidade de sessão é configurada no balanceador de carga externo. Em outras palavras, solicitações para uma sessão iniciada em uma célula particular sempre serão encaminhadas a essa célula. Caso a perda de dados de sessão em caso de failover seja tolerável, é possível configurar um banco de dados local separado para persistência de sessão.

Figura 2. Duas células Ativa-Ativa do WebSphere
Duas células Ativa-Ativa do WebSphere

Observe a configuração da célula mostrada na Figura 2. Nesse cenário, criamos células individuais, porém idênticas, em cada PureApplication System. Como observado, os limites da célula estão contidos inteiramente em cada sistema. Dessa forma, as células do WebSphere são configuradas no modo Ativa-Ativa, mas o banco de dados HADR DB2 é configurado em um modo Ativo-Passivo, como no cenário anterior. A diferença aqui é que as células são independentes uma da outra. Não há comunicação entre os nós do WebSphere Application Server entre os racks.

Talvez a maneira mais fácil de implementar essa abordagem seja criar a primeira célula com um sistema virtual em IPAS A, exportar o padrão de sistema virtual e importar em IPAS B e, por fim, criar uma instância desse padrão em IPAS B. Da mesma forma, é necessário criar um HADR DB2 principal usando um padrão de sistema virtual em IPAS A e criar um secundário com outro padrão de sistema virtual em IPAS B, como no exemplo anterior. Nesse caso, o balanceador de carga externo está configurado novamente para enviar tráfego para o conjunto completo de instâncias do IHS em ambas as células. Caso um dos racks tenha uma falha completa, o outro continua recebendo tráfego sem interrupção.

O primeiro motivo pelo qual é melhor criar duas células nessa instância (em vez de unir todas as instâncias em uma única célula, como no exemplo anterior) é que, em geral, não é boa ideia deixar um membro do cluster separado geograficamente de seu DMgr. A comunicação necessária entre o DMgr e os membros do cluster (para gerenciamento, distribuição de código etc.) não é eficiente em uma rede de longa distância, portanto, não recomendamos a federação de células em longas distâncias como uma melhor prática.


Comparando os cenários

No cenário de célula única, todas as instâncias do servidor WebSphere são gerenciadas a partir de um único ponto central. Ou seja, há um único gerenciador de implementação e um único console de administração para aplicar alterações no ambiente nos dois racks. Além disso, configurações adicionais de balanceamento de carga e afinidade de servidor são disponibilizadas pelos plug-ins do IHS nos dois racks, garantindo que os recursos sejam usados eficientemente. Em essência, o fato de que dois racks estão sendo usados é transparente para a configuração do WebSphere.

No entanto, isso carrega o custo de uma configuração inicial mais complexa. Os nós no Rack B são configurados por um padrão separado, o que os conecta ao DMgr no Rack A. Todas as instâncias do IHS devem ser configuradas no balanceador de carga externo, e é necessário repetir essa etapa quando uma nova instância for criada e iniciada em um dos racks. Além disso, do ponto de vista dos sistemas virtuais, há dois sistemas distintos, um em cada rack, e todas as alterações necessárias devem ser aplicadas a ambos, preferencialmente ao mesmo tempo. Por fim, há uma camada de rede adicional (preferencialmente muito rápida) entre os racks, que aumenta o custo de, por exemplo, fazer chamadas para o banco de dados do segundo rack para o primeiro, ou passar solicitações entre nós do IHS em um rack e JVMs membros do cluster no outro, ou comunicação entre o DMgr e os agentes do nó individual no segundo rack. Mas, novamente, supondo que uma conexão de rede muito rápida tenha sido estabelecida entre os dois, esse gasto adicional é tolerável.

No cenário de célula dupla, a configuração é mais simples. De fato, esse cenário pode ser facilmente executado em um único datacenter. As células são gerenciadas separadamente, tanto da perspectiva do console de administração do WebSphere como da perspectiva de gerenciamento do PureApplication System. Por exemplo, isso significa que é possível aproveitar ao máximo mecanismos do PureApplication System, como roteamento e políticas de ajuste de escala, sem precisar considerar as implicações entre diferentes racks. Isso permite que o mesmo padrão seja implementado em cada rack, cada um usando endereços IP diferentes.

Ao mesmo tempo, há a desvantagem de que todas as alterações administrativas precisam ser feitas em duas células do WebSphere em dois consoles separados. É necessário configurar manualmente o balanceador de carga externo, assim como no primeiro cenário. E, em ambos os casos, há apenas um servidor de banco de dados ativo a qualquer momento, o que significa que ao menos alguns dos recursos no rack com o banco de dados secundário não são usados em condições operacionais normais.


Conclusão

Este artigo descreveu como é possível obter alta disponibilidade em aplicativos do WebSphere Application Server e DB2 em um ambiente dentro do datacenter através do uso de uma abordagem de célula única ou dupla, e como é possível conseguir o mesmo em um ambiente entre datacenters usando a abordagem de célula dupla.

Observe que configurações adicionais são possíveis, especialmente em casos em que há mais de dois racks. Por exemplo, é possível haver dois racks por datacenter, com uma célula definida em cada, o que eleva o total de células para quatro. Ou é possível definir mais de uma célula por rack. Além disso, pode haver números variáveis de clusters nas células.

No entanto, todos esses casos seguem as mesmas etapas e melhores práticas usadas em outros ambientes não relacionados ao PureApplication. Apenas incluímos considerações que se aplicam ao executar o PureApplication System, e, nesse contexto, os cenários descritos acima incluem essas configurações alternativas. Um cenário que não discutimos, propositadamente, é a execução de uma célula do WebSphere entre dois datacenters, pois essa prática não é encorajada.

Embora os exemplos discutidos sejam limitados a aplicativos do WebSphere Application Server e DB2, é possível extrapolar essas abordagens, de forma limitada, para outras configurações de produto. Discutiremos abordagens para outras soluções corporativas, como WebSphere MQ e WebSphere Message Broker, em artigos futuros.

Recursos

Aprender

Obter produtos e tecnologias

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=WebSphere, Cloud computing
ArticleID=826296
ArticleTitle=Topologias de Alta Disponibilidade para IBM PureApplication System
publish-date=07202012