Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "Federated Cloud PaaS"

From EGIWiki
Jump to navigation Jump to search
 
Line 1: Line 1:
{{Fedcloud_Menu}} {{TOC_right}}
#REDIRECT [[Federated_Cloud_IaaS_Orchestration]]
 
'''This page is maintained as a collaborative effort by members of the EGI Federated Cloud User support team. Please help us improve the content: Edit the page directly, or email change requests to support@egi.eu.'''
 
EGI federates Infrastructure as a Service (IaaS) cloud providers into the EGI Federated Cloud. IaaS provides the means to programmatically manage your basic infrastructure: processing power as Virtual Machines and  block and object storage. However as applications grow in complexity managing the individual resources that support the application execution may be better handled by automatic deployment tools or Platform as a Service (PaaS) solutions that allow to develop, run, and manage applications without the complexity of building and maintaining the infrastructure.
 
= Orchestrators =
 
Orchestration automates the deployment of resources on cloud services. Orchestrators normally use some sort of domain specific language or script that defines your application deployment process, that is translated to a set of tasks that interact with the cloud services to start Virtual Machines, Storage, Networks and other kind of resources and services where your application will be installed and run.
 
There are several Orchestration tools that are able to manage resources of the EGI Federated Cloud, each of them with different design approaches that may suit your application needs. The following table summarizes the current supported tools:
 
 
{|{{Egi-table}}
|-
! Name
! Stacks supported
! OCCI support
! Main Features
! Step by step guide
|-
| [http://www.grycap.upv.es/im/index.php IM]
| OpenNebula, OCCI, Amazon EC2, Google Cloud Platform, Microsoft Azure, Docker, Kubernetes, FogBow, OpenStack, libvirt and EGI Federated Cloud.
| Yes
| TBC
| TBC
|-
| [http://occopus.lpds.sztaki.hu/ OCCOPUS]
| Amazon EC2, Openstack, OCCI, CloudBroker, Docker
| Yes
| TBC
| TBC
|-
| [http://www.karamel.io Karamel]
| Amazon EC2, Google Cloud Platform, OpenStack, Bare Metal
| In progress
| TBC Karamel is built on [http://www.chef.io Chef]. The distributed system or experiment is defined in YAML as a set of node groups that each implement a number of Chef recipes, where the Chef cookbooks are deployed on github.
| TBC
|-
| [http://sixsq.com/products/slipstream/ SlipStream]
| OpenStack, OCCI, Amazon EC2, CloudSigma, okeanos, CloudStack
| Yes
| TBC
| TBC
|-
|}
 
= Application Brokers =
 
An application broker abstracts the Cloud infrastructure and frees you from the need to control the deployment of the application. Once you have integrated your application into the broker, it will take care of starting the virtual servers according to the workload, configure them and dispatch the user jobs. The effort to integrate your application into the application broker depends on the application and the broker itself. The most common process, anyway, is to use basic OS images with contextualization or a custom OS image, to which you add the application broker worker node routines.
 
When your application performs parallel processing, using an application broker may speed-up the application execution, since the broker will take the task to submit the processing to different servers, using a wider number of resources.
 
Each application broker is usually suited to a specific use case, they may offer a sort of PaaS or SaaS environment for the applications (ex. Grid clusters, Hadoop clusters, etc...) or integrate applications via wrappers written in Java or other programming languages.
 
The following table shows the application broker solutions currently supported by the EGI Federated Cloud. For information about these application broker solutions, please, visit the web sites linked in the table.
 
{|{{Egi-table}}
|-
! Name
! Cloud Stacks supported
! OCCI support
! Main Features
! Step by step guide
|-
| [http://www.catania-science-gateways.it/ Catania Science Gateway Framework]
| OpenStack, OpenNebula and Synnefo
| Yes, via a JSAGA rOCCI adaptor
|
The CSGF allows users to execute applications on the EGI Federated Cloud through web portals/SGs. The Science Gateways based on CSGF provide users with intuitive web interface to execute applications on the Cloud as jobs and to manage these jobs during their running (check the status and download the output). The SGs takes care of starting the VMs on the EGI Federated Cloud, transfer the needed files (e.g. executable, input files, etc.), stop the VMs and download the output in behalf of the user.<BR>
If you need any assistance or user support, contact the CSGF team at sg-licence@ct.infn.it
| [[Fedcloud-tf:How_to_use_the_Catania_Science_Gateway_Framework_as_Application_Broker|CSGF as Application Broker How To]]
|-
| [http://www.bsc.es/compss COMPSs]
| OpenStack, OpenNebula, Azure, Amazon
| Yes, support of rOCCI servers and OCCI+OVF
| Automatic parallelization and orchestration of applications and services, elasticity, auto scaling
| [[Fedcloud-tf:How_to_use_COMPSs|COMPSs How To]]
|-
| [https://github.com/DIRACGrid/VMDIRAC/wiki VMDIRAC]
| OpenNebula, OpenStack, CloudStack and Amazon EC2
| YES
| Accounting, monitoring, brokering, scheduling, automatic contextualization with cloudinit
| [[Fedcloud-tf:How_to_use_VMDIRAC|VMDIRAC as Application Broker How To]]
|-
| [https://guse-cloud-gateway.sztaki.hu/ WSPGRADE]
| OpenNebula, OpenStack and Amazon EC2
| YES through the rOCCI servers
|
WS-PGRADE/gUSE is a job submission tool to clouds. If you have got a job to run in the cloud you specify only the executable, its input parameters and the name of the result files via a simple user interface as well as the cloud of EGI FedCloud where you want to run your job and then your job will run in the selected cloud. The result file will be available for download from WS-PGRADE/gUSE. To learn the use of this feature is about 10 minutes. (See the demo at the EGI CF in Helsinki.)
 
WS-PGRADE/gUSE is also a gateway to clouds that helps to port your grid application to cloud with minimal effort. If you have a workflow application that used to work on grid resources you can easily reconfigure the nodes of the workflow to run in the EGI FedCloud. See Chapter 18 on "Job Submission to Cloud by Direct Cloud Access Solution" at http://skylink.dl.sourceforge.net/project/guse/3.6.4/Documentation/Portal_User_Manual_v3.6.4.pdf in the WS-PGRADE/gUSE user manual at sourceforge. To learn this feature of WS-PGRADE/gUSE is about 1 hour.
 
Finally, by WS-PGRADE/gUSE you can develop new workflows that can be executed in the EGI FedCloud or in a mixed grid/cloud infrastructure. See the WS-PGRADE/gUSE user manual at sourceforge in the URL mentioned above. To learn this feature of WS-PGRADE/gUSE is about 1 day.
If you need any assistance or user support, contact the WS-PGRADE/gUSE team at portalwide@lpds.sztaki.hu. 
| [[HOWTO08|WSPGRADE How To]]
|-
| [http://www.gridpp.ac.uk/vcycle/ Vcycle]
|
| Yes, via an OCCI connector
|
| [[Fedcloud-tf:How_to_use_Vcycle|Vcycle as Infrastructure Broker How To]]
|}

Latest revision as of 12:47, 25 May 2017