May 2020 Update: If you need to power on/off or scale up/down many instances, you might run into the issue of OCI rate limiting. The Autoscaling script now manages this. Also other new features have been added, like support for notification service to report on the activity.
There are multiple OCI resources that support some form of Autoscaling and/or Power on/off operations. These operations can allow you to reduce cost or get the correct performance when needed.
Currently OCI has 2 native build-in auto scaling policies:
– Autoscaling Configurations for Instance pools
– Autoscaling option for Autonomous Databases
Both build-in auto scaling policies work on the current workload of the resource, but does not really keep into account that OCI billing in done on an hourly basis.
The OCI Autoscaling Script
Hence, I would like to introduce to you the OCI AutoScaling script. This script can Scale and Power On/Off resources just based on a time schedule. Managing the schedule for each resource can easily be done using a pre-defined tag. The value of the tag needs to contain 24 numbers, were each number stands for the size of the resource for that hour of the day. When the value of 0 is specified, the resource will be powered off (if supported by that resource).
The script supports 3 running methods: All, Up, Down
- All: This will execute any scaling and power on/off operation
- Down: This will execute only power off and scaling down operations
- Up: This will execute only power on and scaling up operations
The thinking behind this is that most OCI resources are charged per hour. Some services are billed per second and some per hour. So you likely want to run scale down / power off operations just before the end of the hour and run power on and scale up operations just after the hour.
To ensure the script runs as fast as possible, all blocking operations (power on, wait to be available and then re-scale) are executed in separate threads. I would recommend you run scaling down actions 2 minutes before the end of the hour and run scaling up actions just after the hour.
The script can run anywhere that has internet access to the OCI API services. The script supports instance principle for authentication. Meaning you can run the script inside an instance on OCI and use a Dynamic Group to give it the right privileges. Meaning you do not have to specify any details in side the OS where the script runs.
You can download the script from my GitHub repository:
https://github.com/AnykeyNL/OCI-AutoScale
Which Services can you scale?
Want to have an overview which service in OCI support power on/off or scaling operations? Check out my overview here:
https://www.oc-blog.com/2020/05/12/how-elastic-is-the-oracle-cloud/
Database backup considerations
If you want to stop your Database Cloud Service instances at certain time, you probably want to make sure you manage the backup schedule to fall in windows when you instance is powered on, else the backup can not be made.
According to Oracle’s Database documentation:
https://docs.cloud.oracle.com/iaas/Content/Database/Tasks/backingupOS.htm
Backup Window Time Zone- Automatic backups enabled for the first time after November 20, 2018 on any database will run between midnight and 6:00 AM in the time zone of the DB system's region. If you have enabled automatic backups on a database before this date, the backup window for the database will continue to be between midnight and 6:00 AMUTC. You can create aMy Oracle Supportservice request to have your automatic backups run in a backup window of your choice.
Additionally On-Demand Full Backups can be created for your database at any time unless your database is assuming the standby role in a Data Guard association.
Pingback: How Elastic is the Oracle Cloud – Oracle Cloud Blog
thanks for this amazing script, Richard
I’m new to python and OCI so I’m not sure if you can help me
I’ve followed your page https://www.oc-blog.com/oci-autoscale/ to install the OCI python libraries
but I receive the error:
export PATH=/opt/rh/python27/root/usr/bin:$PATH
export LD_LIBRARY_PATH=/opt/rh/python27/root/usr/lib64
$ /opt/rh/python27/root/usr/bin/python /home/oracle/OCI-AutoScale/AutoScaleALL.py
Traceback (most recent call last):
File “/home/oracle/OCI-AutoScale/AutoScaleALL.py”, line 14, in
import requests
ImportError: No module named requests
I would recommend using python3. but in both cases you need the requests module.
You can install this with the command:
pip install requests
This is truly an amazing hack. How many OCI users using and loving it you couldn’t imagine!
Hi Richard, Can I use the script to VM db scale up and down.
Yes, but is the DB is not run in RAC, it will need to reboot when scaling.
Trying to run autoscale for first time and getting
File “AutoScaleALL.py”, line 1576, in
visualbuilder = oci.visual_builder.VbInstanceClient(config, signer=signer)
AttributeError: module ‘oci’ has no attribute ‘visual_builder’
I am completely new to OCI so hopefully this is not something I have just missed
you need to upgrade the oci sdk, run this command
pip install –upgrade oci
This script is fantastic, however, it is getting hung up on a stale DB Resource. Is there a way to have the script continue on error?
When you say, hung, does it permanently hang? or is it just slow?
Hung is the wrong term, sorry. It stops and throws this error File “/home/opc/OCI-AutoScale/AutoScaleALL.py”, line 333, in
resourceDetails = database.get_db_system(db_system_id=resource.identifier).data
File “/usr/lib/python3.6/site-packages/oci/database/database_client.py”, line 13312, in get_db_system
api_reference_link=api_reference_link)
File “/usr/lib/python3.6/site-packages/oci/base_client.py”, line 468, in call_api
return self.request(request, allow_control_chars, operation_name, api_reference_link)
File “/usr/lib/python3.6/site-packages/circuitbreaker.py”, line 52, in wrapper
return self.call(function, *args, **kwargs)
File “/usr/lib/python3.6/site-packages/circuitbreaker.py”, line 67, in call
result = func(*args, **kwargs)
File “/usr/lib/python3.6/site-packages/oci/base_client.py”, line 623, in request
self.raise_service_error(request, response, service_code, message, operation_name, api_reference_link, target_service, request_endpoint, client_version, timestamp, deserialized_data)
File “/usr/lib/python3.6/site-packages/oci/base_client.py”, line 792, in raise_service_error
deserialized_data=deserialized_data)
oci.exceptions.ServiceError: {‘target_service’: ‘database’, ‘status’: 404, ‘code’: ‘NotAuthorizedOrNotFound’, ‘opc-r
it throws a 404, usually this mean the resource does not exist. In what lifecycle_state is the database when the script is running? What action is it trying to do on the DB?
Yeah, the resource was deleted, but still seems to be cached in OCI. I get a 404 when querying with the oci cli. Will probably need to open a ticket with OCI. Is there a way for the script to continue on status 404? Thanks for the reply.
This should now be fixed. Please dowload the latest version of the script