Instalación de componentes OCI

En artículos anterioes os he dado a conocer OCI 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, en el que vimos una instalación real en hub and spoke, os mostré los distintos componentes que usamos, además tranté de exponer qué era cada uno de ellos. Hoy os voy a presentar los principales aspectos a tener en cuenta a la hora de instalar estos componentes.

En primer lugar os voy a mostrar la página de inicio de OCI:

Desde el menú principal de componente en la parte superior izquierda os iré guiando para llegar a cada uno de los componentes a instalar, aunque como podéis ver, en la parte central de la pantalla os aparece un menú Quick Actions que os permite crear directamente algunos de estos componentes.

Unicamente nos vamos a centrar en los componentes que puedan suponer algún reto a la hora de configurar como ocurrió en el caso del Fast Connect.

Instances: Desde el menú principal de componentes, buscaremos Compute y dentro de este menú seleccionamos instance. En esta nueva ventana nos permite crear servidores. En primer lugar nos pide un nombre de servidor y luego elegir una imagen, bien sea desde el catálogo de OCI, de algunos de los partners o una que importemos desde un sistema nuestro. Descubrirán que el catálogo de imágenes de OCI es bastante completo, nosotros, debido al uso que vamos a darle a estas instancias (Bastiones), seleccionamos Oracle Cloud Developer Image, ya que lleva preinstaladas gran cantidad de herramientas que nos serán muy útiles para la administración de las BBDD (SQL Developer, Visual Studio Code, Ansible, Oracle CLI, etc). Tras seleccionar esto el availability domain se encuentra completado por defecto y más abajo nos parece para eleguir el shape de la máquina donde podremos seleccionar el tipo de procesador (Intel, AMD), el número de OCPUs que tendrá el equipo, y la memoria entre otras opciones. A continuación seleccionaremos la VCN y la subnet a la que estará asociado nuestro equipo y el boot type.

Tras esto viene un punto muy importante; por defecto todos los equipos que montamos en OCI requieren de una clave SSH, podemos crearla nosotros desde putty o linux y podemos administrarla nosotros o subirla al OCI Vault para que sea accesible para todo el compartment. Si dejamos este apartado sin completar, entonces se entiende que queremos acceder con usuario y contraseña tradicional, para lo cual, al finalizar la instalación podemos revisar en la página principal de la configuración del componente, y veremos que el usuario por defecto que nos genera es opc y nos dará una clave de un solo uso para cambiar en el primer acceso. Lo aconsejable es generar las claves SSH y guardarlas en el vault.

Para concluir la configuración de este componente existen una serie de opciones avanzadas ocultas que al desplegarlas nos permiten por ejemplo: Seleccionar el dominio de fallo donde queremos que esté este equipo (por si tenemos más de uno y queremos que esten en distintos), indicarle un script de arranque para que haga ciertas tareas en el arranque, darle una ip privada fija al equipo, etc.

File Storage: como comentamos en otro artículo este componente es muy útil, ya que nos permite crear un file system compartido, al cual si le damos visibilidad desde todas VCNs nos permitirá compartir ficheros de despliegues, cargas de datos y todo tipo de ficheros que de otra forma requeriría operaciones de movimineto de datos bastante largas y tediosas. Para instalarlo, iremos al menú principal de la parte superior izquierda y buscaremos File Storage y dentro File System, este componente a su vez se divide internamente en otros 3 componentes, pero se centraliza la configuración de todos en la ventana que se nos abre al seleccionarlo (desde terraform si que hay que crear los recursos por separado). La configuración de esto es bastante trivial, solo tenemos que indicar el nombre del File System, el path que tendrá y su punto de montaje, todo bastante fácil desde el formulario web.

Lo destacable de este componente es a la hora de usarlo. Una vez creado y configurado, si accedemos al componente dentro de File System, en la página que se nos abre abajo nos aparece el apartado de Exports y el nombre que le dimos al path en la configuración. Al final de ese nombre aparecen 3 puntos que nos dan acceso a un desplegable donde seleccionaremos Mount Commands:

Esto nos abre una nueva ventana con los comandos que debemos ejecutar en los servidores desde los cuales queramos acceder y las reglas de security lists que debemos configurar:

• Stateful ingress to TCP ports 111, 2048, 2049, and 2050, and UDP ports 111 and 2048.
• Stateful egress for TCP source ports 111, 2048, 2049, and 2050, and UDP source port 111.

Importante: es posible que algunos de estos puertos no esten permitidos por el propio firewall de los servidores y será necesario revisarlo para que el servicio funcione correctamente.

Virtual Machine DB Systems: A la hora de crear BBDD exiten varias opciones como ya explicamos anteriormente. Para este caso nos hemos decidido por un DBSystem en máquinas virtuales, desde el menú principal de componentes ir a Bare Metal, VM, and Exadata. Damos a crear DB System y esto nos abre una nueva ventana para comenzar la configuración. Este componente se divide en dos formularios de configuración, el primero de ellos es muy parecido al de una instancia. Nos pide:

• Compartment donde estará alojado.
• Nombre del componente.
• Dominio (definido por defecto).
• Elegir entre: VM, Bare Metal o Exadata (En nuestro caso VM).
• Seleccionar el tamaño de los nodos (Shape).
• Número total de nodos: 1 o 2.
• Versión del software de Oracle: Enterprise, standard, etc.
• Storage Management Software.

- Available storage: Aquí, como mencioné en un artículo anterior, sólo tenemos que preocuparnos por el tamaño de los datos. OCI,automaricamente, hace el cálculo de espacio que va a necesitar para el resto de ficheros de log y redo que necesita para trabajar.

• Clave SSH: Igual que comentamos para las instancias.
• Licencia incluida o aportada por el cliente, en el caso de que ya posea una licencia anterior y quiera migrarla aquí.
• Networking: VCN, subnet, etc.

Tras esto haríamos click en Next y nos mostraría el formulario específico de configuración de la BBDD:

• Nombre de la BBDD.
• Versión de la BBDD (12C, 18C, 19C, etc.)
• Nombre del PDB.
• Password del usuario sys.
• Tipo de carga de trabajo: transaccional o data warhouse.
• Backups automáticos: este punto es muy interesante, ya que si tenemos configurado el DNS Domain name en la subnet nos va a permitir la creación automática de backups con la perioricidad y la retención que nosotros le indiquemos y de manera totalmente desatendida, tambien se puede configurar una vez completada la instalación.
• Opcionos ocultas: en este apartado podemos elegir el juego de caracteres de la BBDD.

Service Gateway: Desde el el menú principal de componentes ir a Networking y ahí buscar Virtual Cloud Network, en la parte de debajo de la nueva ventana que nos muestra veremos un listado de Resources. Aquí nos encontramos con el componente Service Gateway. Este componente no requiere de grandes configuraciones, unicamente nos pide el nombre, el compartment al que asociarlo y el servicio. En el servicio lo que vemos es un desplegable donde nos dice si queremos asociar este SG a un OCI AMS Object Storage (que seleccionaremos si tenemos un object storage donde queremos guardar los backups de nuestras BBDD) o a All AMS Services in Oracle Services Network, esta opción nos da la oportunidad de trabajar con los YUM Repos, que explicabamos en el artículo anterior.

En el próximo artículo hablaremos de otros componentes que no hemos usado en la instalación que nos ocupa y además de algunos problemas o deficiencias que nos encontramos en el proceso.