これがCassandra
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
38,847
On Slideshare
30,640
From Embeds
8,207
Number of Embeds
21

Actions

Shares
Downloads
63
Comments
0
Likes
71

Embeds 8,207

http://kuenishi.hatenadiary.jp 5,703
http://m7a.me 1,965
https://twitter.com 434
http://localhost 24
http://feedly.com 16
http://b.hatena.ne.jp 14
http://nuevospowerpoints.blogspot.com 14
http://tweetedtimes.com 7
http://webcache.googleusercontent.com 6
http://soulinblue.tumblr.com 5
https://www.chatwork.com 5
http://192.168.2.2 3
http://news.google.com 2
http://nuevospowerpoints.blogspot.com.ar 2
http://nuevospowerpoints.blogspot.com.es 1
https://kcw.kddi.ne.jp 1
http://www.peeep.us 1
http://digg.com 1
http://translate.googleusercontent.com 1
https://www.tumblr.com 1
http://www.inoreader.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. これがCasandraまたの名を鬼の哭くシステム
  • 2. 今日話すこと• 2013年からのCassandraとの戦いの日々と愚痴を淡々と語るだけです過度な期待はしないでください
  • 3. システム構成• Node数:97台• サーバスペック機器:Dell R410、R420メモリ:64GBCPU:16コア、24コアHDD:600GBx4 (RAID-10)600GBx2(RAID-1)+SSD 512GB(RAID-0)• クラスタ数:1• Cassandraのバージョン:1.1.5-2(独自バージョン)• KeySpace数:8• ColumnFamily数:156
  • 4. 運用状況とかCluseter Writes Request: 32000/secCluseter Reads Request : 58000/sec1 nodeあたりのデータロードサイズ約200~230GB
  • 5. Cassandraの設定• レプリケーションファクタ:3データを配置するノード数の合計• 一貫性レベル:QUORUMレプリカのあるノードの過半数から応答があった「最新」のデータを返す• ヒープ:8GB8GBより少ないほうがよいらしいhttp://www.datastax.com/docs/1.1/operations/tuning#heap-sizing
  • 6. 運用でよく使うコマンド・nodetool compact特定のkey space やcolumn familyに対してcomapctionを実行・nodetool repair障害復旧時等にデータの修復を実行・nodetool cleanuptokenレンジが変わった際に不要なデータを削除する為に実行・nodetool removetoken停止中のノードをクラスタから取り除く
  • 7. バックアップ• nodetool snapshotで取得• 8時間毎の差分スナップショットをローカルに保存• 1-3-7…のNodeのスナップショットはバックアップサーバに定期コピー
  • 8. ここからは主に2013年に入ってからあったことを語ります
  • 9. 1月・CPU8コアサーバを24コアサーバに筐体交換(6台)→ 筐体交換でデータの修復するためにrepair祭り→ repairかけているNodeとその前後Nodeのデータが肥大しまくる(2~3倍くらいに膨れ上がる)主に特定の1つのcolumn familyが激増・肥大しまくっているデータをなんとか小さくしないとやばい状態→ メジャーCompactionすれば容量が減ることが判明→ メジャーCompaction祭り※このころのrepairは5時間くらいで終わっていた※このころはメジャーCompactionは8時間くらいで終わっていた※肥大しても1台あたりのロードデータは200GBくらいだった肥大してない場合は100GB以下
  • 10. 2月2/885号機障害→ SSDがオフライン現象発生2/1589号機障害→ SSDがオフライン現象発生→ HDDのみの筐体に変更2/2485号機障害→ SSD死亡→ HDDのみ筐体に変更2/786号機障害→ SSDがオフライン現象発生→ removetokenに3時間くらい2/1290号機障害→ SSDが死亡→ HDDのみの筐体に変更2/1686号機障害→ SSDがオフライン現象発
  • 11. 2月• バックアップサーバ(17TB)にスナップショット退避しまくっていたら容量が足らなくなる→ 50TBのサーバ借りて助かる• repairする→余計なデータ増えた状態→メジャーコンパクションすれば消えたけど、その前に近隣ノードが障害→復帰して周囲が余計なデータ持っている状態でrepair→また余計なデータ増えるの繰り返しで1Nodeのロードデータが700GB超えた。。。><(特にでかいのは特定の1つだけ。本来はロードデータ100~200GB程度のはずなのに。。)とにかく特定の1つだけがでかい。。特定の1つだけのSSTableの容量が800GB近くある。。><
  • 12. 2月• 86-90レンジのノード全部のディスク容量が90%超えに。。><1回あたりの差分スナップショットの容量が300~400GBくらいに。。。><(通常は数GBくらいなのに。。)• 86-90間のノードで同時並列でとにかくメジャーCompactionかけまくるメジャーCompaction祭り開催ついでにCleanupもかけまくる※このころはこのオペやっても問題なかった。。• 87号機の特定の1つだけのメジャーCompactionが2日たっても終わらない現象発生。。。(他Nodeだとだいたい10時間くらいかかる。。)• 全台再起動やったらレンテンシがちょいちょい跳ねる現象発生。。。• 実は特定の1つだけの過去データが消えてなかったことが判明。。本来であれば1カ月以前のデータは自動で消えているはずだった。。orzアプリ側を修正してもらって、過去データはバッチで徐々に消してもらう。。。
  • 13. 3月• 1回暴れた以外は平和だった• 毎月恒例の全台再起動はやはりレンテンシ上がる。。orz1-4-7...の順番で1順やり2-5-8...の順番で2順目やっていく方式1順目は大丈夫なのに、2順目以降でレイテンシがはねる。。。
  • 14. 4月04/0189号機障害→ ボードとかのHW障害→ 筐体変更して復活repairかけたら100GB増加する処理終わるのに7時間かかるとにかくrepairしたら容量問題にぶちあたる。。。04/0486号機障害→ SSD死亡→ HDDのみ筐体に変更
  • 15. 4月04/1189号機、repair実行→ メモリリークで死亡死ぬ前もモリモリFullGCしまくりFullGC入っても6GB超のメモリが開放されていない現象発生。。。ここからFullGC祭りがはじまる。。82号機障害(R410)→ SSD死亡バグフィックスしたパッチあてたバージョンに差し替えはじめる(アプリ側に作ってもらった独自バージョン。世の中に出回ってない)
  • 16. 4月04/1689号機→ パッチあてたバージョンでもrepairで死亡04/1889号機が明らかにおかしなデータを持っている感じだったので89号機のデータ消し去って、クラスタに組み込みなおす。repairかける(翌日障害のトリガーになる)。
  • 17. 4月04/19→ 88号機応答なし障害full gcで死亡※82号機で同じオペレーションしても障害はなかった今度は90号機が応答なくなったので、再起動。。orz87号機障害→ SSD死亡→ HDDに差し替え88号機が最後のR420+SSDとなる。。。
  • 18. 4月04/20→ 1:03 88号機メモリリークで障害→ 7:57 88号機メモリリークで障害→ 11:43 88号機メモリリークで障害全部87号機のrepairがトリガー。。。ヒープを 12GBにして回避する→ 23:14 88号機障害(SSD死亡)→ HDDに変更04/23→ 89号機メモリリークで障害メジャーCompactionでふっとぶ。。。4/24→ 87号機メモリリークで障害メジャーCompactionでふっとぶ。。。
  • 19. 4月原因切り分け(特定レンジの問題なのかクラスタ全体の問題なのか)のため63号機をデータ消して、クラスタに組み込みなおし、障害頻発するレンジと同じオペレーション(repairやComapction)やってみる→ 問題はおきなかった→ メモリリークは後半レンジ特有問題と判明あとついでにSSDからHDDに変更しておいた全台をバージョンアップして再起動ヒープも全台戻す(8GBより少ないほうがよいらしいので)
  • 20. 5月05/0790号機メモリリークで障害cleanupでふっとぶ。。87号機(R420)を97号機(R410)と差し替えてみたが、メモリリーク発生OSと機種特有の問題ではないことがわかった。。toke-1でJoinさせてからremoveをやったが、remove時間は変わらず。。orzノード障害への対処の推奨方法はtoken-1で新NodeをJoinさせてから障害NodeをRemoveするのがよいらしいhttp://wiki.apache.org/cassandra/Operations_JP#A.2BMM4w.2FDDJlpxbszB4MG5b.2FlHm-97号機をrepair。。。(翌日障害のトリガーとなる。。。)
  • 21. 5月05/0888,89号機メモリリークで障害再起動しても復旧せずヒープを12GBにして再起動で復旧05/09-1083-90の間に予備機7台をクラスタにJoinさせてデータを分散させる
  • 22. 今後• バージョンアップする(1.2系へ)• クラスタを分割(でかいCFが負荷高いので他に逃がしたい)• 検証(障害頻発環境を再現させてバージョンアップ等で改善するかとか。。。)
  • 23. Cassandraとの付き合い方・JIRAを読む!https://issues.apache.org/jira/browse/CASSANDRA自分が使っているバージョンがどんな地雷踏む可能性があるか把握しておくこと・ソースを読む!ソースコードがマニュアルです・なんかあったら再起動!大抵これで直ります^^/・とにかく祈る!暴れないように日々祈りをささげる
  • 24. 最後に一言
  • 25. あなたはそれでもCassandraを使いますか?