データの安全性を保障するためにはデータの安全性要件を満たすためにクラスタ内に十分なノード数が必要です。クラスタ内の適切なノード数の保持に加え、適切なノード設定も必要です。ノード間での情報の分散と、クラスタ内で保存される情報のレプリカ数という2つの考慮すべき側面があります。
基本的な考えはより多くのノードが少ないノードより優れているということです。もし2つのノードだけなら、半分ずつ分散されます。これは1つのノードが消滅した場合に、データセットの半分が "影響"を受けることを意味します。一方で、10ノードの場合、データセットの10%のみが"影響"を受けることになります。自動フェイルオーバを利用したとしても、ノード障害が発生した場合、データが利用できない期間が発生します。これはノード数を増やすことで軽減することができます。
フェイルオーバ後にクラスタが必要とする負荷についても考慮する必要があります。2ノードだけの場合、それぞれのノードで全ての負荷を処理する準備ができている必要があります。10ノードでは、1台のノードが故障した場合、全ワークロードの10分の1を余計に処理できるようにすることが必要です。
2つのノードは最低限のデータ冗長化レベルを提供しますが、常に少なくとも3ノードを利用することをお勧めします。
Couchbase Serverではレプリカ数を3つまで設定できます（データセットのコピーを4つ生成します）。障害が発生した場合、レプリカを持つノードが十分にある場合のみ（手動あるいは自動）"フェイルオーバ"することができます。 例：
5ノードでレプリカ数1のクラスタのうち、1ノードがダウンした場合はフェイルオーバ可能です。2つノードがダウンしてしまうと、フェイルオーバするために十分なレプリカが無くなり、リカバリするには時間のかかるプロセスが必要になります。
5ノードでレプリカ数2のクラスタのうち、1ノードがダウンした場合、フェイルオーバ可能です。2つノードがダウンしても、フェイルオーバできます。3つノードがダウンしてしまうと、フェイルオーバ用のレプリカがなくなってしまいます。
ノードがダウンし、フェールオーバーされた後は、できるだけ早くそのノードを交換してリバランスしてください。リバランスはレプリカコピーを再作成します（十分な数のノードがある場合）。
目安として、以下の設定を推奨します：
5ノードまではレプリカ数1
5から10ノードはレプリカ数1または2
10ノードより大きなクラスタではレプリカ数1、2あるいは3
これには多くのバリエーションがありますが、小規模のクラスタ内で多くのレプリカを持ってもそれほど効果がありません。
一般的にCouchbase Serverのハードウェア要件は非常に低く、コモディティハードウェア、あるいは仮想化システム上で動作するように設計されています。とはいえ、サーバーの主な考慮事項のおおよその目安として：
RAM: アクティブなアイテムを保持し、Couchbase Serverが低いレイテンシを持つ主な理由であるため、最も重要です。
CPU: Couchbase ServerのCPU要件は非常に低いものです。サーバはマルチスレッドであるためマルチコアシステムの恩恵を受けます。少なくとも4つまたは8つの物理コアを搭載したマシンを推奨します。
ディクス: RAMをIO層から切り離すことで、Couchbase Serverは他のデータベースに比べ、低速なディスクであっても効率的に扱うことができます。SAN、SAS、SATA、SSDおよびEBSで動作が確認され、次の構成が推奨されます：
SSDは書き込みキューを処理する点でも、データをリストアする点（コールドブート及びリバランシング用途）でも優れた性能を発揮することができます。
RAIDは、一般的にスループットの向上と信頼性を提供します。
（Amazon EC2の）EBSボリュームでストライピングすると、スループットを高めることができます。
ネットワーク: ほとんどの構成でギガビットイーサネットインターフェイスで動作します。10GBitやInfinibandのようにさらに高速なソリューションを利用することもできます。
クラウド環境においては、信頼性や一貫したIO性能が欠如していおり、ノード単位のRAMフットプリントを削減し、ノード数を増やすことをお勧めしています。これによりより良いディスクスループットに加え、各ノードが保持するデータが（そして転送するデータも）少なくなるため、リバランスも容易になります。さらにデータを分散することで、単一のノードが故障した際（一般に良く起こりえます）に受ける影響も軽減することができます。
ベストプラクティスも御覧ください「クラウドでのCouchbaseの利用」.