9.4 Nutanix Database Service (NDB) and Database Automation

9.4 Nutanix Database Service (NDB) and Database Automation

Objective 1.2 lists "identify Nutanix Database Automation use cases and features," and the blueprint's reference list points at a single document: Nutanix Database Service (NDB) Overview. NDB, previously shipped under the name Era, is the product behind that phrase. As with every Objective 1.2 item the exam wants recognition — what problem does it solve, what are its headline features, and which capability name matches which scenario — rather than the administration depth tested by the NCP-DB exam.

The Problem NDB Solves

In most organizations databases are the least automated part of the estate. A new database means a ticket to the DBA team; a test refresh means a full copy of production; patching means a maintenance window negotiated instance by instance; and every application team has quietly accumulated copies of the same data. The result is slow delivery, inconsistent configuration, and a large amount of duplicated storage.

NDB provides a database-as-a-service control plane on Nutanix. Application teams request a database from a catalog, the platform provisions it to a standard, protects it automatically, and can refresh it from production on demand. The DBA team stops being a provisioning queue and starts owning the standards that provisioning uses.

Supported Database Engines

NDB is deliberately multi-engine. Nutanix documents support for:

The recognition point is that NDB is not a Nutanix-proprietary database engine and is not limited to one vendor. It is an automation and lifecycle layer wrapped around engines the customer already runs. If an exam option describes "the Nutanix database" as a product you store data in, it is describing something that does not exist.

The Four NDB Services

Nutanix organizes NDB's capabilities into four named services. Learning these four names is the fastest route through any NDB recognition question.

1. One-Click Provisioning

NDB provisions databases from four kinds of profile, and the profile is the unit of standardization:

• Software profile — the operating system image plus the database engine binaries and patch level.
• Compute profile — the vCPU and memory shape of the database server VM.
• Network profile — which VLAN or subnet the database server VM lands on, its gateway, and whether addresses come from DHCP or from a static pool NDB manages.
• Database parameter profile — the engine configuration values, such as PostgreSQL postgresql.conf settings or SQL Server configuration options, applied at provisioning time.

Because every database of a given class is built from the same four profiles, they come out identical. That is what removes the configuration drift that makes large database estates almost impossible to patch safely.

2. Copy Data Management (CDM)

This is the capability customers most often buy NDB for. An NDB clone is built on the same redirect-on-write snapshot and zero-byte clone mechanics covered in section 5.2: the clone initially consumes almost no additional capacity because it shares extents with its parent, and only diverging writes consume new space.

Three CDM features matter for recognition:

• Thin clones. Refreshing a multi-terabyte test database from production goes from an overnight copy job to a task measured in minutes, and ten developer copies of a 4 TB database no longer consume 40 TB.
• Clone refresh schedules. A clone can be set to refresh automatically to the latest state — or to a chosen point in time — on a schedule, and a matching removal schedule can retire short-lived copies so they do not accumulate.
• Sanitized snapshots. NDB can produce a snapshot with sensitive columns masked, so a clone handed to a development team does not carry production personal data into a lower environment. When a scenario mentions compliance concerns about test copies, this is the intended answer.

3. Database Protection

Time Machine is the feature name to remember. Every database registered with NDB gets a Time Machine that captures snapshots on a schedule and continuously backs up transaction logs through an operation NDB calls log catch-up.

Retention is governed by an SLA, and Nutanix defines an SLA as a set of retention durations:

The Continuous value is the one that produces point-in-time recovery. If an SLA sets Continuous to 10 days and Daily to 30 days, then within the last 10 days the database can be restored to any second — the moment before a bad deployment or an errant DELETE — while days 11 through 30 offer recovery only to the discrete daily snapshot. Understanding that split is the difference between reading an NDB scenario correctly and guessing.

Snapshots are also promoted as they age: a daily snapshot that falls on the designated weekly day becomes the weekly snapshot rather than being deleted, and the same promotion carries a weekly into a monthly and a monthly into a quarterly. That is why longer retention tiers do not multiply capacity consumption the way an equivalent stack of independent full backups would.

Data Access Management extends a Time Machine's reach: snapshot and log data can be replicated to additional registered Nutanix clusters, so a clone can be created at a second site, and NDB can tier older backup data to a Nutanix Objects store rather than keeping everything on primary storage.

4. One-Click Patching

Patching is driven from the software profile rather than instance by instance. An administrator publishes a new patch level into the profile and rolls it out to the databases using it. NDB associates the work with a maintenance window, so operating-system and database patching happens inside an agreed period instead of requiring a per-database negotiation.

How NDB Is Deployed

At NCA level you only need the shape, not the build procedure:

• NDB runs as a control-plane VM on a Nutanix cluster, on either AHV or ESXi.
• A lightweight NDB agent runs on each managed database server VM and executes the scheduled work.
• In a multi-cluster deployment, additional Nutanix clusters are registered with NDB and each gets its own agent, which is how one NDB instance manages databases across several clusters and sites.
• An optional high-availability configuration replaces the single control-plane VM with multiple API servers, a replicated internal repository, and a load-balanced virtual IP spread across clusters.

Where NDB Runs

NDB manages databases on Nutanix clusters in the datacenter, at the edge, and on NC2 running on public-cloud bare metal. The same provisioning, protection, and cloning workflows apply in all three places, which is the "multicloud" part of the value proposition and the reason NDB appears on a multicloud infrastructure exam at all. NDB also exposes a REST API and a Kubernetes operator, so database provisioning can be driven from the same pipelines that deploy the application.

[!TIP] If an exam scenario describes a team waiting days for a test database refresh, or storage consumed by many near-identical database copies, NDB with space-efficient clones is the intended answer. If it describes recovery "to the moment before the incident," the answer is Time Machine with continuous log retention.

Summary for the Exam