Moab workload management engine

Moab is capable to consider almost all measurable entities which are provided in DPC, as resources from which Moab can obtain data and on the basis of which, in turn, can make decisions on planning of these resources for the user services:

The stated above illustration describes basic the torus hurovnevy architecture of Moab:

• At the top level "engine" Moab implements abstract algorithms of decision-making on planning of bstraktny resources, without binding to specific types of resources.
• At the bottom level specific resources of DPC are located.
• Averages, intermediate level it is provided thin interlay which between Moab and real resources. This interlay it is made of so-called resource managers, Resource Managers (RM). Resource managers implement interfe with between Moab and each type of a resource. In practice, resource managers, as a rule, represent themselves trivial scripts.

Communication between Moab and specific resources generally bidirectional. From one party, Moab requests the current value of the resource managed by it from the resource manager. From other party, Moab transfers to the resource manager categorical directives on accomplishment of these or those action over a managed resource, depending on the decision made by Moab. Depending on the nature of a specific resource, the resource manager can implement only a part standard the message which Moab can transfer to this resource manager. The typical situation of such type is represented by a resource which value can be read out, but management of such resource is technically impossible or it is senseless. An example is the set of temperature sensors in DPC. Moab can keep track of values of temperature in different points of DPC to prevent placement of new services on the hottest servers. However, it is technically impossible to manage temperature sensors. In that case, the resource manager connecting Moab with temperature sensors implements for Moab only a possibility of poll flowing value of a resource.

To the Moab resources, obviously, processors, memory, disks belong. However, in an equal measure can be the Moab resources which are taken into account when ensuring the user services

• Less obvious characteristics of server platforms, such as relative level of load during the set reporting period, or the average outbound traffic on set network interfe se.
• Factories of network devices.
• Network storages.
• Bespereboa sources leg of a power supply (UPS).
• The managed modules of power distribution (PDU).
• External systems of monitoring of DPC, such as Ganglia or Nagios.
• External program systems of inventory of software.
• External program systems of control of servers, as a rule, the "vendor" solutions delivered together with hardware platforms.
• Tape backup systems.
• Cooling systems, including sensors of humidity and temperature in DPC.
• Farms of different hypervisors, such as KVM and VMware.

Topology of consolidation of DPCs under control of Moab

At consolidation of remote platforms under control of Moab, three supported topology are naturally selected (or combinations of several of this three topology that is also admissible).

• Peer-to-Peer.

There are exactly two DPCs, everyone is controlled the copy of Moab. In process of filling of resources of "the" DPC, Moab of this DPC transfers new requests for processing in Moab of other DPC. Service migration between DPCs and on other politicians, connected not only only with a lack of local resources is also possible. The general sense of topology of Peer-to-Peer consists available two equal DPCs which exchange services.

• Source Destination Topology.

There is a set of DPCs, everyone is controlled the copy of Moab. Over all DPCs there is one more, central copy of Moab which manages resource allocation between DPCs. The essence of this topology is that it, unlike previous, allows to implement as much as difficult allocation policies of resources between remote DPCs, generally not equal.

• Master-Slave.

There is one DPC managed only by Moab copy. However, under control of Moab there is a set of diverse resources – so diverse that the pool of each resource can be considered the certain platform. So, the DPC in which Moab manages a pool of the servers x86, IBM Power, IBM System z, HP Integrity Superdome, SGI Altix, Cray and Oracle will be an example of Master-Slave, most likely. In spite of the fact that Moab in principle is capable to transfer services between different pools of resources, in this case transfer of service between pools of platforms of different type hardly makes sense as to each view of platforms, most likely, there corresponds the specific loading. The sense of topology of Master-Slave also consists in it: exactly one copy of Moab manages a set of logical platforms, each of which is formed by a pool of a specific resource.

The economic overview of award enforcement based on Moab

In general, this document describes competitive advantages of products based on Moab with emphasis on architectural and technical features. However, for more complete understanding of the mechanism of receiving an economic benefit from architectural advantages the solution based on Moab, in the current section briefly we will provide economic benefits in terms of cost reduction and return of investment

Decrease in a capital expenditure (CapEx) is reached in the following directions:

• Reduction of the initial budget by computing infrastructure of DPC. These are the stvo of the products Adaptive Computing sometimes call the principle of 'Do More With Less'. In practice it means reduction of settlement number of servers which requires to be bought ensuring the set level of service in DPC. The required number of servers decreases due to increase in efficiency of use of servers., application of the products Adaptive Computing allows to increase the settled level of loading of resources (sustained utilization) from 50-60% to 95% and above, is frequent to the settled level close to 100%.
• Consolidation of IT infrastructure in DPC with a possibility of remote access.
• Reduction of periodic budgets by expansion of DPC which is reached by the same method: decrease in number of the servers required for providing the set level of service.