O que é Alta Disponibilidade?

O conceito de Alta Disponibilidade surgiu devido a grande demanda de serviços de TI integrados ao negócio, quanto mais o serviço ou aplicação for necessária ao negócio e sua indisponibilidade impactar diretamente nos lucros da empresa, maior será a necessidade de ampliar a disponibilidade dos servidores, aplicações, etc.

A Alta Disponibilidade possui dois modelos de arquiteturas popularmente usados, sendo um deles o modo passivo/ativo. Usado quando se tem dois servidores, sendo um dos nodes o mestre o outro nó o escravo, quando o nó mestre fica indisponível o nó escravo assume o novo papel de mestre, ele é promovido a mestre. Conforme a imagem abaixo.

Tecnicamente este modelo de arquitetura consiste basicamente de três endereços IPs, sendo os dois utilizados nos dois nodes do cluster e o endereço VIP (Virtual IP), o VIP é o endereço de rede que deve ser disponibilizado para os usuários finais, pois quando o mestre ficar indisponível o escravo vai assumir o endereço VIP.

Por exemplo, imagine que um Analista esteja trabalhando durante o horário comercial, das 9hs as 18hs, e o departamento dele atua 24×7, o Analista que estiver escalonado como plantonista, passa ser o escravo (slave), caso o analista do horário comercial (master) estiver indisponível, o escravo é promovido a master e atuar nos chamados as quais o Analista do horário comercial não poder atuar.

O outro método popularmente utilizado é o modelo ativo/ativo, também conhecido como Load Balancing , onde o cluster possui diversos nodes, formando o que é conhecido como “pool”, nesse cluster todos os nodes são mestres, no entanto a carga é balanceada entre todos os nodes. Entenda que node em termos de alta disponibilidade refere-se a servidores. E cada requisição é direcionada a um nó diferente afim de aliviar a carga e distribui-la para que sua aplicação ou serviço tenha ganho de desempenho e produtividade, a grande vantagem do balanceamento de carga é o escalonamento horizontal do seu cluster, quando a aplicação crescer e a arquitetura sofrer demanda, basta adicionar novos nodes no cluster. Conforme o modelo abaixo:

Tecnicamente no Load Balancing os usuários finais da aplicação e/ou serviço não enxergam os servidores que se encontram no “Backend”, os nodes do cluster, apenas o servidor que faz o balanceamento, também conhecido como Balancer (Balanceador) ou Diretor. Inclusive o balanceador é um dos SPOF (Single Point of Failure) dessa arquitetura de alta disponibilidade, o SPOF significa que esse é o único ponto de falha, ou seja, se o balancer ficar indisponível, toda a arquitetura se torna indisponível impactando diretamente o usuário final. Nesse tipo de circunstância é possível aplicar o modelo passivo/ativo no balanceador, assim caso o balanceador mestre ficar indisponível, o balanceador escravo é promovido a mestre e a arquitetura permanece disponível e sem perda significativa para o usuário final. Porém como eu afirmei acima, é UM dos SPOFs, mas não o único, se observarem bem a arquitetura, notarão que o Banco de Dados esta isolado em outro servidor, por tanto se este ficar indisponível, toda arquitetura também falha. Sendo assim é necessário também aplicar algum modelo de alta disponibilidade. Porém se tratando de alta disponibilidade em Banco de Dados, o assunto é bastante delicado, já que se trata de dados, então a indisponibilidade do mestre e a virada do nó escravo para mestre pode ocasionar em perdas transacionais, por exemplo, e em alguns SGBDRs (Sistema de Gerenciamento de Banco de Dados Relacionais) não é possível nativamente construir bancos de dados em modelos master-to-master, onde os dois aceitam escritas e são replicados entre os nodes do cluster, se tornando os dois nodes replicas fiéis um do outro. Normalmente em se tratando de banco de dados o escravo nada mais é do que uma replica com permissão apenas de leitura, não podendo ser escrito diretamente nele, e o chaveamento se torna manual, porém é importante deixar claro que isso não é uma regra, pode sim ter o chaveamento automático dependendo da tecnologia utilizada para intermediar essa situação ou mesmo se o SGBDR tem esse suporte nativo.

Exemplo do conceito de balanceamento, quando um Gerente de TI recebe muitos chamados, a primeira coisa que ele faz é distribuir esses chamados a todos os analistas que estiverem ociosos, a fim de distribuir a carga de trabalho, fazendo uma analogia, o Gerente de TI é o Balanceador, e os analistas são os Backend, são os membros do Cluster. Quando o Gestor de TI recebe uma maior demanda de trabalho ele necessita contratar mais mão de obra, em se tratando de uma arquitetura balanceada não se difere muito, novos membros podem ser adicionados ao cluster, construindo um escalonamento horizontal, tornando uma arquitetura mais ampla.

Estes modelos devem ser aplicados de acordo com determinadas circunstâncias que sempre devem ser avaliadas pelo Arquiteto de Soluções do projeto ou pelo Administrador de Sistemas (SysAdmin), prevendo os possíveis pontos únicos de falha e as formas de contornar a situação construindo um ambiente totalmente tolerante a falhas. Construir ambientes alto disponíveis hoje já é uma realidade e vista com bons olhos dentro das empresas de diversos segmentos ou setores de tecnologias, onde os profissionais com esses conhecimentos e capacidades técnicas para desenhar a solução e aplica-las são muito bem remunerados e considerado um enorme diferencial perante aos seus colegas.

Na categoria sobre Alta Disponibilidade veremos na prática como construir arquiteturas de Alta Disponibilidades eficiente através de soluções FOSS (Free & Open Source Solution), como Heartbeat, Pacemaker, Corosync, DRBD, lvs, RHCS (Red Hat Cluster Suite), etc.

Uma ideia sobre “O que é Alta Disponibilidade?”

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *