Es perfectamente viable montar un Oracle Data Guard standby desde una base on-premises hacia OCI, con costos significativamente más bajos que mantener un sitio físico de DR, y con flexibilidad operativa que ningún data center tradicional puede ofrecer.
Esta última semana estuvimos recreando un standby que ya tiene funcionando más de 2 años entre Guayaquil y Bogotá. Tuvo un retraso importante y ya no fue posible igualarlo. Aprovechamos este trabajo para documentar una arquitectura que pocos conocen, es funcional y permite tener un sitio de respaldo utilizando OCI como destino.
Data Guard híbrido
Oracle Data Guard entre un primary on-premises y un standby en OCI esta soportado, el coste del licenciamiento es menor ya que podemos utilizar el modelo de licenciamiento de OCI y se configura exactamente igual que un Data Guard tradicional entre dos data centers. Cabe mencionar que en este proyecto el primario es un RAC y el standby es un single instance, esta particularidad no impacta el resultado final.
El standby corre sobre un OCI DBSystem — la oferta de Oracle Database gestionada en VM. No es Autonomous Database, no es Exadata Cloud. Es una máquina virtual con Grid Infrastructure y ASM, que se comporta como un servidor on-premises pero corre en la nube de Oracle.
El problema que tenemos en esta implementación es que el canal dedicado hacia Bogotá es pequeño ( 50 mbps ) no tenemos un FastConnect de 1GB y esta es la realidad de casi todas las empresa en Ecuador, canales pequeños dedicados. Por este limitante para mover los respaldos se tuvieron que hacer múltiples transferencias de los respaldos en varias fases por internet, además el espacio en el NFS de premisas estaba limitado a unos pocos TB.
En el caso de este cliente la base tiene alrededor de 16TB por ello movimos los respaldos entre un NFS en premisas a un bucket de Oracle en OCI, esta fase tomo varias semanas. La ventaja que tiene mover desde una máquina virtual con un NFS desde premisas hacia un bucket es que el CLI de Oracle OCI permite realizar el envío en paralelo de la información al bucket, esto permite un uso efectivo del canal de internet. Una vez que los datos están en un bucket se vuelven a bajar a un NFS en OCI desde del cual se hace el restore al DBSystem, este paso es mucho más rápido ya que todo se encuentra dentro de la infraestructura de OCI que tiene redes potentes y optimizadas.
El truco financiero: empezar pequeño, escalar bajo demanda
Aquí está el punto importante de usar esta arquitectura: el standby en OCI no necesita estar dimensionado igual que el primary durante operación normal.
En un escenario tradicional de DR físico, el sitio de respaldo se dimensiona igual o cercano al sitio primario porque es un costo hundido. Si se compra el hardware, está corriendo 24/7 al 100% de capacidad independientemente de si se usa o no.
En OCI esa lógica desaparece. Un DBSystem se puede provisionar con la configuración mínima necesaria para mantener el MRP aplicando redo:
- 2 OCPUs en operación normal (suficiente para que MRP aplique redo)
- En caso de failover, scale up a la capacidad del primary en minutos
Esto tiene dos implicaciones de costo enormes:
- Costo de infraestructura: pagas por 2 OCPUs en lugar de 16, 32 o las que tenga la primary durante el tiempo que se hace la replicación, menor coste de infraestructura durante el tiempo de funcionamiento del standby.
- Costo de licenciamiento: Oracle Database en OCI se licencia por OCPU o por ECPU. Menos OCPUs / ECPUs activos = menos licencias consumidas durante operación normal, bajando el coste.
La operación de scale-up de OCPUs en OCI DBSystem toma minutos, no horas. En caso de un evento real de DR, escalas el standby a la capacidad necesaria como parte del runbook de failover. Este runbook puedo incluir las máquinas virtuales, aplicativos, etc.
Cuándo esta arquitectura tiene sentido
Esta solución encaja particularmente bien para:
- Empresas medianas y grandes con bases Oracle Enterprise Edition existentes : Ya tienen licencias de Enterprise Edition on premise y por lo tanto tienen Data Guard pero no quieren pagar un coste alto para una solución de DR, el scale up de los recursos en OCI puede sumar tiempo al tiempo de recuperación pero abarata muchisimo los costes ( Licenciamiento + Infraestructura )
- Migraciones a la nube de Oracle: Se puede utilizar esta arquitectura para migrar a una base de datos en la nube casi sin tiempo fuera de los sistemas, el tiempo máximo es el que demora la aplicación del MPR. Esto también se puede lograr con Golden Gate con mayor complejidad de implementación ( nosotros lo hemos realizado ).
- Casos de compliance: Se requiere DR documentado con un coste contenido, tener un DR a Bogotá esta soportado no solo a nivel de infraestructura, también es una opción legal viable ( Colombia es miembro de la CAN y tiene un 'Nivel Adecuado' para el tratamiento de datos para la SPDP).
- Sitio de DR total fuera del país: OCI esta preparado para ser una solución de DR total, se pueden sincronizar las máquinas virtuales, aplicativos, contenedores, etc no solo las bases de datos. Se puede tener un runbook de failover listo y automatizado para toda la infraestructura en caso de fallo en Ecuador ( esto merece un post aparte ).