✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

Mostrar mensagens com a etiqueta Priorização de Workload. Mostrar todas as mensagens

quinta-feira, 22 de novembro de 2018

IBM Mainframe Discovery : Capítulo XI — O Almirante Invisível da Frota

Bellacosa Mainframe apresenta ibm mainframe parte xi

☕ Um Café no Bellacosa Mainframe

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

Workload Manager (WLM): A Inteligência que Decide Quem Salva a Galáxia Primeiro

OITAVA REGRA DAS GRANDES FROTAS

Se todas as naves tentarem usar o mesmo portal espacial ao mesmo tempo...

...nenhuma chegará ao destino.

Curiosamente, esse problema não existe apenas nas viagens interestelares.

Ele acontece todos os dias em:

bancos;
bolsas de valores;
companhias aéreas;
seguradoras;
hospitais;
governos;
empresas de telecomunicações.

Milhões de pessoas querem utilizar os mesmos recursos.

No mesmo instante.

Existe apenas uma pergunta.

Quem deve ser atendido primeiro?

Responder essa pergunta parece simples.

Até surgirem:

um PIX.

uma cirurgia.

uma compra de ações.

um caixa eletrônico.

uma consulta médica.

uma folha de pagamento.

Tudo exatamente no mesmo segundo.

Bem-vindo ao universo do Workload Manager.

Ou, simplesmente...

WLM.

A Nave Possui Recursos Limitados

Imagine uma gigantesca nave interestelar.

Ela possui:

motores;
energia;
combustível;
hangares;
radares;
processadores.

Mesmo a maior nave da galáxia possui limites.

Agora imagine que, exatamente às 9h da manhã, aconteçam simultaneamente:

uma invasão.

um incêndio.

um casamento.

uma entrega de suprimentos.

uma reunião diplomática.

uma pane elétrica.

Quem recebe prioridade?

Se ninguém decidir...

o caos decide.

O Grande Equívoco

Muitos acreditam que a CPU executa programas simplesmente na ordem em que chegam.

Isso seria como administrar um aeroporto dizendo:

"Quem correr mais embarca primeiro."

Não parece uma boa ideia.

No IBM Z isso nunca aconteceu.

Conheça o Grande Almirante

Imagine um oficial experiente observando centenas de painéis.

Ele acompanha:

uso de CPU.

memória.

discos.

rede.

tempo de resposta.

filas.

prioridades.

temperatura da batalha.

Ele não pilota nenhuma nave.

Mas decide quem recebe recursos.

Esse personagem chama-se:

Workload Manager.

Segundo Wilhelm G. Spruth, o WLM monitora continuamente o comportamento do sistema e ajusta automaticamente a distribuição de recursos para atender objetivos previamente definidos pela organização.

O Erro da Lista de Prioridades

Imagine uma lista.

Banco
RH
Marketing
Desenvolvimento

Parece suficiente.

Não é.

Porque prioridades mudam.

O banco pode ser prioridade máxima durante o expediente.

À meia-noite...

talvez o processamento Batch seja mais importante.

No domingo...

homologação.

Na segunda...

produção.

O WLM entende que o universo muda constantemente.

Objetivos, Não Ordens

Aqui encontramos uma das ideias mais elegantes do Mainframe.

Você não diz:

"Dê exatamente 37% da CPU para este sistema."

Você diz:

"Quero que esta aplicação responda em menos de um segundo."

O restante...

o WLM descobre sozinho.

Essa filosofia ficou conhecida como:

Goal-Oriented Computing.

Em vez de administrar recursos diretamente, o administrador define metas de negócio, e o sistema procura atingi-las da forma mais eficiente possível.

O Restaurante Galáctico

Imagine um restaurante.

Chegam ao mesmo tempo:

um astronauta.

um embaixador.

uma família.

um entregador.

uma equipe médica.

Todos têm fome.

Mas alguns possuem urgência maior.

O gerente reorganiza a fila.

Sem confusão.

Sem injustiça.

O WLM faz exatamente isso.

Service Classes — As Missões da Federação

Imagine que cada missão recebe uma classificação.

Classe Alfa.

Classe Beta.

Classe Gama.

Classe Ômega.

Cada uma possui expectativas diferentes.

No WLM isso recebe o nome de:

Service Class.

Ela representa o nível de serviço esperado para determinado conjunto de aplicações.

Importance — O Peso da Missão

Agora imagine duas emergências.

Uma delas pode esperar cinco minutos.

A outra não.

Como decidir?

O WLM utiliza um conceito chamado:

Importance.

Ele representa o impacto daquela carga de trabalho para o negócio.

Quanto maior sua importância...

maior a atenção recebida.

Velocity — O Ritmo da Cidade

Nem toda aplicação trabalha respondendo rapidamente.

Algumas permanecem esperando:

discos.

rede.

usuários.

Outras precisam executar continuamente.

Para esses casos existe outro conceito.

Velocity.

Ela mede quanto tempo uma carga realmente consegue trabalhar em relação ao tempo que permanece aguardando recursos.

Response Time — O Relógio do Passageiro

Imagine um cliente entrando num banco.

Ele olha para o relógio.

Quanto tempo demorará?

No CICS isso importa muito.

O WLM acompanha constantemente o tempo de resposta das aplicações online.

Caso perceba degradação...

começa a redistribuir recursos.

Antes que usuários reclamem.

O Médico da Frota

Imagine um médico observando milhares de pacientes.

Ele percebe discretamente:

"A pressão daquele piloto começou a subir."

Nada aconteceu.

Ainda.

Mas ele age preventivamente.

O WLM trabalha exatamente assim.

Ele observa tendências.

Não apenas problemas consumados.

O Universo Está Sempre Mudando

Às 10h:

CICS domina a CPU.

À meia-noite:

Batch domina.

Durante backups:

I/O cresce.

Durante fechamento bancário:

Db2 torna-se crítico.

O WLM adapta continuamente a distribuição dos recursos.

Sem necessidade de intervenção manual.

O Capitão Nem Percebe

Uma característica elegante do WLM é sua discrição.

Ele quase nunca aparece.

Usuários não enxergam:

Service Classes.

Velocity.

Importance.

Eles apenas percebem que:

o sistema continua rápido.

Esse é exatamente o objetivo.

A Conversa com o PR/SM

Lembra do capítulo anterior?

Conhecemos o:

PR/SM.

Agora imagine dois grandes comandantes conversando.

O WLM observa:

"Minha missão Alfa precisa de mais CPU."

O PR/SM responde:

"Posso emprestar dois processadores desta outra LPAR."

Essa cooperação permite redistribuição dinâmica de recursos entre partições.

Spruth destaca justamente essa integração entre WLM e PR/SM como uma das forças da arquitetura IBM Z.

Um Aeroporto Inteligente

Imagine um aeroporto.

Uma pista congestionou.

Imediatamente outra é aberta.

Funcionários mudam de posição.

Portões são reorganizados.

Voos são redistribuídos.

Sem reuniões.

Sem telefonemas.

Sem planilhas.

Tudo automaticamente.

Esse é o espírito do WLM.

O Batch Também Importa

Muitos iniciantes pensam que o WLM trabalha apenas com aplicações online.

Não.

Ele também administra:

Jobs.

Started Tasks.

Serviços UNIX.

Db2.

Java.

WebSphere.

Linux on Z.

Tudo entra na mesma grande estratégia.

O Universo Não É Democrático

Esta talvez seja a lição mais difícil.

Nem todas as aplicações possuem a mesma importância.

Imagine uma companhia aérea.

Você prefere priorizar:

o sistema de reservas

o servidor de papéis de parede?

Parece óbvio.

O WLM transforma essa lógica empresarial em decisões técnicas.

Inteligência em Vez de Força

Existe uma filosofia fascinante escondida aqui.

Durante décadas, muitas empresas resolveram problemas comprando servidores maiores.

O IBM Z preferiu outra abordagem.

Primeiro:

organize.

Depois:

otimize.

Só então:

aumente recursos.

O WLM representa exatamente essa filosofia.

O Que Diz Spruth?

Wilhelm G. Spruth destaca que o Workload Manager foi um dos grandes diferenciais do ambiente z/OS porque deslocou a responsabilidade da administração de recursos para um sistema automatizado baseado em objetivos.

Em outras palavras...

o administrador deixa de controlar detalhes técnicos.

Passa a controlar resultados.

O Que Mudou Desde 2010?

Desde que o relatório foi publicado, o WLM tornou-se ainda mais sofisticado.

Hoje ele trabalha em conjunto com:

z/OS Container Extensions;
Linux on IBM Z;
OpenShift;
z/OSMF;
APIs REST;
IA para observabilidade;
automação baseada em políticas;
ambientes híbridos;
métricas em tempo real.

Mas sua filosofia permanece exatamente igual.

Administrar objetivos.

Não processadores.

Uma Lição Para a Vida

Existe um ensinamento escondido neste capítulo.

Imagine um comandante tentando resolver pessoalmente cada pequeno problema da nave.

Ele fracassaria.

Um bom líder estabelece objetivos.

Forma equipes.

Distribui responsabilidades.

Acompanha resultados.

Corrige desvios.

O WLM faz exatamente isso.

Talvez ele seja menos um software...

...e mais uma filosofia de administração.

Curiosidades do Diário de Bordo

🚀 O WLM foi um dos primeiros sistemas comerciais amplamente utilizados a implementar gerenciamento baseado em metas (goal-oriented management), em vez de simples alocação fixa de recursos.

🛰️ Ele consegue adaptar dinamicamente o uso de CPU e outros recursos conforme o comportamento observado das cargas de trabalho.

📊 Conceitos como Service Class, Importance e Velocity transformam necessidades de negócio em decisões automáticas de infraestrutura.

🌌 Muitas plataformas modernas de orquestração e computação em nuvem utilizam princípios semelhantes de políticas e objetivos, ainda que implementados de maneiras diferentes.

Diário de Bordo do Padawan COBOL

Antes de deixar o Centro de Comando Estratégico da Frota, registre estas coordenadas no seu Holocron Técnico:

✅ O Workload Manager não distribui recursos de forma aleatória; ele trabalha para cumprir objetivos definidos pelo negócio.

✅ O WLM observa continuamente o comportamento do sistema e ajusta prioridades sem necessidade de intervenção constante do operador.

✅ A integração entre WLM, PR/SM e LPARs permite que o IBM Z adapte sua capacidade em tempo real conforme a demanda.

✅ Grandes arquiteturas não dependem apenas de hardware poderoso. Elas dependem de inteligência para decidir, a cada microssegundo, qual missão deve ser cumprida primeiro.

Missão Seguinte

No próximo capítulo embarcaremos em uma gigantesca Biblioteca Galáctica de Dados: o Db2 for z/OS.

Descobriremos por que bilhões de registros podem ser consultados em milissegundos, como páginas, buffers, índices e logs trabalham em perfeita harmonia e por que o Db2 é muito mais do que um banco de dados — ele é o guardião da memória de toda uma civilização computacional.

☕ 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.