As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Práticas recomendadas
Esta seção descreve um conjunto de melhores práticas para enfrentar os principais desafios na replataforma de cargas de trabalho de mainframe em ambientes de nuvem e, ao mesmo tempo, manter o banco de dados no Db2 for z/OS.
Latência de rede
Para prever com precisão o impacto da latência da separação do aplicativo do banco de dados Db2 durante um esforço de reformulação de plataforma, recomendamos que você realize uma avaliação completa do número de chamadas do Db2 para transações e processos em lote. Essa avaliação deve ser feita usando dados de rastreamento e deve incluir as seguintes etapas:
-
Colete dados de rastreamento: reúna rastreamentos detalhados de transações representativas e trabalhos em lote e certifique-se de que os rastreamentos capturem todas as interações do Db2, incluindo entradas e saídas.
-
Analise os dados de rastreamento: conte o número de entradas e saídas do Db2 para cada transação e trabalho em lote e calcule o número médio de interações do Db2 por transação e processo em lote.
-
Meça os tempos de resposta atuais: verifique se o acesso ao Db2 está alinhado com o contrato de nível de serviço (SLA) do seu aplicativo.
-
Estime a latência da rede: determine a latência de rede esperada entre o aplicativo reformulado e o banco de dados Db2. Considere fatores como distância física, infraestrutura de rede e possíveis gargalos.
-
Calcule o impacto potencial: para cada transação e processo em lote, multiplique o número de entradas e saídas do Db2 pela latência estimada da rede. Adicione esse tempo calculado aos tempos de resposta atuais para prever o novo tempo total de processamento.
-
Avalie os resultados: avalie se o aumento previsto da latência é aceitável para seus requisitos de negócios e identifique quaisquer transações ou processos que possam exigir otimização ou redesenho para mitigar os problemas de latência.
-
Considere estratégias de mitigação: explore opções como pool de conexões, armazenamento em cache ou recuperação de dados em lote para reduzir o número de interações individuais do Db2. Avalie a possibilidade de mover dados acessados com frequência para mais perto do nível do aplicativo.
Seguindo essas etapas, você poderá tomar decisões baseadas em dados sobre a viabilidade de sua estratégia de replataforma e identificar possíveis problemas de desempenho antes que eles afetem seu ambiente de produção. Essa abordagem ajudará a garantir uma transição suave, mantendo níveis de desempenho aceitáveis para seus aplicativos dependentes de banco de dados.
Segurança
-
Proteja a criação do seu aplicativo: use uma sub-rede privada na nuvem privada virtual (VPC) para AWS CodeBuild executar e ajudar a garantir o isolamento e a segurança aprimorada. Implemente um contexto confiável do Db2 a partir do CIDR da CodeBuild sub-rede para acesso seguro ao banco de dados durante o processo de criação.
-
Proteja seu ambiente de tempo de execução: use um contexto confiável do Db2 da sub-rede CIDR de tempo de execução para conexões seguras de banco de dados.
-
Gerencie as credenciais do banco de dados com segurança: implemente um cronograma regular de rotação de credenciais para minimizar o risco de acesso não autorizado. Armazene as credenciais do Db2 com segurança no. AWS Secrets Manager
-
Estabeleça a segurança da rede: implemente regras sólidas de segmentação de rede e firewall para proteger os ambientes de construção e de tempo de execução. Use a combinação correta de AWS Direct Connect e AWS Site-to-Site VPN para alcançar o nível de segurança necessário.
-
Aplique criptografia: aplique criptografia para dados em trânsito entre seu aplicativo e o Db2 for z/OS.
Governança de aplicativos
-
Estabeleça uma fonte confiável: estabeleça o novo gerenciamento de configuração de software (SCM) — por exemplo, GitHub — como a única fonte confiável para o código do aplicativo migrado. Isso garante a consistência e elimina as discrepâncias de versão entre os ambientes de nuvem e mainframe durante o período de transição.
-
Atualize o processo de gerenciamento de mudanças: atualize o processo de gerenciamento de mudanças para considerar as modificações no código nesse novo paradigma de ambiente duplo. Esse processo deve incluir:
-
Fluxos de trabalho de aprovação claros para alterações de código.
-
Revisões obrigatórias do código antes de mesclar o código na ramificação principal.
-
Procedimentos de implantação sincronizados para garantir que os dois ambientes recebam atualizações simultaneamente.
-
Mecanismos de reversão em caso de problemas em qualquer ambiente.
-
Elasticidade
A elasticidade da computação em nuvem introduz uma mudança de paradigma que altera significativamente a estrutura de custos e o gerenciamento de recursos do mainframe. Diferentemente do ambiente tradicional de mainframe, que tem capacidade fixa e modelos de preços baseados em picos, as plataformas de nuvem oferecem escalabilidade dinâmica e uma pay-as-you-go abordagem que pode potencialmente levar a economias substanciais de custos e maior eficiência operacional.
Em um ambiente de nuvem, as organizações podem aumentar ou diminuir seus recursos de computação em tempo real com base na demanda real, o que elimina a necessidade de provisionamento excessivo para acomodar cargas de pico. Essa elasticidade permite que as empresas paguem apenas pelos recursos que consomem, em vez de investir em licenças caras de hardware e software para lidar com picos ocasionais no uso.
Para obter detalhes sobre como os preços funcionam AWS, consulte AWS Preços
