Control-M 8 vs Control-M 9 ¿Por que Migrar? | PostgreSQL

¿Por qué usar Control-M Versión 8?

Esta versión es muy robusta y estable, que contempla particularmente cambios muy importantes en temas de funcionalidad, con la opción de FailOver manual, sin mencionar los grandes cambios funcionales y de simplificación operativa de la versión 8, así como todas las adiciones funcionales de las versiones anteriores como AFT, BIM, Forecast, Archiving, Configuration Management demostrando ser muy estable.

 La versión 8 cuenta con los elementos funcionales más importantes que están descritos en la tabla subsiguiente de funcionalidades nuevas de la versión 8.

¿Por qué Migrar de Control-M v8 a Control-M V9?

Esta es la última versión más actual, es muy robusta y estable, que contempla particularmente cambios muy importantes en temas de disponibilidad y continuidad, contando con la opción de FailOver automático, sin mencionar que cuenta con los grandes cambios funcionales y de simplificación operativa de la versión 8, así como todas las adiciones funcionales de las versiones anteriores como AFT, BIM, Forecast, Archiving, Configuration Management, Change Manager, AFTM y ha demostrado ser muy estable.

Las características más importantes que fueron agregadas a esta versión se muestran a continuación.

 
 

 
 

Factores de éxito al migrar a CTM 9

• Continuidad Operativa.
• Una plataforma tecnológica actualizada y soportada
• Funcionalidad apropiada para los requerimientos operativos
• Eficiencia en ejecución, manejo de información, seguridad, disponibilidad de los procesos
• Continuidad del negocio
• Reducción de riesgos operativos
• Integración con tecnologías
• Comunicación.
• Eficiencia.
• Mejores prácticas.

Esquema FailOver

La configuración de FailOver para Control-M (Server) sobre PostgreSQL se puede ver en el siguiente diagrama:

Cuando el Configuration Agent, detecta que nodo primario de Control-M falla y está caído, se realiza el cambio al Host Secundario el cual contiene la base replicada.

El esquema de FailOver se realizará a través de un proceso de configuración manual, Cuando el Agente de Configuración (Configuration Agent) detecte que Enterprise Manager (Control-M/EM) o el Server (Control-M/Server) y su Agente de Configuración están caídos y la operación sobre el primario haya sido detenida inesperadamente. Esto podrá ocurrir en base a:

• Problemáticas en el hardware
• Caída en de la máquina virtual (si se utiliza hipervisor)
• La tarjeta de red no responde
• No hay transacciones hacia la base de datos
• Si todos los componentes están caídos.

El Agente de Configuración (Configuration Agent) estará validando el estado de salud y respuesta de cada uno de los componentes de Control-M (Control-M/EM, Control-M/Server, Control-M/Client, PostgreSQL Database).

Por defecto, el Agente de Configuración, consideraría caída si alguno de los componentes no responde (a través de LIFECHECKS) por un espacio de 60 segundos. Este parámetro se puede configurar. El retorno de operación al primario (FailBack) se realizará de forma Manual.

Se validará de igual forma las características de replicación de la base de datos PostgreSQL, para que la configuración de FailOver quede instalada por completo, a nivel servidores Control-M y Base de Datos.

 Espero este pequeño aporte le dé una idea de los datos importantes entre las versiones y sus diferencias entre versión 8 y versión 9 de BMC Software, Control-M Work Load Automation, éxito en su migración de WLA a ver. 9.