Pensar em missão crítica é naturalmente avaliar cada componente, cada ativo e cada serviço da arquitetura sob a ótica de tolerância a falha. O objetivo não é evitar a falha em si, pois ela possivelmente irá ocorrer, mas garantir que quando aconteça, o serviço ou sistema suportado pelo ativo em falha continue operando, sem ou com o mínimo de impacto na operação.
Posto isso, para desenharmos uma arquitetura altamente disponível, devemos segmentar todos os componentes por tipo ou função, e depois de segmentados, avaliá-los individualmente criticando sua capacidade de operação durante uma falha.
Começando por ativos, uma forma simplificada de avaliar individualmente é considerar que todo e qualquer componente crítico ao funcionamento pleno deverá existir em duplicidade, de forma ativa-ativa, ou seja, online. Tomando como exemplo um servidor x86, para termos um ativo altamente disponível, precisaremos dos seguintes requisitos:
Duas fontes de alimentação, sendo que uma única deverá ter capacidade em Watts para alimentar todo o sistema e ambas deverão operar em redundância ativa;
Dois processadores e memórias com correção de erro;
Duas unidades de armazenamento operando em RAID1 para o sistema operacional;
Duas ou mais portas de rede ethernet;
Duas ou mais portas fiber channel, preferencialmente com duas HBAs.
Esse raciocínio se aplica a todo e qualquer ativo, de um simples switch a blades e storages de grande porte. Claro, nem sempre é possível um ativo ter todos os componentes redundantes, por exemplo, fontes de alimentação, e nesses casos devemos recorrer a sistemas externos para aumentar sua disponibilidade. No caso de fontes únicas de alimentação, conseguimos alta disponibilidade com a utilização de sistemas de energia ATS, que garantem fornecimento contínuo de energia, com pelo menos dois circuitos, para ativos de fonte única.
Já exemplificado o que é um ativo altamente disponível, agora falaremos de arquitetura altamente disponível. O principal requisito de uma arquitetura altamente disponível é a manutenção dos sistemas e serviços frente a falhas de ativos que a compõem, sejam estas falhas físicas ou sistêmicas. Para cumprirmos esse requisito, devemos avaliar nos serviços que consumirão essa arquitetura sua capacidade de operação distribuída, seja essa operação fundamentada em clusters ou em balanceamento de carga na camada de rede ou na camada de aplicação. Uma vez validada essa capacidade, conseguimos desenhar, também usando informações vindas de um capacity planning ou de requisitos de fornecedores, quais e quantos ativos que proverão a capacidade computacional serão necessários.
E a arquitetura final, altamente disponível, também deve considerar fornecedores externos de comunicação, sistemas de refrigeração, sistemas de monitoramento e extinção de incêndios, segurança física, e todo e qualquer controle necessário para mitigar os riscos operacionais e ambientais.
Como melhor prática, avalie criticamente todos os ativos – em produção ou de uma nova arquitetura – sob a ótica de alta disponibilidade, e planeje ações de adequação e mitigação dos riscos identificados.
Com isso claro, o desenho final da arquitetura deve incorporar não apenas os servidores e sistemas internos, mas também elementos externos que são tão críticos quanto: provedores de comunicação, refrigeração, energia, monitoramento, segurança física, incêndio e qualquer outro fator que possa interromper a operação. Alta Disponibilidade real é sempre sistêmica, nunca isolada.
Como boa prática, todo ambiente, novo ou em produção, deve ser revisado periodicamente sob a ótica da alta disponibilidade. Essa avaliação permite identificar riscos antes de eles se tornarem incidentes e preparar ações de mitigação que mantêm a operação estável, previsível e resiliente. No fim, Alta Disponibilidade não é um projeto; é uma disciplina contínua que sustenta a confiança no seu negócio.
