Federated architecture

Transcription

1 Federated architecture Francisco Brasileiro UFCG EUBrazilCC 3rd Technical Meeting, Rio de Janeiro 1

2 Motivation Many scientific applications have bursty workloads Cloudburst excess demand to public clouds is desirable to avoid over provisioned in-house infrastructures Cloudburst to public clouds might not be effective when: Excess demand is too high There are privacy restrictions on the data and programs involved in the computation Federation of private clouds can be an alternative 21-22/10/2014 EUBrazilCC 3rd Technical Meeting, Rio de Janeiro 2

3 Main Challenges How to preserve member s autonomy and deal with: Authentication and authorization Cross-site requests Remote connectivity Interoperability 21-22/10/2014 EUBrazilCC 3rd Technical Meeting, Rio de Janeiro 3

4 Task 3.3 Adaptation and Deployment of Cloud Federation Mechanism [M1-M24] Task leader: Francisco Brasileiro (UFCG) Best-effort community cloud based on a bartering business model Uses spare resources on the private clouds available in the infrastructure Provides an OCCI interface that supports persistent requests for resources that can extrapolate local quotas

5 Main Requirements Every cloud should be able to join the federation with minimal hassle No need to deploy a specific cloud implementation like OpenStack or OpenNebula No need to change the local cloud configuration The cloud admin must simply create a user that will proxy the requests coming from the federation Autonomy to define quota and access policies for this user

6 Fogbow s architecture 21-22/10/2014 EUBrazilCC 3rd Technical Meeting, Rio de Janeiro 6

7 A Fogbow Manager 21-22/10/2014 EUBrazilCC 3rd Technical Meeting, Rio de Janeiro 7

8 Current Release We have released fogbow s second version Provides plug-ins for: OpenStack OpenStack-OCCI OpenNebula Federation authentication and authorization Supports VOMS Supports simple policies for inter-member security policies List of trusted CA s No support for image management No prioritization mechanism (Network of Favours) See for documentation, source code, and development monitoring tools There is a community deployed for testing purposes

9 Task 3.4 Exploitation of Shared Resources in an Opportunistic Federated Cloud [M1-M24] Task leader: Francisco Brasileiro (UFCG) Develop mechanisms to tap idle resources in the workstations connected in a LAN to a best-effort private cloud These private clouds are suitable to be used in the community cloud to be deployed in the context of T3.3

10 Development status Functional implementation for private clouds controlled by OpenStack with PCs running Linux and Windows as compute nodes Leverages on powernap package Supports all idleness policies provided by powernap Started deploying at UFCG Milestone MS3.2 reached (due by M16/January 2015) Future work will include: Support for green IT policies Support for PCs running MacOS

11 Fogbow demo

12 Demo Deployment of fogbow components o fogbow-manager o fogbow-rendezvous o Opportunistic cloud over shared resources The impact of quotas on Fogbow Types of request o one-time o persistent Life-cycle of a request

13 Demo Structure Fogbow Manager Fogbow Rendezvous Open Nebula fogbow: 2 instances Fogbow Manager Fogbow dashboard Fogbow Manager Openstack (cloud.lsd.ufcg.edu.br) fogbow: 5 instances Openstack (local Devstack) fubica: 3 instances fogbow: 5 instances

14 Project Key Indicators for WP3 K3.1 - Percentage of access requests partially provided (ARPP) Target: ARPP > 80% by the end of the first year, for the requests issued in the first year, and ARPP = 100% by the end of the project, for the requests issued during the second year K3.2 - Percentage of access requests fully provided (ARFP) Target: ARFP > 30% by the end of the first year, for the requests issued in the first year, and ARFP > 85% by the end of the project, for the requests issued during the second year. K3.3 - Federation Rate (FR) Expressed by the percentage of partners that provide computing resources with associated facilities federated. Target: FR >=50% by the end of the first year, and FR = 100% by the end of the project. K3.4 - Number of cores exploited opportunistically in an IaaS cloud model (NOC) Target: NOC > 100 by the end of the first year, and NOC > 800 by the end of the project. K3.5 - Number of new releases of the CSGrid middleware (NR) Target: NR >= 1 by the end of the first year, and NR >= 4 by the end of the project.