Showing posts with label cloud. Show all posts
Showing posts with label cloud. Show all posts

Sunday, January 11, 2015

Creating Eucalyptus Machine Images from a Running VM

I often use Eucalyptus private cloud platform for my research. And very often I need to start Linux VMs in Eucalyptus, and install a whole stack of software on them. This involves a lot of repetitive work, so in order to save time I prefer creating machine images (EMIs) from fully configured VMs. This post outlines the steps one should follow to create an EMI from a VM running in Eucalyptus (tested on Ubuntu Lucid and Precise VMs).

Step 1: SSH into the VM running in Eucalyptus, if you already haven't.

Step 2: Run euca-bundle-vol command to create an image file (snapshot) from the VM's root file system.
euca-bundle-vol -p root -d /mnt -s 10240
Here "-p" is the name you wish to give to the image file. "-s" is the size of the image in megabytes. In the above example, this is set to 10GB, which also happens to be the largest acceptable value for "-s" argument. "-d" is the directory in which the image file should be placed. Make sure this directory has enough free space to accommodate the image size specified in "-s". 
This command may take several minutes to execute. For a 10GB image, it may take around 3 to 8 minutes. When completed, check the contents of the directory specified in argument "-d". You will see an XML manifest file and a number of image part files in there.

Step 3: Upload the image file to the Eucalyptus cloud using the euca-upload-bundle command.
euca-upload-bundle -b my-test-image -m /mnt/root.manifest.xml
Here "-b" is the name of the bucket (in Walrus key-value store) to which the image file should be uploaded. You don't have to create the bucket beforehand. This command will create the bucket if it doesn't already exist. "-m" should point to the XML manifest file generated in the previous step.
This command requires certain environment variables to be exported (primarily access keys and certificate paths). The easiest way to do that is to copy your eucarc file and the associated keys into the VM and source the eucarc file into the environment.
This command also may take several minutes to complete. At the end, it will output a string of the form "bucket-name/manifest-file-name".

Step 4: Register the newly uploaded image file with Eucalyptus.
euca-register my-test-image/root.manifest.xml
The only parameter required here is the "bucket-name/manifest-file-name" string returned from the previous step. I've noticed that in some cases, running this command from the VM in Eucalyptus doesn't work (you will get an error saying 404 not found). In that case you can simply run the command from somewhere else -- somewhere outside the Eucalyptus cloud. If all goes well, the command will return with an EMI ID. At this point you can launch instances of your image using the euca-run-instances command.

Friday, July 26, 2013

Avoiding the Risks of Cloud


It's no secret that cloud computing has transformed the way enterprises do business. It has changed the way developers write software and users interact with applications. By now, almost every business organization has a strategy on how to adopt the cloud. Those who don’t will soon be extinct. The influence of the cloud has been so phenomenal, that it truly has turned into a "take it or die" kind of a deal over the last few years.
It is also no secret that today the cloud movement is steered by a handful of giants in the IT industry. Companies like Amazon, Google, Microsoft and Salesforce are clearly among this elite group. These companies, their products and vision have been instrumental in the introduction, evolution and the popularization of the cloud technology. 
With that being the case, we must think about the implications of cloud computing on the current IT landscape of the world. Are all S&M organizations around the world going to get rid of their server racks and transfer their IT infrastructure to Amazon EC2? Are all Web applications and mobile applications going to be based on Google App Engine APIs? Are all enterprise data going to end up in Amazon S3 and Google Megastore? What sort of defenses are in place to prevent a few IT giants from monopolizing the entire IT infrastructure and services market? How easy it would be for us to migrate from one cloud vendor to another? All these are indeed very real and very important problems that all organizations should take under careful consideration.
Fortunately there are several practical solutions to all the above issues. One is openness and standardization. Cloud platforms that are based on open standards and protocols should be preferred over those that use proprietary standards and protocols. Open standards and protocols are likely to be supported by more than just one cloud vendor thus enabling the users to migrate between different vendors easily. Also, in many cases open standards make it easier to port existing standalone applications to the cloud. Take a Java web application for an example. Most Java web applications are based on the J2EE suite of standards (JSP, Servlets, JDBC etc.). If the target cloud platform also supports these open standards, the user can easily migrate his J2EE app to the cloud without having to make too many changes. Similarly he can easily migrate the app from one cloud platform to another as long as both platforms support the same J2EE standards. 
Speaking of openness, cloud platforms that are open source and distributed under liberal licenses should get extra credit over closed source ones. Open source cloud platforms allow the user to modify and shape the platform according to the user requirements, rather than forcing the user to change their apps according to the changes made by the cloud platform vendor. Also, with an open source cloud framework, users will be in a position to maintain and support the platform on their own, in a situation where the original vendor decides to discontinue support for the platform.
Another possible solution is to use a hybrid cloud approach instead of solely relying on a remote public cloud maintained by a third party vendor. A hybrid cloud approach typically involves a private cloud maintained by the user, and then selectively bursting into the public cloud to handle high availability and high scalability scenarios. This method does involve some additional expenses and legwork on the user's part but the user ultimately remains in control of his data and applications, and no third party vendor can take that away from the user. Also as far as most S&M organizations are concerned, what they expect from the cloud are features like multi-tenancy, self-provisioning, optimal resource utilization and auto-scaling. Spending a few bucks on running a server rack or two to make that happen is usually not a big deal. Most companies do that today anyway. However, from a technical standpoint, we need easy-to-deploy, easy-to-maintain and reliable private cloud frameworks, which are compatible with popular public cloud platforms to really take advantage of this hybrid cloud model. Fortunately, thanks to some excellent work by a few start-ups like Eucalyptus and AppScale, this is no longer an issue. These vendors provide highly competitive private cloud and hybrid cloud solutions that are fully compatible with widely used public cloud platforms such as AWS and Google App Engine. If the user is capable of procuring the necessary hardware resources and manpower, these cloud platforms can even be used to setup fully-fledged private clouds that have all the bells and whistles of popular public clouds. That’s a great way to bask in the glory of the cloud, while maintaining full ownership and control over your enterprise IT assets.
Software frameworks like Apache JClouds provide another approach for dealing with potential risks of the cloud. These software frameworks allow user's code to interact with multiple heterogeneous cloud platforms by abstracting out the differences between various clouds. If we consider JClouds, as of now it supports close to 30 different cloud platforms including AWS, OpenStack and Rackspace. This implies that any application written using JClouds can be executed on around 30 different cloud platforms without having to make any code changes. As the influence of the cloud continues to grow, developers should seriously consider writing their code using high-level APIs like JClouds, without getting tied into a single specific cloud platform.
Cloud has certainly changed the way we all think about IT and computing. While its benefits are quite attractive, it also comes with a few potential risks. Users and developers should think carefully, plan ahead and take preventive action soon to avoid these pitfalls.

Friday, April 5, 2013

MDCC - Strong Consistency with Performance

A few weeks back me and a couple of my colleagues finished developing a complete implementation of the MDCC (Multi-Data Center Consistency) protocol. MDCC is a fast commit protocol proposed by UC Berkeley for large-scale geo-replicated databases. The main advantage of MDCC is that is supports strong consistency for data while providing transaction performance similar to eventually consistent systems. 
With traditional distributed commit protocols, supporting strong consistency usually requires executing complex distributed consensus algorithms (e.g. Paxos). Such algorithms generally require multiple rounds of communication. Therefore when deployed in a multi-data center setting where the inter-data center latency is close to 100ms, the performance of the transactions being executed degrades to almost unacceptable levels. For this reason most replicated database systems and cloud data stores has opted to support a weaker notion of consistency. This greatly speeds up the transactions but you always run the risk of data becoming inconsistent or even lost.
MDCC employs a special variant of Paxos called Fast Paxos. Fast Paxos takes a rather optimistic approach by which it is able to commit most transactions within a single network roundtrip. This way a data object update can be replicated to any number of data centers within a single request-response window. The protocol is also effectively masterless which means if the application is executing in a data center in Europe, it does not have to contact a special master server which could potentially reside in a data center in USA. The only time this protocol doesn't finish within a single request-response window is when two or more transactions attempt to update the same data object (transaction conflict). In that case a per-object master is elected and the Classic Paxos protocol is invoked to resolve the conflict. If the possibility of a conflict is small, MDCC will commit most transactions within a single network roundtrip thus greatly improving the transaction throughput and latency. 
Unlike most replicated database systems, MDCC doesn't require explicit sharding of data into multiple segments. But it can be supported on MDCC if needed. Also unlike most cloud data stores, MDCC has excellent support for atomic multi-row (multi-object) transactions. That is multiple data objects can be updated atomically within a single read-write transaction. All these interesting properties make MDCC an excellent choice for implementing powerful database engines for modern day distributed and cloud computing environments.
Our implementation of MDCC is based on Java. We use Apache Thrift as the communication framework between different components. ZooKeeper is used for leader election purposes (we need to elect a per-object leader whenever there is a conflict). HBase server is used as the storage engine. All the application data and metadata are stored in HBase. In order to reduce the number of storage accesses we also have a layer of in-memory caching. All the critical information and updates are written through to the underlying HBase server to maintain strong consistency. The cache still helps to avoid a large fraction of storage references. Our experiments show that most read operations are able to complete without ever going to HBase layer. 
We provide a simple and intuitive API in our MDCC implementation so that users can write their own applications using our MDCC engine. A simple transaction implementing using this API would look like this.
        TransactionFactory factory = new TransactionFactory();
        Transaction txn = factory.create();
        try {
            txn.begin();
            byte[] foo = txn.read("foo");
            txn.write("bar", "bar".getBytes());
            txn.commit();
        } catch (TransactionException e){
            reportError(e);
        } finally {
            factory.close();
        }
We also did some basic performance tests on our MDCC implementation using the YCSB benchmark. We used 5 EC2 micro instances distributed across 3 data centers (regions) and deployed a simple 2-shard MDCC cluster. Each shard consisted of 5 MDCC storage nodes (amounting to a total of 10 MDCC storage nodes). We ran several different types of workloads on this cluster and in general succeeded in achieving < 1ms latency for read operations and < 100ms latency for write operations. Our implementation performs best with mostly-read workloads, but even with a fairly large number of conflicts, the system delivers reasonable performance. 
Our system ensures correct and consistent transaction semantics. We have excellent support for atomic multi-row transactions, concurrent transactions and even some rudimentary support for crash recovery. If you are interested to give this implementation a try, grab the source code from https://github.com/hiranya911/mdcc. Use Maven3 to build the distribution, extract and run.

Monday, January 28, 2013

Introducing AppsCake: Makes Deploying AppScale a Piece of Cake

One of my very first contributions to AppScale was a component named AppsCake. AppsCake is a dynamic web component, which provides a web frontend for the command-line AppScale Tools. It enables the users to deploy and start AppScale over several different types of infrastructure. This greatly reduces the overhead of starting and managing a PaaS as most of the heavy lifting operations can be performed easily by a click of a button. Users do not need to learn the AppScale Tools commands nor they have to be familiar with any command-line interface. With AppsCake, a regular web browser is all you need to initialize AppScale and start deploying applications in the cloud.
As of now AppsCake supports deploying AppScale over virtualized clusters (eg: Xen), Amazon EC2 and Eucalyptus. Users can select the environment in which AppScale should be deployed and provide the required credentials and other metadata for the target environment through the web interface. AppsCake takes care of invoking the proper command sequences with the appropriate arguments to initialize AppScale. The web frontend also allows the users to view deployment logs and monitor the deployment progress in near real-time. 
This component can be further extended and be offered as a service of its own if needed. That way, users can access AppsCake through a well-known URL and setup an AppScale deployment remotely for the purpose of executing a specific task or an application. As an example consider a group of scientists who want to run various scientific computations in the cloud (say as MPI or MapReduce jobs).  The group can use a private Eucalyptus cluster or a shared EC2 account as their computing infrastructure. The group can be provided with a single well-known AppsCake instance as the entry point for AppScale. Then whenever a member of the team wants to run a computation on the target shared environment, he or she can use the AppsCake service to initiate his or her own AppScale instance and run the required computation in the cloud. This scheme maximizes resource sharing while providing sufficient isolation between applications/jobs initiated by individual users.
AppsCake is implemented using Ruby and Sinatra. To try this out, simply checkout the source from Github, and execute the bin/debian_setup.sh script (build script only supports Debian/Ubuntu environments as of now). Then execute bin/appscake to start the AppsCake web service. Now you can point your browser to https://localhost:28443 and start interacting with the service.
Chris has posted a neat little screencast that explains how to use AppsCake to deploy AppScale on Virtual Box. Don’t forget to check that out too.

Sunday, January 20, 2013

On Premise API Management for Services in the Cloud

In some of my recent posts I explained how to install and start AppScale. I showed how to use AppScale command-line tools to manage an AppScale PaaS on virtualized environments such as Xen and IaaS environments such as EC2 and Eucalyptus. Then we also looked at how to deploy Google App Engine (GAE) apps over AppScale. In this post we are going to try something different.
Here I’m going to describe a possible hybrid architecture for deploying RESTful services in the cloud and exposing those services through an on-premise API management platform. This type of an architecture is most suitable for B2B integration scenarios where one organization provides a range of services and several other organizations consume them with their own custom use cases and SLAs. Both service providers and service consumers can greatly benefit from the proposed hybrid architecture. It enables the API providers to reap the benefits of the cloud with reduced deployment cost, reduced long-term maintenance overhead and reduced time-to-market. API consumers can use their own on-premise API management platform as a local proxy, which provides powerful access control, rate control, analytics and community features on top of the services already deployed in the cloud. 
To try this out, first spin up an AppScale PaaS in a desired cloud environment. You can refer my previous posts or go through the AppScale wiki to learn how to do this. Then we can deploy a simple RESTful web service in our AppScale cloud. Here I’m posting the source code for a simple web service called “starbucks” written in Python using the GAE APIs. The “starbucks” service can be used to submit and manage simple drink orders. It uses the GAE datastore API to store all the application data and exposes all the fundamental CRUD operations as REST calls (Creare = POST, Update = PUT, Read = GET, Delete = DELETE).
try:
  import json
except ImportError:
  import simplejson as json

import random
import uuid
from google.appengine.ext import db, webapp
from google.appengine.ext.webapp.util import run_wsgi_app

PRICE_CHART = {}

class Order(db.Model):
  order_id = db.StringProperty(required=True)
  drink = db.StringProperty(required=True)
  additions = db.StringListProperty()
  cost = db.FloatProperty()

def get_price(order):
  if PRICE_CHART.has_key(order.drink):
    price = PRICE_CHART[order.drink]
  else:
    price = random.randint(2, 6) - 0.01
    PRICE_CHART[order.drink] = price
  if order.additions is not None:
    price += 0.50 * len(order.additions)
  return price

def send_json_response(response, payload, status=200):
  response.headers['Content-Type'] = 'application/json'
  response.set_status(status)
  if isinstance(payload, Order):
    payload = {
      'id' : payload.order_id,
      'drink' : payload.drink,
      'cost' : payload.cost,
      'additions' : payload.additions
    }
  response.out.write(json.dumps(payload))

class OrderSubmissionHandler(webapp.RequestHandler):
  def post(self):
    order_info = json.loads(self.request.body)
    order_id = str(uuid.uuid1())
    drink = order_info['drink']
    order = Order(order_id=order_id, drink=drink, key_name=order_id)
    if order_info.has_key('additions'):
      additions = order_info['additions']
      if isinstance(additions, list):
        order.additions = additions
      else:
        order.additions = [ additions ]
    else:
      order.additions = []
    order.cost = get_price(order)
    order.put()
    self.response.headers['Location'] = self.request.url + '/' + order_id
    send_json_response(self.response, order, 201)

class OrderManagementHandler(webapp.RequestHandler):
    def get(self, order_id):
      order = Order.get_by_key_name(order_id)
      if order is not None:
        send_json_response(self.response, order)
      else:
        self.send_order_not_found(order_id)

    def put(self, order_id):
      order = Order.get_by_key_name(order_id)
      if order is not None:
        order_info = json.loads(self.request.body)
        drink = order_info['drink']
        order.drink = drink
        if order_info.has_key('additions'):
          additions = order_info['additions']
          if isinstance(additions, list):
            order.additions = additions
          else:
            order.additions = [ additions ]
        else:
          order.additions = []
        order.cost = get_price(order)
        order.put()
        send_json_response(self.response, order)
      else:
        self.send_order_not_found(order_id)

    def delete(self, order_id):
      order = Order.get_by_key_name(order_id)
      if order is not None:
        order.delete()
        send_json_response(self.response, order)
      else:
        self.send_order_not_found(order_id)

    def send_order_not_found(self, order_id):
      info = {
        'error' : 'Not Found',
        'message' : 'No order exists by the ID: %s' % order_id,
      }
      send_json_response(self.response, info, 404)

app = webapp.WSGIApplication([
    ('/order', OrderSubmissionHandler),
    ('/order/(.*)', OrderManagementHandler)
], debug=True)

if __name__ == '__main__':
  run_wsgi_app(app)
Before we go any further let’s take a few seconds and appreciate how simple and concise this piece of code is. With just about 100 lines of Python code we have developed a comprehensive webapp, which uses JSON as the data exchange format and also does database access and provides decent error handling. Imagine doing the same thing in a language like Java in a traditional servlet container environment. We will have to write lot more code and also bundle a ridiculous amount of additional dependencies to parse and construct JSON and perform database queries. But as seen here, GAE APIs make it absolutely trivial to develop powerful web APIs for the cloud with a minimum amount of code.
You can download the complete “starbucks” application from here. Simply extract the downloaded tar ball and you’re good to go. The webapp consists of just 2 files. The main.py contains all the source code of the app and app.yaml is the GAE webpp descriptor. No additional libraries or files are needed to make this work. Use AppScale-Tools to deploy the app in your AppScale cloud.
appscale-upload-app –-file /path/to/starbucks --keyname my_key_name
To try out the app, put the following JSON string into a file named order.json:
{
  "drink" : "Caramel Frapaccino",
  "additions" : [ "Whip Cream" ]
}
Now execute the following Curl request on your App:
curl –v –d @order.json –H “Content-type: application/json” http://host:port/order
Replace 'host' and 'port'  with the appropriate values for your AppScale PaaS. This request should return a HTTP 201 Created response with a Location header.
And now for the API management part. For this I’m going to use the open source API management solution from WSO2, a project that I was a part of a while ago. Download the latest WSO2 API Manager and install it on your local computer by extracting the zip archive. Go into the bin directory and execute wso2server.sh (or wso2server.bat for Windows) to start the API Manager. You need to have JDK 1.6 or higher installed to be able to do this.
Once the server is up and running, navigate to http://localhost:9763/publisher and sign in to the console using “admin” as both the username and the password. Go ahead and create an API for our “starbucks” service in the cloud. You can use http://host:port as the service URL where 'host' and 'port' should point to the AppScale PaaS. API creation process should be pretty straightforward. If you need any help, you can refer my past blog posts on WSO2 API Manager or go through the WSO2 documentation. Once the API is created and published, head over to the API Store at http://localhost:9763/store.
Now you can sign up at the API Store as an API consumer, generate an API key for the Starbucks API and start using it.
Submit Order:
curl –v –d @order.json –H “Content-type: application/json” –H “Authorization: Bearer api_key” http://localhost:8280/starbucks/1.0.0/order
Review Order:
curl –v –H “Authorization: Bearer api_key” http://localhost:8280/starbucks/1.0.0/order/order_id
Delete Order:
curl –v –X DELETE –H “Authorization: Bearer api_key” http://localhost:8280/starbucks/1.0.0/order/order_id
Replace 'api_key' with the API key generated by the API Store. Replace the 'order_id' with the unique identifier sent in the response for the submit order request.
There you have it. On-premise API management for services in the cloud. This looks pretty simple at first glimpse, but actually this is a quite powerful architecture. Note that all the critical components (service runtime, registry and consumer) are very well separated from each other, which allows maximum flexibility. The portions in the cloud can benefit from cloud specific features such as autoscaling to deliver the maximum throughput with optimal resource utilization. Since the API management platform is being controlled by individual consumer organizations, they can easily enforce their own custom policies, SLAs and optimize for their common access patterns.

Tuesday, January 8, 2013

Evolution of Networked Computing

  • 1969: As of now, computer networks are still in their infancy, but as they grow up and become sophisticated, we will probably see the spread of 'computer utilities', which like present electric and telephone utilities, will service individual homes and offices across the country.Leonard Kleinrock, UCLA
  • 1984: The network is the computer. - John Gage, Sun Microsystems
  • 2008: The data center is the computer. - David Patterson, UC Berkeley
  • 2008: Cloud is the computer. - Rajkumar Buyya, Melbourne University
From the book "Distributed and Cloud Computing" by Kai Hwang et al.

Monday, December 31, 2012

Creating and Uploading Eucalyptus Images

By far the best reference I've found on the subject: http://virtually-a-machine.blogspot.com/2009/09/eucalyptus-5-creating-and-running-vms.html

Simple, elegant and most importantly no BS! I've tried these steps out several times in Euca2 and Euca3 and they work like a charm. Nice work Igor.

Saturday, December 29, 2012

Deploying Applications in the Cloud Using AppScale

In my last two posts I briefly explained how to setup AppScale and get it up and running. Once you have a running AppScale PaaS, you can start deploying webapps in the cloud. You develop webapps for AppScale using Google App Engine (GAE) SDK. AppScale is fully API compatible with GAE and therefore any GAE application can be deployed on AppScale with no code changes. If you do not have any GAE applications to try on AppScale, you may follow one of the official GAE tutorials and develop a sample GAE application using Python, Java or Go. Alternatively you can checkout the AppScale sample-apps repository and try to deploy one of the pre-packaged sample apps. To checkout the sample-apps repository, execute the following command on a shell:
git clone https://github.com/AppScale/sample-apps.git
This will checkout a directory named sample-apps to your local disk. This directory contains 3 subdirectories named python, java and go. As the names suggest, each subdirectory contains a number of sample GAE applications written in the corresponding language. One of the simplest sample applications available for you to try out is the "guestbook" application. The Python version of the application can be found in the sample-apps/python/guestbook directory and the Java version of it can be found in the sample-apps/java/guestbook directory. This application provides a simple web front-end for users to enter a comment and browse comments entered by other users. It uses the GAE datastore API under the hood to store and retrieve comments entered by users. You can use AppScale-Tools to upload the guestbook application to your AppScale cloud.
appscale-upload-app --file samples-apps/python/guestbook --keyname appscale_test
The keyname flag should indicate the keyname you provided when starting the AppScale instance using the appscale-run-instances command. Once you execute the above command you will be prompted to enter the admin e-mail address for your application. Here you can enter the admin e-mail address you used when starting AppScale. Application deployment could take a few minutes. If everything goes smoothly, tools will print the URL through which your webapp can be accessed.
Your app can be reached at the following URL: http://ec2-174-129-188-141.compute-1.amazonaws.com/apps/guestbook
Try uploading a few applications using the above command and see how it goes. You can also try developing your own custom apps and deploying them in the cloud. 
AppScale-Tools also allow you to start an AppScale cloud with an application preloaded. To invoke this feature, you simple need to pass the --file option to the appscale-run-instances command.
appscale-run-instances --min 10 --max 10 --infrastructure euca --machine emi-12345678 --keyname appscale_test --group appscale_test --file samples-apps/python/guestbook
To undeploy an application you can use the appscale-remove-app command.
appscale-remove-app --appname guestbook --keyname appscale_test
Finally you can terminate and tear down an AppScale PaaS using the appscale-terminate-instances command.
appscale-terminate-instances --keyname appscale_test
If your AppScale PaaS was running in over an IaaS layer such as EC2, the above command will also take care of terminating the VMs in the cloud.
In my next few posts, I'll explain a little bit about GAE APIs and how to implement cool apps for AppScale using those APIs.

Wednesday, December 26, 2012

Starting AppScale

This post is written assuming you already have a machine or a VM image with AppScale and AppScale-Tools installed. If you don't please refer to my previous post on "Setting Up AppScale". 
We use AppScale-Tools to start, manage and terminate AppScale instances in various environments. The inputs we should pass into the tools differ slightly based on the environment in which we want to start AppScale. If you're going to deploy AppScale without the help of an IaaS layer like EC2 or Eucalyptus, then you're responsible for manually starting up the required machines or VMs. For an example if you're going to run AppScale on the Xen hypervisor, then you should first start your AppScale Xen images manually. Similarly if you're going to run AppScale over VMWare Fusion, you should start your AppScale Fusion images manually. Once the instances are up and running note down their IP addresses (assuming that the instances obtain IP addresses from a service such as DHCP). As an example lets assume you have 3 VM instances up and running and their IP addresses are 192.168.1.10, 192.168.1.20 and 192.168.1.30. With this information we should compile a simple YAML configuration like this:
--- 
:controller: 192.168.1.10
:servers: 
- 192.168.1.20
- 192.168.1.30
Lets call this file ips.yaml. This configuration instructs AppScale to use one machine as the controller and the rest as ordinary nodes. The controller (aka head node) operates as a load balancer and a ZooKeeper leader. The other nodes will assume the roles of application server and DB server. In this case both server nodes will assume the application server and DB server roles. Therefore we end up with an application server cluster (of 2) and a replicated DB cluster (of 2) fronted by a single load balancer. You can further fine tune how AppScale assigns roles to machines by changing your ips.yaml file. For more information regarding the role placement configuration please refer the "Placement Support" article on AppScale wiki.
Once you have your ips.yaml file you can start deploying AppScale on the VMs. First create a SSH key-pair so that AppScale-Tools can login to the relevant machines remotely. This is done by executing the appscale-add-keypair command.
appscale-add-keypair --ips /path/to/ips.yaml
This will prompt you to enter the root passwords for each of the machines specified in your ips.yaml. Once this step has completed you can fire off AppScale using the app scale-run-instances command.
appscale-run-instances --ips /path/to/ips.yaml
This will start the AppScale daemons on each of the machines and initialize the AppScale PaaS. At some point you will be prompted to enter an email address and a password for the AppScale admin account. Just enter any email address or password for this. You can later use these credentials to login to AppScale management console. (For more details on deploying AppScale over a virtualized cluster setup refer the AppScale wiki)
If you are deploying AppScale over an IaaS layer such as EC2 or Eucalyptus, then you don't need to start the VMs manually nor you need any ips.yaml file. All you need is the unique ID of your AMI or EMI provided by your IaaS provider and the security credentials to interact with the IaaS. In case of EC2 you will need your AWS access key, secret key, AWS private key and X509 certificate. You can get these from the security credentials page of your AWS management console. If you're on Eucalyptus you can download a zip file from Euca admin console which contains all the required credentials.
Using these credentials you should first setup some environment variables.
export EC2_CERT=~/mycert.pem 
export EC2_PRIVATE_KEY=~/mypk.pem 
export EC2_ACCESS_KEY=my-access-key 
export EC2_SECRET_KEY=my-secret-key
In case of Eucalyptus you can simply source the eucarc file found in the downloaded credentials file.
source eucarc
With these environment variables in place you're ready to go. Simply execute the app scale-run-instances command as follows.
appscale-run-instances --min 1 --max 1 --infrastructure ec2 --machine ami-52912a3b --keyname app scale_test --group app scale_test
This will start a simple 1-node AppScale cloud in EC2. If you want more instances in your PaaS, simply adjust the values of min and max flags. For deployment on Eucalyptus change the value of infrastructure flag to 'euca' and provide a valid EMI ID for the machine flag. Here's the command for a 10 node AppScale deployment over Eucalyptus.
appscale-run-instances --min 10 --max 10 --infrastructure euca --machine emi-12345678 --keyname app scale_test --group app scale_test
The values of keyname and group flags will be used to create a keypair and a security group in the respective IaaS environment. Therefore make sure they are unique for your EC2/Eucalyptus account. Note that when running in a billed environment such as EC2, the machines spawned by AppScale are billed against the EC2 credentials provided (the credentials that we set as environment variables). AppScale spawns m1.large instances which cost about 26 cents an hour.
An AppScale deployment could take several minutes to complete. In environments like EC2 and Eucaplyptus, deployment times over 10 minutes are not uncommon. This delay is primarily due to the VM bootup and initialization overhead of IaaS environments which cannot be avoided. Once the AppScale deployment is complete AppScale-Tools will spit out a URL that you can use to check the status of the AppScale deployment:
The status of your AppScale instance is at the following URL: http://ec2-107-22-124-143.compute-1.amazonaws.com/status
Simply copy and paste the URL into your web browser to view the AppScale status page.
In my next post I'll explain how to deploy applications in an already running AppScale PaaS.

Tuesday, December 25, 2012

Setting Up AppScale

The AppScale installation procedure is already well documented in the AppScale wiki. Therefore this blog post only serves as a summary and a refresher of the most important steps. The installation of AppScale usually boils down to creating a virtual machine (VM) image for the environment in which you intend to deploy AppScale. For an example, if you wish to deploy AppScale on Amazon EC2, then you need to create an EC2 AMI with AppScale installed on it. If you wish to run AppScale on Eucalyptus, you will be creating a Eucalyptus EMI with AppScale on it. Similarly you can create AppScale VM images for other virtualized environments (eg: Xen, Virtual Box, Fusion etc). The only exception to this is when you want to deploy AppScale without a virtualization layer. In that case you can directly install AppScale on the host operating system.
As of the time of writing, AppScale is only supported on Ubuntu Lucid 10.04 Server Edition. This is common to all the target environments. Therefore regardless of the virtualization layer you intend to use, your AppScale VM image must be running Ubuntu Lucid 10.04 Server Edition. However we will start supporting newer versions of Ubuntu pretty soon therefore I'd recommend you to refer the AppScale wiki to find out about the latest OS supported by the system. 
Once you have procured your Ubuntu Lucid image you can boot it up and start installing AppScale on it. First login to the VM as root. We will use the command-line Git client to pull the latest AppScale source code on to the VM. But first we need to install the command-line Git client.
apt-get install git-core
Now clone the AppScale and AppScale-Tools repositories to the home directory of root.
git clone https://github.com/AppScale/appscale.git
git clone https://github.com/AppScale/appscale-tools.git
If you want to pull any recent bug fixes or improvements, simply pull the AppScale testing branches. You can do this by adding "--branch testing" flag to the above two commands. Once you have the two repositories checked out, simply change into the appscale directory and run the following command to kick off the build process.
bash debian/appscale_build.sh
AppScale build can take about 20-30 minutes depending on how fast your Internet connection is. Once the AppScale build is complete check for a directory named /etc/appscale. This should contain a subdirectory named after the version of AppScale you just installed and this subdirectory should contain a collection of text files named after different database engines (eg: cassandra, hbase etc). If these files are in place that's a pretty reasonable indication that everything has gone according to the plan. Now change into appscale-tools directory you checked out earlier, and run the same build command as above to start building the AppScale command-line tools. This shouldn't take more than a few seconds. 
You are now done installing AppScale on the VM image. You can now go ahead and start bundling/packing the VM image for your target environment. For an example if you're going to run AppScale on EC2, you can start the AMI bundling process now. The actual procedure for bundling and uploading VM images will depend on your target environment.
It is particularly trivial to setup AppScale in the EC2 environment. The EBS technology of Amazon makes it absolutely simple to create AMI images with AppScale. Here's all you have to do:
1. Start a fresh Ubuntu Lucid 10.04 EBS image (eg: ami-1634de7f). If you start this VM as a m1.large instance the whole thing will be over much quicker.
2. Run the above described procedure to checkout and build AppScale on the EC2 instance.
3. Login to your AWS management console. Right click on your EC2 instance and select the "Create Image (EBS AMI)" option from the menu that appears. This will start bundling your AppScale AMI and it will be available for deployment within several minutes.
It is sometimes necessary to create VM images with only the AppScale-Tools. In this case you may only checkout the AppScale-Tools source code and build it. However you will have to install a few additional libraries manually.
apt-get install openjdk-6-jre
apt-get install ruby
apt-get install rubygems
apt-get install ruby1.8-dev
gem install json
This should enable you to run AppScale-Tools on your VM image.
In my next post I'll describe how to start AppScale and deploy applications on the AppScale PaaS.

Saturday, November 10, 2012

Flexible Cloud Computing with AppScale

I recently started contributing to AppScale, an open source project aimed at developing a scalable Platform-as-a-Service (PaaS) solution. AppScale project was initiated by UC Santa Barbara with the intention of implementing an open cloud PaaS that would enable more research and studies in the area of cloud computing. But over the years AppScale has evolved rapidly gathering a wide range of features and now many enterprise users are finding it useful as a platform that facilitates private, public and hybrid cloud deployments. 
One of the most attractive features of AppScale is the flexibility it provides to the cloud administrators and cloud application developers. Cloud administrators can deploy AppScale on a variety of infrastructure setups. It can be deployed on virtualized computing clusters based on solutions such as Xen and KVM. AppScale also runs on Infrastructure-as-a-Service (IaaS) solutions such as Amazon EC2 and Eucalyptus (It is worth mentioning that Eucalyptus also started out as a research project in UC Santa Barbara). Also if needed AppScale can be deployed directly on physical hardware without the support of any virtualization service. AppScale also comes with a Ruby API and a set of command line tools that can be used to deploy AppScale clouds on any of the above infrastructure setups with minimal human intervention. A single shell command is all it takes to deploy even a 100-node AppScale cloud. To make this process even easier, I recently implemented a new web UI component which allows users to deploy AppScale without bothering about the infrastructure complexities at all (more on this in a future blog post).
As a PaaS offering, AppScale exports a wide range of services for the cloud application developers to use in their applications:
  • Datastore - Persistent storage for application data. Generally operates as a replicated key-value store with support for range queries and transactions within entity groups.
  • Namespace - Facilitates segmenting data into multiple partitions. Can be used in scenarios where certain data items need to be separated from each other (e.g: Production data vs Test data)
  • Memcache - Distributed cache. Useful in developing stateful applications and improving application performance.
  • Blobstore - Persistent storage for large data objects and files.
  • XMPP - Provides instant messaging capabilities to AppScale applications.
  • Channel - Allows pushing data into client's JavaScript code.
  • Users - User account creation and profile management.
  • Mail - Facilitates sending e-mails from applications.
  • Images - Supports programmatic manipulation of images.
  • URL Fetch - Facilitates consuming local and remote REST APIs.
  • Task Queue - Facilitates asynchronous execution of long running jobs.
All these fundamental services are fully API compatible with Google App Engine (GAE). Therefore any GAE application can be deployed on AppScale with zero modifications. This has two very interesting outcomes for the users. First it makes it absolutely simple for the users to migrate from GAE to their own private or hybrid cloud offering based on AppScale. Second, it allows developing applications for AppScale quite straightforward as all GAE APIs are very well documented and comes with a powerful SDK. As a result AppScale has managed to gather a large number of sample applications and a very large developer community actively writing apps for AppScale in very quick time. Just like in GAE, applications can be developed in Java, Python or Go for AppScale. Another interesting aspect is that AppScale allows using a wide range of database systems underneath its Datastore API. Currently supported database systems include Cassandra, HBase, Hypertable, MongoDB, MemcacheDB, MySQL cluster, Voldemort and Redis. This is one area where the flexibility of the AppScale architecture can be observed clearly as it enables cloud administrators to setup AppScale with any one of these database solutions depending on their application requirements and organizational standards.
One thing that should be stressed is that AppScale is not just about running GAE applications. It facilitates deploying a wide range of other applications in the cloud too. This is mainly enabled by Neptune, a software overlay that runs on top of AppScale. It's comprised of a domain specific language that allows developers to execute any arbitrary program in the AppScale cloud PaaS. These programs may include standalone programs written using any arbitrary language, MapReduce jobs and high performance computing applications developed using technologies such as MPI, UPC, X10 and StochKit. The ability of AppScale and Neptune to execute high performance computing applications in the cloud has attracted a lot of attention from the scientific research community as it enables executing long running resource intensive tasks on the cloud using as many nodes as required thus greatly reducing the task completion time and eliminating the need to procure expensive server grade hardware.
On top of all this flexibility, AppScale also provides excellent fault-tolerance and autoscaling capabilities. All the critical services such as the database and the application server can be easily replicated for high availability. ZooKeeper is used to keep track of all the active services and nodes, and automatic failover is performed upon detecting failures. The AppScale autoscaler component keeps track of resource utilization and system performance related metrics, and spins out new nodes dynamically as the demand changes over time. Autoscaler is another very flexible component in the AppScale architecture, in that it allows cloud administrators to engage custom autoscaling policies depending on their application performance and scalability requirements. Some of the built-in autoscaling policies include HA aware autoscaling, QoS aware autoscaling and cost aware autoscaling. If needed more than one autoscaling policy can be engaged at once with an administrator defined priority arrangement. 
One of my personal favorite features of AppScale is its placement support. This is the ability of the PaaS to smartly place cloud services given a set of nodes. For an example if we start an AppScale instance  using three nodes (that is 3 physical or virtual machines), it will place an application server component and a database component in each of them. One of the database components would act as the master and the others would act as slaves. Automatic data replication will be enabled among all database components. One of the three nodes will be designated as the head node and the load balancer and ZooKeeper will be deployed in that node. Note that AppScale attempts to use the nodes in the most optimal manner possible by replicating all the critical services. The actual placement strategy however is also configurable in AppScale. But if the administrator does not explicitly state a placement strategy, we can rely on AppScale to figure out a suitable placement strategy on its own. 
If my introduction of AppScale has intrigued you to try it out, feel free to grab the latest stable source from our github repo. Detailed instructions on building the source and creating your own AppScale machine images can be found in the following wiki pages:
If you need a more ready-to-roll distribution of AppScale to take a quick look, check out our public EC2 image ami-52912a3b which is preloaded with AppScale 1.6.3. If you already have an EC2 account, you can simply setup AppScale command line tools on your computer and start an AppScale instance in EC2 using the tools and the above AMI.
I will roll out a couple of detailed blog posts on setting up AppScale in the near future, so stay tuned.

Friday, August 17, 2012

Introducing WSO2 Carbon 4.0

Samisa Abeysinghe speaking about the latest release of WSO2 Carbon.

Monday, November 15, 2010

SOA Meets the Cloud

We just released WSO2 Stratos v1.0.0, the SOA PaaS solution based on WSO2 Carbon. Stratos enables you to run WSO2 middleware on a cloud infrastructure in a completely multi tenanted environment. This release brings you following SOA middleware services:
  • WSO2 Enterprise Service Bus as a Service
  • WSO2 Application Server as a Service
  • WSO2 Data as a Service
  • WSO2 Governance as a Service
  • WSO2 Identity as a Service
  • WSO2 Business Activity Monitoring as a Service
  • WSO2 Business Processes as a Service
  • WSO2 Business Rules as a Service
  • WSO2 Mashups as a Service
  • WSO2 Gadgets as a Service
With Stratos you can deploy webapps, web services, mediation flows, gadgets and business processes on the cloud. Just like all WSO2 products, Stratos is also free and open source. Try out Stratos for free at cloud.wso2.com.