大雑把な意訳、訳しにくい箇所は英文のまま転載します。
http://basho.com/why-your-riak-cluster-should-have-at-least-five-nodes/
Overview - TODO:後で読むかも
April 26, 2012
Here at Basho we want to make sure that your Riak implementations are set up from the beginning to succeed. While you can use the Riak Fast Track to quickly set up a 3-node dev/test environment, we recommend that all production deployments use a minimum of 5 nodes, ensuring you benefit from the architectural principles that underpin Riak’s availability, fault-tolerance and scaling properties.
TL;DR: Deployments of five nodes or greater will provide a foundation for the best performance and growth as the cluster expands. Since Riak scales linearly with the addition of more nodes, users find improved performance, reliability, and throughput with larger clusters. Smaller deployments can compromise the fault-tolerance of the system: with a “sane” replication requirement for availability (we default to three copies), node failures in smaller clusters mean that replication requirements may not be met. This can result in degraded performance and risk of data loss. Additionally, clusters smaller than five nodes mean that with a sane replication requirement of 3, a high percentage (75-100% of the nodes) will need to respond to each request, putting undue load on the cluster that may degrade performance.
Let’s take a closer look in the scenario of a three- and four-node cluster.
Performance and Fault Tolerance Concerns in a 3-Node Cluster
Cluster が read/write リクエストに常にレスポンスできることを保証するために、Basho はデータのレプリケーションが、異なる 3 台のノードにコピーが作成されるように設定されたデフォルト設定を推奨します。Riak のデフォルト設定は、データのレプリカを単一ノードがひとつより多く持たないことを保証するために、少なくても 4 台の物理ノードを要求します。Riak の今後のバージョンでは、各レプリカは個別の物理ノードに保存されることを保証することができるでしょう。これは、ほとんど 100% 実装されますが、私達はその状態になるまではあなたに保証されるとは伝えないでしょう。3 個のレプリカが 3 台の物理ノードに保存することを保証する設定はできますが、ノード障害が発生した場合やネットワーク分断した場合にレプリカを配置する問題が発生するでしょう。
ノード障害あるいはネットワーク分断が 3 台の物理ノードで構成される Cluster で発生した場合でも、レプリケーションのための要求数は 3 のままです。しかし、サービスのリクエストのために利用できる物理ノードは 2 台しかありません。これはパフォーマンス劣化とデータロストのリスクをもたらします。
Performance and Fault Tolerance Concerns in a 4-Node Cluster
4 台の物理ノードで構成される Cluster で 3 個のレプリカを必要とする場合、あるデータに対するひとつのリクエストは、Cluster 内の 75-100% の物理ノードが応答する必要があるでしょう。これはパフォーマンス劣化を引き起こすかもしれません。ノード障害あるいはネットワーク分断が 4 台の物理ノードで構成される Cluster で発生した場合でも、さきほど記載した問題に戻ります。
What if I want to change the replication default?
もし、あなたの要件のためにデータのレプリカ数を変更する場合は、N をレプリカ数とすると N+2 台の物理ノードで Cluster を構成するようにしてください。
Going With 5 Nodes
5 台の物理ノードで構成される Cluster に新しい物理ノードを加えるとともに、サービスの各リクエストのために必要とされる Cluster 内の物理ノードの割合は下がります。Riak は、この点から予想されるように比例して変化します。物理ノードをサービスアウトあるいは障害が発生しても、残りの物理ノード台数はあなたをデータロストから保護することができるほど十分に多いです。したがって、あなたの開発およびテストは小さな Cluster で行なっても、本稼働時には 5 台の物理ノードではじめてください。
コメント
重要そうな部分だけ意訳してみた。
少し付け加えると、現時点での Riak doc (version-1.3.2) の Replication に「So what does N=3 really mean」と記載されている。内容を大雑把に意訳すると次のようになる。
N=3 はデータが Cluster 内の 3 カ所に格納されることを意味します。従って、3 つの異なるパーティションがデータのコピーを受けます。また 3 つのレプリカは 3 つの異なる物理ノードに格納されるという保証はできません。しかし、レプリカを均等に分散しようとする組み込み関数があります。
そのため、今回の "Why Your Riak Cluster Should Have At Least Five Nodes" は少し古い記事だけど、この内容は現在でも変わっていないと思われる。実際に 3 台の物理ノードで構成される Cluster に対しある程度のデータを書込みした後いくつかのノードを落として pr=all で fetch すると、データのレプリカが同じ物理ノードに複数個格納されている状況を確認できる。また、現時点での Riak doc (version-1.3.2) の Configuration File に「target_n_val」と記載されている。内容を大雑把に意訳すると次のようになる。
"target_n_val" は、あなたが使う予定である最も大きい n_val です。これは cluster 中のパーティションをどのように分散するか、そしてどのように preflists を計算するかに影響を及ぼします。データが同じ物理ノードに一度より多く格納されないことを確実にするのを助けます。稀な状況で設定を変える必要があるでしょう。
"ring_creation_size" が 2 の累乗であると仮定すると、この設定の理想的な設定値は、あらゆる bucket で最も大きい v_val より大きいか等しく、そして "ring_creation_size" を偶数にする除数です。"target_n_val" の初期値は 4 です。ホットスポットを効率的に防ぐために、あなたの cluster の物理ノード数は "target_n_val" より大きいか等しい必要があります。
ここからも、3 個のレプリカを必要とする場合は、これらの条件を満たすには少なくても 4 台の物理ノードが必要となることが分かる。実際に 4 台の物理ノードで構成した Cluster に対して、さきほどと同じ方法で確認してみたところ、正常に別々の物理サーバにレプリカが保存されていることが確認できた。ノード障害やネットワーク分断にも備え、パフォーマンス劣化させないことを考慮すると最低でも 5 台の物理ノードではじめるのが最も良いことが分かった。
間違っていたら指摘してください。Happy scaling !!