 |
| Bellacosa Mainframe e a resiliencia em ibm z parte iv |
☕ Um Café no Bellacosa Mainframe
O Holocron da Resiliência IBM Z
Parte IV – Storage Inteligente e Capacity on Demand: Quando o IBM Z Cresce sem Parar o Negócio
"Para um Padawan, um disco é apenas um lugar para gravar dados. Para um Mestre Mainframe, o armazenamento é uma arquitetura viva, capaz de crescer, proteger informações e continuar funcionando mesmo quando partes dela falham."
Nas partes anteriores aprendemos os fundamentos da Resiliência, conhecemos a arquitetura física do IBM Z e descobrimos como o Parallel Sysplex faz diversos mainframes trabalharem como um único sistema.
Agora chegou a hora de conhecer outro pilar da disponibilidade.
O armazenamento.
Mas cuidado.
Quando falamos em Storage no IBM Z, não estamos falando apenas de discos.
Estamos falando de uma plataforma inteligente que gerencia dados, automatiza migrações, protege informações, compartilha recursos e até aumenta a capacidade do computador sob demanda.
Os conceitos desta parte incluem DFSMS, seus componentes (DFSMSdfp, DFSMSdss, DFSMShsm, DFSMSrmm, DFSMStvs), além de System Logger, Port Sharing, Capacity Backup (CBU), Customer Initiated Upgrade (CIU), Capacity Upgrade on Demand (CUoD), On/Off Capacity on Demand (OOCoD), e-business on Demand (eBoD) e os diferentes modelos de Clusters do IBM Z.
O Maior Patrimônio de Uma Empresa Não É o Computador
Imagine um banco.
Se um servidor quebrar...
Compra-se outro.
Se uma placa apresentar defeito...
Ela pode ser substituída.
Agora imagine perder todas as contas correntes.
Todos os financiamentos.
Todos os investimentos.
Todos os históricos de pagamento.
A empresa praticamente deixa de existir.
No IBM Z, o dado vale muito mais do que o equipamento.
Por isso existe uma infraestrutura gigantesca dedicada exclusivamente à administração dessas informações.
DFSMS – O Grande Administrador dos Dados
Muitos iniciantes acreditam que o sistema operacional controla sozinho todos os discos.
Na realidade existe um conjunto de serviços chamado DFSMS.
Ele funciona como um administrador extremamente organizado.
Enquanto o programador pensa apenas no dataset...
O DFSMS decide:
onde armazenar;
como proteger;
quando migrar;
quando fazer backup;
quando recuperar;
qual volume utilizar;
como otimizar espaço.
É praticamente um "gerente de condomínio" dos dados.
DFSMSdfp
O Data Facility Data Management é a base de todo o armazenamento.
Ele fornece os serviços fundamentais para:
Todo programa COBOL que abre um arquivo VSAM ou Sequential está utilizando recursos administrados por esse componente.
Mesmo sem perceber.
DFSMSdss
Imagine uma equipe especializada em mudanças.
Ela copia apartamentos inteiros.
Transporta móveis.
Replica documentos.
No IBM Z, esse papel pertence ao DFSMSdss.
Ele executa:
cópias;
migrações;
backups;
restaurações;
replicações.
Tudo com enorme eficiência.
É uma das ferramentas mais utilizadas durante migrações e recuperação de ambientes.
DFSMShsm
Nem todo arquivo precisa permanecer em discos de alta velocidade.
Alguns são utilizados diariamente.
Outros apenas uma vez por ano.
O Hierarchical Storage Manager resolve esse problema.
Ele movimenta automaticamente os dados entre diferentes níveis de armazenamento.
Arquivos pouco utilizados podem ser enviados para mídias mais econômicas.
Quando voltam a ser necessários...
São recuperados automaticamente.
O usuário muitas vezes nem percebe essa movimentação.
DFSMSrmm
Imagine uma biblioteca gigantesca.
Milhões de fitas.
Quem sabe exatamente onde cada uma está?
O Removable Media Manager.
Ele controla:
fitas;
cartuchos;
movimentações;
retenções;
empréstimos;
descarte.
Mesmo em plena era da nuvem, fitas continuam sendo extremamente importantes para backup corporativo.
DFSMStvs
Agora imagine uma aplicação Batch gravando dados em VSAM.
No meio da atualização...
Falta energia.
Como garantir que os registros não fiquem inconsistentes?
O Transactional VSAM Services resolve exatamente esse problema.
Ele adiciona características transacionais aos arquivos VSAM.
Muito parecido com aquilo que um banco de dados faz.
Para aplicações críticas, isso representa um enorme ganho de confiabilidade.
System Logger
Imagine dezenas de aplicações produzindo eventos ao mesmo tempo.
CICS.
IMS.
Db2.
MQ.
z/OS.
Quem organiza todos esses registros?
O System Logger.
Ele funciona como um grande repositório de logs compartilhados.
Esses registros são fundamentais para:
Sem logs consistentes...
Recuperar sistemas seria muito mais difícil.
Port Sharing
Outra característica interessante do IBM Z é o compartilhamento inteligente de portas de comunicação.
Em vez de cada aplicação monopolizar uma porta exclusiva...
Diversos serviços podem compartilhar recursos de forma controlada.
O resultado é:
Capacity on Demand – Crescendo Sem Comprar Outro Mainframe
Imagine um shopping.
No Natal chegam milhares de clientes.
Depois do Natal...
O movimento cai novamente.
Faz sentido construir outro shopping apenas para dezembro?
Claro que não.
No IBM Z acontece algo parecido.
Existem períodos de pico.
Fechamento contábil.
Pagamento de salários.
Black Friday.
Imposto de renda.
O sistema precisa crescer.
Mas apenas temporariamente.
É aí que entra o conceito de Capacity on Demand.
Capacity Backup (CBU)
Imagine que um datacenter inteiro seja perdido.
O ambiente de contingência assume toda a operação.
Mas agora ele precisa de muito mais processamento.
O CBU disponibiliza capacidade adicional justamente para essas situações de desastre.
O objetivo é garantir continuidade mesmo durante eventos extremos.
Customer Initiated Upgrade (CIU)
Em alguns casos, o próprio cliente pode ativar recursos previamente instalados no equipamento.
Sem trocar hardware.
Sem aguardar técnicos.
Sem desligar a máquina.
Isso reduz drasticamente o tempo necessário para expansão.
Capacity Upgrade on Demand (CUoD)
Imagine comprar um automóvel já preparado para ter mais potência.
Quando necessário...
Basta liberar eletronicamente os recursos.
É exatamente essa filosofia.
O hardware já possui capacidade instalada.
Ela apenas é ativada quando o negócio realmente precisa.
On/Off Capacity on Demand (OOCoD)
Agora imagine algo ainda mais inteligente.
A empresa utiliza capacidade extra apenas durante alguns dias.
Terminou o pico?
A capacidade adicional é desativada.
O cliente paga apenas pelo período utilizado.
É computação elástica muito antes da popularização da nuvem.
e-Business on Demand (eBoD)
Quando o comércio eletrônico começou a crescer rapidamente, surgiu um desafio.
Como atender milhões de acessos inesperados?
O eBoD foi criado justamente para permitir aumentos rápidos de capacidade durante eventos de grande demanda.
Hoje esse conceito continua influenciando a forma como grandes empresas planejam sua infraestrutura.
Os Diferentes Tipos de Cluster
O IBM Z também trabalha com diferentes arquiteturas de agrupamento.
Virtual Cluster
Recursos compartilhados virtualmente.
Grande flexibilidade.
Melhor utilização da infraestrutura.
Horizontal Cluster
Mais servidores trabalhando juntos.
Ideal para crescimento contínuo.
Quanto maior a demanda...
Mais membros podem ser adicionados.
Mixed Cluster
Combina diferentes gerações de hardware.
Permite evolução gradual do ambiente sem necessidade de substituição completa.
Dynamic Cluster
Talvez o mais interessante.
Os recursos podem ser reorganizados dinamicamente conforme a necessidade do negócio.
É uma infraestrutura que se adapta continuamente às mudanças da carga de trabalho.
O Que Tudo Isso Significa Para um Programador COBOL?
À primeira vista, DFSMS, Capacity on Demand e Storage parecem assuntos exclusivos da infraestrutura.
Mas não são.
Quando um programa COBOL grava um arquivo VSAM, acessa um dataset sequencial ou consulta uma base Db2, ele depende diretamente dessa arquitetura.
Compreender esses componentes ajuda o desenvolvedor a:
escrever aplicações mais eficientes;
evitar acessos desnecessários ao armazenamento;
entender políticas de backup e recuperação;
compreender tempos de resposta;
projetar soluções escaláveis.
O código continua sendo importante.
Mas o ambiente onde ele executa é igualmente decisivo.
A Filosofia do IBM Z
Existe uma característica que diferencia profundamente o IBM Z de muitas outras plataformas.
Enquanto em diversos ambientes a expansão costuma significar comprar novos servidores, instalar sistemas operacionais e redistribuir aplicações, no IBM Z o crescimento frequentemente acontece de forma transparente.
A infraestrutura foi concebida para evoluir junto com o negócio.
Mais usuários.
Mais processamento.
Mais armazenamento.
Mais disponibilidade.
Tudo isso sem interromper as operações críticas.
Esse é um dos motivos pelos quais bancos, seguradoras, empresas de telecomunicações e governos continuam confiando seus dados mais importantes ao IBM Z.
No próximo capítulo do Holocron da Resiliência IBM Z, exploraremos como CICS, Db2, MQ e IMS utilizam toda essa infraestrutura para construir aplicações altamente disponíveis, distribuídas e preparadas para processar milhões de transações por dia.
