In this video, I'll show you how to patch individual components on the Oracle Private
Cloud Appliance.
Security and other updates are provided through patches.
Upgrading your appliance is a different process and uses a different set of commands than
patching.
For upgrade directions, refer to the System Upgrade section of the Oracle Private Cloud
Appliance Administrator Guide at the URL shown: https://docs.oracle.com/en/engineered-systems/private-cloud-appliance/3.0/admin-3.0.1
Patches are delivered as RPM packages through a series of dedicated channels on the Unbreakable
Linux Network (ULN).
Oracle Private Cloud Appliance is not allowed to connect directly to Oracle's ULN servers.
Therefore, you must use a local ULN mirror on a system inside the data center.
Creating a local ULN mirror and configuring your environment for patching is beyond the
scope of this video.
Refer to the Configure Your Environment for Patching section of the Oracle Private Cloud
Appliance Patching Guide at the URL shown: https://docs.oracle.com/en/engineered-systems/private-cloud-appliance/3.0/patch-3.0.1/
Before you begin patching, make sure that you have the correct permissions, and that
you have downloaded the RPM packages to the appropriate locations.
You should also run health checks and perform a system backup before you begin.
I'm going to demonstrate patching from the Service Enclave command-line-interface but
you can also patch individual components using the Service Web UI.
I've logged on to the Service Enclave with an administrator account.
Refer to the "Using the Service CLI on Oracle Private Cloud Appliance" video for a demonstration
on how to use the service command-line-interface.
I'll first enter the command, showcustomcmds patchRequest to ensure that I have the correct
permissions to use the patching commands.
Notice that there are a number of patch commands.
These commands allow you to patch individual hardware and software components.
When you are installing multiple patches at the same time perform the patching operations
in this order: Compute nodes, Management nodes, MySQL cluster
database, EtcD, Vault, Kubernetes cluster, Platform and Firmware.
In this demonstration, I'll be using the patchCN command to patch compute nodes.
I'll be using the patchHost command to patch the management nodes.
And I'll be using the patchPlatform command to patch the platform.
You'll also notice some UlnMirror commands.
The setUpstreamulnMirror is used to enable synchronization between the repository and
the mirror server.
After you have updated the local mirror server, the syncUpstreamulnMirrow command, which I'll
run in this demonstration, updates the local repository used for compute node patches.
And the showupstreamulmMirror command allows you to view the status of the update.
I've switched to an appliance that has been configured for patching and I'm logged in
as the adminstrator to the service command-line-interface.
The first command I'll run is syncUpstreamulnMirrow, which updates the local repository.
This command is successful.
I'm going to patch the compute nodes first.
I'll run the command list computeNode and see that I have 6 compute nodes in this appliance.
Next I'll run a series of commands to complete the patch procedure for each individual compute
node.
These commands are provisioningLock id= the compute node to set the provisioning lock.
Then I'll run maintenanceLock id= the compute node to set the maintenance lock.
Then I'll run show ComputeNode id= the compute node.
This command shows that the locks are set to true and also provides the host IP address
which is needed for the next command.
The next command is patchCN hostIp= the IP address of the compute node, uln= the fully
qualified domain name or the IP address of the ULN mirror in your datacenter, and the
pathname to the RPM files using the syntax shown.
Next I'll run the getUpgradeJobs and wait for the patch job to complete.
Next I'll reboot the compute node.
After the compute node has rebooted, I'll run the maintenanceUnlock id= the compute
node to release the maintenance lock.
And finally, I'll run the provisioningUnlock id= the compute node to release the provisioning
lock.
I'll begin by patching compute node 1.
I run provisioningLock id= and provide the id of compute node 1.
That output shows it was a success.
Next I'll run maintenanceLock id= and provide the id of compute node 1.
This was also a success.
Next I'll run show ComputeNode id= and provide the id of compute node 1.
The output shows that the Provisioning Locked and the Maintenance Locked settings are true.
You can also get the IP address of the compute node which is needed in the patchCN command.
Next I'll run patchCN hostIP= the IP address of compute node 1, uln= and provide the IP
address of the ULN mirror and the path to the RPM packages.
The output shows that the service request has been submitted and provides the job id
and the request id.
This could take up to around 15 minutes to complete so I'll speed through this.
I'm now showing the output of the getUpgradeJobs command, which I just ran.
This shows a number of older jobs with various results but the job that I just submitted
is at the top of the list it shows that the result is Passed, meaning that the patches
were successfully applied to the compute node.
Next I'm going to exit the service CLI and ssh into management node 3 on my appliance.
From here I can ssh into compute node 1 and reboot this compute node.
I need to wait for a few minutes for the compute node to come back up so I'll speed through
this.
After a few minutes, I'll ping compute node 1 just to ensure it's finished rebooting and
my ping command is successful.
Now that compute node 1 has rebooted, I'll exit from management node 3.
I'll log back in to the service command-line-interface.
The final 2 steps for the compute node are to to release the maintenance lock and release
the provisioning lock in that order.
Both these commands require the compute node id as an argument so I'll run the command
list computeNode to get the id for compute node 1.
To release the maintenance lock, I'll run the command maintenanceUnlock id= and provide
the id of compute node 1.
The output shows it was a success.
Finally I'll run provisioningUnlock id= and provide the id of compute node 1.
This was also a success.
And that completes the patching of compute node 1.
Perform this same sequence of steps and commands shown, that I summarized earlier in this video,
for the remaining compute nodes.
I've completed these steps and here I'm showing the output of the getUpgradeJobs command.
Notice that all six compute notes now have a result of Passed.
I'll now move on to patching of management nodes.
Similar to compute node patching, the management nodes must be patched one node at a time.
One of the management nodes holds the cluster virtual IP.
Determine which management node that is, and patch the other management nodes first.
You then move the cluster virtual IP to one of the patched management nodes.
At that point, you are free to patch the final managment node after it no longer holds the
cluster virtual IP.
I'll log on to one of the management nodes and check the status of the cluster.
From here, I'll run the command pcs status.
The output shows that management node 3, or pcamn03, currently holds the cluster virtual
IP.
So I want to patch the other management nodes first, then move the cluster virtual IP to
one of these patched management nodes, before patching management node 3.
I'll log off this node and log back in to the service command-line-interface.
Now I'll run the command patchHost HostIp= and provide the IP address of management node
1, Uln= and provide the the IP address of the ULN mirror and the path to the RPM packages.
I made a typo which I'll correct and run the command again and this time it is a success.
The output shows that the service request has been submitted and provides the job Id
and the request Id.
I'll run the getUpgradeJobs and we see our management host patch job has a result of
None.
I'll wait a few minutes and run the command again and now we see the result is Passed.
Next I'm going to exit the service CLI and ssh into management node 3.
From here I can ssh into management node 1 and reboot this management node.
I need to wait for a few minutes for the management node to come back up so I'll speed through
this.
After a few minutes, I'll ping management node 1 just to ensure it's finished rebooting
and my ping command is successful.
Now that management node 1 has rebooted, I'll exit from management node 3.
I won't demonstrate but next I need to repeat these steps for management node 2.
From the service CLI, run the patchHost command for management node 2.
Run the getUpgradeJobs command to ensure the patch result is Passed.
Here I'm showing the output of this command and that the result is Passed.
Then exit the Service CLI and log into managment node 2 and reboot it.
You next need to move the cluster virtual IP to one of the patched management nodes.
Use the pcs resource command as shown.
This example moves the virtual IP to managment node 1.
You can then optionally run the pcs status command to ensure the previous command was
successful.
I'll demonstrate these 2 commands.
I'm logged on to management node 3 and I'll run pcs resource move mgmt-rg pcamn01.
This breaks my connection to management node 3.
So I'll log in to management node 1 and run the pcs status command from here.
The output shows that management node 1, or pcamn01, now holds the cluster virtual IP.
So I'm now free to patch management node 3 to complete patching of all the management
nodes.
I'm not going to demonstrate but you just need to run the patchHost command from the
service CLI for management node 3.
Run the getUpgradeJobs command to ensure the patch result is Passed.
And exit the Service CLI and log into managment node 3 and reboot it.
Here I'm showing the output of the getUpgradeJobs command and see that the result is Passed
for all 3 management nodes.
I'll now move on to patching the platform.
The platform patching covers both the internal services of the platform layer, and the administrative
and user-level services exposed through the infrastructure services layer.
From the Service CLI, use the patchPlatform command as shown.
This command has only one argument, the fully qualified domain name of the ULN mirror in
your datacenter.
As was the case for compute node patching and management node patching, use the getupgradejobs
command to check the status of the platform patch.
I'll demonstrate patching the platform.
I'm logged on to the service CLI.
I'll enter the command patchPlatform Uln= the fully qualified domain name or the IP
address of the ULN mirror in your datacenter, and the pathname to the RPM packages.
Output shows the status of success and the job and request Ids.
I'll run the command getupgradejobs.
The initial result of the job is None.
I'll wait a few minutes and run the command again.
This time the result is Passed.
Refer to the Oracle Private Cloud Appliance documentation for more information.
For additional training videos like this, go to oracle.com/goto/pcalearning.
This concludes this video.
Thank you for watching.