Address
:
[go:
up one dir
,
main page
]
Include Form
Remove Scripts
Accept Cookies
Show Images
Show Referer
Rotate13
Base64
Strip Meta
Strip Title
Session Cookies
More Web Proxy on the site http://driver.im/
Submit Search
Aerospike 02 監視
•
12 likes
•
4,645 views
Makoto Uehara
Follow
aerospike monitoring
Read less
Read more
1 of 42
Download now
Downloaded 17 times
More Related Content
Aerospike 02 監視
1.
Aerospike v3 その2 “監視” 2014/08/20
@道玄坂 株式会社 cyberz 上原 誠
2.
自己紹介 ・ ~2012年2月 某SIerでインフラ周りに従事 ・
2012年3月 サイバーエージェント入社 - Amebaスマフォプラットフォームの構築 - 統合ログ解析基盤やオンラインデータベースの インフラミドルウェア部分を担当 - Hadoop、HBase、Flume ・ 上原 誠 (@pioho07) 【名前】 【経歴】
3.
本日の内容 ・Aerospike Introduction 2014
夏 ・監視
4.
本日の内容 ・Aerospike Introduction 2014
夏 ・監視
5.
RETAIL E-COMMERCE MOBILE OMNI CHANNEL GAMING WEB VIDEO SOCIAL SEARCH EMAIL Aerospike is
Global share
6.
RETAIL E-COMMERCE MOBILE OMNI CHANNEL GAMING WEB VIDEO SOCIAL SEARCH EMAIL Cyberz also
joined
7.
Aerospike is これ ロケット先端の棒の先についているシンプルな円盤状の板 この板があると、空気抵抗の観点からは不利だが、 音速の壁を超える際の衝撃波がロケットの外側に逃げるため、 本体にはその影響が及ばないという効果があります。 極めてシンプルな部品ではあるものの、それがロケット全体 を守る役割をしている
8.
Aerospike is NoSQL これ
9.
Aerospike is A&P ここ
10.
Aerospike is OSS Topics
: OSSではなかったが、2014/6/26 OSS化されました!
11.
Aerospike is OSS CEがCommunityEditionのことです。 EEがEnterpriseEditionになります。 ここからダウンロード可。下の方にgitのリンクもあるよ。 バージョンアップは頻繁で多いと月に2回くらい頻度で上がる
12.
Aerospike CE and
EE CEとEEで大きい差は、有償であるところとXDRとサポートが付くところ
13.
Price of Aerospike EEの場合の年間費用です。サポートやXDR機能が使えます。
14.
System configuration in
cyberz クラスタ1 svr01 svr02 svr03 slave01 slave02 slave03 クラスタ2 Client Read/Write クラスタ障害時 アプリ側でクラスタ切替えも可能 クラスタ1->クラスタ2 XDR レプリケーション ※サーバーはDellのR620 メモリ192GB、SSD800GB*4、CPU6コア*2
15.
本日の内容 ・Aerospike Introduction 2014
夏 ・監視
16.
Tools Using
17.
・AMC(AerospikeManagementConsole) ・Cliツール ・cactiとnagios Tools Using
18.
Aerospike Management Console
19.
Aerospike Management Console ・AMC(AerospikeManagementConsole) 画像の通り便利そうですが、便利なところと便利でないところがあります。 クラスタの状態をリアルタイムに一元的にグラフィカルに表示できるのがいいので すが、 最大30分前の情報しか残せません。 閾値をもうけてアラートを飛ばすことは出来ません。 こちらもアップデートが頻繁にありますので最新をお勧めします。 逆に言うと上記が満たせるととても魅力的なツールになります。 欲を言えばデプロイまでできたら完璧ですね。
20.
Aerospike Cli Aerospikeのステータス取得コマンド コマンド実行参考例はこの後ちょこちょこ出てきます。 asmonitor (よく使う) ascli
(少し使う) asinfo (少し使う) cli (ほとんど使わない)
21.
Cacti & Nagios ぶっちゃけ作り込みました。 nagiosとgraphiteのプラグインはあるみたいなんだけど、これ多分古いです。解凍 すると2012/09とかだし、これAerospike
v2の時のものでないかな? graphiteはそもそも使ってないし・・ ってことで作りました
22.
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
23.
Cacti & Nagios ・ポート監視 リッスンしてるポートは一通り見てます 3000はサービスポート 9918はハートビートのマルチキャストで使うポート 3001はマイグレーション時に使うFablic通信ポート 3003はasd情報取得に使うinfoポート 3004はxdrの情報取得に使うinfoポート ※ちなみに3002はハートビートをユニキャストで行う場合のポート
24.
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
25.
・参考までに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 request to 172.0.0.1 : 3000 returned error 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
26.
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_FI NAL.pdf
27.
Cacti & Nagios ・SSD容量監視の閾値 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日もあれば復旧します。
28.
Cacti & Nagios ・SSD容量監視の閾値 ですので、サーバー1台あたり800GBのSSDを4本だと実効容量が2.98TB ですが、HWMが60%で1.78TBでこれがCriticalの閾値 Warningは36%で1.07TBとなります。 少し話が逸れましたが、800GBのSSD4本も積んでこれしか使えないので設計段階 ではこの辺考慮が重要です。 性能とコストのトレードオフですねぇ ※メモリも同じ考え方です 少ない・・
29.
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も同じ考え方です
30.
・参考までにasmonitor –e “latency”
コマンド [root@svr01]# asmonitor -e "latency" Enter help for help request to 172.0.0.1 : 3000 returned error skipping 172.0.0.1:3000 request to 172.0.0.1 : 3000 returned error 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==== 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 ====reads==== timespan ops/sec >1ms >8ms >64ms 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==== timespan ops/sec >1ms >8ms >64ms 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
31.
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
32.
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
33.
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“
34.
Cacti & Nagios 実際はこんな風に出てます。 [root@svr01]#
asmonitor -e "latency -h $HOSTNAME:3000 list -k writes_master" Enter help for help request to 172.0.0.1 : 3000 returned error skipping 172.0.0.1:3000 request to 172.0.0.1 : 3000 returned error 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 svr01:3000 19:18:44-GMT->19:18:54 0.4 0.00 0.00 0.00
35.
Cacti & Nagios cactiではこんな感じで。1-8ms,8-64ms,64ms以上で色分けしてます。
36.
Cacti & Nagios ・
Migration Counter(send,receiveのパーティション数) Aerospikeでは全データを4096個のパーティション単位にデータを分割します。こ の単位でノード間をマイグレーション(分散させます。パーティションにはマスタと レプリカがあるので同居しないようにAerospikeがよしなに分散します。デフォル トのレプリケーションファクタは2です。) グラフ化することでマイグレーション発動時の波を見たい程度ですが入れてます。 ※マイグレーションはノード間のパーティションコピーと思ってもらえればと ・ Master Object count(一般的なDBで言うレコード数) これは単純にレコードの件数の増加を見たいので入れています。
37.
Cacti & Nagios ・
Read Transaction per sec ・ Write Transaction per sec これは監視でも取得している値で、秒間のReadとWriteの数をグラフ化しています。 AerospikeだとReadがGet、WriteがSetと呼びます。
38.
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
39.
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=6514 4;stat_dlog_fread=204038;stat_dlog_fseek=51168;stat_recs_logged=1397653;stat_r ecs_relogged=0;stat_recs_dropped=0;stat_pipe_reads_diginfo=1397626;stat_recs_loc alprocessed=1397650;stat_recs_replprocessed=3;stat_recs_shipped=670744;xdr_dele tes_shipped=1;xdr_deletes_relogged=0;xdr_deletes_canceled=0;stat_recs_shipping=1 8446744073709551615;stat_recs_outstanding=0;local_recs_fetched=671535;local_re cs_fetch_avg_latency=0;local_recs_migration_retry=0;local_recs_notfound=1064091; noship_recs_genmismatch=792;noship_recs_expired=0;noship_recs_notmaster=7073 52;noship_recs_unknown_namespace=0;err_ship_client=0;err_ship_server=0;perdc_t imediff_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
40.
まとめ アーキテクチャ上CPUウェイトにはあまりなりません。 データを消さなければ基本メモリとSSDが増え続けます。性能にも可用性にもそこ が一番大きく影響しますのでその監視が重要です。 メモリは1レコード64バイト使います。64*レコード数で増えます。 バリューについては容量は可変なのでどういうデータを入れるか、使い方次第にな ります。 規模が大きくなるとNW帯域は少し気になると思います。 asmonitorで様々なメトリクスがあります。好きな値を取ればいいのですが以下一 覧参照に有用なものがあれば私も教えてほしいです。 http://www.aerospike.com/docs/reference/metrics/ ※説明遅れましたが、Aerospikeはモードが3つ、”オンメモリ”、”メモリ&Disk”、”メモリ&SSD” があります。 弊社では”メモリ&SSD”のモードで使っています。
41.
CyterZ Hadoop Cluster
42.
ご清聴ありがとうございました!
Download