Consideraciones para continuidad de las operaciones

Por Juan Vicenteño
Publicado en diciembre 2011

Desastres naturales como los que se han experimentado en los últimos años, incluidos los terremotos, huracanes, tsunamis, junto con nuevas regulaciones del gobierno, como Sarbanes Oxley, obliga a las empresas e instituciones a buscar la forma de tener una continuidad de las operaciones. Muchas empresas han implementado soluciones de recuperación de desastres que se centran en la recuperación de sus datos después de un desastre o de un acontecimiento. continuidad de las operaciones, sin embargo, es un término más amplio que incluye requisitos estrictos para alta disponibilidad de sistemas y archivos de datos, es decir, la capacidad para operar dentro de criterios aceptables en una amplia variedad de condiciones perjudiciales o interrupciones. Aunque las tecnologías de recuperación de desastres tienen como objetivo reducir el tiempo medio de recuperación (MTTR) en caso de una falla física, las soluciones de continuidad de las operaciones deberían tener el objetivo de maximizar el tiempo medio de falla (MTTF).

Una solución para continuidad de las operaciones debe ser capaz de apoyar el negocio en cualquiera de los tres posibles problemas de disponibilidad desde la perspectiva de los usuarios finales:

1. Cortes no planificados: estas son las interrupciones causadas por los fallos del sistema, como un corte de energía que detiene todos los sistemas. Soluciones de recuperación de desastres se centran en estas interrupciones no planificadas, donde la compañía sólo puede reaccionar después de que ocurra el siniestro. Por cuestiones de este tipo, las empresas requieren de herramientas que permitan recuperar la información de los sistemas cuando ciertas eventualidades pueden estar ocurriendo y no cuando han pasado.

2. Cortes planificados: interrupciones que suceden cuando se pasa de un sistema a otro, como por ejemplo migraciones de bases de datos, sistemas operativos y hardware. Durante este tiempo, los usuarios finales no son capaces de utilizar el sistema dado que interrumpe las operaciones comerciales que dependen de éste. Muchas empresas seleccionan momentos no productivos para hacer dichos cambios. Sin embargo, existen sistemas de misión crítica que no pueden darse el lujo de tirarlos. Por ejemplo, los sistemas médicos de los hospitales que dependen de los pacientes para mantener la vida son sistemas de misión crítica y el hospital no puede dar de baja los sistemas tan sólo unos minutos por la noche para hacer cualquier tipo de cambio. Es por eso que surge la necesidad de una herramienta que permita mantener la disponibilidad para migrar, actualizar o dar mantenimiento a los sistemas críticos.

3. Problemas de rendimiento en sistemas transaccionales: Los sistemas que están sobrecargados con un gran número de usuarios pueden tener problemas de rendimiento a pesar de que todos los componentes subyacentes están en marcha. En tales casos, los usuarios finales pueden experimentar retrasos significativos en los tiempos de respuesta. Este tipo de interrupciones afectan a las empresas porque tienen usuarios finales insatisfechos, problemas de retención y pérdida de posibles ingresos cuando los clientes son los usuarios finales. Por ejemplo, si un sistema de cajeros automáticos de un banco comercial es lento y los usuarios reciben mensajes de error que dicen que el sistema no puede procesar la solicitud en ese momento, se tendrá un impacto negativo del cliente con el banco, y los puede llevar a cambiar de banco. Por motivos de esta índole, las organizaciones necesitan sistemas que permitan balancear la carga de los sistemas en producción.

Planes de continuidad del negocio deben abordar los tres problemas en la disponibilidad para asegurarse que los usuarios finales tendrán acceso a las aplicaciones críticas sobre cualquier eventualidad como desastres, mantenimiento y actualizaciones, así como cuando el volumen de transacciones aumenta los requisitos de procesamiento.

Consideraciones Técnicas

Después de identificar las necesidades para tener una adecuada continuidad de las operaciones, las organizaciones de TI deben evaluar las soluciones desde una perspectiva técnica. Estas consideraciones incluyen:

El rendimiento del sistema Fuente: ¿La solución de HA crea alguna sobrecarga en el sistema origen?
Limitaciones de la red: ¿La solución requiere un ancho de banda adicional?
Las preferencias de la base de datos de destino: ¿La solución permite movimientos de datos sólo entre sistemas similares?, ¿la base de datos destino está activa?
Volver la estrategia: refiriéndonos a migraciones, ¿qué tan fácil y rápido podemos regresar a la base de datos anterior dado que ocurrió una eventualidad en la base de datos nueva?
La distancia geográfica: ¿Hay requisitos de distancia física para el sistema de respaldo? Si es así, ¿cuál es el requisito de distancia mínima?

La solución

Oracle cuenta con una tecnología que abarca tanto las consideraciones de continuidad de las operaciones, así como las consideraciones técnicas: Oracle GoldenGate.

Oracle GoldenGate (OGG) es un producto que permite replicar altos volúmenes de información transaccional entre ambientes heterogéneos y con un tiempo de latencia de hasta milisegundos. Un ambiente típico de OGG incluye tres procesos: capture, pump y delivery. Cada uno de estos procesos puede correr sobre los sistemas operativos y bases de datos más comunes (Incluyendo Oracle y No Oracle). OGG puede mandar toda la información del sistema fuente al destino o incluso puede ser sólo una parte de ésta. OGG es un excelente producto para minimizar el tiempo de inactividad en migraciones, mantenimiento y actualizaciones así como para recuperación de desastres (DR).

OGG es la solución empresarial para las necesidades de datos en línea, tanto para continuidad de las operaciones (acceso en línea) así como para integración de datos en línea. Ofrece operaciones continuas para aplicaciones de misión crítica eliminando los cortes no planeados y reduciendo los costos de las interrupciones planificadas. Además, OGG puede reducir los costos de infraestructura al hacer replicaciones hacía sistemas de menor costo.

OGG es una sola tecnología para diferentes necesidades: recuperación de desastres y protección de datos; cero tiempo de inactividad en migraciones, actualizaciones y mantenimiento; reporteo operacional y descarga de consultas; inteligencia de negocios en tiempo real; distribución de datos.

OGG permite mucha flexibilidad en las posibles configuraciones y alternativas en la implementación de un sistema de High Availability/Disaster Recovery (HA/DR). Ya que no sólo permite una solución uni-direccional, sino también permite soluciones bi-direccionales tanto en modo Activo-Pasivo, como Activo-Activo o Multimaster. Por otra parte OGG también permite trabajar en ambientes heterogéneos (por ejemplo: misma base de datos, diferente sistema operativo y/o hardware), lo cual permite mayor flexibilidad en la configuración de los sites alternos del DRP.

Requerimientos para OGG

OGG trabaja sobre los sistemas operativos más comunes: Windows, Linux, Solaris, IBM z/OS, HP NonStop, entre otros. También puede implementarse sobre las bases de datos más utilizadas: Oracle, DB2, SQL Server, Sybase, Teradata, etc. No requiere de un amplio espacio en disco duro (en el caso de replicación Oracle-Oracle son tan sólo 20 MB en cada servidor), ni de un vasto uso de CPU. Es una tecnología bastante simple de instalar, no requiere de programación, todo es completamente configurable a través de comandos.

OGG además cuenta con una herramienta denominada Oracle GoldenGate Management Pack (licencia aparte) que permite hacer las configuraciones, monitoreo, administración y vistas en un ambiente amigable y con diagramas de flujos. Es una excelente herramienta para levantar los procesos de OGG y es capaz de enviar alertas (vía mail y/o SMS) cuando ocurre algún problema o eventualidad.

Otra de las herramientas adicionales de Oracle GoldenGate es Veridata. Dicha herramienta permite comparar un conjunto de datos con otro, e identifica aquellos que no están sincronizados; es decir, tratar de hallar discrepancias de datos entre dos sistemas que deberían tener la misma información.




Publicado por Juan Vicenteño. Sales Consultant, Oracle Mexico.