Conheci instalações que usavam o z/VM para administrar os ambientes dos clientes, em vez de definir uma LPAR para cada um. Desde que tive contato com elas, funcionavam assim. Focando na versatilidade do z/VM.

O que significa isso? Quais as vantagens e desvantagens? Como isso é feito?

PR/SM — Processor Resource/Systems Manager

Em poucas palavras, o PR/SM, também conhecido como “PRISMA”, é o recurso dos mainframes que permite dividir os recursos físicos do equipamento em fatias: as Logical Partitions, ou LPARs.

Fica embutido no firmware, os programas internos que gerenciam o mainframe.

Em uma comparação rudimentar, pense na BIOS (Basic Input/Output System) existente em outras plataformas, apenas para localizar essa camada interna do equipamento. A função do PR/SM vai além da inicialização feita pela BIOS: ele permanece administrando as partições durante a operação.

Sua principal vantagem está na integração com o hardware e na eficiência com que administra esses recursos. Mas tem dependencia de IOCP e HMC.

O outro lado aparece quando precisamos alterar a organização das LPARs. Parte das definições está na configuração de entrada e saída, o IOCP; parte é ajustada pela HMC, o console de gerenciamento.

Dependendo do que precisa mudar e do que foi previsto, a alteração pode exigir uma parada. Uma intervenção mais abrangente pode alcançar o CPC inteiro. Resultado indesejado: indisponibilidade geral. Para muitos isto é sinonimo de pesadelo.

Aqui estou falando de alterar a configuração das partições, e não de aplicar atualizações ao firmware. Este seria um outro departamento.

É por isso que o planejamento anterior faz tanta diferença.

Basic Mode ou LPAR Mode?

Antes das famílias IBM zSeries z990 e z890, havia equipamentos que podiam operar em Basic Mode, sem utilizar o particionamento do PR/SM.

Isso significava usar a máquina inteira diretamente, sem a divisão em LPARs.

Nesse cenário, o VM era uma forma de utilizar o equipamento com cargas distintas, inclusive com diferentes sistemas operacionais executando simultaneamente. Isto continua cada vez mais vivo, permitindo o sono tranquilo dos envolvidos.

Com a chegada dessas famílias, a operação passou a ser exclusivamente em LPAR Mode, sob o gerenciamento do PR/SM. O limite máximo de LPARs a serem definidas depende do equipamento.

Portanto, usar z/VM para hospedar os ambientes mantém o PR/SM na base. O que muda é onde fazemos a administração desses ambientes.

z/VM, o hypervisor de máquinas virtuais

O z/VM é um gerenciador de recursos que, nos equipamentos atuais, executa dentro de uma LPAR, a qual é gerenciada pelo PR/SM. Trabalham juntos, com o mínimo de overhead possível, quase imperceptível, quando bem administrado.

Dentro dele podem existir outros z/VM, z/OS, Linux para mainframe e outros sistemas compatíveis com os recursos disponíveis.

Cada um executa em sua própria máquina virtual, também chamada de guest.

Na prática, o z/VM também divide recursos e apresenta ambientes separados aos sistemas. Mas faz isso em outra camada, com ferramentas próprias para administrar essas máquinas virtuais.

Então, o que muda?

Aqui entram os prós e contras de cada uso.

PR/SM: integrado ao hardware, administra as LPARs e seus recursos. As possibilidades de configuração seguem as características do equipamento e aquilo que foi preparado para a instalação. O ambiente fica muito mais rígido, pouco flexível. Problemas nessa área podem afetar todo o CEC.

z/VM: executa em uma LPAR e oferece grande flexibilidade operacional. As definições dos guests podem ser mantidas em um simples arquivo de texto, o USER DIRECT, permitindo administrar cada ambiente individualmente. Problemas podem ficar restritos ao Guest, sem interferir com os outros ativos.

Essa camada adicional também utiliza recursos. O efeito sobre o desempenho precisa ser observado na carga que será executada pelo equipamento no geral.

E existe um compromisso importante: se o z/VM hospedeiro precisar parar, os guests que estiverem nele também serão afetados. É a mesma coisa que acontece quando o PR/SM precisa de uma reciclagem. Ambos precisam do mínimo de intervenção possível.

A flexibilidade precisa vir acompanhada do planejamento de disponibilidade.

Como os clientes usam?

Como em toda configuração, depende da necessidade.

Minha premissa é simples: se existe necessidade de criar e reconfigurar ambientes com rapidez, a flexibilidade do z/VM deve ser considerada.

Por exemplo, em um site destinado a Disaster Recovery, onde as configurações precisam ser preparadas ou redefinidas para atender à demanda do momento.

Ou quando se vende uso de máquina. A entrada de um novo cliente precisa ser transparente e acontecer enquanto os demais continuam trabalhando.

Nas instalações que conheci, os ambientes dos clientes estavam sob VM. Era ali que se faziam as alterações, editando manualmente o USER DIRECT, simulando as LPARs que sustentavam a operação. Sem paradas indesejadas para os outros clientes.

Para ambientes mais estáticos, executar os sistemas diretamente em LPARs pode ser a escolha natural.

A cada nova geração de hardware, as funções de gerenciamento são aprimoradas. As possibilidades de alteração dinâmica e os controles da HMC também devem entrar na avaliação. Por exemplo, pesquise por "Dummy LPAR" no IOCP ou "Change LPAR Controls" na HMC.

Em qualquer caso, planejamento é a palavra-chave.

Como implementar?

Simples. O trabalho está em preparar a configuração. Quanto antes, melhor.

Na arquitetura em questão, define-se uma única LPAR no CEC, para o z/VM hospedeiro, com os recursos necessários para sustentar os ambientes previstos. Esta LPAR pode ocupar a maquina inteira, como se fosse um Basic Mode. Deixar reservas de recursos separados pode ter um efeito contrário, pois vai envolver alterações indesejadas durante a operação normal.

Nessa LPAR, instala-se um z/VM enxuto, sem cargas adicionais. Ele será a plataforma para os demais sistemas: outros z/VM, z/OS, Linux ou o que o projeto exigir e a configuração suportar. Cada usuário neste z/VM é o equivalente a uma LPAR. Em teoria, não existe limite para o número de guests definidos. Se forem ativados em excesso, simultaneamente, haverá degradação, mas ainda assim, estarão vivos.

O trabalho dos clientes fica nos guests. O hospedeiro fica dedicado exclusivamente a sustentá-los.

Também se prepara a coleta e a gravação dos registros de desempenho, em disco. Apenas capturar ali; a análise pode ser feita por outro guest. Vai indicar quando o ponto de degradação estiver próximo.

Para administrar as definições, o próprio USER DIRECT pode ser editado manualmente, sem acrescentar um gerenciador de diretório a esse hospedeiro ou qualquer outro aplicativo.

Duplicar o bloco que define um guest e alterar seu nome leva menos de um minuto.

Depois de validar e compilar o diretório, a nova definição fica disponível para ativação. O que esse guest vai executar é outra atividade.

É dessa rapidez que estou falando.

Com os recursos preparados, criar mais uma definição deixa de ser uma alteração na estrutura de LPARs e passa a ser uma edição de texto.

Quem já sentou diante de um terminal para atender uma solicitação urgente sabe o valor disso.

E ainda há outras possibilidades

O z/VM também pode apresentar determinados recursos virtuais sem que exista um dispositivo físico equivalente. Algo que esteja encomendado, mas ainda precisa de um tempo até chegar.

Discos FBA são um exemplo. Ou processadores especializados. Ou mais memória do que existe fisicamente.

Dependendo do recurso e do suporte disponível, isso permite antecipar atividades de desenvolvimento e testes enquanto a configuração definitiva está sendo preparada.

Vale conhecer essas possibilidades antes de concluir que todo o trabalho precisa esperar pela chegada de um equipamento. Tempo é dinheiro, inclusive no Desenvolvimento.

Os detalhes dependem do que você pretende fazer. É justamente o tipo de conversa em que posso ajudar.

“Não tenho pessoal para pensar nisso agora.”

Essa é a parte mais fácil de encaminhar. Fale comigo.

Eu posso planejar e executar esse trabalho para você ou com você e seu time, com o planejamento que for preciso.

Marque uma conversa inicial, sem custo, para avaliarmos o que precisa ser feito.

A partir dela, podemos preparar uma proposta e um contrato, com o trabalho e as datas definidos.

Depois, detalhamos e executamos o projeto. Vamos estudar as possibilidades?

Clique no patrocinador abaixo para manter esta Newsletter gratuita. Deixe que ele pague a conta.

Codie Sanchez, Colin & Samir, Joanna Stern, and Oliver Darcy are here too. They all built newsletters (and podcasts and communities and websites) on beehiiv.

Some came with massive followings. Others built theirs along the way. That’s the thing about beehiiv: with so many ways to earn and grow, the platform is ready for whatever you’re building next.

Get started for free.