Oracle’s Infrastructure as a Service (IaaS) public cloud provides raw compute and storage capabilities that can be used for almost any workload. This blog series will outline the process used to migrate existing workload from our on-premises data center to instances running on Oracle IaaS public cloud compute and storage services. The first part of this series covered the process to manually create the components needed to start an instance using Oracle provided Enterprise Linux image on the Oracle public cloud. The second part covered the process to secure the Oracle IaaS instances. This part of the series will describe the use of orchestrations to provision storage and instances.
The use of orchestrations is the recommended way of provisioning storage and instances in the Oracle Iaas public cloud. The primary reason for this is because it provides a repeatable method of stopping and starting instances. There are also HA policies available on the orchestrations to aid in auto restart of the environment. These HA policies are not visible via the UI. Finally, scaling an IaaS instance can be done by simply updating the orchestration and stopping/starting the orchestration.
The basic process to use orchestrations is as follows:
- Create a security IP reservation
- Build the JSON file containing the orchestration to provision the storage
- Build the JSON file containing the orchestration to provision the instance
- Upload both JSON files to the Oracle IaaS public cloud
- Start the storage orchestration
- Start the instance orchestration
Create a Security IP Reservation:
An IP reservation is used to reserve a public IP address that can be used to access the instances being provisioned. In the main list of tabs, select Network and then select IP Reservations from the options on the left hand side. Click on the Create IP Reservation button:
Enter the name of the IP Reservation and leave For Instance set to None. For clarity, it is recommended that the name reference the name of the host being provisioned. Click on Create:
NOTE*** IP Reservations can also be done using a third orchestration if desired.
Build a Storage Orchestration file:
The storage orchestration file is used to provision the storage that will be used the instance. This is a JSON file and the various options that can be added in the JSON are documented in Oracle Cloud Documentation. Recommendations for building the orchestration:
- There should always be at least two volumes, one for the boot volume and one or more for user data.
- Boot volume should have bootable set to true and should select the OS image from the available list.
- HA_POLICY should be set to monitor for storage orchestrations.
NOTE*** IDENTITY_DOMAIN will need to be changed to match your security domain and USERID will need to be changed to match a userid within your identity domain. These are both used when you log in to the IaaS public cloud and are usually visible in the upper right hand corner of most of the screens.
Sample orchestration file:
{
 "description": "Storage volumes for fdwld75",
 "name": "/IDENTITY_DOMAIN/USERID/fdwld75_storage",
 "oplans": [
   {
     "label": "fdwld75_storage",
     "obj_type": "storage/volume",
     "objects": [
       {
           "name": "/IDENTITY_DOMAIN/USERID/fdwld75_boot",
           "bootable": true,
           "imagelist": "/oracle/public/oel_6.4_5GB_RD",
           "properties": ["/oracle/public/storage/default"],
           "size": "6G"
        },
       {
           "name": "/IDENTITY_DOMAIN/USERID/fdwld75_data1",
           "properties": ["/oracle/public/storage/default"],
           "size": "50G"
        }     ],
                    "ha_policy": "monitor"
   }
 ]
}
The above orchestration file will provision two storage volumes, a 6GB volume containing the bootable image of an OEL 6.4 image and a 50GB.
Build an Instance orchestration file:
The instance orchestration is used to associate the instance to IP reservation, ssh keys, security lists, and the storage to provide a running Linux instance.
Sample instance orchestration file:
{
 "description": "oplan for fdwld75",
 "name": "/IDENTITY_DOMAIN/USERID/fdwld75",
 "oplans": [
   {
     "label": "fdwld75_oplan",
     "obj_type": "launchplan",
     "objects": [
       {
         "instances": [
           {
             "imagelist": "/oracle/public/ol_6.4_5GB_RD",
             "label": "fdwld75",
                                                            "hostname": "fdwld75",
             "networking": {
               "eth0": {
                 "seclists": [
"/IDENTITY_DOMAIN/default/default",
                   "/ IDENTITY_DOMAIN/USERID/DemoFDW"
                 ],
                 "nat": "ipreservation:/IDENTITY_DOMAIN/USERID/fdwld75"
               }
             },
             "shape": "oc3",
             "storage_attachments": [
               {
                 "index": 1,
                 "volume": "/IDENTITY_DOMAIN/USERID/fdwld75_boot"
               },
               {
                 "index": 2,
                 "volume": "/IDENTITY_DOMAIN/USERID/fdwld75_data1"
               }
             ],
             "boot_order": [1],
             "sshkeys": [
               "/IDENTITY_DOMAIN/USERID/id_rsa"
             ]
           }
         ]
       }
     ],
                    "ha_policy": "active"
   }
 ]
}
The orchestration above accomplishes the following:
- Creates an orchestration named fdwld75
- Defines the launchplan (basically the list and order of things to link together) containing:
- OS image of OL_6.4_5GB_RD (an OEL 6.4 5 GB OS image)
- Name the host fdwld75
- Assign security lists (refer to Oracle Iaas Public Cloud: Securing Instances blog) default and DemoFDW
- Attach the IP Reservation created earlier (fdwld75)
- Pick the shape (OC3 equates to 1 OCPU and 7.5 GB of memory)
- Assign the boot and data volumes that were allocated in the storage orchestration
- Associate the ssh public key (refer to Oracle Iaas Public Cloud: Creating Instances blog)
- Set ha_policy to ACTIVE (this will restart the instance if maintenance is performed by Oracle for example)
Refer to the Oracle Cloud documentation for the full details on all of the options available in the JSON.
Upload the orchestration files:
To make the orchestration files accessible to the IaaS public cloud, we now need to upload these files.
From the Orchestrations tab, click on the Upload Orchestration button:
Use the Choose File option and pick one of the orchestration files and click on Upload:
If the Orchestration file is valid, the following messages will appear:
If there are errors in your Orchestration file, an error message will appear instead with a link to download a file containing the error details will be shown.
Repeat this process for your other orchestration file.
Start the storage Orchestration
Now that the Orchestration files are loaded on the IaaS cloud, we can start the storage Orchestration.  Starting the storage orchestration will provision the storage and bring it online for the instance to use. CAUTION: There is an option to stop a storage orchestration. Be warned that stopping a storage orchestration will delete the storage and everything on it will be lost. Once started, a storage orchestration would rarely if ever need to be stopped or started.
From the Orchestration tab, select the drop to the right of the storage orchestration and click on Start:
When the status turns to Ready, you can proceed with starting the instance orchestration.
Start the instance Orchestration:
The instance Orchestration is started following the same steps as starting the storage orchestration. When the instance orchestration status is Ready, you will be able to ssh to the instance and proceed with installing whatever application software you need. After logging on to the OS, you should see the device for the data volume. You will now be able to create a file system, mount it on that device, and add the appropriate entry to fstab if desired. This would make the data volume auto mount every time the instance orchestration is stopped and started.
Note, opposite of the storage orchestration, the instance orchestration will be stop and started several times without losing any data. Stopping an instance orchestration is equivalent to rebooting a VM or Linux host. The recommendation to split storage orchestrations and instance orchestrations into separate orchestrations is made to avoid accidently wiping out the disk by stopping the orchestration containing a disk allocation.
A common example of needing to stop and start the instance orchestration would be scale the instance. To add memory, CPU, or both, you would simply stop the instance orchestration. Update the orchestration file to pick a new shape (for example changing OC3 to OC1M goes from 1 cpu with 7.5GB of memory to 1 cpu with 15GB of memory) and upload that orchestration. Starting that orchestration will now use the same storage volumes (and all of the data on them) with the new CPU and memory configuration.
Conclusion:
The steps listed above are the basic operations needed to provision storage and instances using orchestrations. The use of orchestrations is the recommended approach for managing instances and storage on the IaaS public cloud because of the reasons outlined earlier in this blog. In the next portion of this blog series, we will explore how to leverage FlexDeploy in the Oracle cloud.
Continue your Oracle Cloud education with the blog series: Â FlexDeploy and Oracle Cloud.