Couchbase_server_in_production_tokyo_2014

Couchbase Server in Production

Perry Krug

Sr. Solutions Architect

Agenda

• Deploy• Architecture• Deployment Considerations/choices• Setup

• Operate/Maintain• Automatic maintenance• Monitor• Scale• Upgrade• Backup/Restore• Failures

Deploy

Typical Couchbase production environment

Application users

Load Balancer

Application Servers

Couchbase Servers

Couchbase を用いた典型例

Web Application

Couchbase deployment

Cluster Management

Web Application

CouchbaseClient Library

Web Application … …

Couchbase Server Couchbase Server Couchbase Server Couchbase Server

Replication Flow

Data ports

Couchbase のデプロイ

Hardware

• Designed for commodity hardware

• Scale out, not up…more smaller nodes better than less larger ones

• Tested and deployed in EC2

• Physical hardware offers best performance and efficiency

• Certain considerations with using VM’s:­ RAM use inefficient / Disk IO usually not as fast­ Local storage better than shared SAN­ 1 Couchbase VM per physical host­ You will generally need more nodes­ Don’t overcommit

• “Rule-of-thumb” minimums:­ 3 or more nodes­ 4GB+ RAM­ 4+ CPU Cores­ “best” local storage available

使用ハードウェアについて

Amazon/Cloud Considerations

• Use a EIP/hostname instead of IP:

­ Easier connectivity (when using public hostname)­ Easier restoration/better availability

• RAID-10 EBS for better IO

• XDCR:­ Must use hostname when crossing regions­ Utilize Amazon-provided VPN for security

• You will need more nodes in general

Amazon/ クラウドを使用する場合の検討事項

IP のかわりに EIP/hostname を使用する

IO 性能向上のためには RAID-10 EBS を使用

全般的にノードを増やすことがよい結果につながる

Amazon Specifically…

• Disk Choice:

­ Ephemeral is okay­ Single EBS not great, use LVM/RAID­ SSD instances available

• Put views/indexes on ephemeral, main data on EBS or both on SSD

• Backups can use EBS snapshots (or cbbackup)

• Deploy across AZ’s (“zone awareness” coming soon)

ディスクの選択

view/inex には揮発性ディスクを使用、メインデータは、 EBS もしくは SSDを使用

バックアップには、 EBS スナップショット ( あるいは cbbackup) を使用可能

Amazon に特化した設定について

Setup: Server-side

Not many configuration parameters to worry about!

A few best practices to be aware of:

•Use 3 or more nodes and turn on autofailover

•Separate install, data and index paths across devices

•Over-provision RAM and grow into it

多くのパラメータを設定しない

サーバ側のセットアップ

ポイントは三つ

３台以上のノードを使用し、オートフェールオーバ設定を ON

データと index のパスは、異なるデバイスに設定する

RAM 容量には余裕をもたせる

Setup: Client-side• Use the latest client libraries

• Only one client object, accessed by multiple threads

­ Easy to misuse in .NET and Java (use a singleton)­ PHP/Ruby/Python/C have differing methods, same concept

• Configure 2-3 URI’s for client object

­ Not all nodes necessary, 2-3 best practice for HA• Turn on logging – INFO by default

• (Moxi only if necessary, and only client-side)

クライアント側のセットアップ

最新のクライアントライブラリを使用する

複数スレッドでアクセスされるのは、ただ１つのクライアントオブジェクトのみ

（サーバの） URL を 2-3 台分設定する

ロギングを on にする

Operate/Maintain

Automatic Management/Maintenance

• Cache Management

• Compaction

• Index Updates

•Occasionally tune the above

自動マネジメント / メンテナンス

キャッシュマネジメント

コンパクション

Index アップデート

時折、上記項目をチューニング

Cache Management

• Couchbase automatically manages the caching layer

• Low and High watermark set by default

• Docs automatically “ejected” and re-cached

• Monitoring cache miss ratio and resident item ratio is key

• Keep working set below high watermark

キャッシュマネジメント

Couchbase は、自動的にキャッシュ層をマネージする

ロウ・ウォータマークとハイ・ウォータマークはデフォルト設定にドキュメントは自動的に「排出」され、（必要に応じて）再キャッシュされる

キャッシュミス率とアイテム常駐率をモニタリングすることが重要

ハイ・ウォータマークを常に下回る（ようにリソース管理する）ことが重要

View/Index Updates

• Views are kept up-to-date:

­ Every 5 seconds or every 5000 changes­ Upon any stale=false or stale=update_after

• Thresholds can be changed per-design document

­ Group views into design documents by their update frequency

View/Index の更新

View は常に最新化される

閾値はデザインドキュメントごとに変更される

Disk compaction• Compaction happens automatically:

­ Settings for “threshold” of stale data­ Settings for time of day­ Split by data and index files­ Per-bucket or global

• Reduces size of on-disk files – data files AND index files

• Temporarily increased disk I/O

and CPU, but no downtime!

コンパクション コンパクションは自動的に起動

ディスクファイルのサイズを削減 – データファイル＆インデックファイル

コンパクションにより、ディスク I/Oと CPU を圧迫する。しかし、システムダウンはしない！

Disk compactionInitial file layout:

Update some data:

After compaction:

Doc A Doc B Doc C

Doc C Doc B’ Doc A’’

Doc A Doc B Doc A’ Doc B’ Doc A’’Doc A Doc B Doc C Doc A’ Doc D

Doc D

コンパクション初期状態のファイルレイアウト

データの更新

コンパクション処理後

Tuning Compaction

• “Space versus time/IO tradeoff”

• 30% is default threshold, 60% found better for heavy writes…why?

• Parallel compaction only if high CPU and disk IO available

• Limit to off-hours if necessary

コンパクションのチューニング

Manual Management/Maintenance

• Scaling•Upgrading/Scheduled maintenance•Dealing with Failures•Backup/Restore

手動マネージメント / メンテナンス

Scaling

• Couchbase is completely “shared-nothing” and almost

all factors scale linearly

• Need more RAM? Add more nodes…

• Need more disk IO? Add more nodes…

• Better to add nodes than to incrementally increase

capacity

• Add more nodes BEFORE you need them

Couchbase は、完全に「シェアードナッシング」であり、殆どのファクターはリニアにスケールする

各サーバの能力を上げようとせず、ノードを追加すべき

本当に必要となる「前に」余裕をもってノードを追加すべき

Disk I/O の能力を増やしたい？ノードを追加しよう

RAM の容量を増やしたい？ノードを追加しよう

スケーリング

Couchbase + Cisco + Solarflare

Number of servers in cluster

Op

era

tion

s p

er

secon

d

High throughput with 1.4 GB/sec data transfer rate using 4 servers

Linear throughput scalability

Upgrade1. Add nodes of new version, rebalance…2. Remove nodes of old version, rebalance…3. Done!

No disruption

General use for software upgrade, hardware refresh, planned maintenance

Clusters compatible with multiple versions (1.8.1->2.x, 2.x->2.x.y)

バージョンアップ

新バージョンのノードを追加し、リバランス

旧バージョンのノードを削除し、リバランス

バージョンアップ完了！

サービス停止は発生しない

この手法は、ソフトウェアのバージョンアップ、ハードウェアの更改、計画メンテナンス時に利用

複数バージョンに対応

Planned Maintenance

Use remove+rebalance on “malfunctioning” node:­ Protects data distribution and “safety”­ Replicas recreated­ Best to “swap” with new node to maintain capacity

and move minimal amount of data

計画メンテナンス

「機能不全」ノードの削除＆リバランスに使用

Failures Happen!

Hardware

NetworkBugs

緊急事態発生！

Easy to Manage failures with Couchbase

• Failover (automatic or manual):­ Replica data and indexes promoted for immediate

access­ Replicas not recreated­ Do NOT failover healthy node­ Perform rebalance after returning cluster to full or

greater capacity

Couchbase では、緊急時の対応も簡単

Fail Over Node

REPLICA

ACTIVE

Doc 5

Doc 2

Doc

Doc

Doc 4

Doc 1

Doc

Doc

SERVER 1

REPLICA

ACTIVE

Doc 4

Doc 7

Doc

Doc

Doc 6

Doc 3

Doc

Doc

SERVER 2

REPLICA

ACTIVE

Doc 1

Doc 2

Doc

Doc

Doc 7

Doc 9

Doc

Doc

SERVER 3 SERVER 4 SERVER 5

REPLICA

ACTIVE

REPLICA

ACTIVE

Doc 9

Doc 8

Doc Doc 6 Doc

Doc

Doc 5 Doc

Doc 2

Doc 8 Doc

Doc

• App servers accessing docs

• Requests to Server 3 fail

• Cluster detects server failedPromotes replicas of docs to activeUpdates cluster map

• Requests for docs now go to appropriate server

• Typically rebalance would follow

Doc

Doc 1 Doc 3

APP SERVER 1

COUCHBASE Client Library

CLUSTER MAP

COUCHBASE Client Library

CLUSTER MAP

APP SERVER 2

User Configured Replica Count = 1

COUCHBASE SERVER CLUSTER

フェイルオーバノード

Backup

Data Files

cbbackup

ServerServer Server

network networknetwork

“cbbackup” used to backup node/bucket/cluster online:

バックアップ方法

Restore

“cbrestore” used to restore data into live/different cluster

Data Files

cbrestore

リストア方法

Want more?

Lots of details and best practices in our documentation:

http://www.couchbase.com/docs/

さらに理解を深めるには？

Thank you

Couchbase NoSQL Document Database

[email protected]@couchbase