How DSO Clustering Works
Under the hood, Terracotta DSO is designed to minimize network chatter, guarantee data coherence, and provide maximum operator control, all while providing 100% high availability with no single points of failure.
Deployment Architecture
The Terracotta deployment architecture has two primary components, client nodes and the Terracotta Server Array.
Client JVMs. Your application servers or standalone Java application JVMs are connected to a Terracotta cluster using a Terracotta client driver. The Terracotta client driver is a JAR library that runs on standard Java Virtual Machines and is loaded when your application starts up.
Server Array. The Terracotta Server Array provides fault-tolerant clustering intelligence and a high performance facility for centralized locking and persistence to disk.
Each Terracotta Server Instance in the array is a 100% pure Java process. The array can run in an active/hot-standby configuration for high availability that can achieve tens of thousands of requests per second. If even more capacity is required, active servers can be added as needed to stripe and mirror your Network Attached Memory across an n-way server array.
Terracotta Platform Architecture
JVM-Level Clustering
Terracotta manages mission critical data using Network-Attached Memory (NAM) technology. NAM enables Terracotta to cluster Java Virtual Machines (JVMs) directly underneath applications, and is a proven runtime approach to providing Java applications both high availability and scalability.
Terracotta's Network-Attached Memory looks just like local heap to a Java application. Sharing select parts of this virtual heap allows NAM to act as JVM-level clustering. This creates, from the view of the Java application, one super JVM from a federated set of many individual JVMs.
With NAM, applications running with Terracotta can readily expand to run on any number of computers. In most cases, there is no need to develop a data partitioning scheme upfront to reach high levels of application scale.
Developers or operators define which parts of memory should be shared and which parts are not. This selective sharing assures that NAM shares data in an efficient manner. Also, as shown in the diagram here, Terracotta can identify and propogate fine-grained changes to objects in NAM. Only the changes are shared, and they're only shared where the changed objects are referenced. This precision ensures efficient use of network resources, and is the basis of Terracotta's high performance.
Should one of the clustered JVMs running an application fail, the application itself won't skip a beat. Terracotta will ensure that another available JVM receives the data from the failed JVM's memory to keep the application workflow moving, or to service an ongoing user request. As new application JVMs join a cluster, Terracotta will ensure that they seamlessly join the cluster, immediately contribute to completing the application workload, and stand ready to take failover workload in the event another machine fails.
Coherent Object Changes
With Terracotta, a change in one JVM can be instantaneously reflected throughout the cluster to other JVMs that need to know about the change. Only the field-level changes are sent over the network, and they are sent only to the JVMs whose context implies they "need to know" about the change. Object identity is preserved throughout the cluster as well, so there is no need to compare versions of objects when making a change.
How does Terracotta do this? Terracotta uses the constructor to hook into objects and guarantee cluster-wide object identity. Concurrency is used to batch and order these changes to minimize network traffic and yield maximum application performance.
Clustering Reduced to Tuning
Terracotta is always coherent, meaning there is a consistent view of data across the cluster. It also provides in-memory performance with the security of persistence to disk. Terracotta is also always pure Java, so your favorite development constructs, like java.*, synchronized, and util.concurrent will scale out to a cluster-wide context when needed.
Most code changes that users make when deploying Terracotta are for tuning, not for clustering. Terracotta includes a management console with visualization features to identify good opportunities for lock and performance tuning.