Database appliances seem to be coming back into the forefront. There are several reasons for this, and the resurgence of interest in database appliances has some interesting implications for IT teams.
A database appliance is a server preconfigured with a specific database rated to handle a fixed number of transactions per second. The key advantages include being sold as a single SKU—so customers don’t have to worry about database licensing concerns on top of the hardware outlay—and they’re effectively plug-and-play. Minimal configuration is required after power-on for a database appliance to be ready to serve workloads, and no customization is required to ensure the database is performing at optimal efficiency for the hardware in question.
To a certain extent, cloud computing is to blame for the renewed interest in database appliances. In a cloud environment, instantiating a database instance (or using one of the vendor-provided shared instances) takes seconds. Developers and operations teams are increasingly used to being able to provision resources on an as-needed basis, and vendors selling into on-premises data centers are increasingly focusing on ease of use to compete.
Why Database Appliances?
Database appliances are typically used for large or high-transaction-volume databases. A database in a virtual machine (VM) works; however, it does impose some overhead. This overhead, combined with some byzantine licensing restrictions for virtualized instances, make running a database on bare metal an attractive option for many.
Unfortunately, deploying to—and managing—bare metal servers isn’t as simple as wrangling VMs. Among other considerations, database administrators using bare metal servers are more exposed to hardware considerations (such as drivers) than when using virtualized instances.
In a virtual environment, there’s a much clearer separation between the administrators who deal with checking hardware health and those who herd databases. Virtualization administrators are responsible for making sure the hypervisors work with the hardware upon which they’re installed, while database administrators operate their databases inside the standardized (and thus largely predictable) environment of the VM. In other words, virtualization abstracts some complexity away from the database administrators.
A bare metal server, however, doesn’t have the abstraction layer of the hypervisor. If an update causes a driver to break, it can quickly spiral into becoming the database administrator’s problem.
Here, the value of the appliance model becomes clear: by shipping the appliance as a combined hardware and software solution, a single vendor shoulders the support burden for the appliance. More colloquially, database appliances give database administrators every erg of power the hardware can muster, while providing them a single throat to choke when things go wrong.
Practical Considerations
Database appliances, like any other workloads, have maintenance requirements. Backups and disaster recovery (DR) are real-world concerns, as is high availability (HA). In today’s highly virtualized and cloud-enabled world, it’s almost inconceivable for anyone to go to the trouble and expense of buying a bare metal database appliance to support non-critical workloads, so backups, DR, and HA most likely have demanding requirements.
Here, cobbling together stacks of solutions from multiple vendors to save a few dollars is probably the wrong approach. Yes, getting everything supplied by a single vendor is going to be expensive—mostly likely more expensive than a stack of products from different vendors—but it will also stand the best chance of working when it needs to.
Context is key. Not only are database appliances themselves a significant expense worth properly protecting (and bear in mind, multiple appliances are usually purchased to achieve HA), but the workloads they support are almost always the sort of workloads where even a few seconds of downtime can be disastrous.
Organizations deploying database appliances frequently make the mistake of not adequately sizing their WAN connectivity for the needs of the database. Backups, DR, and HA can all place significant load on WAN links, especially when transaction loads are at their peak. Inadequate WAN capacity can result in degraded performance, inadequate protection, or both. This effectively negates the primary benefit of using an appliance versus a VM in the first place: those last few percentage points of performance.
Scaling is often the fly in the ointment for database appliances. Because a database appliance is a cluster of physical servers, scaling requires adding nodes to the cluster. Each node is a capital expense, and often a significant one. As the cluster performance and capacity scales, backup, DR, and HA considerations all must be reassessed to ensure they can keep up.
Another regularly occurring problem with database appliances is the need to scale going unnoticed until lack of resources starts affecting workloads. In a virtualized environment, there are often two separate teams looking at things: virtualization administrators keeping an eye on the virtualization infrastructure, and database administrators.
It’s not uncommon for database administrators to get busy with a project and not notice a database is approaching performance limits until informed by the virtualization team. Unless the operations team has implemented database performance monitoring software, the impending performance problems of database appliances can easily go unnoticed.
This is especially true if the performance problems in question aren’t with the local appliance, but with some aspect of the backups, DR, or off-site HA. The local appliance cluster may be performing brilliantly while still approaching the limits of the cluster’s hardware capabilities, or those of the WAN links upon which the protective services rely.
In all, database appliances aren’t a bad option. They offer ease of use, consolidated support, and those last few percentage points of performance when compared to their virtualized brethren. But additional operational elements of adopting physical appliances may not be on database administrators’ minds if they’re used to the virtualized or cloud-based delivery models.
Leave a Reply