 | Level: Introductory Paul Zikopoulos (paulz_ibm@msn.com), Senior Database Specialist, IBM
Deb Jenson (dejenson@us.ibm.com), Product Manager, IBM
30 Nov 2006
Updated 15 May 2008 In the third quarter of 2006, IBM software group (SWG) announced a replacement for their processor-based pricing and introduced the concept of Processor Value Unit (VU) as a way to determine the processor rating of a server. Prior to this announcement, customers simply added up the number of processing cores they planned to deploy DB2® on, and multiplied by the price. However, the introduction of multi-core processors, and the rate at which this market is changing, led to confusion and had both clients and vendors asking "What is a processor"? This article describes how to license DB2 for Linux®, UNIX®, and Windows® using the new PVU metric and includes a number of helpful everyday example.
Introduction
In order to understand PVU pricing it helps to have a little background on DB2 pricing in general. Essentially, DB2 provides two licensing metrics:
- One based on a user approach, called the authorized user model
- Another based on the processor rating of the server, called the PVU pricing model
The authorized-user model, as its name would suggest, requires you to count the number of users that will be using DB2 and multiply that number by a per-user price to determine your license costs. This pricing model is especially attractive to companies that have few users in relation to having large databases or for environments, those companies that implement application software such as SAP which is also licensed in this manner, and more. In DB2 9, authorized-user pricing is available for the DB2 Express, DB2 Workgroup, and DB2 Enterprise editions, as well as the special development focused Database Enterprise Developer Edition.
On the other hand, per-processor pricing is a pricing metric where each processor running the DB2 software is counted and multiplied by the DB2 per-processor price to determine the eventual license costs. This model is attractive to companies that have large numbers of users in relation to database size as well as environments where end users are not easily counted (like a Web-based application), because this licensing paradigm removes the need to mainfest or "know" your users (from a licensing perspective). Another attractive feature with per-processor pricing is as new employees are hired, each new employee does not require a license entitlement. This leads to a reduction in license administration costs because you don't have to maintain a manifest of your users.
This article focuses solely on per-processor pricing and how PVUs change the way you
calculate your license costs. For complete details on the features, licensing restrictions, and extensibility options available with the distributed editions of the DB2 family, refer to "Which DB2 9 edition is right for you?."
How we got here
Prior to the introduction of dual-core chips, there wasn't much question what a processor was since all processors were single-core processors. This made processor-based licensing simple to understand and manage: if you had a four processor system, then you needed four software license entitlements.
In October 2000, IBM introduced a new line of highly scalable dual-core microprocessors with their Power processor (the Power4 series was the first generation of dual-core processors released by IBM, this generation was replaced by Power5, and has since been replaced with POWER6). Today, these chips are available with the POWER (formerly known as System i and System p) servers from IBM. These POWER chips changed the technology landscape by implementing two cores (the ability to have two separate circuitry units executing compute instructions) on a single silicon chip (something that plugs into your computer's motherboard). An example of a dual-core processor is shown below:
Figure 1. A dual-core processor
The advantage of dual-core chips is that they can be used to drive performance and reduce power requirements as well as the heat generated by higher and higher clock speeds of their single-core counterparts. Dual-core chips are denser as well, which means their physical requirements are more along the lines of their single-core cousins since they share the same form factor. Dual-core chips would also appear to be more environmentally friendly in that they consume less electricity and have lower HVAC requirements. In addition to this, the proximity of cached memory can yield performance advantages too and more and more software companies are looking to specifically write their application to leverage different cores on a processor for different
operations.
Each core on the first generation POWER dual-core chips were faster than the a single-core processor in the previous
generation; by putting two of these faster cores on the same chip, customers saw their performance improve more than two times for these new "processors" (the physical chip that plugged into the socket on the motherboard that now had two traditional processors on it as opposed to one). At this point, IBM Software Group (IBM SWG) determined that a processor should be defined as a core (so a dual-core processor meant two processors from a licensing perspective) since users were getting the full benefit of both cores on the chip. Soon after, other hardware vendors followed suit by releasing dual-core processors, like Sun, Intel, and AMD; soon after that we've seen a plethora of multi-core chips (quad-core, hex-core- octi-core, and so on) each designed for various characteristics: price performance, electrical consumption, performance, and so on.
Some hardware vendors reference the pieces of silicon that plug into the motherboard as a processor no matter how many cores are on it. You can see the marketing advantage here. One vendor may refer to a server with eight processing cores as an eight-way server while another would call it a four-way (since it has four dual-core processors, each processor with two processing cores). Various benchmarking organizations have adopted policies to limit this type of confusion and have implemented rules with respect to the reporting of server capacity such that you typically see benchmark results now reported as Processors/Cores/Threads(P/C/T); for example, a 32/64/128 benchmark report means that the result was run on a server with 32 dual core processors with some sort of hyperthreading enabled (2 threads per core). The Standard Performance Evaluation Corporation (SPEC) mandates that all results be reported in cores and the Transaction Performance Processing Council (TPC) also mandates the reporting of Processors/Cores/Threads in their disclosure reports.
In the past, to license IBM software running on a dual-core chip, customers counted the number of cores, and multiplied by the per-processor price. If a customer had what was traditionally known as a "four-way" dual-core, they were required to license eight processors of DB2. However, when x86 dual-core chips were introduced from Intel and AMD, they didn't double (or more than double) the performance, as was the case with their POWER counterparts. While Intel and AMD provided performance improvements by placing two cores on a chip, these architectures just didn't yield 2+ times the power of their single-core counterparts; our own research showed the speedup for these first generation x86 dual core servers to be around 30% (give or take); certainly not double as was the case with the POWER-based processors. As a result, the market started to conclude that not all dual-core chips were created equal and therefore shouldn't be licensed the same way.In addition, x86 quad-core chips soon hit the market and generally weren't considered, in their first generation, to be faster than an equal amount of processing cores on a dual-core chip. (For now, two dual core x86 chips would out perform a single x86 quad core chip; however, there is the definite and expected potential for them to be faster.)
Because of this phenomena, IBM announced a policy in 2005 that reflected this such that when licensing x86 dual-core chips you were effectively required to buy one-half of a license for each processor core, or essentially one processor license per
socket.
Note:
When Intel introduced hyperthreading which tricked software into thinking there were two processors for each single-core processor by pausing and inter-weaving schedule threads of work, the performance yield was around 30%; IBM never charged for these virtual processors because they didn't produce twice the performance.
To further complicate the procurement of IT solutions at this point was the fact that most software vendors were charging for each core and most hardware vendors were charging for the chip (since they can't sell half a chip), leading to even greater confusion in the marketplace.
If it hadn't become confusing enough, in the middle of 2006 (before the concept of PVU was announced) the multi-core marketplace became even more complex when Sun introduced their quad-core, hexa-core, and octi-core processors that ship with their first generation T1000/T2000 "Niagara" servers. These processors were not really engineered for straight out performance (though future generations of them have some-what addressed this issue) rather energy efficiencies in relation to performance. The point is that today's marketplace is characterized by different kinds of multi-core processors that have different characteristics: some provide double the performance, some provide massive energy savings, and some try to compromise between the two. Indeed, the evolution of the processing core foreshadowed the need for something new.
As we look into the future and see more multi-core processors from different vendors with different performance characteristics and value propositions, it seemed that there had to be a way to normalize these discrepancies. After all, it wouldn't seem fair to buy two licenses for a dual-core processor if it only yielded a 30% performance improvement. At the same time, it wouldn't seem fair to pay for only one license with a dual-core processor that yields a 200 percent (or more) performance improvement. The PVU methodology is used to standardize the value derived from a varying array of processor architectures to normalize the benefits and equate that to the software you are running to come up with a fair charge metric.
So now what? The Processor Value Unit (PVU)
In the third quarter of 2006, IBM SWG announced a replacement for their fragmented processing core-based pricing, and introduced the concept of PVU pricing. Since this announcement, you now interpret license limits for distributed DB2 data servers, and procure entitlements using this new PVU metric. For example, today, when you want to license your DB2 data server for unlimited users you arrive at the final DB2 price by aggregating the total about of PVUs on the server (or sometimes partition) where the DB2 software is running and multiplying that by the per PVU price of the DB2 edition (and/or Feature Pack) that you are
running.
A PVU is simply a unit of measure used to differentiate cores from the various hardware vendors. IBM now maintains the
PVU Licensing for Distributed Software table which maps today's available processors to the number of PVUs associated with a single respective processing cores. This table is continually updated as manufacturers go to market with different chip architectures. In fact, IBM SWG works so closely with these chip vendors that they are well aware of the performance benefits of many of the new processors before the market itself. You can determine the total PVU rating for your server by adding up the PVUs attributed to each core on your server using this table. Once you've determined the number of PVUs, multiply the total amount of PVUs for your server (unless you're purchasing a DB2 product that is eligible for sub-capacity pricing) by the per-DB2 PVU price for the edition you want to
license.
A PVU Licensing Example
To understand how traditional processor pricing equates to PVU pricing, it's best to compare and contrast the two models. As of the date this article was last updated, conversion rates for processing cores to PVUs are as follows:
Figure 2. PVU Licensing for Distributed Software table as of May
2008
Note:
This table is provided for your convenience and to facilitate a working example; for the most update to date PVU conversion rates, refer to the previous table online.
You can see this table is pretty much organized by decreasing per core PVU ratings for each vendor and their processor brand. Simply locate the brand of your processor, and the respective number of cores on the processor, and arrive at the PVU rating for each core using the PVUs per Processor Core column.
For example, using this table you can see that any single core processor from any vendor requires 100 PVUs. An Intel Xeon x86 quad core processor is 200 PVUs since it is licensed at 50 PVUs per core. You can also see that a System z10 processor (used to run Linux on System z) is rated at 120 PVUs per core for the IFL engine it runs.
So how do we explicitly figure out how many PVUs of a DB2 edition we have to buy? From this table we know that a single dual-core AMD Opteron processor requires 100 PVUs (50 PVUs per core), and let's assume you're server that has two dual-core AMD processors, then you are required to buy 200 PVUs of your DB2 software: (2 processors x (50 PVUs x 2 cores)) = 200 PVUs. In contrast, the faster performing dual-core POWER6 processor yields far more performance than an AMD-based dual-core processor. If you have a POWER server with 2 dual core POWER6 processors, you are required to purchase 480 PVUs of DB2:(2 processors x (120 PVUs x 2 cores)) = 240 PVUs.
Note:
POWER 6 processors - and discussed in the PVU table referenced above - can be rated at a 80 PVUs depending on the server where they run. Specifically, POWER p 520, BladeCenter JS12/JS22 server, then each POWER6 processor is counted as 80 PVUs per core. All other servers using POWER6 processor than those listed here (and updated online in the table) are rated at 120 PVUs.
PVUs are used for licensing restrictions as well. This means that if a DB2 edition is limited to 200 PVUs, like DB2 Express, then from the table referenced above, you can deduce that you could install the DB2 Express on any server that does not exceed a 200 PVU rating. In May 2008 IBM changed the PVU limit for DB2 Workgroup from 400 PVUs to 480 PVUs to accommodate 4-core POWER6 servers running this edition of DB2. For example, you could install DB2 Workgroup on :
- A server with four dual-core x86 AMD-based Opteron chips
- A server with a single quad-core x86 AMD-based Opteron chips
- A server with two dual-core POWER6 chips
- A server with a two quad-core POWER5 5 QCM chips
- A server with a four UltraSparcT1 quad-core chip
- and more...look at the table!
To further assist in determining the number of PVUs your server may aggregate to, you can use the IBM Processor Value Unit Calculator in 'guided mode' (which operates like a Wizard) or 'expert mode'. An example of this tool is shown below:
Figure 3. An example of using the IBM Value Unit Calculator
Wrapping it up...
To summarize, DB2 PVU pricing provides the following benefits:
- Creates a simple and fair licensing structure
- Avoids fractional licensing for multi-core chips
- Avoids charging too much for multi-core chips
- Provides flexibility and granularity
- Enables sub-capacity licensing at the processor core
- Positions for the future
- Continues to deliver software price performance improvements
- Makes licenses more transferable across distributed systems since PVUs can be moved around to different data servers that run on different core architectures
- Provides clarity to middleware licensing
- Over time, new processors will be differentiated based on relative performance
The new PVU model is a change in the way you do things, and to be honest, no one really likes a change. In due time, it'll become old hat, and as different processing cores offering various benefits are brought to the marketplace, you'll be able to leverage them in a fair and consumable manner.
Resources Learn
-
"Compare the distributed DB2 9.5 data servers" (developerWorks, Feb 2008): Compare the DB2 for Linux, UNIX, and Windows editions in a side-by-side comparison table.
-
"Which DB2 9.5 client connectivity option is right for you?" (developerWorks, Apr 2008): Learn the details of all the various client connectivity options.
-
"Which distributed edition of DB2 9.5 is right for
you?" (developerWorks, Feb 2008): Get the details on what makes each edition of DB2 for Linux, UNIX, and Windows unique.
-
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 Enterprise 9.
-
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
About the authors | 
| |
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.
|
| | |
Deb Jenson joined IBM in 2004 to drive strategic marketing for the DB2 data server. As Product Manager for DB2, she is responsible for market strategies that drive incremental growth and increase market awareness for the DB2 data server. Deb has over 12 years experience in the commercial software industry with extensive experience developing database products and driving market execution strategies that drive growth. Deb joined IBM from Quest Software and prior to Quest, held various positions at Platinum Technology focused on the database management product family. Deb can be reached at: dejenson@us.ibm.com..
|
Rate this page
| |
