cassandra 100 node cluster admin operation
19 likes8,509 views
Cassandra summit JPN 2014 : 100 node cluster admin operation
![ログを見ると
INFO [ValidationExecutor:26]
2012-11-09 09:53:14,804
CompactionController.java (line 172)
Compacting large row hoge /fuga :
313938353330333037 (87368050
bytes) incrementally
※ログ出ている中では少ない方です](https://image.slidesharecdn.com/cassandrasummitslide-140126223912-phpapp01/85/cassandra-100-node-cluster-admin-operation-59-320.jpg)
![最近実行したログより
INFO [CompactionExecutor:1709]
2014-01-03 00:33:56,625
CompactionTask.java (line 221) Compacted
to [/var/lib/cassandra/data/ hoge /fuga /
hoge-fuga-he-16636-Data.db,].
352,943,576,048 to 70,536,103,035 (~19% of
original) bytes for 139,068 keys at
0.157685MB/s. Time: 426,599,477ms.](https://image.slidesharecdn.com/cassandrasummitslide-140126223912-phpapp01/85/cassandra-100-node-cluster-admin-operation-78-320.jpg)
cassandra 100 node cluster admin operation
- 1. Cassandra summit JPN 2014 100 node cluster admin operation
- 10. System Scale Daily Peak Cluster Request Read : about 45,000 qps Write : about 40,000 qps Total Data: about 35TB + snapshot 1 node avg: 350GB ※RF:3
- 11. Latency Read / avg 4ms. Write / avg 0.1~0.7ms
- 12. Cluster HW spec CPU : 16 ~ 24 core (HT enable) Memory : 64GB Disk : SAS 600GB RAID 10 ※一部テスト的にSATAだったりSSD入れて みたりのレンジがあり
- 13. 当初10台(Ver 1.1.1 ?)からスタートし -> 15(ver.1.1.3) -> 30 -> 45(Ver1.1.5) -> 60-> 90(Ver 1.1.5-2) -> 100 これはノード追加しないと耐え切れなかったというよ りは、低レイテンシを維持したかった＋データ量に 対応のため。 但し今考えるとこの増やし方はあまり賢いやり方で はなかった。理由は後ほど・・・。
- 14. Daily Operation
- 15. おおまかなまとめ サイバーエージェント 公式エンジニアブログ http://ameblo.jp/principia-ca/entry-11514557323.html
- 16. Build 構築
- 17. Chef + fabric + Jenkins
- 19. Monitoring 監視
- 20. 死活・閾値監視
- 21. Nagios + Jenkins + Perl Script to mail & Push notification
- 22. 死活監視系概要
- 23. 閾値監視系概要
- 24. トレンド監視
- 27. OS monitor ・Cacti : OS, JVM Resource graph ・Proteus-monitor : Real Time OS monitor (cyberagent engineer OSS product) https://github.com/ameba-proteus/ proteus-monitor-agent
- 28. Proteus-monitor : Real Time OS
- 30. Cassandra monitor ・Cassandra Resource graph GrowthForecast(LINE Engineer OSS product) + yohoushi (DeNA Engineer OSS product) ・opscenter :Datastax Cassandra cluster status monitor ・Pending Checker : Real Time Cassandra pending monitor (cyberagent engeneer OSS prodct)
- 31. Opscenter
- 34. Pending Checker
- 36. major nodetool cmd (ver 1.1)
- 37. show status cmd ring : cluster状況確認。多分人生で一番打 つnodetool コマンド。但し1.2系からはstatus cmdが追加されているので、どちらかというと そっちになりそう。 info : node単体の状況確認 cfstats : column family毎の統計情報 tpstats : 各stage毎の統計情報。スローダウ ンしているとかはまずこれ見る。
- 38. show status cmd compactionstats : compaction等の SSTableに対する処理状況を見る。これ 見ている時は凄いやきもきする。 gossipinfo : gossipの状況 netstats : repairなど他のノードとデータ をやりとりするstream系処理の状況。 repair掛けている時はドキドキしながら 見る。
- 39. cluster operation cmd drain : 書き込みを停止させてプロセ スを停止させる decommission : nodeが正常な状態 でクラスタから削除する move : 対象nodeのtokenを変更する removetoken : 対象nodeのtokenをク ラスタから削除する
- 40. data operation cmd flush : memtableをflushする repair : 自身が持つべきデータを他のノードと情報を交換し て修復する cleanup : 重複データ等を削除する（論理削除のみ) compact : SSTableをmajor compactionする。（基本やらな い方が良い） scrub : SSTableファイルが破壊された場合に修復を試みる （らしい） upgradesstables : CassandraのVerアップでSSTableの仕様 が変更されている場合に使用する。手順などは該当Ver -> Update verの手順を確認。
- 45. イメージ
- 48. 今までのバッドノウハウ的な奴
- 50. repair時に各node間でmarkle hash tree交換を実行してそこか ら各node間でデータのstreamを 実行するが、本来は持っている データでもmarkle hash tree交 換の処理で持っていないと判断 され新たに取得・送信している。
- 51. repairイメージ
- 59. ログを見ると INFO [ValidationExecutor:26] 2012-11-09 09:53:14,804 CompactionController.java (line 172) Compacting large row hoge /fuga : 313938353330333037 (87368050 bytes) incrementally ※ログ出ている中では少ない方です
- 64. 対応策 この時はもうしょうがないので、推 奨されていないですがJVMの heap sizeを8GB -> 12GBとかに 変更してしのぎました。
- 66. 対応策 再起動のみ
- 67. その為 Consistency level QUORUM Replica Factor 3 simple strategy (1.1系なのでvnode無し) を考慮した上でアプリケーション側に影響 が少ない全台再起動ジョブを作成し、定期 実行しています。
- 68. HWの安定性の重要さについて
- 69. もしかして見たことがある人が？
- 71. 何が起きるか SSD障害によりノードダウン -> 追 加サーバでrepair -> データ肥大 化 -> cleanup -> compaction -> 周辺ノードがrepairによるデータ書 き込みトリガーでSSD死亡… 以下ループ
- 74. ここが困るよCassandra
- 77. 実測値レベルですが 1 node data -> 300~400GB join / remove -> about 4 ~6 h repair -> about 24 h ※但しexpire的に不要なCFは見送ったりしている。 compaction -> ?
- 78. 最近実行したログより INFO [CompactionExecutor:1709] 2014-01-03 00:33:56,625 CompactionTask.java (line 221) Compacted to [/var/lib/cassandra/data/ hoge /fuga / hoge-fuga-he-16636-Data.db,]. 352,943,576,048 to 70,536,103,035 (~19% of original) bytes for 139,068 keys at 0.157685MB/s. Time: 426,599,477ms.
- 79. 426,600sec = 7110 minute = 118.5 hour = about 5 days (；ﾟДﾟ)
- 94. 1 cluster 1 cluster node -> about 50 node ? これ以上のノード数になるとrepairの実行 時間の所でも触れましたが、基本的な ジョブ等でも時間が結構掛かる
- 98. 1 node Total data -> Limit 100~200GB？ 後々のクラスタ分割や repair + snapshot + compaction等の 運用オペレーションを考慮 snapshotの保存期間とかにもよりますが。1.2系や2.0系でrepair の肥大化が抑えられるのであれば300GBくらいはアリかも。
- 100. CF 1 CFで1 node 200GBとか超えると 後々のコントロールが大変になるので、 50 node で1node 1CF 50GB程度にな るようであれば早めにクラスタ分割や論 理分割を検討？ ※分割する際の移行先クラスタへのデータ 移行やCF自体の分割に伴うApp改修など
- 102. 一般的なWebサービスで使うなら やはりアーカイブ系やヒストリー系 などデータ量が爆発しやすい所が 一番向いているか？ 一時的なイベント系などスキーマレ スが有効に利用できる所も良いか も。
- 103. 今後やっていきたい事
- 105. 監視系の統合 （かなりツール分散しまくっているので） Netflix先生が出している各種toolの検証 https://github.com/Netflix/Priam
- 106. まあ、色々と書きましたが
- 110. 運用することも考えてね！
- 111. 何か質問があればどうぞ！
- 112. 御清聴ありがとうございました