Cloud Architecture as Foundation of Cloud-Based Scientific Applications

23.3.1 Cloud Architecture as Foundation of Cloud-Based Scientific Applications

Doing science in the cloud inevitably depends on how cloud architecture can satisfy the requirements of scientific computing. Despite differing in articulation over the definition of cloud computing, there is commonness in cloud architecture adhering

to layered architecture as depicted in Fig. 23.2 . In the figure, we can see that cloud architecture is constituted of three layers from the bottom up: IaaS (Infrastructure as a Service) layer, PaaS (Platform as a Service) layer, and SaaS (Software as a

540 M.F. Simalango and S. Oh Fig. 23.2 Layered cloud

architecture

Service) layer respectively. The layers also refer to types of services offered in the cloud. Below the three layers, there exists virtualization technology which handles the logic of transforming physical server, storage, and network into a virtualized environment.

Virtualization technologies architect the creation of virtual machines on phys- ical infrastructure which support the overlaying cloud services. Revisiting its definition, virtualization is defined as the abstraction of the logical resources away from the underlying physical resources thus consequently enabling abstrac- tion of the coupling between hardware and OS. This definition is closed to operating system virtualization if compared with types of virtualizations noted by Sun Microsystems (Cloud Computing Primer. http://www.sun.com/offers / docs/cloud_computing_primer.pdf.). In a virtualized environment, multiple operat- ing systems can run the same physical infrastructure and share the resources. It is made possible by the role of virtualization machine monitor (VMM) or hypervisor placed and running between the hardware and operating systems (also referred to as the guests of VMM). VMM arbitrates accesses to underlying physical host and manages the resource sharing between its guest operating systems.

Capabilities pertinent to virtualization can be categorized into workload iso- lation, workload consolidation, and workload migration (Uhlig, et al., 2005 ). Traditionally, an operating system runs various applications under the same sys- tem environment. Workload isolation enables isolation of multiple software stacks in their own VMs thus improving security and reliability. Meanwhile, workload consolidation refers to the capability of virtualization to consolidate individual workloads onto single physical platform thus reducing the total cost of owner- ship. Finally, workload migration makes it possible to decouple the guest from the hardware it is currently running and migrate it to a different platform.

In Fig. 23.1 , we reviewed how we can do science, which is processing data- intensive task, in the grid. As we may notice earlier, the basic notion is parallel processing of data chunk in the worker nodes followed with the compilation of the partial result to yield the final output. Referring to the cloud architecture in Fig. 23.2 and the role of virtualization, we consider that science in the cloud implements the same basic principle, parallelism, in different methodology. Through the techniques

23 Feasibility Study and Experience 541

Fig. 23.3 Processing data-intensive scientific task in the cloud

in doing science in the cloud also differ, in general they resemble the process we depict in Fig. 23.3 . Referring to Fig. 23.3 , a researcher keeps in hand input data to be processed. The process will be handled by certain package of software applications that will be loaded to the data nodes. Before any data node is deployed, the package is bundled in a virtual machine image (VMI) that is stored in data storage infrastructure in the cloud. The example for the persistent storage service in the enterprise cloud is Amazon S3 (Simple Storage Service) or Amazon EBS (Elastic Block Store). There can be several VMIs stored in the storage infrastructure thus the cloud management application or system should provide the interface to the repository of the images. Cloud management system itself can be located in the master node or hosted in another node outside the cloud. It enables dynamic listing of VMIs and provides other interfaces to cloud management and monitoring. However, in the absence of cloud management system, image deployment to compute nodes and corresponding configurations should be done manually.

Upon getting the list of VMIs from the cloud management interface, the researcher will then choose the suitable VMI and then create a number of instances accordingly. One or some of the instances will act as the master node which will splice the data input into several parts and delegate their processing to the worker nodes. Master node(s) control the executions of jobs, collate the partial output, and notify the researcher when all jobs have been finished and final output is ready to

542 M.F. Simalango and S. Oh

be analyzed. In a bigger picture, this resembles the process in the grid computing paradigm. It is then understandable if some experts also state that the cloud is the evolution of the grid (Foster et al., 2008 , Giunta, Lacetti, Montella, 2008 ).

A recent finding by Dejun, Pierre, and Chi ( 2009 ) shows that the performance of EC2 instances is relatively stable. However, one can not predict the performance of a new instance even though statistics of performance of the same instances over some period of time in the past has been collected. The consequence of this finding is two-fold. First, performance stability of a VM instance hints the prospect for con- ducting lengthy computation since system failure during the compute process can

be expected to be minimal. Contrarily, a new resource provisioning mechanism is deemed necessary to ensure that the deployed VM profile matches the requirements of the compute task.

Given that the performance of VM instances in an enterprise cloud service can differ even for those with exactly the same profile, a question about feasibility of entire resource provisioning by a single cloud may be raised. A cloud itself can differ in size thus implying heterogeneity of profiles it may create. A small cloud with less virtualized nodes may support less set of basic profiles. Similarly, a bigger cloud with more resources tends to be more capable of creating various profiles. Meanwhile, another question about the possibility of integrating an internal, private cloud with public, enterprise cloud whenever necessary thus creating a new type of cloud named hybrid cloud or interoperable cloud is also natural to come up to the surface. Adhering to the principle of efficiency and reusability, an entity or orga- nization tends to use its own resource whenever possible instead of paying third parties for renting out and utilizing their resources. These questions end up as a sur- vey of scientific computation cloud infrastructure, platform, and application which is immediately described in the next section.