OCI

Artículo

Componentes en OCI Spokes

En el artículo anterior, os mostramos una reciente instalación que hemos llevado a cabo en la plataforma de OCI. Explicamos cómo interconectar Azure y OCI, así como los elementos y la estructura de HUB and Spoke que usamos, pero sobre todo en la parte de los HUBs. En este artículo analizamos la parte de los spokes y damos las claves de los elementos propios de Oracle que utilizamos.

OCI-PROD Spoke

En el caso que nos ocupa exiten varios spokes, ya que el cliente tenía en Azure una estructura tambien de varios spokes y era necesario recrearlo tambien en OCI para separar las bases de datos de cada entorno y nos ayuda limitar los accesos y la seguridad como veremos más adelante.

OCI PROD spoke

Como todos los spokes son muy paraceidos vamos a analizar sólo uno de ellos:

OCI PROD spoke

Los dos recuadros de la izquierda son los que comentamos en el artículo anterior (Conexión multicloud Azure-OCI y compartment HUB) y hoy nos vamos a centrar en los recuadros de la derecha (Compartment PROD y almacenamiento).
Como vemos en la imagen y comentabamos en el artículo anterior, en el HUB tenemos un bastión dedicado a cada entorno (pro y no-pro, en la imagen sólo vemos el de pro ya que nos vamos a centrar en este entorno) y el bastión se comunica con Local Peering Gateway específico con cada una de las subnets asociadas a cada entorno, de manera que nos permite la gestión y acceso a los entornos de manera más segura.

En la imagen tambien vemos que para este compartment tenemos 2 “entornos” cada uno en su subnet específica, pero el tipo de modalidad de servicio de BBDD que hemos elegido es distinto para que veaís que se pueden tener diferentes tipos. Para producción, se ha elegido un RAC (Real Application Cluster) de dos nodos, y para el entrono de Stage hemos elegido una single instance.

Los elementos ya conocidos que usamos en este compartment son:

  • VCN (PRO) – Virtual Cloud Network, o red principal donde van a estar conectados todos los elementos.
  • Subnets – En este compartment hemos creado una subnet por cada entorno que queremos representar para aislar los unos de otros.
  • Local Peering Gateways – Es un elemento vinculado a una VCN que nos permite establecer comunicación con otras VCNs.
  • Route tables – Como pretendemos limitar la visibilidad de los componentes es importante crear tablas de rutas que establezcan las comunicaciones.
  • 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.

Los elementos nuevos que usamos en este compartment son:

  • Service Gateway – Nos permite a la VCN acceder de forma privada a servicios de Oracle sin exponer los datos a la red pública de internet. No requiere un internet gateway de ni NAT para acceder a esos servicios. El tráfico desde la VCN al servicio Oracle recorre el tejido de red de Oracle y no internet.
  • Virtual Machine DB Systems – OCI dipone de varias opciones a la hora de desplegar sus BBDD: Bare Metal (equipo físicos), Máquinas Virtuales o Exadata. Para nuestra instalación hemos usado la opción de máquinas virtuales. Dedicaremos un apartado a explicar cómo se instala este tipo de componentes.
  • Objet Storage – Se trata un tipo de almacenamiento en caliente para acceso frecuente a datos, que en nuestro caso usabamos para almacenar el fichero de estado del código terraform, ya que el despliegue de toda la infraestructura lo realizamos en este lenguaje de infraestructura como código.
  • YUM Repos – Se trata de otro tipo de almecenamiento ofrecido por OCI específico para backups, parches y actualizaciones del sistema operativo. Lo más interesante de este almacenamiento es que es accesible desde services gateways y no require de NAT gatway, lo cual evita otra vez que nuestros equipos tengan que salir a internet y por consiguente es otro punto de mejora de nuestra seguridad.

En el siguiente artículo expondremos las principales consideraciones que debemos tener en cuenta a la hora de instalar los componentes anteriormente mencionados y algunos problemas que pueden encontrarse.

Conoce a nuestro experto

David Martínez

David Martínez es un jefe de equipo con un amplio conocimiento en los siguientes campos:

  • Consultor de SharePoint: administración de las tecnologías de SharePoint Server 2010 y 2013, diseño de la arquitectura de acuerdo con la topología, edición de webparts, webparts, incidencias de correlación de ids, implantación de la arquitectura en las granjas, administración y análisis de pruebas de rendimiento, optimización de Entornos, resolución de fallos de seguridad.
  • Administración del sistema Wintel: administración de los sistemas operativos, resolución de incidentes y optimización de los entornos como técnico de nivel 3. Además del análisis, documentación del entorno y el desarrollo de una arquitectura en HA y DR de las soluciones. La capacitación técnica que tiene es Ingeniería Técnica en Informática de Sistemas por la Universidad de San Antonio de Murcia.