IBM Z Resiliência : 30 Laboratórios Práticos Do "Meu Primeiro Sysplex" até "Meu Datacenter Nunca Para"

Bellacosa Mainframe e o laboratorio pratico em IBM Z Resiliencia

---

☕ O Holocron da Resiliência IBM Z

30 Laboratórios Práticos

Do "Meu Primeiro Sysplex" até "Meu Datacenter Nunca Para"

A Resiliência no IBM Z vai muito além de conhecer siglas como HA, DR, Parallel Sysplex ou GDPS. Ela representa uma filosofia de engenharia construída ao longo de décadas para garantir que aplicações críticas permaneçam disponíveis mesmo diante de falhas de hardware, software, rede ou até desastres naturais. O objetivo deste guia é conduzir o Programador COBOL, Analista de Sistemas ou futuro Sysprog por uma jornada progressiva, mostrando como cada componente da plataforma contribui para a continuidade do negócio e como todos trabalham em conjunto para entregar disponibilidade praticamente ininterrupta.

A melhor forma de aprender é evoluir em etapas. Comece dominando os conceitos fundamentais de SLA, RPO, RTO, RAS e Single Point of Failure. Em seguida, compreenda a arquitetura do IBM Z, estudando CPC, LPARs, HMC e o papel do LIC. Depois avance para Parallel Sysplex, Coupling Facility, WLM e GDPS, entendendo como múltiplos sistemas operam como um único ambiente resiliente. Na sequência, aprofunde-se em DFSMS, Storage, CICS, Db2, IMS, MQ e estratégias de recuperação e continuidade dos negócios.

Procure sempre relacionar teoria com prática. Analise mensagens do sistema, consulte o SDSF, estude relatórios RMF e SMF, desenhe arquiteturas, simule cenários de falha e questione como sua aplicação reagiria a cada situação. O profissional que compreende Resiliência deixa de enxergar apenas programas COBOL e passa a entender todo o ecossistema que mantém milhões de transações funcionando com segurança, desempenho e confiabilidade. Esse é o caminho para evoluir de Padawan a Mestre no universo IBM Z.

---

🟢 NÍVEL 1 — PADAWAN (Labs 1–10)

Lab 1 – Descobrindo a Arquitetura IBM Z

Objetivo

Identificar todos os componentes físicos do ambiente.

Atividades

• Localizar CPC

• Identificar LPARs

• Ver HMC

• Identificar Storage

Solução

O aluno deve desenhar a arquitetura mostrando como todos os componentes se conectam.

---

Lab 2 – Identificando SPOFs

Objetivo

Encontrar Single Points of Failure.

Atividades

Analisar:

• Rede

• Storage

• CICS

• MQ

• Db2

Solução

Criar uma tabela

Componente	Existe redundância?
Storage	Sim
Switch	Não
Servidor DNS	Não

---

Lab 3 – Calculando SLA

Dado:

99,5%

99,9%

99,99%

99,999%

Calcule:

• indisponibilidade anual

• mensal

• diária

Solução

Utilizar tabela oficial de SLA.

---

Lab 4 – Descobrindo o RPO

Uma empresa aceita perder:

• nenhuma transação

• cinco minutos

• uma hora

Classifique o RPO.

Solução

Relacionar cada cenário ao objetivo de recuperação.

---

Lab 5 – Descobrindo o RTO

Mesmo exercício.

Agora considerando tempo de recuperação.

---

Lab 6 – CFIA

Escolha um ambiente.

Analise:

"O que acontece se..."

• Storage parar

• CPU parar

• Switch parar

Solução

Construir matriz de impacto.

---

Lab 7 – Conhecendo o WLM

No SDSF identificar:

• Service Classes

• Importance

• Velocity

Solução

Explicar porque um Job Batch ficou esperando.

---

Lab 8 – Explorando RMF

Consultar:

CPU

I/O

Paging

Storage

Solução

Gerar relatório resumido.

---

Lab 9 – Health Checker

Executar

F HZSPROC

Interpretar avisos.

---

Lab 10 – Runtime Diagnostics

Executar Runtime Diagnostics.

Interpretar:

• Loop

• Espera

• Deadlock

---

🟡 NÍVEL 2 — JEDI (Labs 11–20)

---

Lab 11 – Criando um Sysplex

Desenhar:

2 LPARs

1 Coupling Facility

Storage compartilhado

Solução

Apresentar diagrama.

---

Lab 12 – Entendendo a Coupling Facility

Identificar:

• Lock Structure

• Cache Structure

• List Structure

Explicar função de cada uma.

---

Lab 13 – Simulando Falha de um Membro

Desligar uma LPAR (ambiente de laboratório).

Observar:

• usuários continuam?

• aplicações continuam?

---

Lab 14 – ARM

Parar uma região CICS.

Verificar reinício automático.

---

Lab 15 – DVIPA

Mover uma aplicação entre membros.

Confirmar:

IP continua igual.

---

Lab 16 – Sysplex Distributor

Monitorar distribuição de sessões.

Verificar balanceamento.

---

Lab 17 – LBA

Analisar recomendações do Load Balancing Advisor.

---

Lab 18 – Capacity on Demand

Criar cenário:

Black Friday.

Qual recurso ativar?

CBU?

CUoD?

OOCoD?

Justifique.

---

Lab 19 – DFSMS

Criar:

Storage Group

Management Class

Storage Class

Data Class

Associar Dataset.

---

Lab 20 – DFSMShsm

Migrar um dataset.

Recuperá-lo.

Verificar tempo.

---

🔴 NÍVEL 3 — MESTRE (Labs 21–30)

---

Lab 21 – CICSplex

Desenhar:

TOR

AOR

FOR

DOR

Fluxo completo.

---

Lab 22 – MQ

Criar:

Queue

Sender

Receiver

Enviar mensagens.

Simular parada do receptor.

Confirmar persistência.

---

Lab 23 – Db2

Executar:

RUNSTATS

REORG

Comparar Access Path.

---

Lab 24 – IMS

Criar fluxo:

Terminal

TM

Programa

IMS DB

Resposta.

---

Lab 25 – Metro Mirror

Desenhar:

Site A

Site B

Replicação síncrona.

Explicar RPO.

---

Lab 26 – Global Mirror

Mesmo exercício.

Agora com longa distância.

Explicar diferenças.

---

Lab 27 – Business Continuity

Escreva um BCP contendo:

• responsáveis

• comunicação

• ordem de recuperação

• testes

---

Lab 28 – Simulação Completa

O cenário:

🔥 Incêndio no Data Center Principal.

O aluno deve decidir:

• ativa GDPS?

• ativa CBU?

• usa Metro Mirror?

• muda DNS?

• inicia ARM?

Justificar todas as decisões.

---

Lab 29 – Projeto de Arquitetura

Receba:

Banco Digital

20 milhões de clientes

PIX

Cartão

Internet Banking

Desenhe:

• Hardware

• Sysplex

• CICSplex

• MQ

• Db2

• Storage

• DR

---

Lab 30 – O Desafio Final do Mestre

A empresa deseja atingir:

• 99,999% de disponibilidade

• RPO = Zero

• RTO = Menor que 5 minutos

• Dois datacenters ativos

• 50 milhões de transações por dia

• Atualizações sem parada

• Crescimento de capacidade sem desligamento

Missão

Projetar toda a arquitetura IBM Z.

O projeto deve incluir:

• IBM Z (CPCs e LPARs)

• Parallel Sysplex

• Coupling Facility

• WLM

• SFM

• ARM

• CICSplex (TOR, AOR, FOR e DOR)

• IBM MQ

• Db2 for z/OS

• IMS (quando aplicável)

• DFSMS

• IBM Copy Services Manager

• Metro Mirror ou Global Mirror

• GDPS

• Business Continuity Plan

• Capacity on Demand (CBU, CUoD ou OOCoD)

Solução esperada

O aluno entrega um documento de arquitetura contendo:

• diagrama completo da solução;

• justificativa técnica para cada componente;

• estratégia de alta disponibilidade;

• estratégia de recuperação de desastres;

• cálculo de SLA, RPO e RTO;

• análise de Single Points of Failure e respectivas eliminações;

• plano de testes de contingência;

• plano de crescimento para os próximos cinco anos.

---

🏆 Certificação Bellacosa Mainframe

Ao concluir os 30 laboratórios, o aluno terá praticado os principais conceitos de resiliência do IBM Z, passando da compreensão dos fundamentos até o desenho de arquiteturas corporativas. Essa sequência é adequada tanto para um Programador COBOL Júnior que deseja entender a plataforma onde suas aplicações executam quanto para profissionais que pretendem evoluir para funções de Analista de Infraestrutura IBM Z, Sysprog, Especialista em Alta Disponibilidade ou Arquiteto Mainframe. Ela também pode servir como base para um curso completo de aproximadamente 40 horas, com exercícios, estudos de caso e desafios progressivos. 

O Holocron da Resiliência IBM Z - A Jornada Completa para Entender Por Que os Mainframes Nunca Param

 

Bellacosa Mainframe e a resiliencia ibm z

☕ Um Café no Bellacosa Mainframe

O Holocron da Resiliência IBM Z

A Jornada Completa para Entender Por Que os Mainframes Nunca Param

Existe uma pergunta que todo Padawan COBOL faz nos primeiros meses trabalhando com IBM Z.

"Por que os bancos utilizam Mainframe até hoje?"

A resposta normalmente é simplificada.

"Porque é seguro."

"Porque é rápido."

"Porque processa milhões de transações."

Embora todas essas afirmações sejam verdadeiras, elas escondem um conceito muito maior.

O verdadeiro diferencial do IBM Z não está apenas em sua capacidade de processamento.

Está na sua capacidade de continuar funcionando.

Ao longo desta série especial O Holocron da Resiliência IBM Z, percorremos uma jornada completa pelos principais componentes que transformam o IBM Z na plataforma mais confiável do mercado para aplicações críticas.

Muito mais do que conhecer novos termos técnicos, o objetivo foi compreender como hardware, sistema operacional, middleware, armazenamento e processos trabalham em perfeita sintonia para garantir continuidade dos negócios.

---

📜 Parte I – Conceitos Fundamentais

Nossa jornada começou entendendo a filosofia da Resiliência.

Exploramos conceitos como:

• Resiliency

• RAS

• High Availability

• Disaster Recovery

• SLA

• RPO

• RTO

• Single Point of Failure

• ITIL

• CFIA

Foi aqui que descobrimos que o IBM Z não foi projetado para impedir falhas.

Ele foi projetado para impedir que as falhas afetem o negócio.

👉 Leia a Parte I: https://eljefemidnightlunch.blogspot.com/2024/01/resiliencia-ibm-z-conceitos.html

---

🖥 Parte II – A Arquitetura do IBM Z

Na segunda publicação descemos até a infraestrutura física.

Conhecemos os componentes invisíveis que sustentam toda a plataforma:

• CPC

• Processing Units

• License Internal Code

• Hardware Management Console

• Support Element

• FFDC

• Runtime Diagnostics

• Predictive Failure Analysis

• Auto IPL

• System Recovery Boost

Foi possível entender como o próprio hardware participa ativamente da prevenção e recuperação de falhas.

👉 Leia a Parte II: https://eljefemidnightlunch.blogspot.com/2024/02/resiliencia-ibm-z-arquitetura-do-ibm-z.html

---

🔗 Parte III – Parallel Sysplex

Em seguida conhecemos uma das maiores invenções da engenharia IBM.

O Parallel Sysplex.

Exploramos:

• Coupling Facility

• WLM

• SFM

• ARM

• DVIPA

• Sysplex Distributor

• Load Balancing Advisor

Aprendemos como diversos mainframes conseguem trabalhar como um único sistema lógico, distribuindo carga automaticamente e mantendo aplicações disponíveis mesmo durante falhas.

👉 Leia a Parte III: https://eljefemidnightlunch.blogspot.com/2024/03/resiliencia-ibm-z-parallel-sysplex-o.html

---

💾 Parte IV – Storage Inteligente

Depois mergulhamos no universo do armazenamento corporativo.

Conhecemos o DFSMS e seus diversos componentes:

• DFSMSdfp

• DFSMSdss

• DFSMShsm

• DFSMSrmm

• DFSMStvs

Também exploramos:

• Capacity on Demand

• CBU

• CUoD

• OOCoD

• eBoD

• System Logger

Descobrimos que, no IBM Z, armazenamento significa muito mais do que simplesmente gravar arquivos.

É uma plataforma inteligente capaz de proteger, migrar, recuperar e expandir dados automaticamente.

👉 Leia a Parte IV: https://eljefemidnightlunch.blogspot.com/2024/04/resiliencia-ibm-z-storage-inteligente-e.html

---

⚙ Parte V – O Coração das Aplicações

Nenhuma infraestrutura teria valor sem aplicações.

Nesta etapa conhecemos os componentes responsáveis por processar milhões de transações diariamente:

• CICS

• CICS TS

• Db2

• IBM MQ

• IMS

• IMS DB

• CICSplex

• TOR

• AOR

• FOR

• DOR

• HALDB

• DBRC

• FDBR

Foi aqui que percebemos como aplicações COBOL continuam evoluindo e hoje conversam naturalmente com APIs REST, microsserviços, dispositivos móveis e plataformas em nuvem.

👉 Leia a Parte V:https://eljefemidnightlunch.blogspot.com/2024/05/resiliencia-ibm-z-o-coracao-das.html

---

🛡 Parte VI – A Última Linha de Defesa

Encerramos nossa jornada explorando os mecanismos responsáveis pela continuidade do negócio diante dos cenários mais extremos.

Conhecemos tecnologias como:

• IBM Copy Services Manager

• Metro Mirror

• Global Mirror

• z/OS Global Mirror

• Zero Data Loss

• Multi Target Metro Mirror

• Coupling Data Set

• Business Continuity Plan

Descobrimos que um desastre não precisa significar interrupção do negócio.

Tudo depende do planejamento e da arquitetura construída antes da emergência acontecer.

👉 Leia a Parte VI: https://eljefemidnightlunch.blogspot.com/2024/06/resiliencia-ibm-z-ultima-linha-de.html 

---

O Que um Padawan Deve Levar Desta Série?

Talvez o maior aprendizado desta série seja perceber que um programa COBOL nunca trabalha sozinho.

Quando um simples programa executa um READ, um WRITE, um EXEC SQL ou um EXEC CICS LINK, existe um verdadeiro ecossistema trabalhando silenciosamente nos bastidores.

Processadores especializados.

Controladores inteligentes.

Storage redundante.

Parallel Sysplex.

Workload Manager.

Middleware.

Replicação síncrona.

Recuperação automática.

Monitoramento contínuo.

Tudo isso existe para garantir que o usuário final consiga realizar uma operação bancária, uma compra no cartão de crédito, uma transferência PIX ou uma reserva de passagem aérea sem sequer imaginar a complexidade envolvida.

É justamente essa engenharia invisível que faz do IBM Z uma referência mundial em computação de missão crítica.

---

A Filosofia Bellacosa Mainframe

Existe uma frase que resume toda esta coleção.

"Resiliência não é uma tecnologia. É uma filosofia de engenharia."

No IBM Z, falhas são previstas.

Componentes quebram.

Discos são substituídos.

Processadores entram em manutenção.

Datacenters podem até ficar indisponíveis.

Mesmo assim, milhões de pessoas continuam utilizando seus serviços normalmente.

Esse é o verdadeiro poder do Mainframe.

Não construir computadores perfeitos.

Mas construir sistemas preparados para continuar funcionando quando a imperfeição inevitavelmente aparecer.

E talvez essa seja a maior lição para qualquer Programador COBOL.

Escrever código é importante.

Mas compreender toda a arquitetura que mantém esse código disponível para milhões de pessoas é o que transforma um Padawan em um verdadeiro Mestre do IBM Z.

Que a Força da Resiliência esteja com você.

Resiliência IBM Z – O Coração das Aplicações Resilientes: Como CICS, Db2, MQ e IMS - Parte V

 

Bellacosa Mainframe e a resiliencia ibm z parte v

☕ Um Café no Bellacosa Mainframe

O Holocron da Resiliência IBM Z

Parte V – O Coração das Aplicações Resilientes: Como CICS, Db2, MQ e IMS Mantêm Milhões de Transações Sempre Disponíveis

"Hardware poderoso impressiona. Mas são as aplicações que entregam valor ao negócio. O verdadeiro desafio é garantir que elas continuem funcionando mesmo quando tudo ao redor muda."

Até aqui nossa jornada mostrou que a Resiliência no IBM Z não depende apenas de computadores robustos.

Conhecemos conceitos como RAS, SLA e Disaster Recovery.

Descobrimos como o hardware foi projetado para detectar falhas antes mesmo que elas aconteçam.

Vimos como o Parallel Sysplex permite que vários mainframes trabalhem como um único sistema.

Também aprendemos que o armazenamento IBM Z é inteligente, automatizado e capaz de crescer sem interromper o negócio.

Mas falta responder uma pergunta.

Quem realmente atende o cliente?

Quem responde uma consulta bancária?

Quem realiza uma transferência PIX?

Quem grava um pagamento?

Quem consulta uma apólice de seguro?

Quem processa uma compra no cartão de crédito?

A resposta está no conjunto de tecnologias conhecido como middleware.

São elas que transformam toda aquela infraestrutura invisível em serviços utilizados diariamente por milhões de pessoas.

Os conceitos desta parte abrangem IBM MQ, IBM Db2 for z/OS, CICS, CICS Transaction Server (CICS TS), z/OS Workload Manager Health API, Automatic Restart Manager (ARM), CICSplex, TOR, AOR, DOR, FOR, IMS, IMS DB, Transaction Manager, HALDB, Fast Database Recovery (FDBR) e IMS Database Recovery Control (DBRC). Esses componentes aparecem na seção final do glossário IBM Z Resiliency.

---

O Que é Middleware?

Imagine uma cidade.

Existe energia elétrica.

Existe abastecimento de água.

Existe internet.

Existe transporte.

Tudo isso representa a infraestrutura.

Mas quem realmente atende o cidadão?

Os hospitais.

Os bancos.

Os supermercados.

As escolas.

No IBM Z acontece exatamente a mesma coisa.

Hardware, Storage e Sysplex representam a infraestrutura.

CICS, Db2, MQ e IMS representam os serviços utilizados pelo negócio.

É ali que mora a aplicação COBOL.

---

CICS – O Grande Atendente do Mainframe

Poucas tecnologias marcaram tanto a história da computação quanto o Customer Information Control System, mais conhecido como CICS.

Imagine uma agência bancária.

Cada cliente chega ao caixa.

Faz uma solicitação.

Recebe uma resposta.

Sai.

O próximo cliente é atendido.

O CICS faz exatamente isso.

Milhares de usuários enviam requisições simultaneamente.

O CICS organiza tudo.

Distribui recursos.

Executa programas COBOL.

Gerencia transações.

Controla segurança.

Coordena acesso aos dados.

Sem ele, grande parte das aplicações online simplesmente não existiria.

---

CICS Transaction Server

O CICS TS representa a evolução moderna do CICS.

Hoje ele suporta:

• APIs REST;

• JSON;

• Web Services;

• Java;

• Eventos;

• Integração com Cloud;

• Containers e Channels;

• Threadsafe;

• OpenTelemetry;

• Segurança moderna.

Muita gente imagina que o CICS ficou preso aos terminais verdes.

Na realidade ele conversa diariamente com aplicativos Android, iPhones, internet banking, caixas eletrônicos e sistemas distribuídos.

O COBOL continua executando.

A tecnologia ao redor evoluiu.

---

Db2 for z/OS – O Guardião dos Dados

Toda empresa possui seu patrimônio.

No banco...

São as contas.

Na seguradora...

São as apólices.

Na companhia aérea...

São as reservas.

Quem protege essas informações?

O Db2.

Ele garante:

• consistência;

• concorrência;

• recuperação;

• integridade;

• desempenho.

Quando dois milhões de pessoas consultam saldo simultaneamente, o Db2 coordena milhares de operações concorrentes sem comprometer a integridade dos dados.

---

IBM MQ – O Carteiro que Nunca Dorme

Imagine uma empresa gigantesca.

Nem todos os departamentos trabalham no mesmo horário.

Mesmo assim as mensagens precisam chegar.

O IBM MQ resolve exatamente esse problema.

Ele entrega mensagens com segurança.

Mesmo que o destinatário esteja temporariamente indisponível.

Isso desacopla aplicações.

Aumenta a disponibilidade.

Facilita integrações.

É por isso que tantas arquiteturas modernas utilizam filas.

---

Quando Tudo Acontece ao Mesmo Tempo

Imagine um PIX.

Em poucos segundos acontecem dezenas de operações.

O aplicativo envia a solicitação.

O CICS recebe a transação.

O COBOL valida regras de negócio.

O Db2 consulta contas.

O MQ envia notificações.

Outro sistema recebe a mensagem.

Tudo precisa acontecer praticamente em tempo real.

Se qualquer componente falhar...

Toda a experiência do cliente será afetada.

É por isso que a Resiliência é tão importante.

---

CICSplex – Um CICS Nunca Vem Sozinho

Assim como existe o Parallel Sysplex...

Também existe o CICSplex.

Ele reúne diversos ambientes CICS trabalhando em conjunto.

Para o usuário...

Existe apenas um sistema.

Na realidade podem existir dezenas de regiões distribuindo carga automaticamente.

---

TOR – Terminal Owning Region

Imagine a recepção de um grande hospital.

Ela recebe os pacientes.

Mas não realiza cirurgias.

O TOR funciona assim.

Ele recebe as conexões dos usuários.

Depois encaminha cada solicitação para outra região responsável pelo processamento.

---

AOR – Application Owning Region

Agora chegamos ao verdadeiro coração da aplicação.

É na AOR que executam os programas COBOL.

Toda lógica de negócio vive aqui.

Quanto mais regiões AOR existirem...

Maior poderá ser a capacidade de processamento.

---

FOR – File Owning Region

Algumas aplicações acessam milhares de arquivos VSAM.

Em vez de cada região abrir esses arquivos individualmente...

Existe a FOR.

Ela centraliza esse acesso.

Reduz conflitos.

Melhora desempenho.

Simplifica administração.

---

DOR – Data Owning Region

A DOR segue filosofia semelhante.

Ela concentra determinados recursos de dados compartilhados entre diversas aplicações.

Essa separação facilita manutenção e escalabilidade.

---

WLM Health API

Lembra do Workload Manager?

Agora imagine que o próprio middleware possa informar ao WLM seu estado de saúde.

É exatamente essa a função da Health API.

O WLM deixa de observar apenas consumo de CPU.

Ele passa a considerar também a qualidade do serviço entregue pelas aplicações.

---

Automatic Restart Manager

Na Parte III conhecemos o ARM.

Agora podemos entender seu impacto real.

Se uma região CICS terminar inesperadamente...

O ARM pode reiniciá-la automaticamente.

Sem operadores.

Sem intervenção humana.

Sem perda significativa de disponibilidade.

---

IMS – O Veterano Que Continua Jovem

Muito antes da internet existir...

O IMS já processava milhões de transações.

Hoje continua fazendo exatamente isso.

O Information Management System permanece como um dos ambientes transacionais mais rápidos do mundo.

Muitas aplicações financeiras ainda dependem dele diariamente.

---

IMS DB

O banco de dados IMS possui características próprias.

Sua organização hierárquica oferece desempenho extremamente elevado para determinadas cargas de trabalho.

Quando corretamente modelado, consegue responder consultas com velocidade impressionante.

---

Transaction Manager

O IMS TM coordena o processamento online.

Recebe requisições.

Controla filas.

Executa programas.

Gerencia recuperação.

Mantém a integridade das transações.

É o equivalente, dentro do universo IMS, ao papel desempenhado pelo CICS em inúmeras aplicações.

---

HALDB – Crescendo Sem Limites

Com o passar dos anos, algumas bases IMS tornaram-se gigantescas.

O High Availability Large Database foi criado para resolver esse desafio.

Ele divide grandes bancos de dados em partições.

Assim é possível:

• aumentar capacidade;

• reduzir tempo de manutenção;

• melhorar disponibilidade;

• facilitar reorganizações.

Tudo isso mantendo o sistema online.

---

Fast Database Recovery

Imagine um acidente.

Quanto mais rápido a recuperação...

Menor o impacto.

O FDBR acelera a recuperação das bases IMS após falhas.

Isso reduz significativamente o RTO.

---

IMS Database Recovery Control

Toda recuperação precisa ser coordenada.

O DBRC registra informações fundamentais sobre backups, logs e processos de recuperação.

Ele garante que as bases sejam restauradas corretamente.

Sem perda de consistência.

---

O Que um Programador COBOL Deve Aprender?

Muitos iniciantes acreditam que basta dominar a linguagem COBOL.

Na prática...

O código representa apenas uma parte da aplicação.

Um profissional IBM Z moderno precisa compreender:

• como o CICS gerencia transações;

• como o Db2 protege dados;

• como o MQ integra sistemas;

• como o IMS processa grandes volumes;

• como a infraestrutura garante disponibilidade.

Quanto maior essa visão...

Maior será sua capacidade de construir aplicações resilientes.

---

O Legado do IBM Z

Existe um motivo pelo qual bancos processam bilhões de transações utilizando tecnologias criadas há décadas.

Elas nunca pararam de evoluir.

O CICS conversa com APIs REST.

O Db2 trabalha com analytics e inteligência artificial.

O MQ conecta aplicações distribuídas.

O IMS continua ampliando desempenho e disponibilidade.

Nada permaneceu parado no tempo.

O legado do IBM Z não é tecnologia antiga.

É tecnologia que amadureceu continuamente sem abandonar aquilo que sempre fez melhor: processar transações críticas com confiabilidade, desempenho e resiliência.

No próximo capítulo do Holocron da Resiliência IBM Z, concluiremos nossa jornada explorando IBM Copy Services Manager (CSM), Metro Mirror, Global Mirror, XRC, Zero Data Loss (ZDL), Coupling Data Sets (CDS), Business Continuity Plan (BCP) e as estratégias que permitem proteger informações mesmo diante de desastres de grande escala, fechando o ciclo completo da Resiliência no IBM Z.

Resiliência IBM Z – Parallel Sysplex: O Segredo que Faz Diversos Mainframes se Comportarem Como Um Só - Parte III

 

Bellacosa Mainframe fala sobre resiliencia ibm z parte III

☕ Um Café no Bellacosa Mainframe

O Holocron da Resiliência IBM Z

Parte III – Parallel Sysplex: O Segredo que Faz Diversos Mainframes se Comportarem Como Um Só

"Se existe uma tecnologia que separa o IBM Z de praticamente todas as outras plataformas do mercado, ela se chama Parallel Sysplex."

Até aqui aprendemos dois conceitos fundamentais.

Na primeira parte entendemos por que a Resiliência existe.

Na segunda conhecemos a infraestrutura física que mantém o IBM Z funcionando.

Agora chegou a hora de conhecer a tecnologia que fez o Mainframe alcançar um nível de disponibilidade praticamente incomparável.

Ela atende pelo nome de Parallel Sysplex.

É ela que permite que vários computadores IBM Z trabalhem como se fossem um único sistema gigante.

Enquanto um servidor comum normalmente representa um único ponto de processamento, um ambiente Parallel Sysplex distribui usuários, aplicações, bancos de dados e transações entre diversos sistemas, mantendo tudo sincronizado quase em tempo real.

Os conceitos desta parte abrangem Monoplex, Base Sysplex, Parallel Sysplex, Coupling Facility (CF), z/OS Workload Manager (WLM), Sysplex Failure Management (SFM), Automatic Restart Manager (ARM), Dynamic Virtual IP Address (DVIPA), Sysplex Distributor e Load Balancing Advisor (LBA).

---

Quando Um Servidor Não É Suficiente

Imagine um supermercado.

Existe apenas um caixa.

Tudo funciona perfeitamente.

Até que chegam centenas de clientes.

Forma-se uma fila enorme.

O caixa quebra.

O supermercado para.

Agora imagine dez caixas.

Se um quebrar...

Os outros continuam atendendo.

O Parallel Sysplex segue exatamente essa filosofia.

Não existe apenas um computador.

Existem vários.

Todos trabalhando juntos.

---

Monoplex

Antes de conhecer o Parallel Sysplex, precisamos entender seu oposto.

O Monoplex.

Ele representa o ambiente clássico.

Existe apenas uma imagem do z/OS.

Um único sistema operacional.

Uma única máquina executando tudo.

Para ambientes pequenos isso pode ser suficiente.

Mas existe um problema.

Se esse sistema parar...

Toda a operação para junto.

Por isso Monoplex é excelente para laboratórios, ambientes de desenvolvimento e pequenas empresas.

Não para grandes bancos.

---

Base Sysplex

O próximo passo na evolução foi o Base Sysplex.

Agora vários sistemas z/OS conseguem conversar entre si.

Compartilham algumas informações.

Cooperam em determinadas atividades.

Mas ainda não executam todas as cargas de maneira integrada.

É como vários departamentos de uma empresa que já utilizam telefone interno.

Eles conseguem conversar.

Mas ainda trabalham de forma relativamente independente.

---

Parallel Sysplex

Agora chegamos ao coração da arquitetura IBM Z.

Imagine cinco grandes mainframes.

Cada um possui:

• processadores

• memória

• discos

• aplicações

• usuários

Para um administrador seriam cinco computadores.

Mas para o usuário...

Existe apenas um.

Esse é o verdadeiro poder do Parallel Sysplex.

Os sistemas compartilham informações críticas.

Distribuem carga automaticamente.

Mantêm consistência dos dados.

E continuam funcionando mesmo quando um dos sistemas deixa de operar.

É praticamente uma orquestra.

Cada músico toca seu instrumento.

Mas o público escuta apenas uma única música.

---

Coupling Facility (CF)

Surge então uma pergunta.

Como todos esses computadores conseguem permanecer sincronizados?

A resposta está na Coupling Facility.

Ela funciona como uma enorme central de coordenação.

Ali ficam estruturas compartilhadas utilizadas por todos os membros do Sysplex.

Entre elas:

• Lock Structures

• Cache Structures

• List Structures

Sempre que dois sistemas precisam garantir que um registro não seja alterado simultaneamente...

É a Coupling Facility quem organiza essa sincronização.

Sem ela...

O Parallel Sysplex simplesmente não existiria.

---

O Grande Maestro: Workload Manager (WLM)

Imagine um aeroporto.

Centenas de aviões.

Milhares de passageiros.

Dezenas de pistas.

Tudo precisa acontecer na ordem correta.

Quem coordena isso?

A torre de controle.

No IBM Z essa torre chama-se WLM.

O Workload Manager observa continuamente:

• utilização da CPU;

• tempo de resposta;

• prioridades;

• metas de negócio;

• disponibilidade dos recursos.

Em vez de distribuir processamento igualmente...

Ele distribui processamento de forma inteligente.

O objetivo não é justiça.

É atender o negócio.

Se um sistema PIX precisa responder em menos de meio segundo...

Ele receberá prioridade sobre um relatório Batch iniciado minutos antes.

---

WLM: Pensando Como o Negócio

É aqui que muitos Padawans mudam sua forma de pensar.

Eles imaginam que CPU pertence aos programas.

Na realidade...

CPU pertence ao negócio.

O WLM decide:

"Quem precisa mais agora?"

E reorganiza todo o ambiente automaticamente.

---

Sysplex Failure Management (SFM)

Falhas acontecem.

O importante é reagir rapidamente.

O SFM monitora continuamente todos os membros do Sysplex.

Se algum deles deixar de responder...

Ele toma decisões automáticas.

Entre elas:

• isolamento;

• retirada do sistema;

• proteção da integridade dos dados;

• coordenação da recuperação.

Tudo acontece em segundos.

Muitas vezes sem qualquer intervenção humana.

---

Automatic Restart Manager (ARM)

Agora imagine outra situação.

Uma aplicação falhou.

O servidor continua funcionando.

O que fazer?

Esperar um operador?

Não.

O ARM entra em ação.

Ele identifica que determinado serviço terminou inesperadamente.

Analisa as políticas definidas.

E reinicia automaticamente aquela aplicação.

O objetivo é reduzir o tempo de indisponibilidade.

Muitas vezes o usuário nem percebe que houve uma falha.

---

Dynamic Virtual IP Address (DVIPA)

Você acessa o Internet Banking.

Digita seu usuário.

Tudo funciona.

Enquanto isso...

O servidor responsável pelo atendimento pode mudar completamente.

Você não percebe.

Isso acontece graças ao DVIPA.

O endereço IP não pertence a um computador específico.

Ele pertence ao serviço.

Se um sistema sair do ar...

Outro assume imediatamente aquele endereço lógico.

Para o cliente...

Nada mudou.

---

Sysplex Distributor

Agora imagine milhares de conexões chegando ao mesmo tempo.

Quem decide qual servidor atenderá cada usuário?

O Sysplex Distributor.

Ele distribui as conexões entre os diversos membros do Sysplex.

Evita sobrecarga.

Melhora desempenho.

Aumenta disponibilidade.

É um balanceador de carga extremamente integrado ao z/OS.

---

Load Balancing Advisor (LBA)

Mas como o Sysplex Distributor sabe qual sistema está menos ocupado?

Ele pergunta ao LBA.

O Load Balancing Advisor coleta informações fornecidas pelo WLM.

Com base nessas métricas, recomenda para onde cada nova conexão deve ser direcionada.

Não basta existir vários servidores.

É preciso enviar cada usuário ao melhor deles.

---

Um Exemplo Bancário

Imagine um banco com quatro sistemas CICS.

Durante uma manhã de pagamento de salários, milhões de clientes acessam o aplicativo.

Nesse momento:

• O WLM identifica prioridades.

• O LBA mede a carga.

• O Sysplex Distributor envia novos acessos ao sistema menos ocupado.

• A Coupling Facility mantém os dados sincronizados.

• O SFM monitora a saúde dos membros.

• Se um ambiente falhar, o ARM reinicia serviços automaticamente.

• O DVIPA garante que os clientes continuem conectados.

Para quem está usando o celular...

Nada aconteceu.

Essa é a verdadeira magia do IBM Z.

---

Por Que Isso É Importante para um Programador COBOL?

Muitos desenvolvedores acreditam que Parallel Sysplex é assunto exclusivo de Sysprog.

Não é.

Quando você escreve uma aplicação COBOL para um ambiente CICS ou Batch, ela pode ser executada simultaneamente em diversos membros do Sysplex.

Isso significa que seu programa deve:

• evitar dependências locais;

• respeitar bloqueios de dados;

• compreender concorrência;

• tratar reinicializações corretamente;

• utilizar recursos compartilhados sempre que possível.

Quanto mais o desenvolvedor entende o ambiente onde sua aplicação será executada, mais robusto será o software produzido.

---

A Filosofia do Parallel Sysplex

Existe uma frase que resume toda essa tecnologia.

"No Parallel Sysplex, o usuário nunca deveria precisar saber qual computador está atendendo sua requisição."

Essa é uma ideia poderosa.

O cliente não acessa um servidor.

Ele acessa um serviço.

O serviço continua disponível independentemente de qual computador esteja processando a solicitação naquele instante.

É essa abstração que faz do IBM Z uma referência mundial em disponibilidade.

No próximo capítulo do Holocron da Resiliência IBM Z, entraremos no universo do DFSMS, Storage, System Logger, Capacity on Demand, CBU, CUoD, OOCoD e das tecnologias que permitem expandir recursos dinamicamente e proteger dados em ambientes corporativos de missão crítica.