Clearspace Server Syndication Feed

Performance Impact of Intel® Intelligent Power Node Manager

egcastroleon — Thu, 22 Oct 2009 23:32:19 GMT

One of the first questions in my mind when I was first exposed to Intel(r) Intelligent Power Manager (Node Manager) was "what is the performance impact of applying Node Manager technology?" I will share some thoughts. The underlying dynamics are complex and not always observable and hence it's difficult to provide a definitive answer. Robert A. Heinlein popularized the term TANSTAAFL ("There ain't no such thing as a free lunch") in his 1966 novel “The Moon is a Hard Mistress”. So, does TANSTAAFL apply here? Node Manager brings benefits with the ability for the application to designate a target power consumption, a capability otherwise known as power capping. On the cost side, Node Manager takes some work to deploy, and has performance impact that varies from very little to moderate. On the other hand, Node Manager can be turned off, in which case there is no overhead.

Node Manager is useful even when it is not actively power capping but is used as a guardrail, ensuring that power consumption will not exceed a threshold. The predictable power consumption has value because it provides data center operators a ceiling in power consumption. Having this predictable ceiling helps optimize the data center infrastructure and reduce stranded power. Stranded power refers to a power allocation that needs to be there even if it's only for occasional use.

The performance impact can vary from zero when Node Manager is used as a guardrail to a percentage equal to the number of CPU cycles lost due to power capping when Node Manager is applied at 100% utilization. When applied during normal operating conditions, the loss of performance is smaller than the number of cycles lost to power capping implies because the OS usually compensates for the slowdown. If the end user is willing to re-prioritize application processes, under some circumstances it is possible to bring performance back to the uncapped level or even beyond.

Power capping is attained through voltage and frequency scaling. Power consumed by a CPU is proportional to frequency and to the square of the voltage applied to the CPU. This is done in discrete steps (“P-states” as defined by the ACPI standard.

The highest performing P-states are also the most energetic. Starting from a fully loaded CPU and the highest P state, the DBS assigns lower energy P-states as workload is reduced utilizing the Intel(r) SpeedStep technology. An additional dip takes place as idle is reached as unused logical units in the CPU are switched off automatically.

Node Manager allows manipulating the P-states under program control instead of autonomously as under SpeedStep. Since the CPU is running slower, this has the effect of potentially removing some of the cycles that otherwise could be used by applications, but reality is more nuanced.

At high workloads, most CPU cycles are dedicated to running the application. Hence, if power capping is applied, a reduction in CPU speed will yield and almost one-to-one reduction in application performance.

At the other end of the curve, if the CPU is idling and power consumption is already at the floor level. An application of Node Manager will not yield any additional power consumption reduction.

The more interesting cases take place in the mid-range band of utilization, when the utilization rate is between 10 and 60 percent, depending on the application (40 to 80 percent in the BMW case studybelow.) Taking utilization beyond the upper limit is not desirable because the system would have difficulty in taking up load spikes and hence response times may deteriorate to unacceptable levels.

We have run a number of applications in the lab and observed their performance behavior under Node Manager. Surprisingly, the performance loss is less than frequency scaling would indicate. One possible explanation is that when utilization is in the mid-range, there are idle cycles available. The OS compensates to some extent for the slower cycles by increasing the time slices to the applications, using up otherwise idle cycles, to the point that the apparent performance of the application is little changed. The application may need to be throttled up to re-gain the pre-capping throughput.

One way to verify this behavior is to observe that CPU utilization has indeed gone up in a power capped regime. BMW conducted a proof of concept with Intel precisely to explore the boundaries of the extent to which that application could be re-prioritized under power capping to restore the original, uncapped throughput. TANSTAAFL still applies here. The application is still yielding the same performance under power capping. However, since there are fewer cycles available due to frequency scaling, there will be less headroom should the workload pick up suddenly. In this case the remedy is simply to remove the cap. The management software needs to be aware of these circumstances and initiate the appropriate action.

The experiments in this proof of concept involved an application mix used at a BMW site. In the first series of experiments we plotted power consumption against CPU utilization by throttling the workload up and down, shown in red.

In the second series, shown in green, for each dot in the original curve we apply an initial power cap. This yields a performance reduction. The workload is throttled up until the uncapped performance is restored. This process is repeated with increasingly aggressive power policy caps until the original performance cannot be reached. The new system power consumption without impacting system performance is shown plotted in green. The difference between the red and green curves represents the range of capping applicable while maintaining the original throughput level. The execution and running at the green level yields the same uncapped system performance. However, since idle cycles have been removed, there is no margin left to pick up extra workload. Should it happen, performance indicators will deteriorate very quickly.

Under the circumstances described above, the system was able to deliver the same throughput at a lower power level. There was no compromise in performance. The tradeoff is in the form of diminished headroom in case the workload picks up. The system operator or management software have the option to remove this cap immediately should this headroom be needed.

Strategies for Managing Power Consumption in the Data Center

egcastroleon — Tue, 01 Sep 2009 04:55:58 GMT

In spite of significant gains in server energy efficiency, power consumption in data centers is still trending up. At the very least, we can make sure that the energy expended yields maximum benefit to the business. A first step in managing power in the servers in a data center is having a fairly accurate monitoring capability for power consumption. The second step is to have a number of levers that allow using the monitoring data to carry out an effective power management policy.

While we may not be able to stem the overall growth of power consumption in the data center, there are a number of measures we can take immediately:

· Implement a peak shaving capability. The data center power infrastructure needs to be sized to meet the demands of peak power. Reducing peaks effectively increase the utilization of the existing power infrastructure.

· Be smart about shifting power consumption peaks. All the watts are not created equal. The incremental cost of generating an extra watt of power during peak consumption hours is much higher than the same watt generated in the wee hours of the morning. For most consumer and the smaller commercial accounts flat rate pricing still prevails. Real time pricing (RTP) and negotiated SLAs will become more common to put the appropriate economic incentives in place. The incentive of real time pricing is a lower energy bill overall, although the outcome is not guaranteed. In pilot programs residential consumers have complained that RTP result in higher electricity costs. With negotiated SLAs the customer can designate a workload to be subject to lower reliability; for instance, instead of 3 9’s, or outages amounting to about 10 hours per year, the low reliability workload can be designated as only 90 percent reliable, and can be out on the average of two hours per day.

· Match the electric power infrastructure in the data center to server workloads to minimize over-provisioning. This approach assumes the existence of an accurate power consumption monitoring capability.

· Upgrading the electrical power infrastructure to accommodate additional servers is not an option in most data centers today. Landing additional servers at a facility that's working at the limit of thermal capacity leads to the formation of hot spots, this assuming that electrical capacity limits are not reached first with no room left in certain branch circuits. Hence measures that work under the existing power infrastructure are to be preferred over alternatives that require additional infrastructure.

For the purposes data center strategic planning it may make economic sense to grow large data centers in a modular fashion. If the organization manages a number of data centers, consider making effective use of the existing data centers, and when new construction is justified, redistribute the workloads to the new data center to maximize the use of the new electrical supply infrastructure.

Intel has built into its server processor lineup a number of technology ingredients that allow data center operators optimize the utilization of the available power system infrastructure in the data center.

Newer servers of the Nehalem generation are much more energy efficient, if only because of the side effect of increased performance per watt. These servers also have a more aggressive implementation of power proportional computing. Typical idle consumption figures are in the order of 50 percent of peak power consumption.

Beyond passive mechanisms that do not require explicit operator intervention, the Intel® Intelligent Power Node Manager (Node Manager) technology allows adjusting the power draw of a server and trade off power consumption against performance. This capability is also known as power capping. The control range is a function of server loading. For the Intel SR5520UR baseboard on the 2U chassis, the server will draw about 300 watts at full load and its power consumption can be rolled down to about 200 watts. The control range tapers down gradually until it reaches zero at idle.

For power monitoring, selected models of the current Nehalem generation come with PMBus specification compliant power supplies allowing real-time power consumption readouts.

The Node Manager power monitoring and capping capability apply to a single server. To make this capability really useful it is necessary to exercise these capabilities collectively to groups of servers, to add the notion of events and a capability to build a historical record of power consumption for the servers in a group. The additional capabilities have been implemented in software through the Data Center Manager Software Development Kit developed by the Intel Solutions and Software Group. An additional Software Development Kit, Cache River allows programming access to components in servers and server building blocks produced by the Intel Enterprise Products Server Division (EPSD), including the baseboard management controller (BMC) and the management engine (ME), the subsystems that host or interact with the Node Management firmware. EPSD products are incorporated in many OEM and system integrator offerings.

Data Center Manager implements abstractions that apply to collections of servers:

· A hierarchical notion of logical server groups

· Power management policies bound to specific server groups

· Event management and a publish/subscribe facility for acting upon and managing power and thermal events.

· A database for logging a historical record for power consumption on the collection of managed nodes.

The abstractions implemented by DCM on top of Node Manager allow the implementation of power management use cases that involve up to thousands of servers.

If this topic is of interest to you, please join us at the Intel Development Forum in San Francisco at the Moscone Center on September 22-24. I will be facilitating course PDCS003, "Cloud Power Management with the Intel(r) Xeon(r) 5500 Series Platform." You will be the opportunity to talk with some of our fellow travelers in the process of developing power management solutions using Intel technology ingredients and get a feel of their early experience. Also please make a note to visit booths #515, #710 and #712 to see demonstrations of early end-to-end solutions these folks have put together.

Energy Management vs. Power Management in the Data Center, Take 2

egcastroleon — Wed, 19 Aug 2009 07:49:28 GMT

I would like to elaborate on the topic energy vs. power management in my previous entry.

Upgrading the electrical power infrastructure to accommodate additional servers is not an option in most data centers today. Landing additional servers at a facility that's working at the limit of thermal capacity leads to the formation of hot spots, this assuming that electrical capacity limits are not reached first with no room left in certain branch circuits.

There are two types of potentially useful figures of merit, one for power management and one for energy management. A metric for power management allows us to track operational "goodness", making sure that power draw never exceeds limits imposed by the infrastructure. The second metric tracks power saved over time, which is energy saved. Energy not consumed goes directly to the bottom line of the data center operator.

To understand the dynamic between power and energy management let's look at the graph below and imagine a server without any power management mechanisms whatsoever. The power consumed by that server would be P(unmanaged) regardless of any operating condition. Most servers today have a number of mechanisms operating concurrently, and hence the actual power consumed at any given time t is P(actual)(t). The difference P(unmanaged) - P(actual) is the power saved. The power saved carried over time t(1) through t(2) yields the energy saved.

Please note that a mechanism that yields significant power savings may not necessarily yield high energy savings. For instance, the application of Intel(r) Dynamic Power Node Manager (DPNM) can potentially bring power consumption by over 100 watts, from 300 watts at full load to 200 watts in a dual-socket 2U Nehalem server that we tested in our lab. However, if DPNM is used as a guard rail mechanism, to limit power consumption if a certain threshold is violated, DPNM may never kick in, and hence energy savings will be zero for practical purposes. The reason why we do this is because DPNM works best only under certain operating conditions, namely high loading factors, and because it works through frequency and voltage scaling, it brings a performance tradeoff.

Another useful figure of merit for power management is the dynamic range for power proportional computing. Power consumption in servers today is a function of workload as depicted below:

The relationship is not always linear, but the figure illustrates the concept. On the x-axis we have the workload that can range from 0 to 1, that is, 0 to 100 percent. P(baseline) is the power consumption at idle, and P(spread) is the power proportional computing dynamic range between P(baseline) and power consumption at 100 percent workload. A low P(baseline) is better because it means a low power consumption at idle. For a Nehalem-based server, P(baseline) is roughly 50 percent of power consumption at full utilization, which is remarkable, considering that it represents a 20 percent over the number we observed for the prior generation, Bensley-based servers. The 50 percent figure is a number we have observed in our lab for a whole server, not just the CPU alone.

If a 50 percent P(baseline) looks outstanding, we can do even better for certain application environments such as load-balanced front end Web server pools and the implementation of cloud services through clustered, virtualized servers. We can achieve this effect through the application of platooning. For instance, consider a pool of 16 servers. If the pools is idle, all the servers except one can be put to sleep. The single idle server is consuming only half the power of a fully loaded server, consuming one half of one sixteenth of the cluster power. The dormant servers still draw about 2 percent of full power. Hence, after doing the math, the total power consumption for the cluster at idle will be about 8 percent of the full cluster power consumption. Hence for a clustered deployment, the power dynamic range has been increased from 2:1 for a single server to about 12:1 for the cluster as a whole.

In the figure below note that each platoon is defined by the application of a specific technology or state within each technology. This way it is possible to optimize the system behavior around the particular operational limitations of the technology. The graph below is a generalization of the platooning graph in the prior article. For instance, a power capped server will impose certain performance limitations to workloads, and hence we assign non time critical workloads to that platoon. By definition, an idling server cannot have any workloads; the moment a workload lands on it it's no longer idle, and its power consumption will rise.

The CPU is not running in any of the S-states than S0. The selection of a specific state depends on how fast that particular server is needed online. It takes longer to bring up a server online in the lower energy states. Servers in G3 may actually be unracked and put in storage for seasonal equipment allocation.

A virtualized environment makes it easier to rebalance workloads across active (unconstrained and power capped) servers. If servers are being used as a CPU cycle engines, it may be sufficient to idle or put to sleep the subset of servers not needed.

The extra dynamic power range comes at the expense of instituting additional processes and operational complexity. However, please note that there are immediate benefits in power and energy management accrued through a simple equipment refresh. IBM reports an 11X performance gain for Nehalem-based HS22 blade servers versus the HS20 model only three years old. Network World reports a similar figure, a ten-fold increase in performance, not just ten percent.

I will be elaborating on some of these ideas at the PDCS003 Cloud Power Management with the Intel(r) Nehalem Platform class at the upcoming Intel Developer Forum in San Francisco on the week of September 20th. Please consider yourself invited to join me if you are planning to attend this conference.

Energy Management vs. Power Management in Data Center Servers

egcastroleon — Tue, 14 Jul 2009 03:52:12 GMT

There are two technologies available to regulate power consumption in the recently introduced Nehalem servers using the Intel® Xeon® processor 5500 series. The first is power proportional computing where power consumption varies in proportion to the processor utilization. The second is Intel® Dynamic Power Node Manager (DPNM) technology which allows the setting of a target power consumption when a CPU is under load. The power capping range increases with processor workload.

An immediate benefit of the Intel® Dynamic Node Manager (DPNM) technology is the capability to balance and trade off power consumption against performance in deployed Intel Nehalem generation servers. Nehalem servers have a more aggressive implementation of power proportional computing where idle power consumption can be as small as 50 percent of the power under full load, down from about 70 percent in the prior (Bensley) generation. Furthermore, the observed power capping range under full load when DPNM is applied can be as large as 100 watts out for a two-socket Nehalem server with the Urbanna baseboard observed in the lab to draw about 300 watts under full load. The actual numbers you will obtain depend on the server configuration: memory, number of installed hard drives and the number and type of processors.

Does this mean that it will be possible to cut the electricity bills by one third to one half using DPNM? This is a bit optimistic. A typical use case for DPNM is as a "guard rail". It is possible to set a target not to exceed for the power consumption of a server as shown in the figure below. The red line in the figure represents the guard rail. The white line represents the actual power demand as function of time; the dotted line represents the power consumption that would have existed without power management.

Enforcing this power cap brings operational flexibility: it is possible to deploy more servers to fit a limited power budget to prevent breakers from tripping or to use less electricity during peak demand periods.

There is a semantic distinction between energy management and power management. Power management in the context of servers deployed at a data center refers to a capability to regulate the power consumption at a given instant. Energy management refers to the accumulated power saved over a period of time.

The energy saved through the application of DPNM is represented by the area between the dotted line and the white graph line below; the power consumed by the server is represent by the area under the solid white graph line. Since power capping is in effect during relatively short periods, and when in effect the area between the dotted line and the guard rail is relatively small, it follows that the energy saved through the application of DPNM is small.

One mechanism for achieving significant energy savings calls for dividing a group of servers running an application into pools or "platoons". If servers are placed in a sleeping state (ACPI S5 sleep) during periods of low utilization it is possible to bring their power consumption to less than 5 percent of their peak power consumption, basically just the power needed to keep the network interface controller (NIC) listening for a wakeup signal.

As the workload diminishes, additional servers are moved into a sleeping state. The process is reversible whereby servers are taken from the sleeping pool to an active state as workloads increase. The number of pools can be adjusted depending on the application being run. For instance, it is possible to define a third, intermediate pool of power capped servers to run lower priority workloads. Capped servers will run slightly slower, depending on the type of workload.

Implementing this scheme can be logistically complex. Running the application in a virtualized environment can make it considerably easier because workloads in low use machines can be migrated and consolidated in the remaining machines.

We are conducting experiments to ***** the potential for energy savings. Initial results indicate that these savings can be significant. If you, dear reader have been working in this space, I'd be more than interested in learning about your experience.

Dynamic Power Allocation for Server Groups

egcastroleon — Sat, 06 Jun 2009 02:14:08 GMT

The Intel(r) Dynamic Power Node Manager technology allows setting a power consumption target for a server under load as described in a previous article. This is useful for optimizing the number of servers in a rack when the rack is subject to a power budget.

Higher level software can use this capability to implement sophisticated power management schemes, especially schemes that involve server groups. The range of control authority for servers in the Nehalem generation is significant. The power consumption of a fully loaded server consuming 300 watts can be rolled back by roughly 100 watts. In virtualized utility computing environments additional control authority is possible by migrating the virtual machines out of a host and consolidating them into fewer host. The power consumption of the power capped host now at 200 watts, can be brought down by another 50 watts, to 150 watts.

The reader might ask about the possibility of constantly running servers in capped mode to save energy. Unfortunately capping entails a performance tradeoff. The dynamic is not unlike driving an automobile. The best mileage is obtained by running the vehicle at a 35 MPH constant speed. This is not practical in a freeway where the the prevailing speed is 60 MPH. The vehicle could be rear ended, or perhaps a more mundane motivation, the vehicle driver drives the vehicle at 60 MPH because she wants to get there sooner. Like a server, the lowest fuel consumption in a running vehicle, at least in gallons per hour, is attained when the vehicle is idling. No real work is done with an idling engine, but at least the vehicle can start moving in no time. Continuing with the analogy, turning a server off is equivalent to storing a car in the garage with the engine stopped.

This document provides an example of the performance tradeoff with power capping. Please look in page 5, Figure 2.

The following example illustrates how group power capping works. The plot is a screen capture of the Intel(r) Data Center Manager software managing the power consumption in a cluster of four servers. The four servers are divided in a cluster of two server sub-groups of two servers each, labeled low-priority and high-priority

The light blue band represents the focus of the plot. The focus can be changed with a simple mouse click. The current focus in the figure is the whole rack. Hence the power plot is the aggregated power for all four servers in a rack. If the high priority sub-group were selected, then the power shown would be the power consumed by the two servers in that sub-group. Finally, if a single server is selected, then the power indicated would be the power for that server only.

There are four lines represented in the graph. The top line is the plate power. It represents an upper bound for the server’s power consumption. For this particular group of servers the plate power is 2600 watts. The servers are identical, and hence rated at 2600 / 4 = 650 watts.

The next line down is the derated power. Most servers will not have every memory slot or every hard drive tray populated. The derated power is the data center’s operator guess about the upper bound for power consumption based on the actual configuration the server. The derated power is still a conservative guess, considerably higher than the actual power consumption of the server. As a rule of thumb, it is ~70% of the nameplate. The derated power has been set at 1820 watts for the rack or 455 watts per server.

Finally, the gold line represents the actual power consumed by the server. The dots represent successive samples taken from readings from the instrumented power supplies.

The servers are running at full power using the SPECpower benchmark. The rack is collectively consuming a little less than 1300 watts. At approximately 16:12 a policy is introduced to constrain power consumption to 1200 watts. DCM instructs individual nodes to reduce power consumption by lowering the set points for Node Manager in each node until the collective power consumption reaches the desired target.

When we instructed Data Center Manager to hold a power cap for the group rack (2), it makes an effort to maintain power at that level, in spite of unavoidable disturbances in the system.

The source of the disturbances can be internal or external. An internal disturbance can be the server fans switching to a different speed causing a power spike or dip. Workloads in servers go up and down, with a corresponding uptick or dip in the power consumption for that server. An external disturbance could be a change in the feed voltage or an operator action. In fact at T = 16:14 we introduced a severe disturbance: we brought the workload of the bottom server, epieg3urb07 down to idle.

Note that it takes a few seconds for Data Center Manager to react and to reach the original power level. Likewise, when the bottom server is brought to idle, it also pulled back the power consumption for the group. However, the group power went back to the target power consumption after a couple of minutes. If we look at the plot of the individual servers, we can see Data Center Manager at work maintaining the target power.

The figure above captures the behaviors of the individual servers. Note how DCM allocates power to individual nodes yet it maintains a global power cap. When the server at the bottom is suddenly idled, there is a temporary dip in power server consumption for the group, but it soon recovers to the target capped level. Also note that the power not used by the bottom server is reallocated to the remaining three nodes until they get close to the previously unconstrained level.

Managing power events and thermal exceptions

egcastroleon — Tue, 19 May 2009 03:27:31 GMT

In this installment on uses of server power management we continue the discussion on using this capability for other uses beyond server rack density.

Intel(r) Data Center Manager (Intel DCM) is a software development kit that can provide real time information to optimize data center operations. It provides a comprehensive list of publish/subscribe event mechanisms that can form the basis of a sophisticated data center management infrastructure integrating multiple applications where applications get notified of relevant thermal and power events and can apply appropriate policies.

These policies can span a wide range of potential actions: dialing back power consumption to bring it down below a reference threshold or to reduce thermal stress on the cooling system. Some actions can be complex, such as migrating workloads across hosts in a virtualized environment, powering down equipment or even performing coordinated actions with building management systems.

Intel DCM also provides inlet temperature or front panel thermals along with a historical record that can be used to identify trouble spots in the data center. This information provides insights to optimize the thermal design of the data center. The actions needed to fix trouble spots need not be expensive at all; they may involve no more than relocating a few perforated tiles or installing blanking panels and grommets to minimize air leaks in the raised metal floor. Traditionally, the hardest part has been identifying the trouble spots, involving time consuming temperature and air flow measurements. Intel Data Center Management provides much of this data ready made from operations. Typically this type of analysis is done by a consulting team and the cost of this exercise is high, anywhere between $50,000 to a $150,000 for a 25,000 square foot data center. This analysis yields a single snapshot in time which becomes gradually more inaccurate as the equipment in the data center is refreshed and reconfigured.

Deployment scaling can range from a small business managing a few co-located servers in a shared rack in a multi-tenant environment to organizations managing thousands of servers.

The event handling capability is an software abstraction implemented by the Intel DCM SDK running in a management console. From an architectural perspective, and the fact that the number of nodes managed can range in the hundreds, it makes more sense to implement this capability as software rather than firmware. Node Manager is implemented as firmware and it typically controls one server. The choice of SDK over a self-standing management application was also deliberate. Although Intel DCM comes with a reference GUI to manage a small number of nodes as a self-standing application, it shines when it's used as a building block for higher level management applications. The integration is done through a Web services interface. Documentation for Intel DCM can be found in http://software.intel.com/sites/datacentermanager/.

Using Intel(r) power management to increase rack density

egcastroleon — Sat, 09 May 2009 00:51:39 GMT

In a previous article we explored the implementation mechanisms for monitoring and controlling the power consumed by data center servers. In this article we'll see that an ability to trim the power consumed by servers at convenient time represents a valuable tool to reduce stranded power and take maximum advantage of the power available under the existing infrastructure. Let's start with a small example and figure out how to optimize the power utilization in a single rack.

Forecasting the power requirements for a server over the product’s lifetime is not an easy exercise. Server power consumption is a function of server hardware specifications and the associated software and workloads running on them. Also the server’s configuration may change over time: the machine may be retrofitted with additional memory, new processors and hard drives. This challenge is compounded by more aggressive implementations of power proportional computing: servers of a few years ago exhibited little variability between power consumption at idle and power consumption at full power.

While power proportional computing has brought down the average power consumption, it also has increased its variance significantly, that is, data center administrators can expect wide swings in power consumption during normal operation.

Under-sizing the power infrastructure can lead to operational problems during the equipment’s lifetime: it may become impossible to fully load racks due to supply power limitations or because hot spots start developing. This extra data center power capacity needs to be allocated for the rare occasion where it might be needed, but in practice and cannot be used because it is held in reserve, leading to the term "stranded power."

One possible strategy is to forecast power consumption using an upper bound. The most obvious upper bound is to use the plate power, that is, the power in the electrical specifications of the server. This is a number guaranteed to never be exceeded. Throwing power at the problem is not unlike the approach of throwing bandwidth at the problem in network design to compensate for lack of bandwidth allocation capability and QoS mechanisms. This approach is overly conservative because the power infrastructure is designed by adding the assumed peak power for each server over the equipment’s life time, an exceedingly unlikely event.

The picture is even worse when we realize that IT equipment represents only 30 to 40 percent of the power consumption in the data center as depicted in the figure below. This means that the power forecasting in the data center must not only include the power consumed by the servers proper, but also the power consumed by the ancillary equipment, including cooling, heating and lighting, which can be over twice the power allocated to servers.

Establishing a power forecast and sizing up a data center based on nameplate will lead to gross underestimation of the actual power needed and unnecessary capital expenses[1]. The over-sizing of the power infrastructure is needed as insurance for the future because of the large uncertainty in the actual power consumption forecast. It does not reflect actual need.

Power allocation in the data center.

A more realistic factor is to de-rate the plate power to a percentage determined by the practices at a particular site. Typical numbers range between 40 percent and 70 percent. Unfortunately, these numbers represent a guess representative over a server’s lifetime and are still overly conservative.

Intel(r) Data Center Manager provides a one year history of power consumption that allows a much tighter bound for power consumption forecasting. At the same time, it is possible to limit power consumption to ensure that group power consumption does not exceed thresholds imposed by the utility power and the power supply infrastructure.

Initial testing performed with Baidu and China Telecom indicates that it is possible to increase rack density by 40 to 60 percent using a pre-existing data center infrastructure.

We will explore other uses in subsequent articles such as managing servers that are overheating and dynamically allocating power to server sub-groups depending on the priority of the applications they run.

[1]Determining Total Cost of Ownership for Data Center and Network Room Infrastructure, APC Paper #6 and Avoiding Costs from Oversizing Data Center and Network Room Infrastructure, APC Paper #37, http://www.apc.com

Actively Managing Power in Nehalem-based Servers: How it Works

egcastroleon — Sat, 04 Apr 2009 00:49:30 GMT

The recently introduced Intel® Xeon® 5500 Series Processor, formerly code named Nehalem brings a number of power management features that not only improve on energy efficiency over previous generations, such as a more aggressive implementation of power proportional computing. Depending on the server design, users of Nehalem-based servers can expect idle power consumption that is about half of the power consumed at full load, down from about two thirds in the previous generation.

A less heralded capability for this new generation of servers is that users can actually adjust the server power consumption and therefore trade off power consumption against performance. This capability is known as power capping. The power capping range is not insignificant. For a dual socket server consuming about 300 watt at full load, the capping range is in the order of 100 watts, that is, for a fully loaded server consuming 300 watts, power consumption can ratcheted down to about 200 watts. The actual numbers depend on the server implementation.

The application of this mechanism for servers deployed in a data center leads to some energy savings. However, perhaps the most valuable aspect of this technology is the operational flexibility it confers to data center operators.

This value comes from two capabilities: First, power capping brings predictable power consumption within the specified power capping range, and second, servers implementing power capping offer actual power readouts as a bonus: their power supplies are PMBus(tm) enabled and their historical power consumption can be retrieved through standard APIs.

With actual historical power data, it is possible to optimize the loading of power limited racks, whereas before the most accurate estimation of power consumption came from derated nameplate data. The nameplate estimation for power consumption is a static measure that requires a considerable safety margin. This conservative approach to power sizing leads to overprovisioning of power. This was OK in those times when energy costs were a second order consideration. That is not the case anymore.

This technology allows dialing the power to be consumed by groups of over a thousand servers, allowing a power control authority of tens of thousands of watts in data centers. How does power capping work? The technology implements power control by taking advantage of the CPU voltage and frequency scaling implemented by the Nehalem architecture. The CPUs are one of the most power consuming components in a server. If we can regulate the power consumed by the CPUs we can have an effect on the power consumed by the whole server. Furthermore, if we can control the power consumed by the thousands of servers in a data center, we'll be able to alter the power consumed in that data center.

Power control for groups of servers is attained by composing power control capabilities of power control of each server. Likewise, power control for a server is attained by composing CPU power control as illustrated in the figure below. We will explain each of the constructs in the rest of this article.

Conceptually, power control for thousands of servers in a data center is implemented through a series of coordinated set of nested mechanisms.

The lowest level is implemented through frequency and voltage scaling: laws of physics dictate that for a given architecture, power consumption is proportional to the CPU's frequency and to the square of the voltage use to power the CPU. There are mechanisms built into the CPU architecture that allow a certain number of discrete combinations of voltage and frequency. Using the ACPI standard nomenclature, these discrete combinations are called P-states, the highest performing state is nominally identified as P0, and the lower power consumption states are identified as P1, P2 and so on. A Nehalem CPU supports about ten states, the actual number depending on the processor model. For the sake of an example, a CPU in P0 may have been assigned a voltage of 1.4 volts and 3.6 GHz, at which point it draws about 100 watts. As the CPU transitions to lower power states, it may have a state P4 using 1.2 volts running at 2.8 GHz and consuming about 70 watts.

The P-states by themselves can't control the power consumed by a server. The CPU itself has no mechanisms to measure the power it consumes. This mechanism is implemented by firmware running in the Nehalem chipset. This firmware implements the Intel(r) Dynamic Node Power Management technology, or Node manager for short.. If what we want is to measure the power consumed by a server, looking only at CPU consumption does not provide the whole picture. For this purpose, the power supplies in Node Manager-enabled servers provide actual power readings for the whole server. It is now possible to establish a classic control feedback loop where we compare a target power against the actual power indicated by the power supplies. The Node Manager code manipulates the P-states up or down until the desired target power is reached. If the desired power lies between two P-states, the Node Manager code rapidly switches between the two states until the average power consumption meets the set power. This is an implementation of another classic control scheme, affectionately called bang-bang control for obvious reasons.

From a data center perspective, regulating power consumption of just a single server is not an interesting capability. We need the means to control servers as a group, and just as we were able to obtain power supply readouts for one server, we need to monitor the power for the group of servers to allow meeting a global power target for that group of servers. This function is provided by a software development kit (SDK), the Intel(r) Data Center Manager or Intel DCM for short. Notice that DCM implements a feedback control mechanism very similar to the mechanism that regulates power consumption for a single server, but at a much larger scale. Instead of watching one or two power supplies, DCM oversees the power consumption of multiple servers or "nodes", whose number can range up to thousands.

Intel DCM was purposely architected as an SDK as a building block for industry players to build more sophisticated and valuable capabilities for the benefit of data center operators. One possible application is shown below, where Intel DCM has been integrated into a Building Management System (BMS) application. Some Node Manager-enabled servers come with inlet temperature sensors. This allows the BMS application to monitor the inlet temperature of group of servers, and if the temperature rises above a certain threshold, it can take a number of measures, from throttling back the power consumed to reduce the thermal stress on that particular area of the data center to alerting system operators. The BMS can also coordinate the power consumed by the server equipment, for instance with the CRAC fan speeds.

With this discussion we have barely begun to scratch the surface of the capabilities from the family of technologies implementing power management. In subsequent notes we'll dig deeper into each of the components and explore how they are implemented, how these technologies can be extended and the extensive range of uses for which they can be applied.

The Curious Case of Virtualized Power, Part 2

egcastroleon — Sun, 15 Mar 2009 18:48:29 GMT

In our previous post we noted that the state of the art power montoring in virtualized environments is much less advanced than power monitoring applied to physical systems. There is a larger historical context, and economic implications in the planning and operation of data centers that make this problem worth exploring.

Let's look at a similar dynamic in a different context: In the region of the globe where I grew up, water used to be so inexpensive that residential use was not metered. The water company would charge a fixed amount every month and that was it. Hence, tenants in an apartment would never see a water bill. The water bill was a predictable cost component in the total cost of the building and included in the rent. Water was essentially an infinite resource and reflecting this fact, there were absolutely no incentives in the system for residents to reign in water use.

As the population increased, water became increasingly a more precious and expensive resource. The water company started installing residential water meters, but bowing to tradition, landlords continued to pay the bills, which was still a very small portion of the overal operating costs. Tenants still had no incentive to save water because they did not see the water bill.

Today there are very few regions in the world where water can be treated as an infinite resources. The cost of water increased so much faster than other cost components to the point that landlords decided to expose this cost to tenants. Hence the practice of tenants paying the specific consumption for the unit they occupy is common today. Also, because this consumption is exposed at the individual unit level, the historical data can be used as the basis for the implementation of water conservation policies, for instance charging penalty rates for use beyond a certain threshold.

The use of power in the data center has been following a similar trajectory. For many years the cost of power had been a noise level item in the cost of operating a data center. It was practical to include the cost of electricity in the bill of the cost of the facilities. Hence IT managers would never see the energy costs. This situation is changing as we speak. See for instance this recent article in Computerworld.

Recent Intel-based server platforms, such as the existing Bensley platform, and more recently, the Nehalem-EP platform to be introduced in March come with instrumented power supplies that allow the monitoring and control of power use at the individual server level. This information allows compiling a historical record of actual power use that is much more accurate than the more traditional method of using derated nameplate power.

The historical information is useful for data center planning purposes by delivering a much tighter forecast, beneficial in two ways: by reducing the need to over-specify the power designed into the facility or by maximizing the amount of equipment that can be deployed for a fixed amount of power available.

From an operational perspective we can expect ever more aggressive implementations of power proportional computing in servers where we see large variations between power consumed at idle vs. power consumed at full load. Ten years ago this variation used to be less than 10 percent. Today 50 percent is not unusual. Data center operators can expect wider swings in data center power demand. Server power management technology provides the means to manage these swings, stay within a data center's power envelope, yet maintain existing service level agreements with customers.

There is still one more complication: with the steep adoption of virtualization in the data center in the past two years starting with consolidation exercises, an increasing portion of business is being transacted using virtualized resources. Under this new environment, using a physical host as the locus for billing power may not be sufficient anymore, especially in multi-tenant environments, where the cost centers for virtual machines running in a host may reside in different departments or even in different companies.

It is reasonable to expect that this mode of fine grained power management at the virtual machine level will take root in cloud computing and hosted environment where resources are typically deployed as virtualized resources. Fine grained power monitoring and management makes sense in an environment where energy and carbon footpring is a major TCO component. To the extent that energy costs are exposed to users along as the MIPS consumed, this information provides the checks and balances and the data to implement rational policies to manage energy consumption.

Based on the considerations above, we see a maturation process for power management practices in a given facility happening in three stages.

Stage 1: Undifferentiated, one bill for the whole facility. Power hogs and energy efficient equipment are thrown in the same pile. Metrics to weed out inefficient equipment are hard to come by.
Stage 2: Power monitoring at the physical host level implemented. Exposes inefficient equipment. Many installations are feeling the pain of increasing energy cost, but organizational inertia prevents passing costs to IT operations. Power monitoring at this level may be too coarse grained, too little, too late for environments that are rapidly transitioning to virtualization with inadequate support for multi-tenancy.
Stage 3: Power monitoring encompasses virtualized environments. This capability would align power monitoring with the unit of delivery of value to customers.

The Curious Case of Virtualized Power

egcastroleon — Sun, 08 Mar 2009 21:44:59 GMT

Given the recent intense focus in the industry around data center power management and the furious pace of the adoption of virtualization, it is remarkable that the subject of power management in virtualized environments has received relatively little attention.

It is fair to say that power management technology has not caught with virtualization.

Here are a few thoughts on this particular subject, which I intend to elaborate in subsequent transmittals.

For historical reasons the power management technology available today had its inception in the physical world where watts consumed in a server can be traced to the watts that came through the power utility feeds. Unfortunately, the semantics of power in virtual machines have yet to be comprehensively defined to industry consensus.

For instance, assume that the operating system running in a virtual image decides to transition the system to the ACPI S3 state, sleep to memory. What we have now is the state of the virtual image preserved in the image's memory with the virtual CPU turned off.

Assuming that the system is not paravirtualized, the operating system can't tell if it's running in a physical or virtual instance. The effect of transitioning to S3 will be purely local to the virtual machine. If the intent of the system operator was to transition the machine to S3 to save power, it does not work this way. The virtual machine still draws resources from the host machine and requires hypervisor attention. Transitioning the host itself to S3 may not be practical as there might be other virtual machines still running, not ready to go to sleep.

Consolidation is another technology for reducing data center power consumption by driving up the server utilization rates. Consolidation for power management is a blunt tool, where applications that used to run in a physical server are now virtualized and squished into a single physical host. The applications are sometimes strange bedfellows. Profiling might have been done to make sure they could coexist, as a priori, static exercise with the virtual machine instances treated as black boxes. There is no attempt to look at the workload profiles inside each virtualized instance and in real time. Power savings come from an almost wishful side effect of repackaging applications formerly running in a dedicated server into virtualized instances.

A capability to map power to virtual machines, in both directions, from physical to virtual and virtual to physical would be useful from an operational perspective. The challenge is twofold, first from a monitoring perspective because there is no commonly agreed method yet to prorate host power consumption to the virtual instances running within, and second from a control perspective. It would be useful to schedule or assign power consumption to virtual machines, allowing end users tomake a tradeoff between power and performance. Fine grained power monitoring would allow prorating power costs to application instances, introducing useful pricing checks and balances encouraging energy consumption instead of the more common method today of hiding energy costs in the facility costs.

Bringing IT to Underserved Markets through Cloud Computing

egcastroleon — Wed, 21 Jan 2009 05:20:48 GMT

In our previous post, A Silent Revolution in the Information Technology Industry we observed that the cycle time to implement and deliver a business application has been steadily decreasing over the past fifty years from several years at the dawn of computing to a few weeks or faster today.

This acceleration of delivery by two or three orders of magnitude is a byproduct a rapidly evolving and maturing current IT infrastructure.

The acceleration comes from the use of pre-built components and our ability to schedule data, applications and compute engines separately, sourcing these resources to the places and methods of lowest cost. We also discovered that this phenomenon is not unique to IT. Most mature industries have become service integrators taking advantage of pre-existing services. In the example of our previous blog entry, it would be foolish a car insurance company wishing to build national coverage to start building a network of car repair shops. Car insurance companies avail themselves of existing car repair shops, and it would be preposterous to think otherwise.

Yet when we think about IT for a large organization, we don't think twice about hundreds of millions of dollars spent in vertically integrated infrastructure, tens of thousands of square feet in huge data centers housing thousands of servers, many of them performing no more than file serving functions and most of the time woefully underutilized.

Under these circumstances it is no surprise that in spite of the proliferation of outsourced services in the past ten years or so, IT is still primarily a privilege for large organizations. It could be argued that this state of affairs is a side effect of the large granularity of IT resources: A 10-employee business may not be able to afford to purchase and maintain a collection of servers, each one dedicated to an application and the associated in house expertise.

Cloud computing is changing the dynamics of application integration and delivery very fast. Service providers in the internet are beginning to offer fine grained services that obviate the need of a large up front capital investment by service consumers: it is no longer necessary to purchase a complete server for data storage even if only a small fraction is used. Storage can be rented fromthe cloud by the gigabyte per month. Virtualization has made it possible for service providers to offer a fractional server for rent for much less than what an in house physical server would cost.

The benefit accrues not only to end user service consumers. It is lowering the cost for new service provider entrants in the market addressing niches that were not profitable before. The Mozy backup service and the Pi Corporation data presence services, recent acquisitions by EMC constitute examples of this new trend.

A consumer may pay just a few dollars a month for a cloud based storage service. This is an example of an IT service scaled down to the consumer market. Instantiating a service takes just a few mouse clicks and a credit card or a Pay Pal funds transfer. Compare this process with the status quo of an "in-house" deployment:

The poor consumer is required to research trade publications and the Internet and identify a suitable backup product. The consumer purchases the product from a software vendor and installs it in the target machine. Once installed, the consumer is required to follow an onerous regime of regular backups.

Even when the backups are scheduled the user needs to be aware of a number of contingencies, such as ensuring the machines are up and running at the time of the scheduled backup, and if the backup is done to a network shared drive, to also ensure that the connection is in working order and that the target machine is up and running.

If the unthinkable happens and there is a problem with the primary drive, some consumers may not have the expertise to perform the repair and recovery and may need to hire a technician at significant cost. Even with this hired expertise, horror of horrors, the consumer may find out in this dire moment that backups are missing or done improperly leading to partial or total data loss.

What is wrong with this picture? First, the end user is being used as the point of integration for the IT process. We have come to accept this situation in an IT context by sheer habit. It would be unacceptable in any other context: would a customer hire a taxi that requires the customer to drive the vehicle?

In our next post we will use a constructive proof of how to build a consumer backup service using more primitive component services.

Using a similar approach, the lowered integration services will not only benefit the consumer end user, but also will create opportunities for service delivery in emerging markets. The fine grained component resources that the cloud makes possible, will enable a new generation of service providers in these markets delivering services specifically tailored for these markets. The potential economic benefit of this new paradigm is potentially enormous.

A Silent Revolution in the Information Technology Industry

egcastroleon — Wed, 17 Dec 2008 21:07:07 GMT

The industrial revolution of the nineteenth century led to the pervasive replacement of manual labor with steel-based machinery powered by coal technology. The visible icons of this revolution are Thomas Newcomen and James Watt with their improvements to the steam engine design.

One aspect that has received little attention is the role of the underlying industrial processes. Railway robber barons did not start from ground zero; they were able to build their empires without having to own coal or iron mines, or having deep knowledge about the extraction technologies. Different grades of steel with known properties became available to build locomotives and steam engines. Manufacturing became more efficient due to a number of standards. Standardized screw sizes in nuts and bolts made these parts interchangeable not only lowered the cost of building the railroad infrastructure, but also made possible the large scale production of firearms that the tycoons needed to defend their lairs.

A similar transformation is happening with the information technology industry. This transformation is being driven by the synergistic interaction of three technologies, virtualization, service orientation and grid computing. As in the industrial revolution, this trio of technologies allows an efficient division of labor. The payoff of this efficiency comes in reduced cost of the delivery of IT services and in their reach across market segments and across geographies. IT services will no longer be the exclusive privilege of large organizations that can afford a sizable in house IT organization; these services will be affordable to small businesses and even individual consumers, and not only in advanced economies but also in developing countries across the world.

There are three essential components to that drives an IT service: the application that defines the service, the data providing the user context, and the computing engines that power the application. Sixty years ago all the pieces were tightly integrated: software was custom built for a specific target machine, and data was essentially an appendage of the code. The industrial evolution analog would be a locomotive manufacturer having to mine the iron ore, doing materials research, making the different kinds of steel and even machining the bolts. This would be an expensive proposition. Since bolts would be unique, the user would be forced to purchase replacement bolts from the locomotive manufacturer. Industries in their initial stages tend to be vertically integrated in this manner, and their products are expensive, limiting their market reach.

An individual consumer can get connected to the world through e-mail in just 10 minutes through a Web mail provider. Fifteen years ago a similar user would have needed expertise to build a TCP/IP stack on top of Windows 3.1, and even with that expertise it would have taken a couple days to set up an ISP account and research and integrate the necessary components. Thirty years ago the user would have had to write a SMTP client or even purchase at least a PDP-11 computer and integrate a Unix stack. It would not have been that easy; it might have been necessary to start by compiling the source code and configuring it specifically for the target machine. A corporate or university research environment would have been necessary to start with a running system to run the compilation.

It is useful to draw an analogy with a mature industry to see this pattern at work. Let's look at the processes used by an automobile insurance company with national coverage to fix a fender bender for a client.

Unless the accident happened in a large city, the company may not even have a local office. The customer calls a toll-free number to file a claim. The insurance company assigns the case to a different company, a settlement company with local presence. An adjuster for the settlement company assesses the damage and refers the case to body shop to have the the repairs done. Meanwhile, the customer is given a temporary replacement vehicle from a car rental company while the repairs are made. We can trace the economic chain ten or twelve more steps until the point where raw materials are extracted. The insurance company can make a business, not because it has expertise in the myriad steps that it takes to deliver their automobile collision service, but because it can rely on a pre-existing infrastructure of services, each one with predictable time and cost. The level of predictability is such that the insurance company can come up with the cost of the insurance policy and reasonably predict what the profit margin will be.

Impressions of the 1st International SOA Symposium, Amsterdam

egcastroleon — Wed, 22 Oct 2008 04:35:47 GMT

The First Annual International SOA Symposium was dubbed by its organizers as "the world's largest and most comprehensive SOA event for practitioners, providing a combination of expert speakers from around the world and a series of SOA training and certification workshops."

The conference, which took place in October 7-8 in Amsterdam, featured about 70 presentations in eleven tracks. Many of the speakers are accomplished book authors in the field representing 22 books already published or as many as 40 if we count the titles under development.

The event was a first, celebrating the coming of age of service orientation and two associated helper technologies, virtualization and distributed computing grids. It is not an overstatement to assert that service orientation has become the new established paradigm by which enterprise applications are to be delivered. Much in the same way that virtualization brought enormous operational flexibility by allowing the decoupling of application instances (virtual machines) from the hardware on which they run, service orientation allows the decoupling of an enterprise function, such as supply chain to be made up of fungible service components.

The mainstreaming of the trio of technologies is borne by their presence in all top five of the InformationWeek 500 Top Innovators in Business Technology for 2008. The top five are

National Semiconductor with an SOA-based multi-partner supply chain system,
Hilton Hotels with a system allowing customers to book individual rooms using grid computing,
Highmark Health for adopting a comprehensive strategy for energy conservation in IT that includes virtualization
Fiserv, for the development a Web 2.0 Facebook application for the company's banking customers that lets users do basic banking tasks such as paying bills, making transfers and checking balances
Unum, a provider of health insurance packages to employers, for integrating more than 300 service operations using SOA; price quotes for new packages, which used to take as long as eight weeks, now are done in less than a week.

One dimension of flexibility is that service components may comprise existing applications that have been service-enabled through middleware, or can be service components from the ground up. Under this paradigm, enterprise applications are built from in-sourced components (i.e., corporate-owned data centers) as well as out-sourced components, such as cloud resources. Interoperability is a given. System architects have the mandate to pick the most economical alternative that meets corporate requirements based on the service components' SLAs.

At this conference, I had the privilege of delivering two presentations, Virtual Service Oriented Grids: A Prescription for Scalable SOA and Scaling the Delivery of IT Services to Consumer Space with SOA based on ideas in the book I co-authored with Jackson He, Mark Chang and Parviz Peiravi. This New Book from Intel Press is due from the printer at the end of October.

In the book we predict the emergence of a cottage industry around SOA. This process seems to be at play at the conference: the main organizer for the event is a comparatively pure play SOA consulting house in the Netherlands called Ordina. It was interesting to see the big companiess like IBM, Microsoft, HP, Oracle and my employer, Intel playing supporting role to a number of small companies. This dynamic reflects the increasing value that the role of integration has as a fraction of the value of an enterprise solution. This is not to say that the big players are soon to become irrelevant. They had prominent roles as presenters, in panels and keynote speakers.

The implications of interoperability and open participation aspects of SOA are potentially momentous. No two-billion dollar fabs are needed to as a ticket to entry. Any small team can band together with an idea and start an SOA company. The only requirements are brains and dedication. The potential for technology leapfrogging in emerging economies cannot be understated. Startups in these countries need not start from zero; re-using components already available from more advanced economies can quickly bootstrap SOA adoption.

I was having lunch the last day when the conference Chairman, Art Ligthart approached me asking if I'd be interested in participating in the panel What is the Value of Service Grids? that afternoon. Other participants would be David Chappell from Oracle and Jim Webber from Thoughtworks, hosted by Herbjörn Wilhelmsen, from Objectware. Mr. Chappell is well known I the industry as the creator of the concept of ESB or enterprise service bus, a central concept to SOA deployments. He presented grids as a software abstraction. I observed that for grids to deliver their design performance it is essential that architects pay attention to the underlying enterprise infrastructure that includes processors and considerations of memory and network latency and bandwidth as well as locality.

If you are interested in the foil sets, I'll be happy to mail you a copy. Please send me a short note to enrique.g.castro-leon at intel.com. If you can't access them for some reason, I'll be happy to mail you a copy. Some ideas in the book are featured in an article in SOA Magazine, issue XXII, Sept 2008.

Enfant Terrible Nicholas G. Carr Strikes Again

egcastroleon — Mon, 20 Oct 2008 21:37:53 GMT

You may recall Nicholas G Carr for his classic Harvard Business Review article about the commoditization of IT.

In his recent book The Big Switch: Rewiring the World, from Edison to Google quoted in Bill Snyder's CIO Magazine article he claims data centers will become obsolete with the adoption of cloud computing.

Looking beyond the hyperbole, my thought is that as the cloud is adopted in the industry, patterns of ownership for data centers will change. The situation won't be black and white, that is, either corporate owned data centers or everything in the cloud.

To the extent that corporate applications have a modular architecture, what we'll see is a gradual outsourcing of non-critical application components to cloud resources. Corporate owned data centers may become smaller, but servers that otherwise would have been there will be purchased by the outsourcing provider. This is consistent with of efficient markets. Coase argues that an optimizing process is at work where the size of an organization (or a data center in this case) is the result of finding the balance between competing tendencies ("transaction costs").

It is hard to believe that data centers will disappear. Companies may decide that their crown jewel applications and data are better run in house. However, to the extent that these applications are modular and federated, non-critical components or components not associated with LOB will be outsourced. Fewer servers will be needed to run the applications, leading to smaller data centers.

The servers needed to run the non-critical functions will not go away; the will be owned (or leased) by the outsourcing provider. These servers will run in a highly optimized, multi-tenant and virtualized environment. The overal effect is that resource usage is optimized over the whole ecosystem.

In this outsourced, multi-tenant environment, manageability and monitoring capabilities become paramount, including the conveyance of metadata across multiple logical levels and the ability to provide multiple logical views to support iron clad SLAs.

Virtualization as an essential ingredient to make the cloud work because it allows applications and their hosts to be scheduled independently. The article also brings issues of security and transparency standing in the way of the cloud. More than a fundamental roadblock, these issues are a function of industry maturity, and it is reasonable to expect that they will be eventually addressed once the outsourced resources become quantifiable with respect to the businesses served.

Microsoft Hyper-V Launch Event in Bellevue

egcastroleon — Fri, 12 Sep 2008 02:23:53 GMT

I had the privilege to get invited to the Microsoft Virtualization Launch event in Bellevue, Washington on September 8, 2008 on occasion of the release of Microsoft Windows Server* 2008. I attended the keynote presentations and a number of technical sessions. I was especially interested in calibrating my experience from the few months before working with Hyper-V as an architect and integrator in putting together a demo that was delivered for the Intel Developer Forum, which took place in San Francisco on August 19-21. Please refer to "[p-11499]" for a detailed account.

The solidity of the product during the months I worked with it was impressive. I've seen behaviors in previous products are technically correct. However, oftentimes with new products (and also with presumably mature products) the system just checks out for a time, or the results of certain operations are ambiguous, yielding a subjective feeling of "mushiness" that does not inspire confidence. None of this happens with the Hyper-V manager user interface. The response was always crisp and the system was good at informing the user about what is happening. At the outset, if the BIOS settings are not correct for running virtualization, it will remind you in very certain terms to turn on hardware support for virtualization and the execute disable bit, even to the point of asking you to power cycle the system before resuming. The claims by Microsoft engineers during the conference about OS and VMM stability are consistent with my own experience.

Hyper-V comes with an extensive set of tools designed to facilitate large-scale deployments, yet they are useful to small enterprises. Examples mentioned: Microsoft Assessment and Planning (MAP) and integration with System Center. The available tools support the complete deployment life cycle.

Microsoft invited Thomas Bittman, a VP and distinguished analyst from Gartner. His vision for virtualization is similar to the one painted extensively a book I co-authored. The alignment of his ideas with those in the book caught my attention. See "[p-11383]". His thesis is that the impact of virtualization comes not from the technology itself, the capability to consolidate workloads and save energy, but from the changes in business models it brings.

"It is now less about the technology and more about process change and cultural change within organizations," said Mr. Bittman. "Virtualization enables alternative delivery models for services. Each virtualized layer can be managed relatively independently or even owned by someone else, for example, streamed applications or employee-owned PCs. This can require major cultural changes for organizations."