O Software Defined Mainframe (SDM) da LzLabs reduz consideravelmente o risco e a complexidade da reospedagem de cargas de trabalho herdadas eliminando a necessidade de encontrar, modificar e recompilar o código-fonte de aplicativos herdados. Essa abordagem permite que programas executáveis binários z/Architecture operem a velocidades nativas em computadores de arquitetura x86_64, que executam uma pilha de software de sistemas abertos, abrindo o caminho para a modernização de componentes herdados.
Arquitetura
Baixe um arquivo SVG dessa arquitetura.
Workflow
- Os aplicativos de SDM do LzLabs são acessados como aplicativos de mainframe comuns por meio de um terminal 3270. Você pode usar qualquer emulador de terminal que desejar. Para gerenciamento, administração e outras atividades, usa-se o cliente LzWorkbench. O componente de servidor é executado na VM do SDM.
- O acesso à porta normalmente é configurado para se adaptar aos requisitos de segurança do cliente.
- Para uma implementação segura do SDM, um front-end de serviços Web deve ser implementado, o qual consiste em:
- Gateway de Aplicativo do Azure para APIs do CICS com acesso pela Web,
- Azure Bastion para acesso seguro para gerenciar as VMs,
- e um Azure Load Balancer.
- O SDM pode ser configurado para failover com o emparelhamento de VNet (rede virtual) para backup e DR (recuperação de desastre) das regiões Secundárias do Azure. Isso melhora a disponibilidade do SDM para cargas de trabalho de produção, pois o Azure mantém uma réplica consistente caso a VM inicial fique offline.
- A máquina virtual do SDM no ambiente de produção é replicada e mantida em sincronia na Região de Failover pelo Azure Site Recovery. Esse serviço mantém o principal disco de SO para produção e as imagens de disco anexadas em sincronia com o SDM da Região Secundária. Ele faz isso para todos os discos anexados, exceto o disco responsável pelo processamento do arquivo de índice (confira o item 10). O Site Recovery também é usado para manter todas as outras imagens da VM em sincronia com a Região Secundária.
- O banco de dados nessa arquitetura é a IaaS do PostgreSQL. No momento, o Serviço PostgreSQL do Azure não pode ser usado e a IaaS do PostgreSQL deve ser usada com o SDM nas implantações. Isso se deve a uma limitação no PostgreSQL do Azure para processamento de UDT (tipos definidos pelo usuário). A instância do banco de dados na Região Secundária é mantida atualizada com o Log de Transações Write-Ahead. Isso permite o failover entre regiões. Quando ocorrer um failover, o modo será definido como ativo. O mesmo processo é usado para manter o banco de dados de failover de produção transacionalmente consistente na Região de Produção. Usando o Log de Transações Write-Ahead para manter essas duas réplicas em sincronia, a camada de banco de dados é altamente disponível. Observação: para melhor desempenho, a VM do banco de dados e a VM do SDM devem ser colocadas em um grupo de posicionamento por proximidade do Azure.
- Um front-end de serviços Web precisa ser implantado para a Região de DR para manter o acesso ao sistema seguro. Muitas cargas de trabalho de mainframe têm uma camada de serviços Web de API para acessar as transações do CICS e os dados do DB2.
- Para a integração de identidade RACF e Top Secret usando extensões do Active Directory, o LzVault fornece autenticação e autorização no Azure para as regras de segurança migradas do mainframe.
- O Servidor Barman está configurado na Camada de Dados. Isso fornece réplicas de instantâneo do banco de dados PostgreSQL para recuperação pontual na Região de Produção e na Região Secundária.
- Conforme mencionado no item 5, o disco que mantém o processamento de arquivo indexado para SDM precisa ser sincronizado entre regiões usando uma solução de espelhamento de banco de dados. Isso ocorre porque o Azure Site Recovery pode garantir a consistência de transação necessária para um banco de dados. Como o processamento de arquivo indexado não está no PostgreSQL, é necessário usar uma solução que possa fornecer isso.
- Para permitir o agendamento do processamento de trabalho em lotes, um agendador como os Aplicativos Lógicos do Azure ou o SMA deve ser usado.
- Para fornecer disponibilidade, há duas VMs do SDM implantadas em um conjunto de disponibilidade do Azure. O Azure Load Balancer fornece serviços de balanceamento de carga para as duas VMs. O estado é compartilhado entre as duas VMs usando um disco compartilhado do Azure. Isso é replicado por meio do DRDB para a instância de DR.
Componentes
- As Máquinas Virtuais do Azure são um dos vários tipos de recursos de computação sob demanda escalonáveis oferecidos pelo Azure. Uma VM (máquina virtual) do Azure oferece a flexibilidade da virtualização sem precisar comprar e manter o hardware físico que as executa.
- As VNets (redes virtuais) são o bloco de construção fundamental para rede privada na Rede Virtual do Azure. A Rede Virtual permite que muitos tipos de recursos do Azure, incluindo VMs, comuniquem-se de maneira segura uns com os outros, com a Internet e com as redes locais. A Rede Virtual é semelhante a uma rede tradicional que você operaria em seu próprio datacenter, mas com os benefícios adicionais da infraestrutura do Azure, como dimensionamento, disponibilidade e isolamento.
- A NIC (Interface de Rede Virtual) do Azure é um controlador de interface de rede (NIC) que permite que uma VM do Azure se comunique com a Internet, outros recursos no Azure e recursos locais. Conforme mostrado nesta arquitetura, você pode adicionar mais NICs à mesma VM, permitindo que as VMs filho do Solaris tenham seu próprio dispositivo de interface de rede dedicado e endereço IP.
- Os Azure SSD Managed Disks são volumes de armazenamento em nível de bloco que são gerenciados pelo Azure e usados com Máquinas Virtuais do Azure. Os tipos de discos disponíveis são Disco Ultra, SSDs Premium, SSDs Standard e HDDs (Unidades de Disco Rígido) Standard. Para esta arquitetura, recomendamos SSDs Premium ou SSDs de Disco Ultra.
- O Armazenamento do Microsoft Azure e os Arquivos do Azure oferecem compartilhamentos de arquivos totalmente gerenciados na nuvem que são acessíveis por meio do protocolo SMB padrão do setor. Os compartilhamentos de arquivos do Azure podem ser montados de maneira simultânea por implantações locais ou na nuvem do Windows, do Linux e do MacOS.
- O Azure ExpressRoute permite que você estenda suas redes locais para a nuvem da Microsoft por meio de uma conexão privada facilitada por um provedor de conectividade. Com o ExpressRoute, você pode estabelecer conexões com os serviços em nuvem da Microsoft, como o Microsoft Azure e o Office 365.
- O Banco de Dados SQL do Azure é um mecanismo de banco de dados de PaaS (plataforma como serviço) totalmente gerenciado que lida com a maioria das funções de gerenciamento de banco de dados, sem o envolvimento do usuário, como atualização, aplicação de patch, backups e monitoramento. O Banco de Dados SQL do Azure está sempre sendo executado na versão estável mais recente do mecanismo de banco de dados do SQL Server e no SO corrigido com 99,99% de disponibilidade. As funcionalidades de PaaS internas do Banco de Dados SQL do Azure permitem que você se concentre nas atividades de administração e otimização de banco de dados específicas do domínio que são essenciais para sua empresa.
Detalhes do cenário
O SDM (Mainframe Definido pelo Software) do LzLabs é uma plataforma de modernização de aplicativos de mainframe e nova hospedagem de carga de trabalho. O SDM permite que aplicativos herdados de mainframe sejam executados em sistemas abertos, sem necessidade de alterações de código-fonte, recompilação ou conversão de tipos de dados. O SDM também tem recursos que permitem que os aplicativos herdados sejam modernizados normalmente para linguagens e implementações atuais, sem comprometer a integridade ou a operação do sistema como um todo.
O SDM reduz consideravelmente o risco e a complexidade da nova hospedagem de cargas de trabalho herdadas, eliminando a necessidade de localizar, modificar e recompilar o código-fonte de aplicativos herdados. Essa abordagem permite que programas executáveis binários z/Architecture operem a velocidades nativas em computadores de arquitetura x86_64, que executam uma pilha de software de sistemas abertos, abrindo o caminho para a modernização de componentes herdados.
Possíveis casos de uso
- Sem código-fonte. O LzLabs é uma solução para clientes que têm cargas de trabalho de mainframe, mas não têm o código-fonte para os aplicativos em execução. Isso pode acontecer se for uma solução personalizável COTS (commercial off-the-shell) comprada de um fornecedor de software independente que não forneceu o código-fonte para o IP. Além disso, como muitos desses aplicativos baseados em COBOL foram gravados há muito tempo, o código-fonte pode ter sido perdido ou extraviado. O LzLabs resolve esse problema porque tudo o que é necessário são os módulos de carga (binários) para execução no SDM.
- O cliente tem o código-fonte e deseja hospedar novamente. O cliente ainda pode ter o código-fonte e simplesmente deseja hospedar novamente as cargas de trabalho de mainframe para reduzir o custo e aproveitar os benefícios de uma plataforma de nuvem como o Azure. O código do COBOL pode ser mantido no SDM em um ambiente moderno de DevOps.
- Failover. Para aumentar o tempo de atividade e evitar possíveis interrupções na continuidade dos negócios, os clientes podem usar o SDM do LzLabs para um ambiente de failover. Nesse caso, os módulos de carga são carregados no SDM e usados como ambiente secundário, se o ambiente de produção ficar indisponível.
Considerações
Com base no Azure Well-Architected Framework, as seguintes considerações são aplicáveis a esta solução.
Disponibilidade
A disponibilidade para a camada de aplicativo é fornecida com o Site Recovery, conforme mostrado no diagrama. Como o SDM do LzLabs aproveita o PostgreSQL para a camada de banco de dados, a disponibilidade é fornecida com um log de transações write-ahead. Isso garante que o banco de dados secundário seja transacionalmente consistente com o banco de dados de produção.
Operações
O ambiente do Azure no diagrama é gerenciado com os scripts e modelos do Azure Resource Manager ou portal do Azure. Isso permite a administração de ativos (como redimensionamento) e o gerenciamento de segurança e acesso. O gerenciamento do ambiente real do SDM é fornecido por meio da ferramenta de administração LzWorkbench. Isso permite a criação e o gerenciamento de ambientes de execução no SDM.
Eficiência de desempenho
Ao migrar cargas de trabalho de mainframe para o Azure, tenha em mente que a taxa de MIPS por vCPU varia de 50 a 150 MIPS por vCPU. Isso pode variar dependendo do tipo de carga de trabalho. Você precisará criar o perfil da carga de trabalho de mainframe para ambientes online e em lotes e, em seguida, dimensionar os recursos de acordo.
Escalabilidade
No momento, a solução para dimensionamento do SDM é escalar verticalmente as máquinas virtuais adicionando mais vCPUs e memória.
Segurança
O acesso aos ativos do Azure é gerenciado por meio do portal do Azure e/ou do Azure Resource Manager. A segurança do SDM é gerenciada usando o componente de Cofre do SDM. Isso migra a segurança e as permissões do RACF ou do Top Secret para um ambiente baseado em LDAP para gerenciamento no Azure.
Otimização de custo
Para estimar o custo de produtos e configurações do Azure, acesse a calculadora de preços do Azure.
Para saber mais sobre os preços dos produtos de Mainframe Definido pelo Software do LzLabs e seus serviços relacionados, acesse o site do LzLabs.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Autor principal:
- Jonathon Frost | Engenheiro de Software Principal
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.
Próximas etapas
- Para obter mais informações, entre em contato com legacy2azure@microsoft.com.
Consulte os seguintes recursos da LzLabs:
- Site do LzLabs
- Visão geral do produto Mainframe Definido pelo Software do LzLabs
- LzWorkbench
- Biblioteca de vídeos do LzLabs
Consulte a seguinte documentação da Microsoft:
- Máquinas virtuais no Azure
- Documentação da Rede Virtual do Azure
- Documentação do modelo do Azure Resource Manager
- Documentação do Azure ExpressRoute
- White paper Desmistificando a migração de mainframe para o Azure
- Centro de migração de mainframe do Azure
- Visão geral da migração de mainframe
- Cargas de trabalho de mainframe compatíveis com Azure
- Reosting do mainframe em máquinas virtuais do Azure
Recursos relacionados
Consulte os seguintes artigos relacionados no Centro de Arquitetura do Azure: