Standalone and Federated Deployment with OpenSplice
Posted in TechBlog on December 07, 2011 by Angelo Corsaro
With OpenSplice v6 we have introduced several different new features but there is one in particular that I've been wanting to cover for some time. Tonight, once dinner was over (very good vegetarian variation of the Risotto alla Milanese which I cooked myself) and kids were in bed I was about to begin my evening Yoga when I had this funny feeling -- had I become a Fimble? Not as far as I could tell, but at the same time I felt that before devoting myself to Yoga I had to write about this one thing.
So what is it?
With OpenSplice v6 we have introduced support for multiple deployment models. This enable users to run an application in what we call the standalone or federated deployment model. The main difference between the two boils down to how OpenSplice is "instantiated". On the standalone model OpenSplice is simply a library while on the federated model it is a set of daemons shared by all applications running on the same node.
Let's try to understand now what are the key characteristics of these dual deployment model.
As mentioned before and as you can see from picture right above the key landmark of this deployment model is a single OpenSplice DDS instance shared across all the applications running on the same mode. In a sense OpenSplice DDS is a Singleton, and this leads to a series of interesting implications.
- Inbound and outbound communication for all applications are mediated by the same OpenSplice DDS instance thus making it very simple and effective to impose node-wide network scheduling. This combined with our real-time networking protocol allows OpenSplice to enforce end-to-end real-time communication.
- Deserialization of samples will happen only once regardless of the number of applications that subscribe to the same topic. This means that if you have a single application subscribing for the topic Foo or you have 1000 applications on the same node subscribing for the topic Foo -- that will not make any difference -- you only have to deserialize each sample only once!
- Inter-core latency for DDS applications running on the same node will be very very low (we've had customer measuring it to be the lowest acros all middleware they had evaluated).
- The life-cycle of data is not tied to the life-cycle of the application. This means that if you have an application having Transient or Persistent data readers, if the application crashes, when restarted will not have to fetch its transient of persistent data from the network as it will find it on the DDS cache that is still running on the node-wide DDS singleton instance. This can really improve the time required to recover from an application failures.
- Data and (most of the) meta-data is shared across multiple applications thus reducing the total memory required by the all the applications running on the system
As with great power comes great responsibility, in this deployment model a lot of responsibility is posed on the OpenSplice singleton instance. Should it fail, the whole node would loose communication capabilities. OpenSplice mitigates this issue by providing a built-in fault-detection and recovery mechanism. Beyond that, properly configuring this deployment option is a bit harder as it requires a more intimate understanding of OpenSplice and of the application at hand.
In summary, the federated deployment option is your best choice when you need extreme scalability, performance and end-to-end determinism.
As you can see from picture above, in the standalone deployment option each application links-in an OpenSplice DDS library. This deployment model does not rely on shared services and there are no daemons running on the node, everything is "bundled-in" with the application. The standalone deployment option is really dual to the federated deployment, and as such it has dual pros and cons.
- The standalone deployment is the simplest to use as it does not require any configuration nor administration in terms of starting and stopping services.
- Smaller inter-node latencies can be achieved with this model as no process boundaries are ever crossed. Thus for applications that are latency sensitive but don't require very high throughput this deployment is advantageous.
- Each application has its own OpenSplice instance, thus a potential middleware failure is confined on the boundaries of an application. On the flip-side many, if not all, of the advantages that came with the federated deployment in terms of data-sharing, demarshalling optimization and so on, are gone.
In brief, federated and standalone deployment are inherently dual -- the pros of one are the cons of the other. There are systems where it makes more sense to use one, and systems where it makes more sense to use the other. The great news is that starting with OpenSplice v6 you can choose the deployment model that best suits you. But that's not all, you can control the deployment model of an application by a runtime configuration parameter!
This means that the same application can be deployed using the federated or standalone model without a single change, relink or re-compilation. Beyond that on the same systems you can mix and match federated and standalone deployments as you will -- obviously that means that you can have the same application deployed on federated and standalone on the same system, or even on the same node.