¿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.
