Oracle Cloud Infrastructure
En este artículo presentamos, a través de un caso técnico concreto, cómo se construye y pone en operación un Oracle Base Database Service en OCI, desde la creación de la red virtual hasta la conexión de una base de datos mediante SQL Developer. El recorrido también muestra las decisiones técnicas que deben considerarse para que una implementación pueda evolucionar desde un ambiente inicial hacia una plataforma preparada para operación productiva.
📌 NOTA En el instructivo se crea una VCN nueva para simplificar el ejemplo. En muchos proyectos reales la VCN ya existe y la administra el equipo de networking — en ese caso, se puede saltar directamente a la sección "Crear la base de datos Oracle".
Del workload a la operación: un enfoque de ciclo de vida
Una estrategia cloud para workloads Oracle puede dividirse en cuatro grandes etapas:
Build
Diseñar y construir la infraestructura necesaria: red, compute, storage, base de datos, seguridad y configuración.
Migrate
Trasladar bases de datos y workloads existentes hacia OCI utilizando mecanismos adecuados al escenario, al volumen de datos y a los requerimientos de disponibilidad.
Deploy
Implementar la configuración de forma repetible y controlada, incorporando automatización e Infrastructure as Code.
Run & Manage
Operar el workload de manera continua, incluyendo seguridad, backup, monitoreo, patching, disponibilidad, optimización y control de costos.
Build: construir la plataforma Oracle en OCI
El primer paso es disponer de una red virtual donde pueda ejecutarse el workload.
1. Diseñar la red
En OCI, una Virtual Cloud Network (VCN) proporciona el contexto de networking necesario para desplegar los recursos.
Para un escenario inicial, el asistente de OCI permite crear una VCN junto con subredes, gateways, tablas de ruteo y listas de seguridad. En ambientes productivos, sin embargo, la arquitectura de red normalmente requiere un diseño más específico y puede incorporar Network Security Groups (NSGs) para aplicar reglas de seguridad más granulares.
Un aspecto importante es habilitar los DNS hostnames de la VCN, ya que intervienen en la resolución de nombres de los nodos y en la configuración del dominio del host del DB System.
Esto permite establecer una base de infraestructura sobre la cual desplegar los servicios Oracle.
Construir el Oracle Database Service
Una vez disponible la red, el siguiente paso es crear el Oracle Base Database Service. Un DB System está compuesto por uno o más nodos con recursos de procesamiento, memoria, networking y storage donde se aloja la base de datos Oracle.
Durante el diseño deben tomarse decisiones que impactan directamente en performance, disponibilidad y costo.
Compute
El shape determina, entre otros aspectos:
- tipo de procesador;
- cantidad de OCPUs;
- memoria;
- ancho de banda de red;
- capacidad teórica de I/O.
OCI permite seleccionar distintas familias de procesadores y, en determinados shapes, ajustar la cantidad de OCPUs de acuerdo con las necesidades del workload.
La posibilidad de utilizar shapes flexibles permite dimensionar inicialmente el entorno y escalar recursos sin tener que reconstruir necesariamente el DB System.
Storage
El diseño también debe contemplar cómo se administrará el storage.
OCI permite seleccionar entre Logical Volume Manager (LVM) y Grid Infrastructure / ASM, además de definir el volumen de almacenamiento destinado a datos y las características de performance.
La elección depende del tipo de workload, arquitectura y requerimientos operativos.
Disponibilidad y edición de Oracle Database
El DB System permite definir el número de nodos y la edición de Oracle Database. Esto resulta especialmente relevante cuando el diseño requiere capacidades de alta disponibilidad como RAC o Data Guard.
La selección de la edición y del modelo de licenciamiento —License Included o BYOL— debe formar parte del diseño inicial y evaluarse conjuntamente con las funcionalidades requeridas y el modelo de costos.
Deploy: pasar del diseño a una implementación reproducible
El despliegue de un workload Oracle no debería depender exclusivamente de configuraciones manuales realizadas desde la consola.
El caso presentado muestra el aprovisionamiento mediante OCI Console, pero el mismo proceso puede evolucionar hacia un modelo automatizado utilizando:
- OCI CLI;
- OCI SDK;
- Terraform;
- OCI Resource Manager.
La propia guía identifica Infrastructure as Code como una alternativa para automatizar la creación de VCNs, DB Systems y operaciones como start/stop, reduciendo errores manuales y permitiendo mantener el aprovisionamiento versionado y auditable.
Esto resulta especialmente relevante cuando una organización necesita repetir despliegues entre ambientes de desarrollo, testing y producción, o estandarizar arquitecturas para múltiples workloads.
Migrate: preparar el workload para Oracle Cloud
Una vez definida la plataforma de destino, el siguiente desafío es la migración.
La estrategia dependerá del origen, tamaño de las bases, ventanas de mantenimiento, requerimientos de disponibilidad y objetivo de recuperación.
Entre las tecnologías identificadas para profundizar en escenarios de migración se encuentran:
- Oracle Data Pump;
- Oracle GoldenGate;
- Zero Downtime Migration (ZDM).
Estas tecnologías permiten abordar distintos patrones de migración, desde movimientos tradicionales de bases de datos hasta escenarios donde se busca minimizar el downtime.
Por eso, migrar no debería considerarse simplemente como "copiar una base de datos a OCI", sino como un proceso que integra assessment, diseño de destino, movimiento de datos, validación y puesta en producción.
Run & Manage: operar el workload después del deployment
La creación del DB System es solamente el comienzo.
Una vez que la base está funcionando, aparecen los requerimientos propios de una operación cloud:
Seguridad
El diseño operativo debe contemplar controles como:
- Network Security Groups;
- acceso restringido mediante OCI Bastion;
- gestión segura de claves y credenciales;
- OCI Vault;
- Transparent Data Encryption (TDE).
Backup y recuperación
Los backups automáticos pueden configurarse utilizando Autonomous Recovery Service u Object Storage, junto con políticas de retención.
Para ambientes productivos, la estrategia debe alinearse con los requerimientos de RPO y RTO, y los procesos de recuperación deben probarse periódicamente.
Alta disponibilidad y disaster recovery
Para workloads que requieren mayor resiliencia, el diseño puede evolucionar incorporando:
- RAC;
- Data Guard;
- Active Data Guard;
- estrategias de recuperación entre Availability Domains o regiones.
La selección depende de los requerimientos de continuidad del negocio y del nivel de disponibilidad necesario.
Monitoreo y gestión
Una operación madura también requiere visibilidad sobre el estado y comportamiento de los workloads.
Entre las capacidades que pueden formar parte de esta etapa se encuentran:
- OCI Monitoring;
- Ops Insights;
- Database Management;
- monitoreo de performance;
- seguimiento de capacidad;
- análisis de costos.
Automatización y eficiencia operativa
La operación cloud también abre oportunidades para automatizar tareas recurrentes.
Un ejemplo sencillo es el control de los DB Systems fuera del horario de uso. En ambientes de desarrollo y testing, los nodos pueden detenerse cuando no son necesarios y volver a iniciarse posteriormente mediante automatización.
A mayor escala, este mismo principio puede extenderse a:
- aprovisionamiento automatizado;
- configuración de ambientes;
- patching;
- backup;
- monitoreo;
- escalamiento;
- gestión de capacidad;
- control de costos.
El objetivo es pasar de una administración reactiva y manual a un modelo de operación estandarizado, automatizado y auditable.
Del proyecto puntual al Managed Service
El valor de una plataforma cloud no se limita a construirla.
Una vez que el workload está desplegado, las organizaciones necesitan mantenerlo disponible, seguro, actualizado y alineado con los requerimientos del negocio.
Por eso, el ciclo Build → Migrate → Deploy → Run & Manage puede convertirse en la base de un modelo de Managed Services.
De la infraestructura a la operación continua
La experiencia técnica en OCI comienza con decisiones concretas: cómo diseñar la red, qué recursos asignar, cómo configurar storage, qué modelo de licenciamiento utilizar y cómo desplegar la base.
Pero una plataforma empresarial requiere mucho más.
Necesita procesos para migrar workloads, automatizar deployments, proteger los datos, garantizar disponibilidad, monitorear performance, controlar costos y operar los ambientes de manera continua.
.png)
