Tuning replication N, R/W quorums, cluster planning

[adr...@gmail.com]

Hello,

I'm interested in scalaris' transactions. I've questions about data access patterns and cluster design:

1)How do I tune the replication factor (N) ? Can I have several Ns according to data importance ? say N1=1 for very transient keys (some minutes lifetime) and N2=4 for "data lost is business lost" keys ?

2)How do I set Read and Write quorums ? say quick'n'dirty read R=1 and dumb paranoia write W=N ? Is it per request, per dataset, per whatelse ?

3)What are the guidelines (or testimonies) about cluster planning: number of active nodes, failure frequency, spare nodes, repair ops, scale up ops (and rebalancing), numbers about datasize & speed?

Best

Pierre M.

[Florian Schintke]

Hi,

> Hello,
>
> I'm interested in scalaris' transactions. I've questions about data access
> patterns and cluster design:
>
> 1)How do I tune the replication factor (N) ? Can I have several Ns
> according to data importance ? say N1=1 for very transient keys (some
> minutes lifetime) and N2=4 for "data lost is business lost" keys ?

currently, it is fixed.

> 2)How do I set Read and Write quorums ? say quick'n'dirty read R=1 and dumb
> paranoia write W=N ? Is it per request, per dataset, per whatelse ?

currently, they are fixed to have equal sizes

> 3)What are the guidelines (or testimonies) about cluster planning: number
> of active nodes, failure frequency, spare nodes, repair ops, scale up ops
> (and rebalancing), numbers about datasize & speed?

to remain operational, a quorum of each replication group has to be
on-line. A system with less than 4 nodes does not make sense.

We successfully ran Scalaris on PlanetLab, a testing environment
spread world-wide with unforeseable system crashes and joins with
about 100 distributed nodes. So, Scalaris seems to be quite robust
against individual system failures. If you have correlated node
failures, you may want to take care of where to place the replicas.

Florian