@Gridify Cloud Computing

Lower Your Electricity Bill With GridGain

2009-11-13T18:18:00.000-08:00

Recently, when talking to a company that creates consumer electronics, an interesting idea popped up. This company is really struggling in minimizing their electricity bill and I was asked if GridGain could help. Interestingly enough, GridGain can help. Let's suppose you have two data centers, A and B, and data center A has low electricity costs between 12am and 12pm and data center B has low costs between 12pm and 12am. All you need to do to make sure that either data center is used during low cost time window is create GridLowElectricityTopologySpi as follows:


@GridSpiInfo(author = "Your Name", version = "1.0")
@GridSpiMultipleInstancesSupport(true)
public class GridLowElectricityTopologySpi 
    extends GridSpiAdapter 
    implements GridTopologySpi {
    /** Auto-inject logger. */
    @GridLoggerResource
    private GridLogger log = null;

    /**
     * Start SPI.
     */
    public void spiStart(String gridName) {
        if (log.isInfoEnabled() == true) {
            log.info(startInfo());
        }
    }

    /**
     * Stop SPI.
     */
    public void spiStop() {
        if (log.isInfoEnabled() == true) {
            log.info(stopInfo());
        }
    }

    /**
     * Given whole grid topology return only nodes
     * selected for execution of this task.
     */
    public Collection<GridNode> getTopology(
        GridTaskSession ses, 
        Collection<GridNode> grid) {
        int hour = Calendar.getInstance(Calendar.HOUR_OF_DAY);

        List<GridNode> top = new ArrayList<GridNode>(grid.size());

        for (GridNode node : grid) {
            String segment = node.getAttribute("segment");

            if (hour <= 12) {
                if (segment.equals("A")) {
                    top.add(node);
                }
            }
            else if (segment.equals("B")) {
                top.add(node);
            }
        }

        return top;
    }
}

Now, the nodes from data center A need to have the following in their configuration (the configuration for data center B is analogous).


<bean 
   id="grid.cfg" 
   class="org.gridgain.grid.GridConfigurationAdapter" 
   scope="singleton">
    ...
    <property name="userAttributes">
        <map>
            <entry key="segment" value="A"/>
        </map>
    </property>
    ...
</bean>

This is all that needs to be done to lower your electric bill. Now all tasks will be routed to the data center with lowest electricity cost.

Enjoy!

GridGain Is Presenting at Dallas JUG, November 11

2009-11-06T11:05:00.000-08:00

GridGain will be presenting at Dallas Java User Group at Dallas, TX, on Wednesday, November 11th. If you are around the Dallas area and interested in Cloud Computing - come see the presentation. As usual we'll have lively discussion on clouds and grids and as always plenty of live coding that you won't see anywhere else - live cloud application in 10 minutes from scratch!. We also going to show some sneak peek preview of GridGain 3.0, including live Cloud Demos.

Endless Conversations with Cucumber

2009-09-23T16:37:00.001-07:00

There is a new kid on the block, Behavior Driven Development, or BDD, so naturally I rushed to check it out. I immediately came across Cucumber, a BDD testing framework for Ruby. The Cucumber site is fairly informative and you pretty much immediately understand that Cucumber is about writing "Given->When->Then" test cases (or as they are called Scenarios). Unlike other test frameworks, developer can really "talk" to Cucumber. You can start implementing a simple use case as follows:

Given that a user arrives to any page
When no session exists
Then user is redirected to Login page

Sounds pretty straight forward - one of the pros of using Cucumber is that your test scenarios are pretty much self-documenting. Once you write this scenario, you start executing it in Cucumber which will keep failing until it succeeds. When you will run it the first time, Cucumber will not understand any of this. As you keep going, you will have to define "that a user arrives to" in Cucumber in order for the first step to pass. Then you will have to define "no session exists", and then "user is redirected to". So gradually you will be explaining to Cucumber what it is that your test case is doing.

My initial impression was that this is way too cool. Looking from the outside, you can basically read the code in plain English which simplifies readability and understanding of what it is you are testing. But once I started looking at it a bit deeper, it occurred to me that testing this way on a serious project can be really dangerous. Here is why.

Cucumber Imposes Endless DSLs
This comment may go towards BDD in general. Basically Cucumber allows you to create an endless Domain Specific Language (DSL) for your tests. Any new or existing developer can just "speak" his mind to Cucumber which will inevitably lead to more and more new "key phrases" for the overall DSL. In my view this may significantly hinder reusability of test cases and pretty soon you may end up in a position where you have thousands upon thousands of unmaintainable Cucumber scenarios. If you look at GridGain test cases for example (and we have about a thousand of test cases), we managed to keep them very concise only because they are mostly reusing existing test components available to them. One may argue that you can do the same in Cucumber, but this would be against overall Cucumber philosophy in my view.

Enterprises Need Structure
Yes, enterprise projects need structure and developers need to be constrained by available libraries and APIs. You cannot just let every developer go willy-nilly by allowing him to "talk freely" to the underlying testing framework. I have nothing against a specific DSL for testing (on the contrary, I would encourage it), but this DSL should be well defined and used by everyone in the company.

I should mention, however, that on a relatively small project, testing the Cucumber way may be very productive. Since small projects are exactly the sweet spot for Ruby, Cucumber may very well be the best testing framework available for Ruby. But as the project will grow, using Cucumber will become more and more painful and unmaintainable.

So, here is the test scenario for GridGain that you could create in Cucumber (forgive the sarcasm, but I couldn't resist):

Given that GridGain is a large enterprise project
When I write test scenarios in Cucumber
Then I will shoot myself in the foot

P.S. I realize that this post may stir some disapproval from Cucumber community. In the interest of full disclosure I want to mention that I have not used Cucumber on a real project and simply am expressing my opinion here which is not based on actual project experience.

GridGain - Simplicity and Developer Usablity

2009-08-31T17:20:00.000-07:00

I just came across a pretty old blog about GridGain where a user explained his experiences with GridGain and had a brief Q&A via comments.

When asked about difference between GridGain and Globus I think he gave a spot-on answer:

"No, I’ve never worked with the Globus Toolkit. From what I’ve read, Globus is more about collaboration of organizations (forming "virtual organizations") and solving all the problems that come with it like interoperability and security concerns.

GridGain on the other hand has a strong focus on simplicity and developer usability. I think it’s perfect for "local" grids with perhaps a few dozens (or hundreds?) of nodes. You can certainly build a more comprehensive solution on top of GridGain, but the local computational grid use case is where it is best suited at the moment.

In my concrete case at work we’ve got a highly secured internal network and need a convenient solution for distributing the workload to boost throughput. Globus looks like overkill, but I’m confident that GridGain is the right thing for us."

Although this conversation took place about 2 years ago and GridGain had since evolved into a Cloud Development Platform with aplenty of new features, our (quoting) "strong focus on simplicity and developer usability" has not changed. Even with such features in the pipeline as data grid and hands-free self-scaling on the clouds, GridGain developers will still enjoy the same simple deployment-less process:

Change -> Compile -> Run On Cloud

Take a look at some of our Online Screen Casts and find out for yourselves.

What is a Native Cloud Application

2009-08-21T18:14:00.001-07:00

With the latest push towards the cloud in the industry and some M&A actions in cloud area we are beginning to be faced more and more with a simple question - what does it mean to build an application for a cloud? At GridGain we strongly believe that for an application to take a real advantage of the cloud it should have some of the following characteristcs:

Massively Parallel Computations
Massively Parallel Data
Auto-Scalability On the Cloud

I like to call applications with such characteristics Native Cloud Applications, or NCAs. With our upcoming GridGain 3.0 release we are planning to build a Cloud Development Platform that will allow you easily build and deploy NCAs on any of the existing cloud providers. So what do the above mentioned characteristics really mean?

Massively Parallel Computation
An application that supports massively Parallel Computation is a application that can simply distribute computations in an environment such as cloud, where resources can be added or removed at any moment either manually or automatically. If you add a resource, your application has to take immediate advantage of it and start distributing computations onto it (the vice versa should apply whenever you remove a resource). In GridGain we achieve massively parallel computations with our innovative MapReduce implementation, Automatic Peer Class loading, and Adapter Discovery and Communication SPIs.

Massively Parallel Data
Well, you may think that most clouds already have distributed storage, so you can just use it. The reality here is that storage like S3 on Amazon provides a distributed disk storage. It does not provide distributed In-Memory storage like a distributed cache or data grid. Google GAE does provide it to a certain extent, but as a cloud, it is less flexible to use than Amazon. So, in order to take a full advantage of the cloud your application In-Memory storage must dynamically increase whenever new resources get added and vise versa. GridGain 3.0 is coming with a comprehensive dynamically partitioned data grid solution that does just that.

Auto-Scalability On The Cloud
A NCA must be able to automatically instruct the cloud to scale up or scale down depending on current load and latency characteristics. In GridGain 3.0 user will be able to specify dynamic SLAs or strategies that will allow to add any kind of resource to a cloud, from addtional memory or CPU to starting or removing an arbitrary number of images.

Although we are adding such a complex and comprehensive feature set, our emphasis on ease of use and ease of deployment has not changed. Stay tuned for our upcoming release.

GridGain presents at Chicago Java User Group, August 18th

2009-08-17T12:08:00.000-07:00

GridGain will be presenting at CJUG - Chicago Java User Group at Chicago, IL, on Tuesday August 18th. If you are around the Chicago area and interesting in Cloud Computing - come see our presentation. As usual we'll have lively discussion on clouds and grids, get a preview on our upcoming GridGain 3.0 release, and 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!

GridGain Is Growing And Growing Strong

2009-08-04T14:59:00.000-07:00

Last month was a very good month for GridGain as we achieved a few important milestones. First and foremost, we crossed a threshold of 1 million starts. Since GridGain product was first launched 2 years ago (around August 2007), GridGain nodes were started over a million times across the globe. This is a very conservative number... I am sure the real number is at least 30% higher. Here is a graph of GridGain starts since the beginning:

The vertical axis has number of starts, and the horizontal axis shows time in months. According to these stats, a GridGain node is started at least every 30 seconds somewhere around the globe.

Another pretty cool stat is our forums usage. We have arguably the most active user community among all the products in the same space. Our forums have over 3,000 messages and over 80,000 views which is very good for a product in this space.

An lastly, there is no bigger reward for any Open Source contributor than kind user testimonials. Here is a few of the latest testimonials we received from our users and customers:

Thanks a lot for your help and for the great product. I'm starting to use Gridgain for one of our production systems and up to this point I had only joy! Keep up the good work.
--jjoubert

I am a big fan of GridGain. We at [...] implemented our solutions with GridGain capability. It is very impressive to my clients whenever we did presentations. Excellent products which helps us solving big problem for us. [...] offers software on SaaS market space which requires huge computing power when number of clients increase. GridGain provides the answer to our problem.
--Charles Hsiao

Thanks for an amazing product. I had considered several others, but GridGain is the most intuitive and well-documented.
--Andrew Hallock

You can find more user testimonials here. It's the usage stats and testimonials like this that keep us motivated to continually make GridGain the best Open Cloud Platform out there.

TCP tuning on Linux

2009-07-02T02:17:00.001-07:00

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

2009-06-30T11:30:00.000-07:00

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

2009-06-15T00:07:00.000-07:00

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

2009-06-09T00:57:00.000-07:00

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...)

2009-05-22T15:35:00.000-07:00

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

2009-05-15T18:57:00.000-07:00

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

2009-05-11T23:16:00.000-07:00

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.

GridGain Presenting At JavaOne 2009

2009-04-27T16:49:00.000-07:00

GridGain will be presenting at JavaOne 2009. This is our first chance to present at JavaOne, so we are very excited. Our session is on June 2nd at 10:50am at Esplanade 302 room. Our presentation is in many ways different from other presentations you will see as majority of the time we spend on coding examples which usually stir up interesting discussions.
Here are some of the coding examples you can expect to see:

Executing grid tasks on a grid with AOP and @Gridify annotations
Executing grid tasks on a grid using direct API calls
Grid job auto-failover demonstration
Grid node auto-discovery demonstration
Grid-enabled JUnit test demonstration

If IP-Multicast will be enabled, then expect some of your personal laptops to participate in the grid - this is usually lot's of fun. Also, we will be touching interesting subjects on grid and cloud computing.

So, if you are at JavaOne, you should definitely stop by!

Google App Engine - Where Does It Fit?

2009-04-16T18:04:00.000-07:00

This is yet another blog about Google App Engine (GAE) recent release of Java. Naturally, as an interested party, I rushed immediately to deploy my sample GridGain app on it, but immediately realized that you cannot deploy any sort of clustering or grid applications on the Google App Engine. This is simply not something they wish to support, happily leaving this portion of the market to Amazon EC2 customers.

A good way to think about GAE for Java is as of a Plain Vanilla Servlet Container Hosting. If you have a standard J2EE app that simply processes web requests and accesses DB data, then GAE is an ideal solution for you and will be much easier to use than Amazon EC2. But if your application needs to do anything beyond retrieving and showing DB data, then with GAE you will run into a brick wall. So, if GAE fits, if fits like a glove, but if it doesn't - then there is nothing you can do to help it.

Here is the list of some limitations you may wish to consider when starting with GAE:

1. You have no control over number of deployment instances.
This may be a non-issue for trivial use cases, but you immediately hit a wall if your application requires any knowledge of clustering or even of threads. For example, let's say you need to generate a web report that would normally take about 1 minute to generate in a single thread, which is normally too long for a web-request (GAE will automatically time it out after 30 secs). Ideally, to make it run faster, I would split it into multiple sub-parts, run it in parallel on several nodes, aggregate the results and produce a response to user within, say, 5 seconds.

However, there is nothing you can do to speed it up on GAE. Firstly, you have no idea how many parts to split the report into, and even if you did, there is no way to tell GAE that every part should run on a separate CPU or on a separate server instance altogether. On top of that, what if 9 out of 10 sup-parts completed successfully and 1 failed? Again, you cannot instruct GAE to retry just the part that failed - the whole request will have to be retried.

2. You have no control over load balancing
Not every application is a website and not every application can be measured in number of page hits. The underlying notion here is that if you are not a website, then GAE is not for you. However even if you are a website, not being able to control load-balancing can be quite limiting. If you take my report generation example above, GAE again would not be able to load balance it at all.

3. You cannot use any of the existing clustering infrastructure you have
If you already make use of clustering within your application (like discovery of different app server nodes, exchanging messages between app servers, using existing caching or compute grid products, etc..), you cannot do it in GAE. You are limited to the set of caching and data storage libraries provided by GAE only.

4. You cannot use full set of the JDK classes or services
Google published JRE White List for a list of JDK classes supported by the App Engine. The main limitation there is lack of AWT or Swing packages. Although not often used in web apps, this may be quite limiting for apps that use AWT for purposes other than thick UI, like dynamic image generation, etc... I should mention that GAE does offer its own image manipulation service to compensate for this.

5. You cannot access or store files
The only way to access a file is to put it in WAR and then get it off the classpath. Creation of files is prohibited - you can only store data using GAE datastore services. This alone can become a show-stopper for many applications, as even if your application does not access or store any files, it may very well depend on the libraries that do.

6. You don't get any access to the box your app is deployed on
From GAE standpoint, this limitation is justified. The GAE is running multiple WARs from different users on the same app server, so by giving you direct access to the box, they will be giving you access to the code that does not belong to you. On the other hand, not being able to access the box will scare many traditional sys admins who generally like to poke around production environments, look at OS-specific logs, do tuning, and other environment and runtime geeky stuff.

I will stop here as far as listing limitations. I think it is quite clear that GAE is not targeting enterprises as their customers. On the contrary, it looks like are they willingly leaving this portion of the market to Amazon EC2 and are concentrating on simple web application hosting which is a huge market on its own. The way they are beating Amazon here is by being elegantly simpler to use and deploy - there is no image creation, nor should user be concerned about number of images that are started. GAE will automatically manage web load and add CPU's to your app as load changes.

So, if you are a small business owner and need a quick and cheap hosting solution - go with GAE!

Auto-Searches On The Cloud

2009-03-26T17:37:00.000-07:00

In GridGain 3.0 we are coming up with a set of useful annotations to automate grid-enabling of common functionality that works on ranges and collections. The whole idea is that given a certain collection, GridGain can automatically split that collection into sub-collections, send them to remote nodes for execution, get results back, reduce them and return them back to user. Sort of automatic map-reduce for collecions.

Let's take search for example. You can model almost any search as taking a collection of values, picking the right value in that collection, and returning that value. For example, let's assume that we need to find the max value in a collection (forgive the simplicity of the example, in real life you would probably be grid-enabling searches that are a lot more complex than this one).

In Java this would look like the following:


public Integer findMax(Collection<Integer> vals) {
  Integer max = Collections.max(vals);

  return max;
}

If we were to grid-enable above functionality, we would have to do the following:

Map Step: Split the initial collection into a number of sub-collections
Send each sub-collection to a remote node
Have every remote node find a max value in the sub-collection assigned to it and return it.
Reduce Step: Find the maximum out of all values returned from remote nodes and return it to user.

As simple as it is, you can apply the same kind of steps to many other searches you do in real life.

To do this search in GridGain 3.0, all you would have to do is attach @GridifySetToValue(recursive=true) annotation to your method and you are done:


@GridifySetToValue(recursive=true)
public Integer findMax(Collection<Integer> vals) {
  Integer max = Collections.max(vals);

  return max;
}

By a virtue of attaching a single annotation, you are basically telling GridGain to perform steps 1 to 4 described above automatically. On top of that, with GridGain peer-class-loading functionality no code needs to be explicitly deployed to remote nodes at all. Simply bring up several GridGain images on a cloud and they are ready to start computing whatever you throw at them.

In the coming weeks I will show how some other annotations can be used to automate grid-enabling of other common tasks we encounter on daily basis.

I should also mention that you can achieve the above with relative ease on the current version of GridGain (you would have to do some of the steps manually though).

Stay tuned for GridGain 3.0 scheduled for release this summer.

GridGain Advance Training – Amsterdam, May 18-20, 2009

2009-03-19T23:47:00.000-07:00

GridGain will conduct 3-day advance public training in Amsterdam, May 18-20, 2009. This training provides full in-depth learning of all features in GridGain. Beyond standard features and use cases, this 3-day course goes deep in complex scenarios of homogeneous and heterogeneous environments, SPI development, global grid and advanced security, custom topology resolution, and many other advanced topics.

This 3-day training is intended for developers, architects and system analysts who are going to use GridGain in a complex environment and want to have unparalleled understanding and knowledge about every aspect of how GridGain is designed and how it operates. Taught by the people that actually develop the GridGain product and with labs to bring hands on experience.

For more information visit http://gridgain.eventbrite.com

Five Challenges In Setting Up Hybrid Clouds

2009-03-02T18:02:00.000-08:00

With emergence of cloud computing, the term "Hybrid Topology" or "Hybrid Deployment" is becoming more and more common. Let me first start with definition of what "Hybrid Topology" is. A "Hybrid Topology" is when you join different cloud deployments into one connected cluster. For example, you can have your local data center forming a join cluster with several images deployed on a cloud.

Here is a simple use case. Let's say that you have an application deployed in your local data center that stays idle for most of the time and only peaks for 3 hours in a day, say from 4pm to 7pm. To make it cost efficient, you want to keep as few nodes as possible for the most of the time and, once load peaks, you want to automatically detect that and bring up a few more nodes. These new nodes that you bring up to help your existing cluster may be in a totally different data center, or different cloud (e.g. Amazon EC2 or GoGrid), yet you want them to join your cluster and participate in load balancing, job collision resolution, job execution, fail-overs, etc...

Here are some challenges to consider when setting up hybrid clouds:

1. On Demand Startup and Shutdown
Your infrastructure must be able to start up and shutdown cloud nodes on demand. Usually you should have some policy implemented which listens to some of your application characteristics and reacts to them by starting or stopping cloud nodes. In simplest case, you can react to CPU utilization and start up new nodes if main cloud gets overloaded and stop nodes if it gets underloaded.

2. Cloud-based Node Discovery
The main challenge in setting up regular discovery protocols on clouds is that IP Multicast is not enabled on most of the cloud vendors (including Amazon and GoGrid). Your node discovery protocol would have to work over TCP. However, you do not know the IP addresses of the new nodes started on the cloud either. To mitigate that, you should utilize some of the cloud storage infrastructure, like S3 or SimpleDB on Amazon, to store IP addresses of new nodes for automatic node detection.

3. One-Directional Communication
One of the challenges in big enterprises is opening up new ports in Firewalls for connectivity with clouds. Quite often you will only be allowed to make only outgoing connections to a cloud. Your middleware should support such cases. On top of that, sometimes you may run into scenario of *disconnected clouds*, where cloud A can talk to cloud B, and cloud B can talk to cloud C, however cloud A cannot talk to cloud C directly. Ideally in such case cloud A should be allowed to talk to cloud C through cloud B.

4. Latency
Communication between clouds may take longer than communication between nodes within the same cloud. Often, communication within the same cloud is significantly slower than communication within local data center. Your middleware layer should properly react to and handle such delays without breaking up the cluster into pieces.

5. Reliability and Atomicity
Many operations on the cloud are unreliable and non-transactional. For example, if you store something on Amazon S3 storage, there is no guarantee that another application can read the stored data right away. There is also no way to ensure that data is not overwritten or implement some sort of file locking. The only way to provide such functionality is at application or middleware layers.

There are certainly other things that could go wrong, but these turned out to be the main challenges we had to resolve while working on the GridGain 3.0 version. Some of the cool features we plan to support are On Demand Startup and Shutdown Policies (including Cost-based policies) and Disconnected Clouds. GridGain 3.0 is planned to be released this summer, so stay tuned!

GridGain At OGF25/EGEE Conference

2009-03-02T01:08:00.000-08:00

GridGain project will be presented at OGF25/EGEE International Conference on March 5th, 2009.

EGEE, OGF and OGF-Europe are spearheading efforts to connect developers, users and newcomers to distributed computing for the benefit of business and research, now and in the future. The EGEE 4th User Forum / OGF25 & OGF-Europe’s 2nd International Event will catalyse people from diverse sectors to drive forward the evolution of distributed computing and open standards for the knowledge-based economy.

This premier event in Europe will help to strengthen existing business and research communities and foster new relationships and collaborative developments on a European and global level. Special emphasis will be placed on showcasing high-level technological developments, identifying best practices, evaluating user requirements and deliberating the top priorities for the future.

EGEE 4th User Forum/OGF25 & OGF-Europe’s 2nd International Event is a multi-faceted event featuring keynote talks delivered by high-profile experts from business, government and research, and a series of parallel and joint sessions focusing on specific sectors and technologies.

For more information visit OGF25/EGEE website.

GridGain At Calgary JUG

2009-02-10T13:22:00.000-08:00

GridGain will be presenting at Calgary JUG this Thursday, February 12th, 2009. As always we are going to have a great time with pizza, cloud computing, and raffled iPod with “GridGain – Grid Computing Made Simple” custom engraving. If you are in Calgary – Edmonton area – please make sure to stop by. Also, make sure to bring your laptop if you would like to participate in our ad-hoc grid demo.

More information at http://cjug.com

Processing Events in Grid Environments

2009-02-09T17:20:00.001-08:00

When working with distributed systems, it is often problematic to exchange events between grid nodes. Simple broadcasting does not work in majority of the cases. Just imagine having a grid of 100 nodes, and every node pushing its events to all other nodes. If you just push every event at the time it happens, then you will end up pushing events every millisecond, which will flood the network. If you let them accumulate and throttle them, then you end up pushing very large messages which is not good for your network either. On top of that, none of the nodes care about most of the events that happen on other nodes.

The right approach is to provide a flexible event storage and query events on demand as needed.

For example, in GridGain with its pluggable SPI architecture, implementation of event storage is just an implementation of event interface. By default, GridGain will use in-memory storage for all events which will keep in memory only last N number of events and automatically discard the old ones. But user is free to provide a different implementation. For example, it is fairly trivial to provide a DB/SQL based event storage implementation which could selectively store certain events in database and ignore all other ones. It could event throttle events and store them in one batch database operation.

Here is the method that allows you query events in GridGain:


/**
 * @param filter Implementation of GridEventFilter which is 
 *    a simple filter that either accepts or rejects an event. 
 * @param nodes Collection of grid nodes to send the query to.
 * @param timeout Timeout in milliseconds to wait for results.
 */
Collection<GridEvent> Grid.queryEvents(
    GridEventFilter filter, 
    Collection<GridNode> nodes, 
    long timeout
);

So the filter will be sent to the specified remote nodes and as a result you will get a collection of accepted grid events from all the queried nodes.

However, the coolest thing here is that, with GridGain Peer Class Loading, remote nodes can be bare-bone GridGain nodes that have absolutely no knowledge of your event filter class. As a matter of fact, you can simply startup several stand alone grid nodes by executing a startup script, then execute any grid task directly from your IDE and then query for events. All task execution code and event querying code (including the filter you just created) will be automatically deployed to the remote grid nodes.

The above approach allows GridGain to be very productive in development and yet remain very effective in production.

Controlling Users In Grid Environments

2009-01-30T00:45:00.001-08:00

When executing tasks and jobs on the grid you may be faced with the question: "How do I make sure that tasks from other users are not executed on nodes started by me?" For example, what if you have several grid/cloud nodes used by everyone and a couple of private grid/cloud nodes started by you and you want to make sure that other users don't get to use your private grid nodes.

Here is how this problems solved with GridGain. Let me firstly note that we are not solving any security issues here, but simply trying to facilitate proper usage of resources within a trusted environment.

Now, let's state the problem:

Lets assume that we have grid users Tom and Jim. Let's also assume the following grid topology:
Nodes NodeP1 and NodeP2 are public and can be used by everyone.
Node NodeT1 and NodeT2 are private nodes that should only be used for tasks executed by Tom. Tom can start execution of his tasks from any of these nodes.
Node NodeJ1 and NodeJ2 are private nodes that should only be used for tasks executed by Jim. Jim can start execution of his tasks from any of these nodes.

So the problem at hand is how does Tim ensure that his tasks run on his private nodes and public nodes, but do not run on Jim's private nodes?

In GridGain this is solved purely by configuration without touching user's code. Let's assume that Tom's user name is 'tom' and Jim's user name is 'jim'. Let's also assume that public nodes are started from account 'publicuser'.In GridGain all system properties are available on every node as attributes. Since user name is available in Java as system property 'user.name', we can get it as follows:


GridNode localNode = GridFactory.getGrid().getLocalNode();

String userName = localNode.getAttribute("user.name");

We need to ensure that tasks started by Tom are only executed on public nodes and Tom's private nodes. For this we have to configure GridNodeFilterTopologySpi to only include required nodes. GridGain comes with a special node filter, GridJexlNodeFilter, based on Apache JEXL, which allows us to specify node inclusion rules in one-liner JEXL expression:


<bean id="grid.custom.cfg" 
 class="org.gridgain.grid.GridConfigurationAdapter" 
 singleton="true">
 ...
 
  <bean 
   class="org.gridgain.grid.spi.topology.nodefilter.GridNodeFilterTopologySpi">
   
    
     
      
       <![CDATA[
        node.attributes['user.name'] == 'tom' ||
        node.attributes['user.name'] == 'publicuser'
       ]]>
      
     
    
   
  </bean>
 
 ...
</bean>

Consequently, JEXL expression for Jim would look like follows:


...

 
  
   <![CDATA[
    node.attributes['user.name'] == 'jim' ||
    node.attributes['user.name'] == 'publicuser'
   ]]>
  
 

...

The above configuration ensures that Tom's tasks will never run on Jim's nodes and vice versa. Now all we have to do is to bring up the all the nodes from proper user accounts and we are good to go.

I invite you to download GridGain and try it for yourself. Of watch a set of online demos here.

Cloud Cafe PodCast - GridGain A Grid in a Cloud

2009-01-05T23:42:00.000-08:00

John Willis has an interesting blog where he has done many very interesting podcasts about cloud computing. Recently he has done a podcast on "GridGain - A Grid In a Cloud" where he interviewed Nikita Ivanov about GridGain and how it can help with development of Cloud Applications. What I found really interesting is the concept of "Native Cloud Application" which can be built on top of GridGain. With more and more products moving their infrastructure onto clouds, it is becoming critical that application can reuse native cloud services with minimal changes in configuration - and GridGain with SPI-based Architecture fits right in.

You can listen to the podcast here.

Join Multiple App Servers with GridGain

2008-12-10T17:25:00.000-08:00

As some of you may know, integration is one of the strongest points of GridGain. GridGain can natively run on JBoss, WebSphere, WebLogic, TomCat, etc... By natively I mean that GridGain fully reuses all the underneath plumbing of an application server and practically becomes a part of it. For example, if you take integration with JBoss, then you get the following:

GridGain starts as JBoss service, the same way as any other native component of JBoss.
GridGain reuses JBoss Communication and Discovery protocols if JBoss is run in HA clustered mode. This means that you don't have to open a single extra network port or introduce any additional network protocols. Whatever JBoss is using - GridGain will also use it.
GridGain reuses standard JBoss EE deployment model and in addition allows you to dynamically load resources with GridGain Peer Class Loading.
With its Affinity Load Balancing GridGain allows to partition data stored in JBoss Cache across multiple grid nodes, so you can actually load much more data into cache and scale it much better (the feature JBoss cache does not provide on its own).
GridGain lets you reuse JBoss AOP for transparent grid-enabling of your code with @Gridify annotation.

The same level of integration you can expect for other application servers and network protocols.

However, recently one of our clients raised a good question - what if you have both, JBoss and WebSphere. Can they be part of the same cluster? Well, if you simply have JBoss use its HA clustering protocol and WebSphere use its own, then you will never create a cluster out of the two. However, you can start JBoss and WebSphere in unclustered modes and have GridGain take care of all the clustering needs. Basically by doing this, you can have JBoss nodes know everything about WAS nodes and easily send computational task from one to another. What's even better, is that with GridGain Peer Class Loading you can have your WAS server automatically load all the classes deployed into JBoss (and vise versa) without any explicit deployment steps.

I should however mention that Peer Class Loading does not apply to resources managed by the container, such as EJBs - if you have an EJB deployed in JBoss, this EJB is fully managed by JBoss and will be absolutely useless to WAS server. However, you can easily execute some computation task from any App Server (even from your EJB) and have this task distributed to all JBoss and WAS servers in your cluster.

Stay tuned for GridGain 2.1 release coming out any day now!