Plan de Resiliencia

Su empresa u organización tiene requisitos específicos para la integración de datos de cliente. Antes de comenzar a diseñar de forma detallada, realice el tiempo necesario para planificar una arquitectura de integración que satisfaga sus requisitos en sus ACS.

Determinar Requisitos de Resiliencia

Antes de divulgar lo que hará resistente su entorno, primero debe definir lo que significa resiliencia hacer y su empresa. En otras palabras, ¿cuál es el costo asociado con una interrupción de los procesos de integración?

Para algunos clientes, una interrupción de unos minutos es aceptable y solo retrasará parcialmente un proceso por lotes que se ejecuta bien dentro de su ventana de procesamiento. Para otros clientes, incluso unos segundos de interrupción dan como resultado pérdidas financieras con un impacto directo en el negocio.

Desde esa perspectiva, es importante consultar los siguientes elementos:

  • ¿Cuál es la duración de una interrupción aceptable en su entorno? Aquí debe definir el costo para el negocio en caso de una interrupción y outline cómo esta interrupción evoluciona con la duración de la interrupción.
  • ¿Qué tecnologías se utilizan y cómo se pueden entregar en el nivel de servicio esperado? ¿Está teniendo un enfoque en tiempo real o por lotes? ¿O una combinación de ambos? ¿Cuántos datos está procesando?

Definir una Arquitectura de Resilient

Para definir una arquitectura resistente, es necesario consultar la solución de integración de datos completa.

En el caso de un proceso de integración, debe considerar los siguientes componentes de la arquitectura (hardware y software):

  • Resiliencia del sistema de origen
  • Resiliencia del sistema de destino
  • Resiliencia del área temporal si se utiliza cualquiera
  • Resiliencia de las herramientas de integración de datos
  • Resiliencia de la orquestación (si está fuera de la herramienta ETL)
  • Resiliencia de la red (desde una perspectiva de conectividad y una perspectiva de ancho de banda)

También debe tener en cuenta los requisitos en términos de recuperación ante desastres y alta disponibilidad. ¿Qué sucede si pierde el centro de datos en el que está instalada esta infraestructura?

Para que la instalación de Oracle Data Integrator sea resiliente, se necesitan los siguientes elementos:

  • Los agentes deben ser redundantes: Los agentes de JEE están diseñados para ofrecer resiliencia en que un equilibrador de carga distribuirá la carga entre agentes.
  • El repositorio de Oracle Data Integrator debe ejecutarse en un sistema resistente: una instalación de Oracle RAC u Exadata sería un requisito mínimo, para que la pérdida de un nodo no indique la pérdida de la infraestructura completa. Para despliegues de Oracle Cloud, Oracle Database Exadata Cloud Service proporciona una solución resiliente.
  • Si utiliza un producto externo para orquestar los procesos de Oracle Data Integrator ( Oracle Integration por ejemplo), debe asegurarse de que este producto también es resistente.

Si tiene en cuenta una estrategia de recuperación ante desastres, se necesitan los mismos elementos que los descritos anteriormente, por lo que tendrá que asegurarse de que:

  • Tiene una copia (suficientemente reciente) del repositorio de Oracle Data Integrator en el sitio de DR para poder seguir ejecutando los procesos de Oracle Data Integrator.
  • Dispone de agentes de Oracle Data Integrator en ese sitio de DR para acceder a este repositorio.
  • Se tiene acceso a los sistemas de origen y destino, o acceso a una copia de los sistemas de origen y destino.

Para Oracle Data Integrator específicamente, habrá dos elementos de topología que se deben validar:

  • La dirección IP o el nombre del servidor del repositorio de trabajo de Oracle Data Integrator se almacena en el repositorio maestro de Oracle Data Integrator. Si el nombre o la dirección IP cambia cuando cambia al sitio de DR, debe asegurarse de que esta información se actualice antes de iniciar Oracle Data Integrator.
  • La dirección IP o el nombre del servidor para los sistemas de origen y destino se almacenan en el repositorio de trabajo. Existen dos estrategias posibles:
    • Defina contextos separados para cada entorno (primary y DR) que permitan tener dos definiciones de servidor físico diferentes para cada unidad lógica.
    • O bien, sobrescriba la dirección IP o los nombres de servidor antes de iniciar Oracle Data Integrator en el sitio DR.
  • En todos los casos, cualquier script que utilice el SDK que sobrescriba información en los repositorios de Oracle Data Integrator debe tener un script de reversión para restaurar la información en el sitio primario.

Plan para cargas iniciales y sucesivas

Los cambios tendrán que diseñar un proceso ligeramente diferente para la carga inicial del sistema de destino antes de centrarse en las cargas normales (como lotes casi en tiempo real o diarios).

De este modo, si desea protegerse frente a interrupciones futuras no incluyendo, es crucial mantener y mantener estos procesos de carga iniciales. Si tiene la capacidad de volver a ejecutar una carga inicial (o una carga inicial parcial), no se debe desarrollar nunca, en particular cuando se mira a las siguientes situaciones:

  • Se ha detectado una mezcla mayor en la validez de los datos que se han cargado (datos que faltan, fórmula no válida en ETL, etc.).
  • Se produce una interrupción grave en el sistema de destino, lo que genera una pérdida masiva de datos.
  • Por algún motivo, los procesos de integración no se pueden ejecutar durante un período demasiado largo.

Al tener la capacidad de ejecutar cargas iniciales en la misma, también se proporciona la capacidad de instanciar nuevos entornos.

También puede mejorar estas estrategias de carga con la capacidad de volver a aplicar una carga anterior (como un mes anterior de datos). Esto requeriría una combinación de limpieza parcial de los datos cargados, así como una carga parcial.