Licensing distributed DB2 10.1 servers in a high availability (HA) environment
The licensing and packaging information provided in this article is for marketing and reference purposes only. For full details on DB2 packaging and DB2 license rights and obligations, please consult the DB2 license agreements.
Customers choose DB2 as their database of choice because of its incredible time to value, its 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 (HA) 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.
We receive a lot of questions about licensing DB2 in an 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 HA environments.
Another source of confusion stems from the terms used in discussions that relate to HA. For example, the term clusters. Sometimes the IT industry refers to HA environments as clusters. We don't like using this term by itself anymore, as it has become somewhat overloaded in that clusters can refer to clustering for scalability (like the InfoSphere Warehouse database partitioning feature - DPF - which is based on DB2) or clustering for availability (for example, using the Tivoli System Automation for Multi-platforms (SA-MP) clustering software that comes deeply integrated with DB2, or both (as is the case with a DB2 pureScale cluster, or the IBM Smart Analytics System). For this article, when referring to the term cluster, we mean clustering for HA (unless otherwise noted). For simplicity, you should prefix the term cluster with high availability or scalability when discussing clusters with your clients or colleagues. Of course, some solutions address both scalability and high availability solutions with a cluster - so ensure you're always communicating what you're trying to do.
Still another source of confusion arises from the terms used to describe the server that acts as the failover server in the event of an outage. For example, this server may be referred to as a standby or secondary server. If you've been around long enough, you've likely encountered various terms describing the function a standby server performs. Terms such as idle, active, cold, warm, hot, and passive have all been used in availability discussions.
For the most part, IBM Software Group (IBM SWG) literature uses the cold, warm, and hot taxonomy to describe standby servers, and DB2 has conformed to the IBM SWG taxonomy since DB2 9.5. We've updated this article for the DB2 10.1 release to help you sort out DB2 high availability licensing rules and put you in-the-know.
This article also covers the DB2 pureScale technology that was initially announced in October 2009 and has been greatly enhanced for the DB2 10.1 release which became generally available on April 30, 2012. In DB2 10.1, pureScale is included with DB2 Workgroup Edition and is an add-on feature option for both DB2 Enterprise Edition and DB2 Advanced Enterprise Edition.
Figure 1 gives a good description of the DB2 10.1 high availability (HA) taxonomy and some examples of the types of configurations that fall into each category.
Figure 1. Some helpful hints when it comes to the DB2 10.1 hot, warm, and cold HA taxonomy
Table 1 shows the most common terms used to describe HA environments mapped to the DB2 taxonomy and licensing terms.
Table 1. Mapping industry high availability terms to the DB2 licensing terms
|Database software is installed on another server intended for failover purposes.||Database software is installed on another server intended for failover purposes.||Database software is installed on another server intended for failover purposes.|
|The database instance is not started during normal operations, and it will be started only when a failover occurs. The database can also be started briefly for maintenance operations (such as applying a fix pack or performing a backup) following which it must be stopped.||The database instance is started, and it might be receiving updates from the primary database for high availability purposes only, such as applying logs or doing recovery work. There is no end-user access to this standby database.||At the same time that this server is maintaining its partner high availability scenario, it is servicing other applications as a primary data server. There is end-user access to this standby database even when no failure has occurred.|
|Typically used in clustering scenarios where DB2 pureScale, High Availability Disaster Recovery (HADR), or log shipping is not deployed and the database manager isn't started, such as for a PowerHA for AIX cluster (formerly known as HACMP).||Typically used in a "vanilla" (no Read on Standby) HADR, Q-Replication, or log shipping scenario.||Typically used in twin-failover HADR (more on that in a bit), HADR with Read on Standby, DB2 pureScale, or replication scenarios.|
Table 1 appended a general rule of thumb below each HA category; however, after reading this article, the details hopefully will be clear. How you license a DB2 server in an HA environment depends on your answers to these key questions:
- What DB2 edition do you have installed?
- Is it: DB2 Express-C (Note that we consider DB2 Express-C to be a package as opposed to an edition), DB2 Express, DB2 Workgroup, DB2 Enterprise, or DB2 Advanced Enterprise? If it's the free DB2 Express-C, you should be aware that you are not licensed to use DB2 Express-C in any kind of HA configuration. If you need HA, you minimally need DB2 Express. All editions of DB2 10.1 include full support for hot, warm, or cold standby server configurations (more on that in a bit). Note this is especially good news for DB2 Express customers using HADR who had to separately license the DB2 High Availability Feature for Express Edition with DB2 9.7 if they licensed DB2 Express under either the PVU or AU pricing metrics, to set the HADR failover.
- How is the standby machine being used when a failure has not occurred?
- For example, is it being used as a production server for DB2 transaction and query work? Is the DB2 instance on this server started? Perhaps the instance is performing some form of work, but only to help prime a recovery database in the event of a failure; for example, in an HADR scenario. Are you managing a DB2 pureScale cluster? What the standby server is doing when everything is running just fine has pretty much everything to do with how your DB2 server needs to be licensed.
- How did you license your primary DB2 server that you want to ensure is highly available?
- The DB2 edition and license metric chosen for the standby server must match the primary server. For example, if you licensed a DB2 Express server using the SERVER (or FTL) license options, you'd have to buy an additional SERVER (or FTL) license for the standby server whether it's hot or warm. Only if the standby was cold is an additional SERVER (or FTL) license not required. If you licensed your DB2 Express server using the Authorized User Single Install (AUSI) model, you'd license the standby server in a warm state for 5 AUSIs and wouldn't need any licenses for a cold standby machine. If your DB2 Express server was licensed using the Processor Value Unit (PVU) model, you'd license a warm standby server for 100 PVUs (no matter what processor architecture the server is using) and wouldn't even need a license for a cold standby machine either.
If you're looking for an overview of all the distributed DB2 10.1 servers and how to license them, refer to "Which distributed edition of DB2 10.1 is right for you?". For comparisons of the features, functions, and benefits between the different DB2 10.1 server editions, read "Compare the distributed DB2 10.1 data servers".
Since the DB2 8.2 release, there have been a number of licensing enhancements that have significantly lowered the cost of HA associated with your DB2 servers. For example, in DB2 8.2, if you wanted to license DB2 Workgroup with HADR you had to purchase the High Availability Feature option, and license this feature on both servers. In DB2 9, this changed: you no longer had to license this feature on the standby server. In DB2 9.5, IBM made the High Availability Feature option free for DB2 Workgroup servers. As previously noted, DB2 10.1 goes a step further by making the High Availability Feature option free for DB2 Express servers. Quite simply, release after release, IBM has lowered the cost of your DB2-based availability environments because of the following changes.
- When a single physical server is acting as a warm standby for multiple production servers and the standby servers are running the same edition of DB2 licensed under the same charge metric, you only have to license the warm standby server once (as of DB2 8.2). This rule applies regardless of whether the warm standbys are running in separate partitions or the same partition on the physical server. For example, if you licensed a hot DB2 server for an unlimited number of users, the warm standby server would require 100 PVUs. If five different 400 PVU-rated servers were running DB2 Workgroup, and each server was configured in an HADR cluster to fail over to the same standby server, you would only have to license 2100 PVUs (5 servers x 400 PVUs + 100 PVUs for the standby server) as opposed to 2500 PVUs [(5 servers x 400 PVUs) + (5 servers x 100 PVUs)].
- You no longer have to license DB2 feature options on a server that is acting as a warm or cold standby server (as of DB2 9). For example, if you licensed the Storage Optimization Feature option (which provides compression for XML data, tables, indexes, temporary tables, and more) for your DB2 Enterprise server and configured the database to participate in an HADR cluster, you would need to purchase only 100 PVUs of DB2 Enterprise on the standby server. No extra licensing would be incurred for using the Storage Optimization Feature option.
- You no longer have to license select tools on a DB2 server that is
acting as a warm or cold standby server (as of DB2 10.1). This applies
to the following tools:
- DB2 Recovery Expert for Linux, UNIX, and Windows
- DB2 Merge Backup for Linux, UNIX, and Windows
- InfoSphere Optim High Performance Unload for Linux, UNIX, and Windows
- InfoSphere Optim Performance Manager Extended Insight for Linux, UNIX, and Windows
- InfoSphere Optim Performance Manager Extended Edition for Linux, UNIX, and Windows
- InfoSphere Optim Performance Manager Enterprise Edition for Linux, UNIX, and Windows
- InfoSphere Optim Performance Manager Workgroup Edition for Linux, UNIX, and Windows
- InfoSphere Optim Performance Manager Content Manager Edition for Linux, UNIX, and Windows
- InfoSphere Optim Configuration Manager for Linux, UNIX, and Windows
- InfoSphere Optim Query Workload Tuner for Linux, UNIX, and Windows
- HADR is included in DB2 Workgroup at no extra charge as of DB2 9. Now DB2 Express also includes HADR at no charge (as of DB2 10.1). If you look around the competitive landscape there is no other vendor that offers the same kind of functionality (there are no restrictions for the HADR technology on DB2 Workgroup or DB2 Express) for any SMB-targeted server.
- You get free clustering and management software with all DB2 editions - Tivoli System Automation for Multi-platforms (Tivoli SA-MP) - to create an HA cluster for your DB2 servers (as of DB2 9).
- You no longer have to license a cold standby machine as of DB2 9.5. In fact, some vendors claim some sort of advantage by offering 10 days of failover use for an HA solution; however, with DB2, it's really unlimited for the same kind of clusters. You also get the clustering software for free! In fact, the Tivoli SA-MP clustering software is deeply integrated into DB2 as of DB2 9.5 and includes rich management interfaces that reduce the TCO of an HA cluster.
- HADR includes support for up to three standby servers as of DB2 10.1, which means you can replicate data to multiple sites. As a result, you can now implement redundant high availability and disaster recovery strategies all using the same easy to use and reliable technology that comes included with your edition of DB2.
In this article we refer to licensing a server; however, all DB2 editions support sub-capacity licensing where you solely license the capacity that the DB2 server is using. If we use a phrase such as license the PVU rating of the server, you can take that to mean the PVU rating of a VMWare session or an LPAR if you're using these virtualization technologies. There are some prerequisites and special rules for both PVU and non-PVU-based sub-capacity licensing so ensure you know all the details before deploying DB2 in this kind of environment.
There have been a lot of changes to flatten the total cost of ownership (TCO) associated with DB2 HA clusters both from a licensing and administrative perspective; that's pretty refreshing considering the kind of economy we are in. The best place to start a discussion of the effects of HA clusters on DB2 10.1 licensing is with examples that correlate to the DB2 HA taxonomy. As previously mentioned, DB2 10.1 defines three types of standby servers: hot, warm, and cold.
A hot standby configuration is one in which all physical or virtual servers have operational DB2 databases that service user transactions and queries. This configuration is called a hot/hot cluster (though it's sometimes called an active/active configuration since all the servers in the cluster are performing some level of business production work at all times). If one of the servers in the HA cluster were to fail, then clustering software would redistribute the failed server's workload to one or more surviving servers in the HA cluster. This environment could be characterized by a single application or one where each server backs the other up, but also has its own service level agreement (SLA) it has to adhere to.
If a failure were to happen on one of the servers, the transfer of resources could effectively double (in a 2-node cluster) the workload on the hot standby server (for example, the lone surviving machine in a two-member pureScale cluster) because it now has to handle its original workload plus the failed server's workload. This situation is something that you need to consider when setting up any HA environment. If you are a database administrator (DBA) who's laying it all on the line for a tight SLA, you need to ensure you properly vet your HA topology and the choice of the HA solution you are using.
To summarize, a hot standby server is any machine or virtual server being used to service user transactions and queries during normal operational periods. At the same time, the server acts as a standby for another server that is also used to service user transactions during normal operational periods. When a failure of the server in the cluster occurs, the hot standby server takes on the load of the failed server. However, whether the standby server continues to execute the work that it was performing during normal execution (as would be the case with DB2 pureScale) or not (as would be the case with the HADR Read on Standby feature which abandons the standby read workload when taking over the work from the primary) is immaterial. The fact that the standby server was being used to service user transactions or user queries during normal operations means that it must be fully licensed. A scenario illustrating a two-node hot standby HA cluster is shown in Figure 2, where Machine 1 is a hot standby for Machine 2, and Machine 2 is a hot standby for Machine 1. Machine 2's workload fails over to Machine 1 in the event of a failure and vice versa.
Figure 2. Two-node hot standby HA cluster scenario
In this example, Machine 1 and Machine 2 are a pair of unpartitioned servers that are both being used for transaction and query workloads during periods of normal operation. The solid boxes represent the database on each machine where the workload is executing where before a failure, the cross-hatched boxes are the standby databases where the work will occur in the event of a failure of a respective machine. In this sample scenario, Machine 2 fails, and its workload is transferred to its failover partner, Machine 1. Machine 1 is a hot 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, twin failover pair, hot/hot pair, or active/active pair and is common in today's IT landscape. There are many ways in which to implement a hot/hot high availability cluster in DB2, and depending on what you need from the solution, you can use PowerHA for AIX, HADR in conjunction with a database on each server failing over to the other, HADR (with Read on Standby activated), Q-Replication, using a hot standby for reporting via snapshot technology or disk image copies, or the pinnacle of scalability and availability combined: leverage the DB2 pureScale technology.
Again, both Machine 1 and Machine 2 shown in Figure 2 were being used all along for DB2 production workloads during normal operations; when Machine 2 failed, its DB2 workload was simply transferred to Machine 1.
An HADR cluster can function as a hot/hot cluster in multiple ways. Consider the environment shown in Figure 3.
Figure 3. An HADR hot/hot cluster due to mutual HADR failover clusters
Figure 3 shows that an unpartitioned Server A hosts a production database called Database A as well as a standby database in an HADR cluster called Database B1. At the same time, unpartitioned Server B hosts a production database called Database B as well as a standby database in the same HADR cluster called Database A1. In this case, when there is no failure, both Server A and Server B are busy servicing production work on Database A and Database B respectively and therefore this is considered a hot/hot configuration and both servers must be fully licensed.
Note that Figure 3 describes a scenario where you would need to fully license both servers even if there were no standby databases in the environment. This example highlights an important point: If a physical or virtual server running an edition of DB2 is already fully licensed, no additional licenses are required to run a standby database of the same edition in that physical or virtual server. This rule applies regardless of charge metric and whether the standby database is warm or hot. For example, if all databases, (as shown in Figure 3), were DB2 Express licensed under the SERVER metric, you would only need two SERVER licenses in total. However, if you were running the primary and standby databases in separate LPARs, you would need four SERVER licenses.
Figure 4 shows an example of an HADR environment that is using the Read on Standby capability that's part of DB2 9.7 Fix Pack 1 and later.
Figure 4. An HADR hot/hot cluster due to Read on Standby
Figure 4 shows that clients can read and write to the Primary server (making it hot); but, since clients are also reading on the Secondary server during normal operations, it is also hot and therefore both servers must be fully licensed. If you read data from a server for business purposes, then it's a hot server. Period.
Figure 5 shows a three-member DB2 pureScale HA and scaling cluster.
Figure 5. A DB2 pureScale cluster
In Figure 5, you only license DB2 and the DB2 pureScale Feature Pack on the Members (the machines processing transactions). The Cluster Caching Facility (CF) servers, which as shown are typically fully duplexed, do not require any licenses whatsoever. In this example, since transactions are being seamlessly load balanced across all three Members, they are all hot and therefore must all be fully licensed.
Licensing considerations for a hot standby
As a general rule of thumb, a hot/hot configuration should be licensed in the same way you would license each server as if they weren't clustered for HA at all.
As of DB2 10.1, there are five different licensing methods (some are only available with specific DB2 editions): SERVER, Fixed Term License (FTL), SOCKET, Authorized User Single Install (AUSI), and Processor Value Unit (PVU). The following information details the HA-licensing considerations that you should be aware for each respective license in a hot/hot HA cluster.
- SERVER license
- The SERVER license was introduced in DB2 9.7 and is only available for DB2 Express servers. When licensing a DB2 Express server using a SERVER license, you simply buy a license for each physical or virtual server in the cluster that is hot or warm. Aside from cold which requires no license, there's no need to identify the activity level of a DB2 Express server licensed using a SERVER license when it comes to HA licensing. There are no user minimums, and you don't have to figure out the PVU rating of the underlying server or anything else: simple! While in a hot/hot configuration this rule has no effect on licensing (since both machines are hot); you will see in a warm standby configuration, the SERVER (and FTL) licensing requirements are different compared to other DB2 licenses.
- Fixed Term License (FTL) license
- A DB2 Express FTL license gives you access to the DB2 Express software for a period of one year and is a term license as opposed to a perpetual license as provided with other DB2 edition licenses. Other than that, the FTL license is identical to the SERVER license, including how the standby is licensed in hot configurations.
- SOCKET license
- The SOCKET license was introduced in DB2 9.7 and is only
available for DB2 Workgroup servers. When licensing a hot DB2
Workgroup standby server using a SOCKET license, you simply license
the number of sockets on the physical or virtual server, the
same as you would the primary server, since this is a hot/hot
configuration and all servers are fully utilized for regular
For example, if your hot standby was running on an unpartitioned, 4-way dual core IBM POWER7 server, you would buy four DB2 Workgroup SOCKET licenses. Incidentally, this server would be rated at 960 PVUs and you would still just buy four DB2 Workgroup SOCKET licenses. For a hot/hot configuration, and assuming the primary server is identical to the standby server, you would require eight DB2 Workgroup SOCKET licenses: four sockets for the hot primary server, and four sockets for the hot standby server. Whenever you license a DB2 Workgroup server, you should use this license because of the additional CPU capacity it offers your environment.
- Processor Value Unit (PVU) license
- Any DB2 physical or virtual server can be licensed using the PVU
model. In an active/active configuration, the entire PVU
rating of the hot standby server must be additionally licensed. Of
course, you would use this same approach to license your DB2 server
even if it weren't part of an HA cluster since it is servicing
production work anyway, so there shouldn't be any surprises here.
If the servers in Figure 3 used four cores of a POWER7 server, and assuming each machine was running DB2 Workgroup, you would have to purchase a total of 960 PVUs for this solution: 480 PVUs for machine 1 and 480 PVUs for machine 2.
- Authorized User Single Install (AUSI) license
- For any DB2 server product licensed by the AUSI model, you
must license such an environment by purchasing the total number of
Authorized Users (AUs) that will access it on the hot primary. In
addition, you must license the corresponding number of users that will
access the hot standby server too (since they are both effectively hot
servers for their own applications and standby servers for each
An AU is a single individual (in some cases, it can be an application or appliance so long as it doesn't act on behalf of other users) with a specific identity that resides inside or outside your company. These licenses can be used over the Internet as well (like an online trading application) because the end user is well known since they must be specifically identifiable for this license. If you're using multiplexing or connection concentration software, these users need to be fully identified and enumerated for before such technologies are applied to the counted connection.
You need an AUSI license for anyone accessing the server. However, no matter how many users are accessing your server, there are some edition-dependent minimums that you need to account for. The DB2 Express or DB2 Workgroup editions require a minimum of five AUSI licenses. DB2 Enterprise and DB2 Advanced Enterprise require a minimum of 25 AUSI licenses per 100 PVUs for the underlying server. Put another way, for every 100 PVUs on the server, you require one 25-AUSI license pack.
For example, a server with 480 PVUs would at minimum require 125 AUSI licenses because you round up the PVU count to 500 PVU for user minimum determination. Of course, if you had 150 users, then you would need to license the server beyond the minimum count to the actual number of uses; in this case 150 AUs. AUSI licenses are not transferable across work shifts (though they can be transferred for employment turnover), and they are only valid for a specific server. Of course since Figure 3 is an example of a hot/hot configuration, these rules don't apply since they have to be licensed like independent servers anyway.
In Figure 3, if you had 100 users that needed to access both hot DB2 Workgroup servers, you would need to purchase a total of 200 DB2 Workgroup AUSI licenses for these 100 users: 2 servers x 100 AUs per server. Even if only 12 of these users were ever connected to either server at any one time, all 100 users would still have to be licensed for each server (so you still need 200 AUSI licenses for this example).
If you were using DB2 Express or DB2 Workgroup in Figure 3, and you only had 3 users in your company, you would need a total of 10 DB2 Express or DB2 Workgroup AUSI licenses (2 servers x 5 minimum AUs) to satisfy the minimum AUSI requirements associated with these editions of DB2.
If the servers being used in Figure 3 were DB2 Enterprise, as previously mentioned, things are a little different: let's continue with the example where we assume that each server is a 4-core POWER7-based server rated at 480 PVUs. If you had 100 users that needed to access both hot DB2 Enterprise servers, you would need to purchase a total of 250 DB2 Enterprise AUSIs for these 100 users: 2 servers x 125 AUs per server because of the 25 users per 100 PVU minimum for each DB2 Enterprise server. Again, even if only 12 of these users were ever connected to either DB2 server at one time, all 125 users would still have to be licensed for each server.
A warm standby configuration is one in which at least one physical or virtual server in the HA cluster with DB2 installed and running is not servicing user transactions or query workloads during periods of normal operation. It is warm in the sense that the server is not performing "useful" work for end users. Work that is classified as "not useful" (although ironically it could be the most useful work your standby server ever does) includes administrative actions that assist in failover scenarios such as having a database in roll-forward pending state to support log shipping, supporting transaction-level log shipping for an HADR environment, performing a backup, and so on. If one of the servers in the HA cluster fails, then the workload is redistributed to the warm standby server.
One common misconception about a warm standby configuration is that a warm standby server is a waste of resource when solely dedicated to recovery operations. This perception is an incorrect understanding of this type of configuration. You can leverage a warm standby server for many uses (both DB2 and non-DB2 related) beyond the standby role.
For example, you could create a separate DB2 instance on the warm standby server (depending what DB2-related work you choose to perform here, it could have licensing implications) and use it as a test server, or perhaps offload other workloads and functions on it. In the event of a failure, you could scale back these workloads (or resources allocated to a virtualized partition where they run) and allow the warm standby server to use all of its resources to handle the load of the failed server thereby circumventing the load considerations outlined in the hot/hot standby discussion in the last section.
A warm standby scenario is shown in Figure 6. This is a "vanilla" HADR configuration (the Read on Standby capability is not being used) which has been created for a production OLTP environment. 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 a warm standby for Machine 2's workload. Machine 2 fails and its DB2 workload is passed to its warm 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 workload after the failure of Machine 2 (or Machine 1 was originally sized to support its workload and Machine 2's workload at the same time, otherwise you'll see a performance issue), as shown in Figure 6.
Figure 6. Machine 2's workload is transferred to the warm standby server, Machine 1 in this typical HADR cluster
Because, during periods of normal operation, only Machine 2 is hot from a DB2 perspective while the other DB2 server on Machine 1 is doing some warm activity like priming an HADR failover partner, this configuration is often referred to as hot/warm (or active/idle, in some circles). The important concept to note here is that Machine 1 wasn't doing any "meaningful" DB2 work before the outage occurred. Of course in an HADR Read on Standby or DB2 pureScale scenario, the 'standby' (which isn't really a standby because it is hot) is doing meaningful work and therefore none of these technologies are associated with a warm or cold standby rating.
Clients take different approaches to standby machines. You should prioritize your goals and business requirements with regards to a standby machine. For example, some clients may choose to set up a HA environment on a standby machine and at the same time use the standby database for a somewhat current read-only version of the production machine, thereby spreading out cost allocations over more and more resources; you can do this with HADR Read on Standby as of DB2 9.7 Fix Pack 1 or later.
Be aware that many vendors limit this model to either/or; meaning that while you are reading the database, you can't roll forward through the logs to keep it current (if it isn't either/or, there is a compromise with respect to how fast the redo processing can run among other considerations). Subsequently, leaving the database open for extended periods of read-only operations in such environments increases the mean time to repair (MTTR) in the event of a failure: the very issue this configuration is designed to avoid. Another example is with reading standby OLTP databases. If you think about it, an OLTP database is designed such that there are minimal indexes. If you start running reporting-like workloads on its standby server, the standby is likely to experience a number of table scans since there are no indexes to assist it for quick looks up. Running full table scans on a standby server could consume so many resources such that it may have trouble keeping the databases synchronized.
Depending on your availability requirements, workload, and so on, a warm standby may or may not be the right choice for your environment; however, when planning for the kind of standby you want to support, never forget why you have an HA environment in the first place, to minimize the MTTR from an outage. The point is that DB2 has options for hot/hot too (including the HADR Read on Standby technology introduced in DB2 9.7 Fix Pack 1) and DB2 pureScale. If you read off a standby server, for example, in an HADR configuration, that server is instantly considered hot. Bottom line, the notion that a warm standby server (from a DB2 perspective) is just sitting around wasting resources is an often very misunderstood concept when you really look at it, but with DB2, the choice is up to you; just remember that DB2 can deliver any configuration you want.
Licensing considerations for a warm standby machine
As of DB2 10.1, there are five different licensing methods (some are only available with specific DB2 editions): SERVER, Fixed Term License (FTL), SOCKET, Authorized User (AU), and Processor Value Unit (PVU). The following details the HA-licensing considerations you should be aware of for each respective license.
- SERVER license
- The SERVER license introduced with DB2 9.7 is only available
for DB2 Express servers. When licensing a DB2 Express standby server
using a SERVER license, you simply buy a license for each hot or
warm physical or virtual server in the cluster, while cold
standbys require no license. There are no user minimums, and you don't
have to figure out the PVU rating of the underlying server or anything
What this means is that in a hot/warm HA cluster, you'd actually buy a SERVER license for each DB2 Express server in the cluster, regardless of whether the server was hot or warm.
- Fixed Term License (FTL) license
- A FTL license is likewise only available for DB2 Express servers just
like a SERVER license. In fact, an FTL license is identical to the
SERVER license described above except a DB2 Express FTL license only
gives you access to the DB2 Express software for a period of one year.
It's a term license as opposed to a perpetual licenses as provided
with all other DB2 license options. When licensing a DB2 Express
server using an FTL license, you simply buy an FTL license for
each hot or warm physical server in the cluster - just
like the DB2 Express SERVER licenses. Cold standby servers require no
license. With the FTL license, there are no user minimums, and you
don't have to figure out the PVU rating of the underlying server or
anything else: simple!
What this means is that in a hot/warm HA cluster, you'd actually buy a FTL license for each DB2 Express server in the cluster, regardless of whether the server was hot or warm.
- SOCKET license
- The SOCKET license, also introduced in DB2 9.7, is only
available for DB2 Workgroup servers. When licensing DB2 Workgroup on a
warm physical or virtual server using a SOCKET license, you simply
need only one SOCKET license. For example, if your cluster consisted
of two unpartitioned, 4-way dual core IBM POWER7 servers, you would
buy 4 DB2 Workgroup SOCKET licenses for the primary server. For the
warm standby server, you simply purchase one additional SOCKET
license, no matter what. In the Figure 6 example, you would need 4 sockets (hot
Machine 2) + 1 socket (warm standby Machine 1) = 5 sockets.
Incidentally, the primary server would be rated at 960 PVUs and you still would just buy 4 DB2 Workgroup SOCKET licenses. Whenever you license a DB2 Workgroup server, you should use a SOCKET license because of the additional CPU capacity it offers your environment.
- Processor Value Unit (PVU) license
- For any physical or virtual server licensed using the PVU
model, you license a warm DB2 standby server for 100 PVUs
no matter what kind of processing core architecture the
server is based on. For example, if a server with four quad core AMD
processors equates to 800 PVUs and a server with two quad core POWER7
processors to 960 PVUs, with a warm standby server, you license either
machine with 100 PVUs of the corresponding DB2 edition.
In Figure 6, if the server used just four cores of a POWER7 server rated at 120 PVU per core, and assuming each machine was running DB2 Workgroup, you would have to purchase a total of 580 PVUs for this solution: (480 PVUs for Machine 2 + 100 PVUs for the warm standby Machine 1).
- Authorized User (AUSI) license
- For any DB2 server licensed by the AUSI model, you must license the
warm standby server by purchasing the minimum number of AUSIs for that
edition in consideration of it being a warm standby server. For DB2
Express and DB2 Workgroup, because the minimum number of AUSIs you
must license is five for any installation, a warm standby server would
require five AUSI licenses.
In Figure 6, if one DB2 Workgroup server was hot and was configured to participate in a hot/warm HADR cluster, and you had 100 users, you would need to purchase a total of 105 DB2 Workgroup AUSI licenses for these 100 users: 100 AUSIs + 5 AUSIs for the warm standby server. (Of course, the minimum number of AUSI licenses for the hot server needs to be met if the number of users is less than the minimum requirement.)
If Figure 6 was using DB2 Enterprise, things are a little different and admittedly a little more confusing. In DB2 Enterprise, the minimum number of AUSIs is 25 for every 100 PVUs (as detailed earlier in this article). Since you have to minimally licensed 100 PVUs for a warm standby in the PVU model with a DB2 Enterprise server, you convert the minimum 100 PVUs to 25 AUSIs. The 25 AUSIs becomes the minimum number of AUSIs needed for a DB2 Enterprise warm standby server that is licensed using the AUSI model.
For example, if the servers in Figure 6 were 2 socket Intel x86-based dual core servers, the total PVU rating for the hot server would be 200 PVUs. If you only had three users accessing the hot DB2 Enterprise server, you would still need a total of 75 AUSIs for this configuration: (200/100=2 x 25 AUs) for the hot server plus 25 AUs for the DB2 Enterprise warm standby server. However, if the servers in Figure 6 were two socket POWER7 dual core servers (so there are a total of four cores on this server), the total PVU rating for the hot server would be 480 PVUs. If you only had three users accessing the hot DB2 Enterprise server, you would now need a total of 150 AUs users for this configuration: (480/100=4.8, rounded up is 5 x 25 AUs for the hot server = 125 AUs) + the minimum 25 AUs for the DB2 Enterprise warm standby server.
A question that often comes up in warm standby configurations is the license impact of a failover. For example, suppose you have an unpartitioned 4-socket primary server, and another unpartitioned 4-socket warm standby server, both running DB2 Workgroup licensed by the SOCKET metric, For that configuration, you would have to purchase 4 + 1 = 5 SOCKET licenses. Now suppose the hot primary server goes down such that the standby server becomes the new primary, and the former primary server becomes the new standby server when it's brought back online. In this scenario, no additional license is required as the configuration is still covered by the 5 existing SOCKET licenses.
Note that when running multiple warm standby servers on the same physical machine, you only need to license the first standby, providing all are the same DB2 edition licensed under the same charge metric. This rule applies whether the warm standbys are running in the same partition or multiple partitions / virtual sessions. It also applies whether the warm standbys are part of the same HA cluster or different HA clusters. As a result, one effective money-saving HA strategy is to consolidate multiple warm standbys onto as few physical servers as practical. For example, suppose a company has 10 warm DB2 Enterprise standby servers licensed by PVU, installed on 10 separate physical servers. Total warm standby license requirements for that configuration would be 10 x 100 = 1000 PVU. If instead, they consolidated all of their standby servers onto one physical server, they would only need 100 PVUs. That’s quite substantial savings, and doesn’t even take into consideration additional savings as a result of hardware consolidation (such as higher utilization, space savings, easier maintenance, and others). We recommend you take advantage of warm standby consolidation wherever it makes sense to do so.
A cold standby configuration is one in which at least one physical or virtual server in the cluster:
- Does not have a DB2 database that is servicing user transactions or query workloads during periods of normal operation.
- Is not performing any administrative actions during normal operation that assist in failover scenarios such as having a database in roll-forward pending state to support HADR; in fact, a cold server may not even be powered on except for brief periods to conduct maintenance – such as performing a back-up or applying a fix pack.
A cold standby scenario is shown in Figure 7.
Figure 7. Machine 1 is a cold standby server for Machine 2
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 doesn't have a started DB2 instance. Perhaps it's even the case that DB2 is installed on the machine and it's turned off; in the event of a failure, Machine 1 is booted up, recovered to a certain point in time from a backup image, and opened up for user transactions. It could also be the case that Machine 1 is configured to be part of a Tivoli SA-MP cluster (among other HA clustering options, including PowerHA for AIX), but the database instance isn't started. As you can imagine, a cold standby configuration isn't much of an availability solution in that the MTTR is typically going to be a lot longer than a hot or warm standby configuration; that said, it may suit the needs of some of your applications, and if it does, the cost of this solution got really attractive as of DB2 9.5 and beyond for the reasons outlined earlier.
Licensing considerations for a cold standby machine
A DB2 cold standby server doesn't need to be licensed and thus there are obviously no licensing considerations. A good rule of thumb to determine if a standby machine can be classified as cold is to see if the DB2 instance is started; however, there are some exceptions. For example, if you took a snapshot image off of a production server and started the DB2 standby server for the sole purpose of performing a backup then stopped it, we would consider that a cold standby, and no license for that server would be required. In a failover scenario where the cold standby is started and becomes the new hot primary, no additional licenses are required if the number of licenses required for that server is the same or less than the number of licenses that were required for the former primary server. If that is not the case, you must acquire additional license appropriate for the new hot primary server. Alternatively, you should switch the primary back to a server for which you are appropriately licensed to run in a hot configuration.
Mixed standby environments
So far we have only considered HA scenarios where the standbys were all hot, all warm, or all cold. That will always be the case if you only have a single standby server in your cluster or if you are using DB2 pureScale which only supports hot standbys. However, it's also possible to have multiple standbys in an HA environment that are not the same 'temperature'. For example, suppose you require redundant HA at your primary data center as well as disaster recovery at a second remote data center. Furthermore, suppose you need the ability to process read workloads without adding any extra load to the primary server during normal operations. One architecture that minimally meets those requirements is shown in Figure 8.
Figure 8. Mixed standby environment
In this example, the primary database on Machine 1 uses log shipping or Q-Replication to replicate to two local standby servers, Machine 2 and Machine 3, as well as a third remote standby server, Machine 4. In the event that Machine 1 fails, Machine 2 takes over the workload. If Machine 2 also fails, then Machine 3 takes over. During normal operations, Machine 2 is also used to process read workloads and must therefore be fully licensed. Machines 3 and 4 don't process any end-user workloads during normal operations, but must be fully functional in order to receive and apply the logs from the primary, so they must both be licensed as warm servers.
Note the license considerations for each standby in a mixed standby environment are exactly as described in the above sections. For example, if you were running DB2 Enterprise, and each machine (shown previously in Figure 8), was an unpartitioned two socket POWER7 dual core server rated at 100 PVU per core, then you would need (4x100) = 400 PVU DB2 Enterprise entitlements for the primary server and another 400 PVU entitlements for the hot standby server. For each of the warm standby servers, you would need an additional (1x100) = 100 PVU entitlements. Therefore, you would need 1000 DB2 Enterprise PVU entitlements in total for this entire environment.
If instead you were licensing DB2 Enterprise under the AUSI metric and had 88 authorized users that would access Machine 1, and 10 authorized that would access Machine 2 under normal conditions, you would need (25x4) = 100 DB2 Enterprise AUSI entitlements for the primary server and another (25x4) = 100 AUSI entitlements for the hot standby server. For each of the warm standby servers, you would need an additional (25x1) = 25 AUSI entitlements. Therefore, you would need 250 DB2 Enterprise AUSI entitlements in total for this entire environment.
There are various ways to implement the environment,(shown previously in Figure 8). However, the most straightforward way would be to use the new HADR Multiple Standby capability introduced in all DB2 10.1 editions. This new function allows you to create a cluster with a primary server, with up to 3 standby servers all using the same proven and easy to use HADR functionality (prior to DB2 10.1, a HADR cluster could only have 1 primary and 1 standby server). Moreover, each of the standby servers can be cold, warm, or hot without regard for the other standby servers in the cluster.
With HADR, the primary server Machine 1, (shown previously in Figure 8), would ship logs at transaction boundaries to Machines 2, 3, and 4. Machine 2 would also use the Read on Standby feature to be able to handle read workloads. If Machine 1 fails, the TSA functionality included with HADR would automatically re-route Machine 1’s workload to Machine 2. Upon taking over this work, Machine 2 would stop processing its original read workload so that it can focus exclusively on its new workload. If Machine 2 also fails, your DBA would manually failover the workload to Machine 3. In the worst case scenario where you lose your primary site, including everything that was on Machines 1, 2, and 3, your remote standby Machine 4 would be up-to-date, except perhaps for any logs that were in flight when your primary site went down.
Reach higher - availability that is
You have a lot of HA options with DB2. We recommend that you create multi-tier classifications for applications that require availability; for example, Bronze, Silver, and Gold ratings. Perhaps it's the case that anything rated Bronze would leverage a cold standby and a DB2 integrated cluster; while a Silver rated solution would leverage DB2 HADR technology; and finally, a Gold rated solution would be a hot standby configuration such as DB2 pureScale. We've put together a cheat sheet of some of the possible HA solutions and their respective categorization in Table 2.
Table 2. Approaching your HA requirements with a tiered solution and the corresponding DB2 technologies available
|DB2 integrated clustering||HADR||DB2 pureScale|
It isn't always the case that everything needs to be a gold-level solution. Everyone thinks they need 24/7 availability for all applications, but in our vast consulting experience, that's just not the case.
For example, one client had a mission critical application that need 24x7 availability, but their other applications could take up to a two day outage. In these cases, would it make sense to treat them all the same from an availability perspective? If you had an unlimited budget, perhaps. Choose the right availability solution that matches the service level agreement (SLA) that's backing your job: HA is a linear cost curve in that the more redundancy and availability you want, the more it will cost from a hardware and software perspective. Beyond the software, the more HA you want, the more you typically end up paying (think redundancy, licensing, power, and more). The bottom line is not everything needs to be ultra-available; be smart and definitely leverage the right technology for the right HA requirements.
Although outside the scope of this article, for completeness, we thought we would include a cheat sheet for HA's "cousin" Disaster Recovery (DR) in Table 3. Use the same considerations you use to determine appropriate licensing for HA and apply them to DR as was demonstrated in the discussion involving what was shown previously in Figure 8.
Table 3. Approaching your DR requirements with a tiered solution and the corresponding DB2 technologies available
|Q replication||HADR physical replication||HADR logical replication|
- Download a free trial version of DB2 for Linux, UNIX, and Windows.
- Now you can use DB2 for free. Download DB2 Express-C, a no-charge version of DB2 Express Edition for the community that offers the same core data features as DB2 Express Edition and provides a solid base to build and deploy applications.
- Read "Compare the distributed DB2 10.1 servers" (developerWorks, May 2012): In a side-by-side comparison table, authors William Kulju, Steven Astorino, and Paul Zikopoulos make it simple to understand the basic licensing rules, functions, and feature differences between the members of the distributed DB2 10.1 server family.
- Read "Which distributed edition of DB2 10.1 is right for you?" (developerWorks, May 2012): Learn the details on what makes each edition of DB2 10.1 unique. The authors lay out the specifications for each edition and describe some interesting things customers are doing with each edition of DB2.
- Read "DB2 and IBM Processor Value Unit (PVU) pricing" (developerWorks, Sep 2009): This article describes how to license DB2 products using the new Value Unit metric as well as a number of helpful everyday scenarios.
- Visit the developerWorks resource page for DB2 for Linux, UNIX, and Windows to read articles and tutorials and connect to other resources to expand your DB2 skills.
- Learn about DB2 Express-C, the no-charge version of DB2 Express Edition for the community.
- Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.