Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Prácticas recomendadas
En esta sección, se describe un conjunto de prácticas recomendadas para abordar los principales desafíos que supone la conversión de las cargas de trabajo del mainframe a entornos de nube y, al mismo tiempo, mantener la base de datos en Db2 for z/OS.
Latencia de la red
Para predecir con precisión el impacto que tendrá en la latencia la separación de la aplicación de la base de datos de Db2 durante un proceso de cambio de plataforma, le recomendamos que lleve a cabo una evaluación exhaustiva del número de llamadas a Db2, tanto para las transacciones como para los procesos por lotes. Esta evaluación debe realizarse mediante datos de rastreo e incluir los siguientes pasos:
-
Recopile datos de rastreo: Recopile trazas detalladas de transacciones representativas y trabajos por lotes, y asegúrese de que las trazas capturen todas las interacciones de Db2, incluidas las entradas y salidas.
-
Analice los datos de rastreo: cuente el número de entradas y salidas de Db2 para cada transacción y trabajo por lotes, y calcule el número promedio de interacciones de Db2 por transacción y proceso por lotes.
-
Mida los tiempos de respuesta actuales: compruebe si el acceso a Db2 cumple con el acuerdo de nivel de servicio (SLA) de su aplicación.
-
Calcule la latencia de la red: determine la latencia de red esperada entre la aplicación con la nueva plataforma y la base de datos de Db2. Tenga en cuenta factores como la distancia física, la infraestructura de red y los posibles cuellos de botella.
-
Calcule el impacto potencial: para cada transacción y proceso por lotes, multiplique el número de entradas y salidas de Db2 por la latencia de red estimada. Agregue este tiempo calculado a los tiempos de respuesta actuales para predecir el nuevo tiempo total de procesamiento.
-
Evalúe los resultados: evalúe si el aumento de latencia previsto es aceptable para los requisitos de su empresa e identifique cualquier transacción o proceso que pueda requerir una optimización o un rediseño para mitigar los problemas de latencia.
-
Considere estrategias de mitigación: explore opciones como la agrupación de conexiones, el almacenamiento en caché o la recuperación de datos por lotes para reducir el número de interacciones individuales de Db2. Evalúe la posibilidad de acercar los datos a los que se accede con frecuencia al nivel de la aplicación.
Si sigue estos pasos, podrá tomar decisiones basadas en datos sobre la viabilidad de su estrategia de cambio de plataforma e identificar cualquier posible problema de rendimiento antes de que afecte a su entorno de producción. Este enfoque ayudará a garantizar una transición fluida y, al mismo tiempo, a mantener niveles de rendimiento aceptables para las aplicaciones que dependen de las bases de datos.
Seguridad
-
Proteja la creación de su aplicación: utilice una subred privada en la nube privada virtual (VPC) para AWS CodeBuild ejecutarla y así garantizar el aislamiento y mejorar la seguridad. Implemente un contexto de confianza de Db2 desde la CodeBuild subred CIDR para garantizar el acceso a la base de datos durante el proceso de creación.
-
Proteja su entorno de ejecución: utilice un contexto confiable de Db2 de la subred de ejecución CIDR para proteger las conexiones de bases de datos.
-
Administre las credenciales de la base de datos de forma segura: implemente un programa de rotación de credenciales regular para minimizar el riesgo de acceso no autorizado. Guarde las credenciales de Db2 de forma segura en. AWS Secrets Manager
-
Establezca la seguridad de la red: Implemente reglas sólidas de segmentación de red y firewall para proteger los entornos de construcción y tiempo de ejecución. Utilice la combinación correcta de AWS Direct Connect y AWS Site-to-Site VPN para lograr el nivel de seguridad necesario.
-
Aplique el cifrado: aplique el cifrado de los datos en tránsito entre su aplicación y Db2 for z/OS.
Gobernanza de aplicaciones
-
Establezca una fuente de verdad: establezca la nueva administración de configuración de software (SCM), por ejemplo, GitHub como la única fuente de verdad para el código de la aplicación migrada. Esto garantiza la coherencia y elimina las discrepancias de versión entre los entornos de nube y mainframe durante el período de transición.
-
Actualice el proceso de administración de cambios: actualice el proceso de administración de cambios para tener en cuenta las modificaciones del código en este nuevo paradigma de doble entorno. Este proceso debe incluir:
-
Flujos de trabajo de aprobación claros para cambios de código.
-
Revisiones obligatorias del código antes de fusionarlo en la rama principal.
-
Procedimientos de implementación sincronizados para garantizar que ambos entornos reciban actualizaciones simultáneamente.
-
Mecanismos de reversión en caso de problemas en cualquiera de los entornos.
-
Elasticidad
La elasticidad de la computación en nube introduce un cambio de paradigma que altera significativamente la estructura de costos y la administración de recursos del mainframe. A diferencia del entorno de mainframe tradicional, que tiene una capacidad fija y modelos de precios basados en los picos de consumo, las plataformas en la nube ofrecen una escalabilidad dinámica y un pay-as-you-go enfoque que puede suponer un importante ahorro de costes y una mejora de la eficiencia operativa.
En un entorno de nube, las organizaciones pueden aumentar o reducir sus recursos informáticos en tiempo real en función de la demanda real, lo que elimina la necesidad de aprovisionamiento excesivo para adaptarse a los picos de carga. Esta elasticidad permite a las empresas pagar solo por los recursos que consumen, en lugar de invertir en costosas licencias de hardware y software para hacer frente a los picos ocasionales de uso.
Para obtener más información sobre cómo funcionan los precios AWS, consulte AWS Precios
