1.2 Preview: Automation
You probably saw Paul’s post this week announcing our 1.2 release. It’s full of “previews.” Why? ‘Cause there are a bunch of things we’ve been working on quietly that are finally making it into the product. Needless to say, we’re psyched about this stuff. The one preview feature that didn’t make it onto Paul’s list is that with 1.2 we’re pulling back the curtain on our automation work.
I’ve talked a lot on this blog about how easy it is to automate monitoring and management in NuoDB. I’ve also said that we’re building on that to make the product much easier to work with out of the box. What we’re showing off in our latest release is how we’re approaching it. This preview isn’t intended to be production-ready, but it is ready for you try using and we really want feedback!
In this preview release automation consists of three layers: a core ability to describe the requirements for a database, a new REST interface for managing a Domain and a proof-of-concept UI for setting up NuoDB like a Database as a Service. In this post I’m going to explain how to get it all running, what you can do with these layers today and how this is changing between now and our next release this fall.
What does automation mean?
Before I get into the details, let’s talk about what automation means in this context, and how it helps you. NuoDB is a distributed systems that addresses a lot of problems like on-demand scale, geo-distribution and high-availability. To solve these problems, you need to have the software on multiple systems and then you need to run a combination of Transaction Engines and Storage Managers with the right settings that optimize for the problem you’re facing.
For instance, the minimal ACID deployment for NuoDB is a single host running a Broker, a TE and an SM. You get a full database that’s useful for testing and simple production cases but that gives you no redundancy. If you start a second host and run a TE and an SM on that host now you’ve got independent copies of your data, and if either host fails your database is still available. To get even better availability, you might move the TEs onto their own hosts, so you have a 4-host deployment that is fully redundant. You can script this kind of behavior in the system today but you’d need to think first about the problem you’re trying to solve and the deployment that requires.
Our automation work is all about simplifying this. Rather than explicitly starting processes you should be able to say “here’s the problem I’m trying to solve” and we’ll take care of the configuration. Some examples are “run a local database”, “run a fully redundant database”, “run a database that will scale on-demand up to a certain size” or “run a database that is always available in at least two regions.” At the core of our automation work is a way to capture these requirements into what we call Templates. A Template is basically a way to map these Service Level Agreements into deployment strategies.
Now, rather than starting a bunch of processes one-by-one you can tell NuoDB to start a database based on some Template. We’ve automated the process of deploying the software to solve some specific problem. We’ve also simplified monitoring because there are clear SLAs that a database needs to meet, so NuoDB can let you know if a database is running at expected levels.
Because NuoDB knows what is required of database, you can let it automate enforcement of those requirements. For instance, let’s say you start a database on a single host with the requirement that TEs should run on up to five hosts. When you provision a second host for use, NuoDB will automatically start a second TE there. Or, if your requirement is that there should always be exactly two TEs and one of the hosts with a TE fails, NuoDB will start a new TE if there’s some available host to pickup the load. In this way, we’ll take care of meeting your requirements, and reporting back to you when any database requirements can’t be met.
The requirements for a given database may change over time, so you can always re-assign Templates. For instance, suppose you start a database for development purposes using a single-host Template. Time passes, and now you want to test scale-out. By simply re-assigning the database to a multi-TE Template NuoDB will start taking advantage of any hosts that aren’t already supporting this database with no additional work on your part.
The preview release that’s available today comes with three built-in Templates: run on a single host, run on exactly two hosts and scale out TEs on as many hosts as there are available. This doesn’t cover all the use-cases that we’ll eventually support, but it highlights the basic capabilities that we’ll support. By the time our next major release is available you’ll be able to write your own Templates. In the meantime, read on to learn how you can get started with this feature today.
Describe your databases
For this first, preview release the moving pieces to support automation are being shipped separately from the core 1.2 release. In our next release it will all be bundled together. You can read more about the specifics of how to configure the pieces in our product documentation, but here are the highlights.
To add support for the Templates described above you need to include a service into your agents. Actually, in addition to supporting Templates this service also supports what we call Database Descriptions, which is how we map a given database to its Template and flesh out specific values like archive directories. These Descriptions are durable, so if you shut down your Domain and then re-start everything all of your databases will come back online too.
To get this core facility running you need to
- Download the description service.
- Create the agent plugin directory and copy the jar file with the right permissions. For instance, on Linux or Mac you would do this:
sudo mkdir -p /opt/nuodb/plugin/agent
sudo cp description-plugin.jar /opt/nuodb/plugin/agent
sudo chown -R nuodb:nuodb /opt/nuodb/plugin
- Edit the default.properties file to use the service. Anywhere in the file, add the following:
# Include the description service to support database automation
customServices = DescriptionService
- Restart the local agent.
You’ve now got a Broker with a core set of Templates and the ability to automate databases. This service also introduces another feature called Tags. Each host may be tagged with any number of values, and then Templates can use these in the context of a database. For instance, each host has an archive_base tag that points to the default location where archives should be kept on that host. This ensures that when you’re getting started NuoDB will default your archive to a known, existing location with the permissions set correctly to get up and running.
Enable the REST layer
With the description service loaded you need something that can address this functionality. You could go grab our python management modules if you wanted to go that route, and in our next release you’ll be able to use the command-line nuodbmanager, but part of this preview is a new REST module so let’s use that instead. The REST API we’re introducing is actually a complete management interface for doing the kinds of things you can do from the command-line or web console today. It isn’t fully fleshed out, but that’s kind of the point. We’re releasing it in a very early state so we can get feedback about where to take it.
java -jar -jar nuodb-rest-api.jar server configuration.yml
By default, you’ve now got a web server running on port 8888 that will respond to management queries. There’s no authentication in this first version (yes, we know, we’re going to lock it down before this is part of the product) so you can get up and running right away. For instance, to verify that you started the broker service correctly you can ask to see the available Templates like this:
curl -i -H "Accept: application/json" -X GET "http://localhost:8888/api/1/templates"
If you don’t have curl installed you could just put the URL into your browser, or use your HTTP tool of choice. In any case, if what you see come back is a bunch of JSON with summaries of different Templates then you’re all set. We’ll be publishing the full API as soon as we can get the doc wrapped up, but in the meantime we’ve given you a simple way to start working with this feature.
Deploy your own DBaaS
One obvious advantage to all this automation work is that it lets you use NuoDB like any other service. To really let you see this in action, we’ve included a light-weight but fully-functional UI. It’s part of the same web server you started already, but the UI element is disabled by default. So, stop the web server (if you still have it running) and re-start it with a new property:
java -Dui=true -jar nuodb-rest-api.jar server configuration.yml
Now, point your browser at localhost:8888 and you’ll see our demo service interface. Go ahead, click on the “launch an instance” button. You’ll get something that asks you for the name of your database, your initial DBA credentials and what Template you want to follow. Here’s what it looks like if you’re trying to run on a single host:
Click on “submit” and the database is started for you with no more interaction. Better still, we’ll make sure that database keeps running. For instance if you just started a database on your local host and you re-start your machine, when the broker comes back up so too will your database.
Since NuoDB is a multi-tenant product, you can use this new DBaaS interface to start as many different databases as you like. You can use this interface to quiesce, stop, re-start or remove any of your automated databases. If you’re only running on a single host, and you try to start a database with the Template that requires two hosts you’ll see an error reporting that the requirements can’t be met.
Recall I said above that you can re-assign a database’s Template. If you just started a database using the “Single Host” Template then try clicking on the “Edit” button. This will give you the option to change the Template. For instance, you could now change to the “Multi Host” Template to take advantage of new hosts as they come online:
What’s next for NuoDB and automation?
Over the next two months we’ll be hard at work expanding on this preview release. The UI and REST interfaces are getting fleshed out so they can support a wider set of use-cases and a strong security model. The Template mechanism is getting enhanced to be more expressive and to support richer customization. The way that NuoDB enforces database requirements is also evolving into a more powerful statistics and event-based model.
Between now and our next release we’ll also be providing more concrete examples of how to work with this new set of features. Expect the REST API soon, and some examples of how to pair this work with Cloud Formation on Amazon to automate scale-out on-demand. We’ve got a couple of other fun surprises lining up too.
In the meantime, I hope you like the direction we’re taking, and I hope you’ll take the release for a spin and give us feeback!