Temas pendientes en nuestra instalación OCI

En artículos anterioes os he dado a conocer Oracle como proveedor cloud, tambien os mostré como sería hacer una interconexión entre los clouds de OCI y Azure, y un desarrollo que hicimos para un cliente, y os mostré algunas peculiaridades que nos fuimos encontrando durante la instalación de algunos componentes. Hoy vamos a tratar algunos componentes que aún no hemos usado y que os pueden resultar interesantes. Pero antes quiero mostraros un problema con el que nos topamos durante la instalación:

Problemas de DNS en un entorno multicloud

No todo podía ser perfecto, en la instalación que os hemos descrito, hemos encontrado algo que aún no está muy maduro dentro del mundo de las infraestructuras multicloud de OCI, y es el tema de tener un repositorio único de DNS. A día de hoy Oracle tiene dos métodos para la resolución de nombre:

• Internet: pero esta solución está descartada, ya que se trata de aplicaciones internas de nuestro cliente que no quiere que esten expuestas internet, por lo que esto no nos resulta útil.
• VCN: A nivel de la VNC donde hemos montado una BBDD o un servidor, la visibilidad de nombres está garantizada, y entre distintas VCNs se puede montar un DNS Zone que encontramos dentro del menú principal de aplicaciones, Networking – DNS Zone Management. Pero esto se complica también al usar la arquitectura de Hub and Spoke, como la que hemos elegido para esta solución, y además si queremos trasladarla a Azure.

Abrimos un caso con Oracle para tratar de resolver este problema y nos comentaron que estaban trabajando en ello. Quizás para cuando se publique este artículo ya esté diponible la solución (según nos indicó el soporte: Octubre de 2020), mientras tanto nos ofrecian un workarround montando un DNS Proxi:

https://blogs.oracle.com/cloud-infrastructure/configuring-a-custom-dns-resolver-and-the-native-dns-resolver-in-the-same-vcn

Otra complicación que nos encontramos es que desde Azure cuando intentamos crear una entrada DNS, el formulario nos ofrece crear un nombre contra una IP, pero cuando hemos creado el RAC de BBDD en OCI, ellos nos ofrecen un nombre DNS que es el que deberíamos publicar, pero en el apartado de IPs nos ofrece un pool de 3 IPs llamado Scan IP Addresses que mediante Round Robin nos permite llegar a cualquier nodo disponible. Estas IPs el sistema las calcula del rango de la subnet de la VCN que le hemos dado, descontando las IP de los servidores, las floating IPs, además de las que el sistema reserva para uso propio (como ocurre con todos los proveedores de cloud). Entonces de cara a la configuración tendríamos que elegir una de ellas, por la imposibilidad de hacer referencia a las 3 a la vez, y esto podría provocar la sobre carga del sistema por peticiones a esa IP, pero desde el soporte nos aseguraron que se trata de un servicio con 3 IPs y la gestión de disponibilidad de instancias de RAC se gestiona en siguientes capas, a partir de la VIP’s y local listener’s. Por lo que, si tenemos varios servicios que necesitan atacar este RAC desde Azure, en nuestro caso, podemos usar un IP distinta para cada una, y de esa manera evitaríamos que todos ataquen a la misma IP.

Ahora os voy a exponer otros componentes muy interesantes de OCI que quedaban fuera del alcance de nuestro proyecto por diversos motivos, pero que está muy bien tenerlos en cuenta, a la hora de montar una Arquitectura en OCI.

WAF: en un artículo anterior os hablé de Vault para guardar claves SSH y contraseñas a nivel de compartment. Dentro del menú de componentes en la parte de Security encontramos también: WAF (Web Application Firewall). Se trata de un componente de seguridad para proteger nuestras aplicaciones de tráfico macilioso y no deseado. En este apartado encontramos varios métodos que podemos implementar:

• Policies: Nos permite crear políticas de acceso a las URL de nuestas aplicaciones.
• Certificates: Podemos cargar paquetes de certificados publicos y su clave privada. Además nos permite trabajar internamente en OCI con certificados autofirmados.
• Custom Protection Rules: En este apartado podemos crear nuestras propias reglas siguiendo la nomenclatura ModSecurity Rule Language.
• IP Address Lists: Se trata de un IP Whitelist, donde incluiremos el direccionamiento IP desde el cual se permite el acceso a nuestras aplicaciones.

Monitoring

Oracle Cloud nos ofrece unas herramientas muy interesantes de monitorización y nos permite monitorizar no sólo las BBDD, sino casi todos los recursos que podemos montar en OCI: Block Storage, load balancing, network, object storage, etc… os dejo un enlace a la lista completa:

https://docs.cloud.oracle.com/en-us/iaas/Content/Monitoring/Concepts/monitoringoverview.htm#supported

Desde el menú principal de componentes podemos navegar hasta encontrar la opción de Monitoring; una vez dentro de la nueva ventana nos aparece un menú a la izquierda con 5 opciones que podemos ir navegando:

• Service Metric: Nos muestra dentro de cada compartment, los servicios o aplicaciones que muestran métricas y podemos ir navegando entre ellos para conocer su estado en el tiempo.
• Metric Explorer: Se trata de un agregador de métricas donde podremos ver las métricas y una comparativa de las distintas métricas de todos los componentes de un mismo tipo.
• Alarm Definition: Nos permite crear alarmas en función a unas métricas que nosotros le indiquemos, para conocer el estado de nuestros componentes en todo momento y que en el caso de que se sobre pasen los umbrales que hemos definido se active dicha alarma.
• Alarm Status: Se trata de un visualizador las alarmas que hemos generado antes y se encuentren activas, para decidir las acciones a tomar en cada caso.
• Health Check: Nos permite monitorizar mediante sondas, la disponibilidad, latencia y salud en general de las aplicaciones que tenemos dentro de OCI. También admite definir dichas sondas, para que se ejecuten desde distintas localizaciones geográficas y así comprobar la latencia en varios puntos del planeta. Y además, Testing Pruebas bajo demanda: realiza pruebas bajo demanda para medir rendimiento y solución de problemas.

El health Check también incluye un sistema de detección de problemas en DNS (DNS Traffic Management Failover Detection), que nos permite detectar errores de DNS que pueden hacer que nuestra aplicación no esté dando servicio y él conmutaría a otro punto para así, garantizar que el servicio continúa estando disponible.

Todas estas métricas de monitorización son exportables y enviables para no tener que revisarlas directamente desde la consola de OCI.

Notificaciones

Todas estas métricas anteriores no sirven de mucho si necesitas a una persona revisando la ventana de estatus constantemente, por lo que OCI ofrece un sistema de notificaciones, el cual permite una comunicación, bajo una serie de desencadenantes (trigger) que nosotros mismos podemos definir y que no siempre tienen que ser comunicaciones, si no que podemos enviar esas notificaciones a aplicaciones externas o funciones para que en el caso de que las notificaciones sean provocadas por un problema se puedan realizar acciones de manera automática.

Por tanto, dentro del menú principal de aplicaciones en Application Integration -> Nofication encontramos el Notification Service que podemos usar para el envío de correo, envío de notificaciones a herramientas tipo service now o al Management Cloud de Oracle. Incluso podríamos enviar estas notificaciones a Oracle Functions y dentro de esta otra herramienta crea una tarea o flujo de trabajo que, nos permita realizar ciertas acciones repetitivas sin necesidad de nuestra supervisión, o que realice de manera automática un escalado vertical u horizontal para hacer que nuestra capacidad de cómputo crezca ante un pico de carga.

Eventos

Oracle Cloud Infrastructure Events, te permite crear eventos basados en cambios de estados que no estén necesariamente asociados a un problema, por ejemplo: Creación de una instancia, creación de una bbdd, creación o subida de un fichero a un bucket, al acabar un backup con errores, etc.

Events Service: Con esta herramienta creamos reglas para que cuando llegue un evento sea capaz de reaccionar mediante microservicios y realizar diferentes acciones: Llamar a una función igual que veíamos en el punto anterior. Notificarnos de diversas formas como hemos visto antes o incluso Oracle ofrece un servicio de streeming basado en Kafka de enrutamiento para analíticas.

Encontraremos esta herramienta en l menú principal de componentes, Application Integration -> Events Service.

Costes

En el punto anterior veíamos como podemos recibir notificaciones de eventos y esto es muy importante a tambien a la hora de controlar los costes, imaginemos por un momento que alguien empieza a crear servidores o bases de datos de manera descontrolada, esto puede suponer un incremento importante de los costes, por eso es impotante que, por ejemplo, controlemos mediante eventos la creación de este tipo de componentes.

Por otro lado, dentro del menú principal de componentes encontramos Account Management -> Cost Analisys.

Dentro de esta herramienta podremos hacer un seguimiento del gasto mensual de nuestros servicios en OCI, y podremos escoger entre varios filtros para revisar los servicios que más consumo tienen, reviar el gasto por compartment, por región, pero sistema de etiquetas que hemos definido, etc.

En este mismo aparatado de la herramienta podremos ver nuestras facturas, presupuestos o incluso si somos administradores del tenant cambiar el método de pago.

En un proximo artículo analizaré algunos otros componentes y herramientas de OCI que pueden ser muy útiles, así como algunas alianzas recientes de Oracle con otros proveedores que os facilitarán mucho algunas tareas de migración o conexión multicloud.