Real Terracotta

REAL TERRACOTTA
Real-world scalability patterns with Terracotta

SERGIO BOSSA
Pro-Netics / Sourcesense

Sergio Bossa - sergio.bossa@pronetics.it - Pro-Netics / Sourcesense
Javaday Roma III Edizione – 24 gennaio 2009

About Me

Software architect and engineer
✔

http://www.pronetics.it
➔

http://www.sourcesense.com
➔

Blogger
✔

http://sbtourist.blogspot.com
➔

Open Source Enthusiast
✔

➔ Lead at Scarlet - Clustering for Jira

http://scarlet.sf.net
➔

Committer at Spring Modules
➔

http://springmodules.dev.java.net
➔

Committer at Terracotta Forge
➔

http://forge.terracotta.org
➔


Agenda

Do I need a cluster?
✔

Terracotta concepts.
✔

Scalability patterns with Terracotta.
✔


Do I need a cluster?

The old, dummy, question:
✔

➔ Do I need a clustered architecture?

The correct one:
✔

➔ Do I need scalability?

➔ Do I need availability?

➔ Nowadays, the answer is: yes, you need.


Why should I need a cluster?

Several changes in the social and market landscape ...
✔

In a few words:
✔

➔ More and more users surfing the web.

➔ More and more hardware at cheaper price.

➔ More and more processors ... even on a single machine.


What should I use for my cluster?


The Terracotta Revolution


The Terracotta Revolution

Transparent clustering.
✔

➔ Everything happens under the hood.

Easy to work with.
✔

➔ If you know Java, you can cluster your application with

no-to-minimal code changes.
➔ Deep integration with common frameworks and patterns.

Optimized for performance.
✔

➔ No cross-node communication.

➔ Built on the concept of diff.

Open Source.
✔

➔ With a great community.


Terracotta Technology
Overview

Network Attached Memory
✔

➔ All cluster nodes share part of their memory heap: a

shared object graph starting from one or more roots.
➔ Shared objects changes are propagated at the byte

level: only the different bytes get propagated!
➔ Shared objects changes are delimited by lock-guarded

transactions.
➔ Shared objects are backed by the cluster server

filesystem.
➔ With preserved Java semantics (i.e. object identity)!


Overview

Hub-and-Spoke network architecture
✔

➔ A central cluster server with one or more cluster client

nodes.
➔ Clients talk only with the server.

➔ Server can be put in active-passive mode (no SPOF).

➔ For enterprise customers only: server can be put in

active-active mode (no SPOB).


Details

Bytecode instrumentation
✔

➔ Instrument classes in order to:

➔ Share classes among cluster nodes.

➔ Intercept and propagate changes.

➔ Apply transactions.

➔ Distribute method invocations.


Details

Roots
✔

➔ AKA super-static: created only for the first time, and then

shared among all cluster nodes.
➔ Start of the shared object graph: all objects reachable

from roots are shared among all cluster nodes.
➔ Except transient ones.


Details

Locks
✔

➔ Every read or write operation on a shared object state

must be guarded by locks.
➔ Synchronized blocks.

➔ java.util.concurrent.locks.ReentrantReadWriteLock

➔ Acting as a transaction boundary.

➔ Acting as a change propagation boundary.


Details

Distributed Method Invocation
✔

➔ Methods called on a shared object from a cluster node,

are automatically fired on the same object instance of all
other cluster nodes.


Details

Declarative configuration:
✔

➔ XML file.

➔ Java annotations.


Terracotta Quick Start
Plan

Identify roots and related shared object graphs.
✔

Identify transactional methods.
✔

Identify classes that need to be instrumented.
✔

Identify distributed methods (optional).
✔

Choose your cluster deployment configuration:
✔

➔ How many client nodes?

➔ How many server nodes?

➔ How much memory?

➔ ...


Terracotta Quick Start
Operate
Configure the cluster.
✔

Start the Terracotta cluster server:
✔

sh tc_home/bin/start-tc-server.sh -f path/to/tc-conf.xml

Start the Terracotta cluster client(s):
✔

TC_INSTALL_DIR=...

TC_CONFIG_PATH=...

. $TC_INSTALL_DIR/bin/dso-env.sh -q

export JAVA_OPTS=${TC_JAVA_OPTS}

java ...


What about real world scalability?
Feeling like lost at sea?


Scalability in the real world
We need some patterns!

Cache your data in a distributed fashion.
✔

Partition your cached data and collocate with your
✔

processing.

Asynchronously write-behind to your back-end.
✔

Asynchronously de-couple components communication.
✔

Asynchronously de-couple components processing.
✔


Data-affinity caching


In a nutshell
Key concepts:
✔

➔ Use a partition function for grouping related entries on

the same distributed cache instance.
➔ Use the partition function to look up the cache instance

and put/get related entries.
➔ Process the cached data on the same node it belongs

to.

Key features:
✔

➔ No network traffic between cache instances.

➔ Distributed load.

➔ Higher scalability.


With Terracotta

Use:
✔

➔ Tim-Tree-Map-Cache

http://forge.terracotta.org/releases/projects/tim-tree-map-cache/
➔

Key classes:
✔

org.tc.cache.CacheFactory
➔

org.tc.cache.ITerracottaCache
➔


Asynchronous write-behind


In a nutshell

Key concepts:
✔

➔ Always write and read from your (distributed) cache.

➔ Asynchronously schedule writes to the storage.

Key features:
✔

➔ Higher throughput.

➔ Load throttling.


With Terracotta

Use:
✔

➔ Tim-Async

http://forge.terracotta.org/releases/projects/tim-async/
➔

Key classes:
✔

org.terracotta.modules.async.AsyncCoordinator
➔

org.terracotta.modules.async.ItemProcessor
➔


Asynchronous messaging


In a nutshell

Key concepts:
✔

➔ Connects application components through pipes.

➔ Configure processing filters to elaborate messages and

make them flow through pipes.

Key features:
✔

➔ De-coupled application components.

➔ Higher reliability.

➔ Higher scalability.


With Terracotta

Use:
✔

➔ Tim-Pipes

http://forge.terracotta.org/releases/projects/tim-messaging/
➔

Key classes:
✔

org.terracotta.message.topology.TopologyManager
➔

org.terracotta.message.topology.Topology
➔

org.terracotta.message.routing.Router
➔

org.terracotta.message.pipe.Pipe
➔

org.terracotta.message.pipe.PipeProcessor
➔

org.terracotta.message.subscriber.Subscriber
➔

org.terracotta.message.subscriber.SubscriberProcessor
➔


Asynchronous processing


In a nutshell

Key concepts:
✔

➔ Create a set of tasks.

➔ Submit tasks to a master.

➔ Tasks will be executed by workers.

➔ Eventually wait for tasks to be completed.

Key features:
✔

➔ De-coupled execution of expensive tasks.

➔ Parallel execution of tasks.

➔ Customisable routing logic.

➔ Load distribution.


With Terracotta

Use:
✔

➔ Tim-MasterWorker

http://forge.terracotta.org/releases/projects/tim-messaging/
➔

Key classes:
✔

org.terracotta.executor.DistributedExecutorService
➔

org.terracotta.executor.DistributedCompletionService
➔

org.terracotta.workmanager.statik.StaticWorkManager
➔

org.terracotta.workmanager.statik.StaticWorker
➔

org.terracotta.workmanager.dynamic.DynamicWorkManager
➔

org.terracotta.workmanager.dynamic.DynamicWorker
➔


Conclusion
Enjoy scalability challenges!

Design your scalable architecture ...
✔

Program in plain old Java ...
✔

Run with Terracotta!
✔


Q&A


Real Terracotta

Recommended

Recommended

More Related Content

Similar to Real Terracotta

Similar to Real Terracotta (20)

More from Sergio Bossa

More from Sergio Bossa (7)

Recently uploaded

Recently uploaded (20)

Real Terracotta