Note: Updated for DB2 V8.2 (formerly known as DB2 "Stinger").
Customers choose IBM® DB2® Universal Database™ because of its incredible time to value, ability to scale and integrate across disparate environments, its robustness, and for the minimization of 'down-time' (both planned and unplanned). In this article, we focus on the high-availability aspects of DB2, not so much from a functionality point of view (of which much has been written), but from the point of view of licensing. For an excellent resource guide on the technical aspects of DB2 in a high availability environment, we suggest picking up a copy of The High Availabilty Guide for DB2, by Chris Eaton and Enzo Cialini (ISBN 0131448307). (Note: this book does not include the new high availability enhancements, like High Availability Disaster Recovery, delivered as part of DB2 V8.2 - for more information on that, visit the DB2 V8.2 Web page.)
We hear a lot of questions about licensing DB2 in a high availability (HA) environment -- configurations that are designed to address unplanned outages (and sometimes planned ones too). Usually the first level of confusion is caused by wide variations in how different vendors price their database products in high availability environments. The good news is that IBM is more lenient in its licensing terms so your organization will likely save money.
Another level of confusion centers around the terms used in discussions of high availability. For example, the term clusters. Sometimes the IT industry refers to highly available environments as clusters. We don't like using this term by itself anymore as it has become somewhat overloaded as of late in that clusters can refer to clustering for scalability (like the database partitioning feature (DPF) available with DB2 Enterprise Server Edition), or clustering for availability (for example, using Microsoft Cluster Server on a group of Windows servers). Despite not liking the term, it's used; so for this article, when referring to the term cluster, we mean clustering for high availability (unless otherwise noted). For simplicitly, we recommend you prefix the term cluster with high availability or scalability when discussing clusters with your customers, colleagues, and so on.
Another source of confusion arises from the terms used to describe the server which will act as the failover server in the event of an outage. If you've been around long enough (that doesn't mean your old, it means your a seasoned professional), you've likely run the gammit of terms desribing this one server. These terms include: idle, active, cold, warm, hot, passive, and so on.
For the most part, IBM eServer literature uses the cold, warm, and hot terms to describe standby servers. However, things in DB2-land are a little different. DB2 uses the terms idle and active for standy database servers. Consequently, DB2 has pricing and licensing terms that may not be the same as some other IBM software products. This too is often a source of a confusion for customers, so reading this article will help you sort this out and put you in-the-know.
In Figure 1, we have mapped the most common terms used to describe HA environments to the DB2 terms:
Figure 1. Mapping industry high availability terms to DB2's terms
In the previous figure we appended a general rule of thumb below each category, but after reading this article, it will all be apparent to you. As well, keep in mind that this is the general rule, you may indeed call something a hot standby when for DB2 purposes it is idle (read on).
Licensing a DB2 server in a high-availability environment depends on your answer to several key questions, including:
- What edition of a DB2 server do you have installed? Is it: DB2 Express, DB2 Workgroup Server Edition (DB2 WSE), DB2 Workgroup Server Unlimited Edition (DB2 WSUE), or DB2 Enterprise Server Edition (DB2 ESE)?
- How are you licensing your DB2 servers? Depending on the edition of DB2 you purchased, options include a concurrent user (capacity) license, a registered/named user entitlement, or a processor entitlement. (If you're looking for an overview of all the distributed DB2 servers and how to license them, read Which Distributed Edition of DB2 is Right for You by Paul Zikopoulos.)
- How is the standby machine being used when a failure has not occurred? Is it being used as a production server for DB2 transaction and query work? Is it idle and waiting for a failure to occur? Perhaps it's performing some level of work, but only to help prime a recovery in the event of a failure? Quite simply, what the standby server is doing when everything is running just fine has a lot to do with how DB2 on that server is licensed.
- Are you using the new High Availability Disaster Recovery (HADR) product that's new in DB2 V8.2?
An active standby configuration is one in which all servers have independent, operational DB2 databases that service user transactions and queries. This configuration is sometimes called an active/active configuration since all the machines in the cluster are performing some level of useful work at all times. If one of the servers in the cluster was to fail, then clustering software would transfer that failed server's workload to a surviving server in the cluster.
If a failure were to happen, the transfer of resources would effectively double the workload on the active standby server (the surviving machine) because it now has to handle its original workload plus the failed server's workload. This is something that you need to consider when setting up any highly-available active/active environment. If you are database administator (DBA) who's laying it all on the line for a tight service-level agreement (SLA), then this may or may not be the best choice (unless you size for it).
To summarize, in DB2 an active standby server is a machine that is being used to service user transactions and queries during normal operational periods; when a failure of another server in the cluster occurs, the active standby server will take on the load of the failed server machine in addition to the work that it was performing during normal operations. Because the active standby machine is still used for user transactions and query, even if no failure occurs, it must be fully licensed. For example, imagine having two databases on two separate machines, one running an ERP package and the other doing some SCM work. If the SCM database was to fail, the machine running the ERP workload would have to service all the SCM users too.
An active/active standby scenario is shown in Figure 2. In this example, there is a pair of servers that are both being used for transaction and query workloads during periods of normal operation (the solid boxes represent where the workload for each machine occurs before a failure, the cross-hatched boxes are where work would occur in the event of a failure of a respective machine). Machine 2 fails and its workload is transferred to its failover partner, machine 1. In this scenario, machine 1 is an active standby server to machine 2 (and vice-versa when you look closely at this figure - note the cross-hatched box for machine 1 on machine 2). This type of configuration is often referred to as a high-availability clustering pair and is quite common it today's IT landscape.
Both machine 1 and machine 2 were being used all along for their own transactional and query workload management, and when machine 2 failed, its DB2 workload was simply transferred to machine 1. Again, in this case, if you did not correctly size machine 1's resources for machine 2's failed workload responsbilities (and vice-versa), you could have performance issues after an outage occurs as a result of the transfer of workload.
Figure 2. Machine 1 is an active standby for machine 2. Machine 2's workload fails over to machine 1 in the event of a failure.
Licensing considerations for an active standby machine
As a general rule of thumb, an active/active configuration should be priced the same way you would price each server as if they weren't clustered for high availability together (there are some exceptions, and we'll cover them here). The following section details the licensing considerations you should be aware of depending on how your DB2 server is licensed.
Processor licensing: For any DB2 server products that are licensed by the processor licensing model (for example, DB2 Express, DB2 WSUE, and DB2 ESE), all processors on the active standby server (machine 2 in our example) must be licensed.
In the example shown in Figure 2, assuming each machine is running DB2 Express on a 2 CPU server, you must license: 2 servers x 2 processors = 4 processors.
Concurrent user: For any DB2 server product that is licensed based on the concurrent user model (at this time, DB2 WSE is the only DB2 server hat can be licensed this way), you must license the active standby server with a DB2 server license and the number of concurrent users that will be accessing the active standby server (machine 2) during periods of normal operation - in other words, before a failure occurs. (If you are using connection concentration software or a multiplexer, you must count the number of users before the are concentraed.) During a period of failure, the concurrent licenses on the failed server can be freely transferred to the active standby (machine 1) without charge. Quite simply, each server is licensed for their own respective workload environments, and when a falure occurs, the concurrent user licenses can be freely transferred to the surviving machine.
In the example shown in Figure 2, if each DB2 WSE server is licensed for 50 concurrent users, then you will need: (2 servers x 50 concurrent users) = 100 concurrent user licenses + 2 DB2 WSE server licenses (one for each server).
During a period when machine 2 is non-operational, the active standby server (in this case machine 1) is licensed for 100 concurrent users; that is, machine 1's original 50 concurrent licenses plus the additional 50 concurrent licenses from machine 2. When all operations are normal, each serve is only licensed for 50 concurrent users each.
Registered or named users: For any DB2 server product that is licensed by the named user model (for example, DB2 Express) or registered user model (for example, DB2 WSE), you must license the active standby server with a server license. (For clarification purposes, the DB2 Express named user license is the same thing as a DB2 WSE registered user license.) DB2 registered and named user licenses are entitlements for specific individuals to access any DB2 servers that are licensed for named or registered users in a company. For example, you could have a single named user access ten different DB2 database servers in your environment if those servers were licensed with the named or registered user model.
In the example shown in Figure 2, if you have 100 registered users and two DB2 WSE servers, then you will need to license: 100 registered users + 2 DB2 WSE server licenses. Remember, registered and named user licenses are for specific users only and are not dynamically transferable at connect time (like concurrent user licenses).
There are additional High Availability Disaster Recovery (HADR) licensing considerations that you must be aware of if you are using the new HADR feature for DB2 V8.2 - we'll cover them later in this article.
An idle standby configuration is one in which at least one server in the high availability cluster does not have a DB2 database that is servicing user transactions or query workloads during periods of normal operation. This server has DB2 server software installed on it and may or may not be powered on, but it is idle in that it is not performing "useful" work. Work that is classified as "not useful" (although ironically it could be the most useful work you do) includes administrative actions that assist in failover/HA scenarios such as having a database in rollforward pending state to support log shipping, making a flash copy of a DB2 database and then performing a database backup of this copy on another server, supporting transaction shipping for an HADR environment, and so on. If one of the servers in the high availability cluster fails, then the clustering software transfers the workload to the idle standby database server.
One common misconception many have about an idle standby configuration is that the idle standby machine is a waste of resource when solely dedicated to recovery operations. This is an incorrect understanding of this type of configuration. The truth is that you can leverage the idle machine for many uses (both DB2 and non-DB2 related) beyond the standby role. For example, you could create a new DB2 instance on the idle machine (depending what DB2-related work you choose to perform here, it could have licensing implications) and use it as a test machine, or perhaps offload other workloads and functions on it. In the event of a failure, you could scale back these workloads and allow the standby machine to use all of its resources to handle the load of a failed server, thereby circumventing the load considerations outlined in the active standby disucssion. For example, you may have the idle standby machine rolling forward through the DB2 logs, while at the same time, it is running test scenarios in another instance (or test scenarios for non-DB2 purposes - like application testing and so on). In the event of a failure, you simply queisce the test workload and let DB2 assume the load of the failed server without consideration for throughput reduction.
Customers take all sorts of different approaches to standby machines. We recommend that you prioritize your goals and business needs in regards to a standby machine. For example, some customers may choose to set up a log shipping environment on a standby machine. At the same time, they also want to use this same standby database for a somewhat current read-only version of the production machine - thereby spreading out cost allocations over more and more resources (accountants really like to see this). Most vendors limit this model to either/or -- meaning that while you are reading the database, you cannot roll forward through the logs to keep it current (if it isn't eithyer/or, there is a compromise with respect to how fast the rolling forward process can keep up - as in a logical standy server). Subsequently, leaving the database open for extended periods of time for read-only opeations increases the mean time to repair in the event of a failure: the very issue this configuration is designed to avoid. Our advice, if you need outstanding availability characteristics, then price and size the environment with that as the premier goal. If you can afford longer outage times, then you'll get more options with respect to the use of the standby machine.
Finally, it wouldn't be a marketing fluff-like statement to note that in many cases, licensing DB2 in an active/idle environment is cheaper (even when including the hardware) than other vendor's active/active environments. DB2 V8.2 for Linux also includes a free 2-node license of Tivoli System Automation for Linux which can provide 20 second failover scenarios with relatively little complexity (the minmization of complexity part is a big thing). In addition to this, don't forget that HA-licensing is available for all DB2 servers -- not just the Enterprise editions.
An idle standby scenario is shown in Figure 3. In this example, during periods of normal operations, machine 2 is being used for transaction and query workloads (noted as active work in the figure), while machine 1 is sitting as an idle standby for machine 2's workload, and perhaps supporting some additional functions like application development, or it could even be powered off. Machine 2 fails, and its DB2 workload is passed to its idle partner machine 1. In this scenario, it would likely be the case that if any work (of any kind) was being performed on machine 1 before the failure, it would be scaled back to handle the new workoad after the failure of machine 2 (or machine 1 was originally sized to support its workload, be it DB2 or non-DB2 work, and machine 2's workload at the same time - otherwise you'll see a performance issue).
Since during periods of normal operation only one machine is active from a DB2 perspective in Figure 3, while the other is doing something else, this configuration is often refered to an active/idle configuration. (Note that depending on the work being performed on the idle standby machine, you may need to purchase additional DB2 licenses: for example, you may choose to buy DB2 Universal Developer Edition licenses for the developers that use this box to support a DB2 application development environment on the same box that will serve as an idle standby.) The important concept to note here is that machine 1 wasn't doing and meaningful DB2 work before the outage occured.
Figure 3. Machine 2's workload is transferred to the idle standby server, machine 1.
Again, depending on your availability requirements, workload, etc., an idle standby may or may not be the right choice for your environment; however, don't forget why you have a high availability environment in the first place - to minimize the mean time to repair from an outage.
Licensing considerations for an idle standby machine
Processor licensing: For any DB2 server products that are licensed by the processor licensing model (for example, DB2 Express, DB2 WSUE, or DB2 ESE), only a single processor on the idle standby server must be licensed for high availability purposes. In the example above, assuming each machine was running DB2 WSUE on 2-way CPU servers, you would need to license: (1 active server x 2 processors) + 1 processor for the idle standby machine = 3 processors
Partitioned database: The licensing terms for idle standby machines in a partitioned database environment have been changed in DB2 Version 8.1. Idle standby machines used in conjunction with the Database Partitioning Feature (DPF), a feature delivered in DB2 Version 7 by DB2 Enterprise - Extended Edition, are licensed the same way as servers that are not partitioned. Before DB2 V8.1, you had to license all of the failover processors in a DB2 EEE environment.
For example, if you have four 8 CPU servers and install DB2 ESE on 3 of them for production and one of them as a standby server (along with the DPF feature), you would need to license: (3 active servers x 8 processors) + 1 processor for the idle standby machine = 25 processors (we're assuming in this example that you consider a processor license equal to a DB2 ESE processor license plus the additional per processor charge for the DPF feature).
Concurrent user: For any DB2 server product that is licensed by the concurrent user model (for example, DB2 WSE), you only need to license the idle standby server with a server license because during a failover, the concurrent user licenses on the failed server can be dynamically transferred to the idle standby machine.
In the example above, if you installed DB2 WSE on both machines and licensed the active server for 50 concurrent users, then you will need: 2 server licenses (one for production and one for failover) + 50 concurrent user licenses.
Remember, DB2 WSE is licensed using a per server license charge plus a user charge (concurrent or registered). After a failover, the idle standby server is licensed for 50 concurrent users, which are machine 2's original 50 concurrent licenses.
Registered or named users: For any DB2 server product that is licensed by the named user model (for example, DB2 Express) or registered user model (for example, DB2 WSE), you only need to license the idle standby server with a server license. (More accurately, although they are the same thing, DB2 Express can be licensed with a named user license and DB2 WSE can be licensed with a registered license.) DB2 registered and named user licenses are entitlements for specific individuals to access any DB2 servers that are licensed for registered users in a company.
In the example above, if you have 100 named users and a production DB2 Express server, then you will need to license: 2 DB2 Express server licenses + 100 named user licenses. Since named user licenses can access multiple servers in your environment, you don't need separate named user entitlements for each server.
Tip: In this environment, you may be able to derive further value from your registered or named user licenses by using the idle standby machine as an active standby machine since it will not affect your licensing costs (because of terms and conditions associated with named or registered users). The tradeoff would involve the load on the standby machine in the event of an outage - so you have to weigh-out the advantages and disadvatages of this approach. Quite simply, an idle standby machine licensed for registered or named users can be used as in an active/active configuration without consideration to licensing.
There are additional HADR licensing considerations that you must be aware of if you are using the new HADR feature in DB2 V8.2 - we cover them in the next section.
High availability pricing with HADR
DB2 V8.2 introduces a new availability product called the High Availability Disaster Recovery (HADR) Option. The HADR product enables DB2 to ship transactions from the log buffers, as opposed to log file shipping which DB2 has done for quite some time. This enhancement enables a richer, more granularized, and comprehensive turnkey data loss prevention environment with extended options like being able to upgrade your operating system without taking an outage. HADR has three data loss prevention levels, one of which guarantees a zero loss transaction environment. Wrapping all this up is a full-featured GUI that makes setting up an HADR environment a snap. An example of HADR is shown in Figure 4. below:
Figure 4. DB2 in an HADR environment.
It's out of the scope of this article to discuss the technical details of HADR; visit the DB2 V8.2 Web page for more information.
The HADR option is included at no extra charge with DB2 ESE and is also available as an add-on product for DB2 Express, DB2 WSE, and DB2 WSUE servers -- if you're planning on using HADR with your DB2 ESE server, simply follow the guidelines outlined in this article and skip this section.
The only way you can purchase the DB2 High Availability Disaster Recovery Option for DB2 Express, DB2 WSE, and WSUE is via a processor license. Each active processor on the DB2 server has to be licensed for HADR, and the standby machines need to be licensed for HADR in the same manner in which you would license them for your DB2 server with a processor license (depending on the standby machine's active or idle status).
If your DB2 server is licensed with the conccurent, named user, or registered user model, you still must license the HADR Option via the number of processors on your server. In other words, licensing for the DB2 HADR Option is always based on the number of processors regardless of how the DB2 server itself was licensed. For example, if you had a DB2 WSE server that was licensed with 10 concurrent users and used in an active/idle standby cluster with the DB2 HADR Option product on a 2 CPU server, you would need to license: 2 DB2 WSE server licenses + 10 concurrent user licenses + ((2 DB2 HADR Option processor licenses for the active machine) + 1 DB2 HADR Option processor license for the idle machine = 3 HADR processor licenses).
Did that last example catch you off guard? It can get tricky. We'll simplify it for you. In this example, you have 2 servers each with 2 processors (there are a total of 4 processors in the cluster). One machine is active and doing some meaningful work. The other machine is idle, it's likely doing some other work, but from a DB2 perspective, it's only doing some work to aid in recovery etc. Since we have two servers, and we chose to license DB2 WSE using the concurrent user model, we need 2 DB2 WSE server licenses. In addition, since the active machine will have no more than 10 concurrent users at any one time, you will need 10 concurrent user licenses (you don't need them for the idle machine since concurrent user licenses can be dynamically transferred in the event of an outage). Finally, since you are using HADR you need 2 HADR processor licenses for the active server, and one HADR processor license for the standby server.
- developerWorks DB2 zone: Learn more about DB2. You'll find technical documentation, how-to articles, education, downloads, product information, and more.
- developerWorks blogs: Get involved in the developerWorks community.
Dig deeper into Information management on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.