Aerospike 02 監視

Aerospike v3 その2 “監視”

2014/08/20 @道玄坂

株式会社 cyberz

上原誠

自己紹介

・～2012年2月某SIerでインフラ周りに従事・ 2012年3月サイバーエージェント入社

- Amebaスマフォプラットフォームの構築

- 統合ログ解析基盤やオンラインデータベースの

インフラミドルウェア部分を担当

- Hadoop､HBase、Flume

・上原誠 (@pioho07)

【名前】

【経歴】

本日の内容

・Aerospike Introduction 2014 夏

・監視

本日の内容


・監視

RETAIL

E-COMMERCE

MOBILE

OMNI

CHANNEL

GAMING

WEB

VIDEO

SOCIAL

SEARCH

EMAIL

Aerospike is Global share

RETAIL

E-COMMERCE

MOBILE

OMNI

CHANNEL

GAMING

WEB

VIDEO

SOCIAL

SEARCH

EMAIL

Cyberz also joined

Aerospike is これ

ロケット先端の棒の先についているシンプルな円盤状の板

この板があると、空気抵抗の観点からは不利だが、

音速の壁を超える際の衝撃波がロケットの外側に逃げるため、

本体にはその影響が及ばないという効果があります。

極めてシンプルな部品ではあるものの、それがロケット全体を守る役割をしている

Aerospike is NoSQL

これ

Aerospike is A&P

ここ

Aerospike is OSS

Topics : OSSではなかったが、2014/6/26 OSS化されました！

Aerospike is OSS CEがCommunityEditionのことです。

EEがEnterpriseEditionになります。

ここからダウンロード可。下の方にgitのリンクもあるよ。

バージョンアップは頻繁で多いと月に2回くらい頻度で上がる

Aerospike CE and EE CEとEEで大きい差は、有償であるところとXDRとサポートが付くところ

Price of Aerospike EEの場合の年間費用です。サポートやXDR機能が使えます。

System configuration in cyberz

クラスタ１

svr01 svr02 svr03 slave01 slave02 slave03

クラスタ２

Client

Read/Write クラスタ障害時

アプリ側でクラスタ切替えも可能クラスタ１->クラスタ２

XDR レプリケーション

※サーバーはDellのR620

メモリ192GB、SSD800GB*4、CPU6コア*2

本日の内容


・監視

Tools Using

・AMC(AerospikeManagementConsole)

・Cliツール

・cactiとnagios

Tools Using

Aerospike Management Console

Aerospike Management Console

・AMC(AerospikeManagementConsole)

画像の通り便利そうですが、便利なところと便利でないところがあります。

クラスタの状態をリアルタイムに一元的にグラフィカルに表示できるのがいいのですが、

最大30分前の情報しか残せません。

閾値をもうけてアラートを飛ばすことは出来ません。

こちらもアップデートが頻繁にありますので最新をお勧めします。

逆に言うと上記が満たせるととても魅力的なツールになります。

欲を言えばデプロイまでできたら完璧ですね。

Aerospike Cli

Aerospikeのステータス取得コマンド

コマンド実行参考例はこの後ちょこちょこ出てきます。

asmonitor (よく使う)

ascli (少し使う)

asinfo (少し使う)

cli (ほとんど使わない)

Cacti & Nagios

ぶっちゃけ作り込みました。

nagiosとgraphiteのプラグインはあるみたいなんだけど、これ多分古いです。解凍すると2012/09とかだし、これAerospike v2の時のものでないかな？

graphiteはそもそも使ってないし・・

ってことで作りました

Cacti & Nagios

Nagios側の監視で一般的なものはいつも通りな感じで監視しています。

PING、CPU、LA、DISK、SSH、NTPとか

Aerospikeの監視としては以下を取得しています。必要最小限の項目で今後運用しながら増やすことを検討しています。

・asdプロセス、xdrプロセス (現在はasdプロセスとレプリのxdrプロセスが別れています)

・ポート：3000,9918,3001,3003,3004

・SSD容量

・Memory容量

・Read Transaction per sec

・Write Transaction per sec

・Client Connection

※今後増やす候補

・err_**

・queue

Cacti & Nagios

・ポート監視

リッスンしてるポートは一通り見てます

3000はサービスポート

9918はハートビートのマルチキャストで使うポート

3001はマイグレーション時に使うFablic通信ポート

3003はasd情報取得に使うinfoポート

3004はxdrの情報取得に使うinfoポート

※ちなみに3002はハートビートをユニキャストで行う場合のポート

Cacti & Nagios

・SSD容量

SSD上にファイルシステムを作ってないのでOSコマンドでは使用率の取得ができません。なのでAerospikeのasmonitorコマンドを使って値をゲットします。

以下のように得られる結果を

[root@svr01]# asmonitor -e “stat –h $HOSTNAME” | grep used-bytes-disk

used-bytes-disk 231,971,784,064

↓のようなワンライナーで加工して値だけ取り閾値を定め監視します。カンマいらねー。

[root@svr01]# asmonitor -e "stat -h $HOSTNAME:3000 list" | grep used-bytes-disk | awk '{print $2}' | sed -e "s/,//g"

231971887744

・参考までにasmonitor –e “stat” コマンド

[root@svr01]# asasmonitor -e "stat -h $HOSTNAME"

Enter help for help

request to 172.0.0.1 : 3000 returned error

skipping 172.0.0.1:3000


3 hosts in cluster: 172.0.0.1:3000,172.0.0.2:3000,172.0.0.3:3000

====svr01:3000====

batch_errors 0

batch_initiate 44,509

batch_queue 0

batch_timeout 0

batch_tree_count 0

client_connections 28

cluster_integrity true

cluster_key 3XXXXXXXXXXXXXXX

cluster_size 3

data-used-bytes-memory 0

err_duplicate_proxy_request 0

err_out_of_space 0

err_replica_non_null_node 0

err_replica_null_node 0

err_rw_cant_put_unique 0

err_rw_pending_limit 0

err_rw_request_not_found 0

err_storage_queue_full 0

err_sync_copy_null_master 0

err_sync_copy_null_node 0

err_tsvc_requests 0

err_write_fail_bin_exists 0

err_write_fail_generation 0

Cacti & Nagios

・SSD容量監視の閾値

閾値の決め方はSSDとAerospikeの仕組を考慮します。

話が長くなりますが、

今回1本800GBのSSDを使用しました。

まずSSD自体のパフォーマンスと寿命の最適化という意味でOP(Over Provisioning)されている必要があります。これはベンダーによってはOP済のSSDもあれば、こちらでOPしてあげる必要があるものもあります。OPの推奨値は概ね15-29%(これもベンダーによりまちまち)ですのでOP済でないと容量的に設計に大きな影響がでます。事前にこれを考慮した容量のSSDを購入する必要があります。

ですのでOP済なら問題なし、OP済でない場合はOPしその分の容量を引きます。

ちなみに弊社で利用したSANDISK 型番:SDLB6JC-800G-20 はOP済でした。

http://www.sandisk.com/assets/docs/WP004_OverProvisioning_WhyHow_FINAL.pdf



Cacti & Nagios


SSD自体の性能とは別に、Aerospike自体がデータとは別にデフラグ処理の為の領域を必要としています。これはミドルウェアレベルでのSSD性能の為に必要領域でその上限値をHWM(High Water Mark)と言います。

こちらはSSDであれば50%(設定変更は可能。弊社は検証した結果目に見える性能劣化がなかったので60%としています)がAerospikeが定める基準値で、それを超えると古いデータが消されていきます。監視の閾値としてはこれを超えることは致命的(Critical)と見るべきです。

もちろんCriticalの前段のWarningで気付いて、速やかにサーバー増設を行う必要があります。この時のWarningの閾値がポイントになります。例えば3台のクラスタの場合は60%がCriticalなのでWarningを50%くらいにすると、クラスタ内の1台のサーバーがダウンした時点で残りの2台が25%増大するので75%となりCriticalの閾値を超えてしまいます。弊社ではWarningを36%としています。この場合1台サーバーがダウンした場合18%が乗ってきますので、54%となりCriticalには達しません。ただCritical直前の状態であるので迅速なサーバー復旧とサーバー追加が必要です。この点についても弊社では常に追加できるサーバーをwarm standbyさせる運用設計を取っている為どんなに長くても1日もあれば復旧します。

Cacti & Nagios


ですので、サーバー1台あたり800GBのSSDを4本だと実効容量が2.98TB

ですが、HWMが60%で1.78TBでこれがCriticalの閾値

Warningは36%で1.07TBとなります。

少し話が逸れましたが、800GBのSSD4本も積んでこれしか使えないので設計段階ではこの辺考慮が重要です。

性能とコストのトレードオフですねぇ

※メモリも同じ考え方です

少ない・・

Cacti & Nagios

・Read Transaction per sec

・Write Transaction per sec

秒間のRead/Writeのトランザクションが0な状態も弊社の使い方だとあり得ない状況なので監視しています。

以下のワンライナーで値をゲットして0だと検知します。

[root@svr01]# asmonitor -e "latency -h $HOSTNAME:3000 list -k reads" | grep ^$HOSTNAME | awk '{print $3}' | sed -e "s/,//g" | cut -d "." -f 1

※Client Connectionも同じ考え方です

・参考までにasmonitor –e “latency” コマンド

[root@svr01]# asmonitor -e "latency"

Enter help for help


skipping 172.0.0.1:3000


3 hosts in cluster: 172.0.0.1:3000,172.0.0.2:3000,172.0.0.3:3000

====writes_master====

timespan ops/sec >1ms >8ms >64ms

172.0.0.1:3000 17:58:23-GMT->17:58:33 0.1 0.00 0.00 0.00

172.0.0.2:3000 02:59:04-GMT->02:59:14 0.0 0.00 0.00 0.00

172.0.0.3:3000 02:58:58-GMT->02:59:08 0.2 0.00 0.00 0.00

====writes_reply====


172.0.0.1:3000 17:58:23-GMT->17:58:33 0.1 0.00 0.00 0.00

172.0.0.2:3000 02:59:04-GMT->02:59:14 0.0 0.00 0.00 0.00

172.0.0.3:3000 02:58:58-GMT->02:59:08 0.2 0.00 0.00 0.00

====reads====


172.0.0.1:3000 17:58:23-GMT->17:58:33 0.5 0.00 0.00 0.00

172.0.0.2:3000 02:59:04-GMT->02:59:14 0.8 0.00 0.00 0.00

172.0.0.3:3000 02:58:58-GMT->02:59:08 1.5 0.00 0.00 0.00

====udf====


172.0.0.1:3000 17:58:23-GMT->17:58:33 0.0 0.00 0.00 0.00

172.0.0.2:3000 02:59:04-GMT->02:59:14 0.0 0.00 0.00 0.00

172.0.0.3:3000 02:58:58-GMT->02:59:08 0.0 0.00 0.00 0.00

Cacti & Nagios

cacti側のリソースも一般的なものはいつも通りな感じで取得しています。

CPU、LA、DISKとか

Aerospikeのリソース監視としては以下を取得しています。必要最小限の項目で今後運用しながら増やすことを検討しています。

・Read Latency、Write Latency

・ Memory

・ Migration Counter(send,receiveのパーティション数)

・ Master Object count(一般的なDBで言うレコード数)

・ Read Transaction per sec

・ Write Transaction per sec

・ xdr digestlog 使用率

・ xdr throuput

Cacti & Nagios

cacti で今後取りたい値

・ max-write-cache

・ ongoing_write_reqs

・ record_locks

・ waiting_transactions

・ stat_rw_timeout

・ storage_defrag_corrupt_record

・ storage_defrag_records

・ write_master

・ write_prole

・ record_refs

・ reaped_fds

・ record_locks

・ queue

Cacti & Nagios

・Read Latency、Write Latency

レイテンシは取りたいですよね。

Aerospikeだとほれこんな感じで

asmonitor -e "latency -h $HOSTNAME:3000 list -k writes_master" | grep ^$HOSTNAME | awk '{print $3}' | sed -e "s/,//g“

Cacti & Nagios 実際はこんな風に出てます。

[root@svr01]# asmonitor -e "latency -h $HOSTNAME:3000 list -k writes_master"

Enter help for help


skipping 172.0.0.1:3000


3 hosts in cluster: 172.0.0.1:3000,172.0.0.2:3000,172.0.0.3:3000

====writes_master====


svr01:3000 19:18:44-GMT->19:18:54 0.4 0.00 0.00 0.00

Cacti & Nagios cactiではこんな感じで。1-8ms,8-64ms,64ms以上で色分けしてます。

Cacti & Nagios

・ Migration Counter(send,receiveのパーティション数)

Aerospikeでは全データを4096個のパーティション単位にデータを分割します。この単位でノード間をマイグレーション(分散させます。パーティションにはマスタとレプリカがあるので同居しないようにAerospikeがよしなに分散します。デフォルトのレプリケーションファクタは2です。)

グラフ化することでマイグレーション発動時の波を見たい程度ですが入れてます。

※マイグレーションはノード間のパーティションコピーと思ってもらえればと

・ Master Object count(一般的なDBで言うレコード数)

これは単純にレコードの件数の増加を見たいので入れています。

Cacti & Nagios

・ Read Transaction per sec

・ Write Transaction per sec

これは監視でも取得している値で、秒間のReadとWriteの数をグラフ化しています。

AerospikeだとReadがGet、WriteがSetと呼びます。

Cacti & Nagios

・ xdr digestlog 使用率

・ xdr throuput

XDRは”cross(X) Datacenter Replication”の略でデータセンター間でのクラスタ間レプリケーションの機能です。別にDC間でなくてもOKです。弊社もDC内で利用しています。

digestlogは更新ログを溜め込むファイルです。更新ログをレプリ先に転送し転送先で実行されます。MySQLで言うバイナリログですね。溜めておくので非同期でレプリケーションします。プロセス停止しても再開後途中から転送してくれます。

記載通りログファイルの使用率と帯域を取っています。

コマンドは実は少し今までと違い以下になります。

asinfo -p 3004 -v statistics | grep -v ^requested | awk '{print $3}' | cut -d ";" -f 3 | cut -d "=" -f 2 | cut -d "%" -f 1

Cacti & Nagios

参考までにasinfoの結果です。1行です・・

[root@svr01]# asinfo -p 3004 -v statistics

requested value statistics

value is used-recs-dlog=352153;total-recs-dlog=1249375300;free-dlog-pct=100%;stat_dlog_read=1435792;stat_dlog_write=1397623;stat_dlog_fwrite=65144;stat_dlog_fread=204038;stat_dlog_fseek=51168;stat_recs_logged=1397653;stat_recs_relogged=0;stat_recs_dropped=0;stat_pipe_reads_diginfo=1397626;stat_recs_localprocessed=1397650;stat_recs_replprocessed=3;stat_recs_shipped=670744;xdr_deletes_shipped=1;xdr_deletes_relogged=0;xdr_deletes_canceled=0;stat_recs_shipping=18446744073709551615;stat_recs_outstanding=0;local_recs_fetched=671535;local_recs_fetch_avg_latency=0;local_recs_migration_retry=0;local_recs_notfound=1064091;noship_recs_genmismatch=792;noship_recs_expired=0;noship_recs_notmaster=707352;noship_recs_unknown_namespace=0;err_ship_client=0;err_ship_server=0;perdc_timediff_lastship_cur_secs=0;timediff_lastship_cur_secs=0;cur_throughput=0;latency_avg_ship=0;latency_avg_dlogwrite=0;latency_avg_dlogread=0;esmt-bytes-shipped=72865892;esmt-bytes-shipped-compression=0;esmt-ship-compression=0.00%;xdr-uptime=1272850

まとめ

アーキテクチャ上CPUウェイトにはあまりなりません。

データを消さなければ基本メモリとSSDが増え続けます。性能にも可用性にもそこが一番大きく影響しますのでその監視が重要です。

メモリは1レコード64バイト使います。64*レコード数で増えます。

バリューについては容量は可変なのでどういうデータを入れるか、使い方次第になります。

規模が大きくなるとNW帯域は少し気になると思います。

asmonitorで様々なメトリクスがあります。好きな値を取ればいいのですが以下一覧参照に有用なものがあれば私も教えてほしいです。

http://www.aerospike.com/docs/reference/metrics/

※説明遅れましたが、Aerospikeはモードが3つ、”オンメモリ”、”メモリ&Disk”、”メモリ＆SSD” があります。

弊社では”メモリ＆SSD”のモードで使っています。

CyterZ Hadoop Cluster

ご清聴ありがとうございました！

Technology

Aerospike 02 監視