Editar

Partilhar via

Usar o LzLabs Software Defined Mainframe (SDM) em uma implantação de VM do Azure

Azure Virtual Machines
Azure Database for PostgreSQL
Azure Virtual Network
Azure Resource Manager

O LzLabs Software Defined Mainframe (SDM) reduz significativamente o risco e a complexidade da rehospedagem da carga de trabalho legada, eliminando a necessidade de localizar, modificar e recompilar o código-fonte de aplicativos legados. Essa abordagem permite que programas executáveis binários z/Architecture operem em velocidades nativas em computadores de arquitetura x86_64 executando uma pilha de software de sistemas abertos, abrindo o caminho para a modernização legada.

Arquitetura

Diagrama mostrando a arquitetura e o fluxo de dados descritos em detalhes pelo texto do artigo que acompanha o artigo.Faça o download de um arquivo SVG desta arquitetura.

Fluxo de Trabalho

  1. Os aplicativos SDM LzLabs são acessados como aplicativos de mainframe comuns por meio de um terminal 3270. Você pode usar qualquer emulador de terminal que você gosta. Para gerenciamento, administração e outras atividades, o cliente LzWorkbench é usado. O componente de servidor é executado na VM SDM.
  2. O acesso à porta é normalmente configurado para se adaptar aos requisitos de segurança do cliente.
  3. Para uma implementação segura do SDM, um front-end de serviços Web deve ser implementado que consiste em:
  4. O SDM pode ser configurado para failover com emparelhamento de rede virtual (VNet) para as regiões de backup, recuperação de desastres (DR) e Azure Secundário. Isso melhora a disponibilidade do SDM para cargas de trabalho de produção porque o Azure mantém uma réplica consistente caso a VM inicial fique offline.
  5. A máquina virtual SDM no ambiente de produção é replicada e mantida sincronizada na Região de Failover pelo Azure Site Recovery. Este serviço mantém o disco principal do SO para produção e as imagens de disco anexadas sincronizadas com o SDM da região secundária. Ele faz isso para todos os discos conectados, exceto o disco responsável pelo processamento do arquivo de índice (ver item 10). A Recuperação de Site também é usada para manter todas as outras imagens de VM sincronizadas com a Região Secundária.
  6. O banco de dados nesta arquitetura é PostgreSQL IaaS. Atualmente, o Serviço PostgreSQL do Azure não pode ser usado e o IaaS PostgreSQL deve ser usado com o SDM em implantações. Isso ocorre devido a uma limitação no Azure PostgreSQL para processar tipos de dados definidos pelo usuário (UDT). 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 o failover ocorre, o modo será definido como ativo. O mesmo processo é usado para manter o banco de dados de failover de produção transacionalmente consistente dentro da Região de Produção. Usando o log de transações Write Ahead para manter essas duas réplicas sincronizadas, a camada de banco de dados fica altamente disponível. Nota: Para obter o melhor desempenho, a VM de banco de dados e a VM SDM devem ser colocadas em um grupo de posicionamento de proximidade do Azure.
  7. Um front-end de serviços Web precisa ser implantado para a Região DR para manter o acesso seguro ao sistema. Muitas cargas de trabalho de mainframe têm uma camada de serviços da Web de API para acessar transações CICS e dados DB2.
  8. Para integração de identidade RACF e Top Secret usando extensões do Ative Directory, o LzVault fornece autenticação e autorização no Azure para as regras de segurança migradas do mainframe.
  9. O Barman Server está configurado na camada de dados. Isso fornece réplicas de instantâneo do banco de dados PostgreSQL para recuperação point-in-time na Região de Produção e na Região Secundária.
  10. Como mencionado no item 5, o disco que mantém o processamento de arquivos indexados 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 não pode garantir a consistência de transação necessária para um banco de dados. Como o processamento de arquivos indexados não está dentro do PostgreSQL, uma solução deve ser usada para fornecer isso.
  11. Para acomodar o agendamento do processamento de trabalho em lote, um agendador como Aplicativos Lógicos do Azure ou SMA deve ser usado.
  12. Para fornecer disponibilidade, há duas VMs 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 via 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 escaláveis e sob demanda que o Azure oferece. Uma máquina virtual (VM) do Azure oferece a flexibilidade da virtualização sem precisar comprar e manter o hardware físico que a executa.
  • As redes virtuais (VNets) são o bloco de construção fundamental para a sua rede privada na Rede Virtual do Azure. A Rede Virtual permite que muitos tipos de recursos do Azure, incluindo VMs, se comuniquem com segurança entre si, com a Internet e com 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 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 nessa arquitetura, você pode adicionar mais NICs à mesma VM, permitindo que as VMs filhas do Solaris tenham seu próprio dispositivo de interface de rede dedicado e endereço IP.
  • Os discos gerenciados do SSD do Azure são volumes de armazenamento em nível de bloco gerenciados pelo Azure e usados com as Máquinas Virtuais do Azure. Os tipos de discos disponíveis são Ultra Disk, SSDs Premium, SSDs Standard e Unidades de Disco Rígido (HDDs) Padrão. Para esta arquitetura, recomendamos SSDs Premium ou SSDs Ultra Disk.
  • O Armazenamento do Azure e os Arquivos do Azure oferecem compartilhamentos de arquivos totalmente gerenciados na nuvem que podem ser acessados por meio do protocolo SMB (Server Message Block) padrão do setor. As partilhas de ficheiros do Azure podem ser montadas em simultâneo por implementações na cloud ou no local do Windows, Linux e macOS.
  • O Azure ExpressRoute permite-lhe expandir as redes no local para a cloud da Microsoft através de uma ligação privada facilitada por um fornecedor de conectividade. Com o ExpressRoute, pode ligar aos serviços cloud da Microsoft, tais como o Microsoft Azure e o Office 365.
  • O Banco de Dados SQL do Azure é um mecanismo de banco de dados de plataforma como serviço (PaaS) totalmente gerenciado que lida com a maioria das funções de gerenciamento de banco de dados sem o envolvimento do usuário, incluindo atualização, aplicação de patches, backups e monitoramento. O Banco de Dados SQL do Azure está sempre em execução na versão estável mais recente do mecanismo de banco de dados do SQL Server e no sistema operacional com patch com 99,99% de disponibilidade. As funcionalidades de PaaS incorporadas na Base de Dados SQL do Azure permitem-lhe que se concentre nas atividades de administração e otimização da base de dados específica do domínio que são essenciais para a sua empresa.

Detalhes do cenário

O LzLabs Software Defined Mainframe (SDM) é uma plataforma de rehospedagem de carga de trabalho e modernização de aplicativos de mainframe. O SDM permite que aplicativos legados de mainframe sejam executados em sistemas abertos sem a necessidade de alterações no código-fonte, recompilação ou conversão de tipos de dados. O SDM também possui recursos que permitem que aplicativos legados sejam graciosamente modernizados para linguagens e implementações contemporâneas, sem comprometer a integridade ou a operação do sistema como um todo.

O SDM reduz significativamente o risco e a complexidade da rehospedagem da carga de trabalho herdada, 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 em velocidades nativas em computadores de arquitetura x86_64 executando uma pilha de software de sistemas abertos, abrindo o caminho para a modernização legada.

Potenciais casos de utilização

  • Sem código-fonte. 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 a solução for uma solução personalizável pronta para uso (COTS) comprada de um fornecedor de software independente que não fez o código-fonte para o IP. Além disso, como muitos desses aplicativos baseados em COBOL foram escritos há muito tempo, o código-fonte pode ter sido perdido ou extraviado. LzLabs resolve este problema porque tudo o que é necessário são os módulos de carga (binários) para execução em SDM.
  • O cliente tem código-fonte e quer rehospedar. O cliente ainda pode ter o código-fonte e simplesmente querer rehospedar suas cargas de trabalho de mainframe para reduzir custos e aproveitar os benefícios de uma plataforma de nuvem como o Azure. O código COBOL pode ser mantido no SDM em um ambiente DevOps moderno.
  • Ativação pós-falha. Para aumentar o tempo de atividade e evitar possíveis interrupções na continuidade dos negócios, os clientes podem usar o LzLabs SDM para um ambiente de failover. Nesse caso, os módulos de carga são carregados no SDM e usados como um ambiente secundário se o ambiente de produção ficar indisponível.

Considerações

As considerações a seguir, com base no Azure Well-Architected Framework, aplicam-se a esta solução.

Disponibilidade

A disponibilidade para a camada de aplicativo é fornecida com a Recuperação de Site, conforme mostrado no diagrama. Como o LzLabs SDM 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 o portal do Azure ou modelos e scripts do Azure Resource Manager. Isso permite a administração de ativos (como redimensionamento) e gerenciamento de segurança e acesso. O gerenciamento do ambiente SDM real é fornecido por meio da ferramenta de administração LzWorkbench. Isto permite a criação e gestão de ambientes de execução no SDM.

Eficiência de desempenho

Ao migrar cargas de trabalho de mainframe para o Azure, lembre-se de que a proporção MIPS por vCPU varia de 50 a 150 MIPS por vCPU. Isso pode variar dependendo do tipo de carga de trabalho. Você precisará traçar o perfil da carga de trabalho de mainframe para ambientes online e em lote e, em seguida, dimensionar os recursos de acordo.

Escalabilidade

Atualmente, a solução para dimensionar o SDM é aumentar a escala das 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 Gerenciador de Recursos do Azure. A segurança do SDM é gerenciada usando o componente Vault do SDM. Isso migra a segurança e as permissões do RACF ou Top Secret para um ambiente baseado em LDAP para gerenciamento no Azure.

Otimização de custos

Para estimar o custo dos produtos e configurações do Azure, visite a calculadora de preços do Azure.

Para saber mais sobre os preços dos produtos LzLabs Software Defined Mainframe e seus serviços relacionados, visite o site da LzLabs.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos

  • Para mais informações, contacte legacy2azure@microsoft.com

Veja os seguintes recursos do LzLabs:

Consulte a seguinte documentação da Microsoft:

Consulte os seguintes artigos relacionados no Centro de Arquitetura do Azure: