The Terracotta Deployment Architecture

The Terracotta architecture 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.

The Terracotta deployment architecture has two primary components, client nodes and the Terracotta Server Array.

Client Nodes

Each client node corresponds to a Java process in the cluster, for example an application server. The client nodes run on standard Java Virtual Machines. Terracotta is loaded in to the JVM by Terracotta JAR libraries that are loaded at JVM startup.

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

Changes In One JVM Are Visible In Others

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.

JVM Level Clustering

Terracotta's NAM 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.

Sounds like Magic...

But it's not. It's solid software engineering that has built durable, transactional, clustered shared memory that an significant number of organizations have adopted to make their mission-critical applications more scalable with fewer performance and reliability trade-offs and, more importantly, with cost benefits that far outweigh competing solutions.

Terracotta Reduces Clustering 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.

Is Terracotta Right For Me?

The next section helps you identify common use cases for Terracotta, illustrates where and how other people are using Terracotta successfully, provides reference applications and clustered design patterns, and more.