Interconexión multi-cloud OCI

Interconexión multi-cloud OCI

En un artículo anterior os daba a conocer OCI y de cómo Oracle revolucionaba el mundo de las BBDD en cloud. Pero hay que reconocer que OCI por si sólo se queda un poco corto para muchas de las funcionalidades que a día de hoy nos ofrece el mundo cloud. Sí que nos ofrece un amplio abanico de imágenes de servidores con gran cantidad de posibilidades. Pero puede ser que nuestros clientes ya tengan una infraestructura en otros clouds como Azure o AWS y hagan uso de muchos de los servicios que estos proveedores ofrecen para su negocio, y que Oracle no les puede ofrecer por sí mismo, o que lo único que quieran sea migrar sus BBDD actuales al cloud de Oracle.

Para solventar esto, durante una serie de artículos os vamos a exponer un caso de éxito que recientemente hemos llevado a cabo y donde os presentaré algunas de las dificultades encontradas, e intentaré adentraros un poco más en la oferta que OCI nos brinda.

Azure-OCI

Cómo decía en este artículo os voy a hablar de un caso real que hemos desarrollado. En nuestro caso el cliente disponía de una infraestructura previa montada en Azure donde tenía distintos entornos productivos y no productivos, y necesitaba que sus bases de datos siguiesen una estructura similar. Para esto nos decidimos por una estructura de Hub and Spoke en ambas plataformas:

Resumiendo un poco la arquitectura que vemos en el dibujo tenemos:

• En rojo la infraestructura de OCI.
• En azul la infraestructura de Azure.
• Y en gris la infraestructura de las oficinas del cliente (On-premise), donde el cliente ya disponía de elementos básicos, además de los propios usuarios de las aplicaciones.

Como vemos en la imagen el cliente ya tenía arquitectura previa en sus oficinas (On-premise) y otra en Azure interconectadas por Express Route. Entonces para implementar nuestra infraestructura necesitábamos crear otra interconexión entre OCI y Azure. Para esto fue necesario crear una conexión del lado de Azure (Express Route) y otra del lado de OCI (Fast Connect), os dejo un enlace de ambos proveedores donde se explica muy bien cómo se hace esta conexión:

• Azure
• OCI

Un par de puntos que pueden resultar un poco confusos en la documentación de OCI, son:

• El bandwith debe ser el mismo en ambas plataformas (Azure y OCI).
• La parte del direccionamiento IP:

En el punto 3 de la documentación de Azure, habla de establecer dos espacios de direcciones IP privadas de /30 cada una, para que no se superpongan con la red virtual de Azure o con el espacio de direcciones IP de la red de la nube virtual OCI. En nuestro caso elegimos un direccionamiento de Azure, y la configuración en OCI quedó así:

• Customer Primary BGP IP Address: 10.0.0.2
• Oracle Primary BGP IP address (optional): 10.0.0.1
• Customer Secondary BGP IP Address: 10.0.0.6
• Oracle Primary BGP IP Address (optional): 10.0.0.5

Como se indica en la documentación, el paso previo a crear el Fast Connect en OCI, es crear un DRG (Dynamic Routing Gateway). Este elemento no es más que router que proporciona conectividad entre las redes internas que creamos dentro de nuestra infraestructura de OCI y los componentes exteriores. Para poder crear el DRG en OCI, previamente tendremos que haber creado al menos una VCN (Virtual Cloud Network), en nuestro caso, tal como vemos en la imagen anterior, este elemento está incluido en la zona de HUB de OCI y conecta mediante Express Route y Fast Connect con Azure.

OCI-HUB

OCI te permite organizar tus componentes en lo que ellos llaman Compartment. Nosotros usamos estos compartment para organizar los elementos comunes tanto al HUB como a cada uno de los SPOKE que dividimos, como muestra el dibujo, entre los distintos entornos. En este punto, os quiero explicar lo que montamos dentro del compartment de HUB antes de pasar a los detalles de electrónica de red y otros componentes. En el HUB la idea era centralizar todas las conexiones, de manera que restringir más fácilmente la seguridad y las conectividades entre ambos entornos. Entonces la idea era, que tanto en el HUB de Azure como en el de OCI existiesen dos bastiones, que dieran visibilidad a los entornos productivos y no productivos respectivamente. Dejando como único punto de acceso a la administración el bastión correspondiente al entorno en el que se quiera trabajar. Para hacer esto necesitamos crear los siguientes elementos:

• VCN (HUB) – Virtual Cloud Network, o red principal donde van a estar conectados todos los elementos.
• Subnet de management pro – Subred de la VCN anterior dónde conectamos todos los elementos que van a acceder al compartment de PRO.
• Subnet de management no-pro – Subred de la VCN anterior dónde conectamos todos los elementos que van a acceder al compartment de No-PRO.
• Route tables – Como pretendemos limitar la visibilidad de los componentes es importante crear tablas de rutas que establezcan las comunicaciones.
• Local Peering Gateways – Es un elemento vinculado a una VCN que nos permite establecer comunicación con otras VCNs.
• Security Lists – Se trata de listas de seguridad, con reglas para permitir el tráfico de entrada y salida tipo firewall, asociadas a las subnets.
• Instancias – Es el nombre que OCI da a los servidores y nosotros los usamos para crear nuestros bastiones.
• File Storage – Se trata de un elemento que nos permite tener un único punto de acceso a datos, en nuestro caso montamos una unidad de ficheros compartidos, que más adelante usamos para almacenar los export de BBDD que nos envió el cliente para poder hacer el import sobre las nuevas BBDD.

En este punto no hay demasiado donde profundizar, ya que estos son elementos comunes a todas las plataformas clouds. En el próximo artículo explicaré y profundizaré en los elementos usados en parte de los spokes, los cuales son más específicos, así como otros elementos que ofrece OCI.