Child pages
  • How DSO Clustering Works

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
Include Page
{div:style=} {include:
Wiki Markup
Include Page
} {div}
{div9:id=documentationcolumn} {include:HeaderBasic} {include:dsoCaveat_include} {html}
Wiki Markup
Include Page
Include Page


		      <div class="product-main-column">
			<h1>How DSO Clustering Works</h1>
			<p>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.</p>

			<h2>Deployment Architecture</h2>

			<p>The Terracotta deployment architecture has two
			   primary components, client nodes and the Terracotta
			   Server Array.</p>
			<p><strong>Client JVMs.</strong> 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.</p>

			<p><strong>Server Array.</strong> The Terracotta Server
			   Array provides fault-tolerant clustering
			   intelligence and a high performance facility for
			   centralized locking and persistence to disk.</p>

			<p>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.</p>

			  <img src="/img/platform/arch.png" alt="Terracotta Platform Architecture"/><br/>
			  <strong>Terracotta Platform Architecture</strong>
			<h2>JVM-Level Clustering</h2>
			<p>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
			<p>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.</p>

			<p>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.</p>

			<p>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.</p>

			<p>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.</p>

			<h2>Coherent Object Changes</h2>
			<p>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.</p>

			<p>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

			<h2>Clustering Reduced to Tuning</h2>
			<p>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.</p>

			<p>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.</p>

{html} {div9}