Cloud Federations and the benefits of SDN/NFV

Transcription

1 Cloud Federations and the benefits of SDN/NFV This project has received funding from the European Union s Seventh Framework Programme for research, technological development and demonstration under grant agreement no Albert Vico-Oton, Ph.D. March 2014

2 17 Partners iminds [former IBBT] University of Southampton (IT Innovation) Université Pierre et Marie Curie Paris 6 (UPMC) Fraunhofer Institute for Open Communication Systems (Fraunhofer) Technische Universität Berlin (TUB) The University of Edinburgh (EPCC) Institut National de Recherche en Informatique et en Automatique (INRIA) National ICT Australia (NICTA) ATOS Spain (ATOS) University of Thessaly (UTH) National Technical University of Athens (NTUA) University of Bristol (UNIVBRIS) Fundacio Privada i2cat, Internet i Innovacio Digital a Catalunya (i2cat) European Institute for Research and Strategic Studies in Telecommunications (EUR) Delivery of Advanced Network Technology to Europe (DANTE) Universidad de Cantabria (UC) National Information Society Agency (NIA) 2

3 Experimentation Facilities EPCC BonFIRE testbed Outside EU Sydney: NORBIT testbed UNIVBRIS OFELIA island ilab.t Virtual Wall FuSeCo playground Korea: NORBIT testbed Outside EU ilab.t Wireless lab Grid 5000 PlanetLab Europe Smart Santander facility i2cat OFELIA island NITOS wireless testbed 3 NETMODE wireless testbed

4 Clouds There are as many ways to understand cloud computing as there are organizations, but they mostly fall between two extreme cloud models: Datacenter Virtualization: Cloud as an extension of virtualization in the datacenter; hence looking for a vcloud-like infrastructure automation tool to orchestrate and simplify the management of the virtualized resources. Infrastructure Provision: Cloud as an AWS-like cloud onpremise; hence looking for a provisioning tool to supply virtualized resources on-demand. 4

5 (some) Cloud Federation Challenges Different CPMs Different implementations. Different Locations Different networks Different Users Different User Management Different SLAs Different QoS Not fun! 5

6 SDN and NFV SDN Used in the dynamic configuration of the Network. A key enabler for Federation. Abstraction of the networking details Enabling multi-tenancy NFV Ensure customization, security and isolation on v-networks. Applying locally specific network functions : Firewalling Load Balancing DoS protection BoD 6

7 SDN & NFV The Objective: A customer should be able to: Spin up a N-port isolated virtual network, with its own storage and compute resources, and ultimately its own performance characteristics. The means: Network services, such as load balancing, security and QoS should be mapped into each virtual network depending on customer needs and demands. A packet processing module should/could provide an open NFV application programming interface that lets customers build in their own network functions. 7

8 Fed4FIRE F4F is a complex federated ecosystem F4F is the perfect platform for developing federation tools and experiment with them. F4F encourages the experimentation on heterogeneous grounds allowing for an execution of a large diversity of use cases. Through this mechanisms F4F enables SDN and NFV experimentation on different conditions and scenarios. The OFELIA testbed is part of F4F, enabling F4F users to experiment in SDN. 8

9 Acknowledgement This work was carried out with the support of the Fed4FIRE-project ( Federation for FIRE"), an Integrated project receiving funding from the European Union s Seventh Framework Programme for research, technological development and demonstration under grant agreement no It does not necessarily reflect the views of the European Commission. The European Commission is not liable for any use that may be made of the information contained herein. 9

10 Back up slides 10

11 Main characteristics of Cloud types DATACENTER VIRTUALIZATION INFRASTRUCTURE PROVISION Applications Interfaces Management Capabilities Multi-tiered applications defined in a traditional, enterprise way Feature-rich API and administration portal Complete life-cycle management of virtual and physical resources Cloud Deployment Mostly private Mostly public Internal Design Enterprise Capabilities Datacenter Integration Bottom-up design dictated by the management of datacenter complexity High availability, fault tolerance, replication, scheduling provided by the cloud management platform Easy to adapt to fit into any existing infrastructure environment to leverage IT investments 11 Re-architected applications to fit into the cloud paradigm Simple cloud APIs and selfservice portal Simplified life-cycle management of virtual resources with abstraction of underlying infrastructure Top-down design dictated by the efficient implementation of cloud interfaces Most of them built into the application, as in design for failure Built on new, homogeneous commodity infrastructure Source: