 |
| Bellacosa Mainframe e a resiliencia ibm z parte vi |
☕ Um Café no Bellacosa Mainframe
O Holocron da Resiliência IBM Z
Parte VI – A Última Linha de Defesa: Como o IBM Z Sobrevive a Desastres e Nunca Perde os Dados
"Um servidor pode falhar. Um storage pode quebrar. Um datacenter inteiro pode desaparecer. Mas o negócio não pode parar."
Chegamos à última etapa da nossa jornada pelo Holocron da Resiliência IBM Z.
Ao longo desta série aprendemos que Resiliência não depende apenas de um computador robusto.
Conhecemos o hardware.
Descobrimos como funciona o Parallel Sysplex.
Exploramos o armazenamento inteligente.
Entendemos o papel do CICS, Db2, MQ e IMS.
Mas ainda existe uma pergunta que todo executivo faz.
"E se acontecer o pior?"
E se um incêndio destruir o datacenter?
E se uma enchente atingir toda a cidade?
E se um apagão deixar um estado inteiro sem energia?
E se ocorrer um ataque cibernético que torne um ambiente indisponível?
É justamente para responder essas perguntas que existem as tecnologias de Business Continuity do IBM Z.
Os conceitos desta última parte incluem IBM Copy Services Manager (CSM), Continuous Availability (CA), Metro Mirror (PPRC), Global Mirror (GM), Coupling Data Set (CDS), Zero Data Loss (ZDL), z/OS Global Mirror (XRC), Multi Target Metro Mirror (MTMM), Server/Application State Protocol (SASP) e Business Continuity Plan (BCP).
Quando o Impensável Acontece
Imagine uma cidade inteira sem energia.
Imagine um terremoto.
Imagine um incêndio no prédio onde funciona o datacenter principal.
Para um computador doméstico...
É o fim.
Para um IBM Z...
É apenas mais um cenário previamente planejado.
O segredo nunca foi impedir desastres.
O segredo sempre foi estar preparado para eles.
Business Continuity
Existe uma diferença enorme entre recuperação e continuidade.
Recuperação significa voltar a funcionar.
Continuidade significa praticamente nunca deixar de funcionar.
É uma mudança completa de filosofia.
O objetivo não é consertar rapidamente.
É continuar operando mesmo durante o desastre.
IBM Copy Services Manager (CSM)
Imagine um maestro.
Diversos músicos.
Cada um toca um instrumento.
O maestro garante que todos permaneçam sincronizados.
O IBM Copy Services Manager exerce papel semelhante.
Ele administra toda a replicação entre storages.
Coordena espelhamentos.
Automatiza operações.
Orquestra procedimentos de recuperação.
Em vez de administrar dezenas de equipamentos manualmente, tudo passa a ser centralizado.
Continuous Availability
Imagine trocar o motor de um avião em pleno voo.
Parece impossível.
Mas essa é exatamente a filosofia da Continuous Availability.
Atualizações.
Trocas de hardware.
Mudanças de configuração.
Migração de workloads.
Tudo deve acontecer com o menor impacto possível para quem está utilizando a aplicação.
No IBM Z, indisponibilidade planejada deve ser tão rara quanto a não planejada.
Metro Mirror (PPRC)
Agora imagine dois prédios separados por poucos quilômetros.
Sempre que um dado é gravado no primeiro...
Ele também é gravado imediatamente no segundo.
Somente depois disso a operação termina.
Esse é o conceito do Metro Mirror.
A replicação é síncrona.
Os dois ambientes permanecem praticamente idênticos.
O RPO tende a zero.
Nenhuma informação é perdida.
Por isso é muito utilizado quando a distância física entre os datacenters é relativamente pequena.
Global Mirror
Mas...
E quando os datacenters ficam em estados diferentes?
Ou até em países diferentes?
Nesse caso, esperar a confirmação imediata poderia aumentar o tempo de resposta.
Surge então o Global Mirror.
A replicação passa a ser assíncrona.
As informações continuam protegidas.
Porém existe uma pequena diferença temporal entre os dois ambientes.
Em troca...
Obtém-se enorme flexibilidade geográfica.
z/OS Global Mirror (XRC)
O XRC, conhecido atualmente como z/OS Global Mirror, leva essa ideia ainda mais longe.
O próprio z/OS participa da coordenação da replicação.
Isso permite controlar grandes volumes de dados distribuídos em longas distâncias.
É muito comum em estratégias nacionais de recuperação de desastres.
Zero Data Loss
Poucas expressões impressionam tanto quanto esta.
Zero Data Loss.
Zero.
Nenhuma transação perdida.
Nenhum pagamento desaparece.
Nenhuma transferência bancária some.
Nenhuma operação financeira deixa de existir.
Naturalmente atingir esse objetivo exige enorme investimento.
Mas para determinados negócios...
É simplesmente obrigatório.
Multi Target Metro Mirror
Imagine escrever simultaneamente em diversos locais.
Não apenas em dois.
Mas em três.
Ou quatro.
Esse é o objetivo do MTMM.
Existem múltiplos destinos recebendo exatamente as mesmas informações.
Isso amplia ainda mais a segurança operacional.
Coupling Data Set (CDS)
Ao longo da série falamos bastante sobre o Parallel Sysplex.
Mas onde ficam armazenadas suas informações essenciais?
No Coupling Data Set.
Ele guarda definições fundamentais utilizadas pelo ambiente.
Caso esse conjunto de informações seja perdido, o funcionamento do Sysplex pode ser comprometido.
Por isso sua proteção é extremamente importante.
Server/Application State Protocol (SASP)
Outro componente importante é o SASP.
Seu objetivo é manter informações sobre o estado das aplicações.
Quem está ativo.
Quem está aguardando.
Quem assumiu determinada função.
Esses dados permitem que processos de recuperação ocorram de maneira organizada e consistente.
O Business Continuity Plan
Toda tecnologia do mundo é inútil sem planejamento.
É aqui que entra o Business Continuity Plan.
O BCP responde perguntas como:
Quem decide iniciar o ambiente de contingência?
Quem comunica clientes?
Quem valida os sistemas?
Quem libera operações financeiras?
Quem acompanha a recuperação?
Quais aplicações voltam primeiro?
Quais podem esperar?
Um bom plano reduz o improviso.
E improviso costuma ser o maior inimigo durante grandes crises.
Um Exemplo Real
Imagine um grande banco brasileiro.
São 40 milhões de clientes.
Às 10 horas da manhã ocorre um incêndio no datacenter principal.
Automaticamente:
os dados já existem no site secundário graças ao Metro Mirror;
o Copy Services Manager coordena o ambiente;
o Sysplex identifica a indisponibilidade;
aplicações críticas continuam disponíveis;
o BCP define quais equipes entram em ação;
clientes continuam utilizando PIX, cartões e Internet Banking.
Talvez a maioria das pessoas jamais descubra que um desastre aconteceu.
Esse é justamente o objetivo.
O Que um Padawan COBOL Aprende Com Tudo Isso?
Depois desta série, talvez a maior descoberta não seja um comando do JCL.
Nem uma instrução COBOL.
Nem um parâmetro do CICS.
O verdadeiro aprendizado é perceber que uma aplicação empresarial nunca trabalha sozinha.
Ela faz parte de um ecossistema gigantesco.
Quando um programa COBOL executa um simples:
READ CLIENTES
Existe uma enorme cadeia trabalhando nos bastidores.
Storage.
DFSMS.
Db2.
CICS.
IMS.
MQ.
Parallel Sysplex.
Coupling Facility.
GDPS.
Metro Mirror.
Global Mirror.
BCP.
Milhares de engenheiros contribuíram para que aquele simples comando execute em poucos milissegundos.
O Verdadeiro Poder do IBM Z
Existe um motivo pelo qual o IBM Z continua sendo referência mundial após mais de seis décadas.
Ele nunca foi apenas um computador.
Sempre foi uma filosofia de engenharia.
Uma filosofia baseada em princípios simples.
Esperar falhas.
Eliminar pontos únicos de falha.
Automatizar recuperações.
Priorizar o negócio.
Proteger os dados.
Evoluir continuamente.
Manter os serviços disponíveis.
Esses princípios permanecem atuais mesmo na era da computação em nuvem, inteligência artificial e microsserviços.
Palavra Final do Mestre
Todo Padawan começa aprendendo COBOL.
Depois aprende JCL.
Mais tarde conhece CICS, Db2, VSAM e IMS.
Mas chega um momento em que ele percebe que escrever código é apenas uma pequena parte do trabalho.
Os profissionais mais respeitados do mundo Mainframe não são aqueles que apenas conhecem comandos.
São aqueles que entendem por que uma transação bancária continua funcionando durante um desastre, por que milhões de clientes conseguem acessar seus serviços simultaneamente e como uma infraestrutura inteira trabalha silenciosamente para proteger aquilo que realmente importa: os dados e a continuidade do negócio.
Esse é o verdadeiro legado do IBM Z.
Não apenas processar milhões de transações por segundo.
Mas fazê-lo com uma confiabilidade tão extraordinária que, na maior parte do tempo, ninguém sequer percebe a engenharia monumental que existe por trás de um simples acesso ao saldo da conta.
E talvez seja exatamente esse o maior elogio que um sistema crítico possa receber.
Quando tudo funciona perfeitamente, ninguém percebe que existe um Mainframe trabalhando nos bastidores.
Sem comentários:
Enviar um comentário