This article explores a new feature in OCI called Resource Scheduler.  First released in May 2024, this is a long awaited and very welcome addition to the OCI service offering.

One of the many benefits of running PeopleSoft on public cloud infrastructure is that you only pay for what you use.  Many cloud services are charged on a Pay As You Go subscription basis and particularly applies to servers (or Instances which are a type of Resource).

In Oracle Cloud Infrastructure (OCI) you only get charged when the server is running.   So, if you have environments which are not often used and non-production systems that are not used during the night or at weekends, then you can shut them down and reduce your costs.

Turn it off and save money.

At time of writing (September 2024) the monthly cost of an E5 Flex shape server with 4 x OCPU and 32 GB RAM would be £109 per month.  This cost is for the server running 24 hours a day for every day in the month (Oracle assume all months have 31 days so bases this price on 744 hours of running time for the server). 

Server running 24 x 7

If this server were part of your non-prod Development estate and your developers started work at 08:00 and finished at 19:00 and if no one needed access to Development over the weekend then this server  could be shutdown on weekday nights and over the weekend.   What would our saving be?

Not all months have the same number of days or same number of weekends so we have to work with an average month.   In OCI a month is deemed to have 31 days or 744 hours.  We could say that each month contains, on average 4.3 weeks. .  

If the server must be available weekday from 08:00 to 19:00 then that's 11 hours of running time.  So how may days of the month does this server need to be running?   If we work on the basis of 4.3 weeks per month then that's about 21.5 weekdays per month or 21.5 x 11 hours = 237 running hours per month

 If we plug this into the Oracle online Cost Estimator the cost per month comes down to £34.76.   

Running weekdays 11 hours a day

If you had 10 x non-prod servers with the same specification as our example then your monthly cost would come down from £1,093 to £348.    This provides a saving of 68% or, over a whole year a saving of nearly £9,000. 

Now, not all services can be stopped (e.g. OCI Firewall) and some services are charged by other metrics (e.g. Block Storage).  So this cost reduction strategy can only be applied to Compute Instances (servers) and other services that are charged by the hour such as Base Database, Digital Assistant and the Oracle Database license component of Exadata Cloud Service.

One of my work colleagues has blogged more on this cost optimisation here https://medium.com/version-1/oracle-cloud-infrastructure-insights-into-oci-cost-optimisation-and-management-f6612b6ee756 

OCI Resource Scheduler

So let's look at the OCI Resource Scheduler, a new feature which allows a schedule to be created to automatically Start or Stop one or more Compute Instances.   Remember, if you turn it off, you save money!

Previously the solution to this operation had to be manually crafted using scripting.  An example of this that I've used before is https://github.com/AnykeyNL/OCI-AutoScale  and if you're looking for something more sophisticated and which covers more OCI resources types (like Base Database) then you may need to continue using a scripted solution.  But the new Resource Scheduler feature is on it's first release and I can well imagine there's a roadmap of enhancements planned.  

What can it do now?

At time of writing (September 2024) the Resource Scheduler can do the following:

• automatically STOP or START Compute or Autonomous DB Instances.
• define the set of Instances as a static list of named specific Instances.
• define a dynamic set of Resources based on filters. Current filters are:
• Compartment
• Instance Type (Compute Instance, Autonomous DB, Instance Pool, OCI Functions)
• Instance State (Running. Stopped, etc)
• Tags (any Tag or Tag value)

This is the first release of this new service (May 2024) and I would imagine we will see other new features and enhancements appear in the future.    Watch for updates on the Resource Scheduler Release Notes page .

How to get started?

There is an excellent Getting Started Guide from the OCI team here  but I'm going to briefly summarise this here along with a few things to look out for.

(1) Create Policies

To prepare for using Resource Scheduler you need to authorize two things; (a) permission for a user to create the Schedules and (b) grant permission to Resource Scheduler to control your Resources .  I found the simplest way to do this was to create the following Policy statements at the Compartment level in which I'm testing this.

(a) Give all the users in my PSAdmin Group the permission to create, edit and delete Schedule definitions. The compartment I'm testing is called GrahamTest.  (Obviously substitute your Group and Compartment names)

Allow group PSAdmins to manage resource-schedule-family in compartment GrahamTest

(b) Give the Schedule itself the permission to control (start/stop) the Resources specified in the Schedule.  

allow any-user to manage instances in compartment GrahamTest where all {request.principal.type='resourceschedule'}

What this Policy does is to grant permission to manage instances (stop/start) for  any user that executes a Schedule which exists in the Compartment GrahamTest.   We don't actually specify the user that will execute a Schedule because it's run by some internal OCI service.  That's why we need both any-user and the action being requested , request.principal.type='resourceschedule'. In other words it's the resourceschedule itself which manages Instances.

NOTE: The example above differs slightly from the example given in the Getting Started guide  (see below) which not only specifies the request.principal.type='resourceschedule' but also explicitly references the OCID of the Schedule definition itself.   Ok... this is not wrong and is probably a little more secure. But, if you delete and recreate the Schedule definition then even if it has the same Name it will have a different OCID and then you must update the Policy for it to have permissions to manage instances.   What I've done is simply to say that ANY Schedule inside my Compartment can have permissions by simply omitting the reference to a specific Schedule OCID.

Specifying the ocid of the Schedule is not required

Omitting the Schedule ocid seems just as satisfactory on the basis that if you have permission to create a Schedule then it seems reasonable that you would want to execute it without having to update and add the Schedule OCID to the Policy rule each time.

(2) Create the Schedule definition

You define a Schedules under Governance & Administration.  A Schedule defines an action (START or STOP) against a set of Instances and a Recurrence (time) for execution and it has a guided 4 step process.

Step 1 - Define the Action

Step 1 - Define Action

Step 2 - Select Resources to control

Choose the set of Resources to perform the action against.  There are 2 methods:  

• Static (specific) Resources. A defined constant list of named Resources. (e.g. only start/stop a specific instance(s))
• Dynamic set of Resources defined by some criteria. Use criteria to qualify Resources for the start/stop operation.

NOTE:  When using Dynamic method, the current set of Resources which match the criteria is displayed for reference.  When the Schedule executes at the the prescribed time the set of qualifying Resources may be different as the criteria is applied at runtime. This is a powerful feature and means that you don't need to keep editing your schedule when you create, terminate or tag resources.

In the example below any Resource Type of Instance and is in Compartment GrahamTest and is in a state of Stopped and has a tag Schedule =  Weekday will be Started.

Step 2 - Example Dynamic Resource Schedule

Step 3 - Define the Recurrence

There is a basic form in which you can define a Schedule (hourly, daily ,weekly, etc) and the time you want the action to be performed.  If this isn't enough you can specify a Cron expression (see example below).

Step 3 - Define Recurrence - Every day at 17:20

Cron Example.   30 15 * * 1-5 is 15:30, Monday through Friday

A note about Tagging

In my example above I selected any instances that were in a specific Compartment that had a specific tag.

This is a great way to qualify which Instances are included in your nightly or weekend shutdown Schedule.   It also provides a nice and easy way of removing an Instance from the schedule if you want to leave it up and running for some reason either permanently or temporarily.  Just change the Tag value.  You could define Tag values to mean different things. To process each Tag differently you would need a Schedule defined for each.  For example:

• Weekday:  Start @ 08:00 and Stop @ 19:00, Mon - Fri.  (ie shutdown at night time)
• Weekend:  Stop @ 19:00 Friday and Start 08:00 Monday.  (ie shutdown at weekends)
• UpAllTheTime:  Do not qualify in any Schedule Resource selection.  (ie never shutdown)

Weekday Tag

In Conclusion

• If you shut the Compute Instance down then you save money.
• Some Instances need to be available at different times to others. (e.g. Demo vs Development)
• This problem was previously solved using Cron jobs and scripting. Now there is a native OCI Resource Schedule service.
• I can imagine that Oracle will start to add other actions and features to this Scheduler.   Some of the things I'd really like to see in a future release include
• Pre-shutdown scripts.  My own custom scripts to be executed on the target before it's shutdown.  This would allow me to do controlled shutdowns of PeopleSoft services.
• New action of "Script Only".  In other words just run my custom script against the qualified targets.  This would allow me to use this Resource Scheduler service as a general purpose job scheduler.
• Improved logging with easier to read displays of Instances affected and drillable  links to those instances from the Log page.