Cloud Computing Principles and Paradigms: 7 enhancing cloud computing environments using a cluster as a service

Editor's Notes

• #2: While cloud computing has emerged as a new economical approach for sourcing organization IT infrastructures, cloud computing is still in its infancy and suffers from poor ease of use and a lack of service discovery. To improve the use of clouds, we proposed the RVWS framework to improve publication, discovery, selection, and use of cloud services and resources.
• #3: the Cluster as a Service (CaaS) is a Web service for exposing via WSDL and for discovering and using clusters to run jobs.From the virtualization point of view the CaaS is an interface for clusters that makes their discovery, selection, and use easier.What is needed is an approach to provide higher layer abstraction and support for users through the provision of simple publication, discovery, selection, and use of resources.------------------------------------------EC2 does not provide any means for publishing services by other providers, nor does it provide the discovery and selection of services within EC2. An analysis of EC2 documentation [13] shows that network multicasting (a vital element to discovery) is not allowed, thus making discovery and selection of services within EC2 difficult.App Engine does not contain any support to publish services created by other service providers, nor does it provide discovery and selection services.Azure also provides a discovery service within the cloud itself. Called the .NET Service Bus [14], services hosted in Azure are published once and are locatable even if they are frequently moved.Salesforce only offers CRM software and does not allow the hosting of custom services.
• #4: While Web services have simplified resource access and management, it is not possible to know if the resource(s) behind the Web service is (are) ready for requests. Clients need to exchange numerous messages with required Web services to learn the current activity of resources and thus face significant overhead loss if most of the Web services prove ineffective. we proposed the RVWS framework to improve publication, discovery, selection, and use of cloud services and resources.------------------------------------------The novelty of RVWS is that it combines dynamic attributes, stateful Web services (aware of their past activity), stateful and dynamic WSDL documents [1], and brokering [17] into a single, effective, service-based framework.------------------------------------------
• #8: Connector is used to detect changes in resources and then inform the Web service.(1-2)The Detection module routinely queries the resource for attribute information (3)Any changes in the attributes are passed to the Decision module that decides if the attribute change is large enough to warrant a notification. This prevents excessive communication with the Web service. (4)Updated attributes are passed on to the Notification module (5)which informs the stateful Web service that updates its internal state. (6)clients requests the stateful WSDL document (7)the Web service returns the WSDL document with the values of all attributes at the request time.
• #9: (WSDL) is an XML-based language that is used for describing the functionality offered by a Web service.For each resource behind the Web service, a ResourceInfo section exists.stateful WSDL document eliminates the overhead incurred from manually learning the attributes of the service and its resource.
• #10: To help ease the publication and discovery of required services with Stateful WSDL documents, a Dynamic Broker was proposed.The goal of the Dynamic Broker is to provide an effective publication and discovery service based on service, resource, and provider dynamic attributes.the provider sends attributes of the Web service to the Dynamic Broker (publishing)the Broker gets the Stateful WSDL document from the Web serviceDynamic Broker extracts all resource dynamic attributes from the Stateful WSDL documents and stores the resource attributes in the resources storestores the (stateless) WSDL document and service attributes from (1) in the service storeall attributes about the provider are placed in the providers store.As the Web service changes, it is able to send a notification to the Broker which then updates the relevant attribute in the relevant store
• #11: When discovering services(e.g. clusters):the client submits to the Dynamic Broker three groups of requirements: service, resource, and providerThe Dynamic Broker compares each requirement group on the related data storeafter getting matches, the Broker applies filtering As the client using the Broker could vary from human operators to other software units, the resulting matches have to be filtered to suit the client.filtered results are returned to the client
• #12: The SLA reached by the client and cloud service provider specifies attributes of services that form the client’s request or workflow.The automatic selection of services is performed to optimize a function reflecting client requirements. Time-critical and high-throughput tasks benefit by executing a computing intensive application on multiple clusters exposed as services of one or many clouds.
• #13: The purpose of the CaaS Technology is to ease the publication, discovery, selection, and use of existing computational clusters.The role of the CaaS Service is to (i) provide easy and intuitive file transfer tools so clients can upload jobs and download results and (ii) offer an easy to use interface for clients to monitor their jobs.A typical cluster is comprised of three elements: nodes, data storage, and middleware. The middleware virtualizes the cluster into a single system image;(scheduler) is a component that manage the allocation of jobs to nodes.(monitor) is a component that monitor the activity of the cluster.To make information about the cluster publishable, a Publisher Web service and Connector were created using the RVWS framework. The purpose of thepublisher Web service was to expose the dynamic attributes of the cluster via the Stateful WSDL document. Publisher service is published to the Dynamic Broker so clients can easily discover the cluster.To find clusters, the CaaS Service makes use of the Dynamic Broker. While the Broker is detailed in returning dynamic attributes of matching services, the results from the Dynamic Broker are too detailed for the CaaS Service. Thus another role of the CaaS Service is to “summarize” the result data so that they convey fewer details.
• #14: Inside the state and characteristic elements, an XML element for each cluster node was created.The advantage of the XML structuring of our cluster attributes means that comparing client requirements to resource attributes only requires using XPath queries. XPath, the XML Path Language, is a query language for selecting nodes from an XML document.
• #15: The CaaS service can be described as having four main tasks: cluster discovery and selection, result organization, job management, and file management.Based on these tasks, the CaaS Service has been designed using intercommunicating modules. Each module in the CaaS Service encapsulates one of thetasks and is able to communicate with other modules to extend its functionality.The modules inside the CaaS Web service are only accessed through an interface. The use of the interface means the Web service can be updated over time without requiring clients to be updated nor modified.
• #17: Before a client uses a cluster, a cluster must be discovered and selected first. To start, clients submit cluster requirements in the form of attribute values to the CaaS Service Interface.The requirements range from the number ofnodes in the cluster to the installed software (both operating systems and software APIs). The CaaS Service Interface invokes the Cluster Finder module Cluster finder communicates with the Dynamic Broker and returns service matches (if any).To address the detailed results from the Broker, the Cluster Finder module invokes the Results Organizer module that takes the Broker results returns an organized version that is returned to the client (5-6).
• #20: After selecting a required cluster, all executable and data files have to be transferred to the cluster and the job submitted to the scheduler for execution. All required data, parameters, such as estimated runtime, are uploaded to the CaaS Service.Once the file upload is complete, the Job Manager is invoked. It resolves the transfer of all files to the cluster by invoking the File Manager File manager makes a connection to the cluster storage and commences the transfer of all files.Upon completion of the transfer the outcome is reported back to the Job Manager On failure, a report is sent and the client can decide on the appropriate action to take. If the file transfer was successful, the Job Manager invokes the scheduler on the cluster.The same parameters the client gave to the CaaS Service Interface are submitted to the scheduler; the only difference being that the Job Manager also informs the scheduler where the job is kept so it can be started. If the outcome of the scheduler is successful, the client is then informed.
• #22: During execution, clients should be able to view the execution progress of their jobs. Even though the cluster is not the owned by the client, the job is. Thus, it is the right of the client to see how the job is progressing and (if the client decides) terminate the job and remove it from the cluster.First, the client contacts the CaaS service interface CaaS service interface invokes the Job Manager module. No matter what the operation is (check, pause, or terminate), the Job Manager only has to communicate with the scheduler and reports back a successful outcome to the client (4-5)
• #24: error or data files need to be transferred to the client.Clients start the error or result file transfer by contacting the CaaS Service InterfaceCaaS Service Interface then invokes the File Manager File manager retrieve the files from the cluster’s data storage. If there is a transfer error, the File Manager attempts to resolve the issue first before informing the client. If the transfer of files is successful, the files are returned to the CaaS Service Interfaceand then the client.When returning the files, URL link or a FTP address is provided so the client can retrieve the files.
• #25: The CaaS Service was implemented using Windows Communication Foundations (WCF) of .NET 3.5 that uses Web services. An open source library for building SSH clients in .NET (sharpSSH) [19] was used to build the Job and File Managers.To improve reliability, all file transfers between the cluster and the client are cached.
• #30: In terms of future research for the RVWS framework and CaaS technology, the fields of load management, security, and SLA negotiation are open. Load management is a priority because loaded clusters should be able to offload their jobs to other known clusters.