Utility-based Selection of Resources on Computational Grids

1. Utility-based Selection of Resources on Computational Grids Vinicius Petrucci, Orlando Loques, Alexandre Sztajnberg Instituto de Computação Universidade Federal Fluminense (UFF) vpetrucci,loques@ic.uff.br Instituto de Matemática e Estatística Universidade do Estado do Rio de Janeiro (UERJ) alexszt@uerj.br

2. Key Points • CR-RIO is an architecture-based approach to specify, deploy and manage applications with non-functional requirements (or system qualities) • Grids are being used as generic platforms for sharing any type of resource in network • Utility theory helps make trade-offs where multiple (sometimes conflicting) objectives must be considered to select the best resource in an operating scenario

3. CR-RIO Approach • Contractual Reflective-Reconfigurable Interconnectable Objects • Adopts software architecture as a conceptual abstraction for modelling complex software systems and then for deployment and evolution • Describes and formalizes the dynamic non-functional requirements using architectural contracts • Provides an infrastructure to deploy and manage the application based on the contracts • (Continuously) monitor the resources and adapt the application to current resource availability

4. Contract Language in a nutshell • Categories describe resource properties • Profiles quantify the category properties and represent constraints to architectural components and/or interactions among them • Services describe allowed operating conditions or possible configurations regarding the application’s architecture • Negotiation defines rules to guide the selection of the specific service to be deployed • possible transitions between services Client Terminal Contract

5. Grid • The Grid technology focus on sharing resources to reach high computational capacity • commonly used in scientific applications to solve large-scale computational problems • Now, the Grid is being used as generic platform for sharing any type of resource in network • increasingly being used in multi-user applications, such as games and video conference • The next step in this computing infrastructure is a shift from a closed user group system to a Ubiquitous Computing environment • a grid system must integrate heterogeneous resources with varying quality and availability

6. Autonomic Computing x Grids • Highly dynamic and unpredictable environment • Benefits of geographically dispersed computing requirements • Adaptability and fault tolerance • Dynamically changing user needs • Resource variability • local resources (ex.: CPU, memory) • communication resources (ex.: bandwidth, latency) • Resource discovery • software components, devices and services

7. Autonomic Computing • The ultimate aim is to automate human tasks in system management to achieve high-level stakeholder objectives • One common approach is to capture and represent human expertise in a computer-executable form • When more than one dimension must be considered, representing choice and trade-offs becomes impractical • In short, programmatic or rule-based approach is insufficient for • expressing the necessary adaptation expertise • emulating trade-off decisions in the presence of multiples objectives

8. Utility Functions • Utility function is a mathematical formulation that returns a measure of utility-value given an environment state • Utility is an ordinal (i.e. ordering or ranking) concept • For example, if U(x) = 0.6and U(y) = 0.2 then x is strictly preferred to y. However, x is not necessarily “three times better” than y • Utility functions allow expressing high-level preferences for an application, regarding resource attributes, in a compact and systematic way

9. We describe a state as a vector of attributes (measured or predefined) Autility function maps each possible state of a system or component to a real scalar value on a common scale Actionsrepresent the utility-value of transitioning the system The action that maximizes overall utility is taken Utility-based Model States and actions possible state S1 a1 a1 current state S possible state S2 a2 a3 possible state S3 S = <attr1, ..., attr n>

10. Video Conference Reflectors Problem: in a given Grid domain, with a previously established reflector configuration, a client X wants do join the service refUFF refUERJ Client X refLMPD

11. Video Conference Reflectors Problem: which reflector to use? refUFF ? refUERJ Client X refLMPD

12. Video Conference Reflectors Problem: the client wants to maximize the benefits selecting the “best” Reflector to connect to, e.g., regarding delay and bandwidth attributes refUFF refUERJ Client X refLMPD

13. Video Conference Reflectors Solution: apply an utility function, which specifies the user’s preferences regarding each property, and selects the most useful reflector refUFF refUERJ Client X refLMPD

14. User Preferences • Resource characteristics and properties that can be monitored are defined Category { delay: decreasing numeric ms; bandwidth: increasing numeric Kbps; } Transport; • An utility class is defined based on the class and category properties Utility { delay: pref(Transport.delay) weight 0.6; bandwidth: pref(Transport.bandwidth) weight 0.4; } utilRefl; • The preference function, pref, normalizes the monitored variables and returns a real value between [0,1] • the weight operator defines importance of attributes

15. Contract for a Client Terminal Selection Function prototype @ref = select(ResourceClass,UtilClass); Contract contract { service { (...)‏ link term to @ref = select*(Reflector, reflUtil); } HQTerm; service { (...)‏ } LQTerm; negotiation { (...) } } videoConf; Periodically checks if the current selected component is still the best choice Contract Language

16. Selection Example • Reflector Class = {refUFF, refUERJ, refLMPD} • Monitoring Snapshot: refUFF = {delay:63 ms; bandwidth:578 kps} refUERJ = {delay: 126 ms; bandwidth: 926 kbps} refLMPD = {delay: 27 ms; bandwidth: 414 kbps} • Preference Calculation: pref(refUFF) = {delay: 0.64; bandwidth: 0.32} pref(refUERJ) = {delay: 0.00; bandwidth: 1.00} pref(refLMPD) = {delay: 1.00; bandwidth: 0.00}

17. Selection Example • Overall utility calculation: U(refUFF) = (0.6 * 0.64) + (0.4 * 0.32) = 0.51 U(refUERJ) = (0.6 * 0.00) + (0.4 * 1.00) = 0.40 U(refLMPD) = (0.6 * 1.00) + (0.4 * 0.00) = 0.60 • Selection Process: refUFF 0.51 refUERJ select 0.40 0.60 refLMPD

18. Dynamic Reconfiguration • Environment Change: refUERJ = {delay: 48 ms; bandwidth: 926 kbps} • Preference re-calculation: pref(refUFF) = {delay: 0.00; bandwidth: 0.32} pref(refUERJ) = {delay: 0.42; bandwidth: 1.00} pref(refLMPD) = {delay: 1.00; bandwidth: 0.00} • Overall utility re-calculation: U(refUFF) = (0.6 * 0.00) + (0.4 * 0.32) = 0.13 U(refUERJ) = (0.6 * 0.42) + (0.4 * 1.00) = 0.65 U(refLMPD) = (0.6 * 1.00) + (0.4 * 0.00) = 0.60 • A new reflector is selected =>refUERJ

19. Infrastructure Resource Discovery • Queries a resource repository and the Context Service in a given domain • Accepts a list of profiles • Returns a list of components of a given class that meets the profiles ResourceDiscovery ContextService Query Resources Resource List Context Service • Monitors a (set of) resource Selector Contractor Contract Contract Manager Configurator Contract Manager • Interprets the contracts, selects a service to be negotiated • Commands the Contractors to verify if the profiles are valid

20. Infrastructure ResourceDiscovery Context Service Selector • Selects the best resource given • a component class • A utility function Query Resources Resource List Selector best resource Profiles + utility function + resource class Contractor Contract Contract Manager Configurator

21. Infrastructure ResourceDiscovery ContextService Query Resources Resource List Selector best resource Profiles + utility function + resource class Contractor Profiles Contract Contract Manager Validation / Violation Configurator Contractor • Gets local resource demands (profiles) form the CM • Manages and mediates the monitoring process

22. Infrastructure ResourceDiscovery ContextService Contract Manager • Commands the Configurator to deploy the architectural components or • Selects another service to negotiate according to the policy specified Query Resources Resource List Selector best resource Profiles + utility function + resource class Contractor Profiles Contract Contract Manager Validation / Violation Effect configuration Configurator Contractor • Validations and validations of the profiles are notified to the CM Configurator • Effectuates (re)configurations

23. Infrastructure ResourceDiscovery ContextService Selector (select*) • Continuously queries the Resource Discovery and computes the utility function • Notifies the Contract manager if a even better utility value is found Query Resources Resource List Selector Notify +best resouce Profiles + utility function + resource class Contractor Profiles Contract Contract Manager Validation / Violation Effect configuration Configurator

24. Final Remarks • Grid as a candidate for provisioning computational services to applications in ubiquitous computing environments • Utility-based selection mechanism allows handling complex-decision cases, catering for the balance of multiple (many times conflicting) objectives that depend on the combination of several variables of the environment • Our approach can also be applied on the configuration of services • the reflector overlay network topology and component selection

25. Future Steps • Prototype implementation and results • CR-RIO framework • Globus services, NWS, Remos • Disruption on reconfigurations • notion of cost of change associated with swapping a component • Learning services • machine learning techniques • a learned function is employed for future automation