TCP tuning on Linux

I came across an interesting article from US Department of Energy which goes in detail on various Linux TCP parameters that can be tuned to achieve better performance. I think it's a must read for anyone deploying applications on Linux:

http://fasterdata.es.net/TCP-tuning/linux.html

Saving Money on Inter-Cloud Communication with GridGain

As you probably may have already read, GridGain 3.0 will come with TCP discovery which in turn will support discovery of different cluster groups. For example, you can have your EC2 Cloud belong to one network group and your boxes on your local network belong to another, and all nodes in both groups will discover each other automatically even though there is no direct connectivity between some of them. So, from user stand point, you get a view on the whole grid without worrying about underlying groups or connectivity constraints. However, here is another advantage of such network topology that I have not mentioned before - it saves you money.

Let's say you have Group1 running on in your local network and Group2 running on EC2 cloud. The way GridGain implements it, there would be at least one network tunnel open between one hub node H1 in Group1 and at least one hub node H2 in Group2 (there can be more tunnels for redundancy). So, all the communication that goes from any node in Group1 to any node in Group2 would have to go through this tunnel, essentially from hub H1 to hub H2 or vice versa.

So, imagine now that you have a node N1 in Group1 sending a message to all the nodes in cloud Group2. With standard clustering approach, node N1 would have to have a physical connection with all nodes in Group2. This would mean that the same message would have to be send to each node in Group2. As in cloud environments you pay for external traffic, and this traffic is external, if you have M number of nodes in cloud Group2, you would have to pay M times for the same message. However, in GridGain approach, the message path would be as following:

N1 -> H1 -> H2 -> Group2.

This means that there would be only one message exchanged between the groups (H1 -> H2), and then H2 would distribute it internally within the cloud Group2. As internal cloud traffic is free, you only pay for one message sent from H1 to H2. Given that number of nodes in the cloud Group2 is dynamic and can grow very fast upon request, such cost-optimized communication between external nodes and the cloud essentially becomes the most cost-effective way to communicate with the cloud.

On top of that, GridGain will also support one way connections. So, for example, if your cloud firewall is configured not to allow external connections but to allow incoming connections, then H1 will connect to H2. If your firewall is configured the other way, then H2 will connect to H1.

Stay tuned for GridGain 3.0 release scheduled for Q4 this year.

 

GridGain at Jazoon 09

GridGain will be presenting at Jazoon09 - International Conference on Java Technology at Zurich, Switzerland, on Tuesday June 23rd. If you are around the Zurich and attending the conference - come see our presentation.

As usual you can expect lively discussions in the areas of:

• Compute and Data Grids
• Cloud Computing
• MapReduce
• Scalability

And of course as always plenty of live coding that you won't see anywhere else - live grid application in 10 minutes from scratch!

Hope to see you there.

 

GC3D - 3D Rendering Engine Using GridGain

It turns out that guys at GC3D have been busy. I have recently found out that they have created a web-based 3D distributed rendering engine, using GridGain as a distributed computing framework.

Here is a pretty cool animation created with this framework - Meteor Shower by Marijn Swenne:



Here are some other interesting examples created with POV-Ray or MegaPOV.

The project allows you to submit POV files for processing from the website and provides some monitoring on the status of grid topology and active grid tasks while rendering happens in the background on the grid.

Technologies used involve GridGain as Grid Computing framework, POV-Ray / MegaPOV as 3D Rendering engine (ray-tracing), MEncoder to encode the video, x264 as video codec, JQuery as JavaScript library, Tomcat as web-server, etc...

It is really nice to see what amazing things you can achieve using the right tools at hand and distributed computing to speed things up.

GridGain Pearls (Continued...)

Nikita started GridGain Pearls list last week and I think it's a great idea. Here are some more GridGain pearls to add to the list. Once we have a full list, we will post it on the Wiki. Feel free to comment with your own.



How to inject user resources into your grid tasks or jobs?

public class MyTask extends GridTaskAdapter {
    ...
    @GridUserResouce
    MyResourceClass resource;
    ...
}

How to inject Spring beans into yoru tasks or jobs?

public class MyJob extends GridJobAdapter {
    ...
    @GridSpringResource(resourceName="myBean")
    MyBeanClass myBean;
    ...
}

How to get grid node topology version?

long ver = GridFactory.getGrid().getTopologyHash();

How to listen to node topology changes?

GridFactory.getGrid().addDiscoveryListener(new GridDiscoveryListener() {
    public void onDiscovery(GridDiscoveryEventType evt, GridNode node) {
        ...
    }
});

How to execute grid task asynchronouosly?

GridFactory.getGrid().execute(MyTask.class, someArg, new GridTaskListener() {
    public void onFinished(GridTaskFuture future) {
       ...
    }
}

How to query grid events from all grid nodes?

Grid grid = GridFactory.getGrid();
grid.query(new MyGridEventFilter(), grid.getAllNodes(), 2000 /*timeout*/);

How to print CPU utilization (or any other metric) for all nodes?

for (GridNode node : GridFactory.getGrid().getAllNodes()) {
    System.out.println("Node-ID=" + node.getId() + 
        ", Cpu-Utilization=" + node.getMetrics().getCurrentCpuLoad());
}

GridGain Double Jug Rally

Nikita will be speaking at Triangle JUG (Raleigh, NC) on May 18th and Charlotte JUG on May 19th. As always, this is going to be a fun presentation with plenty of live coding and exchange of ideas.

If you are nearby - please come see your fellow Java, grid and cloud developers and learn about GridGain.

May 18th - Triangle JUG: http://trijug.org/
May 19th - Charlotte JUG: http://www.charlottejug.org/

Grids vs. Clouds

I constantly run into conversations where people use the word Grid and Cloud interchangeably without actually understanding what each one really means. When I actually ask what do they mean by Grid or Cloud - the usual answer is that they are the same. Well, they are not.

Cloud Computing is on-demand provisioning of virtual resources and services around those resources. For example, if a cloud provider wants to provide a data storage (like S3), then the same provider also needs to provide APIs to access and manipulate this data storage. If a cloud provider allows for allocation of virtual instances, then the same provider must provide APIs to create images and deploy them on those instances.

Grid Computing, on the other hand, has to do with providing ability to join multiple computers together for the purpose of solving computational problems. It deals with such issues as auto-node discovery, dynamic deployment and redeployment of a problem, topology and collision resolutions, load balancing and monitoring, etc... A grid should allow you to take a problem, determine the optimal node topology for it, dynamically deploy the problem onto the chosen topology, provide means to divide the problem into multiple parts for parallel execution, distribute the problem within topology, gather results, and return them to user. In the middle of all that, a grid should automatically scale computations as load changes by transparently utilizing additional nodes while remaining fault tolerant.

There is an obvious connection between grids and clouds. If clouds let you easily deploy your application on 20 nodes, then grids should easily connect those applications into a cluster. This makes it absolutely vital to allow users seamlessly grid-enable their applications on the clouds. At GridGain we are working on making the process of gridifying cloud applications as transparent as possible. For example, with GridGain 3.0, user applications will transparently auto-discover each other on a cloud, without any additional effort or configuration. On top of that GridGian will allow combining different clouds into one joined topology - this way you can have a few computers from your local datacenter work together with virtual instances started on a cloud.

So, to summarise, in majority of the cases (with some exceptions) cloud computing has to do with providing virtual hardware resources together with APIs that allow access to those resources. Grid computing is at a higher level - it is the middleware that allows you to join multiple physical or virtual resources together to solve computational problems in parallel fashion.