Translate

Mostrar mensagens com a etiqueta virtualização. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta virtualização. Mostrar todas as mensagens

quarta-feira, 25 de março de 2026

☁️ Da Sala Gelada do Mainframe à Nuvem Elástica: O Guia Jedi de Cloud para Padawans que Vieram do Ferro Pesado

 

Bellacosa Mainframe comenta sobre Data Cente CPD e Mainframe

☁️ Da Sala Gelada do Mainframe à Nuvem Elástica: O Guia Jedi de Cloud para Padawans que Vieram do Ferro Pesado

“A Força não está no hardware… está na abstração.”

Se você cresceu ouvindo o zumbido de um data center, viu consoles verdes brilharem no escuro e acha que “downtime” é palavrão — bem-vindo, Padawan. 🧙‍♂️

Hoje vamos atravessar o hiper-espaço da TI: do mainframe on-premises para o multiverso da Cloud Computing — sem perder a sanidade, a disciplina operacional nem o amor pelo controle absoluto.

Este não é um tutorial raso. É um mapa estelar.


🏗️ Antes da Nuvem: O Império do Ferro

No modelo tradicional:

  • Você comprava o hardware
  • Instalava tudo
  • Mantinha equipe 24x7
  • Planejava capacidade para o pior caso
  • Rezava para o orçamento sobreviver

Era como construir a Estrela da Morte para hospedar um site institucional.

💡 Curiosidade Bellacosa:
Mainframes já faziam virtualização quando a cloud ainda usava fraldas. VM/370 (1972) mandou lembranças.


☁️ A Virada: Infraestrutura como Serviço (IaaS)

IaaS é o primeiro portal dimensional.

Você não compra mais servidores — você invoca instâncias.

O provedor cuida de:

  • Hardware
  • Energia
  • Refrigeração
  • Virtualização

Você cuida de:

  • Sistema operacional
  • Aplicações
  • Dados
  • Segurança do software

👉 Tradução para o mainframeiro:

IaaS é como ganhar um LPAR sob demanda… sem comprar o CPC.


🧪 PaaS e SaaS: Quanto mais alto, menos dor de cabeça

🧪 PaaS — “Só traga seu código”

Perfeito para construir aplicações sem montar infraestrutura.

📦 SaaS — “Só use”

Software pronto no navegador.

💡 Exemplo prático:

  • IaaS → montar servidor DB2 virtual
  • PaaS → subir API REST
  • SaaS → usar sistema de CRM online

📦 Containers e Serverless: O lado ninja da Força

Containers (CaaS)

  • Leves
  • Portáveis
  • Escaláveis
  • Compartilham o kernel

👉 Pense em JOBs isolados rodando no mesmo sistema.

FaaS / Serverless

Código executa sob demanda e desaparece.

Como um programa batch que só existe enquanto roda… e você só paga por esse tempo.


🌍 Modelos de Implantação: Onde a Força Reside

🌐 Public Cloud — A galáxia compartilhada

Características:

  • Multi-tenant
  • Baixo custo inicial
  • Escala absurda
  • Acesso pela internet

⭐ Ideal para startups e workloads variáveis.


🏢 Private Cloud — Seu próprio Templo Jedi

Características:

  • Infraestrutura dedicada
  • Controle máximo
  • Compliance facilitado
  • Alto custo

⭐ Bancos, governo, saúde — a tríade da cautela.


🔀 Hybrid Cloud — O melhor dos dois mundos

Private + Public trabalhando juntos.

Usos clássicos:

  • Backup na nuvem
  • Disaster recovery
  • Cloud bursting
  • Migração gradual

👉 É o modelo dominante nas grandes corporações.


🌐 Multicloud — Não confie em um único Império

Múltiplos provedores simultaneamente.

Motivos:

  • Evitar lock-in
  • Alta resiliência
  • Escolher o melhor serviço de cada um

💡 Muitas empresas usam Hybrid + Multicloud ao mesmo tempo.


🤝 Community Cloud — A aliança rebelde

Compartilhada por organizações com necessidades comuns:

  • Governo
  • Saúde
  • Educação
  • ONGs

Objetivo: custo compartilhado + compliance setorial.


⚡ Caso real: Por que startups amam Public Cloud

Imagine um Padawan empreendedor criando um sistema de compartilhamento de arquivos.

Sem cloud:

  • Comprar servidores
  • Contratar equipe
  • Dimensionar para milhões (ou falhar)

Com cloud:

👉 Lançar hoje
👉 Escalar amanhã
👉 Pagar só quando crescer

Muitos unicórnios começaram assim.


🛟 Hybrid na prática: Disaster Recovery Jedi

Empresa roda sistemas críticos on-premises.

Backup e réplica ficam na nuvem pública.

Se o data center cair:

👉 Failover automático
👉 Continuidade do negócio
👉 Sem construir um segundo data center


🧠 Easter Eggs para quem veio do Mainframe

  • Virtualização não nasceu na cloud
  • Autoscaling lembra WLM turbinado
  • Cloud bursting ≈ adicionar MIPS temporários
  • Object Storage ≈ datasets gigantes sem JCL
  • Serverless ≈ JOB que cobra por CPU time real

🧭 Guia rápido para escolher o modelo certo

SituaçãoMelhor opção
StartupPublic
BancoPrivate ou Hybrid
Grande corporaçãoHybrid + Multicloud
Órgãos governamentaisPrivate ou Community
Workload sazonalHybrid

🌌 Conclusão: A Força da Abstração

A cloud não substitui o conhecimento de infraestrutura — ela o amplifica.

O verdadeiro poder não é possuir servidores.
É poder invocá-los… e dispensá-los… quando quiser.

Para o Padawan vindo do mainframe, a nuvem não é uma ameaça.

É apenas:

👉 um data center que atravessou o hiper-espaço.

sexta-feira, 27 de setembro de 2024

Hypervisor no Mainframe sem Mistérios

 

Bellacosa Mainframe e o hypervisor no mainframe sem misterios

☕ Um Café no Bellacosa Mainframe

Hypervisor no Mainframe sem Mistérios

Como um IBM Z Executa Centenas de Servidores ao Mesmo Tempo — O Guia Definitivo para o Programador COBOL Padawan Inspirado em Star Trek

"A lógica é o começo da sabedoria, não o fim."

— Sr. Spock


Introdução — A Grande Ilusão da Computação

Imagine entrar na ponte da USS Enterprise.

O Capitão Kirk acredita que possui uma nave inteira à sua disposição.

O engenheiro Scotty controla motores, energia e sistemas.

O Dr. McCoy utiliza computadores médicos.

Spock executa simulações científicas.

Cada um acredita possuir recursos exclusivos.

Mas existe apenas uma única nave.

O segredo é que existe um sistema extremamente inteligente distribuindo recursos para todos ao mesmo tempo.

No IBM Z acontece exatamente isso.

Para um programador COBOL iniciante, isso pode parecer magia.

Na realidade, trata-se de uma das maiores invenções da história da computação:

o Hypervisor.

E a parte curiosa?

O mainframe fazia isso quando o restante do mundo ainda estava tentando descobrir como compartilhar um computador entre vários usuários.


Antes de tudo...

Muita gente pensa que virtualização nasceu com VMware.

Spoiler...

Não nasceu.

A IBM já fazia virtualização completa décadas antes da Internet existir.

Quando o primeiro PC da IBM apareceu em 1981, os mainframes já executavam dezenas de sistemas operacionais simultaneamente.

Isso muda completamente a perspectiva histórica.


O que é um Hypervisor?

A definição técnica é simples.

Um Hypervisor é um software (ou firmware especializado) responsável por criar computadores virtuais.

Cada computador virtual recebe:

  • memória

  • CPUs

  • discos

  • placas de rede

  • dispositivos

  • acesso ao hardware

Tudo isso sem possuir fisicamente esses equipamentos.

Para o sistema operacional convidado (Guest OS), parece existir um computador inteiro.

Na verdade...

Ele está dividindo recursos com centenas de outros sistemas.


Uma analogia Bellacosa

Imagine um enorme prédio comercial.

Existe:

  • uma única estrutura

  • um único elevador

  • uma única instalação elétrica

  • um único sistema hidráulico

Mas existem centenas de empresas trabalhando ali.

Cada empresa acredita possuir seu próprio escritório.

Quem administra tudo?

O síndico.

No mundo da computação...

O síndico chama-se Hypervisor.


O problema que ele resolve

Nos anos 60 um computador custava milhões de dólares.

Não fazia sentido deixá-lo executando apenas um sistema.

Era desperdício.

A IBM percebeu isso rapidamente.

A ideia era simples:

"Se o computador é poderoso, por que não criar vários computadores dentro dele?"

Nascia a virtualização.


A origem histórica

Voltamos para 1964.

IBM System/360.

Era revolucionário.

Mas ainda executava apenas um sistema operacional por vez.

Logo depois veio o projeto:

CP-40

Depois:

CP-67

Esses projetos deram origem ao:

VM/370

E praticamente toda a indústria copiou essa ideia décadas depois.

Curiosamente...

A palavra "Virtual Machine" já era usada pela IBM muito antes do VMware existir.


Linha do tempo

1964

System/360

1967

CP-40

1968

CP-67

1972

VM/370

1988

PR/SM

1990

LPAR

2000+

z/VM

Hoje

IBM z16

IBM z17

Linux

z/OS

z/VM

KVM

Todos convivendo na mesma máquina.


O nascimento das Máquinas Virtuais

Imagine possuir um computador enorme.

O Hypervisor cria:

Computador A

Computador B

Computador C

Computador D

Todos são imaginários.

Mas funcionam como computadores reais.

Cada um pode instalar:

  • Linux

  • z/OS

  • z/VM

  • z/VSE

  • z/TPF

Sem interferir uns nos outros.


Como isso funciona?

O Hypervisor controla quatro grandes recursos.

CPU

Quando um sistema precisa processar algo...

Ele pede CPU.

O Hypervisor responde:

"Espere sua vez."

Em microssegundos ele alterna entre centenas de sistemas.

Para cada sistema parece possuir uma CPU exclusiva.


Memória

O mesmo acontece com RAM.

Cada máquina virtual acredita possuir memória exclusiva.

Na realidade...

Toda memória é compartilhada cuidadosamente.


Disco

Cada sistema possui seus próprios discos.

Mas muitas vezes esses discos são apenas áreas reservadas dentro de grandes volumes físicos.


Rede

Cada servidor virtual possui placas de rede.

Elas também podem ser totalmente virtuais.

O Hypervisor conecta tudo internamente.

Sem sequer sair do equipamento.


Parece mágica?

Não.

É matemática.

E engenharia.

Muita engenharia.


Hypervisor Tipo 1

Existem dois tipos.

O mais poderoso é:

Bare Metal.

Ou:

Tipo 1.

Ele roda diretamente sobre o hardware.

Sem Windows.

Sem Linux.

Sem intermediários.

É exatamente o caso do IBM Z.


Hypervisor Tipo 2

Neste caso existe um sistema operacional.

Windows

VMware Workstation

Máquinas Virtuais

O desempenho é menor.


No IBM Z é diferente

Hardware

Firmware

PR/SM

LPARs

z/VM

Linux

Aplicações

Existe uma enorme hierarquia.

Cada camada aumenta a flexibilidade.


PR/SM

Aqui mora um dos segredos do mainframe.

PR/SM significa:

Processor Resource/System Manager.

Ele é considerado um Hypervisor de nível extremamente baixo.

Na prática...

Ele divide o computador físico em diversas LPARs.


O que é uma LPAR?

Significa:

Logical Partition.

É praticamente um computador inteiro.

Pode possuir:

12 CPUs

64 GB RAM

20 discos

10 interfaces de rede

Enquanto outra LPAR possui recursos completamente diferentes.


Imagine uma pizza

Uma pizza inteira representa o IBM Z.

Você corta em:

4 fatias.

Cada fatia torna-se uma LPAR.

Cada LPAR acredita possuir sua própria pizza.

Mesmo pertencendo à mesma pizza original.


E depois entra o z/VM

Agora vem a parte divertida.

Dentro de uma LPAR...

Pode existir outro Hypervisor.

Esse Hypervisor chama-se:

z/VM.

Agora temos:

IBM Z

LPAR

z/VM

500 máquinas Linux

Containers

Aplicações

Sim.

Virtualização dentro da virtualização.

É como um espelho refletindo outro espelho.


Star Trek explica isso muito bem

Lembra do Holodeck?

O Holodeck cria ambientes completos.

Cada personagem acredita estar vivendo num mundo real.

Mas tudo acontece dentro da Enterprise.

O Hypervisor faz exatamente isso.

Cada sistema operacional acredita possuir um computador físico.

Na realidade...

Está dentro do "Holodeck" do IBM Z.


Por que isso é tão importante?

Porque aumenta:

  • utilização

  • segurança

  • disponibilidade

  • economia

  • flexibilidade


Segurança

Cada máquina virtual fica isolada.

Se uma apresentar problema...

As demais continuam funcionando.

É como compartimentos estanques de uma nave estelar.

Uma explosão na Engenharia não destrói a ponte.


Alta disponibilidade

Imagine atualizar um Linux.

Os outros continuam funcionando.

Atualizar uma aplicação.

As demais continuam.

Trocar memória.

Trocar CPU.

Adicionar discos.

Tudo quase sem impacto.


Eficiência absurda

Um servidor x86 costuma operar entre:

15%

30%

de utilização.

Um IBM Z frequentemente trabalha entre:

80%

95%

de utilização.

Sem perda significativa de desempenho.

Esse é um dos grandes diferenciais do mainframe.


Compartilhamento Inteligente

O Hypervisor conhece prioridades.

Um banco pode receber mais CPU.

Uma aplicação de testes recebe menos.

Tudo automático.


Dynamic Resource Allocation

Outro recurso fantástico.

É possível aumentar CPUs.

Adicionar memória.

Modificar prioridades.

Tudo enquanto o sistema continua funcionando.

Sem reboot.

Isso impressiona até hoje.


Como isso afeta um programador COBOL?

Muito mais do que parece.

Seu programa roda dentro de:

COBOL

LE Runtime

z/OS

LPAR

PR/SM

Hardware

Você raramente percebe.

Mas o Hypervisor trabalha silenciosamente por trás.


Quando um COBOL executa

Imagine um programa de folha de pagamento.

Ele solicita CPU.

O z/OS solicita recursos.

O PR/SM entrega processadores.

Tudo acontece em microssegundos.

Você nunca percebe.

Mas existe um verdadeiro maestro coordenando toda essa orquestra.


O que acontece se houver excesso de carga?

O Hypervisor redistribui recursos.

Algumas LPARs recebem mais CPU.

Outras esperam alguns microssegundos.

Tudo automaticamente.


Curiosidade impressionante

Um único IBM Z pode executar milhares de máquinas virtuais Linux.

Tudo dentro do mesmo equipamento.

Consumindo menos energia que centenas de servidores distribuídos.

É por isso que grandes bancos continuam investindo em mainframe.


Easter Egg nº 1

A expressão Virtual Machine ficou famosa nos PCs.

Mas ela nasceu dentro da IBM.

Décadas antes.


Easter Egg nº 2

O VMware foi fundado apenas em 1998.

O VM/370 existia desde 1972.

Mais de 25 anos antes.


Easter Egg nº 3

A maioria dos administradores VMware nunca imaginou que muitos conceitos modernos foram herdados direta ou indiretamente dos laboratórios da IBM.


Easter Egg nº 4

O PR/SM possui certificação de isolamento extremamente rigorosa (EAL5+ em avaliações Common Criteria para determinadas configurações), permitindo que workloads de diferentes níveis de confiança coexistam com forte separação lógica. Isso é um dos motivos pelos quais governos e grandes instituições financeiras confiam na plataforma.


Dicas para o Padawan COBOL

✔ Nunca pense que seu programa "está sozinho".

Sempre existe uma camada abaixo dele.


✔ Aprenda o conceito de LPAR.

Você verá esse termo praticamente todos os dias.


✔ Entenda o z/VM.

Mesmo trabalhando apenas com COBOL.

Ele aparece frequentemente em ambientes Linux on Z.


✔ Estude PR/SM.

Poucos desenvolvedores conhecem.

Mas quem entende virtualização compreende muito melhor o IBM Z.


✔ Não confunda LPAR com Máquina Virtual.

LPAR é uma partição lógica criada diretamente pelo PR/SM. Dentro de uma LPAR, o z/VM pode criar centenas ou milhares de máquinas virtuais.


Comparação rápida

Universo Star TrekIBM Z
USS EnterpriseHardware físico
HolodeckHypervisor
Ponte de ComandoLPAR
Simulações do HolodeckMáquinas Virtuais
ScottyAdministrador do sistema
SpockWLM e gerenciamento inteligente de recursos
Computador da navePR/SM + z/VM

Lições aprendidas

Existe um mito de que virtualização é uma tecnologia moderna.

Na realidade, ela nasceu no mundo dos mainframes.

O IBM Z não apenas executa programas COBOL. Ele hospeda diversos sistemas operacionais, milhares de aplicações e enormes ambientes Linux com isolamento, segurança e desempenho excepcionais. O hypervisor — especialmente o PR/SM, complementado pelo z/VM quando necessário — é o grande responsável por essa façanha.

Quando um programador COBOL envia um JOB pelo JCL, acessa Db2, CICS ou IMS, dificilmente percebe que há uma sofisticada infraestrutura distribuindo CPUs, memória, dispositivos e redes em tempo real. Assim como a tripulação da Enterprise confia que a nave responderá a cada comando, o desenvolvedor confia que o IBM Z entregará recursos quando forem necessários.

E talvez essa seja a maior lição do universo de Star Trek aplicada ao mainframe: a tecnologia mais extraordinária é aquela que trabalha tão bem que quase se torna invisível. O hypervisor é esse "oficial silencioso" da nave. Ele não aparece na tela 3270, não compila programas COBOL e não executa SQL, mas sem ele grande parte da eficiência, da disponibilidade e da confiabilidade que tornaram o IBM Z uma referência mundial simplesmente não existiria.

Como diria o Sr. Spock:

"A eficiência não está em possuir mais recursos, mas em utilizá-los com inteligência."

Essa frase resume perfeitamente a filosofia do hypervisor no IBM Z: transformar um único computador físico em uma verdadeira frota de computadores virtuais, trabalhando em perfeita harmonia há mais de cinco décadas.


quinta-feira, 16 de dezembro de 2021

Da USS Enterprise aos Containers: O Guia Definitivo do Programador COBOL Padawan para Entender Docker, DevOps e Cloud Computing

 

Bellacosa Mainframe e o docker sem misterios

☕ Um Café no Bellacosa Mainframe

🐳 Docker sem Mistérios

Da USS Enterprise aos Containers: O Guia Definitivo do Programador COBOL Padawan para Entender Docker, DevOps e Cloud Computing

"A lógica é o começo da sabedoria, não o fim."

Sr. Spock


Introdução — Bem-vindo à Sala de Teletransporte

Imagine que você acaba de embarcar na USS Enterprise.

Você é um jovem oficial recém-saído da Academia da Frota Estelar.

Seu trabalho é manter os computadores da nave funcionando.

No entanto...

A Enterprise não possui apenas um computador.

Ela possui centenas.

Existem computadores para:

  • Controle de navegação

  • Motores de Dobra

  • Sensores

  • Transporte

  • Comunicações

  • Holodeck

  • Engenharia

  • Laboratórios científicos

Todos precisam funcionar simultaneamente.

Mas imagine se, para executar um simples software de navegação, fosse necessário construir uma Enterprise inteira.

Foi exatamente assim que a computação funcionou durante décadas.

Cada aplicação precisava praticamente de um servidor inteiro.

Era desperdício.

Foi então que surgiu uma ideia revolucionária.

"E se pudéssemos empacotar apenas a aplicação e tudo aquilo que ela realmente precisa?"

Nasciam os containers.

E alguns anos depois...

O mundo conheceria uma pequena baleia azul chamada Docker.

Hoje, Docker é um dos pilares de DevOps, Cloud Computing, CI/CD, Kubernetes e da computação moderna.

Neste Café no Bellacosa Mainframe vamos entender absolutamente tudo, especialmente para quem vem do universo COBOL, JCL, CICS, Db2 e IBM Z.

Prepare seu café.

O computador da Enterprise já iniciou o boot.


Capítulo 1 — Antes do Docker

Durante muitos anos instalar software era um verdadeiro ritual.

Imagine um servidor Linux.

Você precisava instalar:

  • Java

  • Python

  • NodeJS

  • Apache

  • Bibliotecas

  • Drivers

  • Dependências

Depois disso...

Rezava para tudo funcionar.

Se alguém atualizasse uma biblioteca...

Seu programa quebrava.

Era comum ouvir:

"Na minha máquina funciona."

Essa frase virou praticamente uma piada mundial.

O problema não era o código.

Era o ambiente.


Capítulo 2 — O Grande Problema

Imagine três aplicações.

Sistema A

Java 8

Sistema B

Java 17

Sistema C

Java 21

Todos no mesmo servidor.

Cada uma exige versões diferentes.

Resultado?

Conflitos.

Muito parecidos com programas COBOL compilados com runtimes incompatíveis.

No IBM Z isso sempre foi tratado com enorme cuidado.

No mundo distribuído...

Era um caos.


Capítulo 3 — A Solução Chamada Container

Container significa isolamento.

Cada aplicação leva consigo:

  • bibliotecas

  • dependências

  • configuração

  • runtime

Tudo empacotado.

Sem interferir nas demais.

É como colocar cada programa em sua própria cabine da Enterprise.

Todos dividem a nave.

Mas ninguém invade o espaço do outro.


Capítulo 4 — Máquina Virtual x Container

Durante anos usamos máquinas virtuais.

Servidor

↓

Hypervisor

↓

Windows

↓

Aplicação

Docker mudou completamente.

Servidor

↓

Linux

↓

Docker Engine

↓

Containers

Não existe outro sistema operacional inteiro.

Existe apenas:

  • processo

  • isolamento

  • filesystem

Resultado?

Inicialização em segundos.

Pouca memória.

Baixíssimo consumo.


Curiosidade

O kernel Linux enxerga um container apenas como um processo.

Nada mais.

Esse é um dos maiores segredos do Docker.


Capítulo 5 — O Docker Engine

O Docker Engine é o capitão da nave.

Ele administra:

  • containers

  • imagens

  • volumes

  • redes

  • armazenamento

  • execução

Sem ele...

Nada acontece.


Capítulo 6 — Dockerfile

O Dockerfile é uma receita culinária.

Exemplo:

FROM ubuntu

RUN apt update

RUN apt install python3

COPY app.py .

CMD ["python3","app.py"]

Ele diz exatamente como montar a aplicação.

No mundo Mainframe ele lembra bastante:

  • PROC JCL

  • CLIST

  • REXX

  • Script SMP/E

  • Job de instalação


Capítulo 7 — O Processo Completo

Tudo segue uma sequência lógica.

Dockerfile

↓

docker build

↓

Imagem

↓

docker run

↓

Container

Jamais confunda.

Dockerfile não executa.

Imagem não executa.

Quem executa é o container.


Capítulo 8 — O Mistério das Imagens

Imagem é um template.

Ela é imutável.

Pense em:

  • ISO

  • Backup

  • Snapshot

  • Golden Image

Você cria uma única imagem.

Depois gera cem containers.

Todos iguais.

Essa repetibilidade é um dos grandes segredos do DevOps.


Capítulo 9 — docker build

docker build -t web .

Significa:

Construa uma imagem usando o Dockerfile localizado no diretório atual.

"-t"

significa Tag.

Exemplo:

bellacosa/site:v1

Capítulo 10 — docker images

Lista todas as imagens.

docker images

Saída típica:

REPOSITORY

TAG

IMAGE ID

SIZE

Pense nisso como um catálogo de módulos carregáveis.


Capítulo 11 — docker pull

O Docker Hub funciona como uma biblioteca mundial.

docker pull nginx

Baixa uma imagem pronta.

Sem instalar manualmente.

Sem configurar dependências.

Sem sofrimento.


Curiosidade

O Docker Hub possui milhões de imagens.

Mas...

Nem todas são oficiais.

Sempre prefira imagens verificadas.


Capítulo 12 — docker run

Provavelmente o comando mais famoso.

docker run nginx

Ele cria:

Imagem

Container

Nunca altera a imagem.


Principais parâmetros

-d

Modo background.

docker run -d nginx

Muito parecido com iniciar um Started Task no z/OS.


-p

Mapeamento de portas.

-p 8080:80

Host

8080

Container

80


--name

docker run --name web nginx

Muito melhor que decorar IDs enormes.


-e

Variáveis de ambiente.

-e DB_USER=admin

-v

Volumes.

-v dados:/var/lib/mysql

Sem volumes...

Os dados desaparecem ao remover o container.


Capítulo 13 — docker ps

docker ps

Lista apenas containers ativos.

Muito parecido com observar tarefas em execução no ambiente operacional.


docker ps -a

Mostra também:

  • encerrados

  • falhados

  • pausados

É excelente para troubleshooting.


Capítulo 14 — docker logs

Todo administrador aprende isso rapidamente.

Quando algo falha...

Primeiro comando:

docker logs

É equivalente ao programador COBOL abrir imediatamente:

  • JESMSGLG

  • JESJCL

  • SYSOUT

  • CEEDUMP

  • SDSF

Os logs contam a história do que aconteceu.


Capítulo 15 — docker exec

docker exec -it web bash

Agora você entra literalmente dentro do container.

Como abrir um terminal remoto exclusivo daquele ambiente.

Muito útil para:

  • investigar arquivos

  • executar comandos

  • validar configurações


Capítulo 16 — docker stop

Encerra um container.

Primeiro envia um SIGTERM.

Dá tempo para o programa finalizar corretamente.

Caso ignore...

Recebe SIGKILL.

Muito semelhante a uma finalização controlada antes de um cancelamento forçado.


Capítulo 17 — docker rm

Remove containers.

Mas apenas se estiverem parados.

Fluxo típico:

docker stop web

docker rm web

Capítulo 18 — docker rmi

Remove imagens.

docker rmi nginx

Só funciona se ninguém estiver usando aquela imagem.


Capítulo 19 — docker system prune

O famoso botão vermelho.

docker system prune -a

Remove:

  • cache

  • containers

  • imagens

  • redes não utilizadas

  • artefatos temporários

Libera dezenas de gigabytes.

Mas...

Muito cuidado.


Capítulo 20 — Comandos que Todo Profissional Usa

docker inspect

Mostra praticamente tudo.

IPs.

Volumes.

Redes.

JSON completo.


docker stats

Monitoramento em tempo real.

CPU

RAM

Rede

Disco

É semelhante a consultar métricas de desempenho em ferramentas de monitoramento corporativas.


docker top

Lista processos internos.


docker cp

Copia arquivos.

Host

Container

Container

Host


docker restart

Reinicia.


docker start

Liga novamente um container parado.


docker pause

Congela processos.


docker unpause

Retoma execução.


docker network ls

Lista redes.


docker volume ls

Lista volumes persistentes.


docker history

Mostra todas as camadas da imagem.

Excelente para otimização.


Capítulo 21 — Como Docker Funciona Internamente

Pouca gente sabe...

Mas um container não é uma máquina virtual.

Ele utiliza recursos do próprio kernel Linux, como:

  • Namespaces

  • Control Groups (cgroups)

  • OverlayFS

  • Union File Systems

Essas tecnologias isolam processos, redes, usuários e sistemas de arquivos sem a necessidade de um sistema operacional completo por container.

É por isso que containers iniciam em poucos segundos e consomem muito menos memória que VMs tradicionais.


Capítulo 22 — Docker e DevOps

Docker revolucionou o DevOps porque eliminou um dos maiores problemas da engenharia de software: ambientes inconsistentes.

Hoje é possível:

  • Desenvolver localmente.

  • Testar em homologação.

  • Implantar em produção.

Tudo usando exatamente a mesma imagem.

Isso torna pipelines de CI/CD previsíveis e reproduzíveis.


Capítulo 23 — Docker no Mundo Mainframe

Você pode pensar:

"Mas eu trabalho com COBOL no IBM Z. O que Docker tem a ver comigo?"

A resposta é: muito.

Mesmo que aplicações COBOL rodem diretamente no z/OS, Docker é amplamente utilizado para hospedar ferramentas que fazem parte do ecossistema de desenvolvimento moderno:

  • Jenkins para automação de builds e deploys.

  • SonarQube para análise estática de código.

  • GitLab e Gitea para repositórios Git.

  • Nexus e Artifactory para gerenciamento de artefatos.

  • Bancos PostgreSQL, MariaDB e MongoDB para aplicações satélite.

  • Ambientes de testes para APIs REST que consomem serviços do z/OS Connect EE.

  • Ferramentas como Zowe CLI, Ansible e utilitários DevOps.

Assim, Docker não substitui o mainframe: ele o complementa, oferecendo um ecossistema ágil ao redor do IBM Z.


Boas Práticas

  • Use imagens oficiais sempre que possível.

  • Evite executar containers como usuário root.

  • Versione seus Dockerfiles junto com o código-fonte.

  • Utilize tags específicas (nginx:1.28) em vez de latest para garantir previsibilidade.

  • Mantenha imagens pequenas, removendo dependências temporárias.

  • Faça limpeza periódica de recursos não utilizados com cautela.


Curiosidades

  • O mascote do Docker chama-se Moby Dock, uma baleia carregando contêineres.

  • Docker foi lançado em 2013 pela empresa dotCloud.

  • O formato de imagens e containers inspirou o padrão aberto OCI (Open Container Initiative).

  • Embora muita gente diga que "Kubernetes usa Docker", atualmente o Kubernetes conversa com runtimes compatíveis com OCI, como containerd e CRI-O, mantendo compatibilidade com imagens Docker.

  • Muitas distribuições Linux modernas já trazem ferramentas de containers integradas, mostrando como esse modelo se tornou um padrão da indústria.


Easter Egg Bellacosa Mainframe

No universo de Star Trek, o computador da USS Enterprise isola centenas de subsistemas críticos — navegação, comunicações, sensores, suporte de vida e controle dos motores de dobra — para que uma falha em um deles não comprometa toda a nave.

Os containers seguem exatamente essa filosofia: cada aplicação roda em um ambiente isolado, compartilhando apenas os recursos essenciais do sistema operacional. Se um serviço apresentar problemas, os demais continuam operando normalmente.

Essa ideia também ecoa no IBM Z. Assim como LPARs, z/VM e mecanismos de isolamento permitem executar múltiplas cargas de trabalho com segurança e eficiência, os containers oferecem isolamento leve e portabilidade para aplicações modernas.

Missão do Padawan COBOL: quando você entender que Docker não é apenas um conjunto de comandos, mas uma forma diferente de pensar a infraestrutura, terá dado um importante salto rumo ao universo de DevOps. Afinal, tecnologias mudam, ferramentas evoluem, mas os princípios de isolamento, automação, repetibilidade e confiabilidade permanecem — exatamente como ensinaria o Sr. Spock na ponte da Enterprise. 🚀

sexta-feira, 24 de maio de 2019

Do CPD ao Data Center

 

Bellacosa Mainframe do cpd ao data center


☕ Um Café no Bellacosa Mainframe

Do CPD ao Data Center

A Jornada da Computação Corporativa — O que Todo Programador COBOL Padawan Precisa Saber Sobre a Evolução dos Grandes Templos da Tecnologia

"O nome mudou. Os equipamentos mudaram. A velocidade mudou. Mas a missão continua exatamente a mesma: manter os dados vivos."


Introdução

Existe uma expressão que praticamente desapareceu do vocabulário dos profissionais mais jovens da informática.

CPD.

Quem começou a trabalhar na década de 70, 80 ou 90 dificilmente esquece essa sigla.

Era comum ouvir frases como:

"Vou até o CPD."

"O pessoal do CPD resolveu."

"O programa está parado no CPD."

Hoje quase ninguém fala isso.

O termo da moda virou Data Center.

Mas será que eles são exatamente a mesma coisa?

A resposta é não.

Embora ambos representem ambientes responsáveis pelo processamento das informações de uma empresa, existe uma enorme evolução tecnológica, organizacional e cultural entre um antigo CPD e um moderno Data Center.

Para um Programador COBOL Padawan entender isso é extremamente importante.

Porque o COBOL nasceu dentro dos CPDs.

E continua vivo dentro dos maiores Data Centers do planeta.

Vamos viajar por quase oitenta anos de história.


Antes do CPD

Voltemos aos anos 1940.

Os computadores daquela época eram monstruosos.

ENIAC.

UNIVAC.

IBM 701.

IBM 650.

Eles ocupavam salas inteiras.

Consumiam centenas de quilowatts.

Geravam muito calor.

Exigiam operadores especializados.

Não existia computador pessoal.

Computador era patrimônio nacional.

Somente governos, universidades e grandes empresas possuíam um.

Naquela época nem existia a expressão "Data Center".

Havia simplesmente:

Computer Room

ou

Machine Room

Ou seja:

Sala das Máquinas.


A origem do termo CPD

Quando os computadores começaram a ser usados comercialmente nos anos 60 e 70, surgiu a necessidade de criar departamentos exclusivos para cuidar deles.

No Brasil adotou-se a tradução:

Centro de Processamento de Dados

(CPD)

A palavra centro era importante.

Porque o computador era literalmente o centro de toda a empresa.

Todos os departamentos dependiam dele.

RH.

Financeiro.

Contabilidade.

Produção.

Estoque.

Folha de pagamento.

Tudo passava pelo CPD.


O que significava um CPD?

Imagine um prédio.

Dentro dele havia uma sala enorme.

Piso elevado.

Ar-condicionado potente.

Poucas pessoas podiam entrar.

Porta pesada.

Vidros escuros.

Muito silêncio.

No centro:

Um IBM System/360.

Depois um System/370.

Mais tarde um IBM 3090.

Ou um IBM 4381.

Ao redor existiam dezenas de equipamentos auxiliares.

Era praticamente um templo da computação.


O CPD era muito mais que um computador

Na verdade o computador era apenas uma pequena parte.

Um CPD normalmente possuía:

  • Mainframe

  • Unidades de fita magnética

  • Leitoras de cartão perfurado

  • Impressoras de linha

  • Consoles do operador

  • Controladoras

  • Discos removíveis

  • Unidades DASD

  • Painéis elétricos

  • Nobreaks

  • Geradores

  • Ar condicionado industrial

Tudo isso funcionando simultaneamente.


Por que o piso era elevado?

Essa é uma curiosidade clássica.

O famoso piso falso não existia apenas para esconder cabos.

Ali passavam:

  • energia elétrica

  • fibra óptica (mais recentemente)

  • cabos coaxiais

  • cabos de dados

  • tubos de refrigeração

  • sensores

  • aterramento

Além disso o ar frio era insuflado por baixo do piso.

O frio subia pelas grelhas exatamente onde os equipamentos estavam.

Esse conceito ainda existe em muitos Data Centers atuais.


O operador era quase um piloto de avião

Hoje quase tudo é automático.

Na década de 80 não era.

Existiam operadores trabalhando 24 horas.

Eles:

montavam fitas,

trocavam discos,

iniciavam jobs,

cancelavam jobs,

alimentavam impressoras,

reabasteciam formulários contínuos,

verificavam mensagens do console,

reiniciavam equipamentos.

Era uma profissão extremamente especializada.


O nascimento do Data Center

Nos anos 90 aconteceu uma revolução.

Os servidores começaram a ficar menores.

A arquitetura cliente-servidor cresceu.

Unix.

Windows NT.

Linux.

Sun.

HP.

DEC.

IBM RS/6000.

Em vez de um único computador gigantesco, passaram a existir centenas de servidores.

O antigo CPD começou a mudar.

Foi quando o termo internacional ganhou força:

Data Center

Centro de Dados.

Perceba a mudança.

Antes o foco era:

Processar dados.

Agora passou a ser:

Hospedar dados.

Disponibilizar serviços.

Conectar aplicações.

Executar virtualização.

Armazenar informações.

Oferecer alta disponibilidade.


O nome mudou porque a missão mudou

CPD focava em:

Processamento Batch.

Folha de pagamento.

Contabilidade.

Relatórios.

Lotes noturnos.

Data Center passou a focar em:

Internet.

Cloud.

APIs.

Virtualização.

Containers.

Microserviços.

IA.

Big Data.

Streaming.

Ambientes híbridos.

Hoje o processamento acontece continuamente.

24 horas.

365 dias.


O Mainframe desapareceu?

Não.

Esse é um dos maiores mitos da informática.

O que desapareceu foi o modelo centralizado do antigo CPD.

O Mainframe continua evoluindo.

Na verdade ele faz parte dos maiores Data Centers do mundo.

Bancos.

Companhias aéreas.

Seguradoras.

Governos.

Cartões de crédito.

Bolsa de valores.

Todos utilizam enormes Data Centers onde coexistem:

IBM Z

Linux

Windows

Storage

Cloud

Containers

OpenShift

Kubernetes

IA

Tudo integrado.

O mainframe deixou de ser "o computador" para se tornar um dos pilares da infraestrutura corporativa, convivendo com milhares de outros componentes.


A evolução dos equipamentos

Ontem

Mainframe

Fitas

Cartões

Impressoras

Terminais 3270

Discos removíveis

Controladoras dedicadas

Cabos grossos


Hoje

IBM Z

Blade Servers

Storage SAN

NAS

NVMe

SSD

GPUs

Switches Fibre Channel

Ethernet 400 Gb

Roteadores

Firewalls

Load Balancers

Appliances de Segurança

Clusters Kubernetes

Hipervisores

Cabines All Flash

Bibliotecas Robotizadas

Sistemas de Backup Imutável

Equipamentos de IA


O coração continua sendo a energia

Existe um detalhe curioso.

Mudou tudo.

Menos uma prioridade.

Energia.

Sem energia não existe Data Center.

Por isso encontramos:

UPS

Nobreaks

Baterias

Banco de baterias

Geradores Diesel

Geradores a Gás

Transformadores

Painéis elétricos redundantes

ATS (Automatic Transfer Switch)

PDU (Power Distribution Unit)

Barramentos inteligentes

Monitoramento em tempo real.

Nos grandes Data Centers existe redundância N+1, 2N ou até 2N+1 para garantir que uma falha não interrompa os serviços.


O ar-condicionado virou engenharia

Os antigos aparelhos de parede desapareceram.

Hoje encontramos:

CRAC

Computer Room Air Conditioner

e

CRAH

Computer Room Air Handler

Além disso:

Corredor frio.

Corredor quente.

Contenção de ar.

Sensores térmicos.

Resfriamento líquido.

Rear Door Heat Exchanger.

Immersion Cooling.

IA para otimização térmica.

Em instalações de alta densidade, especialmente com GPUs para IA, o resfriamento líquido está se tornando cada vez mais comum devido ao enorme consumo energético.


A evolução das equipes

No CPD existiam poucas funções.

Operador

Programador

Analista

Supervisor

Hoje um Data Center reúne dezenas de especialidades.

Infraestrutura

SysAdmin

Linux

Windows

Virtualização

VMware

Hyper-V

KVM


Redes

LAN

WAN

Wi-Fi

BGP

OSPF

SD-WAN


Mainframe

System Programmer

Storage Administrator

CICS

IMS

Db2

MQ

RACF

JES2

z/OS


Cloud

AWS

Azure

Google Cloud

IBM Cloud

OpenShift

Kubernetes

Terraform

Ansible


Segurança

SOC

Blue Team

Red Team

IAM

PAM

SIEM

EDR

XDR

Zero Trust


Observabilidade

Prometheus

Grafana

Elastic

OpenTelemetry

Splunk

Instana

Z APM Connect

RMF

SMF


DevOps

Git

GitHub

GitLab

Jenkins

Azure DevOps

IBM DBB

Zowe

ArgoCD

CI/CD


O armazenamento mudou completamente

Antes:

Discos enormes.

Pouca capacidade.

Caríssimos.

Hoje:

Petabytes.

Flash.

NVMe.

Object Storage.

Storage distribuído.

Snapshots.

Replicação síncrona.

Replicação assíncrona.

Deduplicação.

Compressão.

Immutable Backup.

Mesmo assim, conceitos clássicos de organização, integridade e recuperação continuam sendo fundamentais.


A segurança ganhou protagonismo

No antigo CPD bastava controlar quem entrava na sala.

Hoje isso está longe de ser suficiente.

Além da segurança física, um Data Center moderno precisa proteger:

  • identidade dos usuários;

  • aplicações;

  • APIs;

  • bancos de dados;

  • redes;

  • containers;

  • máquinas virtuais;

  • segredos e certificados;

  • criptografia em repouso e em trânsito;

  • monitoramento contínuo;

  • resposta a incidentes.

O prédio continua protegido, mas agora a "porta" também existe na internet.


A virtualização mudou tudo

Antigamente:

1 servidor.

1 sistema operacional.

1 aplicação.

Hoje:

Um único servidor pode hospedar centenas de máquinas virtuais.

Ou milhares de containers.

No IBM Z isso não é novidade.

LPARs, PR/SM e z/VM já permitiam consolidação e isolamento décadas antes de a virtualização se popularizar no mercado x86. Muitos conceitos considerados "modernos" em cloud nasceram primeiro no universo mainframe.


O Data Center virou uma nuvem

O usuário não sabe mais onde está seu sistema.

Pode estar:

São Paulo.

Dallas.

Frankfurt.

Tóquio.

Ou distribuído entre todos eles.

Essa é a essência do modelo híbrido.

O Data Center deixou de ser apenas um prédio.

Hoje ele pode ser uma combinação de infraestrutura própria, colocation e serviços em múltiplas nuvens públicas.


O papel do Programador COBOL nesse novo cenário

Muitos iniciantes imaginam que o programador COBOL trabalha isolado.

Na realidade, ele faz parte de um ecossistema muito maior.

Um programa COBOL pode:

  • acessar Db2;

  • publicar mensagens no IBM MQ;

  • consumir APIs REST via z/OS Connect;

  • trocar dados com microsserviços Java;

  • participar de pipelines CI/CD;

  • ser monitorado por observabilidade moderna;

  • executar em um IBM Z integrado à cloud.

Conhecer o ambiente onde sua aplicação roda é tão importante quanto conhecer a linguagem.


CPD x Data Center

CPDData Center
Foco em processamentoFoco em serviços e disponibilidade
Mainframe centralInfraestrutura distribuída
Batch predominanteBatch + tempo real
Operação manualAutomação e orquestração
Poucas equipesTimes multidisciplinares
Ambiente fechadoIntegração global
Equipamentos proprietáriosPlataformas híbridas
Escalabilidade limitadaEscalabilidade horizontal e vertical

Curiosidades

  • O termo CPD continua muito usado em empresas brasileiras antigas, especialmente bancos e órgãos públicos, mesmo quando a infraestrutura já é um Data Center moderno.

  • Muitos Data Centers de missão crítica ainda utilizam piso elevado, embora algumas instalações de alta densidade adotem outras soluções de distribuição de energia e refrigeração.

  • Grandes provedores de nuvem operam Data Centers com centenas de milhares de servidores, mas também utilizam tecnologias inspiradas em décadas de engenharia de ambientes críticos.

  • Um IBM Z atual ocupa muito menos espaço do que seus antecessores e oferece desempenho, segurança e eficiência energética incomparavelmente superiores.


O verdadeiro ensinamento

Existe um erro comum entre os iniciantes.

Pensar que CPD é apenas um nome antigo para Data Center.

Não é.

O CPD representava uma época em que o objetivo principal era processar informações.

O Data Center representa uma era em que é preciso processar, armazenar, proteger, integrar, escalar e disponibilizar dados e serviços continuamente, para usuários espalhados pelo mundo.

Apesar dessa transformação, um princípio nunca mudou.

Desde os cartões perfurados até a inteligência artificial, desde o IBM System/360 até o IBM z17, desde as fitas magnéticas até o armazenamento em flash distribuído, a missão permanece a mesma:

garantir que a informação certa esteja disponível, íntegra e segura, exatamente quando alguém precisar dela.

Esse é o legado dos antigos CPDs.

Esse é o coração dos modernos Data Centers.

E é exatamente nesse ambiente que o Programador COBOL Padawan continua escrevendo sistemas que movimentam bancos, governos, hospitais, seguradoras e empresas em todos os continentes.

Porque tecnologias evoluem, nomes mudam e equipamentos são substituídos. Mas a engenharia da informação — construída com disciplina, confiabilidade e décadas de experiência — continua sendo a verdadeira força que mantém o mundo funcionando, 24 horas por dia, 7 dias por semana.


sexta-feira, 28 de setembro de 2018

IBM Mainframe Discovery : Capítulo IX — A Federação das Naves Invisíveis

 

Bellacosa Mainframe apresenta ibm mainframe parte ix

☕ Um Café no Bellacosa Mainframe

Capítulo IX — A Federação das Naves Invisíveis

PR/SM, LPARs e Virtualização: Como Um Único Computador se Transformou em uma Galáxia Inteira 


SEXTA REGRA DAS GRANDES CIVILIZAÇÕES

Nunca compre uma nave espacial apenas porque ela é enorme.

Pergunte primeiro:

Quantas civilizações diferentes conseguem viver dentro dela sem começar uma guerra?

Parece uma pergunta estranha.

Mas foi exatamente essa pergunta que a IBM respondeu décadas atrás.

Imagine uma nave gigantesca.

Dentro dela vivem:

  • uma federação de banqueiros;

  • um grupo de cientistas;

  • uma academia militar;

  • uma universidade;

  • um hospital;

  • uma estação meteorológica;

  • uma fábrica de robôs.

Todos utilizam o mesmo casco.

A mesma energia.

Os mesmos motores.

Mas nenhum deles sabe que os outros existem.

Parece magia.

Não é.

É virtualização.


O Grande Apartamento Cósmico

Imagine um prédio com cem apartamentos.

Todos compartilham:

  • fundação;

  • elevadores;

  • telhado;

  • energia elétrica;

  • encanamento.

Mas cada morador acredita possuir sua própria casa.

O IBM Z faz exatamente isso.

Só que em escala planetária.


Antes da Virtualização

Voltemos algumas décadas.

Você precisava de um servidor para:

Banco.

Outro para RH.

Outro para folha.

Outro para testes.

Outro para desenvolvimento.

Outro para homologação.

Resultado?

Salas inteiras cheias de computadores.

Baixa utilização.

Muito calor.

Muito desperdício.


Então Surgiu Uma Ideia Revolucionária

Um engenheiro olhou para aquele enorme computador e perguntou:

"Por que não dividir essa nave em várias menores?"

Hoje isso parece óbvio.

Na década de 1970 era praticamente ficção científica.


A Grande Mágica

Imagine um teatro.

Existe apenas um palco.

Mas cinco peças diferentes acontecem simultaneamente.

Cada plateia acredita que ocupa o teatro inteiro.

Como isso seria possível?

No IBM Z isso acontece todos os dias.

Cada ambiente acredita possuir:

sua própria CPU.

sua própria memória.

seus próprios discos.

seu próprio sistema operacional.

Na realidade...

todos compartilham o mesmo hardware.


Conheça o PR/SM

Nos bastidores existe um personagem extremamente discreto.

Seu nome é:

PR/SM

Processor Resource/System Manager.

Pense nele como o administrador da estação espacial.

Ele decide:

quem recebe CPU.

quem recebe memória.

quem recebe canais de I/O.

quem pode utilizar determinado recurso.

Segundo Wilhelm G. Spruth, o PR/SM é responsável por particionar logicamente um único sistema físico em ambientes completamente independentes, oferecendo isolamento em nível de hardware.


As LPARs — Pequenos Universos

Agora chegamos às estrelas principais deste capítulo.

As famosas:

LPARs

(Logical Partitions).

Imagine uma gigantesca nave.

Agora coloque dentro dela:

USS Alpha.

USS Beta.

USS Gamma.

USS Delta.

Cada nave possui:

tripulação.

missões.

comandante.

computadores.

sistemas.

Elas dividem o mesmo casco.

Mas vivem vidas completamente independentes.

Cada LPAR acredita ser um computador completo.

E, do ponto de vista do sistema operacional...

ela realmente é.


Um Hotel de Luxo

Imagine um hotel.

Cada hóspede possui:

quarto.

banheiro.

telefone.

televisão.

Wi-Fi.

Ar-condicionado.

Nenhum hóspede invade o quarto do outro.

As LPARs seguem exatamente esse princípio.

Cada uma recebe recursos exclusivos.

Segurança.

Isolamento.

Previsibilidade.


O Vizinho Barulhento Não Existe

Você já morou perto de alguém que fazia festa às três da manhã?

No IBM Z isso seria inaceitável.

Uma LPAR não pode consumir recursos pertencentes à outra.

O PR/SM garante essa separação.

Mesmo que uma aplicação apresente problemas...

as demais continuam funcionando normalmente.


Compartilhar Não Significa Misturar

Essa é uma lição importante.

Compartilhar hardware não significa compartilhar tudo.

Imagine um prédio.

Os apartamentos compartilham:

estrutura.

água.

energia.

Mas ninguém compartilha:

escova de dentes.

geladeira.

conta bancária.

O isolamento permanece absoluto.


CPU Compartilhada ou Dedicada?

Agora imagine uma frota espacial.

Algumas naves possuem pilotos exclusivos.

Outras utilizam pilotos compartilhados.

No IBM Z acontece exatamente isso.

Uma LPAR pode receber:

CPUs dedicadas

ou

CPUs compartilhadas.

O administrador escolhe conforme a necessidade.


O Maestro Continua Trabalhando

Lembra do Supervisor?

Agora ele ganhou um chefe.

O PR/SM coordena as LPARs.

Dentro de cada LPAR...

o Supervisor organiza seus próprios programas.

É uma hierarquia elegante.

Como uma federação.

Cada planeta governa seus habitantes.

Mas existe um conselho superior distribuindo recursos entre todos.


E Se Uma LPAR Travar?

Imagine um apartamento.

O morador derruba uma estante.

Os outros apartamentos continuam intactos.

O mesmo ocorre aqui.

Uma LPAR pode sofrer problemas.

As demais continuam operando normalmente.

Esse isolamento é um dos pilares da confiabilidade do IBM Z.


O Grande Restaurante Galáctico

Imagine um restaurante gigantesco.

Existem:

clientes VIP.

turistas.

tripulações.

embaixadores.

Todos utilizam a mesma cozinha.

Mas recebem atendimento diferente.

O PR/SM faz algo semelhante.

Distribui recursos conforme prioridades.

Sem desperdício.


Dynamic LPAR

Agora imagine algo curioso.

Enquanto a nave está viajando...

você aumenta o tamanho de um dos apartamentos.

Sem parar a nave.

Sem desligar motores.

Sem evacuar passageiros.

Isso existe.

Chama-se:

Dynamic LPAR.

Processadores, memória e alguns recursos podem ser adicionados ou removidos dinamicamente, reduzindo drasticamente interrupções operacionais.


O Universo Está Vivo

As necessidades mudam.

Às nove da manhã:

Banco precisa de mais CPU.

À meia-noite:

Batch precisa crescer.

Domingo:

Homologação precisa de recursos.

Segunda-feira:

Desenvolvimento aumenta.

Tudo isso pode acontecer dinamicamente.


WLM Entra em Cena

Agora surge outro personagem.

O famoso:

Workload Manager.

Imagine um gerente de aeroporto.

Ele percebe:

"A pista internacional está lotada."

Então redistribui equipes.

Abre novos portões.

Prioriza determinados voos.

O WLM faz exatamente isso com cargas de trabalho.

Ele conversa continuamente com o PR/SM para ajustar a distribuição dos recursos conforme os objetivos definidos pela instalação.


A Grande Ilusão

Curiosamente...

o sistema operacional nunca percebe toda essa complexidade.

O z/OS acredita possuir um computador inteiro.

Linux acredita possuir outro.

z/VM acredita possuir outro.

Todos vivem felizes.

Enquanto o PR/SM coordena silenciosamente tudo nos bastidores.


A Virtualização Não Nasceu Ontem

Existe um mito curioso.

Muita gente acredita que virtualização começou com VMware.

Ou Hyper-V.

Ou KVM.

Na realidade...

o universo Mainframe experimentava esses conceitos décadas antes.

Spruth destaca a virtualização por hardware como uma das características distintivas do System z, muito antes de ela se tornar comum em servidores distribuídos.

Isso não diminui a importância das plataformas modernas.

Mas mostra como muitas ideias consideradas "novas" possuem raízes muito mais antigas.


Hipersockets — O Teletransporte

Imagine duas naves estacionadas lado a lado.

Tradicionalmente...

elas conversariam usando rádio.

No IBM Z surgiu outra ideia.

Por que usar cabos...

...se ambas vivem dentro da mesma nave?

Assim nasceram os:

Hipersockets.

Eles permitem comunicação extremamente rápida entre LPARs, utilizando memória em vez de redes físicas.

É quase um teletransporte de mensagens.

Spruth apresenta os Hipersockets como um mecanismo de comunicação interna de altíssimo desempenho entre partições lógicas.


Uma Cidade Dentro de Outra Cidade

Imagine uma metrópole.

Dentro dela existe outra cidade.

Dentro dessa cidade...

outra.

Parece impossível.

Mas no IBM Z isso também acontece.

Uma LPAR pode executar:

z/VM.

Dentro do z/VM surgem:

centenas.

milhares.

de máquinas virtuais Linux.

Uma verdadeira galáxia de computadores vivendo dentro de outro computador.


O Que Mudou Desde 2010?

Desde que Spruth escreveu seu relatório, a virtualização evoluiu ainda mais.

Hoje encontramos:

  • dezenas de TB de memória por sistema;

  • milhares de máquinas Linux simultâneas;

  • OpenShift nativo;

  • Kubernetes;

  • containers;

  • Secure Execution;

  • integração híbrida com nuvem;

  • LinuxONE;

  • IA embarcada.

Mas o conceito permanece idêntico.

Um único computador.

Múltos mundos.

Perfeitamente isolados.


Uma Lição Para a Vida

Existe uma filosofia escondida neste capítulo.

Uma grande cidade não precisa eliminar diferenças.

Ela precisa organizá-las.

Cada LPAR possui sua missão.

Seu ritmo.

Sua prioridade.

Seu sistema operacional.

Sua cultura.

Mesmo assim...

todas cooperam utilizando a mesma infraestrutura.

Talvez essa seja uma das metáforas mais bonitas da engenharia.


Curiosidades do Diário de Bordo

🚀 O PR/SM é certificado em altos níveis de segurança e isolamento, permitindo que ambientes com diferentes requisitos coexistam no mesmo hardware físico.

🛰️ Hipersockets eliminam boa parte da latência de comunicação entre LPARs ao manter o tráfego inteiramente dentro do sistema.

🖥️ Um único IBM Z pode hospedar simultaneamente z/OS, Linux, z/VM e outros ambientes, cada um acreditando possuir sua própria máquina.

🌌 A virtualização em hardware do IBM Z antecedeu em muitos anos a popularização da virtualização em servidores x86.


Diário de Bordo do Padawan COBOL

Antes de deixar a Federação das LPARs, registre estas coordenadas no seu Holocron Técnico:

✅ Virtualização não significa apenas dividir recursos; significa criar ambientes independentes, seguros e previsíveis.

✅ O PR/SM atua como o grande administrador da nave, distribuindo CPU, memória e I/O entre diferentes partições.

✅ As LPARs permitem consolidar múltiplos sistemas em um único hardware sem sacrificar isolamento ou desempenho.

✅ Muitas tecnologias modernas de consolidação e computação em nuvem seguem princípios que o IBM Z já aplicava décadas antes.


Missão Seguinte

No próximo capítulo faremos um salto para uma das tecnologias mais impressionantes do universo IBM Z: o Parallel Sysplex e a Coupling Facility.

Descobriremos como várias naves conseguem pensar como uma só, compartilhar dados em tempo real e continuar operando mesmo quando uma delas sai de combate. Se as LPARs transformaram um computador em vários mundos, o Parallel Sysplex transformará vários computadores em uma única civilização galáctica.

☕ Um Café no Bellacosa Mainframe

O Guia Galáctico do IBM Z

Dezoito capítulos e uma conclusão reunidos em um painel interativo. Escolha uma missão, abra no visor e continue explorando diretamente no artigo original.

Não entre em pânico: se o Blogger impedir a exibição dentro do iframe, use “Abrir artigo”. Os links diretos continuam visíveis para leitores e motores de busca.
01

Capítulo I — Não Entre em Pânico!

Leia no visor ou abra a publicação original.

Abrir artigo
02

Capítulo II — A Planta da Nave Mais Duradoura da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
03

Capítulo III — A Nave Que Se Recusa a Explodir

Leia no visor ou abra a publicação original.

Abrir artigo
04

Capítulo IV — A Sala dos Cofres Cósmicos

Leia no visor ou abra a publicação original.

Abrir artigo
05

Capítulo V — A Frota Invisível do Transporte Interestelar

Leia no visor ou abra a publicação original.

Abrir artigo
06

Capítulo VI — O Grande Maestro Invisível

Leia no visor ou abra a publicação original.

Abrir artigo
07

Capítulo VII — O Grande Terminal de Embarque da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
08

Capítulo VIII — A Metrópole das Transações Infinitas

Leia no visor ou abra a publicação original.

Abrir artigo
09

Capítulo IX — A Federação das Naves Invisíveis

Leia no visor ou abra a publicação original.

Abrir artigo
10

Capítulo X — A Consciência Coletiva da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
11

Capítulo XI — O Almirante Invisível da Frota

Leia no visor ou abra a publicação original.

Abrir artigo
12

Capítulo XII — A Biblioteca Infinita da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
13

Capítulo XIII — O Serviço Postal Mais Confiável da Galáxia

Leia no visor ou abra a publicação original.

Abrir artigo
14

Capítulo XIV — O Jardim Secreto da Nave

Leia no visor ou abra a publicação original.

Abrir artigo
15

Capítulo XV — O Tradutor Universal da Federação

Leia no visor ou abra a publicação original.

Abrir artigo
16

Capítulo XVI — A Fábrica Automática da Federação

Leia no visor ou abra a publicação original.

Abrir artigo
17

Capítulo XVII — A Última Fronteira Nunca Foi o Espaço

Leia no visor ou abra a publicação original.

Abrir artigo
18

Capítulo XVIII — O Guia Nunca Terminou

Leia no visor ou abra a publicação original.

Abrir artigo
19

Conclusão — Não Entre em Pânico... A Jornada Está Apenas Começando

Leia no visor ou abra a publicação original.

Abrir artigo
Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...