Laurent is a software engineer with over 20 years of experience in software development, design and architecture. He has a Masters in Computer Science, obtained at EFREI in Paris, France. Laurent is the founder of JPPF, the open source grid computing solution, and created the French startup Parallel Matters, which provides commercial services around JPPF. Laurent has posted 28 posts at DZone. View Full User Profile

Master/worker or P2P Grid? How about You choose?

02.04.2012
| 2990 views |
  • submit to reddit

What is possible?

Simple master/worker topology

In its initial design, JPPF is a distributed parallel processing framework based on a master/worker architecture. A JPPF grid is made of 3 sorts of components that communicate with each other: clients which submit the work to the grid, nodes which execute the work, and servers which receive the work from clients and distribute it to the nodes in parallel. This gives us a grid topology like this:

An important point to note is that each node can only be attached to a single server at any given time. It doesn't have to always be the same server. For instance, if the connection to the server is broken, some failover mechanisms, whether built-in or user-defined, will allow the node to connect to another server.

Let's get more complex

A further addition to this design enables servers to communicate with each other, allowing a server to offload some of its work to other servers. The current implementation allows users to configure a server so that it can be seen as a node by other servers, and these other servers will be seen as clients. If you define that relationship both ways, you have the possiblity to define much more complex topologies for your JPPF grid:

Here we see that servers can be connected to each other in a P2P topology, but also in one-way fashion, which opens up a bunch of possibilities.

Local nodes

Another possibility in JPPF is the ability to have a node local to the server's JVM. This local node is exactly the same as a remote node, except that it is always connected to the same server, and the communication with the server is done directly in memory instead of via a network connection. This allows for a much faster communication between the local node and the server, however this communication boost is only available to the local node. In a simple topology, it would look like this:

Note that both a local node and remote nodes can be attached to the same server.

Pure P2P

Now, if we only attach a local node to each server, and configure all servers to communicate with each other in full duplex, we achieve a pure P2P topology for the grid:

How is it done?

All the topologies we have seen above are achieved by configuring the JPPF servers accordingly. We will see here how to configure a pure P2P grid. In the simplest case, where all components are on the same network, and when there are no restrictions on UDP multicasting, all you have to do is the following:

  • enable each server to broadcast its connection information: this is enabled by default
  • enable each server to receive broadcasts from other servers (disabled by default)
  • activate a local node in each server (disabled by default)

Concretely, this translates into setting the following properties in the server's configuration file:

 

# enable the broadcast of connection information
jppf.discovery.enabled = true

# enable auto-discovery for peer-to-peer communication between servers
jppf.peer.discovery.enabled = true

# activate the local node
jppf.local.node.enabled = true

In more complex network environments, you may not be able to rely on UDP multicast for broadcasting. This would happen if some of the servers are on different networks, or if the servers are running within a cloud environment such as Amazon's EC2. In this case you might have to perform a manual configuration of the peer servers to connect to. We won't detail it here, however it is fully documented in our server configuration guide.

Conclusion

We have seen that a JPPF grid is not limited to a master/worker architecture. A lot of flexibility is offered by the framework, which results in complete freedom for the users to chose the topology that works best for them, be it simple, complex, P2P-based, or anything in between. Even better, this can be achieved with simple configuration changes.
Published at DZone with permission of its author, Laurent Cohen.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)