aci advanced$cloud$infrastructures$people.rennes.inria.fr/christine.morin/wp-content/... ·...
TRANSCRIPT
ACI Advanced Cloud Infrastructures
Master 2 SIF & CCS University of Rennes 1 EIT Digital Master school
ChrisAne Morin
Outline
• IntroducAon to distributed cloud compuAng • Interconnected clouds • Distributed clouds
19/09/17 2
Cloud Service Models
19/09/17 3
From TOOSI, Adel Nadjaran, CALHEIROS, Rodrigo N., et BUYYA, Rajkumar. Interconnected cloud compuAng environments: Challenges, taxonomy, and survey. ACM CompuAng Surveys (CSUR), 2014, vol. 47, no 1.
Cloud Stakeholders
• Cloud providers (CP) – Offer uAlity compuAng services required by cloud users
• Cloud users – So[ware applicaAon service providers (SP) who have their service customers
• Offer economically efficient services using hardware provisioned by cloud providers
– End-‐users who use cloud services directly
19/09/17 4
Cloud Market
CP 1
CP 2
CP 3
CP 4
CP 5
19/09/17 5
Cloud Market
19/09/17 6
Issues Raised for Users • Which cloud provider to host my informaAon system? • How to select the right cloud provider(s) for my applicaAon? • How to select the right set of cloud services for my applicaAon? • How to opAmize the cost of running my applicaAon in the cloud? • How to get the best performance for my applicaAon? • What kind of virtual machines do I need for my applicaAon? • Can I move my applicaAon from one cloud provider to another
one? Vendor lock-‐in issue. • How can my cloud applicaAon adapt to fluctuaAng condiAons? • How can I get at any Ame all the resources needed by my
applicaAon if my private cloud can’t provide them? • How can my applicaAon tolerate cloud failures?
19/09/17 7
MoAvaAon for Interoperability: the Cloud Providers Point of view
• Scalability and wider resource availability – Capacity of a cloud provider’s datacenters is limited and eventually can be fully uAlized
• Infinite pool of resources is an illusion • Currently handle by datacenter overprovisioning resulAng in large expenses for cloud owners
Cloud federaCons
19/09/17 8
MoAvaAon for Interoperability: the Cloud Providers Point of view
• Availability and disaster recovery – Failures may affect a single cloud system leading to service interrupAon
– Mechanisms to relocate the resources among mulAple cloud systems
Cloud federaCons
19/09/17 9
MoAvaAon for Interoperability: the Cloud Providers Point of view
• Geographic distribuCon and low-‐latency access – Unlikely that a cloud provider owns datacenters in all geographic locaAons of the world
– Hard to predict the geographic distribuAon of users consuming a cloud provider’s services
– Mechanisms needed to automaAcally coordinate load distribuAon between mulAple clouds in order to saAsfy applicaAon QoS under variable load, resource and network condiAons
19/09/17 10
MoAvaAon for Interoperability: the Cloud Providers Point of view
• Legal issues and meeCng regulaCons – Many customers have specific restricAons about the legal boundaries in which their data or applicaAon can be hosted
– Cloud interoperability as an opportunity for a provider to idenAfy another provider able to meet the regulaAons due to the locaAon of its datacenter
19/09/17 11
MoAvaAon for Interoperability: the Cloud Providers Point of view
• Cost Efficiency and Saving Energy – Cloud providers should avoid the problems of
• Idle capacity – Under-‐uAlizaAon of their hardware
• Peaks in demand – Their own systems are overloaded for a period
– Average demand is several Ames smaller than the peak demand
• Cloud providers can lease their resources to other cloud providers – Avoid wasAng unused resources
• Cloud providers can purchase resources from other cloud providers
– To manage peaks of demand • Lower energy consumpAon
19/09/17 12
Cloud Interoperability Scenarios
• VerAcal federaAon – InterconnecAon between clouds at different levels in the cloud service model stack
• Between a PaaS and IaaS cloud provider – Heroku provides PaaS services on top of Amazon EC2 – Some PaaS systems can run on top different IaaS cloud providers
• Horizontal federaAon – InterconnecAon between clouds at the same level in the cloud service model stack
19/09/17 13
Provider-‐centric vs Client-‐centric Interoperability
• Provider-‐centric interoperability – Requires cloud providers to adopt and implement standard interfaces, protocols, formats and architectural components to facilitate interoperability
• Client-‐centric interoperability – Not supported by cloud providers – IniAated by cloud customers or by third-‐party brokers – No prior business agreement between cloud providers – Minimal or no adopAon of common interfaces
19/09/17 14
Cloud Interoperability Scenarios
19/09/17 15
From TOOSI, Adel Nadjaran, CALHEIROS, Rodrigo N., et BUYYA, Rajkumar. Interconnected cloud compuAng environments: Challenges, taxonomy, and survey. ACM CompuAng Surveys (CSUR), 2014, vol. 47, no 1.
Federated Cloud
• Service provider has a contract with a single cloud provider • Service provider is unaware of the federaCon • The cloud provider is part of a federaAon and trades resources with the other cloud providers of the federaAon to deliver the compuAng uAlity service
19/09/17 16
From TOOSI, Adel Nadjaran, CALHEIROS, Rodrigo N., et BUYYA, Rajkumar. Interconnected cloud compuAng environments: Challenges, taxonomy, and survey. ACM CompuAng Surveys (CSUR), 2014, vol. 47, no 1.
Hybrid Cloud
• An organizaAon that owns its private cloud moves part of its operaAon to external cloud providers. • The service providers and end-‐users applicaAon can scale out through both private and public clouds when the local infrastructure is insufficient.
19/09/17 17 From TOOSI, Adel Nadjaran, CALHEIROS, Rodrigo N., et BUYYA, Rajkumar. Interconnected cloud compuAng environments: Challenges, taxonomy, and survey. ACM CompuAng Surveys (CSUR), 2014, vol. 47, no 1.
MulAcloud Scenario
• The service providers and end-‐users are responsible for managing resources across mulCple clouds:
• service deployment • negoAaAon with each cloud provider • monitoring each cloud provider during service operaAon
• An adapter layer or proper abstracCon library may be needed to run services on different clouds • A separated layer handles aggregaAon and integraAon issues
• Cloud providers not involved at all 19/09/17 18
From
TOOSI, A
del N
adjaran, CALHE
IROS, Rod
rigo N., et BUYYA, Rajkumar.
Intercon
nected
cloud
com
puAn
g en
vironm
ents: C
hallenges, taxon
omy,
and survey. A
CM Com
puAn
g Surveys (CSUR), 2014, vol. 47, no 1.
Aggregated Service Broker Scenario
Broker = new stakeholder as a single entry point to mulAple cloud providers • The broker aggregates services from mulAple cloud providers and offers an integrated service to service providers and end-‐users. • Cloud providers may have to install some internal components to support aggregated services by a trusted broker.
19/09/17 19
From
TOOSI, A
del N
adjaran, CALHE
IROS, Rod
rigo N., et BUYYA, Rajkumar.
Intercon
nected
cloud
com
puAn
g en
vironm
ents: C
hallenges, taxon
omy,
and survey. A
CM Com
puAn
g Surveys (CSUR), 2014, vol. 47, no 1.
The Inter-‐cloud Vision Inter-‐cloud term introduced by CISCO [Bernstein 2009]
an interconnected global cloud of clouds (analogy with the Internet – network of networks)
19/09/17 20 From TOOSI, Adel Nadjaran, CALHEIROS, Rodrigo N., et BUYYA, Rajkumar. Interconnected cloud compuAng environments: Challenges, taxonomy, and survey. ACM CompuAng Surveys (CSUR), 2014, vol. 47, no 1.
Inter-‐cloud Challenges
• Provisioning • Portability • Service Level Agreement (SLA) • Security • Monitoring • Economy • Network • Autonomics
19/09/17 21
Provisioning • Discovery
– AutomaAc detecAon of services and resources offered by cloud providers on the Internet
• SelecCon – OpAmal applicaAon deployment requires an effecAve selecAon strategy that works based on QoS criteria and returns the set of most suitable cloud services for end-‐users.
• AllocaCon – End-‐user’s service selecAon leads to resources allocaAon on the cloud provider’s side.
19/09/17 22
Discovery
A Variety of Cloud Services
• IaaS offering – Instance type
• Capacity, operaAng system – Pricing model
• On-‐demand • Spot instances • Reserved • Dedicated host
– VM with pre-‐installed so[ware • E.g. database
19/09/17 24
25
Service Offered – Instances
26
Service Offered – Instances
27
Service Offered – Market Place
28
Service Offered – Market Place
A variety of Cloud Services • PaaS differenAaAng factors
– Targeted applicaAon family • Web service, HPC, data processing…
– Supported languages – Services offered
• Auto-‐scaling, load-‐balancing, fault-‐tolerance – Resources used
• Proprietary, public resources • Resource from one or several clouds
– Type of architecture • Virtual machines or containers • Resources dedicated to an applicaAon
– Pricing model • Pay-‐as-‐you-‐go, subscripAon
19/09/17 29
Discovery • Cloud providers offer a variety of services and different ways to
describe them – Cloud providers offer limited discovery services at best
• Lack of integrated repository of cloud services – Peer-‐to-‐peer cloud service discovery over a DHT overlay network – Intercloud Root instances and Intercloud exchanges
• Service catalog giving an abstracted view of cloud resources • No common understanding regarding service funcAonaliAes, QoS,
metrics among cloud providers and customers • Difficult to enforce a common syntax to describe cloud services and
common metrics – Ontology-‐based approaches
• Cloud services change constantly and are dynamic in nature – Framework to manage dynamic apributes
19/09/17 30
SelecAon
• Currently: manual selecAon of cloud services by cloud customers – Difficult task given the diversity of cloud services’ characterisAcs and QoS
• AutomaAc selecAon for applicaAon deployment = a highly desirable feature – Different aspects to opAmize: latency, reliability, throughput; data transfer, cost
– Constraints to take into account: legal issues or security
19/09/17 31
SelecAon Process • Based on staAc informaAon on the service quality provided by
cloud providers – OPTIMIS deployment engine
• Risk assessor provides a mulA-‐criteria evaluaAon of cloud services (past performance, maintenance, security, customer support, legal aspects)
– Cloud service selecAon framework in the cloud market to recommend best services from different cloud providers that match user requirements [Han et al 2009]
• Ranking of different services with providers – RepresentaAon of cloud services and resources as web services
• Leveraging the work done in SOA to select resources
• Dynamic negoAaAon of SLA – agent-‐based dynamic negoAaAon for cloud services (mOSAIC project) – SLA negoAaAon in federated clouds (Contrail project)
19/09/17 32
AllocaAon • Resource allocaAon is challenging for cloud providers – Virtualized resources offered based on different QoS levels
– Physical resources shared between mulAple users • Allocate resources to the requests in a profitable manner while fulfilling requests’ QoS requirements – Cloud federaAons prone to resource contenAon
• Request that cannot be admiped, not enough resources as they are used for other requests
19/09/17 33
Resource AllocaAon in Cloud FederaAons
• Market based approaches – Dynamic pricing scheme for federated sharing of compuAng resources where federaAon parAcipants provide and use resources
• Percentage of successful requests and of allocated resources increased in comparison with fixed pricing
– Meryn system opAmizing the PaaS provider profit in cloud bursAng scenarios
• On-‐demand request to a third party or terminaAon of on-‐going requests
19/09/17 34
Portability
• Virtual machine mobility – Problem solved for VM live migraAon within a data center
• Shared storage system • Hosts connected on the same LAN
– Difficult between different clouds • Independent storage and network and separated by firewalls
• State transfer over a WAN between the two clouds
19/09/17 35
Cross-‐cloud VM MigraAon
• Requirements – Memory and state transfer between hosts residing in different data centers
– Same LAN access by VMs at the desAnaAon host, without 2 sites sharing LAN
– Same storage access by VMs at the desAnaAon host, without 2 sites sharing storage
19/09/17 36
Cross-‐cloud VM MigraAon
• Extending LANs between sites using WAN encapsulaAon technologies (e.g. VMware F5, Cisco and VMware MigraAon soluAon) – May violate providers’ IT infrastructure autonomy, security and privacy
• Virtual networking technology allowing VMs connected to the same virtual network to communicate with each other over a private and isolated virtual network within and across clouds – Examples: Vine, VNET
19/09/17 37
ViNe Virtual Network
• ViNe developed at the University of Florida – All-‐to-‐all connecAvity between virtual machines of different clouds (on different physical networks)
– Targets high performance communicaAon • Principle: network overlay on Internet connecAons
– Resources can use private IP addresses – Resources can be in networks behind NATs or firewalls
19/09/17 38
ViNe Architecture
• Two kinds of components – ViNe nodes (VN)
• Communicate directly with each other or through the ViNe infrastructure
– ViNe routers (VR) • Create an overlay for forwarding the traffic between VNs which cannot communicate directly
19/09/17 39
Network transparency issues
• MigraAon from one subnet to another – Conflicts
• MAC address conflicts • IP address conflicts
– RouAng • From/to virtual machines of the same subnet • From/to virtual machines of other subnets
19/09/17 40
SoluAon selected for ViNe
• Configure ViNe as a big network – All machines believe they are in the same LAN – Use ARP proxy to allow traffic between LANs – Use the ViNe infrastructure to tunnel traffic
• A[er migraAon: – Use gratuitous ARP packets to
• Redirect traffic to ViNe routers • Enable direct communicaAon in the same LAN
19/09/17 41
Single Machine Live MigraAon (1/3)
Cloud B
Cloud A
Cloud C
19/09/17 42
Single Machine Live MigraAon (2/3)
ARP: I am the migrated VM
ARP: I am the VMs from the origin LAN
ARP: The migrated VM is in this LAN now
ARP: The migrated VM is in this LAN now
Cloud B
Cloud A
Cloud C
19/09/17 43
Single Machine Live MigraAon (3/3)
Cloud B
Cloud A
Cloud C
19/09/17 44
Single Machine Live MigraAon (3/3)
Maurício Tsugawa, Pierre Riteau, Andréa Matsunaga, José Fortes.
User-‐level Virtual Networking Mechanisms to Support Virtual Machine
MigraAon Over MulAple Clouds.
In IEEE InternaAonal Workshop on Management of Emerging Networks
and Services, 2010.
19/09/17 45
Data Portability
• Users and applicaAons store data in the cloud – Data services from other cloud providers may access the data
• Giving users control over their data to establish trust – Users need to be able to move their data from one cloud to another one
– Industry standards and exporAng tools needed to avoid vendor lock-‐in
19/09/17 46
SoluAons to Avoid Data Lock-‐in • Using API that have mulAple independent implementaAons
– E.g. Amazon EC2 API • Choosing an API that can run on mulAple clouds
– E.g. MapReduce and Hadoop – Resilin system to run Hadoop MapReduce on resources from mulAple clouds
• Decoupling the cloud-‐specific code of the applicaAon designed for each cloud provider from the applicaAon logic layer
• CreaAon of widespread standards and APIs • UAlizaAon of vendor-‐independent cloud abstracAon layers
such as jclouds and libcloud
19/09/17 47
Data Mobility • Google liberaAon front
– Goal: to make easier to move data in and out Google products – Google Takeout to allow users to export any data they create
• Cloud Storage AbstracAon Layer (CSAL) – To enable portable cloud applicaAons – Three storage abstracAons: blobs, tables, queues – Manages metadata necessary to use storage services across mulAple clouds
• MetaStorage – Federated cloud storage system that replicates data on top of diverse storage services using scalable distributed hash tables
• XtreemFS cloud storage system for cloud federaAons
19/09/17 48
Service Level Agreement (SLA)
• An SLA is a contract between cloud providers and customers. It describes – Provided service
• Set of expected service-‐level objecAves (QoS expectaAons)
– Rights and obligaAons – PenalAes
19/09/17 49
SLA Management in Cloud FederaAon
User
Federation Service
Cloud Provider Cloud Provider
• Each parAcipant cloud has its own SLA management mechanisms • Role of the federaAon service:
• set up and enforce a global SLA • monitor the applicaAon to verify that the SLA is
met by providers and react to SLA violaAons • SLA negoAaAon for each user request
• An applicaAon may use services from mulAple cloud providers
19/09/17 50
FederaAon-‐Level Agreement
• Providers parAcipaAng to a federaAon sign a contract when joining the federaAon – Rules for minimum resources contributed to the federaAon
– Set of QoS such as minimum availability
19/09/17 51
SLA Monitoring
• Need to monitor QoS in a federaAon to verify if it matches the end-‐user QoS requirements
• Dependencies between services when the provider uses other cloud services to provide its service – QoS of the applicaAon can be affected by the external services
– Need to model the dependencies between services
19/09/17 52
Legal Issues • Privacy and security • Issues related to the locaAon and ownership of data – Different countries have different laws – Mechanisms needed to guarantee the security and privacy of sensiAve data within legal borders
– Geo-‐locaAon and legislaAon awareness policies must be imposed into the enAty acAng as a mediator between the cloud consumer and interoperable cloud providers (broker, federaAon layer)
• Business consideraAons
19/09/17 53
Reading List • TOOSI, Adel Nadjaran, CALHEIROS, Rodrigo N., et BUYYA, Rajkumar. Interconnected cloud compuAng
environments: Challenges, taxonomy, and survey. ACM CompuAng Surveys (CSUR), 2014, vol. 47, no 1. • Contrail: Distributed ApplicaAon Deployment under SLA in Federated Heterogeneous Clouds, Roberto
Cascella, Blasi Lorenzo, Yvon Jégou, Massimo Coppola, ChrisAne Morin, Galis, Alex and Gavras, Anastasius. FIA book 2013, 7858, Springer, 2013, Lecture Notes in Computer Science.
• Maurício Tsugawa, Pierre Riteau, Andréa Matsunaga, José Fortes. User-‐level Virtual Networking Mechanisms to Support Virtual Machine MigraAon Over MulAple Clouds. In IEEE InternaAonal Workshop on Management of Emerging Networks and Services, 2010.
• Managing OVF applicaAons under SLA constraints on Contrail Virtual ExecuAon Plaworm, Yvon Jégou, Piyush Harsh, Roberto Gioacchino Cascella, Florian Dudouet, ChrisAne Morin, 6th InternaAonal DMTF Academic Alliance Workshop on Systems and VirtualizaAon Management: Standards and the Cloud, Oct 2012, Las Vegas, United States. 2012.
• Using Open Standards for Interoperability -‐ Issues, SoluAons, and Challenges facing Cloud CompuAng, Piyush Harsh, Florian Dudouet, Roberto G. Cascella, Yvon Jégou, ChrisAne Morin, 6th InternaAonal DMTF Academic Alliance Workshop on Systems and VirtualizaAon Management: Standards and the Cloud, Oct 2012, Las Vegas, United States. 2012.
• SLA-‐based PaaS profit opAmizaAon, Djawida Dib, Nikos Parlavantzas, ChrisAne Morin, Concurrency and ComputaAon: PracAce and Experience, Wiley, 2017, 〈10.1002/cpe.4251〉
• Daleel: Simplifying cloud instance selecAon using machine learning, F Samreen, Y ElkhaAb, M Rowe, GS Blair, Network OperaAons and Management Symposium (NOMS), 2016 IEEE/IFIP, 557-‐563
19/09/17 54