The initiative takes advantage of the advanced planning and optimization technologies in the Elastra Cloud Server. These algorithms in conjunction with Elastra’s modeling languages allow customers to specify metrics they want to explicitly optimize for. If they want to optimize for a metric like the PUE ratio or density of applications on a virtual machine they can use Elastra’s software to facilitate this process. In the example above Application A gets deployed to VM3 for the following reasons:Capabilities meet the Requirements of Application ALowest cost in terms of Electricity of the VMs whose Capabilities meet the Requirements of the ApplicationApplication A doesn’t get deployed to VM 1 because the Cost is too highApplication A doesn’t get deployed to VM 2 because the Capabilities don’t meet the requirements even though the Cost is lower than VM 3
Image from the Uptime institute - http://www.uptimeinstitute.org/symp_pdf/(TUI3004C)DataCenterEnergyEfficiency.pdf
Source: Energy Star – Datacenter Energy Report to Congress 7-25-07http://www.energystar.gov/ia/partners/prod_development/downloads/EPA_Datacenter_Report_Congress_Final1.pdf
The Elastic Modeling Languages are a set of modular languages, defined in OWL v2, that express the end-to-end design requirements, control and operational specifications, and data centre resources & configurations required to enable automated application deployment & management.While the foundation of the modeling languages is in OWL and RDF, developers can interoperate with the Elastra Cloud Server through its RESTful interfaces; all functions available to the Elastra Workbench are available through this interface, which are based on Atom collections and serialized JSON, XML, or RDF (XML or Turtle) entries.The Elastic Modeling Languages provide a balance between enabling users to express declarative, machine-reasonable policy, and procedural know-how for configuration or provisioning.For More Information on the Modeling Languages please view the appendix section for more information on ECML, EDML, and EMML
The Elastra Plan Composer performs explicit reasoning and deliberation on behalf of system administrators. It chooses and organizes actions that the cloud control plane should take, by anticipating the expected outcomes of those actions.The Elastra Plan Composer enables administrators and change boards to synthesize a plan for execution. It analyzes the proposed application designs and infrastructure models, comparing them against a library of actions and outcomes. It then generates a plan guided by preferences or constraints in the models.Extensibility occurs through operational knowledge modules in the Plan Composer. These modules provide searchable, reusable process descriptions that encode the operational know-how for specific subject areas. For example, a “network knowledge module” can interpret and enact a network configuration; a “resource allocation knowledge module” knows how CPU, storage, and memory should be allocated to an application.
The structural view is the primary view to which other views correspond, usually by transforming or constraining the structure of the system.The structural view consists of:Components - Abstract units of software, configuration, and capability requirements, which expose interfaces for communication.Connectors - Abstract units of communication and/or mediation between components, which also may contain software, configuration, and capability requirements, which expose interfaces for binding to components.Components and Connectors can be assembled through interfaces that are described on declared slots.The lifecycle of the component or connector describes the various states available for that element, its transitions, and various requirements for a component or connector to be in that state.Finally, ECML’s extensible views capture higher-level policies such as:Resource Allocation The mapping of components to virtual hosts, storage & network resources.Scalability The policy of specifying components & connectors into tiers, where components and connector bindings are replicated depending on a scaling factor.
Resource elements model scarce infrastructure that must be provisioned and tracked in various pools or zones. Typically resources are data center resources, and EDML includes a virtual data center model to represent common entities such as Hosts, Storage, VLANs, Hypervisors, etc.Configuration elements model software packages or configuration metadata that make up the “bits” of a component or connector, and are installed and started on a set of resources.Categories provide a taxonomy of concepts to provide searchable descriptive metadata for elements in both EDML (Resources and Configuration elements) and ECML (Components, Connectors, etc.).Capabilities capture the features and functions that are available from an enterprise’s shared infrastructure, such as chip architecture, and storage or network capacity. Capabilities are grouped into bundles to expose standardized units of provisioning and configuration for applications to consume. Capabilities are extensible, and are not just decompositions of physical attributes. They can represent a variety of quantitative or qualitative (symbolic) measures
EMML provides elements to describe various configuration items in an IT management system, and their relationships, dependencies or states. Every element in ECML or EDML can be described as some kind of EMML design or resource item, and EMML introduces an independent “Deployed Item” to describe the state of a deployed application. EMML provides a CMDB-like interface for querying, analyzing, versioning, and archiving the configuration state of IT applications as they evolve over time.
Elastra Green It Initiative
Software based approach for energy efficient data centers<br />Solutions for Green IT<br />
Elastra’s Solution for Green IT<br />Overview of Elastra’s Green IT Approach<br />Why is Energy Efficiency Important?<br />How does Elastra Achieve this?<br />Why is Elastra’s Solution Different?<br />2<br />
Software Solution for Optimizing Energy Efficiency in the Datacenter<br />3<br />VM 1<br />Capabilities:<br />4 GB of RAM<br />2 Core<br />Cost: 250W<br />Application A<br />Requirements: 4GB <br />of RAM and 2 Core<br />VM 2<br />Capabilities:<br />2 GB of RAM<br />1 Core<br />Cost: 120W<br />VM 3<br />Capabilities:<br />4 GB of RAM<br />2 Core<br />Cost: 160W<br />Match!<br />
Elastra’s Solution for Green IT<br />Overview of Elastra’s Green IT Approach<br />Why is Energy Efficiency Important?<br />How does Elastra Achieve this?<br />Why is Elastra’s Solution Different?<br />4<br />
Projections Indicate Energy Consumption Could Increase by 25% by 2012<br />5<br />
Datacenter Electricity Costs Expected to Increase by ~23% by 2011<br />6<br />
Elastra’s Solution for Green IT<br />Overview of Elastra’s Green IT Approach<br />Why is Energy Efficiency Important?<br />How does Elastra Achieve this?<br />Why is Elastra’s Solution Different?<br />7<br />
Modeling Languages Describe Resources and Applications<br />8<br />
Plan-Composer Creates Plans Based on ECML and EDML<br />9<br />Plan Composer Architecture<br />Plan <br />Generation<br />ECML and <br />EDML<br />Structural<br />Analyzer<br />Plan Synthesizer<br />Knowledge Modules<br />Lifecycle and Action <br />Generation<br />Install and <br />Configuration<br />Resource <br />Allocation<br />
Modules for Optimizing for Energy Efficiency based on User Defined Attributes<br />10<br />Minimize Energy Usage<br />Assign a energy cost <br />to virtual <br />resources<br />During Plan Composition <br />the system evaluates all <br />virtual resources <br />available<br />Resources are <br />provisioned<br /> to minimize cost<br />Optimize for Power Utilization<br />Determine the metric to <br />evaluate power <br />utilization<br />Assign a cost for how <br />resources <br />contribute to the metric<br />Resources are<br />provisioned to optimize <br />utilization<br />
Elastra’s Solution for Green IT<br />Overview of Elastra’s Green IT Approach<br />Why is Energy Efficiency Important?<br />How does Elastra Achieve this?<br />Why is Elastra’s Solution Different?<br />11<br />
Ours is a Software Oriented Versus Hardware Oriented Approach<br />12<br />vs<br />
We take a Proactive versus Reactive Approach to Energy Efficiency<br />13<br />Proactive Approach<br />Put systems in place to <br />optimize energy efficiency as<br />environment changes<br />Spend less time trying to fix<br />problems because they have<br />been actively managed<br />Reactive Approach<br />Put systems in place to <br />measure electricity usage<br />Spend more time trying to<br />fix efficiency problems after<br />they have occurred<br />