zSystem IBM (mainframe) - Arquitetura - 1

z System IBM - Arquitetura 1

Arquitetura de Neumann (1945)

Arquitetura de Neumann - 1945

John von Neumann publicou em 1945 um relatório que incluía o modelo da arquitetura de um sistema computadorizado, observando o modelo proposto é possível identificar que os modelos hoje aplicados aos computadores se mantêm fiéis ao modelo inicial. As principais inovações do modelo de 1945 estão relacionadas com a velocidade dos processadores e a capacidade da memória e claro, os periféricos que realizam o "input" e "output".

Mainframe IBM e z System

z System é o hardware que possui o DNA do mainframe. Podemos subir máquinas virtuais com diferentes sistemas operacionais, incluindo alguns sabores de Linux, pode processar programas desenvolvidos em linguagens recentes como Python, Groovy e conserva a capacidade de processar programas cobol compilados a décadas, se estiver compilado a décadas, recomendo fortemente recompilar com a versão mais atual do Cobol 😉Pode estar desperdiçando dinheiro aqui..

Eu particularmente não aprecio muito a denominação MAINFRAME, a evolução do hardware, sistemas operacionais, middleware, a modernização capacitada ao desenvolvimento de novos sistemas e integração das aplicações disponíveis no zSystem o coloca como a mais sofisticada e eficiente plataforma de processamento comercial disponível em nosso planeta.

z System & Neumann

O modelo de Neumann está presente também na arquitetura do zSystem, entretanto, outros conceitos foram incluídos como os co-processadores especializados, mais recentemente um para IA 😮, criando diferenciais importantes para o processamento de negócios com alto desempenho e garantia total para a integridade das informações.

Aqui podemos ver o modelo de Neumann em um processador z16, anunciado em abril de 2022.

Os processadores do zSystem seguem o mesmo princípio do modelo de Neumann (1945), assim como os processadores que estão em seu servidor corporativo ou ainda em calculadoras, laptops, tablets, smart phones, console de games, etc.

A diferença do zSystem para outros servidores está na arquitetura da máquina, os processadores são utilizados de forma diferenciada dependendo do tipo de carga de processamento, tipo do processamento. A distribuição da carga, o gerenciamento de I/O e da memória também possui seus processadores "especializados".

Arquitetura z System

Os Processadores

O desenho dos processadores no zSystem não possui até aqui nada de extraordinário frente à outros processadores, a grande diferença está em como esses processadores são utilizados dentro da arquitetura.

Convém lembrar que todos possuem a mesma estampa contudo, são configurados para trabalharem em especialidades.

Tipo	Nome	Especialidade
CP	Central Processor	Processar cargas tradicionais z/OS, z/VSE - Sistemas/programas COBOL, PL/I, Assembler.
zIIP	z Integrated Information Processor	Processar cargas especiais z/OS, z/VSE - Sistemas/programas , JAVA, XML, data offload
IFL	Integrated Facility for Linux	Processar carga de servidores virtuais Linux
CBU	Capacity Backup	Processador para ser ativado em caso de contingência - para suportar carga de outra máquina
ON/OFF	ON/OFF	Processadores disponíveis para processar a carga em demandas sazonais.
ICF	Integrated Coupling Facility	Processadores dedicados à gestão do Coupling Facility (Memória com dados compartilhados entre diferentes máquinas físicas ou virtuais)
SAP	System Assistant Processor	Processadores dedicados ao subsistema de I/O, também denominado CHANNEL SUBSYSTEM.
SPARE	Processador extra	Assume a função de qualquer dos anteriores que venham a apresentar problema.

Exemplo de configuração dos processadores da z/14

As diferentes funcionalidades dos processadores serão apresentadas durante as descrições da arquitetura interna do zSystem

Sistemas Operacionais

Para facilitar o detalhamento da arquitetura de hardware do zSystem, é necessário apresentar os sistemas operacionais disponíveis para este hardware. Para iniciar:

1 – OS, DOS, MVS, MVS/XA, MVS/ESA, OS/390 e z/OS, é o mesmo sistema operacional com diferentes nomes de batismo utilizados ao longo de sua evolução. Usarei apenas z/OS para referenciar o sistema operacional mais utilizado em zSystem;

2 – VM e z/VM são nomes diferentes para o mesmo sistema operacional Virtual Machine, utilizado quase que exclusivamente como Hipervisor. Usarei apenas z/VM para referências ao Hipervisor.

3 – Linux, diversos sabores estão disponíveis para execução no zSystem. Usarei Linux on z para referenciar quaisquer dos sabores de Linux em zSystem;

Nota: Existem outros sistemas operacionais como o VSE, zVSE e TPF, zTPF, como são de nichos específicos, vou me ater ao mais comuns e utilizados.

Sistemas Operacionais e Processadores.

Como já comentei, um dos diferenciais do zSystem para outros servidores é como os processadores são utilizados. Eles são utilizados de acordo com o sistema operacional ou a tarefa que será executada, como podemos ver na tabela.

S.O.	Processador	Especialidade
z/OS	CP	Processar cargas tradicionais, Assembler, COBOL, PL/I, C, FORTRAN, Bancos de dados DB2, IMS, ADABAS.
z/OS	zIIP	Processar cargas especiais, XML, JAVA, OFFLOAD
z/VM	IFL	Gerenciar servidores virtuais
Linux on z	IFL	Processar carga com origem em servidores virtuais Linux.

Razão para diferenciar processadores

Diferenciar os processadores por carga permite desenvolver novos sistemas de negócios, utilizando diferentes tecnologias e integrados com os sistemas tradicionais no zSystem (como Cobol por exemplo), sem impactar os custos do software (mensal, licenciamento e suporte).

Facilidade em alocar recursos humanos para o desenvolvimento de novos sistemas, modernização das aplicações sem necessidade de alterar a base de dados são outros benefícios proporcionados pela introdução dos processadores diferenciados por carga.

zSystem – Componentes da arquitetura

Agora que conhecemos os processadores e suas funções, vamos aos componentes internos do zSystem, e entender se os entusiastas desta plataforma estão corretos em suas alegações.

zSystem – PR/SM

Processo Resource/System Manager é o virtualizador de máquina em firmware – TYPE 1 hipervisor – o qual permite múltiplas partições lógicas compartilhem todos os recursos físicos da máquina, conceito pouco comum considerando que maioria dos servidores utilizam software como hipervisor.

O PR/SM além de gerenciar os processadores que atendem as aplicações, também é responsável por gerenciar os processadores que atendem os serviços internos como I/O, alocação de memória, balanceamento de carga, tudo de forma transparente para as máquinas virtualizadas z/OS, Linux ou z/VM. 

Para realizar parte de suas atividades o PR/SM utiliza os processadores SAP (System Assistent Processor)

Utilizando a configuração básica de uma z13 modelo 2964-707/N63 como modelo. O PR/SM faz a orquestração do uso dos recursos direcionando a carga z/OS tradicional (em vermelho) aos processadores CPs, a carga z/OS JAVA e XML (em verde) aos processadores zIIPs e a carga Linux (em azul) aos processadores IFL. Leitura interessante 

A memória será compartilhada entre todas as partições lógicas, z/OS ou Linux on z e para todos os serviços, não é necessário se preocupar se haverá invasão de memória, cada partição lógica só conhece os endereços de memória que a ela foram destinados pelo PR/SM.

O modelo apresentado – 2964-707/N63 – possui 63 processadores, com 39 em uso + 2 SPAREs, os demais 22 podem ser utilizados em diferentes ocasiões ou necessidades. Os processadores extras serão explicados oportunamente.

Resumo: O PR/SM é responsável por alocar e gerenciar as partições lógicas (z/OS, Linux, z/VISE), fornecendo acesso adequado aos processadores e memória. Tudo em acordo com a característica da carga de trabalho e com base em parâmetros previamente definidos de prioridade.

zSystem – Channel Subsystem

Channel Subsystem é o principal componente do subsistema de I/O, diferente de outros hardwares é uma composição, trabalho associado entre o PR/SM, processadores CPs, IFLs, e zIIP, com os processadores SAP (System Assistent Processor).

Os processadores que executam o código das aplicações não executam I/O 😬. O Channel Subsystem é o responsável por executar o I/O, os processadores CP, zIIP e IFL ficam 100% disponíveis para executar os códigos dos programas de aplicações.

Quando o código do programa solicita um read/write/rewrite do registro de um arquivo, a solicitação é gravada em memória e o processador é disponibilizado para processar o código de outro programa, podendo ser da mesma partição lógica ou de outra, segundo a gerencia do PR/SM.

Um dos processadores SAP lerá a memória com a solicitação de I/O, transformará a solicitação em endereços físicos – unidade de controle de I/O, unidade física de disco e fará a transferência da informação para realização do I/O, quando a informação é retornada, a área de memória é atualizada com a informação (SAP), no próximo ciclo do PR/SM o programa solicitante poderá ser reiniciado com a informação solicitada disponível para processamento.

Mesmo se considerarmos apenas um processador, na máquina, ele teria capacidade de processar em paralelo milhares de programas com excelente desempenho.

Importante: Quando um programa de aplicação solicita leitura, o processo no Channel Subsystem somente é iniciado se o dado não estiver em memória. Os processos de gravação sempre disparam o processo Channel Subsystem. Subsistemas transacionais como CICS, IMS, WAS  etc. banco de dados como DB2, IMS, ADABAS entre outros possuem buffers com registros mais acessados, mitigando a necessidade de I/O físico para leitura.

Resumo: O Channel Subsystem, associado ao PR/SM libera os processadores para processar o código das aplicações de negócios 100% do tempo. Os processadores SAP não entram na conta para cobrança de licenças de software ou suporte.

zSystem – Coupling Facility (z/OS somente)

Coupling Facility provavelmente é um dos conceitos mais disruptivos disponível em uma plataforma de hardware. Para entender sua concepção primeiro temos que entender o problema para o qual sua concepção veio atender.

O problema

A virtualização em computadores IBM iniciou em 1972 (System/370) trazendo grande avanço em termos de usabilidade do equipamento, podendo transformar uma máquina física em máquinas virtuais, assim era possível ter duas ou mais partições lógicas em uma mesma máquina.    

Não existe garantia da integridade das informações para atualização simultânea quando duas ou mais máquinas - físicas ou lógicas - acessam a mesma informação. Essa regra vale para qualquer hardware.

Até meados dos anos 90 a única forma de assegurar a integridade das informações era executar programas remotos, utilizando conectividade de rede, mas a latência da comunicação e o custo da execução remota eram condições inibidoras para a maior parte do processamento.

A solução

O laboratório IBM mais uma vez pensando fora da caixa, desenhou um sistema de memória que poderia ser compartilhado entre diferentes partições, para isso é capaz de fazer gestão independente dos dados em memória e orquestrar a fila de solicitações. Resumindo uma memória compartilhada entre as máquinas virtuais.

Para realizar a gestão independente da memória em diferentes partições lógicas implicaria em muita atividade para os processadores das aplicações (CP) os tornando mais lentos, assim, foi aplicada a mesma solução do subsistema de I/O (CHANNEL), foram criados processadores dedicados para o gerenciamento da memória e filas para execução.

Os processadores que executam o compartilhamento de informações em memória são os ICFs, Integrated Coupling Facility. A gerência da atividade e fila de execução é o PR/SM associado ao Channel Subsystem.

O Coupling Facility permitiu acoplar as partições lógicas z/OS para compartilharem os dados de arquivos e banco de dados em velocidade de memória, sem custos adicionais em licenciamento para software e suporte, pois todo o processamento das informações no CF é realizado pelos processadores ICFs.

O Coupling Facility evoluiu, passou a compartilhar dados entre partições lógicas de diferentes máquinas, veremos a seguir.

Parallel Sysplex (z/OS somente)

Parallel Sysplex pode ser traduzido como um “cluster de máquinas” trabalhando como sendo uma única, aumentando a capacidade horizontal de processamento (escalabilidade). Utilizando conexões de alta velocidade denominadas “Coupling Link” é possível conectar diferentes máquinas zSystem.

São os principais benefícios do Parallel Sysplex:

a)    Aumentar a escalabilidade do processamento – possível clonar sistemas em diferentes máquinas, todos acessando informações em banco de dados e arquivos de forma simultânea, sem alterar as aplicações e sem a latência da rede de comunicação;

b)    Integração das aplicações – a necessidade de replicar informações para diferentes arquivos e banco de dados acaba, assim como sistemas com informações em D-1, D-2, etc.

c)    Alta Disponibilidade – caso uma das máquinas (física ou virtual) apresente problema as demais acopladas no mesmo Sysplex assumirão a carga, ficando transparente aos usuários;

São as características dos sistemas que mais aderentes

a)    Sistemas online transacional de alto volume e missão crítica;

b)    Sistemas que necessitam de alta disponibilidade;

c)    Sistemas que possuem alto grau de integração por dados/registros/informações.

O Parallel Sysplex tem como base dois componentes o Coupling Link e o Coupling Facility, e para garantir a integridade dos dados um “relógio virtual”, componente denominado Sysplex Timer sincroniza o “clock” de todas as máquinas acopladas.

A configuração do Parallel Sysplex pode variar de acordo com a necessidade do cliente ou a característica da carga, podendo inclusive haver um ou mais zSystem exclusivo para Coupling Facility.

Representação da configuração de Parallel Sysplex interno nas máquinas, com duas partições lógicas por máquina te e um Coupling Facility por máquina as pretas são PR/SM. As conexões tipo “Coupling Link” são representados pelas setas vermelhas.

Representação da configuração de Parallel Sysplex em máquinas separadas, as conexões tipo “Coupling Link” são representadas pelas setas vermelhas. O Sysplex Timer sincroniza o “clock” de todas as máquinas.

Resumo: Parallel Sysplex é a possibilidade de ter sistemas integrados em alta disponibilidade e escalabilidade, com integridade de dados, mesmo executando o mesmo programa em diferentes máquinas  acessando as mesmas informações ao mesmo tempo.

Hipersocket

Hipersocket é uma tecnologia IBM embarcada na arquitetura z para prover comunicação de alta (mas muito alta) velocidade entre servidores virtualizados – z/OS ou Linux – hospedados em uma mesma máquina, provendo conexão TCP/IP em memória.

Toda comunicação se dá sobre memória, em velocidade de memória, aumentando performance das conexões, reduzindo latência da comunicação e melhorando a percepção o usuário final sobre o tempo de resposta.

Não menos importante que a possibilidade de executar comunicação entre servidores virtuais em velocidade de memória é o ganho em confiabilidade e disponibilidade da rede, não há gateway, router, spliter, adapters, repetidores para apresentarem defeitos ou cabos para tropeçarmos.

Continua ....