licensing distributed db2 9.7 servers in a high availability (ha

Licensing distributed DB2 9.7 servers in a highavailability (HA) environmentSkill Level: Introductory

Paul Zikopoulos ([email protected])Director of Technical ProfessionalsIBM

Steven Astorino ([email protected])Senior Development ManagerIBM

29 Oct 2009

Updated 18 Aug 2011

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 availabilityenvironment? Don't have the time or the will to read through the announcementletters, PLETs, or your licensing sheets? Authors Paul Zikopoulos and Steve Astorinoexplain it all in plain English for the DB2 9.7 release that became generally availableon June 17th, 2009 and for later releases. [2011 June 16: The authors updated thisarticle to include information about the latest changes done in fixpacks for the DB29.7 release. --Ed.]

Customers choose DB2 as their database of choice because of its incredible time tovalue, its ability to scale and integrate across disparate environments, itsrobustness, and for the minimization of down-time (both planned and unplanned). Inthis article, we focus on the high-availability (HA) aspects of DB2, not so much froma functionality point of view (of which much has been written), but from the point ofview of licensing.

We hear lots of questions about licensing DB2 in an HA environment - configurationsthat 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

Licensing distributed DB2 9.7 servers in a high availability (HA) environment Trademarks© Copyright IBM Corporation 2009, 2011 of 24

mailto:[email protected]

mailto:[email protected]

http://www.ibm.com/developerworks/ibm/trademarks/

http://www.ibm.com/legal/copytrade.shtml

vendors price their database products in highly available environments.

Another source of confusion stems from the terms used in discussions that relate tohigh availability. For example, the term clusters. Sometimes the IT industry refers tohighly available environments as clusters. We don't like using this term by itselfanymore, as it has become somewhat overloaded as of late in that clusters can referto clustering for scalability (like the InfoSphere Warehouse database partitioningfeature - DPF - which is based on DB2) or clustering for availability (for example,using the Tivoli System Automation for Multi-platforms (SA-MP) clustering softwarethat was first introduced in DB2 9 and subsequently deeply integrated in the DB2 9.5release 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 thisarticle, when referring to the term cluster, we mean clustering for HA (unlessotherwise noted). For simplicity, we recommend you prefix the term cluster with highavailability or scalability when discussing clusters with your clients or colleagues. Ofcourse, some solutions address both scalability and high availability solutions with acluster - so just ensure you're always communicating what you're trying to do whentalking to your colleagues.

Another source of confusion arises from the terms used to describe the server thatacts as the failover server in the event of an outage. For example, this server maybe referred to as a standby or secondary server (among other names). If you'vebeen around long enough, you've likely run the gambit of terms describing thefunction 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 HAtaxonomy and licensing terms conform to the IBM SWG taxonomy and licensingterms with respect to HA pricing. For example, if you configured a DB2 9.1 HAcluster using IBM PowerHA for AIX (once known as High Availability ClusterMultiprocessing - HACMP) such that one server sat idle (and the database managerwas not started), you would have had to partially license that server. As of DB2 9.5and on, you don't have to pay a cent! Likewise, if you had DB2 9.1 installed on aserver 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'tpowered on. We've updated this article for the DB2 9.7 release and any interimchanges as a result of a fixpack to help you sort out DB2 high availability licensingrules and put you in-the-know.

Note: This article also covers the DB2 pureScale technology that was initiallyannounced 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 youare running a DB2 9.7 server and don't have plans to use DB2 pureScale, you wouldnot move to DB2 9.8.

developerWorks® ibm.com/developerWorks




Figure 1 gives a good description of the DB2 9.7 high availability (HA) taxonomy andsome 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 coldhigh availability taxonomy

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

Table 1. Mapping industry high availability terms to the DB2 9.7 licensingtermsCold Warm Hot

DB2 is installed on anotherserver intended for failoverpurposes.

Database software is installedon another server intended forfailover purposes.

Database software is installedon another server intended forfailover purposes.

The database instance is notstarted, and it will be startedonly when a failover occurs.

The database instance isstarted, and it might bereceiving updates from theprimary database for highavailability purposes only. Thereis no end-user access to thisstandby database.

At the same time that this serveris maintaining its partner highavailability scenario, it isservicing other applications as aprimary data server. There isend-user access to this standbydatabase even when no failurehas occurred.

Typically used in clusteringscenarios where HighAvailability Disaster Recovery(HADR) or log shipping is not

Typically used in a "vanilla" (noread on standby) HADR,Q-Replication, or log shippingscenario.

Typically used in twin-failoverHADR (more on that in a bit),HADR with read on standby,DB2 pureScale, or replication

ibm.com/developerWorks developerWorks®




deployed and the databasemanager isn't started, such asfor a PowerHA for AIX cluster(formerly known as HACMP).

scenarios.

Table 1 appended a general rule of thumb below each category; however, afterreading this article, it will hopefully be clear. Quite simply, how you license a DB2server in an HA environment depends on your answers to these several keyquestions:

What edition of DB2 do you have installed?Is it: DB2 Express-C, DB2 Express, DB2 Workgroup, DB2 Enterprise, or DB2Advanced Enterprise? For example, a DB2 Express server with a SERVERlicense (introduced when DB2 9.7 became generally available) doesn't havethe 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 DB2Express-C in any kind of HA configuration - if you need HA you minimally needDB2 Express. (Note that the DB2 Express - C FTL was available only in theDB2 9.5 release and is no longer available in DB2 9.7. It is now available asDB2 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 andquery work? Is the DB2 instance on this server started? Perhaps the instanceis performing some form of work, but only to help prime a recovery in the eventof a failure; for example, in an HADR scenario. Are you managing a DB2pureScale cluster? Quite simply, what the standby server is doing wheneverything is running just fine has pretty much everything to do with how DB2on that server needs to be licensed.

How did you license your DB2 server that you want to ensure is highlyavailable?

For example, if you licensed a DB2 Express server using the SERVER licenseintroduced in DB2 9.7, you have to buy an additional SERVER license for thestandby server no matter what kind of operational state it's in: hot, warm, orcold. 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'tneed a license at all for a cold standby machine. If you're DB2 Express serverwas licensed using the Processor Value Unit (PVU) model, you'd license awarm standby server for 100 PVUs (no matter which processor architecture theserver is using) and wouldn't even need a licensed for a cold standby machineeither.

If you're looking for an overview of all the distributed DB2 9 servers and how tolicense them, refer to "Which distributed edition of DB2 9.7 is right for you?". Forcomparisons of the features, functions, and benefits between the different DB2



http://www.ibm.com/developerworks/data/library/techarticle/dm-0611zikopoulos2/

http://www.ibm.com/developerworks/data/library/techarticle/dm-0909db2whichedition/



server editions, read "Compare the distributed DB2 9.7 data servers".

Since the DB2 8.2 release, there have been a number of licensing enhancementsthat have significantly lowered the cost of HA associated with your DB2 servers. Forexample, in DB2 8.2, if you wanted to license DB2 Workgroup with HADR you had topurchase the High Availability Feature Pack, and license this feature pack on bothservers. In DB2 9, this changed: you no longer had to license this feature pack onthe standby server. In DB2 9.5, IBM made the High Availability Feature Pack free forDB2 Workgroup servers. Quite simply, release after release, IBM has lowered thecost of your DB2-based availability environments because of the following changes:

• When a single server is acting as a warm standby for multiple productionservers, you only have to license the warm standby server once (as ofDB2 8.2). For example, if you licensed a hot DB2 server for an unlimitednumber of users, the warm standby server would require 100 PVUs. If 5different 400 PVU-rated servers were running DB2 Workgroup, and eachserver 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 + 100PVUs for the standby server) as opposed to 2500 PVUs [(5 servers x 400PVUs) + (5 servers x 100 PVUs)].

• You no longer have to license feature packs on a server that is acting asa warm or cold standby server (as of DB2 9). For example, if you licensedthe Storage Optimization Feature Pack (which provides compression forXML data, tables, indexes, temporary tables, and more) for your DB2Enterprise server and configured the database to participate in an HADRcluster, you would need to purchase only 100 PVUs of DB2 Enterprise onthe standby server. No extra licensing would be incurred for using theStorage Optimization Feature Pack.

• HADR is included in DB2 Workgroup at no extra charge (as of DB2 9); ifyou look around the competitive landscape there is no other vendor thatoffers the same kind of functionality (there are no restrictions for theHADR technology on DB2 Workgroup) for any SMB-targeted server.

• You get free clustering software for virtually any edition (with DB2Express you need to use an FTL or SERVER license, or you need to buya feature pack) - Tivoli System Automation for Multi-platforms (TivoliSA-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). Infact, some vendors claim some sort of advantage by offering 10 days offailover use for an HA solution; however, with DB2, it's really unlimited forthe same kind of clusters. What's more, you get the clustering software forfree! In fact, the Tivoli SA-MP clustering software is deeply integrated intoDB2 (as of DB2 9.5) and includes rich management interfaces that slashthe TCO of an HA cluster.



http://www.ibm.com/developerworks/data/library/techarticle/dm-0909db2compare/



• You can configure two DB2 Express servers in an HADR cluster withouthaving to purchase the High Availability Feature Pack if you license yourDB2 Express servers using either the Fixed Term License (FTL) orSERVER license (both licensing options were introduced when DB2 9.7became generally available).

Note: In this article we refer to licensing a server; however, all DB2 editions supportsub-capacity licensing where you solely license the capacity that the DB2 server isusing. If we use a phrase such as license the PVU rating of the server, you can takethat to mean the PVU rating of a VMWare session or an LPAR if you're using thesevirtualization technologies. There are some prerequisites to this kind of licensing thatyou should be aware of, so ensure you know all the details before deploying DB2 inthis kind of environment.

As you can see, there have been a lot of changes to flatten the TCO associated withDB2 HA clusters both from a licensing and administrative perspective; that's prettyrefreshing considering the kind of economy we are in. The best place to start adiscussion of the effects of HA clusters on DB2 9.7 licensing is with examples thatcorrelate to the DB2 HA taxonomy. As previously mentioned, DB2 9.7 defines threetypes of standby servers: hot, warm, and cold.

Hot standby

A hot standby configuration is one in which all servers have operational DB2databases that service user transactions and queries. This configuration is called ahot/hot cluster (though it's sometimes called an active/active configuration since allthe machines in the cluster are performing some level of business production workat all times). If one of the servers in the HA cluster were to fail, then clusteringsoftware would redistribute the failed server's workload to one or more survivingservers in the HA cluster. This environment could be characterized by a singleapplication or one where each server backs the other up, but also has its ownservice level agreement (SLA) it has to adhere to.

If a failure were to happen on one of the servers, the transfer of resources couldeffectively double (in a two node cluster) the workload on the hot standby server (forexample, the lone surviving machine in a two-node HADR cluster) because it nowhas to handle its original workload plus the failed server's workload. This issomething that you need to consider when setting up any HA environment and notleveraging advanced clustering topologies such as DB2 pureScale. If you are adatabase administrator (DBA) who's laying it all on the line for a tight SLA, you needto ensure you properly vet your HA topology and the choice of the HA solution youare using.

To summarize, in DB2, a hot standby server is any machine being used to serviceuser transactions and queries during normal operational periods, yet acts as a



http://www-01.ibm.com/software/lotus/passportadvantage/Counting_Software_licenses_using_specific_virtualization_technologies.html



standby for another server that is also used to service user transactions duringnormal operational periods too. When a failure of the server in the cluster occurs, thehot standby server takes on the load of the failed server machine in addition to thework that it was performing during normal operations. Because the active standbymachine is still used for user transactions and query, even if no failure occurs, itmust be fully licensed. For example, imagine having two databases on two separatemachines, one running an enterprise resource planning (ERP) packaged applicationand the other running a supply chain management (SCM) packaged application. Ifthe SCM database was to fail, the machine running the ERP workload would have toservice all the SCM users too. A scenario illustrating a two node hot standby HAcluster is shown in Figure 2.

Figure 2. Machine 1 is a hot standby for machine 2 and machine 2 is a hotstandby for machine 1. Machine 2's workload fails over to machine 1 in theevent of a failure and vice versa.

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 representwhere the workload for each machine occurs before a failure, the cross-hatchedboxes 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 failoverpartner, machine 1. Machine 1 is a hot standby server to machine 2 (and vice-versawhen you look closely at this figure - note the cross-hatched box for machine 1 onmachine 2). This type of configuration is often referred to as a high-availabilityclustering pair, twin failover pair, hot/hot pair, or active/active pair and is common intoday's IT landscape. There are many ways in which to implement a hot/hot highavailability cluster in DB2, and depending on what you need from the solution, youcan use PowerHA for AIX, HADR in conjunction with a database on each serverfailing 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, orthe pinnacle of scalability and availability combined: leverage the DB2 pureScaletechnology.

Again, both machine 1 and machine 2 in Figure 2 were being used all along forproduction workloads; when machine 2 failed, its DB2 workload was simplytransferred 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

In the previous figure you can see that Server A hosts a production database calledDatabase 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 wellas 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 productionwork on Database A and Database B respectively and therefore this is considered ahot/hot configuration and both servers must be fully licensed.

Figure 4 shows an example of an HADR environment that is using the Read onStandby 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

In Figure 4 you can see that clients can read and write to the Primary server (makingit hot); but, since they are reading on the Secondary server it is also hot andtherefore both servers must be fully licensed. Quite simply, if you read data from aserver 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

In Figure 5, you only license DB2 and the DB2 pureScale Feature Pack on theMembers (the machines processing transactions). The Cluster Caching Facility (CF)servers (which as you can see are typically fully duplexed) do not require anylicenses whatsoever. In this example, since transactions are being seamlessly loadbalanced 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 sameway you would license each server as if they weren't clustered for high availability atall.

As of DB2 9.7, there are five different licensing methods (some are only availablewith specific DB2 editions): SERVER, Fixed Term License (FTL), SOCKET,Authorized User (AU), and Processor Value Unit (PVU). The following details theHA-licensing considerations you should be aware for each respective license in ahot/hot HA cluster.

SERVER licenseA SERVER license is new to DB2 9.7 and is only available for DB2 Expressservers. When licensing a DB2 Express server using a SERVER license, yousimply buy a license for each server in the cluster no matter what type ofstandby (hot, warm, or cold) it is. Quite simply, there's no need to identify theactivity level of a DB2 Express server licensed using a SERVER license whenit comes to HA licensing. There are no user minimums, and you don't have tofigure 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 bothmachines are hot); you will see in a warm standby configuration, the SERVERlicensing requirements are different compared to other DB2 licenses.In addition, if you wanted to create an HADR cluster using a DB2 Expressserver in DB2 9.5, you had to buy the DB2 High Availability Feature Pack to getthis feature along with other HA-related features. In DB2 9.7, the DB2 ExpressSERVER license actually comes with all the features in the High AvailabilityFeature Pack (including HADR) for free; however you do buy this feature packif you want HADR (or other features) with a DB2 Express server licensed viathe alternative PVU or AU licenses. For this reason, and more, we recommendusing this (or an FTL) license for any DB2 Express servers.

Fixed Term License (FTL) licenseWhile FTL license is new to DB2 Express 9.7, it has the same pricingmethodology as the old DB2 Express-C FTL 9.5 license (which is no longeravailable). This license gives you access to all the features in DB2 Express(unlike its predecessor). A DB2 Express FTL license gives you access to theDB2 Express software for a period of one year - it's a term license as opposedto a perpetual license as provided with other DB2 edition licenses. Whenlicensing a DB2 Express server using an FTL license, you simply buy an FTLlicense for each server in the cluster - just like the DB2 Express SERVERlicenses - no matter what type of standby (hot, warm, or cold) it is. Quitesimply, there's no need to identify the activity level of a DB2 Express server




http://www.ibm.com/software/data/db2/9/editions_features_ha.html



licensed using an FTL license when it comes to HA licensing. There are nouser minimums, and you don't have to figure out the PVU rating of theunderlying server or anything else: simple! While in a hot/hot configuration thisrule has no effect on licensing (since both machines are hot), you will see in awarm standby configuration, the licensing requirements are different comparedto other DB2 editions.A DB2 Express server licensed with an FTL license gives you access to all thefeatures in the DB2 High Availability Feature Pack, including HADR. (Note,however, that you have to buy this feature pack to enable HADR, among otherhigh 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 licenseA SOCKET license is new to DB2 9.7 and is only available for DB2 Workgroupservers. When licensing a DB2 Workgroup server using a SOCKET license,you simply license the same number of sockets as on the primary for eachserver since this is a hot/hot configuration and all servers are fully utilized forregular operations.For example, if you had a 4-way dual core IBM POWER7 server, you wouldbuy 4 DB2 Workgroup SOCKET licenses. Incidentally, this server would berated at 960 PVUs and you would still just buy 4 DB2 Workgroup SOCKETlicenses. For a hot/hot configuration, you would require 8 DB2 WorkgroupSOCKET licenses: 4 sockets for the hot primary server and 4 sockets for thehot standby server. Whenever you license a DB2 Workgroup server, westrongly recommend using this license because of the additional CPU capacityit offers your environment.

Processor Value Unit (PVU) licenseAny DB2 server can be licensed using the PVU model. In an active/activeconfiguration, the entire PVU rating of the hot standby server (machine 1 in ourworking example) must be additionally licensed. Of course, you would use thissame approach to license your DB2 server even if it weren't part of an HAcluster since it is servicing production work anyway, so there shouldn't be anysurprises here.If the server in Figure 3 utilized just four cores of a POWER7 server, andassuming each machine was running a DB2 Workgroup (which is limited withthis license to servers with a maximum 480 PVU rating of as of 2Q08), youwould have to purchase a total of 960 PVUs for this solution: 480 PVUs formachine 1 and 480 PVUs for machine 2.

Authorized User (AU) licenseFor 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 iton the hot primary, in addition to the corresponding number of users that willaccess the hot standby server too (since they are both effectively hot serversfor their own applications and standby servers for each other).An AU is a single individual (in some cases, it can be an application orappliance so long as it doesn't act on behalf of other users) with a specificidentity that resides inside or outside your company. These licenses can beused over the Internet as well (like an online trading application) because theend user is well known since they must be specifically identifiable for thislicense. AU licenses are full entitlements; there is no need for separate serverlicenses as was the case back in DB2 8 where you bought user entitlementsalong with a base server license. If you're using multiplexing or connectionconcentration software, these users need to be fully identified and enumeratedfor before such technologies are applied to the counted connection.

You need an AU license for anyone accessing the server. However, no matterhow many users are accessing your server, there are some edition-dependentminimums that you need to account for. The DB2 Express or DB2 Workgroupeditions require a minimum of five AU licenses. DB2 Enterprise requires aminimum 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, aserver with 480 PVUs would at minimum require 125 AU licenses because youround up the PVU count for user minimum determination. Of course, if you had150 users, then you would need to license the server beyond the minimumcount to the actual number of uses; in this case 150 AUs. AU licenses are nottransferable across work shifts (though they can be transferred for employmentturnover), and they are only valid for a specific server. Of course since Figure 3is an example of a hot/hot configuration, these rules are moot since they haveto be licensed like independent servers anyway.

In the example shown in Figure 3, if you had 100 users that needed to accessboth hot DB2 Workgroup servers, you would need to purchase a total of 200DB2 Workgroup AU licenses for these 100 users: 2 servers x 100 AUs perserver. Even if only 12 of these users were ever connected to either server atany one time, all 100 users would still have to be licensed for each server (soyou still need 200 AU licenses for this example). If you were using DB2Express or DB2 Workgroup in Figure 3, and you only had 3 users in yourcompany, you would need a total of 10 DB2 Express or DB2 Workgroup AUlicenses (2 servers x 5 minimum AUs) to satisfy the minimum AU requirementsassociated with these editions of DB2.

If the servers being used in Figure 3 were DB2 Enterprise, as previouslymentioned, things are a little different: let's continue with the example where weassume that each server is a 4-core POWER7-based server rated at 480PVUs. If you had 100 users that needed to access both hot DB2 Enterpriseservers, 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 per100 PVU minimum for each DB2 Enterprise server. Again, even if only 12 ofthese users were ever connected to either DB2 server at one time, all 125users 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 clusterdoes not have a DB2 database that is servicing user transactions or queryworkloads during periods of normal operation. It is warm in the sense that the serveris not performing "useful" work. Work that is classified as "not useful" (althoughironically it could be the most useful work your standby server ever does) includesadministrative actions that assist in failover scenarios such as having a database inrollforward pending state to support log shipping, supporting transaction-level logshipping for an HADR environment, and so on. If one of the servers in the HA clusterfails, then the workload is redistributed to the warm standby server.

One common misconception many have about a warm standby configuration is thata warm standby machine is a waste of resource when solely dedicated to recoveryoperations. This is an incorrect understanding of this type of configuration. The truthis that you can leverage a warm standby machine for many uses (both DB2 andnon-DB2 related) beyond the standby role. For example, you could create aseparate DB2 instance on the warm standby machine (depending what DB2-relatedwork you choose to perform here, it could have licensing implications) and use it asa test machine, or perhaps offload other workloads and functions on it. In the eventof a failure, you could scale back these workloads (or resources allocated to avirtualized partition where they run) and allow the warm standby machine to use allof the server's resources to handle the load of the failed server therebycircumventing the load considerations outlined in the hot/hot standby discussion inthe last section.

A warm standby scenario is shown in Figure 6. In this figure, a "vanilla" (the Read onStandby capability is not being used) HADR configuration has been created for aproduction OLTP environment. In this example, during periods of normal operations,machine 2 is being used for transaction and query workloads (noted as Active Workin 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. Inthis scenario, it would likely be the case that if any work (of any kind) was beingperformed on machine 1 before the failure, it would be scaled back to handle thenew workload after the failure of machine 2 (or machine 1 was originally sized tosupport its workload and machine 2's workload at the same time - otherwise you'llsee a performance issue).

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 one machine is hot from a DB2perspective in Figure 6 while the other is doing some warm activity like priming anHADR failover partner, this configuration is often referred to as hot/warm (oractive/idle, in some circles). The important concept to note here is that machine 1wasn't doing any "meaningful" DB2 work before the outage occurred. Of course inan HADR Read on Standby or DB2 pureScale scenario, the 'standby' (which isn'treally a standby because it is hot) is doing meaningful work and therefore none ofthese technologies are associated with a warm or cold standby rating.

Clients take all sorts of different approaches to standby machines. We recommendthat you prioritize your goals and business requirements with regards to a standbymachine. For example, some clients may choose to set up an HA environment on astandby machine and at the same time use the standby database for a somewhatcurrent 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.7Fix Pack 1 or later. You should be aware that many vendors limit this model toeither/or; meaning that while you are reading the database, you can't roll forwardthrough the logs to keep it current (if it isn't either/or, there is a compromise withrespect to how fast the redo processing can run among other considerations).Subsequently, leaving the database open for extended periods of read-onlyoperations in such environments increases the mean time to repair (MTTR) in theevent of a failure: the very issue this configuration is designed to avoid. Anotherexample is with reading standby OLTP databases. If you think about it, an OLTPdatabase is designed such that there are minimal indexes. If you start runningreporting-like workloads on its standby server, the standby is likely to experience anumber 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 resourcessuch that it may have trouble keeping the databases synchronized.

Depending on your availability requirements, workload, and so on, a warm standbymay or may not be the right choice for your environment; however, when planningfor the kind of standby you want to support, never forget why you have an HAenvironment in the first place - to minimize the MTTR from an outage. The point isthat DB2 has options for hot/hot too (including some HADR read on standbytechnology that wasn't part of DB2 9.7 when it first became available but wasintroduced in DB2 9.7 Fix Pack 1) and the all new DB2 pureScale. If you read off astandby server, for example, in an HADR configuration, that server is instantlyconsidered hot. Bottom line, the notion that a warm standby server (from a DB2perspective) is just sitting around wasting resources is an often very misunderstoodconcept when you really look at it - but with DB2, the choice is up to you; justremember 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 availablewith specific DB2 editions): SERVER, Fixed Term License (FTL), SOCKET,Authorized User (AU), and Processor Value Unit (PVU). The following details theHA-licensing considerations you should be aware of for each respective license.

SERVER licenseA SERVER license is new to DB2 9.7 and is only available for DB2 Expressservers. When licensing a DB2 Express server using a SERVER license, yousimply buy a license for each server in the cluster no matter what type ofstandby (hot, warm, or cold) it is. Quite simply, there's no need to identify theactivity level of a DB2 Express server licensed using a SERVER license whenit comes to HA licensing. There are no user minimums, and you don't have tofigure 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 Expressserver in DB2 9.5, you had to buy the DB2 High Availability Feature Pack to getthis 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 AvailabilityFeature Pack (including HADR) for free; however you do buy this feature packif you want HADR (or other features) with a DB2 Express server licensed viathe alternative PVU or AU licenses. For this reason, and more, we recommendusing 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 DB2Express server. If you wanted to create an HADR cluster using a DB2 Expressserver in DB2 9.5, you had to buy the DB2 High Availability Feature Pack to getthis feature along with other HA-related features. In DB2 9.7, the DB2 ExpressSERVER license actually comes with all the features included in the HighAvailability Feature Pack (including HADR) for free. You have to buy thisfeature pack if you want to use HADR (or a number of other advancedHA-related DB2 technologies) with a DB2 Express server licensed via a PVU orAU licenses.

Fixed Term License (FTL) licenseWhile FTL license is new to DB2 Express 9.7; it has the same pricingmethodology as the old DB2 Express-C FTL 9.5 license (which is no longeravailable). This license gives you access to all the features in DB2 Express(unlike its predecessor). A DB2 Express FTL license gives you access to theDB2 Express software for a period of one year - it's a term license as opposedto a perpetual license as provided with other DB2 edition licenses. Whenlicensing a DB2 Express server using an FTL license, you simply buy an FTLlicense for each server in the cluster - just like the DB2 Express SERVERlicenses - no matter what type of standby (hot, warm, or cold) it is. Quitesimply, there's no need to identify the activity level of a DB2 Express serverlicensed using an FTL license when it comes to HA licensing. There are nouser minimums, and you don't have to figure out the PVU rating of theunderlying server or anything else: simple!In a hot/warm HA cluster, you'd actually buy an FTL license for each DB2Express server. If you wanted to create an HADR cluster using a DB2 Expressserver in DB2 9.5, you had to buy the DB2 High Availability Feature Pack to getthis feature along with other HA-related features. In DB2 9.7, the DB2 ExpressFTL license actually comes with all the components of the High AvailabilityFeature Pack (including HADR) for free; in fact, a DB2 Express FTL licenseentitles you to all the features available in the DB2 High Availability FeaturePack! You have to buy this Feature Pack if you want HADR (or a number ofother advanced HA-related DB2 technologies) with a DB2 Express serverlicensed via the PVU or AU licenses. For this reason, and more, we stronglyrecommend using this (or a SERVER) license for any DB2 Express servers.

SOCKET licenseA 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 SOCKETlicense, you simple buy a license for the number of sockets that DB2 will useon the primary server. If you had a 4-way dual core IBM POWER7 server, youwould buy 4 DB2 Workgroup SOCKET licenses. For the warm standby server,you simply purchase one additional SOCKET license, no matter what. In theFigure 6 example, you would need 4 sockets (hot machine) + 1 socket (warmstandby) = 5 sockets.Incidentally, the primary server would be rated at 960 PVUs and you still wouldjust buy 4 DB2 Workgroup SOCKET licenses. Whenever you license a DB2Workgroup server, we strongly recommend using this license because of theadditional CPU capacity it offers your environment.

Processor Value Unit (PVU) licenseFor any DB2 server that is licensed using the PVU model, you license a warmstandby server for 100 PVUs no matter what kind of processing corearchitecture the server is based on. In other words, if a server with four quadcore AMD processors equates to 800 PVUs and a server with two quad corePOWER7 processors to 960 PVUs, with a warm standby server, you justlicense it with 100 PVUs of the corresponding DB2 edition.For example, if the server in Figure 6 utilized just four cores of a POWER7server, and assuming each machine was running DB2 Workgroup (which is nolonger 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 PVUsfor machine 2 + 100 PVUs for warm standby machine 1).NOTE: As of June 2011, the 480-PVU restriction has been removed. Thismeans you can now install and use DB2 Workgroup on physical or virtualservers with more than 480 PVUs, provided you have appropriately licensed allthe PVUs that DB2 Workgroup has access to, up to 16 cores. If the physical orvirtual server has more than 16 cores, you still only pay for 16 cores becausethat's all DB2 will use. This applies to 9.5 and 9.7.

Authorized User (AU) licenseFor any DB2 server that is licensed by the AU model, you must license thewarm standby server by purchasing the minimum number of AUs for thatedition in consideration of it being a warm standby server. For DB2 Expressand DB2 Workgroup, because the minimum number of AUs you must license is5 for any installation, a warm standby server would require 5 AU licenses. InFigure 6, if one DB2 Workgroup server was hot and was configured toparticipate in a hot/warm HADR cluster, and you had 100 users, you wouldneed to purchase a total of 105 DB2 Workgroup AU licenses for these 100users: 100 AUs + 5 AUs for the warm standby server. (Of course, the minimumnumber of AU licenses for the hot server needs to be met if the number ofusers 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 25for every 100 PVUs (as detailed earlier in this article). Since you have tominimally licensed 100 PVUs for a warm standby in the PVU model with a DB2Enterprise server, you convert the minimum 100 PVUs to 25 AUs and thatbecomes the minimum number of AUs needed for a DB2 Enterprise warmstandby server that is licensed using the AU model. Let us clarify with the useof an example using Figure 6. If the servers in Figure 6 were two socket Intelx86-based dual core servers, the total PVU rating for the hot server would be200 PVUs. If you only had three users accessing the hot DB2 Enterpriseserver, you would still need a total of 75 AUs for this configuration: (200/100=2x 25 AUs) for the hot server plus 25 AUs for the DB2 Enterprise warm standbyserver. However, if the servers in Figure 6 were two socket POWER7 dual coreservers (so there are a total of 4 cores on this server), the total PVU rating forthe hot server would be 480 PVUs. If you only had three users accessing thehot DB2 Enterprise server, you would now need a total of 150 AUs users forthis 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 doesnot have a DB2 database that is servicing user transactions or query workloadsduring periods of normal operation and it isn't performing any administrative actionsthat assist in failover scenarios such as having a database in rollforward pendingstate to support HADR; in fact, a cold server may not even be powered on. A coldstandby 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 fortransaction and query workloads (noted as Active Work in the figure), while machine1 doesn't have a started DB2 instance. Perhaps it's even the case that DB2 isinstalled on a machine and it's turned off; in the event of a failure, machine 1 isbooted up, recovered to a certain point in time from a backup image, and opened upfor user transactions. It could also be the case that machine 1 is configured to bepart of a Tivoli SA-MP cluster (among other HA clustering options, includingPowerHA for AIX), but the database instance isn't started. As you can imagine, acold standby configuration isn't much of an availability solution in that the MTTR istypically 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 costof this solution gets really attractive in DB2 9.5 and beyond for the reasons outlinedearlier 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 obviouslyno licensing considerations. A good rule of thumb to determine if a standby machinecan be classified as cold is to see if the DB2 instance is started; however, there aresome exceptions. For example, if you took a snapshot image off of a productionserver and started the DB2 standby server for the sole purpose of performing abackup 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 DB2save you money and who isn't looking for that in this tight economy? Let's assumeyou were licensing a DB2 9 Workgroup server along with the pureXML Feature Packfor an XML-based application with some HA requirements. In DB2 9, you wouldhave to fully license the hot server (as expected) for both DB2 and the pureXMLFeature Pack; in addition, the cold server would have to be licensed for 100 PVUs ofDB2 Workgroup and 100 PVUs of the pureXML Feature Pack. In DB2 9.7, youwould just buy DB2 Workgroup licenses for the hot server. The pureXML feature isfree in all DB2 editions (as of February 9th, 2009) and a cold standby server requiresno licensing. Now add in the fact that you can license DB2 Workgroup with aSOCKET license, and you've doubled the capacity of your highly availableXML-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 recommendclients create multi-tier classifications for applications that require availability; forexample, Bronze, Silver, and Gold ratings. Perhaps it's the case that anything ratedBronze would leverage a cold standby and a DB2 integrated cluster; while a Silverrated solution would leverage DB2 HADR technology; and finally, a Gold ratedsolution would be a hot standby configuration such as DB2 pureScale. We've puttogether a cheat sheet of some of the possible HA solutions and their respectivecategorization in Table 2.

Table 2. Approaching your HA requirements with a tiered solution and thecorresponding DB2 technologies availableBronze Silver Gold

DB2 Integrated Clustering HADR DB2 pureScale

• Hot/cold

• Basic availabilitysolution

• Free in most cases

• Provides failover,typically in lessthan 5 minutes

• Hot/warm (optionalhot with read onstandby)

• Provides very fastfailover, typically inless than 1 minute

• Easy to setup withturnkey availability

• Minimal licensingon the standbyserver

• Potential zero dataloss option

• Hot/hot

• Online failover

• Transactions onsurviving nodes arenot impacted

• Provides thefastest failover,typically in lessthan 30 seconds

• Online scaleoutcapability toaddress workloadspikes





We'd like to note at this point that it isn't always the case that everything needs to bea Gold-level solution. Everyone thinks they need 24-hours/day by 7-days/weekavailability for all applications, but in our vast consulting experience, that's just notthe case. For example, one client had a mission critical application that need 24x7availability, but their other applications could take up to a two day outage. In thesecases, would it make sense to treat them all the same from an availabilityperspective? If you had an unlimited budget, perhaps. Choose the right availabilitysolution that matches the service level agreement (SLA) that's backing your job: highavailability in a linear cost curve. Beyond the software, the more HA you want, themore 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 definitelyleverage the right technology for the right HA requirements.

Although outside the scope of this article, for completeness, we thought we wouldinclude a cheat seat for HA's "cousin" Disaster Recovery (DR) in Table 3. (The sameconsiderations you use to determine appropriate licensing for HA applies to DR):

Table 3. Approaching your DR requirements with a tiered solution and thecorresponding DB2 technologies availableBronze Silver Gold

Q Replication HADR Physical Replication HADR Logical Replication

• Hot/hot

• Unrestrictedaccess to the targetdatabase

• Supports differentversions of DB2 onsource and target

• Supportssub-setting of data

• Multiple targetsupport

• Online failover

• Can replicate to adifferent topology

• Async only

• Can be complex toset up

• No DDL support

• Hot/warm

• Zero data lossoption

• Provides very fastfailover, typically inunder 1 minute

• Easy to set up withturnkey availability

• DDL and DMLreplication support

• Limited use of thestandby

• Single targetsupport only

• Full databasereplication only

• Hot/hot

• Zero data lossoption

• Online failover

• Provides thefastest failover,typically in lessthan 30 seconds

• Online scaleoutcapability toaddress workloadspikes

• Unrestrictedaccess to the target

• Can be configuredwith time delayapply

• Multiple targetsupport

• DDL and DMLreplication support





• Rolling versionupgrade capability

• Can replicate to adifferent topology





Resources

Learn

• "Compare the distributed DB2 9.7 servers" (developerWorks, Sep 2009): In aside-by-side comparison table, author Paul Zikopoulos makes it simple tounderstand the basic licensing rules, functions, and feature differences betweenthe members of the distributed DB2 9.7 server family.

• "Which distributed edition of DB2 9.7 is right for you?" (developerWorks, Sep2009): Learn the details on what makes each edition of DB2 9.7 unique. Theauthor lays out the specifications for each edition, outlines licensingconsiderations, historical changes from DB2 9, and describes some interestingthings customers are doing with each edition of DB2.

• "DB2 and IBM Processor Value Unit (PVU) pricing" (developerWorks, Sep2009): This article describes how to license DB2 using the new Value Unitmetric as well as a number of helpful everyday scenarios.

• Visit the developerWorks resource page for DB2 for Linux, UNIX, and Windowsto read articles and tutorials and connect to other resources to expand yourDB2 skills.

• Learn about DB2 Express-C, the no-charge version of DB2 Express Edition forthe community.

• developerWorks Information Management: Learn more about IBM InformationManagement 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 versionof DB2 Express Edition for the community that offers the same core datafeatures as DB2 Express Edition and provides a solid base to build and deployapplications.

Discuss

• Participate in the discussion forum for this content.

• developerWorks blogs: Get involved in the developerWorks community.

About the authors

Paul Zikopoulos



http://www.ibm.com/developerworks/data/library/techarticle/dm-0909db2compare/

http://www.ibm.com/developerworks/data/library/techarticle/dm-0909db2whichedition/index.html

http://www.ibm.com/developerworks/data/library/techarticle/dm-0611zikopoulos2/index.html

http://www.ibm.com/developerworks/data/products/db2luw

http://www.ibm.com/software/data/db2/udb/db2express/

http://www.ibm.com/developerworks/data/

http://www.ibm.com/developerworks/downloads/im/udb/index.html

http://www.ibm.com/developerworks/downloads/im/udbexp/index.html

http://www.ibm.com/developerworks/forums/forum.jspa?forumID=842

http://www.ibm.com/developerworks/blogs/



Paul C. Zikopoulos, B.A., M.B.A., is the Director of TechnicalProfessionals for IBM Software Group's $5B Information Managementdivision. In this role, he has executive responsibilities for the vitality ofits client facing technical professional community (ensuring they areamong the most technically skilled personnel in the marketplace),driving revenue and profit attainment goals, accelerating the salespipeline, and leading the competitive charge against its competitors. Inhis previous role, Paul led the IM DB2 Evangelist and Competitiveprograms for IBM. Paul is an award-winning writer and speaker withmore than 18 years of experience in Information Management: fromGovernance to Implementation to Business Value Assessments. Paulhas written more than 300 magazine articles and 14 books includingDB2 pureScale, Database Cost Saving Features, information onDemand, DB2 for Dummies, and many more. Paul is an IBM CertifiedAdvanced Technical Expert and an IBM Certified Solutions Expert. Inhis spare time, he enjoys all sorts of sporting activities, includingrunning with his dog Chachi, avoiding punches in his Masters of MartialArts training, and trying to figure out the world according to Chloë, hisdaughter.

Steven AstorinoSteven Astorino, BSc - Computer Science, is a Senior Manager of DB2Development, overseeing Information Development, User Experience,and DB2 Install Development. He has many years of experience withdatabases, including DB2 and real time database replication. Stevenbegan his career as a developer, and he has held a wide range of rolesfrom software development and quality assurance to informationdevelopment and user experience. Early in his career, Steven spentseveral years working with network testing technologies for the telecomindustry, and he played a key role in providing VoIP testing solutions.High quality, efficiency, and customer focus are some of his key goalsto ensure outstanding customer satisfaction.





licensing distributed db2 9.7 servers in a high availability (ha

Documents