Inside pSeries Servers


To understand the capabilities of pSeries systems, it is necessary to take a quick look at a few key architectural elements inside pSeries servers.

POWER4 and POWER4+

The pSeries line is the third generation of reduced instruction set computing (RISC) products. With the RISC approach, a very simple set of programming instructions is executed at extremely high speeds, resulting in better overall performance.

The pSeries line was introduced using the POWER3 and PowerPC microprocessors. The latest RISC processor generation from IBM—POWER4—was introduced in October 2001 on the pSeries 690 server. The POWER4 design is now used in many pSeries systems.

The POWER4 microprocessor is the first single chip to house two processors, which gives it a significant performance advantage over competitive designs. Over 174 million transistors and a mile of microscopic wiring are able to fit on a single chip through the use of advanced packaging technology (0.18 micron).

The POWER4 uses IBM silicon-on-insulator and copper wiring technologies. These technologies allow the POWER4 to operate 25% faster while generating 25% less heat. Less heat, in addition to copper wiring on the chip, means better reliability. Figure 2.1 shows a wafer containing a group of POWER4 microprocessors ready to be cut and packaged.

click to expand
Figure 2.1: A wafer of IBM POWER4 microprocessor chips.

The POWER4+ microprocessor is an enhanced version of the POWER4 and was first used in the pSeries Model 650 introduced in November 2002. The POWER4+ used even greater density packaging technology (0.13 micron) to pack in an additional 10 million transistors. The increased density also allowed for still higher operating speeds, reduced power consumption, and reduced heat generation (again aiding in reliability).

start sidebar
MORE ON THE WEB
  • IBM Redbook: The POWER4 Processor

  • Collection of five papers on POWER4

  • POWER4 System Microarchitecture (paper)

end sidebar

Symmetric Multiprocessing (SMP)

All pSeries systems support the use of multiple processors within a single system to achieve higher levels of performance. All the processors within a pSeries system share the same memory, disk, communications adapters, tape drives, and the like (Figure 2.2). This shared memory model of computing is called symmetric multiprocessing (SMP). The SMP design of pSeries combines functions of both the processor and the AIX or Linux operating systems.

click to expand
Figure 2.2: Symmetric multiprocessing (SMP).

The SMP implementation within pSeries systems enables several valuable things. First, it affords a business more choices in terms of processing power when selecting a pSeries server for a particular need. And, of course, it allows a business to upgrade the processing power of a pSeries server (by adding additional processors) as the business grows.

Perhaps even more importantly, the pSeries implementation of SMP enables a new type of flexibility and another self-healing function (part of the autonomic computing strategy). The new type of flexibility comes in the form of Capacity Upgrade on Demand (covered next), which allows a business to switch on dormant processors as workloads increase.

The self-healing function of pSeries SMP comes through a function called dynamic processor deallocation. Here is how it works: A dedicated service processor (separate from the SMP processors) constantly monitors and manages the overall health of the pSeries system. If one of the SMP processors shows signs of impending failure, the service processor often can turn off the failing processor and activate a spare processor—all the while keeping the system running smoothly. Then the service processor can literally place its own service call to initiate the needed repairs.

Note that SMP is not the same thing as clustering. With clusters, every processor in the cluster has its own memory, disk, etc., but all are cooperating closely through the high-speed connections between them. This is why clustered configurations are often called "shared nothing" configurations, while SMP implementations are called "shared everything" configurations.

Capacity on Demand

Even in stable environments, it is often hard to tell what level of computing power one should buy for a particular situation. While it is less than ideal to buy too much power, it is completely unacceptable to buy too little. This means that most of the time you wind up purchasing more computing power than you need, which by definition means some of that capacity is wasted.

Now factor in the unexpected acquisitions, a hiring binge to support business growth (i.e., unanticipated user population growth), a current event or successful advertising campaign that drives masses to your Web site, whatever. So to say the least, it is difficult to always purchase just the right amount of computing power. This problem is the genesis behind the capacity on demand function available on some of the iSeries models. Capacity on demand provides a way to activate additional processing power and memory as business needs change.

Here is how capacity on demand works. When you order a pSeries system, you get some extra standby processors that lie dormant. For example, on a p690 you get four active processors (also called start-up processors) and four inactive standby processors (which you don't pay for yet). If, once your p690 is installed and running, you suddenly find you need more processing power, you can activate standby processors to meet the demand. You can activate the dormant processors under two different versions of capacity on demand: Capacity Upgrade on Demand (CUoD) or On/Off Capacity on Demand.

Capacity Upgrade on Demand is used when a business needs to permanently increase the performance of a pSeries server. Here are the steps to activating CUoD:

  1. You call IBM and send them your current configuration data over the Internet.

  2. IBM sends you an encrypted key over the Internet.

  3. You use the key to activate one or more of the dormant processors.

Nothing to install, no hardware to ship, no new contracts to sign... it's just activated and off you go. You are charged only for the additional processors you choose to activate.

The other type of capacity on demand, called On/Off Capacity on Demand or On/Off CoD, is intended to meet temporary needs—that is, to accommodate peak workloads generated by such things as seasonal transaction volume increases, increased Web site traffic due to a special event, etc. To use On/Off CoD, you must first enable the On/Off CoD function with a code provided by IBM. Once it is enabled, you can activate dormant processors and deactivate them as needed. The pSeries server will report processor usage, and you pay for the number of "processor days" you use.

The memory on pSeries systems also allows you to increase system memory using a similar process. As for disk storage, you can get capacity on demand capability through devices like the IBM TotalStorage Enterprise Storage Server. Over time, you will see more and more resources made available through the capacity on demand approach.

To help businesses monitor and plan for performance needs overtime, there is the "pSeries performance management for AIX" service (PM/AIX). With this service, registered pSeries systems regularly gather key performance data and send it to IBM for analysis. The business can then customize and review the results of that analysis in graphical form from anywhere over the Internet. From the analysis you can see what resources are approaching maximum capacity (disk, processor, memory, etc.) or are under contention. This helps a business methodically plan ahead for performance needs rather than reacting to performance problems as they arise.

start sidebar
MORE ON THE WEB
  • pSeries Capacity Upgrade on Demand Advantages

  • pSeries 670 and 690 CUoD Planning Guide

  • pSeries performance management for AIX (PM/AIX) info

end sidebar

Dynamic LPAR

"LPAR" stands for logical partitioning. It refers to a popular function first introduced in IBM mainframe computers and now implemented in pSeries servers. The LPAR function allows you to take a single pSeries server and make it appear to be a collection of independently operating servers. That is, you can define multiple "virtual" pSeries servers within a single "real" pSeries server. You do this by "logically partitioning" the system into virtual servers and then allocate resources (processors, memory, input/output devices, etc) to each virtual server. The largest pSeries systems can have up to thrity-two logical partitions, yet there is only one "real" system to manage.

Each partition can run its own instance of the operating system (AIX or Linux), middleware, and application programs, making each an independent "virtual" server. To complete the picture, each partition can support an independent set of users.

Businesses can use dynamic LPAR in many ways. For one thing, you can move the workloads of multiple UNIX servers onto one partitioned pSeries server. This type of server consolidation can often yield dramatic benefits in terms of reducing the costs associated with floor space, rack space, software licensing fees, power consumption, air conditioning, maintenance, support, etc., while simplifying systems management. Further, using the "dynamic" part of LPAR, you can shift the resources from partition to partition as needed without disrupting users. This is something you can't do with a collection of independent servers, and it makes for more efficient use of computing power.

What if a problem arises in one of the partitions? There is hardware (and firmware) to protect problems in one partition (e.g., a hardware failure or application program failure) from disrupting users in another partition.

Dynamic LPAR can be used to facilitate the testing of new application programs, new operating system versions, new devices, etc. By running a "test partition," you won't disrupt the real (production) users if things don't go well during the testing. This avoids the extra cost of purchasing additional independent servers for testing purposes.

Dynamic LPAR can also be employed to support backup and recovery functions, application programs that require different versions of the operating system, a fail-over backup server function, application programs requiring different time zone settings, and better utilization of scarce or expensive resources (tape libraries, optical storage, high-performance communications adapters, etc.).

IBM eServer systems are not the only ones to implement LPAR. Other brands of computers also offer this function. Be aware that subtle differences in the way LPAR is implemented can affect your ability to benefit from them. See the More on the Web inset and read "LPAR for Decision Makers" for more on using LPAR and a description of implementation differences.

start sidebar
MORE ON THE WEB
  • LPAR for Decision Makers (technology paper)

  • Collection of LPAR technology papers and links

end sidebar

For a real-world example of how Dynamic LPAR can be used for server consolidation, see the Toyota Australia case study in Chapter 4.




Building on Your Aix Investment(c) Moving Foreword With IBM Eserver pSeries in an on Demand World
Writing Secure Code, Second Edition
ISBN: N/A
EAN: 2147483647
Year: 2003
Pages: 56

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net