Licensing distributed DB2 9.7 servers in a high availability (HA) environment

Are you trying to ensure you're licensing your IBM® DB2® Version 9.7 for Linux®, UNIX®, and Windows® (DB2 9.7) servers correctly in a high availability environment? Don't have the time or the will to read through the announcement letters, PLETs, or your licensing sheets? Authors Paul Zikopoulos and Steve Astorino explain it all in plain English for the DB2 9.7 release that became generally available on June 17th, 2009 and for later releases. [2011 June 16: The authors updated this article to include information about the latest changes done in fixpacks for the DB2 9.7 release. --Ed.]

Paul Zikopoulos (paulz_ibm@msn.com), Director of Technical Professionals, IBM

Paul Zikopoulos photoPaul C. Zikopoulos, B.A., M.B.A., is the Director of Technical Professionals for IBM Software Group's $5B Information Management division. In this role, he has executive responsibilities for the vitality of its client facing technical professional community (ensuring they are among the most technically skilled personnel in the marketplace), driving revenue and profit attainment goals, accelerating the sales pipeline, and leading the competitive charge against its competitors. In his previous role, Paul led the IM DB2 Evangelist and Competitive programs for IBM. Paul is an award-winning writer and speaker with more than 18 years of experience in Information Management: from Governance to Implementation to Business Value Assessments. Paul has written more than 300 magazine articles and 14 books including DB2 pureScale, Database Cost Saving Features, information on Demand, DB2 for Dummies, and many more. Paul is an IBM Certified Advanced Technical Expert and an IBM Certified Solutions Expert. In his spare time, he enjoys all sorts of sporting activities, including running with his dog Chachi, avoiding punches in his Masters of Martial Arts training, and trying to figure out the world according to Chloë, his daughter.



Steven Astorino (astorino@ca.ibm.com), Senior Development Manager, IBM

Steven Astorino photoSteven Astorino, BSc - Computer Science, is a Senior Manager of DB2 Development, overseeing Information Development, User Experience, and DB2 Install Development. He has many years of experience with databases, including DB2 and real time database replication. Steven began his career as a developer, and he has held a wide range of roles from software development and quality assurance to information development and user experience. Early in his career, Steven spent several years working with network testing technologies for the telecom industry, and he played a key role in providing VoIP testing solutions. High quality, efficiency, and customer focus are some of his key goals to ensure outstanding customer satisfaction.



18 August 2011 (First published 29 October 2009)

Also available in Chinese Russian Vietnamese Portuguese

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 hear lots 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 highly available environments.

Another source of confusion stems from the terms used in discussions that relate to 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 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 was first introduced in DB2 9 and subsequently deeply integrated in the DB2 9.5 release on a group of servers), or both (as is the case with a DB2 pureScale cluster, or the IBM Smart Analytics System). Despite not liking the term, it's used; so for this article, when referring to the term cluster, we mean clustering for HA (unless otherwise noted). For simplicity, we recommend you 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 just ensure you're always communicating what you're trying to do when talking to your colleagues.

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 (among other names). If you've been around long enough, you've likely run the gambit of terms describing the function that this one 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. Before DB2 9.5, things in "DB2-land" were a little different, however, since the DB2 9.5 release (and later), the DB2 HA taxonomy and licensing terms conform to the IBM SWG taxonomy and licensing terms with respect to HA pricing. For example, if you configured a DB2 9.1 HA cluster using IBM PowerHA for AIX (once known as High Availability Cluster Multiprocessing - HACMP) such that one server sat idle (and the database manager was not started), you would have had to partially license that server. As of DB2 9.5 and on, you don't have to pay a cent! Likewise, if you had DB2 9.1 installed on a server that was powered off, you would have had to partially license that server too. As of DB2 9.5 and later you don't have to buy a DB2 license for a server that isn't powered on. We've updated this article for the DB2 9.7 release and any interim changes as a result of a fixpack to help you sort out DB2 high availability licensing rules and put you in-the-know.

Note: This article also covers the DB2 pureScale technology that was initially announced in October 2009. The delivery vehicle for DB2 pureScale is DB2 9.8; however, the only reason to run DB2 9.8 is for DB2 pureScale. In other words, if you are running a DB2 9.7 server and don't have plans to use DB2 pureScale, you would not move to DB2 9.8.

Figure 1 gives a good description of the DB2 9.7 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 9.7 hot, warm, and cold high availability taxonomy
Some helpful hints when it comes to the DB2 9.7 Hot, Warm, and Cold high availability taxonomy

Table 1 shows the most common terms used to describe HA environments mapped to the DB2 9.7 taxonomy and licensing terms.

Table 1. Mapping industry high availability terms to the DB2 9.7 licensing terms
ColdWarmHot
DB2 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, and it will be started only when a failover occurs.The database instance is started, and it might be receiving updates from the primary database for high availability purposes only. 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 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 category; however, after reading this article, it will hopefully be clear. Quite simply, how you license a DB2 server in an HA environment depends on your answers to these several key questions:

What edition of DB2 do you have installed?
Is it: DB2 Express-C, DB2 Express, DB2 Workgroup, DB2 Enterprise, or DB2 Advanced Enterprise? For example, a DB2 Express server with a SERVER license (introduced when DB2 9.7 became generally available) doesn't have the concept of hot, warm, or cold for a standby server (more on that in a bit). You should be aware that you are not licensed to configure the free DB2 Express-C in any kind of HA configuration - if you need HA you minimally need DB2 Express. (Note that the DB2 Express - C FTL was available only in the DB2 9.5 release and is no longer available in DB2 9.7. It is now available as DB2 Express FTL: same price as before with more features!)
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 in the event of a failure; for example, in an HADR scenario. Are you managing a DB2 pureScale cluster? Quite simply, what the standby server is doing when everything is running just fine has pretty much everything to do with how DB2 on that server needs to be licensed.
How did you license your DB2 server that you want to ensure is highly available?
For example, if you licensed a DB2 Express server using the SERVER license introduced in DB2 9.7, you have to buy an additional SERVER license for the standby server no matter what kind of operational state it's in: hot, warm, or cold. If you licensed your DB2 Express server using the Authorized User (AU) model, you'd license the standby server in a warm state for 5 AUs and wouldn't need a license at all for a cold standby machine. If you're DB2 Express server was licensed using the Processor Value Unit (PVU) model, you'd license a warm standby server for 100 PVUs (no matter which processor architecture the server is using) and wouldn't even need a licensed for a cold standby machine either.

If you're looking for an overview of all the distributed DB2 9 servers and how to license them, refer to "Which distributed edition of DB2 9.7 is right for you?". For comparisons of the features, functions, and benefits between the different DB2 server editions, read "Compare the distributed DB2 9.7 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 Pack, and license this feature pack on both servers. In DB2 9, this changed: you no longer had to license this feature pack on the standby server. In DB2 9.5, IBM made the High Availability Feature Pack free for DB2 Workgroup 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 server is acting as a warm standby for multiple production servers, you only have to license the warm standby server once (as of DB2 8.2). For example, if you licensed a hot DB2 server for an unlimited number of users, the warm standby server would require 100 PVUs. If 5 different 400 PVU-rated servers were running DB2 Workgroup, and each server was configured in an HADR cluster to fail over to the same 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 feature packs 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 Pack (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 Pack.
  • HADR is included in DB2 Workgroup at no extra charge (as of DB2 9); 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) for any SMB-targeted server.
  • You get free clustering software for virtually any edition (with DB2 Express you need to use an FTL or SERVER license, or you need to buy a feature pack) - 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. What's more, you 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 slash the TCO of an HA cluster.
  • You can configure two DB2 Express servers in an HADR cluster without having to purchase the High Availability Feature Pack if you license your DB2 Express servers using either the Fixed Term License (FTL) or SERVER license (both licensing options were introduced when DB2 9.7 became generally available).

Note: 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 to this kind of licensing that you should be aware of, so ensure you know all the details before deploying DB2 in this kind of environment.

As you can see, there have been a lot of changes to flatten the 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 9.7 licensing is with examples that correlate to the DB2 HA taxonomy. As previously mentioned, DB2 9.7 defines three types of standby servers: hot, warm, and cold.

Hot standby

A hot standby configuration is one in which all 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 machines 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 two node cluster) the workload on the hot standby server (for example, the lone surviving machine in a two-node HADR cluster) 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 HA environment and not leveraging advanced clustering topologies such as DB2 pureScale. 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, in DB2, a hot standby server is any machine being used to service user transactions and queries during normal operational periods, yet acts as a standby for another server that is also used to service user transactions during normal operational periods too. When a failure of the server in the cluster occurs, the hot standby server takes 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 enterprise resource planning (ERP) packaged application and the other running a supply chain management (SCM) packaged application. If the SCM database was to fail, the machine running the ERP workload would have to service all the SCM users too. A scenario illustrating a two node hot standby HA cluster is shown in Figure 2.

Figure 2. 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.
Machine 1 is a hot standby for machine 2 who is a hot standby for machine 1

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). 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 in Figure 2 were being used all along for production workloads; 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. For example, consider the environment shown in Figure 3.

Figure 3. An HADR hot/hot cluster due to mutual HADR failover clusters
An HADR hot/hot mutual cluster.

In the previous figure you can see that 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, 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.

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
An HADR hot/hot cluster due to Read on Standby

In Figure 4 you can see that clients can read and write to the Primary server (making it hot); but, since they are reading on the Secondary server it is also hot and therefore both servers must be fully licensed. Quite simply, if you read data from a server for business purposes, it's a hot machine.

Finally, Figure 5 shows a 3 member DB2 pureScale HA and scaling cluster.

Figure 5. A DB2 pureScale cluster
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 you can see are typically fully duplexed) do not require any licenses whatsoever. In this example, since transactions are being seamlessly load balanced across all the Members, they are all hot and therefore must all be fully licensed.

Licensing considerations for a hot standby machine

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 high availability at all.

As of DB2 9.7, 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 for each respective license in a hot/hot HA cluster.

SERVER license
A SERVER license is new to 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 server in the cluster no matter what type of standby (hot, warm, or cold) it is. Quite simply, 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 licensing requirements are different compared to other DB2 licenses.

In addition, if you wanted to create an HADR cluster using a DB2 Express server in DB2 9.5, you had to buy the DB2 High Availability Feature Pack to get this feature along with other HA-related features. In DB2 9.7, the DB2 Express SERVER license actually comes with all the features in the High Availability Feature Pack (including HADR) for free; however you do buy this feature pack if you want HADR (or other features) with a DB2 Express server licensed via the alternative PVU or AU licenses. For this reason, and more, we recommend using this (or an FTL) license for any DB2 Express servers.

Fixed Term License (FTL) license
While FTL license is new to DB2 Express 9.7, it has the same pricing methodology as the old DB2 Express-C FTL 9.5 license (which is no longer available). This license gives you access to all the features in DB2 Express (unlike its predecessor). A DB2 Express FTL license gives you access to the DB2 Express software for a period of one year - it's a term license as opposed to a perpetual license as provided with other DB2 edition licenses. When licensing a DB2 Express server using an FTL license, you simply buy an FTL license for each server in the cluster - just like the DB2 Express SERVER licenses - no matter what type of standby (hot, warm, or cold) it is. Quite simply, there's no need to identify the activity level of a DB2 Express server licensed using an FTL 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 licensing requirements are different compared to other DB2 editions.

A DB2 Express server licensed with an FTL license gives you access to all the features in the DB2 High Availability Feature Pack, including HADR. (Note, however, that you have to buy this feature pack to enable HADR, among other high availability features, if you are using a DB2 Express PVU or AU license.) For this reason, and more, we strongly recommend using this (or a SERVER) license for any DB2 Express servers.

SOCKET license
A SOCKET license is new to DB2 9.7 and is only available for DB2 Workgroup servers. When licensing a DB2 Workgroup server using a SOCKET license, you simply license the same number of sockets as on the primary for each server since this is a hot/hot configuration and all servers are fully utilized for regular operations.

For example, if you had a 4-way dual core IBM POWER7 server, you would buy 4 DB2 Workgroup SOCKET licenses. Incidentally, this server would be rated at 960 PVUs and you would still just buy 4 DB2 Workgroup SOCKET licenses. For a hot/hot configuration, you would require 8 DB2 Workgroup SOCKET licenses: 4 sockets for the hot primary server and 4 sockets for the hot standby server. Whenever you license a DB2 Workgroup server, we strongly recommend using this license because of the additional CPU capacity it offers your environment.

Processor Value Unit (PVU) license
Any DB2 server can be licensed using the PVU model. In an active/active configuration, the entire PVU rating of the hot standby server (machine 1 in our working example) 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 server in Figure 3 utilized just four cores of a POWER7 server, and assuming each machine was running a DB2 Workgroup (which is limited with this license to servers with a maximum 480 PVU rating of as of 2Q08), 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 (AU) license
For any DB2 server product that is licensed by the AU model, you must license such an environment by purchasing the total number of AUs that will access it on the hot primary, in addition to 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 other).

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. AU licenses are full entitlements; there is no need for separate server licenses as was the case back in DB2 8 where you bought user entitlements along with a base server 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 AU 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 AU licenses. DB2 Enterprise requires a minimum of 25 AUs per 100 PVUs for the underlying server. Put another way, for every 100 PVUs on the server, you require one 25-AU pack. For example, a server with 480 PVUs would at minimum require 125 AU licenses because you round up the PVU count 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. AU 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 are moot since they have to be licensed like independent servers anyway.

In the example shown 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 AU 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 AU 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 AU licenses (2 servers x 5 minimum AUs) to satisfy the minimum AU 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 AU 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.


Warm standby

A warm standby configuration is one in which at least one server in the HA cluster does not have a DB2 database that is 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. 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 rollforward pending state to support log shipping, supporting transaction-level log shipping for an HADR environment, 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 many have about a warm standby configuration is that a warm 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 a warm standby machine 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 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 (or resources allocated to a virtualized partition where they run) and allow the warm standby machine to use all of the server's 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. In this figure, a "vanilla" (the Read on Standby capability is not being used) HADR configuration 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).

Figure 6. Machine 2's workload is transferred to the warm standby server, machine 1 in this typical HADR cluster
Machine 2's workload is transferred to the warm standby server, machine 1 in this vanilla HADR cluster

Because during periods of normal operation only one machine is hot from a DB2 perspective in Figure 6 while the other 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 all sorts of different approaches to standby machines. We recommend that you prioritize your goals and business requirements with regards to a standby machine. For example, some clients may choose to set up an 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 as of DB2 9.7 Fix Pack 1 or later. You should 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 some HADR read on standby technology that wasn't part of DB2 9.7 when it first became available but was introduced in DB2 9.7 Fix Pack 1) and the all new 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 9.7, 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
A SERVER license is new to 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 server in the cluster no matter what type of standby (hot, warm, or cold) it is. Quite simply, 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!

In addition, if you wanted to create an HADR cluster using a DB2 Express server in DB2 9.5, you had to buy the DB2 High Availability Feature Pack to get this feature along with other HA-related features. In DB2 9.7, the DB2 Express SERVER license actually comes with all the features in the High Availability Feature Pack (including HADR) for free; however you do buy this feature pack if you want HADR (or other features) with a DB2 Express server licensed via the alternative PVU or AU licenses. For this reason, and more, we recommend using this (or an FTL) license for any DB2 Express servers.

In a hot/warm HA cluster, you'd actually buy a SERVER license for each DB2 Express server. If you wanted to create an HADR cluster using a DB2 Express server in DB2 9.5, you had to buy the DB2 High Availability Feature Pack to get this feature along with other HA-related features. In DB2 9.7, the DB2 Express SERVER license actually comes with all the features included in the High Availability Feature Pack (including HADR) for free. You have to buy this feature pack if you want to use HADR (or a number of other advanced HA-related DB2 technologies) with a DB2 Express server licensed via a PVU or AU licenses.

Fixed Term License (FTL) license
While FTL license is new to DB2 Express 9.7; it has the same pricing methodology as the old DB2 Express-C FTL 9.5 license (which is no longer available). This license gives you access to all the features in DB2 Express (unlike its predecessor). A DB2 Express FTL license gives you access to the DB2 Express software for a period of one year - it's a term license as opposed to a perpetual license as provided with other DB2 edition licenses. When licensing a DB2 Express server using an FTL license, you simply buy an FTL license for each server in the cluster - just like the DB2 Express SERVER licenses - no matter what type of standby (hot, warm, or cold) it is. Quite simply, there's no need to identify the activity level of a DB2 Express server licensed using an FTL 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!

In a hot/warm HA cluster, you'd actually buy an FTL license for each DB2 Express server. If you wanted to create an HADR cluster using a DB2 Express server in DB2 9.5, you had to buy the DB2 High Availability Feature Pack to get this feature along with other HA-related features. In DB2 9.7, the DB2 Express FTL license actually comes with all the components of the High Availability Feature Pack (including HADR) for free; in fact, a DB2 Express FTL license entitles you to all the features available in the DB2 High Availability Feature Pack! You have to buy this Feature Pack if you want HADR (or a number of other advanced HA-related DB2 technologies) with a DB2 Express server licensed via the PVU or AU licenses. For this reason, and more, we strongly recommend using this (or a SERVER) license for any DB2 Express servers.

SOCKET license
A SOCKET license is also new in DB2 9.7 and is only available for DB2 Workgroup servers. When licensing a DB2 Workgroup server using a SOCKET license, you simple buy a license for the number of sockets that DB2 will use on the primary server. If you had a 4-way dual core IBM POWER7 server, you would buy 4 DB2 Workgroup SOCKET licenses. 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) + 1 socket (warm standby) = 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, we strongly recommend using this license because of the additional CPU capacity it offers your environment.

Processor Value Unit (PVU) license
For any DB2 server that is licensed using the PVU model, you license a warm standby server for 100 PVUs no matter what kind of processing core architecture the server is based on. In other words, 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 just license it with 100 PVUs of the corresponding DB2 edition.

For example, if the server in Figure 6 utilized just four cores of a POWER7 server, and assuming each machine was running DB2 Workgroup (which is no longer limited to servers with a maximum 480-PVU rating of as of June 2011), you would have to purchase a total of 580 PVUs for this solution: (480 PVUs for machine 2 + 100 PVUs for warm standby machine 1).
NOTE: As of June 2011, the 480-PVU restriction has been removed. This means you can now install and use DB2 Workgroup on physical or virtual servers with more than 480 PVUs, provided you have appropriately licensed all the PVUs that DB2 Workgroup has access to, up to 16 cores. If the physical or virtual server has more than 16 cores, you still only pay for 16 cores because that's all DB2 will use. This applies to 9.5 and 9.7.

Authorized User (AU) license
For any DB2 server that is licensed by the AU model, you must license the warm standby server by purchasing the minimum number of AUs for that edition in consideration of it being a warm standby server. For DB2 Express and DB2 Workgroup, because the minimum number of AUs you must license is 5 for any installation, a warm standby server would require 5 AU 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 AU licenses for these 100 users: 100 AUs + 5 AUs for the warm standby server. (Of course, the minimum number of AU 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 AUs 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 AUs and that becomes the minimum number of AUs needed for a DB2 Enterprise warm standby server that is licensed using the AU model. Let us clarify with the use of an example using Figure 6. If the servers in Figure 6 were two 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 AUs 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 4 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.


Cold standby

A cold standby configuration is one in which at least one server in the cluster does not have a DB2 database that is servicing user transactions or query workloads during periods of normal operation and it isn't performing any administrative actions that assist in failover scenarios such as having a database in rollforward pending state to support HADR; in fact, a cold server may not even be powered on. A cold standby scenario is shown in Figure 7.

Figure 7. Machine 1 is a cold standby server for Machine 2
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 a 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 heck of 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 gets really attractive in DB2 9.5 and beyond for the reasons outlined earlier in this article.

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.

So here is a perfect example how licensing rules over the last few releases in DB2 save you money and who isn't looking for that in this tight economy? Let's assume you were licensing a DB2 9 Workgroup server along with the pureXML Feature Pack for an XML-based application with some HA requirements. In DB2 9, you would have to fully license the hot server (as expected) for both DB2 and the pureXML Feature Pack; in addition, the cold server would have to be licensed for 100 PVUs of DB2 Workgroup and 100 PVUs of the pureXML Feature Pack. In DB2 9.7, you would just buy DB2 Workgroup licenses for the hot server. The pureXML feature is free in all DB2 editions (as of February 9th, 2009) and a cold standby server requires no licensing. Now add in the fact that you can license DB2 Workgroup with a SOCKET license, and you've doubled the capacity of your highly available XML-based solution and reduced your costs by over 50%!


Reach higher - availability that is

As you can see, you have a lot of high availability options with DB2. We recommend clients 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
BronzeSilverGold
DB2 Integrated ClusteringHADRDB2 pureScale
  • Hot/cold
  • Basic availability solution
  • Free in most cases
  • Provides failover, typically in less than 5 minutes
  • Hot/warm (optional hot with read on standby)
  • Provides very fast failover, typically in less than 1 minute
  • Easy to setup with turnkey availability
  • Minimal licensing on the standby server
  • Potential zero data loss option
  • Hot/hot
  • Online failover
  • Transactions on surviving nodes are not impacted
  • Provides the fastest failover, typically in less than 30 seconds
  • Online scaleout capability to address workload spikes

We'd like to note at this point that it isn't always the case that everything needs to be a Gold-level solution. Everyone thinks they need 24-hours/day by 7-days/week 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: high availability in a linear cost curve. 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 seat for HA's "cousin" Disaster Recovery (DR) in Table 3. (The same considerations you use to determine appropriate licensing for HA applies to DR):

Table 3. Approaching your DR requirements with a tiered solution and the corresponding DB2 technologies available
BronzeSilverGold
Q ReplicationHADR Physical ReplicationHADR Logical Replication
  • Hot/hot
  • Unrestricted access to the target database
  • Supports different versions of DB2 on source and target
  • Supports sub-setting of data
  • Multiple target support
  • Online failover
  • Can replicate to a different topology
  • Async only
  • Can be complex to set up
  • No DDL support
  • Hot/warm
  • Zero data loss option
  • Provides very fast failover, typically in under 1 minute
  • Easy to set up with turnkey availability
  • DDL and DML replication support
  • Limited use of the standby
  • Single target support only
  • Full database replication only
  • Hot/hot
  • Zero data loss option
  • Online failover
  • Provides the fastest failover, typically in less than 30 seconds
  • Online scaleout capability to address workload spikes
  • Unrestricted access to the target
  • Can be configured with time delay apply
  • Multiple target support
  • DDL and DML replication support
  • Rolling version upgrade capability
  • Can replicate to a different topology

Resources

Learn

  • "Compare the distributed DB2 9.7 servers" (developerWorks, Sep 2009): In a side-by-side comparison table, author Paul Zikopoulos makes it simple to understand the basic licensing rules, functions, and feature differences between the members of the distributed DB2 9.7 server family.
  • "Which distributed edition of DB2 9.7 is right for you?" (developerWorks, Sep 2009): Learn the details on what makes each edition of DB2 9.7 unique. The author lays out the specifications for each edition, outlines licensing considerations, historical changes from DB2 9, and describes some interesting things customers are doing with each edition of DB2.
  • "DB2 and IBM Processor Value Unit (PVU) pricing" (developerWorks, Sep 2009): This article describes how to license DB2 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.
  • developerWorks Information Management: Learn more about IBM Information Management products. You'll find technical documentation, how-to articles, education, downloads, product information, and more.

Get products and technologies

  • 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.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=427138
ArticleTitle=Licensing distributed DB2 9.7 servers in a high availability (HA) environment
publish-date=08182011