NuoDB has a distributed object architecture that works in the cloud, which means that in order to scale-out the database, a new node can be added and the database runs faster. That’s why it represents the perfect example of a new-gen cloud-native architecture and a solution for containerized applications running on Kubernetes.

NuoDB provides all the properties of ACID-compliant transactions and standard relational SQL language support. It’s designed from the start as a distributed system that scales the way a cloud-native service is expected to scale, providing continuous availability (CA) and resiliency with no single points of failure. Different from traditional shared-disk or shared-nothing architectures, NuoDB presents a new kind of peer-to-peer, on-demand independence that yields CA, low-latency, and a deployment model that is easy to manage. The chart below is a simple comparison and decision chart from the NuoDB website.

Quick Notes on the NuoDB Architecture

NewSQL systems are designed to operate in a distributed cluster of shared-nothing nodes, in which each node owns a subset of the data.

Although it appears as a single, logical SQL database to the application, it has two-layers that retain strict transactional consistency. It can even be deployed across multiple availability zones (even on different clouds!) and is optimized for in-memory speeds, continuous availability, and adaptive scale-out that adjusts to the application needs.

NuoDB Architecture: TEs (Top), SMs (Bottom)

Transaction Engines (TEs): The TE layer is used for (ACID) SQL and caching, made up of in-memory process nodes that coordinate with each other and the SM layer.

Storage Managers (SMs): The SM layer is used for storage and consists of process nodes that have both in-memory and on-disk storage components. SMs provide on-disk data durability guarantees, and multiple SMs can be used to increase data redundancy.

Both TE and SM node types can be easily added or removed to align with need.

Why Use OpenEBS for NuoDB?

Running applications on traditional virtualized systems or bare metal are different than running them on Kubernetes. NuoDB is a horizontally scalable database which offers scale up in performance on the fly from the underlying storage system. Container Attached Storage (CAS) solutions like OpenEBS is a perfect choice to run NuoDB on Kubernetes, both on-premise (such as OpenShift) and cloud because of the following benefits:

Local disks or cloud disks are managed seamlessly and in the same way by OpenEBS;

Persistent volumes (PVs) can be made available to NuoDB from a shared pool of disks. You can run multiple stateful databases out of the same physical disks present on the Kubernetes worker nodes, simplifying operations, increasing density, and decreasing costs;

Large size PVs can be provisioned for NuoDB. OpenEBS supports volumes up to petabytes in size;

Increasing the size of PVs as needed. With OpenEBS it is possible to start with small capacities and to add disks as needed on the fly. Sometimes NuoDB instances are scaled up because of capacity on the nodes. With OpenEBS persistent volumes, capacity can be thin provisioned and disks can be added to OpenEBS on the fly without disruption of service;

In situations where NuoDB requires highly available storage, OpenEBS volumes configured with three replicas to provide availability even across zones;

NuoDB backups can be taken at the storage level and stored in S3. Using these backup/restore capabilities of OpenEBS, NuoDB instances can be moved across clouds or Kubernetes clusters seamlessly. There is no vendor lock-in problem when OpenEBS is used as the underlying storage;

And last but not the least – OpenEBS is 100% open source and in userspace.

Hardware

How to Install NuoDB?

If you don’t have an OpenShift cluster you can follow my previous blog here to get both OpenShift and cloud-native storage OpenEBS up and running on Kubernetes.

The NuoDB CE OpenShift template is available in two options: using ephemeral storage and using persistent storage. With ephemeral storage, if the Admin Service pod or Storage Manager (SM) pod are stopped or deleted, the database will be removed with the pod as expected. That is where OpenEBS comes into play. When running NuoDB on OpenEBS, even if the pod is stopped or deleted, the DB state will be preserved and available again on automatic pod restart.

Disable Transparent Huge Pages (THP)

Additionally, on your OpenShift nodes run the command below to make sure Transparent Huge Pages (THP) is disabled. NuoDB will not run on a Linux machine with THP enabled.

$ cat/sys/kernel/mm/transparent_hugepage/enabled

If it returns |always| madvise never THP is enabled and you must disable it by adding the transparent_hugepage=never kernel parameter option to the grub2 configuration file. Append or change the “transparent_hugepage=never” kernel parameter on the GRUB_CMDLINE_LINUX option in /etc/default/grub file similar to below:

Configure cStor Pool

After OpenEBS installation, cStor pool has to be configured. If cStor Pool is not configured in your OpenEBS cluster, this can be done following the instructions here. Sample YAML named openebs-config.yaml for configuring cStor Pool is provided in the Configuration details below. During cStor Pool creation, make sure that the maxPools parameter is set to >=3.

Create the Storage Class

You must configure a StorageClass to provision a cStor volume on a given cStor pool. StorageClass is the interface through which most of the OpenEBS storage policies are defined. I will be using a StorageClass to consume the cStor Pool that is created using external disks attached on the Nodes. Since NuoDB is a statefulset application, it requires only a single storage replica. So cStor volume replicaCount is =1. Sample YAML named openebs-nuodb.yaml to consume cStor pool with cStoveVolume Replica count as 1 is provided in the configuration details below.

Click “Create” and shortly you will see one pod each for the Administrative Service (Admin), Storage Manager (SM), Transaction Engine (TE) and Insights processes started under the nuodb namespace with volumes provided by OpenEBS.

NuoDB installed

What’s Next?

If you would like to read more about the design considerations, running test loads with YCSB, monitoring through Insights or volume metrics through MayaOnline and inserting some chaos engineering with Litmus you can find a detailed solution doc on MayaData website under the Resources section here.

Next, I plan to cover some 2nd-day operations for NuoDB using OpenEBS snapshots, clones, backup, recovery and using MayaOnline functionalities such as topology and access logs. If you’d like to see anything not covered here, feel free to comment on my blog or contact me via Twitter @muratkarslioglu.