Terracotta Discussion Forums

I see Terracotta positioned for scalability and for "fault tolerance", and that's the area of interest for me at the moment. What I'm wondering is if the fault tolerance is referring strictly to a cluster model, or if there is something more that's not immediately obvious.

I view clustering as a load balancing approach, which certainly has value, but is not something that I imagine being spread between a primary data center and remote disaster recovery site.

Would or could terracotta be used in a fail-over mode between geographically dispersed systems?

Current version of Terracotta products enable machines in a cluster to fail-over by making sure that the state in the failed machine is not lost. With the current products, if the machines are across a WAN the performance of the cluster will be greatly reduced.

We hope to have a solution that will allow you to cluster across a WAN sometime in 2007.

Arvind
Field Engineer
Terracotta, Inc.

I'm looking forward to implement Tarracotta sessions over two clusters located in different locations. Each cluster has 3 nodes, seperate hardware load balancers, and the clusters are connected with a seperate T1 connection directly with each other. The latency beween a node of a cluster with another node of the other cluster is (average) 13ms.

So, what do you think about this scenario? How will Tarracotta Sessions perform in terms of Fail-Over of a single node? Will the performance be accaptable?

Thanks in advance...

mozammel8435,

Before I answer your question it would help if I understand where you expect to share state.

So, based on your description, I see that you have the following:

Cluster 1 in Data Center 1
- Load Balancer
- 3 nodes

Cluster 2 in Data Center 2
- Load Balancer
- 3 nodes

My questions thus are:

1) how do you balance between data center 1 and data center 2 load balancers? Are they A/P or A/A balanced?
2) After picking a load balancer (via the load balancing scheme in Q1), do your users return to the same load balancer? (I presume if yes, that the user will also return to the same node using sticky sessions - if no please explain)
3) Where do you expect to share state? For example, would the 3 nodes in Data Center 1 share state with each other, but not the three nodes in Data Center 2? Or is it critical that if DC 1 is lost, users are able to transparently fail over to DC2 with no loss of session state?

It's most critical for me to understand point 3 - in other words is all of the state shared all of the time - or is it possible to divide the state into two distinct sets that correspond to each of your 2 clusters of 3 nodes?

In the first case, shared state all of the time, the architecture (and hence failover characteristics) for Terracotta is different than in the second case, where the state can be subdivided.

Thanks,

Taylor

HI Taylor,

1) how do you balance between data center 1 and data center 2 load balancers? Are they A/P or A/A balanced?

We currently don't load balance between our two clusters. Currently we have one Primary Site, and other Secondary Site. The Primary Site is taking all the loads. But in case of the failure of Primary Site, the requests are being forwarded to the Secondary Site. Both primary and scendary sites have seperate load balancers within their clustered nodes.

2) After picking a load balancer (via the load balancing scheme in Q1), do your users return to the same load balancer? (I presume if yes, that the user will also return to the same node using sticky sessions - if no please explain)

Yes, they return to the same load balancer, but not necessarily to the same node. So, currently we don't use sticky sessions. Our users may go to any node within one cluster. That's one of the reason we are looking forward to implement Terracutta Sessions.

3) Where do you expect to share state? For example, would the 3 nodes in Data Center 1 share state with each other, but not the three nodes in Data Center 2? Or is it critical that if DC 1 is lost, users are able to transparently fail over to DC2 with no loss of session state?

We want the users to be able to transparently fail over to DC2 (Secondary Site), in case a failure of DC1 (Primary Site). We also want transparent fail over handling within nodes of a single session.

Please note that Primary Site, and Secondary Site are connected with each other using a seperate T1 connection.

For your convenience, I'm attaching a sample diagram of the configuration: