Conteúdo


Topologias de Alta Disponibilidade para IBM PureApplication System

Comments

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
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
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 para download


Temas relacionados


Comentários

Acesse ou registre-se para adicionar e acompanhar os comentários.

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