Editar

Compartilhar via


Refatorar sistemas de computador mainframe que executam o Adabas & Natural

AKS (Serviço de Kubernetes do Azure)
Azure ExpressRoute
Azure Managed Disks
Azure NetApp Files

A Software AG fornece uma plataforma popular de mainframe 4GL baseada na linguagem de programação Natural e no banco de dados Adabas. Este artigo mostra uma arquitetura para organizações que usam computadores mainframe que executam o Adabas & Natural e que estão procurando maneiras de modernizar essas cargas de trabalho e movê-las para a nuvem.

Arquitetura de mainframe

Este diagrama ilustra um exemplo de mainframe com os módulos Adabas & Natural da Software AG instalados, antes da migração para o Azure. Este exemplo mostra uma arquitetura do IBM z/OS.

Diagrama que mostra uma arquitetura de mainframe que usa o Adabas & Natural da Software AG antes da migração para o Azure.

Baixe um Arquivo Visio dessa arquitetura.

Workflow

R. A entrada é feita por TCP/IP, incluindo TN3270 e HTTP(S). A entrada no mainframe utiliza protocolos de mainframe padrão.

B. O recebimento de aplicativos pode ser em lotes ou sistemas online.

C. As linguagens Natural, COBOL, PL/I, Assembler ou outras compatíveis são executadas em um ambiente habilitado.

D. Os serviços de dados e banco de dados comumente usados são sistemas de banco de dados hierárquicos/de rede e tipos de bancos de dados relacionais.

E. Os serviços comuns incluem execução de programa, operações de E/S, detecção de erros e proteção no ambiente.

F. O middleware e os utilitários gerenciam serviços como armazenamento em fita, enfileiramento, saída e serviços Web no ambiente.

G. Os sistemas operacionais fornecem a interface entre o mecanismo e o software que ele executa.

H. Partições são necessárias para executar cargas de trabalho separadas e separar os tipos de trabalho no ambiente.

Arquitetura do Azure

Este diagrama mostra como migrar a arquitetura herdada para o Azure usando uma abordagem de refatoração para modernizar o sistema:

Diagrama mostrando a arquitetura herdada após a migração para o Azure.

Baixe um Arquivo Visio dessa arquitetura.

Workflow

  1. Entrada. A entrada normalmente é feita via Azure ExpressRoute de clientes remotos ou por meio de outros aplicativos em execução no Azure. Nos dois casos, as conexões TCP/IP são o principal meio de conexão com o sistema. A porta TLS 443 fornece acesso a aplicativos baseados na Web. Você pode deixar a camada de apresentação de aplicativos baseados na Web praticamente inalterada para minimizar a readaptação do usuário. Se preferir, você pode atualizar essa camada com estruturas de UX modernas, conforme suas necessidades. Para acesso administrativo às VMs, você pode utilizar hosts do Azure Bastion para maximizar a segurança minimizando as portas abertas.

  2. Acesso no Azure. No Azure, o acesso aos clusters de cálculo de aplicativo ocorre via balanceador de carga do Azure. Essa abordagem permite que os recursos de computação de expansão processem o trabalho de entrada. Você pode usar balanceadores de carga de nível 7 (aplicativo) ou nível 4 (protocolo de rede). Entretanto, o tipo de balanceador de carga a ser usado depende de como a entrada do aplicativo chega ao ponto de entrada do cluster de cálculo. Recomendamos usar o Gateway de Aplicativo do Azure com recursos de firewall de aplicativos Web para tráfego da camada 7.

  3. Clusters de cálculo de aplicativo. A arquitetura tem suporte para aplicativos executados em um contêiner que pode ser implantado no Serviço de Kubernetes do Azure (AKS). Os componentes do Adabas & Natural podem ser executados dentro de contêineres baseados em Linux. Você pode rearquitetar os aplicativos herdados em arquiteturas modernas baseadas em contêiner e operar nos AKS.

  4. Emulação de terminal ApplinX (Software AG). O ApplinX é uma tecnologia baseada em servidor que fornece conectividade Web e integração aos principais aplicativos do sistema sem exigir alterações nos aplicativos. O Natural Online permite que os usuários online se conectem a aplicativos Natural por um navegador da web. Sem o ApplinX, os usuários precisam se conectar com o software de emulação de terminal usando SSH. Os dois sistemas são executados em contêineres.

  5. EntireX (Software AG). O EntireX permite conectar facilmente os serviços executados no Integration Server a programas críticos escritos em linguagens como COBOL e Natural. O Natural Business Services permite o acesso por API a funções de negócios programadas em Natural. Os dois sistemas são executados em contêineres.

  6. Adabas (Software AG). O Adabas é um sistema de gerenciamento de banco de dados NoSQL de alto desempenho. O Natural batch (Software AG) é um componente dedicado para executar trabalhos em lote. Os trabalhos Natural batch, que são agendados por um sistema de agendamento de trabalhos em lote da sua escolha, devem ser executados no mesmo nó que o banco de dados Adabas para evitar impacto no desempenho.

  7. Armazenamento. Os serviços de dados usam uma combinação de armazenamento de alto desempenho (SSD Ultra/Premium), armazenamento de arquivos (NetApp) e armazenamento padrão (Blob, arquivamento e backup) que podem ser redundantes localmente ou ter redundância geográfica, dependendo do uso. Os sistemas operacionais de nó usam o armazenamento em disco gerenciado. Todos os dados persistentes, como arquivos de banco de dados, logs de proteção, dados de aplicativo e backup, usam o Azure NetApp Files. O AKS gerencia volumes do sistema operacional armazenados em discos gerenciados. Todos os dados críticos para os negócios dos bancos de dados, incluindo arquivos ASSO, DATA, WORK e logs de proteção Adabas, devem ser gravados em volumes separados em Azure NetApp Files.

  8. CONNX. O módulo CONNX for Adabas fornece acesso de leitura/gravação altamente seguro e em tempo real a fontes de dados Adabas no OS/390, z/OS, VSE, Linux, Solaris, HP-UX, AIX e Windows via .NET, ODBC, OLE DB e JDBC. O CONNX fornece uma camada de virtualização de dados que emprega conectores para Adabas e outras fontes de dados, como o Banco de Dados SQL do Azure, o Banco de Dados do Azure para PosgreSQL e o Banco de Dados do Azure para MySQL.

Componentes

  • O Azure ExpressRoute estende suas redes locais até a nuvem da Microsoft por meio de uma conexão privada que é facilitada por um provedor de conectividade. Você pode usar o ExpressRoute para estabelecer conexões com serviços do Microsoft Cloud, como o Azure e o Office 365. Como alternativa, ou como backup, você pode estabelecer conexões com o Gateway de VPN do Azure. No entanto, recomendamos usar o ExpressRoute para que você possa se conectar ao ambiente do Azure por meio de uma conexão privada de alta velocidade de segurança aprimorada.

  • O AKS é o serviço Kubernetes totalmente gerenciado para implantar e gerenciar aplicativos conteinerizados. O AKS oferece Kubernetes sem servidor, uma experiência integrada de integração contínua/entrega contínua (CI/CD) e segurança e governança de nível empresarial. Nesse cenário, os contêineres Adabas & Natural estão implantados no AKS.

  • Os Azure 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. Há vários tipos disponíveis: discos ultra, SSD premium, SSD standard e HDD standard. Discos SSD são usados nessa arquitetura. Nesse cenário, todos os volumes do sistema operacional são armazenados em discos gerenciados do Azure.

  • O Azure NetApp Files fornece compartilhamentos de arquivos do Azure de nível empresarial fornecidos pela NetApp. O Azure NetApp Files facilita a migração e a execução de aplicativos complexos baseados em arquivo sem alterar o código. Nesse cenário, todos os dados persistentes, como arquivos de banco de dados, logs de proteção, dados de aplicativo e arquivos de backup, usam o Azure NetApp Files.

Detalhes do cenário

Os aplicativos executados em computadores mainframe têm estado no cerne da maioria das operações de negócios há quase 50 anos. Embora esses sistemas mainframe tenham oferecido uma confiabilidade fantástica ao longo dos anos, eles se tornaram um tanto problemáticos porque são rígidos e, em alguns casos, difíceis de manter e caros de operar.

Muitas organizações estão procurando maneiras de modernizar esses sistemas. Elas estão procurando formas de liberar os recursos restritos necessários para manter esses sistemas, controlar custos e obter mais flexibilidade nas interações com os sistemas.

A Software AG fornece uma plataforma popular de mainframe 4GL baseada na linguagem de programação Natural e no banco de dados Adabas.

Dois dos padrões de racionalização na nuvem permitem executar aplicativos Adabas & Natural no Azure: reospedagem e refatoração. Este artigo descreve como refatorar um aplicativo usando contêineres que são gerenciados no Serviço Azure Kubernetes (AKS). Para obter mais informações, consulte Abordagem baseada em contêiner, mais adiante neste artigo.

Possíveis casos de uso

Essa arquitetura se aplica a qualquer organização que usa computadores mainframe executando o Adabas & Natural e planeja modernizar essas cargas de trabalho e movê-las para a nuvem.

Considerações

Abordagem baseada em contêiner

Para aproveitar ao máximo a flexibilidade, a confiabilidade e as funcionalidades do Azure, você precisa rearquitetar os aplicativos de mainframe. Recomendamos que você reescreva os aplicativos monolíticos como microsserviços e use uma abordagem baseada em contêiner para a implantação. Um contêiner agrupa todo o software necessário para a execução em um pacote executável. Ela inclui o código de um aplicativo, junto com os arquivos de configuração relacionados, bibliotecas e dependências que são necessários para executar o aplicativo. Os aplicativos conteinerizados são rápidos para implantar e aceitam práticas populares de DevOps, como integração contínua (CI) e implantação contínua (CD).

Os contêiners Adabas & Natural são executados em pods, sendo que cada um executa uma tarefa específica. Pods são unidades de um ou mais contêineres que permanecem juntos no mesmo nó e compartilham recursos como o nome do host e o endereço IP. Como são separados da plataforma subjacente, os componentes nos pods são dimensionados de forma independente e permitem maior disponibilidade. Um aplicativo conteinerizado também é portátil: é executado uniforme e consistentemente em qualquer infraestrutura.

Os serviços em contêineres e os componentes de sistema de rede e armazenamento associados precisam ser orquestrados e gerenciados. Recomendamos o AKS, um serviço de Kubernetes gerenciado que automatiza o gerenciamento de clusters e de recursos. Você designa o número de nós necessários e o AKS ajusta os contêineres nos nós certos para fazer o melhor uso dos recursos. O AKS também aceita distribuições e reversões automatizadas, detecção de serviços, balanceamento de carga e orquestração de armazenamento. E o AKS tem suporte para autorrecuperação: se um contêiner falhar, o AKS iniciará um novo. Além disso, você pode armazenar segredos e parâmetros de configuração fora dos contêineres com segurança.

O diagrama de arquitetura mostrado neste artigo mostra uma implementação baseada em contêiner do Adabas & Natural. Ao configurar o AKS, você especifica o tamanho da VM do Azure para os nós, o que define as CPUs, a memória e o tipo de armazenamento, como unidades de estado sólido (SSDs) de alto desempenho ou unidades de disco rígido (HDDs) comuns. O Natural deve ser executado em três instâncias ou mais de VM (nós) para aumentar a escalabilidade e a disponibilidade da interface de usuário (Natural Online mais ApplinX) e da camada de API (Natural Services mais EntireX).

Na camada de dados, o Adabas é executado no cluster do AKS, que é automaticamente expandido e reduzido horizontalmente com base no uso de recursos. Você pode executar vários componentes do Adabas no mesmo pod ou, para maior escala, o AKS pode distribuí-los entre vários nós do cluster. O Adabas usa o Azure NetApp Files, um serviço de armazenamento de arquivos limitado de alto desempenho, para todos os dados persistentes, como arquivos de banco de dados, logs de proteção, dados de aplicativo e backup.

Posicione os pods de lotes do Natural na mesma zona de disponibilidade (datacenter) que os pods do Adabas. Você deve usar grupos de posicionamento por proximidade para posicionar os pods de lote do Adabas e do Natural no mesmo pool de nós dentro da mesma zona de disponibilidade.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança.

Essa arquitetura é criada principalmente no Kubernetes, que inclui componentes de segurança como segredos e padrões de segurança de pod. O Azure fornece recursos de segurança adicionais, como o Microsoft Entra ID, o Microsoft Defender para contêineres, o Azure Policy, o Azure Key Vault, grupos de segurança de rede e atualizações de cluster orquestrado. Os contêineres refatorados devem ser implantados em um cluster de AKS privado com acesso de entrada por meio de um servidor de API privado e endereços IP internos. Todo o tráfego de saída deve ser roteado através de uma camada de firewall de saída.

Otimização de custos

A Otimização de Custos trata da redução de despesas desnecessárias e da melhoria da eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design para otimização de custos.

Excelência operacional

A Excelência operacional abrange os processos de operações que implantam uma aplicação e as mantêm em execução em produção. Para obter mais informações, consulte Lista de verificação de revisão de design para Excelência Operacional.

A refatoração permite a adoção mais rápida da nuvem. Ela também promove a adoção de princípios operacionais de DevOps e Agile. Você tem total flexibilidade das opções de implantação de desenvolvimento e produção.

Eficiência de desempenho

A eficiência do desempenho é a capacidade de dimensionar a carga de trabalho para atender às demandas exigidas pelos usuários de maneira eficiente. Para obter mais informações, consulte Lista de verificação de revisão de design para eficiência de desempenho.

O Kubernetes fornece um dimensionador automático de cluster. O dimensionador automático ajusta o número de nós com base nos recursos de computação solicitados no pool de nós. Ela monitora o servidor de API de métricas a cada 10 segundos para ver se há alterações que precisam ser feitas na contagem de nós. Se o dimensionador automático de cluster determinar que uma alteração é necessária, o número de nós no cluster do AKS aumentará ou diminuirá de acordo. 

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

  • Marlon Johnson | TPM Sênior

Colaborador:

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.

Estes são alguns recursos adicionais: