1. 2 Configuring the Cloud Inside and out Paul Anderson publications/mysore-2010-talk.pdf School of.

Slides:



Advertisements
Similar presentations
Large-Scale, Adaptive Fabric Configuration for Grid Computing Peter Toft HP Labs, Bristol June 2003 (v1.03) Localised for UK English.
Advertisements

Computer Networks TCP/IP Protocol Suite.
3. Introduction to Strategic Information Systems Planning (SISP)
Analysis of Computer Algorithms
Chapter 1: The Database Environment
Distributed Systems Architectures
Chapter 7 System Models.
Copyright (c) 2002 Japan Network Information Center Introduction of JPNICs New Registry System Izumi Okutani IP Address Section Japan Network Information.
1 Resonance: Dynamic Access Control in Enterprise Networks Ankur Nayak, Alex Reimers, Nick Feamster, Russ Clark School of Computer Science Georgia Institute.
2 Introduction A central issue in supporting interoperability is achieving type compatibility. Type compatibility allows (a) entities developed by various.
ASYCUDA Overview … a summary of the objectives of ASYCUDA implementation projects and features of the software for the Customs computer system.
Relational Database and Data Modeling
By Rick Clements Software Testing 101 By Rick Clements
17 Copyright © 2005, Oracle. All rights reserved. Deploying Applications by Using Java Web Start.
Designing Services for Grid-based Knowledge Discovery A. Congiusta, A. Pugliese, Domenico Talia, P. Trunfio DEIS University of Calabria ITALY
Universität Innsbruck Leopold Franzens Copyright 2006 DERI Innsbruck LarCK Workshop, ISWC/ASWC Busan, Korea 16-Feb-14 Towards Scalable.
Jeopardy Q 1 Q 6 Q 11 Q 16 Q 21 Q 2 Q 7 Q 12 Q 17 Q 22 Q 3 Q 8 Q 13
Jeopardy Q 1 Q 6 Q 11 Q 16 Q 21 Q 2 Q 7 Q 12 Q 17 Q 22 Q 3 Q 8 Q 13
So far Binary numbers Logic gates Digital circuits process data using gates – Half and full adder Data storage – Electronic memory – Magnetic memory –
|epcc| NeSC Workshop Open Issues in Grid Scheduling Ali Anjomshoaa EPCC, University of Edinburgh Tuesday, 21 October 2003 Overview of a Grid Scheduling.
Fawaz Ghali Web 2.0 for the Adaptive Web.
Configuration management
Software change management
Your synergistic outsourcing solution Powered by CTB Solutions, Inc Patent Pending.
Information Systems Today: Managing in the Digital World
Chapter 18 Methodology – Monitoring and Tuning the Operational System Transparencies © Pearson Education Limited 1995, 2005.
Chapter 1: Introduction to Scaling Networks
The Platform as a Service Model for Networking Eric Keller, Jennifer Rexford Princeton University INM/WREN 2010.
Chapter 6 Data Design.
© 2008 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialPresentation_ID 1 Chapter 8: Subnetting IP Networks Network Fundamentals.
Describing Complex Products as Configurations using APL Arrays.
Component-Based Software Engineering Main issues: assemble systems out of (reusable) components compatibility of components.
IONA Technologies Position Paper Constraints and Capabilities for Web Services
Software Requirements
© 2009 VMware Inc. All rights reserved Confidential Overview: vCenter Server Heartbeat Q
Software Processes.
Database System Concepts and Architecture
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 4 Slide 1 Software processes 2.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 27 Slide 1 Quality Management.
Lecture 5: Requirements Engineering
Introduction to Databases
Executional Architecture
Global Analysis and Distributed Systems Software Architecture Lecture # 5-6.
© 2006 Cisco Systems, Inc. All rights reserved.Cisco ConfidentialBCMSN BCMSN Module 1 Lesson 1 Network Requirements.
1 Chapter 11: Data Centre Administration Objectives Data Centre Structure Data Centre Structure Data Centre Administration Data Centre Administration Data.
Chapter 9: Subnetting IP Networks
25 seconds left…...
Copyright 2001 Advanced Strategies, Inc. 1 Data Bridging An Overview Prepared for DIGIT By Advanced Strategies, Inc.
Chapter 10: The Traditional Approach to Design
Systems Analysis and Design in a Changing World, Fifth Edition
We will resume in: 25 Minutes.
Database Administration
Supply Chain Performance Measurement
Supply Chain Performance Measurement
Technical Architectures
Reliability Week 11 - Lecture 2. What do we mean by reliability? Correctness – system/application does what it has to do correctly. Availability – Be.
Course Instructor: Aisha Azeem
VAP What is a Virtual Application ? A virtual application is an application that has been optimized to run on virtual infrastructure. The application software.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reuse.
 Cloud computing  Workflow  Workflow lifecycle  Workflow design  Workflow tools : xcp, eucalyptus, open nebula.
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 12 Slide 1 Distributed Systems Architectures.
1 소프트웨어공학 강좌 Chap 9. Distributed Systems Architectures - Architectural design for software that executes on more than one processor -
SAMANVITHA RAMAYANAM 18 TH FEBRUARY 2010 CPE 691 LAYERED APPLICATION.
1 Object-Oriented Analysis and Design with the Unified Process Figure 13-1 Implementation discipline activities.
Distributed Systems Architectures Chapter 12. Objectives  To explain the advantages and disadvantages of different distributed systems architectures.
Distributed Systems Architectures. Topics covered l Client-server architectures l Distributed object architectures l Inter-organisational computing.
Chapter 6 – Architectural Design
SAMANVITHA RAMAYANAM 18TH FEBRUARY 2010 CPE 691
Chapter 5 Architectural Design.
Presentation transcript:

1

2 Configuring the Cloud Inside and out Paul Anderson publications/mysore-2010-talk.pdf School of

3 Configuration in the Cloud If a hosting provider goes out of business, applications can easily switch to a different provider Processing/storage resources are acquired and released as the demand changes Processes/storage migrate in search of cheaper providers Storage migrates to be closer to the processing The customer-visible service interface remains the same, but the underlying implementation continually changes... The components remain largely the same - their number, location and relationships (configuration) change

4 Other Layers of Configuration Network routing, address assignment, name services System OS, authentication services, file services Virtualisation virtual/physical mapping, storage mapping Services load balancing of a web service The layers of infrastructure which support the cloud services require a similar configuration...

5 Overview Ill explain why I think this is a good idea Ill give some examples of configuration issues at different layers Ill abstract some of the important problems and show how they might be relevant to cloud service configuration Ill say a little about my configuration research 5 It is tempting to treat cloud services as another independent layer with its own configuration procedures and technologies But Id like to argue that it is very useful to consider a more holistic approach to configuration of all the layers...

6 A More Holistic Approach to Configuration ?

7 Layer Dependencies Co-locating highly dependent cloud services requires knowledge/control of the physical locations Migrating a virtual machine involves changes in the network routing and possibly other services Responsive load balancing requires some knowledge of the service characteristics Deploying a redundant service needs to guarantee that the copies do not depend on any common infrastructure How realistic is it to expect to configure layers efficiently without any knowledge/control of the other layers?

8 A More Holistic Approach Provide a common language for different layers to share configuration requirements Support the explicit specification of inter-layer dependencies Support automatic reasoning and validation across the layers Allow configuration problems at one layer to benefit from solutions to similar problems at other layers Speed the development of underlying theories & tools 8 A more holistic approach to specifying configurations would...

9 In The Meantime... But we can learn useful lessons from looking at the problems and approaches in the other layers these may provide good models and examples for configuration at the cloud service level we can better understand the potential problems with inter-layer dependencies 9 Many different communities and perspectives are involved, so there wont be a universal configuration paradigm at any time soon!

10 The Configuration Problem at Other Layers

11 Network Configuration A move towards dynamic configuration under the control of central policies DHCP instead of fixed IP addresses Dynamic DNS Distributed configuration DNS dynamic routing, rather than fixed source-routing Formal verification of properties for reliability, security etc.. 11 Network configuration operates at the layer of switches and routers and addressing etc..

12 System Configuration Specification languages are important describing complex entities Deployment is important Autonomics Mostly centralised, rather than distributed although there is a need for a more distributed approach A need for continuous, incremental changes dont undeploy the dns service System configuration operates at the layer of servers and workstations and clusters and the system software that runs on them...

13 Virtualisation Configuration Both the physical, and the virtual machines need to be configured currently, this usually happens independently There are lots of dependencies between the VMs, network and storage Autonomics is important for failure recovery for load balancing Virtualisation configuration operates at the layer of virtual machines, virtual networks and virtual storage

14 Service Configuration Dependencies between services are important Composition is important services depend on one another in complex ways Deployment and undeployment sequencing are important Elastic services change configuration dynamically in response to demand 14 Service configuration operates at the layer of web servers and load balancers and database services and the relationships between them...

15 Some Common Underlying Issues

16 Degrees of Automation Fully autonomic decisions guided by constraints or policies Selection from a set of canned solutions Fully manual decisions authorised by various different people Some combination of all of the above There is often a tension between the desire for a fully autonomic service, and the need to have some aspects confirmed by a human decision We are interested in a framework which would support an integrated range of approaches...

17 Separation of Concerns Note that an aspect is cross-cutting concern not simply a question of modularity How do we compose these requirements without involving manual negotiation? What happens if they conflict? How do we manage security Many different people (or automatic systems) may have requirements on some aspect of a configuration

18 Specifying Configurations Policies can be implemented directly Service X must not run on the vendor as service Y Declarative aspects can be composed Service Y must run on vendor A,B or C Properties can be proven much more easily But this is a difficult implementation problem potentially a large constraint satisfaction problem There are many advantages to declarative specifications which describe the desired state, rather than the sequence of steps needed to achieve it

19 Deploying Configurations Moving a service from one vendor to another may mean moving many related components the transfer has to be sequenced so that the overall service does not breakl at any point during the transfer Deployment can be compounded by uncertainty on a large scale, there will always be broken services or are they just slow ? or is the monitoring service broken ? Deploying declarative configurations is a planning problem

20 Human Factors Configuration languages need to be clear and simple for a wide range of different users Extreme automation can have unpredictable effects why has the company research experiment just been migrated to the competitors cloud service ? Automatic systems need to explain decisions A flexible framework allows gradual automation 20 Configuration errors are responsible for a large proportion of downtime. Most of these are due to misunderstandings & human error.

21 Distributed Configuration We may not be able to plan the composition and deployment of an entire service in advance It is fairly obvious that we can introduce a hierarchical model but it is not clear how to specify this particularly considering the previous issues such as cross-cutting concerns This problem analogous to moving from conventional to distributed programming For performance and reliability reasons, it is not always practical to evaluate the entire configuration centrally

22 Finally...

23 Summary Exploitation of cloud technology for large-scale applications will entail some difficult configuration issues Many of these issues are alreday problems for other layers of the supporting infrastructure There would be many advantages to a unified configuration framework across the layers But this is not likely to happen soon However, we can learn pehaps something from the problems and solutions at the other layers 23

24 Some Research Issues Declarative languages and constraints Frameworks for integrating manual and automatic decision making Planning configuration change sequences Distributed configuration negotiation Human issues 24

25 Configuring the Cloud Inside and out Paul Anderson publications/mysore-2010-talk.pdf School of