Couchbase Server Release Note 2.5 解説

土田 行一

2.5がリリースされました！(2014.2.11)

Community Edition は2.2にバージョンアップしました

2.5.0 2.2.0

EE2.2.0 とCE2.2.0 のビルド番号は同じ

build 837

簡単に2.2をおさらいします• XDCRのプロトコルをmemcahdedプロトコルに変更（パフォーマンスが向上）

• metadata purge設定が追加（削除されたアイテムのメタデータを除去することが可能に）

• 閲覧専用のユーザアカウント設定が追加

• ルート権限が不要なインストール＆サーバ起動が可能に

では早速2.5の解説をします

Couchbase Server Release Notes for 2.5 GA¶ Couchbase Server 2.5 (February 2014) is a minor release following Couchbase Server 2.2. This includes some important new features and bug fixes.

Couchbase Server 2.5 (2014年２月リリース) は、Couchbase Server 2.2 に続くマイナーリリースです。本バージョンには、いくつかの重要な機能の追加と、バグフィックスが含まれます。

Enhancements in 2.5¶ Couchbase Server 2.5 includes the following new features and enhancement: • Rack Awareness (Enterprise Edition only) • XDCR data security (Enterprise Edition only) • Optimized connection management

Couchbase Server 2.5 、以下の新しい機能と、性能改善が施されています。

!・ラック・アウェアネス（エンタープライズエディション限定）

・XDCRデータセキュリティ（エンタープライズエディション限定）

・接続制御の最適化（による性能向上）

Rack Awareness feature¶ The Rack Awareness feature allows logical groupings of servers on a cluster where each server group physically belongs to a rack or availability zone. This feature provides the ability to specify that active and corresponding replica partitions be created on servers that are part of a separate rack or zone. This increases reliability and availability in case entire racks or zones become unavailable.

ラックア・ウェアネス機能

ラック・アウェアネス機能は、各サーバグループがラックやアベィラビリティゾーンに物理的に従属している（環境での）、クラスタ上にあるサーバの論理的なグルピーングを許容します。この機能では、アクティブ（パーティション）と、（このアクティブパーティションから）ラックやゾーンとしては分離されたサーバ上に生成された、対応するレプリカパーティションを特定する能力を提供します。

この機能により、ラックもしくはゾーン単位での機能不全が起きた場合の信頼性が向上します。

Server Group

Server Group毎にサーバノードを定義できます

Rack#1=Group1 Rack#2=Group2 とした場合の例

XDCR data encryption feature¶ The cross data center (XDCR) data security feature provides secure cross data center replication using Secure Socket Layer (SSL) encryption. The data replicated between clusters can be SSL-encrypted in both uni and bi-directional.

XDCR データ暗号化機能

XDCR データ暗号化機能は、SSL暗号化を使用してセキュアなクロスデータセンタレプリケーションを提供します。単方向あるいは双方向にてクラスタ間でレプリケートされたデータは、SSL暗号化が施されます。

XDCR data encryption feature¶ With the XDCR data security feature, the XDCR traffic can be secured by selecting the XDCR encryption option and providing the remote cluster’s certificate. The certificate is a self-signed certificate used by SSL to initiate secure sessions.

XDCRデータセキュリティ機能を使用することで、XDCRによる通信は、選択されたXDCR暗号化オプションとリモートクラスタから提供される証明書によりセキュアな通信が確保できます。この証明書は、セキュアなセッションを生成するためにSSLにより使用される、自己署名証明書です。

XDCR Data Encryption

XDCR Data Encryption

Optimized connection management¶ In releases prior to Couchbase Server 2.5, a developer, via a client library of their choice, randomly selects a host from which to request an initial topology configuration. Any future changes to the cluster map following the initial bootstrap are based on the NOT_MY_VBUCKET response from the server. This connection is made to port 8091 and is based on an HTTP connection.Starting with Couchbase Server 2.5, client libraries query a cluster for initial topology configuration for a bucket from one of the nodes in the cluster. This is similar to prior releases. However, this information is transmitted via the memcached protocol on port 11210 (rather than via persistent HTTP connections to port 8091). This significantly improves connection scaling capabilities.

接続制御の最適化

Couchbase Server 2.5以前のリリースでは、デベロッパはクライアントライブラリを通じて、初期のトポロジ設定をリクエストするために、ランダムにホストを選択していました。将来的なクラスタマップの変更や後続の初期ブートストラップは、すべて、サーバからのNOT_MY_VBUCKETレスポンスを基礎にしていました。

この接続はポート番号8091に対して行われ、HTTPコネクションを基礎としていました。

Starting with Couchbase Server 2.5, client libraries query a cluster for initial topology configuration for a bucket from one of the nodes in the cluster. This is similar to prior releases. However, this information is transmitted via the memcached protocol on port 11210 (rather than via persistent HTTP connections to port 8091). This significantly improves connection scaling capabilities.

Couchbase Server 2.5からは、クライアントライブラリは、クラスタ内のノードの１つからの、バケットのための初期トポロジ設定のために、クラスタに問い合わせをします。これは、以前のリリースとほとんど同じように見えますが、しかし、（ポート番号8091からHTTPパーシステントコネクションを通じてではなく）ポート番号11210からmemcahedプロトコルを通じて転送されるようになります。このことは、接続に関するスケーリング能力を著しく向上させます。

Note This change is only applicable to Couchbase type buckets (not memcached buckets). An error is returned if a configuration request is received on port 8091.!

注意事項

この変更は、Couchbaseタイプのバケットにのみ適用されます。memcachedバケットには適用されません））。もしもコンフィギュレーションリクエストがポート番号8091に受け取られた場合、エラーが返却されます））

Couchbase社に問い合わせたところ、後方互換性は保たれているそうです。

実際、Couchbase Server 2.5と、Java SDKの最新版(2.5リリース前のバージョン）でset getできるか

試したところ、問題なくできました。

後日談

http://blog.couchbase.com/couchbase-java-sdk-140-new-and-noteworthy

meet up の数時間後に、 Java SDK 1.4.0-dp(デベロッパ・プレビュー）

のアナウンスがありました。

Java SDKではこのバージョンで Optimized Connection Managementの

サポートがされるとのことです。

簡単にJava SDKの動作 (初期Server接続)をまとめてみますCouchbase Server バージョン

SDKバージョン 動作（土田の理解）

2.5 JavaSDK1.3.2

従来のサーバ接続動作を実行（後方互換されている） ①8091ポートに接続(HTTPプロトコル) ②クラスタマップを取得 ③11210ポートに接続(バイナリmemcachedプロトコル) ④以降11210ポートに対して後続のオペレーションを実行

2.5 JavaSDK1.4.0

新しいサーバ接続動作 (Optimized Connection Management)

①11210ポートに接続(バイナリmemcachedプロトコル) ②以降11210ポートに対して後続のオペレーションを実行

2.5以前は以下のように動作するようです

Couchbase Server バージョン

SDKバージョン 動作（土田の理解）

2.5以前 JavaSDK1.3.2

従来のサーバ接続動作を実行（後方互換されている） ①8091ポートに接続(HTTPプロトコル) ②クラスタマップを取得 ③11210ポートに接続(バイナリmemcachedプロトコル) ④以降11210ポートに対して後続のオペレーションを実行

2.5以前 JavaSDK1.4.0

新しいサーバ接続動作（後方互換されている） ①11210ポートに接続(バイナリmemcachedプロトコル) ②失敗したら(2.5以前では失敗する）8091ポートに接続(HTTPプロトコル) ③クラスタマップを取得 ④11210ポートに接続(バイナリmemchaedプロトコル) ⑤以降11210ポートに対して後続のオペレーションを実行

サーバ接続が高速化すると思いましたので試してみました。

（実行してみたサンプルコード： 1.3.2/1.4.0-dpともに同じコードで動作）public class CouchTest {! public static void main(String[] args) throws Exception { ArrayList<URI> nodes = new ArrayList<URI>(); nodes.add(URI.create("http://127.0.0.1:8091/pools")); int times = 1000;//Server接続・切り離しを1000回試行 long startTime = System.nanoTime(); for(int i=0; i < times; i++){ CouchbaseClient client = null; try { client = new CouchbaseClient(nodes, "default", "");//Server接続（これまでと同じ記述で動作する様です） } catch (Exception e) { System.exit(1); } client.shutdown(); } long estimateTime = System.nanoTime() - startTime; System.out.println("Average Time: " + (estimateTime/times)/1000000 + " msec."); }}

実行内容：　サーバの接続とシャットダウンを単純に1000回繰り返し平均を算出

単純な計測ですが、たしかに高速化している様です

Java SDK 1.4.0-dpで実行

Java SDK 1.3.2で実行

実行環境: mac os-x 10.9.1 Intel Core i5 2.4GHz memory 4GB Server Clientともにローカルで実行

Upgrade notes for 2.5¶ When upgrading to Couchbase Server 2.5, if the cluster has more than one (1) replica configured during swap rebalance, some vBuckets are re-distributed across the cluster.

2.5へアップグレードする際の注意事項

Couchbase Server 2.5にアップグレードする際に、スワップリバランスの間、対象のクラスタが2以上のレプリカ設定をしている場合、いくつかのvBucketはクラスタ全体に再配布されるでしょう。

Important Prior to upgrading to Couchbase Server 2.5 from previous versions, if buckets are using any of the following reserved ports, change the port for the bucket. Otherwise, XDCR data encryption is unavailable. (This applies to both offline and online upgrades.)With XDCR data encryption, the following ports are reserved:

Port Description

11214 Incoming SSL Proxy

11215 Internal Outgoing SSL Proxy

18091 Internal REST HTTPS for SSL

18092 Internal CAPI HTTPS for SSL

重要

以前のバージョンから、2.5にアップグレードするに先立って、もしも、バケットが、以下の予約されたポートを使用している場合、ポート番号を変更してください。さもなければXDCRデータ暗号化機能は使用できなくなります。（これは、オンラインアップグレードでも、オフラインアップグレードでも同じです）

XDCR暗号化のため、以下のポートが予約されています。

Important Ensure that these reserved ports are available prior to using XDCR data encryption.

重要事項

これらの予約ポートが、XDCRデータ暗号化を使用する前に、利用可能であることを確認してください。

Releace Noteでは書かれていないこと

RAM QuotaがWebコンソールから設定変更可能になっている

auto failover のデフォルト値が30秒→120秒に変更されている

設定可能な範囲は３０～3600と以前と変わっていない

Metadata Purge Intervalが 0.04 = 1時間まで設定できるようになっている

レプリカ数が後から変更できるようになっていました

設定をSave後、リバランスを実行し有効にする様です。

ありがとうございました