前言

Couchbase Server是一款开源、分布式的NoSQL文档型数据库。它提供的快速KV存储使用缓存管理可以应对亚毫秒级别的数据操作；专门设计的索引器可以支持快速查询；更包含可以执行类SQL查询的查询引擎。
Couchbas在国内比较小众，因此中文资料也少得可怜，为了能让国内开发者在自己环境用好Couchbase，专门翻译了《Couchbase - Environment Configuration Best Practices》这份资料，原作者Alex Ma, Justin Machiel, Asif Kazi，为Couchbase原厂资深开发工程师。

下文概述了部署Couchbase的基础架构配置的最佳实践，我们将在后续《参数调优》、《监控指标》文章中给出更多的配置细节，请积极关注：
 
为了让Couchbase集群获得最优性能，需要确保集群大小的正确分配，不能仅满足当前的工作负载，还要考虑维护、业务增长趋势和高峰负载。一般来说，推荐给集群预留一定的净上空间来适应容量上的异常毛刺和集群中的硬件故障。

系统、硬件

1. 裸机(bare metal)安装总能获得最佳性能。虚拟化会增加开销，减少各方面的整体资源效率，如操作系统、磁盘I/O、网络性能、CPU。
2. 永远使用本地磁盘存储（节点间无共享架构）。使用SAN不光会导致单点故障，还会导致资源竞争。
3. 如果你必须使用虚拟化架构，你仍然可以用专用的本地存储替代逻辑虚拟化磁盘来提高性能。

系统级

1. 生产上只使用64位操作系统。
2. Linux上部署，其内核版本应该大于2.6.32-504.12.2来避免已知的内核缺陷。
3. 在这里查看支持平台所有列表。

内存

1. 最少保留10%的系统内存用于内核进程和页面缓存。其余内存应分配给Bucket和Index quotas。
2. 在BIOS中禁止非一致性内存访问(NUMA)。

磁盘、卷设计

1. 一切顺利的话，SSD要优于机械盘，更优于网络块设备（iSCSI或EBS）。注意的是NFS不支持。
2. 从性能角度来看，等价容量前提下（RAID 0 或 RAID 10 而不是 RAID 5），多并行设备要优于单块硬盘，例如 4块256GB SSDs要比单个1TB的SSD磁盘快，就因为并行I/O通道变多了。
3. 为了性能，要给每个索引和数据配置独立的磁盘卷来隔离I/O。更快的磁盘应该给索引。

CPU

1. 最小4核
2. 每10,000 ops/s吞吐量一个bucket对应 +1 核
3. 每个视图文档或者GSI索引对应 +1 核
4. 每个XDCR流对应 +1 核
5. 调优索引节点上的IRQ affinity来减少IRQ竞争。Linux上有个脚本可以自动完成该操作。

网络

1. Couchbase只会使用一个网络接口。如果多个接口可用，需要进行接口绑定。
2. 在相同VLAN内部署Couchbase节点。
3. 消除集群节点间的路由跨界(router hops)
4. 消除客户端和集群间的路由跨界(router hops)

Couchbase

1. 生产环境中Data，Index和Query服务应该部署在不同的服务器上。最低限度，Data和Index应该隔离在不同的卷上来防止资源竞争。
2. 配置数据的Bucket尽可能少，推荐上限是一个集群5个buckets。
3. 分配所有可用的集群quota内存给buckets和索引。如果需要，可用减少Bucket quota分配来容纳额外的buckets。
4. 在Couchbase指导下在Bucket上使用Value Eviction。
5. 确保所有buckets上的Flush被禁用。
6. 启用内置的告警功能，配置发送到监控中。
7. 启用auto-failover，设置120秒超时时间。一旦网络稳定性确定了，这个值还可以再减少。
8. 如果发现IO竞争。在非高峰时间窗口进行压缩。
9. 确保部署视图后生产环境上的开发设计文档被移除。
10. 生产环境中删除默认的bucket。

虚拟化环境的考虑

查看http://support.couchbase.com/entries/26790124-Virtualization-Considerations