House of Brick has seen a lot of interest from customers lately in migrating Oracle and SQL Server database platforms away from VMware vSphere virtualized environment and into Nutanix environments. While likely driven by a desire to avoid Broadcom’s price hikes and bundling for VMware products, it does put DBAs in the awkward position of needing to learn a new platform. In the case of customers who are purchasing Nutanix Database Service (NDB) as their new platform for virtualizated databases, this can be especially confusing as NDB is far more than a hypervisor.
What Is Nutanix Database Service (NDB) — Not Just Another DBaaS
NDB at first glance seems to be a Database-as-a-service (DBaaS) software similar to Amazon Relational Database Service or other similar offerings from cloud vendors, but DBAs approaching it with that expectation are often disappointed. NDB is actually a framework for building a DBaaS platform, but it’s up to the DBA teams to configure and operate the master images, the patching cadence, etc.
There’s a daunting learning curve to adjust traditional, and likely manual, DBA operations to embrace this framework and gain advantages in speed and quality of routine activities such as database provisioning, cloning, and patching. In this post we will focus on patching on specific as the NDB documentation is a bit high-level and vague, so we wanted to share some tips we’ve learned about patching Oracle databases in NDB to make this a smoother experience for a DBA approaching NDB for the first time.
Building a Custom RPM Repository for Safe O/S Patching
First off, NDB will do O/S patching. For the systems we see most often, mostly Oracle databases running Red Hat Enterprise Linux (RHEL) or Oracle Enterprise Linux (OEL), this means running yum or dnf to upgrade the system. When issuing the command via the NDB console to patch the operating system for a database VM, all that happens is that NDB invokes yum or dnf and asks it to upgrade to latest patches that are available at that moment. This can be dangerous in that there is no logic to validate that those patches are compatible with the release and configuration of the database running in the VM or are in sync with patches applied in other environments.
To keep new patches from being tested first in a production environment, House of Brick recommends building a custom RPM repository to house a known patchset and pointing all the DB VMs at that repository. This will ensure consistent patches are available even if the process of performing O/S upgrades on DB VMs spans several weeks. This creates a predictable and repeatable flow where at the beginning of each DB VM patching cycle, the custom repository is updated with latest patches, then the patches are tested in sandbox or non-production environments, and only after lower-environment validation are the patches applied to production environments.
Managing Database Software Patching with NDB Profile Versions
The patching of the database software itself is relatively straightforward, but again it’s up to the DBA to control exactly which patches get applied and when. In order to patch in NDB, a new version of the NDB profile with a newer patch level must be created in the NDB console. This is done by instantiang a new empty reference DB VM, either by provisioning one via NDB or simply by keeping a reference VM around constantly.
The new patches are then manually applied to the reference VM and the new software layout is ingested into NDB as a new profile version. The updated profile version can then be applied to all existing DB VMs built from the original profile as a patch. NDB automation makes the patch application relatively smooth and seamless, but there are a few traps that can trip up the unwary DBA.
Testing and Rollback Strategies to De-risk NDB Patch Deployments
One mistake we see a lot of organizations make is not further validating the NDB patches because the exercise to patch the reference VM manually didn’t encounter issues. Unfortunately just because the reference VM patched smoothly doesn’t mean that NDB will be able to roll the patches smoothly into more complex DB VMs that may have different workloads or circumstances. Proper caution calls for testing the NDB patching on throwaway clones of existing DB VMs in order to validate that the patched DB is entirely functional and performant. In addition rollback should be tested as well and timings gathered so that the patching exercise is smooth and issue-free when applied to business-critical production databases.
Overall NDB is a great tool for managing fleets of databases, but don’t make the mistake of assuming that the NDB-provided automation will guard against the traditional DBA issues of incompatible or flaky patches at the O/S or DB level. Do proper validation and exercise caution, NDB is a good automation tool for streamlining things but it can’t replace technical and testing safeguards to de-risk patching exercises.
Ready to De-Risk Your NDB Patching?
Don’t leave your Oracle and SQL Server updates to chance. Partner with House of Brick’s experts to build your custom RPM repository, manage NDB profile versions, and validate rollback strategies—so your production databases stay safe and performant.
