Home > Articles > Web Services > XML

  • Print
  • + Share This
This chapter is from the book

Workload-to-Resources Mapping

Having described the resources and workload managed by the N1 Grid OE, it is now appropriate to explore how the workload is mapped onto the resources. In a traditional system, the operating system scheduler, memory manager, and device driver components map workloads onto processors, memory, and I/O resources based on simple policies. The operating system virtualizes the underlying resources and provisions the workloads onto them. In an N1 Grid system, virtualization and provisioning are also fundamentally important mechanisms that enable the N1 Grid OE to map workload onto resource.

Today, both terms are used to describe work being undertaken to solve the data center management problems enumerated in Chapters 1 and 2. However, they are not usually described within the context of a single systemic view. Consequently, it is often unclear how these technologies should be combined or used together to deliver integrated infrastructure solutions. The N1 Grid vision, and specifically the N1 Grid OE, provides a single context for understanding these two important areas: how they are related, and how they can be combined to provide a single context for developing infrastructure solutions.


In general, virtualization is the abstraction of some entity. Typically, virtualization involves adding a layer of software onto some entity so that the new layer exhibits the interface properties of the original entity. However, this layer hides the true implementation of the virtualized object so that the original entity can be changed or replaced without fundamentally impacting how other entities, which have a dependency on it, interact with it. This provides flexibility.

For example, a storage controller might virtualize a raw disk or a collection of raw disks by presenting a logical unit number (LUN). The LUN has all of the interface properties of a raw disk, yet that LUN might be a part of one physical disk or it might be a whole disk or a collection of disks in a RAID stripe. The point is that whoever or whatever uses the LUN does not need to care about its internal composition. They just use it and automatically take advantage of the properties of a specific underlying implementation (for example, greater performance or availability). Other examples include virtual local area networks (VLANs) and N1 Grid Containers.

Another example of virtualization involves adding a layer of software that changes the level of abstraction of interaction with an object, changing the attributes of the interfaces (for example, to make it more manageable). An example of this would be enabling the N1 Grid OE to manage an application (for example, a database service) based on quality-of-service goals (for example, the average transactional response time), rather than having to manually manage numbers of processors, amount of memory, and I/O allocation directly. Thus, software can be used to translate between the old entity that was managed and the new abstract entity. The administrator of an N1 Grid system manages services, while the N1 Grid OE translates this into the management of more traditional workloads and resources. This means that management scaling can be fundamentally changed and that efficiency, reliability, and agility can be improved through automation.

An operating system or operating environment virtualizes the sets of resources under its control, presenting them to the services that consume them in a consistent fashion (FIGURE 3-2).

03fig02.gifFigure 3-2 Traditional Operating System Virtualization

A traditional operating system like the Solaris OS virtualizes processors, memory, and I/O within a large SMP. The operating system maps a workload onto resources in line with policies. The workload resolves to a set of processes or threads that run on some set of resources. The operating system virtualizes the resources so that they appear equivalent to the application. For example, an application that runs on four processors can run on any four processors within a 32-processor system.

The operating system and the system itself ensure that the identity of physical processors does not matter. Indeed, the actual processors used could change, from one instant to the next, as long as four of them are used. Thus, virtualization turns a collection of discrete, identical resources into a pool of shared resources. This enables greater flexibility and utilization of those resources because they can be efficiently shared. For example, two applications could run and use up all of the 32 processors. However, at any instant, application A could be using any four of the processors, and application B could be using 28. In another instant, application A could be using ten processors, and application B could be using 22. The system decides how many, and which specific ones, to use on behalf of the service, removing complexity and improving performance and utilization.

The N1 Grid system analogy of this (see FIGURE 3-3) is that the N1 Grid OE can turn 200 blade servers into a single pool of resources so that you no longer care which 12 are used for web server instances within a multitier bookstore service. The N1 Grid OE ensures that the right number, that is 12, are used to meet the business goals of the service.

03fig03.gifFigure 3-3 N1 Grid Operating Environment Virtualization

FIGURE 3-4 shows the most basic view of virtualization. If you think about both previously described definitions of virtualization, then you can view the data center as a series of layers of components, each depending on those below it and each virtualizing those below them, either through simply separating the logical properties from the physical entities or through changing the level of abstraction to present new properties to the layers above. Each layer of virtualization provides the opportunity to hide complexity and improve flexibility and efficiency.

03fig04.jpgFigure 3-4 Layers of Virtualization

Unable to access graphic file. File is apparently not in standard EPS format.

Applying this technique to the N1 Grid system means that several of the problems associated with managing data center infrastructures can be addressed. These problems include:

  • Removing complexity

    This improves management scaling, reliability, availability, and security, and it reduces costs and risk.

  • Increasing flexibility

    This enables faster repurposing to recover from failure, faster repurposing to cater to load or goal variation, and faster time to market in deploying new services through the pipeline.

Provisioning Services

The systemic approach, combined with virtualization techniques, also changes the perspective on provisioning services or applications. Provisioning is the act of taking a service, installing it, and ending up with a running service on a system or collection of systems.

Because most provisioning today has a considerable manual element to it and is typically silo-ed (for example, into network, storage, and server-related aspects), it is risk laden, time consuming, and expensive. This results in a reluctance to repurpose infrastructure components, which in turn leads to static environments with poor utilization and a lack of flexibility. The model for provisioning is server-centric, rather than system-centric. If you take a system-centric approach, these problems can be resolved.

Provisioning typically requires the following sequence of events:

  1. Copying the bits somewhere (for example, from a compact disc to storage, associated with a specific operating system instance)

  2. Binding them to the underlying platform instance (base hardware or hardware and operating system stack, if already configured)

  3. Turning them into a service-specific instance

  4. Instantiating them (that is, running them)

Typically, this sequence is done in one or two steps, whereas logically, it might be better to break it down into several separate steps. FIGURE 3-5 shows a comparison of traditional and N1 Grid OE-based steps of provisioning. The new sequence, and tools that automate it, enable more dynamic provisioning in response to load or policy changes.

03fig05.gifFigure 3-5 Flow Between Provisioning Model Phases

Provisioning today is viewed as server-centric. However, it is in fact system-centric, but in the sense of the old system—a server. For example, when installing a database that requires four processors on a 24-processor system, the software is installed to the system, not to four specific processors. Then, the system instantiates the database on the four processors of its choosing, based on policies and goals.

Extending this model to an N1 Grid system, the database is installed to the system, in this case the N1 Grid system. It is then instantiated on any four processors of any platform that meets the dependency requirements of the database. For example, it might require the Solaris 8 OS with patches X, Y, and Z.

The model is in essence the same, if you think in terms of a system. However, the sequence of events changes, or rather, it becomes important. In a traditional view, the ordering of binding to the platform instance and turning a generic component into a specific service instance (for example, turning a generic database installation into the database for a bookstore by creating the table spaces and loading them) is not important. Both have to be done after installing the bits and before running the instance.

The order matters when provisioning within the context of the N1 Grid system. By creating a service-specific instance that is not bound to a specific platform or operating system instance, you end up with a service component (in this case a database) that is able to run on a number of potential platform components. The target platform can be decided at runtime, based on available resources and a comparison of the goals and priorities of this service versus those of others hosted within the same N1 Grid system. Indeed, the target platform can be easily changed if the initial one no longer meets the resource requirements of the service component, due to load or policy changes.

In a traditional system, the database is installed to the system that is a server, and the system runs it on any of the processors it deems appropriate. In an N1 Grid system, the database is installed to the system that is a network. Thus, it is installed on shared storage so that it can be run on any four processors of any server that has the right underlying instruction set architecture and operating system version. Ultimately, it is virtualization that enables this dynamic binding and rebinding.

As an aside, it should be obvious that Java and the J2EE platform become the ultimate in server virtualization technologies. The target platform for a Java or Enterprise JavaBeansTM (EJBTM) component then becomes any J2EE application server that supports the appropriate version of Java or the J2EE platform. Thus, the compute elements are effectively made homogeneous, and maximum flexibility and choice of deployment is achieved.

Virtualization and Provisioning Examples

The following are some simple examples that illustrate the potential of combining virtualization with provisioning, using functionality available today, but within the context of the N1 Grid solutions.

Provisioning a Service Component on an Existing Operating System

This section contains an example of provisioning a service component, such as a database, on an existing operating system instance.

A database can be installed, and table spaces created and loaded, on shared storage, such as network-attached storage (NAS) or SAN storage, so that it can be instantiated on any one of a set of servers, as long as each meets the database requirements in terms of operating system and patch level and each is able to access the storage.

The database can also be provided with its own IP address and host name, independent of those associated with the underlying server, so that they can move with the database service to wherever it is instantiated.

After it has been installed and configured on an initial host environment, the set of variables and configuration parameters that associate it with a specific operating system instance and underlying platform need to be noted. Then, the database can be stopped.

When the database is to be instantiated, the storage containing the database application and that containing the data can be associated with the chosen, preinstalled, and already running target operating system instance. Then, the appropriate operating system tuning can be done, together with the configuration of any other operating system instance-specific dependencies of the database (for example, an IP address).

If the database is to run in a shared environment (that is, one in which the hosting operating system is also hosting one or more other service components), this configuration can be applied to an operating system partition, such as an N1 Grid Container.

Virtualization of the storage environment and of the network, combined with the N1 Grid vision of provisioning, results in a database service that can be instantiated on any server running the correct operating system version and set of patches. This enables the database to be stopped and restarted on a different compute element in the event of changing resource requirements or in the event of underlying platform failures. Repurposing becomes automated and reliable enough to enable greater agility, potentially greater availability, and greater resource utilization.

Provisioning a Service Component as Part of a Complete Bootable Image

This section contains an example of provisioning a service component, such as an application server, as part of a complete bootable image.

Consider an application server instance that is part of a bootable image in a SAN environment. Again, this complete bootable image could be created on a reference server, and all instance-specific tunables and configuration parameters noted. The application server could be a part of a cluster of application servers that act as a front end by a load balancer of some description.

This bootable stack could then be booted on one or more compute elements. If the compute elements are identical, little modification to the boot image would be required during the boot and application server instantiation.

As with the first example, this method results in greater agility, especially if management of the load balancing or application server clustering functionality is automated and integrated with the application server instantiation.

Both of these examples illustrate that the principal behavioral aspects of an N1 Grid system can be realized today. The reasons they are often not are that too many tools must be used to implement this behavior, and because service component instance-specific configuration parameters and tuning information are often not properly understood or noted. In short, implementation is complex and typically a manual process. Thus, it is time consuming and error prone. These implementations become viable only after the configuration information can be formally captured and an integrated mechanism can be provided for associating and binding a service component with an operating system instance or for associating a stack with a compute element. Combining virtualization techniques with a different focus on provisioning results in the ability to provision and reprovision service components dynamically, resulting in better resource utilization, agility, and availability.

Separating the aspect of provisioning that creates a service-specific instance of an application (for example, the creation of the database for the bookstore) from the aspect that binds it to the operating system instance it is to run on (that is, instantiation) is of fundamental importance. Combining this with virtualization to provide flexible mapping between the service-specific instance and an appropriate underlying resource enables enormous flexibility.

Many of the mechanisms required to implement these aspects of an N1 Grid OE exist today. However, to actually deliver this functionality and consequent value, a consistent context is required, and many tools are required to be manipulated or managed, often manually. The lack of such a context and the complexity in terms of available tools result in risk. Thus, infrastructure architectures and implementations that leverage all of the available mechanisms are rarely realized. The goal of the N1 Grid strategy is to both automate this binding or provisioning and to automate the decision-making process that determines what resources to allocate to the service components and how to change them to meet the high-level business goals for the service.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020