Follow along as we demonstrate how easy it is to deploy the NuoDB cloud-native SQL database in Red Hat OpenShift using the NuoDB Operator. During the demo we will show:
- How NuoDB can easily scale out to meet application transactional throughput requirements
- How to configure NuoDB to be continuously available
Hello, welcome to the NuoDB Operator demo. Today, I would like to demonstrate for you how easy it is to deploy the NuoDB cloud-native, SQL database and OpenShift using the latest NuoDB Operator written in Golang.
During the demonstration, I will also show how NuoDB can easily scale out to meet application transactional throughput requirements, as well as how to configure NuoDB to be continuously available, even in the event of common hardware, software and network failure events. The operator can easily be installed from the OpenShift OperatorHub Marketplace, a service catalog which is seamlessly integrated into the OpenShift 4 web UI, which creates a single click experience that deploys the NuoDB operator from catalog to cluster in less than a minute. The NuoDB Operator install instructions are available from our NuoDB Operator GitHub repo for you to give NuoDB a try for yourself.
The panel on the left is the OpenShift web UI. I have created a new project named NuoDB and it's currently empty. On the right is a Linux command window, where we can issue commands to control the operator. For example, instruct the operator to start a NuoDB database. First, we'll deploy the operator into our OpenShift cluster, using the OpenShift Operator Hub.
The operator starts up right away. The automated deployment process creates several Kubernetes CRDs, custom resource definitions, that define the operators functions. Finally, it's set some roles and permissions and then starts the operator. All of which happens in under a minute.
The next step is to simply ask the operator to start a NuoDB SQL database, but before we do that, let's just cover a few benefits operators offer and why they are so useful when managing a Kubernetes environment. Operators are a Kubernetes feature, which provides a method to package, deploy, auto scale and manage Kubernetes applications. Operators are controlled by Kubernetes tooling. That is Kubernetes API or kubectl command. Operators offer many benefits over a manual deployment using YAML manifest files.
- First, they are highly accessible to operator marketplaces and service catalogs like the OpenShift Operator Hub.
- Two, they are much less error prone than running YAML manifest files, as the operator completely automates provisioning and day to day operational tasks like rolling upgrade or backup and recovery and so much more.
- Three, they're also tested, marketplace certified, and ready for your use.
- Four, they are portable across Kubernetes distributions.
- Five, they also provide useful information about the Kubernetes applications that can help vendors better support your use of them.
Now that we can appreciate what operators can do for us, let's use the NuoDB operator to start a high performance NuoDB cloud-native transactional SQL database that is both ANSI SQL and ACID transactional compliant. Inside the NuoDB operator are all the smarts needed to start a user configurable NuoDB database. We just need to ask for it.
Here we have a file called
nuodb-cr-aws.yaml and in this file defines a custom values that allow users to edit and start a NuoDB database tailored exactly to their needs and configuration. We see that there are parameters that control the number of admin pods, a storage manager and TE pods, as well as the memory CPU, and disc requirements that users may want to alter and configure prior to starting their NuoDB database. I've created this command to ask the operator to give me a NuoDB SQL database. As you can see, as soon as I ran the command, which runs the appropriate CR YAML, NuoDB database provisioning command, it has signaled to the operator to give me a NuoDB database and the database seems to jump right out of the operator. The operator is now busy taking all of the necessary steps to properly provision a NuoDB SQL database.
A NuoDB database is a collection of three different process types.
- An admin, responsible for creating a management domain across physical hosts that can support several logical databases.
- A storage manager, which we call an SM, which is responsible for persisting database changes to the database on disc.
- And a transaction engine, which we call a TE, which is an in memory database component responsible for processing SQL transactions on behalf of the client application.
The database will be active and available as soon as there is one of each process type running. NuoDB also allows you to create a highly scalable and fault-tolerant system, simply by configuring multiple containers of each process type. If any process should fail for any reason, it's okay. There are others of the same type to pick up the load. The result? Your applications are continuously available, while the operator completes the task of starting the NuoDB database along with NuoDB Insights, the NuoDB visual monitoring tool and a sample SQL application.
Let's discuss the options available when deploying NuoDB insights. NuoDB Insights supports two modes of deployment: on-cluster and as-a-service.
That is, users can choose to store their performance data privately and locally within their Kubernetes cluster, or they can send their performance data to NuoDB's hosted Insights portal in the AWS public cloud, where it is stored securely and only accessible via a private subscriber ID.
Let's demonstrate NuoDB's benefits starting with ease of scalability. As your applications require more or less SQL transactional throughput, NuoDB can be dynamically adjusted to meet those requirements at runtime. Unlike other databases, NuoDB transactional and storage tiers scale independently of each other, a core tenant to NuoDBs cloud-native properties. Now that our NuoDB database and NuoDB Insights visual monitor are both up and running and SQL workload is being processed, we can demonstrate adding more application pods, which generates an increased application workload and then respond by scaling out the NuoDB transaction layer to meet the additional application demand.
Additionally, we can show NuoDB resilience and fault tolerance in the event of common hardware, software, and network failure events. NuoDB is built to run in environments where failures can and will occur. NuoDB will keep running and keep servicing SQL transactions as long as redundancy has been built into the database deployment. I'm running the NuoDB Community Edition (CE) in this demonstration, a free community version, which allows you to create multiple admin and transaction engines to demonstrate this database resiliency feature.
Please note: creating a redundant storage manager tier is an enterprise edition feature that you can try for yourself in a trial or PoC by contacting your NuoDB sales representative.
Let's start by introducing a failure event into the system by deleting a TE process. You will notice in NuoDB Insights a deterministic percentage of transactional throughput will decrease for a short period while the database recovers by replacing the failed TE process with a new TE process. But, the database doesn't go down. The applications continue to run with very little impact to overall transactional throughput.
Likewise, the same can be done at the admin tier. To demonstrate, you can follow a similar process to a failure event into the admin tier. Yet, NuoDB will continue to process SQL, while the database recovers the admin process in less than a minute. This portion of the demo is left as an exercise to try for yourself. Notice when we view the running database system in NuoDB Insights, over the period of time where the TE failure events were injected, the database fully recovers often in just several seconds and always continues to process SQL during the recovery period. Most importantly, the applications never experience downtime.
Thank you for attending this demonstration.