Oracle Grid Infrastructure 18c patching part 1: Some history

Posted on by

Down the memory lane

Although sometimes I think I have been working with Oracle Grid Infrastructure since it exists, sometimes my memory does not work well. I still like to go through the Oracle RAC family history from time to time:

  • 8i -> no Oracle cluster did exist. RAC was leveraging 3rd party clusters (like Tru Cluster, AIX HACMP, Sun Cluster)…
  • 9i -> if I remember well, Oracle hired some developers of Tru Cluster after the acquisition of Compaq by HP. Oracle CRS was born and was quite similar to Tru Cluster. (The commands were almost the same: crs_stat instead of caa_stat, etc)
  • 10g -> Oracle re-branded CRS to Clusterware
  • 11g -> With the addition of ASM (and other components), Oracle created the concept of “Grid Infrastructure”, composed by Clusterware and additional products. All the new versions still use the name Grid Infrastructure and new products have been added through the years (ACFS, RHP, QoS …)

But I have missing souvenirs. For example, I cannot remember having ever upgraded an Oracle Cluster from 9i to 10g or from 10g to 11g. At that time I was working for several customers, and every new release was installed on new Hardware.

My first, real upgrade (as far as I can remember) was from 11gR2 to 12c, where the upgrade process was a nice, OUI-driven, out-of-place install.

The process was (still is 🙂 ) nice and smooth:

  • The installer copies, prepares and links the binaries on all the nodes in a new Oracle Home
  • The upgrade process is rolling: the first node puts the cluster in upgrade mode
  • The last node does the final steps and exists the cluster from the upgrade mode.

This is about Upgrading to a new release. But what about patching?

In-place patching

Patching of Grid Infrastructure has always been in-place and, I will not hide it, quite painful.

If you wanted to patch a Grid Infrastructure before release 12cR2, you had to:

  • read the documentation carefully and check for possible conflicts
  • backup the Grid Home
  • copy the patch on the host
  • evacuate all the services and databases from the cluster node that you want to patch
  • patch the binaries (depending on the versions and patches, this might be easy with opatchauto or quite painful with manual unlocking/locking and manual opatch steps)
  • restart/relocate the services back on the node
  • repeat the tasks for every node

The disadvantages of in-place patching are many:

  • Need to stage the patch on every node
  • Need to repeat the patching process for every node
  • No easy rollback (some bad problems might lead to deconfiguring the cluster from one node and then adding it back to the cluster)

Out-of-place patching

Out-of-place patching is proven to be much a better solution. I am doing it regularly since a while for Oracle Database homes and I am very satisfied with it. I am implementing it at CERN as well, and it will unlock new levels of server consolidation 🙂

I have written a blog series here, and presented about it a few times.

But out-of-place patching for Grid Infrastructure is VERY recent.

12cR2: opatchauto 

Oracle 12cR2 introduced out-of-place patching as a new feature of opatchauto.

This MOS document explains it quite in detail:

Grid Infrastructure Out of Place ( OOP ) Patching using opatchauto (Doc ID 2419319.1)

The process is the following:

  • a preparation process clones the active Oracle Home on the current node and patches it
  • a switch process switches the active Oracle Home from the old one to the prepared clone
  • those two phases are repeated for each node

12cr2-oop

The good thing is that the preparation can be done in advance on all the nodes and the switch can be triggered only if all the clones are patched successfully.

However, the staging of the patch, the cloning and patching must still happen on every node, making the concept of golden images quite useless for patching.

It is worth to mention, at this point, that Grid Infrastructure Golden Images ARE A THING, and that they have been introduced by Rapid Home Provisioning release 12cR2, where cluster automatic provisioning has been included as a new feature.

This Grid Infrastructure golden images have already been mentioned here and here.

I have discussed about Rapid Home provisioning itself here, but I will ad a couple of thoughts in the next paragraph.

18c and the brand new Independent local-mode Automaton

I have been early tester of the Rapid Home Provisioning product, when it has been released with Oracle 12.1.0.2. I have presented about it at UKOUG and as a RAC SIG webinar.
https://www.youtube.com/watch?v=vaB4RWjYPq0
http://www.ludovicocaldara.net/dba/rhp-presentation/

I liked the product A LOT, despite a few bugs due to the initial release. The concept of out-of-placing patching that RHP uses is the best one, in my opinion, to cope with frequent patches and upgrades.

Now, with Oracle 18c, the Rapid Home Provisioning Independent Local-mode Automaton comes to play. There is not that much documentation about it, even in the Oracle documentation, but a few things are clear:

  • The Independent local-mode automaton comes without additional licenses as it is not part of the RHP Server/Client infrastructure
  • It is 100% local to the cluster where it is used
  • Its main “job” is to allow moving Grid Infrastructure Homes from a non-patched version to an out-of-place patched one.

I will not disclore more here, as the rest of this blog series is focused on this new product 🙂

Stay tuned for details, examples and feedback from its usage at CERN 😉

—

Ludo

The following two tabs change content below.
My Twitter profileMy LinkedIn profile

Ludovico

Principal Product Manager at Oracle
Ludovico is a member of the Oracle Database High Availability (HA), Scalability & Maximum Availability Architecture (MAA) Product Management team in Oracle. He focuses on Oracle Data Guard, Flashback technologies, and Cloud MAA.

12 thoughts on “Oracle Grid Infrastructure 18c patching part 1: Some history”

  1. Hi Ludovico,

    you mentioned that at CERN you have fully automated cluster installation/patching including the infrastructure , Kindly share some detail about the solution if possible as I am also looking something like this for our environment.

    Many thanks
    Raj

    Reply ↓

    • Hi Raj,
      once the servers are ready in the rack, their information is updated in a central inventory.
      As first step, the servers are automatically installed using PXE/TFTP using an OS image. The install process include the puppet agent.
      When we need to install a new cluster, we put the servers in a puppet hostgroup that triggers the modules that set all the requirements (packages, parameters, users, volumes, etc.). Then we run a rundeck job where we pass in input the hosts, the cluster name and the Grid Infrastructure golden image.
      The rundeck job itself is a series of script that prepares the ASM volumes, sets up the firewall for the cluster, etc.. and then runs the gridSetup, the root.sh and the post config.
      Sorry, I cannot share all the details, it would take a couple of books 🙂
      —
      Ludo

      Reply ↓

  2. Hi,

    Is there any testing completed on RHP in local mode, starting 19c this seems a very good option (considering traditional OOP) to handle the gold images better.

    Thanks

    Reply ↓

  3. Hi Ken, of course you are right. My memory lane was about the cluster layer. If I remember correctly, OPS had no cluster layer (voting disks, quorums) also because no cache fusion at the time. The disk sharing was assured by 3rd party clusters (veritas?)

    Reply ↓

  4. memory lane correction if you care, oracle 8.0.x came out with OPS aka Oracle parallel server, that was the 1st attempt by Oracle in building active-active cluster.
    i like to look around heavy user of RHP like me to see what i can do better.

    Reply ↓

  6. In oracle 18c they mentioned Zero impact grid patching but dont find any details in metalink or documentation could you do a post on oracle 18c grid zero impact patching,it would be really helpful for the community

    Reply ↓

  7. Hi Norbert, Look at it the other way around:
    the Database Licensing Information User Manual says that RHP is included in EE and does not need Lifecycle Management Pack except if it is a cross-cluster deployment:

    “EE and EE-ES: When deployed across multiple clusters, requires Oracle Database Lifecycle Management Pack for Oracle Database on targets”

    https://docs.oracle.com/en/database/oracle/oracle-database/18/dblic/Licensing-Information.html#GUID-0F9EB85D-4610-4EDF-89C2-4916A0E7AC87

    As the local-mode automaton is local-only and not managed by a RHP server, it is included in EE.

    Reply ↓

  8. Hello,
    I am looking for a place in the documentation that describes that the “Independent local-mode automaton” is not part of the Lifecycle Management Pack. Can you please name the reference to which your statement refers?

    Best regards
    Norbert Gößwein

    Reply ↓

  9. Hi Michael,
    to be honest, I gave it just a small try with Grid Infrastructure deployments while working at Trivadis. Because it was not stable in its initial release, I opted for custom solutions to cope with my customer requirements.
    Now I expect the 18c release to be better, but at CERN now we have already a fully automated cluster installation (including storage, network and other prereqs), so we will probably stick on our solution rather than trying to introduce the full RHP framework.
    The local-mode automaton by opposite is exactly what I was looking for 😀

    Best regards
    —
    Ludovico

    Reply ↓

  10. Ludovico,

    Looking forward to seeing your content on Local-mode Automaton.

    Do you consider RHP Server ready to be used for deploying Grid?

    Using 12.2.0.1… my experience using RHP to deploy DB homes and move between them has been great.

    In contrast my experience with using RHP to move grid homes hasn’t been that great. When using RHP to move GI Homes… I have had inconsistent results across non-prod, standby and prod clusters. Which has eroded my trust in this tool.

    I am going to look at 18C version and see if it is more stable.

    Regards

    Michael Lewis

    Reply ↓

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.