El artículo también se encuentra publicado en Ingles English version.
Uno de los puntos que hay que tener en cuenta a la hora de crear nuevos entornos en OCI es la gestión de apagado/encendido de los entornos para reducir los costes dentro de la tenancy de nuestros clientes.
Desde Mayo del 2024, OCI lanzo el servicio de “OCI resource scheduler“ para facilitarnos esta tarea. Antes de esa fecha, podríamos controlarlo con alguno de estos métodos:
Crontab. Normalmente, en el entorno de producción se configuraba dentro del usuario opc un shell script con el listado de nodos que se deberían apagar/arrancar.
Ese sh se ejecutaba dentro de una tarea planificada:
[opc ~]$ crontab -l
30 7 * * 1,2,3,4,5 /home/opc/dbsystem/start_dbsystem.sh >> /home/opc/dbsystem/start_dbsystem.log
[opc ~]$ cat /home/opc/dbsystem/start_dbsystem.sh
cd /home/opc/dbsystem
NODE_SWITCH=<OCID>
. ./oci-curl.sh
oci-curl <END_POINT> POST ./empty.json /20160918/dbNodes/${NODE_SWITCH}?action=start
Auto Scaling para OCI. el gran Richard Garsthagen tiene publicado en su github un repositorio denominado OCI-AutoScale (link repositorio) para gestionar este tipo de operaciones por medio de tags.
Cuando realizas la instalación de OCI-AutoScale en una instancia, uno de los pasos es definir en la etiqueta Schedule:
Asociaríamos esas etiquetas a las instancias que queremos aplicarlo:
En este ejemplo, tendríamos dos etiquetas aplicadas, son:
Weekend: Apagado el fin de semana.
WeekDay: Encendido ciertas horas. La traducción de “0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0” sería la tabla de la izquierda.
OCI resource scheduler
Estos son los pasos que vamos a seguir para utilizar Resource Scheduler:
Antes de ver como trabaja este servicio en OCI, debemos de asegurarnos que:
El usuario que utilicemos tiene permisos para crear schedules.
Allow any-user to manage resource-schedule-family in tenancy
Debemos asegurarnos que a nivel schedule se le han dado permisos para administrar recursos en nuestro tenancy.
Allow any-user to manage all-resources in compartment '<compartment>' where all{request.principal.type='resourceschedule'}
Definimos una instancia para testear el nuevo servicio:
Después de asegurarnos que tenemos todos esos puntos, ya podríamos configurar nuestro servicio, ¡vamos a ello!
Vamos a la sección “Governance & Administration” y “Schedules”
Una vez dentro, veremos la siguiente ventana. Aquí solo debemos pulsar en “Create a schedule”:
En la primera parte tendremos que cumplimentar la información básica, como es un nombre y la acción a realizar, en nuestro caso es start.
En la siguiente ventana, debemos seleccionar el recurso de nuestra tenancy que queremos aplicar este servicio:
Si nos fijamos bien, tenemos un filtro con dos valores: Static o Dynamic. La diferencia entre ambos, es que Static, sería aplicarlo de manera individual, es decir, a un único recurso (este sería nuestro caso) o Dynamic, que sería aplicarlo a un conjunto de recursos que cumplan el siguiente criterio:
Tag: Aplica a todos los recursos que lleven ese tag.
Resource Type: Los tipos de recurso a los que se puede aplicar son: Instance, InstancePool, AutonomousDatabase, Function o DBSystem.
Compartment: Podemos seleccionar un compartment especifico o que aplique a todos.
Status: Los estados son Available, Running, Stopped o que aplique a todos
Seleccionamos Static y seleccionamos la instancia en el que queremos aplicarlo:
En la siguiente ventana sería para agregar parámetros a nuestro recurso que hemos seleccionado en el paso anterior. En nuestro caso no aplica.
La siguiente ventana es la más importante, porque vamos a definir la hora de arranque.
La primera opción es, como quieres definir la información referente al schedule, si bien desde la propia interface “Form Interface“ o bien desde “Cron expression”. Como vamos ha definir dos, uno de arranque y otro de parada, probaremos los dos.
En nuestro caso, para el arranque vamos a seleccionar “Cron expression”
Las opciones que vemos son:
Recurrence details: Una pequeña descripción, es opcional. Cuidado con este punto, porque en caso de que seleccionemos vía cron, debemos informar ahí la Cron expression.
De no hacerlo, no salta un error interno a la hora de crearlo:
Nuestra Cron expression es: “30 12 \ * *“*.
Time: En formato de 24h-UTC, sería la hora en la que se ejecuta.
Start date: Que día empieza a estar vigente. Podemos introducir la fecha a mano o por medio del calendario.
End date: Si queremos marcar una fecha fin, es opcional.
La última ventana sería como un resumen del schedule que vamos a definir .
Para el apagado será exactamente igual salvo la información referente al schedule, donde la vamos a definir como From interface:
Con esto ya tenemos definidos el arranque/parada de nuestra instancia.
Si volvemos a la ventana del principio, podemos ver que nuestros schedules se están ejecutando correctamente:
Listo, de esta manera tan sencilla podemos controlar el arranque/apagado de nuestros recursos.
Espero que os sirva :)
![[OCI] Resource Scheduler](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fres%2Fhashnode%2Fimage%2Fupload%2Fv1761114496929%2Fe3dac661-21d9-4fa7-9d8c-06da78c36baa.jpeg&w=3840&q=75)
![[26ai] SQL: Calendar functions/Aggregation Filters "CALENDAR"](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F587e3328-9877-4c7a-aad7-7811e251f81e.png&w=3840&q=75)
![[OCI] Recreación PDB$SEED](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F289ede5b-558c-4f93-b5c0-fa04680c91ca.png&w=3840&q=75)
![[OCI] Clone PDB](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F8ce0c665-4a5d-459d-91cf-ffe3f47d8176.png&w=3840&q=75)
![[OCI] Check Jobs DBCli](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F1376a869-58fa-491e-926a-a6ead08f9c80.png&w=3840&q=75)
![[26ai] JOIN_TO_ME](/_next/image?url=https%3A%2F%2Fcdn.hashnode.com%2Fuploads%2Fcovers%2F65605419d28f19cc44df7ef1%2F16a23f6e-ec4c-4f0a-9529-2c8a2af2ef5e.png&w=3840&q=75)