 |
| Bellacosa Mainframe ibm z resiliencia parte i |
☕ Um Café no Bellacosa Mainframe
O Holocron da Resiliência IBM Z
Parte I – Conceitos Fundamentais: Por que os Mainframes Quase Nunca Param?
Quando um jovem Padawan COBOL entra pela primeira vez em uma empresa que utiliza IBM Z, normalmente ele acredita que seu trabalho consiste em escrever programas COBOL, executar alguns Jobs, consultar arquivos VSAM e, eventualmente, criar uma transação CICS.
Não demora muito para ouvir frases como:
"Precisamos garantir o SLA."
"O RTO deste sistema é de cinco minutos."
"Não podemos ter nenhum Single Point of Failure."
"Essa aplicação precisa ser resiliente."
Nesse momento, o Padawan percebe que entrou em um universo completamente diferente daquele ensinado na maioria dos cursos de programação.
No IBM Z, escrever software é apenas uma parte da engenharia. A outra metade consiste em garantir que esse software continue funcionando quando tudo ao redor começa a falhar.
Bem-vindo ao mundo da Resiliência.
Os conceitos apresentados nesta primeira parte são a base para compreender por que os maiores bancos, seguradoras, bolsas de valores, companhias aéreas e governos do mundo continuam confiando no IBM Z para executar suas aplicações mais críticas. Os termos discutidos a seguir fazem parte do glossário de Resiliency do IBM Z e representam os pilares conceituais dessa arquitetura.
O que significa Resiliency?
Imagine um hospital.
Ninguém espera que um hospital nunca enfrente problemas.
Equipamentos quebram.
Transformadores queimam.
Geradores precisam de manutenção.
Redes elétricas falham.
Mesmo assim...
A cirurgia não pode parar.
No mundo dos computadores acontece exatamente a mesma coisa.
Resiliência significa continuar prestando serviço mesmo quando partes da infraestrutura apresentam defeitos.
Esse é um conceito muito diferente de simplesmente "não quebrar".
Todo equipamento quebra.
Todo software possui defeitos.
Todo disco possui vida útil.
Toda memória pode apresentar falhas.
A diferença é que o IBM Z foi projetado assumindo que essas falhas acontecerão.
A arquitetura inteira trabalha para impedir que o usuário perceba qualquer interrupção.
Essa filosofia explica por que milhares de transações bancárias continuam acontecendo enquanto técnicos substituem processadores, discos ou placas de comunicação.
Para um programador COBOL, compreender Resiliency muda completamente a forma de pensar. O objetivo deixa de ser apenas fazer o programa "funcionar"; passa a ser escrever aplicações que convivam com uma infraestrutura preparada para falhas.
RAS – Reliability, Availability and Serviceability
Existe um conceito extremamente famoso dentro da IBM:
RAS.
São apenas três palavras.
Mas representam décadas de engenharia.
Reliability
Confiabilidade.
O equipamento precisa falhar pouco.
Isso envolve:
qualidade dos componentes;
redundância;
testes de fábrica;
validações contínuas.
Quanto maior a confiabilidade, menor a probabilidade de interrupções inesperadas.
Availability
Disponibilidade.
Mesmo quando alguma coisa quebra...
O serviço continua.
É exatamente aqui que entram conceitos como:
Parallel Sysplex;
GDPS;
Load Balancing;
WLM.
Disponibilidade não significa ausência de falhas.
Significa continuidade do negócio.
Serviceability
Facilidade de manutenção.
Imagine trocar um disco sem desligar o computador.
Ou substituir memória durante a operação.
Ou atualizar firmware sem interromper milhares de usuários.
Isso é Serviceability.
Quanto mais simples a manutenção...
Menor o tempo de indisponibilidade.
High Availability (HA)
Muitos iniciantes acreditam que Alta Disponibilidade significa "100% online".
Não é verdade.
Alta Disponibilidade significa reduzir o impacto das interrupções até um nível aceitável para o negócio.
Imagine dois caixas eletrônicos.
Se um apresentar defeito...
O cliente utiliza o outro.
Agora imagine dois servidores CICS.
Se um falhar...
O outro assume automaticamente.
Essa é a essência da HA.
A infraestrutura foi desenhada para absorver falhas sem interromper o serviço.
Disaster Recovery (DR)
Enquanto a Alta Disponibilidade lida com falhas locais, o Disaster Recovery pensa em eventos extremos.
Perguntas típicas são:
E se o prédio pegar fogo?
E se faltar energia por várias horas?
E se houver uma enchente?
E se todo o datacenter ficar inacessível?
Nesse cenário entra o Plano de Recuperação de Desastres.
O objetivo não é impedir o desastre.
É garantir que o negócio sobreviva a ele.
No IBM Z, tecnologias como GDPS, replicação de dados e sites espelhados fazem parte dessa estratégia.
SLA – Service Level Agreement
Todo sistema existe para atender um negócio.
E o negócio estabelece compromissos.
Exemplo:
"O Internet Banking deve permanecer disponível 99,99% do tempo."
Isso é um SLA.
Curiosamente, poucas pessoas percebem o impacto desses números.
Veja:
99% parece excelente.
99,9% é muito melhor.
99,99% é extraordinário.
99,999% representa apenas alguns minutos de indisponibilidade por ano.
Cada "9" adicional exige muito mais investimento em hardware, software, processos e pessoas.
RPO – Recovery Point Objective
Imagine que um banco sofra uma pane às 15h.
Qual o último dado aceitável?
15h00?
14h59?
14h30?
Ontem?
Essa resposta define o RPO.
Quanto menor o RPO...
Menor a perda de informações.
Em sistemas financeiros modernos, o objetivo costuma ser próximo de zero.
Nenhuma transação pode desaparecer.
RTO – Recovery Time Objective
Agora faça outra pergunta.
Quanto tempo o sistema pode permanecer parado?
Cinco minutos?
Uma hora?
Quatro horas?
Isso é o RTO.
Observe a diferença.
O RPO mede perda de dados.
O RTO mede tempo de recuperação.
São conceitos diferentes.
E ambos determinam toda a arquitetura de um ambiente corporativo.
Single Point of Failure (SPoF)
Este talvez seja o termo mais importante para qualquer arquiteto.
Imagine um único switch de rede.
Se ele quebrar...
Toda a empresa para.
Esse switch é um SPoF.
Agora pense em um único banco de dados.
Ou uma única fonte de alimentação.
Ou um único servidor DNS.
Todos são candidatos a pontos únicos de falha.
A missão dos arquitetos IBM Z é eliminar todos eles.
Por isso existem componentes redundantes, caminhos alternativos e múltiplos mecanismos de recuperação.
Component Failure Impact Analysis (CFIA)
O nome parece complicado.
Mas a ideia é simples.
Pergunte para cada componente:
"O que acontece se você morrer agora?"
Depois repita para:
discos;
processadores;
memória;
switches;
links;
storages;
sistemas operacionais.
Se alguma resposta for:
"Tudo para."
Você encontrou um problema.
O CFIA é justamente o exercício sistemático de identificar esses riscos antes que eles ocorram.
ITIL – Muito Além da Tecnologia
Muitos desenvolvedores imaginam que disponibilidade depende apenas do hardware.
Na prática, processos mal definidos também derrubam sistemas.
É aqui que entra a ITIL.
Ela organiza boas práticas para:
mudanças;
incidentes;
problemas;
configuração;
continuidade;
disponibilidade.
Quando uma grande instituição financeira realiza uma atualização em produção, normalmente existe todo um processo inspirado nessas práticas para reduzir riscos.
A Mentalidade IBM Z
Existe uma frase bastante conhecida entre profissionais experientes de Mainframe:
"No IBM Z, falhas são esperadas. O que não é aceitável é que elas interrompam o negócio."
Essa mentalidade muda completamente a forma de desenvolver software.
O programador COBOL deixa de enxergar apenas linhas de código e passa a compreender que sua aplicação faz parte de um ecossistema muito maior, onde hardware, sistema operacional, middleware, armazenamento e processos trabalham em conjunto para garantir continuidade.
Cada programa Batch, cada transação CICS e cada acesso ao Db2 participa de uma cadeia cuidadosamente projetada para manter milhões de pessoas utilizando serviços bancários, comprando passagens aéreas, movimentando bolsas de valores ou recebendo benefícios sociais sem sequer imaginar a complexidade escondida por trás de uma simples tela.
Esse é o verdadeiro espírito do IBM Z.
Não construir computadores que nunca falham.
Mas construir sistemas que continuam funcionando mesmo quando inevitavelmente algo dá errado.
No próximo capítulo, deixaremos os conceitos e entraremos na infraestrutura física do IBM Z, explorando componentes como CPC, Processing Units, HMC, Support Element, License Internal Code e outros elementos que fazem do mainframe uma das plataformas mais resilientes já criadas.
