The document discusses scaling limitations of containerized applications and proposes using a data grid approach with eventual consistency to address these limitations. It describes how current replication approaches do not scale well due to high memory and network usage from fully replicating data across all nodes. A data grid partitions data across nodes and allows asynchronous, eventually consistent replication to improve scalability and performance at the cost of strict consistency. The data grid model is better suited for high availability applications with uncontrolled loads that require high availability over consistency.

1. Container Independent Failover Framework Mobicents 2011 Summit

3. Current Scaling Limitations Mobicents 2011 Summit

8. DataGrids and Eventual Consistency Mobicents 2011 Summit

10. Drop Network Partition

11. Drop Availability Network Partition Failure : All affected nodes wait until the partition is whole again before replying, thus loss of availability

12. Drop Consistency Network Partition Failure : Consistency is Broken

15. Peer to Peer Mode with DIST with L1 Cache The application container or the apps will need to access sessions, dialogs and other objects in the distributed store. Each container will maintain a quick-lookup local cache of deserialized objects. In Sip Servlets that is implemented for sessions. If that fails (the session needed by the app is not in the local cache), then the container will look it up in infinispan. Each infinispan instance has a data store with items hashed to the specific node (DIST-assigned serialized data). This is where the majority of the memory is consumed. However the data in this store is randomly distributed based on hash values and is not cached based on LRU or other common caching rule. To help with that infinispan allows enabling L1 cache which will enable LRU policy on commonly accessed items that are missing from the DIST-assigned store.

16. Data Grid HA Model In this model the data is primarily stored in a remote data-grid by partitioning it based on some key value. The communication with the grid is done only via the network with protocols such as hot rod, memcached or thrift. In this model caching deserialized data would be very difficult if concurrent changes are allowed. Protocols for network lookup and transport in grid systems rarely allow delivery of async events to the clients (in this case the Local Node is the client for the grid). So we will never be eagerly notified of some session has changed so that we know if we can use the cached deserialized local copy. L1 cache for serialized chunks however may have a function to check if the data is up to date which still requires at least one network request by itself even without locking the data. Each grid protocol supports different operations and features that can be used to optimize the network access and support cache more efficiently. Local cache invalidation is more difficult in this model as it is not guaranteed that the HA grid architecture allows notifications to keep the caches up to date with any remote changes.

17. Thank you ! http://telestax.com/