7 posts from February 2009

EBS (Elastic Block Store) - Persistent disks in EC2

I did read about this a while back when the challenges using EC2 was how not lose a database in case of a machine failure. Luckily it never happened and forgot all about EBS, the persistent disk for Amazon EC2. We went live with a new customer over the weekend and EBS came up all over again for data backup. Quite simple to use it.


1. Created a new volume using ElasticFox and attached it to a running instance. 
2. Formatted it to ext3 - yes | mkfs -t ext3 /dev/sdh
3. Created a new folder /permnt
4. Mounted it - mount /dev/sdh /permnt
5. That's all, it is up and running.

Its quite a pleasant experience using Amazon's various services - they are so simple to use which always inspires us startups to emulate that simplicity.

Still to check auto backup to S3 from EBS - I am sure it will be as simple.

Post a comment Tags: amazon, ec2, ebs

FTP in Java

Sending files through ftp is a piece of cake, or so I thought with all the commons net libraries around. I had to spend a few hours trying with apache commons net library and finally did it through sun.net.ftp.FtpClient. Below is the full code for anyone who needs it, without all the log messages.


TelnetOutputStream fos = null;
BufferedOutputStream bos = null;
FileInputStream theFile = null;
BufferedInputStream bis = null;
FtpClient ftp = null;
try 
{
ftp = new FtpClient();
ftp.openServer("FTP_SERVER");
ftp.login("FTP_USER", "FTP_PASSWORD");
ftp.cd("REMOTE_DIR");

fos = ftp.put("REMOTE_FILENAME");
bos = new BufferedOutputStream(fos);

theFile = new FileInputStream("LOCAL_FOLDER" + "/" + "LOCAL_FILENAME");

              bis = new  BufferedInputStream(theFile,1000000);
         
       byte buffer[] = new byte[1000000];
       int i;
       while ((i = bis.read(buffer)) != -1) 
       {
          bos.write(buffer,0,i);
       }
} 

catch (Exception e) 
{
throw e;
}
finally
{
           if (bis != null) bis.close();
           if (theFile != null) theFile.close();
           if (bos != null) bos.flush();
           if (bos != null) bos.close();
           if (fos != null) fos.flush();
           if (fos != null) fos.close();
           if (ftp != null) ftp.closeServer();
}

Post a comment Tags: java, ftp, ftpclient

Adobe Collaboration Services

Adobe has launched hosted software toolkit (can't think of a better name) to build collaborative applications. You can check it out here at http://labs.adobe.com/technologies/afcs/. Some interesting features which are business agnostic - 


  • VoIP Audio
  • Webcam Video
  • Chat
  • Multi-User Whiteboards
  • Real-Time File Sharing
  • User Management
  • Roles and Permissions
  • Robust Data Messaging




An interesting trend in software development - it is becoming similar to the hardware assembly line - like the way we order a Dell computer. It will be interesting to see how easy and seamless integrating the above stuff into an application will be. Add other services from acrobat.com and it is a decent business toolset.

1 comment Tags: flex, cocomo, collboration

Scalability & Failover on Amazon EC2

Interesting aspect to tackle after putting applications on EC2 in a live production environment. Our first customer has been live for over 1 year on EC2 and never been down for a single time. We didn't have to reboot the linux server though we had to restart our java processes for upgrades. Touchwood. Database incremental backups happen every minute to S3 and a daily back up at night. This is mostly an enterprise app, so not very stringent requirements on real time failover. Shortly we are going live with a new retail customer facing application - a 24 x 7 uptime requirement. Scalability is not much of an issue as our server is still operating under 65MB with response times under 50ms most of the time. Failover is a key aspect for us - passive or active, active being the preferred option.


Scalr seems to be decent option (and the only one I could find) for EC2 environments. Server side clustering which also spawns new instances as load increases. Terracota has an offering on EC2 environment where the cache serves as the intermediate database for all practical purposes.

In our solution there is no http session or cache to hold data, every read and write operate on the database. There is only a small portion of read only configuration data that is cached in the server. So java server operates in a stateless mode - meaning a browser client has no affinity to a server. If there are 3 servers then client can utilize all 3 servers for its requests. So client itself can take of clustering and failover. When client first comes to server thru a url server loads the client and gives all server urls to it. Client discovers an available server out of this and sticks to it till server is either down or too loaded. Client switches to another server at that point from its list. No need for a gatekeeper on server.

Failover is largely needed at database layer. As long as database is replicated realtime (master-master replication) failover from a database perspective will be seamless. We are exploring solutions for this:

1) mysql clustering. There are some trials of this but none seem to be in a production EC2 setup.
2) C-JDBC or Sequoia: JDBC level clustering, seems the most transparent way. Have to check if JGroups etc can talk to EC2 servers only visible on http
3) HA-JDBC: Similar to C-JDBC.

Will check out in the next couple of weeks and post the results.

Post a comment Tags: mysql, database, ec2, clustering, failover, replication

ANT - Another Neat Tool

Ant (http://ant/.apache.org) is embodies simplicity, extensibility and never in your way software. A lot of developer tasks can be automated with this tool. For quite some time we used it to just build a WAR file and deploy it Tomcat on our desktop machines. Deployment to server used to be a one hour task. Build with the server configuration files, ftp to server, extract static stuff to apache, re-deploy the database and recycle the server.


We were able to automate the whole process in ant. I like the import feature where all common tasks are hived off into a common file and the front facing files can setup different config parameters as per deployment - desktop vs server.

<import file="${basedir}/build_common.xml"/>

Other feature I like is macrodef where in a task can take in parameters and use them inside the task. After the server specific war file is built, its time to ftp it to server.

<ftp password="password" server="amazon ec2 server" userid="userid" 
remotedir="/rermotedir">
<fileset dir="${build.dir}">
            <include name="${context.root}.war"/>
</fileset>
</ftp>

After the file made it to server, time to deploy it. All the commands for deployment are captured in a shell file on the server, so it just came down to invoking the shell script from ant.

<sshexec host="amazon ec2 server"
username="username" trust="true"
keyfile="amazon id_rsa-gsg-keypair"
command="deployment.sh ${context.root}"/>

All of it done under 20 mins and the new version of software is up and running.

Post a comment Tags: ant, deployment, ec2

RIAs delivered faster with CDN

In a traditional server centric architecture UI is built on the server via php scripts, jsp or asp. So the UI is built and all that html travels back to the browser over the network. Ajax reduces this traffic by updating portions of pages on the browser. CDN benefits these architectures in 2 ways:


1) Delivering static content from an edge server
2) IP route optimization - like a dedicated network pipe between the client browser and the server (may not be complete end to end but a large part of the network pipe) provided by the CDN provider. So IP packet loss should be lower leading to better latency.

When it comes to full blown RIAs with complete client side UI frameworks - GWT or Flex (there are quite a few complete client side JS frameworks - have used GWT and Flex and listing here) the entire network traffic after the client is downloaded is limited to just data transfer requests. Static content becomes more either in the form of Flex modules or the huge JS framework files. So point 1) above becomes more critical to RIAs. Point 2) - route optimization can still deliver benefits but as the traffic is just data (should be roughly about 20% of a complete html UI) the benefits are much less. In our deployment (Flex + Java backend) a server request typically lasts about 20ms on the server on a 32MB tomcat. The largest response size goes to about 8K after compression (we compress data as it mostly xml).

Post a comment Tags: ria, cdn

Amazon CloudFront - CDN for everyone

Had been checking out Amazon's CDN solution - CloudFront for one of our solutions. Amazingly easy to setup and run. Check out the product page at http://aws.amazon.com/cloudfront/.Very simple to get up and running:


1) Create a S3 bucket for static stuff
2) Create a CDN distribution via the windows cloudfront admin tool
3) Changed the client UI code to refer to a different server for the data etc Now that UI stuff is deployed on CDN, the business server is on EC2 at some other place.

I am using this with Flex code so quite a few benefits apart from static images, js, html. The combined flex modules are about 1.5 MB (largest being 400 KB) so all of this is now being served out of the cdn. The initial screen loading (flex framework + first module) takes 24 seconds to show the first screen. With cdn it is down to 10 seconds. With a little bit more tuning (using RSL) this should come down further. RSL way of compiling typically takes out about 150-200 KB out of the main app module.

One thing to highlight here. RIA (Flex, GWT or any client only frameworks) will benefit the most with CDN as the entire UI is built and painted at the browser. Typically this is all static sources/compiled stuff and hence can leverage CDN much better. RIAs make stateless servers a reality.

How does Cloudfront compare with Akamai? I am doing this from Bangalore, the nearest cloudfront edge server is in HK. Akamai's footprint is a lot more dense, I think they have a couple edge servers of them right here in Bangalore and definitely in India. Akamai delivers the same first screen in about 7 seconds. So there is some 30% more speed than Cloudfront. To Amazon's credit they have just started, so a fair comparison can be done maybe a year down the road or in a geographic location like US where Amazon's footprint is better.

But pricing - Cloudfront beats it hands down with its pay as you go usage model and no fixed monthly or setup costs. Overall very satisfied with the performance so far and planning to go live very soon on this.

One thing to watch out for - all static sources once uploaded to the CDN will NOT expire less than 24 hours. A bummer during testing phase. One workaround is renaming changed resources with every deployment, maybe with a version number. We are following that for the swf file names, images and other resources are ok to live with a 24 hour life.

2 comments Tags: cloudfront amazon akamai