Construindo arquiteturas de alta disponibilidade

Olá pessoal, tudo certo?

O que você chama de “Alta Disponibilidade”?

Esses dias estive envolvido nessa discussão e surgiram algumas dúvidas no time. Vou aproveitar esse post para compartilhar alguns tópicos do assunto.

Podemos começar a discussão fazendo uma definição sobre o termo “Disponibilidade”. Em TI, um sistema ou solução pode ser chamado de disponível quando está:

  • Presente e pronto para uso; acessível para usuários;
  • Qualificado e pronto para ser servido;
  • Disponíveis para consumo com garantias prévias de níveis de serviços oferecidos;

Uma definição do Wikipedia segue abaixo:

Ou seja, se precisamos garantir a disponibilidade para um determinado sistema, precisamos garantir a oferta de seus serviços em diferentes situações de operação (falhas, carga, desastres, etc), com níveis de qualidade pré-estabelecidos. As situações de operação mais conhecidas são:

  • Tolerância a falhas;
  • Suporte a picos de carga e alta demanda;
  • Recuperação de desastres;
  • Cenários de redundância de dados;
  • Cenários de redundância de aplicações e funcionalidades;

Veja, essas situações exigem uma combinação de requisitos de software e hardware. Podemos ainda usar métricas para determinar o nível de disponibilidade que precisamos, como:

image

Os níveis de disponibilidade exigidos para a aplicação devem estar alinhados aos requisitos do negócio. Ainda, maiores níveis de disponibilidade exigem maiores níveis de investimentos e definições de hardware, software e redes que suportam adequadamente os níveis exigidos.

Portanto, Alta Disponibilidade deve ser classificada de acordo com o cenário e nível de serviço que estamos considerando. Veja um exemplo de arquitetura clássica de alta disponibilidade para dois nós em cluster, com base de dados compartilhada:

imageby wikipedia.

A plataforma Windows Server 2008 R2, por exemplo, oferece uma série de recursos que apoiam a construção de soluções com alta disponibilidade, como:

  • Failover Clustering
  • Network Load Balancing
  • Windows Hardware Error Architecture (WHEA)
  • Dynamic Hardware Partitioning
  • Fault Tolerant Hardware
  • Scaling Up (até 256 processadores)
  • Shadow Copy
  • Windows Server Backup
  • Windows Recovery, etc.

Pensando na arquitetura de hardware e infraestrutura, diversos fornecedores oferecem soluções combinadas envolvendo SAN - Storage Area Network, SCSI - Small Computer System Interface, SATA - Serial AT Attachment e RAID - Redundant Array of Independent Drives, criando cenários que podem ser combinados para a construção de ambientes de alta disponibilidade, como vemos a seguir:

imageimageimage

Assim, vemos soluções para disponibilidade de dados, alta disponibilidade de aplicações, alta disponibilidade de interfaces Web, compartilhamento de dados na rede, balanceamento de serviços, espelhamento de ambientes, cluster de servidores de dados, de máquinas virtuais, etc.

Outro exemplo interessante é o uso de virtualização para cenários de alta disponibilidade, onde uma combinação de máquinas virtuais, com clusterização de servidores e gerenciamento ativo geram uma infraestrutura robusta, tratando situação de recuperação, falhas e balanceamento de carga que tornam as aplicações mais disponíveis e com provisionamento dinâmico para cenários de nuvens privadas.

Uma pergunta importante: qual é a real necessidade do negócio quanto a alta disponibilidade da aplicação?

Veja o exemplo a seguir, para uma infraestrutura de alta disponibilidade consolidando máquinas virtuais, balanceamento de carga, monitoração integrada e cluster de servidores sobre plataforma Microsoft, usando o iSCSI Software Target:

image

Whitepaper: How to Build a Hyper-V Cluster Using the Microsoft iSCSI Software Target v3.3
Ref.: https://www.aidanfinn.com/?p=11164

Microsoft iSCSI Software Target 3.3
Ref.: https://www.microsoft.com/download/en/details.aspx?id=19867

O exemplo acima é um laboratório simples de dois nós de máquinas virtuais, suportando aplicações com alta disponibilidade sobre o iSCSI Software Target 3.3 da Microsoft.

Finalmente, até esse ponto, não falamos sobre o impacto desse tipo de arquitetura sobre as aplicações. Para muitos cenários, é recomendado que se faça uma avaliação sobre o comportamento e a arquitetura de software presente nas aplicações envolvidas. Para alguns cenários, as aplicações irão precisar de ajustes importantes para que suportem o ambiente de alta disponibilidade criado. Exemplos de cuidados para aplicações são:

  • Monitoração com Microsoft System Center Suite, com gerenciamento de níveis de serviços e orquestração de atividades.
  • Hospedagem com Windows Server AppFabric/IIS, com hospedagem de serviços e workflows, com caching, monitoração integrada, persistência, etc.
  • Patterns de arquitetura de aplicações, como suporte ao balanceamento de carga, tratamento de exceções, instrumentação, orientação a serviços, etc.

Portanto, em sua próxima definição de arquitetura, avalie a necessidade de alta disponibilidade em sua solução final. Para completar o post, veja os artigos da seguinte edição da revista The Architecture Journal:

Journal 11 - The Architecture Journal
Ref.: https://msdn.microsoft.com/en-us/architecture/bb491107

Journal 24: The Different Paths to Virtualization
Ref.: https://msdn.microsoft.com/en-us/architecture/ff803567

Mass-Hosting High-Availability Architectures
Ref.: https://msdn.microsoft.com/en-us/library/bb491120.aspx

Espero que ajude!

Por enquanto é só! Até o próximo post :)

Waldemir.