Browse Prior Art Database

Method and Apparatus for Computing Utility Services using Real and Virtual Machines

IP.com Disclosure Number: IPCOM000020254D
Original Publication Date: 2003-Nov-06
Included in the Prior Art Database: 2003-Nov-06
Document File: 2 page(s) / 60K

Publishing Venue

IBM

Abstract

The eUtility model for computing services is generally drawn using an analogy to the electric power utility model. Cost-saving potential to customers is enormous and the market for these services has been projected to grow rapidly (IDC estimates the market opportunity in eUtilities will reach $50 billion by 2003). This disclosure makes a case for a highly efficient approach to implementing an eUtility for server computing services for businesses. The eUtility will consist of server farms consisting entirely of a single-platform machines sharing resources such as network bandwidth and Shark storage devices. An example of single-platform machine would be the eServer zSeries platform. The single-platform server farm will host virtual machines for target platforms that are widely used by businesses (e.g. Windows NT Server on x86, Solaris on Sparc, etc.) As the demand from subscribers rises, more virtual machines for the necessary platforms are spawned and made available to the subscriber. The accuracy of platform emulation guarantees that the subscriber does not have to be aware of the fact that the server is a virtual machine rather than the real one. Native zSeries platforms such as MVS, VM, and TPF are run natively, or as virtual machines depending upon the level of service required.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 40% of the total text.

Page 1 of 2

  Method and Apparatus for Computing Utility Services using Real and Virtual Machines

The eUtility Model

The eUtility model for computing services is generally drawn using an analogy to the electric power utility model. In the electric power utility model, a power provider maintains power generation capacity, and signs up subscribers, providing them with agreements of service-levels guaranteeing a certain quality of service. A subscriber's power needs may vary, and any time he needs more power, he simply draws more of it from the power provider . The provider increases or reduces power generation to match fluctuations in overall customer demand, and charges the subscriber based on a meter reading, modified by factors such as time of day, etc. One huge advantage of this model is that the subscriber does not have to build, operate, maintain, and back-up the power plants, and can draw more or less power as needed without paying for extra local capacity when it is not needed.

In a similar fashion, a computing eUtility would provide server computing power to corporations. A corporation would subscribe to the service for each operating platform on which it runs its server workloads (for example: MVS on zSeries, NT on NetFinity, Linux on NetFinity, Solaris on Sparc). Consider a subscriber which has a higher demand for computing power during the day when the corporation's employees are performing their functions. Responding to the rising demand, the eUtility (compute power provider) will bring additional servers on-line to satisfy the demand and maintain the level of service promised to the subscriber. At night, when there is much lower demand for computing power by the subscriber company, some of the servers employed to satisfy the daytime demand could be detached from the subscriber and returned to an the provider's available compute resource pool. If the subscriber is an e-commerce company, it must stay open for business 24-hours-a-day/7-days-a-week/365-days-a-year, so the demand for server compute power may not fluctuate as much on a daily basis, though the demand would likely rise as the holiday season approaches and subside as the season passes. Be it a brick-and-mortar-type subscriber or 24/7/365 e-commerce-type subscriber, the basic nature of the problem remains the same.

Approaches to building an eUtility

The Java Approach. One approach to building an eUtility is based primarily on Java, and caters to subscribers that want to run only Java workloads. Java workloads run anywhere, so to provide on-demand compute power for Java workloads is easy: install and maintain highly cost-effective server farms; there is no need to install heterogeneous server platforms. This approach is rather limited because it satisfies the needs of only the subset of customers which primarily (or exclusively) use Java to run their businesses; if the customer requires support for a non-Java platform, he must maintain those servers separately.

The Static Mult...