Amazon's EC2

If cloud computing is considered "platform as a service," then there are "platforms" that may be uniquely flexible enough to support both development and deployment of cloud applications. With a little inventive mixing and matching by developers, it's even possible to support both public and private clouds. Amazon's Elastic Compute Cloud (EC2) is the most generalized and wellknown of the cloud computing service offerings. It's thoroughly documented, with a good developer program and easily executed development, and it offers comprehensive support for narrow- or wide-ranging deployment of applications. Pricing is pay-as-you-go for the ability to host Amazon Machine Images (AMI), which consist of an application and their associated runtime libraries. There is a per-hour charge and a data exchange charge, both of which are reasonable, and there is no monthly minimum. Any additional charges are for "reserved," as opposed to on-demand, service. Persistent data storage is also available at additional cost per gigabyte. Any programming language can be used for application development, and deployment is supported on x86 platforms running Linux, Solaris and, for an extra charge, Windows. The AMI can make development easy by mirroring the development/test system. EC2 applications can use other Amazon web services like Simple Storage Service, Simple Queue Service, and SimpleDB, but this is not required. EC2 is also supported by key IT vendors: Oracle and IBM have. Eucalyptus is an open source software framework that implements an IaaS environment. It can deploy private or public clouds, and gives users the ability to run and control entire virtual machine instances deployed across a variety of physical resources" . Since October 2009, Eucalyptus is part of the Linux distribution Ubuntu Server, rebranded as Ubuntu Enterprise Cloud. The Eucalyptus API is compatible to Amazon EC2 and hence makes it possible to control both Amazon and Eucalyptus instances with the same tools. Its main objectives are to provide a platform for testing applications before they are moved to Amazon's infrastructure, as well as to manage and control large collections of distributed resources . In general, Eucalyptus (and the included storage daemon Walrus) emulate EC2 and S3 by providing the same SOAP and Query interfaces as Amazon, and by acting similar to the real Amazon

cloud. However, even though the external APIs are mostly identical, the interior of the Eucalyptus cloud is rather different: Amazon's EC2 is based on a modified version of the Xen hypervisor and uses its own image format (Amazon Machine Image, AMI). In contrast, Eucalyptus can run on Xen, KVM or VMware ESX and also ships with a different VM format (Eucalyptus Machine Image, EMI). With the exception of the APIs, both systems are hence completely incompatible. Eucalyptus does not advertise itself as hybrid toolkit, but rather as private cloud software. And in fact it strongly depends on the definition of hybrid cloud computing whether or not it qualities as such: Eucalyptus does not integrate remote resources transparently in the private infrastructure, and it provides no tools to extend the local capacity via external cloud providers. Instead it simply emulates the EC2 infrastructure, and can thereby serve as foundation for hybrid solutions. It is not designed to be an hybrid cloud software, but rather to bridge between public and private clouds to enable hybrid cloud infrastructures"

Nimbus Platform
Infrastructure clouds created a revolution in the outsourcing of computational resources: they enable users to provision resources customized to their needs, including the right software stack and execution privileges on a pay-as-you-go basis. But the ability to leverage this new outsourcing capability is still a challenge to many: users need to find ways to allow the on-demand resources to share security and configuration context, manage the deployment of potentially diverse platform, ensure reliability and scalability in the environment, etc. Nimbus Platform provides an integrated set of tools designed to overcome these challenges. Our aim is to enable users to move to the cloud quickly and effortlessly, automating and facilitating much of the process. We also aim to provide a bridge allowing a user to overlay familiar concepts, such as virtual clusters, onto the resources provisioned in the cloud. Nimbus Platform tools released so far include:

cloudinit.d
cloudinit.d is a tool for launching, controlling, and monitoring cloud applications. If the application is simple or complex, single cloud or multi-cloud, VM based or bare metal, or any combination of the above, cloudinit.d is designed to make the management and coordination of that application easy.

Context Broker
The Context Broker is a service that allows clients to coordinate large virtual cluster launches automatically and repeatably.

What is Nimbus?
Nimbus is an open source project focused on cloud computing, it is built around three goals targeting three different communities:

Enable resource owners to provide their resources as an infrastructure cloud Enable cloud users to access infrastructure cloud resources more easily Enable scientists and developers to extend and experiment with both sets of capabilities.

The first goal is realized by the Nimbus Infrastructure (the Workspace Service and Cumulus components providing a compute and storage cloud, respectively), the second by the Nimbus Platform (e.g., the Context Broker and cloudinit.d tools), and the third by strongly supporting open source development practices via modular, extensible code and engagement with open source developers.

III. EUCALYPTUS CLOUD PLATFORM Eucalyptus (Elastic Utility Computing Architecture for Linking Your Programs To Useful Systems) project began from California University Santa Barbara,

and mainly was used to build open-source private cloud platform [8]. Now it has been run by Eucalyptus system company. Eucalyptus is an open-source implementation of Amazon EC2 and compatible with business interfaces. It also implement virtualization depending on Linux and Xen as EC2 does. Eucalyptus is an elastic computing structure that can be used to connect the users' programms to the useful systems, it is an open-source infrastructure using clusters or workstations implementation of elastic, utility, cloud computing and a popular computing standard based on service level protocol that permit users lease network for computing capability. Currently, Eucalyptus is compatible with EC2 from Amazon, and may support more other kinds of clients with minimum modification and extension. Figure 2 demonstrates the topology structure of Eucalyptus resources.

In figure 2, node controller is a component running on the physical resources, on which all kinds of entities of virtual machine can run. It answers for the startup, check, shutdown and clearup of the virtual machines. Logic connected node controllers form a virtual cluster, all nodes belong to the same virtual cluster report to the cluster controller and are under the control and management of the cluster controller. Virtual cluster controller runs on the head node or server of the virtual cluster, is used to access private or public network. Cloud controller is the core of the manager of cloud platform, a component answering for global decision-making which is transplant to users. An Eucalyptus cloud has only one cloud controller. In Eucalyptus, client interface is the pass of communication and connection between the interior

and the outside of Eucalyptus, through which users can access all kinds of resources on the cloud computing platform. Eucalyptus Eucalyptus is designed to be an open-source answer to the commercial EC2 cloud. Eucalyptus, for its front-end for users, includes a program called euca2ools,which is very similar to Amazons EC2 front-end programs. However, some versions of EC2 itself, as well as Rightscale are also compatible front-ends. The overall design specification of the cloud have been published,

The steps for constructing a virtual machine in a configuration of Eucalyptus: 1) A user uses the euca2oolsfront-end to request a VM. 2) The VM template disk image is pushed to a compute node. 3) This disk image is padded to the correct size and packaged for use by the hypervisor on the compute node. 4) The compute node sets up network bridging to provide a virtual NIC with a virtual MAC. 5) On the head node the dhcp is set up with the MAC/IP pair. (Note: Technically this Is STATIC mode. But other modes are similar.) 6) VM is spawned on the VMM. 7) The user can now SSH directly into the VM.[20], along with an overview of the most recent version, [26] and much of the feature documentation is available online. [3] In figure 2, we give the steps taken in spawning a VM in a typical installation. With regard to the overall philosophy underlying Eucalyptus, the system is very much designed for the

corporate enterprise computing setting, a fact confirmed by the language used on its website and in its documentation. [20] All told, the structure of Eucalyptus confirms this focus. First, there is a very strong separation from user-space and admin-space. Root access is required for everything done by the administrator on the physical machines themselves. Users are only allowed to access the system via a web interface or some type of front-end tools. (The default is for this Eucalyptus own euca2ools) With few exceptions, Eucalyptus attempts to protect users from as many of the complexities of the underlying systems as possible. For authentication of the euca2ools, users download a zip file with the needed keys and follow short instructions on how to load them. Once included scripts set up certain environment variables, the euca2ools will work. Similarly, rather then expose the complexity of disk configurations available under libvirt, the administrator sets 5 configurations for available processors, memory and hard drive space, and the user must choose one of these sizes for each of their VM. In this way, users can be more easily protected from the complex underlying systems. The software configuration also leans more toward decentralizing resources, insofar as possible. The system allows for multiple clusters, such that while there is a single head node for handling user interfaces, there can be multiple cluster controllers. This works particularly well if groups of machines in the cloud are physically separated from each other. Furthermore, Eucalyptus implements a distributed storage system called Walrus which is designed to imitate Amazons S3 distributed storage. Essentially, users are assigned a cap for the amount of Walrus storage they are allowed touse. The storage is separated into structures which, if needed, can be distributed throughout the cloud. Each VMs running disk image, however, is stored locally on the computer node. This storage mode further increases the decentralization by allowing VMs, once started, to run independently of all other machines.Eucalyptus also assumes that the administrators ofthe machines have some leeway to configure the network in accordance with the expectations of one of the network configurations of Eucalyptus. For example, ifthe administrator is using SYSTEM, it is assumed that the external network is configured to accept new random MAC addresses and will assign IP addresses to them. Not all networks, especially secured ones, will necessarily do this. The other configurations assume that the cluster controller is allowed to operate its own DHCP server. Again, not all network setups will like this. Moreover, all these components must be configured with address ranges that are all in agreement with each other. As such, network configuration can present a real challenge in many network settings. Eucalyptus works best when each cluster is its own subnet, with its own reserved address range on the wider network. The highly decentralized design of Eucalyptus, with multiple clusters,

distributed storage, and locally stored running virtual disks, lends itself to a large number of machines. Second, as far as possible, the internal technical details are hidden from users, catering to persons whose primary focus might not be computer science. The web administration interface caters to settings where there is a large number of users to administer, including built in signup features in which users of the cloud might not know the administrator. Internal maintenance assumes undisputed root access to cloud machines. Optimal network configuration incorporates the ability to carefully control network address spaces, and most optimally, setup a dedicated subnetfor Eucalyptus machines. All these features lend themselves to conditions which are more likely available in a corporate enterprise setting. IV. NIMBUS CLOUD COMPUTING PLATFORM Nimbus is an open tool set, and also a cloud computing solution providing IaaS. Put forward based on scientific research in the early stage, Nimbus have supported many non scientific research domain applications [7]. It permit users lease remote resources and build the required computing environment through the deployment of virtual machines.

Figure 3 shows that nimbus cloud computing platform includes many different components, say client, agent, resource manager and so on. Generally, all these functional components can be classified as three kinds. One kind is client-supported modules which are used to support all kinds of cloud clients. Context client module, cloud client module, reference client module and EC2 client module are all belong to this kind of component. The second kind of component is mainly service-supported modules of cloud platform, providing all kinds of cloud services. It includes context agent module, web service resource framework module, EC2 WSDL module and remote interface module. The third kind of component is the backgroud resource management modules which are mainly used to manage all kinds of pyhsical resources on the cloud computing platform, including work service management module,

IaaS gateway module, EC2 and other cloud platform support module, workspace pilot module, workspace resource management module and workspace controller. These components functions are briefed as follows: Workspace service module is a independent virtual machine manager and can access different kinds of remote protocol. It is irrelevant to the content running on the system while relevant to the Java application. The front of web service resource framework is the protocol before applications implemented between workspace and client. The front of EC2 is an implementation of web service description language (WSDL) from Amazons elastic cloud computing platform, it permit users to develop EC2 not just nimbus cloud only. Cloud client module permit user run the requirement he want by very simple click operation. Reference client module is try to present the user all the characteristics of the front of WSRF in command line manner. This is a bit complex as it includes scripts of some specific applications. Object pilot is a program that tries to submit tasks to the local website resource manager to obtain virtual machine manager. Usually, the pilot module is an optional choice, and the service programs just manage the nodes deployed by the pilot program instead of running it. Remote management interface is a kind of interior interface. It permit implement the remote security protocol and independently process and manage operations. Context agent module answer for support client and coordinate manage the auto startup service of the large scale clusters. Besides, it also provide personal virtual machine services and can run both on nimbus cloud platform as well as EC2 through the backend service of EC2. EC2 gateway can provide many functions, for example, running the publich Amazon virtual machine image on the Amazon cloud platform, checking the status of homogeneous wireless sensor network, notice the user the public IP of virtual machine through the characteristics of resources when it is available and so on.NimbusThe Nimbus project explicitly advertises itself as a science cloud solution. [4] [15] [14] Nimbus is also affiliated with the Globus Project and uses Globus credentials for the authentication of users. Until recently, Nimbus relied on GridFTP (a Globus project) to be used as a disk image repository. In their newest version, they are shifting to Cumulus, a system, like Eucalyptus Walrus, compatible with S3. [30] Like OpenNebula, Nimbus is incredibly customizable. Figure 4 shows the steps in spawning a VM in a typical configuration. The customization available in Nimbus, however, has a slightly different focus. One reasonable, albeit imperfect generalization, is that a large number of the customizations available in OpenNebula pertain directly to the underlying technical details of VM creation, whereas for Nimbus these details are more protected. OpenNebula basically allows for switching nearly every component, including the underlying file system, the DHCP, the front-

end. Moreover, in the default configuration, much of the customization is available to users and administrators. Nimbus, on the other hand, leaves most of the customization to the administrator and not to the user and has several more components which are constants. These components include the image storage, (previously GridFTP and now Cumulus), the use of Globus credentials for all user authentication, and the requirement that the running Nimbus process can cleanly SSH into all compute nodes. Similarly, while Nimbus is very flexible in the number and types of virtual networks that can be set up [16], the underlying physical mechanism for doing so is much less flexible, (at least as of this writing), and involves a DHCP server on each compute node with Nimbus choosing a random MAC address. Lastly, among these three pieces of software, Nimbus is the one which probably pays the most attention to capacity allocation and capacity overflow.

The steps for constructing a virtual machine in a configuration of Nimbus. 1) A user uses cloud-client to request a VM. 2) Nimbus will ssh into a compute node. 3) The VM template disk image is pushed to the compute node. (In the newest versions of Nimbus, this will be done using a distributed storage similar to S3 and Walrus.) 4) On the compute node, the disk image is padded to the correct size and configured. 5) The compute node sets up network bridging to provide a virtual NIC with a virtual MAC. 6) A dhcp server on the compute node is configured with a MAC/IP pair. 7) VM is spawned on the VMM. 8) The user can now SSH directly into the VM. The ability to give different users different lease limits as a means of scheduling comes standard with Nimbus, whereas it is an add-on for the other two. Second, the idea of allowing EC2 or another cloud the ability to pick up excess demand is heavily researched with Nimbus. [18] [10] This capacity is similar to previous research into federated clouds. [22] Given all of these ideas, Nimbus sits somewhat in the middle of Eucalyptus and

OpenNebula on the customization chain. There are a large number of options for user and administrators in deploying the cloud, but fewer of those options pertain to the nitty-gritty of the underlying software stack. The security level is slightly higher then in OpenNebula, due to the required integration of Globus certificate credentials. A facility is incorporated into the system for sharing capacity between clouds, if desired. However, Nimbus is not so open as OpenNebula, which exposes large amounts of the underlying software in the default private cloud configuration. Nimbus level of openness is ideal for the scientific community, which would be most conducive to sharing cluster time, but most users probably do not want to contend with the oddities of the underlying software configuration.