Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Aerospike 02 監視
Más de Makoto Uehara
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
- 10. Aerospike is OSS Topics : OSSではなかったが、2014/6/26 OSS化されました！
- 12. Aerospike CE and EE CEとEEで大きい差は、有償であるところとXDRとサポートが付くところ
- 14. System configuration in cyberz クラスタ１ svr01 svr02 svr03 slave01 slave02 slave03 クラスタ２ Client Read/Write クラスタ障害時 アプリ側でクラスタ切替えも可能 クラスタ１->クラスタ２ XDR レプリケーション ※サーバーはDellのR620 メモリ192GB、SSD800GB*4、CPU6コア*2
- 15. 本日の内容 ・Aerospike Introduction 2014 夏 ・監視
- 16. Tools Using
- 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
- 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日もあれば復旧します。
- 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
- 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
- 42. ご清聴ありがとうございました！