|
|
|
|
Are you trying to ensure you're licensing your IBM® DB2® Version 9 for Linux®, UNIX®, and Windows® (DB2 9) data servers correctly in a high availability environment? Don't have the time nor the will to read through the announcement letters, PLETs, or your licensing sheets?
Customers choose the IBM DB2 data server 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, I focus on the high-availability aspects of DB2, not so much from a functionality point of view (of which much has been written), but from the point of view of licensing.
I hear a lot of questions about licensing DB2 in a high availability (HA) environment -- configurations that are designed to address unplanned outages (and sometimes planned ones too). Usually the first level of confusion is caused by wide variations in how different vendors price their database products in high availability environments.
Another level of confusion centers on the terms used in discussions of high availability. For example, the term clusters. Sometimes the IT industry refers to highly available environments as clusters. I 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 DB2 database partitioning feature (DPF), or clustering for availability (for example, using Microsoft Cluster Server on a group of Windows servers). Despite not liking the term, it's used; so for this article, when referring to the term cluster, I mean clustering for high availability (unless otherwise noted). For simplicity, I recommend you prefix the term cluster with high availability or scalability when discussing clusters with your clients or 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 can be referred to as a standby or secondary server. If you've been around long enough, you've likely run the gambit of terms describing the function that this one server performs. These terms include: idle, active, cold, warm, hot, and passive.
For the most part, IBM literature uses the cold, warm, and hot taxonomy to describe standby servers. However, things in "DB2-land" are a little different. DB2 uses the terms idle and active for standby data servers. Consequently, DB2 has pricing and licensing terms that may not be the same as some other IBM software products. This too is often a source of confusion for clients, so reading this article will help you sort this out and put you in-the-know.
In Figure 1, I've mapped the most common terms used to describe HA environments to the DB2 terms:
Figure 1. Mapping industry high availability terms to DB2's terms
In the previous figure I appended a general rule of thumb below each category, but after reading this article, it will hopefully by clear. As well, keep in mind that this is the general rule; you may indeed call something a hot standby when for DB2 purposes it is idle (read on).
How you license a DB2 server in a high-availability environment depends on your answers to several key questions, including:
Note that the terms and conditions associated with DB2 Express-C do not allow you to configure it for use within any type of high availability cluster, which is not the case with DB2 Express-C FTL (more on that in a bit).
The best place to start a discussion of the effects of high availability clusters on DB2 9 licensing is with the terminology that's used in "DB2-land" - so that we are all on the same page. As previously noted, DB2 defines two types of standby servers: active and idle .
An active standby configuration is one in which all servers have independent operational DB2 databases that service user transactions and queries. This configuration is sometimes called an active/active configuration since all the machines in the cluster are performing some level of "useful" work at all times. If one of the servers in the high availability cluster was to fail, then clustering software would transfer that failed server's workload to a surviving server in the cluster.
If a failure were to happen, the transfer of resources would effectively double the workload on the active standby server (the lone surviving machine in a two-node 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 highly-available active/active environment. If you are database administrator (DBA) who's laying it all on the line for a tight service-level agreement (SLA), then this may or may not be the best choice (unless you size for it or use technolgoies that limit this impact).
To summarize, in DB2, an active standby server is any machine being used to service user transactions and queries during normal operational periods. When a failure of another server in the cluster occurs, the active standby server 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.
An active/active standby scenario is shown in Figure 2. In this example, there is a pair of servers that are both being used for transaction and query workloads during periods of normal operation (the solid boxes represent where the workload for each machine occurs before a failure, the cross-hatched boxes are where work would occur in the event of a failure of a respective machine). Machine 2 fails and its workload is transferred to its failover partner, machine 1. In this scenario, machine 1 is an active standby server to machine 2 (and vice-versa when you look closely at this figure - note the cross-hatched box for machine 1 on machine 2). This type of configuration is often referred to as a high-availability clustering pair and is quite common in today's IT landscape. There are many ways in which to implement an active/active high availability cluster in DB2, and depending on what you need from the solution, you can use the database partitioning feature, HADR in conjunction with a database on each server failing over to the other, using an active standby for reporting via snapshot technology or disk image copies, and more. There are even some other DB2 optimized technology offerings that provide active/active HA solutions that have advantages beyond what any database vendors out there offers today for active/active configurations - contact your IBM representative or business partner for more information.
Both machine 1 and machine 2 in Figure 2 were being used all along for their own transactional and query workload management, and when machine 2 failed, its DB2 workload was simply transferred to machine 1. Again, in this case, if you did not correctly size machine 1's resources for machine 2's failed workload responsibilities (and vice-versa), you could have performance issues after an outage occurs as a result of the transfer of workload.
Licensing Considerations for an Active Standby Machine
As a general rule of thumb, an active/active configuration should be licensed in the same way you would license each server as if they weren't clustered for high availability (there are some exceptions, and I'll cover them in a bit). The following section details the licensing considerations you should be aware of depending on how your DB2 data server is licensed.
Value Unit (VU) licensing:
For any DB2 data server that is licensed using the VU model, the entire VU rating of the active standby server (machine 1 in this example) must be licensed (unless you are using sub-capacity licensing that's available for DB2 Enterprise).
In the example shown in Figure 2, assuming each machine was running DB2 Workgroup (which is limited to servers with a maximum VU rating of 400), you would have to purchase a total of 800 VUs for this solution: 400 VUs for machine 1 and 400 VUs for machine 2.
Authorized user licensing
For any DB2 server product that is licensed by the authorized user model, you must license the active standby server by purchasing the total number of authorized users that will access it, in addition to the corresponding number of users that will access the active primary data server too (since the are both effectively primary data servers for their own applications and standby servers for each other). An authorized user 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 banking application) because the end user is well known since they must be specifically identifiable for this license. Authorized user licenses are full entitlements; there is no need for separate server licenses as with previous versions of DB2. Note the term specific identity. If you are using multiplexing or connection concentration software, these users need to be fully identified and appreciated before such software is applied to the counted connection.
You need an authorized user license for anyone accessing the data server. However, no matter how many users are accessing your data server, at the very least you need to license a DB2 Express or DB2 Workgroup data server with five minimum authorized user licenses and a DB2 Enterprise data server with 25 authorized users per 100 VUs on the server. Authorized user licenses are not transferable across work shifts (though they can be transferred for employment turnover) and they are only valid for a specific data server.
In the example shown in Figure 2, if you had 100 users that needed to access both active DB2 Workgroup data servers, you would need to purchase a total of 200 DB2 Workgroup authorized user licenses for these 100 users: 2 servers x 100 authorized users per server. Even if only 12 of these users were ever connected to either data server at one time, all 100 users would still have to be licensed for each data server (so you still need 200 of these authorized user licenses for this example). If you were using DB2 Express or DB2 Workgroup in Figure 2, and you only had 3 users accessing each data server, you would need a total of 10 DB2 Express or DB2 Workgroup authorized user licenses (2 servers x 5 authorized users) to satisfy the minimum authorized user requirements associated with these editions of DB2.
If the data server being used in Figure 2 was DB2 Enterprise, as previously mentioned, things are a little different. Continuing with the example in the previous paragraph, if you had 100 users that needed to access both active DB2 Enterprise data servers, you would need to purchase a total of 200 DB2 Enterprise authorized user licenses for these 100 users: 2 servers x 100 authorized users per server. Again, even if only 12 of these users were ever connected to either data server at one time, all 100 users would still have to be licensed for each data server (so you still need 200 DB2 Enterprise authorized user licenses for this example). If the DB2 Enterprise data servers in Figure 2 were 2 socket Intel x86-based dual core servers, the total VU rating for these servers would be 200 VUs each. If you only had 3 users accessing each data server, you would still need a total of 100 authorized users (2 servers x 200/100 VUs x 25 authorized users) to satisfy the minimum authorized user requirements associated with this edition of DB2. However, if the servers in Figure 2 were 2 socket Power5-based dual core servers, the total VU rating for each server would be 400 VUs. So with this server, if you only had 3 users accessing each data server, you would still need a total of 200 authorized users (2 servers x 400/100 VUs x 25 authorized users) to satisfy the minimum authorized user requirements associated with this edition of DB2.
As previously mentioned, DB2 Express-C does not support high-availability configurations. However, DB2 Express-C FTL does. When you license DB2 Express-C FTL in a high-availability environment you don't follow the rules outlined in this section. Since Express-C is a free data server, and the Fixed Term License (the FTL part) is the support contract that's been recently made availabile for it, there is a different way. When you license DB2 Express-C FTL in a high availability environment, you simply have to buy a support contract for each server in the cluster. No need to identify the role it places, how many users are accessing it, the value unit rating of the underlying data server, or anything else: simple!
An idle standby configuration is one in which at least one server in the high availability cluster does not have a DB2 database that is servicing user transactions or query workloads during periods of normal operation. This server has the DB2 data server software installed on it and may or may not be powered on, but it is idle in that it is not performing "useful" work. Work that is classified as "not useful" (although ironically it could be the most useful work you do) includes administrative actions that assist in failover/HA scenarios such as having a database in rollforward pending state to support log shipping, making a flash copy of a DB2 database and then performing a database backup of this copy on another server, supporting transaction-level log shipping for an HADR environment, and so on. If one of the servers in the high availability cluster fails, then the clustering software transfers the workload to the idle standby data server.
One common misconception many have about an idle standby configuration is that the idle standby machine is a waste of resource when solely dedicated to recovery operations. This is an incorrect understanding of this type of configuration. The truth is that you can leverage the idle machine for many uses (both DB2 and non-DB2 related) beyond the standby role. For example, you could create a new DB2 instance on the idle machine (depending what DB2-related work you choose to perform here, it could have licensing implications) and use it as a test machine, or perhaps offload other workloads and functions on it. In the event of a failure, you could scale back these workloads and allow the standby machine to use all of its resources to handle the load of the failed server, thereby circumventing the load considerations outlined in the active standby discussion. For example, you may have the idle standby machine rolling forward through the DB2 logs, while at the same time, it is running test scenarios in another instance (or test scenarios for non-DB2 purposes - like application testing and so on). In the event of a failure, you simply queisce the test workload and let DB2 assume the load of the failed server without consideration for throughput reduction.
Clients take all sorts of different approaches to standby machines. I recommend that you prioritize your goals and business requirements in regards to a standby machine. For example, some clients may choose to set up a log shipping environment on a standby machine. At the same time, they also want to use this same standby database for a somewhat current read-only version of the production machine — thereby spreading out cost allocations over more and more resources (accountants really like to see this). Most vendors limit this model to either/or; meaning that while you are reading the database, you cannot roll forward through the logs to keep it current (if it isn't either/or, there is a compromise with respect to how fast the rolling forward process can keep up — as in a logical standby server through a snapshot). Subsequently, leaving the database open for extended periods of time for read-only operations increases the mean time to repair in the event of a failure: the very issue this configuration is designed to avoid. My advice, if you need outstanding availability characteristics, then price and size the environment with that as the premier goal and leave it as that (no one really appreciates the resource put into a high availability solution if they haven't had to use it in a while). If you can afford a longer mean time to repair gaps, then you'll get more options with respect to the use of the standby machine (like using it for read queries): just remember, it's an inverse curve. As much as any vendor would love you to believe, the higher the availability levels you want, the more it costs. The key is to find what's right for your solution. With that said, the active/active solution I referred to earlier is very appropriate for the right application and is not affected by the issues I've mentioned for typical active/active solutions offered from other vendors.
Finally, it wouldn't be a marketing fluff-like statement to note that in many cases, licensing DB2 in an active/idle environment is cheaper (even when including the hardware) than other vendor's active/active environments. DB2 Enterprise also includes a free 2-node license of Tivoli System Automation which can provide very fast failover times (seconds when used with HADR) with relatively little complexity (the minimization of complexity part is a big thing). In addition to this, don't forget that HA features are available for all DB2 data server editions -- not just DB2 Enterprise unlike some other products in the market.
An idle standby scenario is shown in Figure 3. In this example, during periods of normal operations, machine 2 is being used for transaction and query workloads (noted as active work in the figure), while machine 1 is sitting as an idle standby for machine 2's workload, and perhaps supporting some additional functions like application development, or it could even be powered off. Machine 2 fails, and its DB2 workload is passed to its idle partner machine 1. In this scenario, it would likely be the case that if any work (of any kind) was being performed on machine 1 before the failure, it would be scaled back to handle the new workload after the failure of machine 2 (or machine 1 was originally sized to support its workload, be it DB2 or non-DB2 work, and machine 2's workload at the same time - otherwise you'll see a performance issue).
Since during periods of normal operation, only one machine is active from a DB2 perspective in Figure 3, while the other is doing something else, this configuration is often referred to as an active/idle configuration. The important concept to note here is that machine 1 wasn't doing any "meaningful" DB2 work before the outage occurred.
Figure 3. Machine 2's workload is transferred to the idle standby server, machine 1.
Again, depending on your availability requirements, workload, and so on, an idle standby may or may not be the right choice for your environment; however, don't forget why you have a high availability environment in the first place - to minimize the mean time to repair from an outage.
Licensing Considerations for an Idle Standby Machine
Value Unit (VU) Licensing:
For any DB2 data server that is licensed using the VU model, you license an idle standby server for 100 VUs no matter what kind of processing core architecture the server is based on. In other words, the fact that a server with a four dual core AMD processors equates to 400 VUs and a server with four dual core Power5 processors to 800 VUs, with an idle standby server, you just license it with 100 VUs of the corresponding DB2 software.
In the example shown in Figure 3, assuming each machine was running DB2 Workgroup (which is limited to servers with maximum VU rating of 400) you would have to purchase a total of 500 VUs for this solution: 100 VUs for the idle standby machine 1 and 400 VUs for active machine 2.
Database Partitioning Feature:
The licensing terms for idle standby machines in a partitioned database environment are for the entire scalability cluster (this feature is only available through the VU metric). For example, if you had a scalability cluster composed of four active servers (each rated at 800 VUs) and they were all configured to failover to a single idle standby server (rated at 800 VUs as well), you would need to license 3300 VUs of DB2 Enterprise software and an additional 3300 VUs of the Database Partitioning Feature: (4 active servers x 800 VUs) + 100 VUs for the idle standby for each product for the data server and for the Database Partitioning Feature Pack.
Authorized user
For any DB2 server product that is licensed by the authorized user model, you must license the idle standby server by purchasing the minimum number of authorized users for that edition in consideration of it being an idle standby server. For DB2 Express and DB2 Workgroup, since the minimum number of authorized users you must license is 5 for the physical server, an idle standby server would require five authorized user licenses. In the example above, if one DB2 Workgroup server was active and configured to participate in an active/idle cluster, and you had 100 users, you would need to purchase a total of 105 DB2 Workgroup authorized user licenses for these 100 users: 100 authorized users + 5 authorized users for the idle standby server. (Of course the minimum number of authorized user licenses for the active server needs to be met if the number of users is less than this number.)
For DB2 Enterprise, you would have to purchase 25 authorized user licenses for an idle standby server because in the VU model, you only license 100 VUs for a DB2 Enterprise idle standby server and this equates to 25 authorized users in consideration of the minimum number of DB2 Enterprise authorized users per 100 VUs. Continuing with the example illustrated in Figure 3, if you had 100 users that needed to access an active DB2 Enterprise data server that was configured in an active/idle configuration, you would need to purchase a total of 125 DB2 Enterprise authorized user licenses for these 100 users: 100 authorized users per server + 25 authorized users for the idle standby server.
If the servers in Figure 3 were two socket Intel x86-based dual core servers, the total VU rating for the active server would be 200 VUs. If you only had three users accessing the active DB2 Enterprise data server, you would still need a total of 75 authorized users for this configuration: (200/100 x 25 authorized users for the active server) + 25 authorized users for the DB2 Enterprise idle standby server. However, if the servers in Figure 3 were two socket Power5-based dual core servers, the total VU rating for the active server would be 400 VUs. If you only had three users accessing the active DB2 Enterprise data server, you would still need a total of 125 authorized users for this configuration: (400/100 x 25 authorized users for the active server) + 25 authorized users for the DB2 Enterprise idle standby server.
As previously mentioned, DB2 Express-C does not support high-availability configurations. However, DB2 Express-C FTL does. When you license DB2 Express-C FTL in a high-availability environment, you don't follow the rules outlined in this section. Since Express-C is a free data server, and the Fixed Term License (the FTL part) is the support contract that's been recently made availabile for it, there is a different way. When you license DB2 Express-C FTL in a high availability environment you simply have to buy a support contract for each server in the cluster. No need to identify the role it places, how many users are accessing it, the value unit rating of the underlying data server, or anything else: simple!
High Availability Pricing with HADR
HADR enables DB2 to ship transactions from the log buffers, as opposed to log file shipping which DB2 has done for quite some time. This technology enables a richer, more granular, and comprehensive turnkey data loss prevention environment with extended options like being able to upgrade your operating system without taking an outage. HADR comes with a set of controls that allows you to granularly control the recovery point objective (RPO) that you are willing to tolerate with your applications: one of which provides a virtually zero loss transaction environment. Wrapping all this up is a full-featured GUI that makes setting up an HADR environment a snap. An example of HADR is shown in Figure 4. below:
DB2 Enterprise includes the High Availability Disaster Recovery (HADR) technology. The HADR technology can be added to a DB2 Express or DB2 Workgroup data server by purchasing the High Availability feature pack. HADR is included with DB2 Express-C FTL (it's not available for DB2 Express-C), but its licensing follows the same pattern as previously mentioned: you just pay for the support contract for the servers involved in the cluster, no concern for value units, number of users, or feature packs.
The High Availability feature pack can be purchased for DB2 Express and DB2 Workgroup data servers using the VU metric or the authorized model previously outlined in this article. The same minimums and active or idle considerations apply when licensing feature packs as with the base DB2 data server software.
Figure 5. Examples of HADR in active/active and active/passive environments.
Since HADR is only available for the DB2 Express and DB2 Workgroup editions by purchasing the High Availability feature pack, you have to license this feature pack in addition to the base server using the same licensing scheme.
For example, if you licensed a DB2 Workgroup data server in the active/active HADR configuration shown at the top of Figure 5, and each server was rated for 400 VUs, you would need to purchase a total of 800 VUs of DB2 Workgroup and 800 VUs of the High Availability feature: (2 DB2 Workgroup servers x 400 VUs each = 800 VUs) + (2 High Availability Feature packs x 400 VUs each = 800 VUs). If you used the same servers in an active/idle configuration (as shown at the bottom of Figure 5), then you would need 500 VUs of DB2 Workgroup and 500 VUs of the High Availability feature: (1 DB2 Workgroup active server x 400 VUs each + 100 VUs for a DB2 Workgroup idle server = 500 VUs) + (1 High Availability Feature pack x 400 VUs + 100 VUs of the High Availability Feature for the idle standby = 500 VUs).
Since HADR is free with DB2 Enterprise, there are no considerations other than the proper licensing of the DB2 Enterprise software. For example, if you were using a cluster of servers that were each rated at 1000 VUs, and configured HADR for an active/active cluster (shown at the top of Figure 5), you would require 2000 VUs of DB2 Enterprise software since each server is servicing user transactions. If you configured the environment as active/idle (shown at the bottom of Figure 5), you would require 1100 VUs. When performing a software upgrade, the VU entitlements seamlessly transfer to the lone active server and therefore do not affect licensing.
Like I said, HADR is part of DB2 Express-C FTL. You don't have to buy the High Availability feature pack to get this option, like you have to with DB2 Express and DB2 Workgroup. If you want to use HADR with your DB2 Express-C FTL data server, you simply have to buy a support contract for each data server: that's it. Simple!
Paul C. Zikopoulos, BA, MBA, is an award-winning writer and speaker with the IBM Database Competitive Technology team. He has more than ten years of experience with DB2 and has written over sixty magazine articles and several books about it. Paul has co-authored the books: Information on Demand: Introduction to DB2 9 New Features, IBM DB2 9: New Features, DB2 Version 8: The Official Guide, DB2: The Complete Reference, DB2 Fundamentals Certification for Dummies, DB2 for Dummies, and A DBA's Guide to Databases on Linux. Paul is a DB2 Certified Advanced Technical Expert (DRDA and Cluster/EEE) and a DB2 Certified Solutions Expert (Business Intelligence and Database Administration). In his spare time, he enjoys all sorts of sporting activities, running with his dog Chachi, and trying to figure out the world according to Chloë - his new daughter. You can reach him at: paulz_ibm@msn.com.
This article was originally published by IBM on the Information Management developerWorks web site.
