![[GKE & Spanner 勉強会] Cloud Spanner の技術概要](https://cdn.slidesharecdn.com/ss_thumbnails/gke02-200121091040-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
これがCassandra
- 3. システム構成 • Node数：97台 • サーバスペック 機器：Dell R410、R420 メモリ：64GB CPU: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/sec Cluseter Reads Request : 58000/sec 1 nodeあたりのデータロードサイズ 約200～230GB
- 5. Cassandraの設定 • レプリケーションファクタ：3 データを配置するノード数の合計 • 一貫性レベル：QUORUM レプリカのあるノードの過半数から応答があった「最新」のデータ を返す • ヒープ：８GB ８GBより少ないほうがよいらしい http://www.datastax.com/docs/1.1/operations/tuning#heap-sizing
- 6. 運用でよく使うコマンド ・nodetool compact 特定のkey space やcolumn familyに対してcomapctionを実 行 ・nodetool repair 障害復旧時等にデータの修復を実行 ・nodetool cleanup tokenレンジが変わった際に不要なデータを削除する為に 実行 ・nodetool removetoken 停止中のノードをクラスタから取り除く
- 7. バックアップ • nodetool snapshotで取得 • 8時間毎の差分スナップショットをローカ ルに保存 • １－３－７…のNodeのスナップショットは バックアップサーバに定期コピー
- 9. 1月 ・CPU8コアサーバを24コアサーバに筐体交換（6台） → 筐体交換でデータの修復するためにrepair祭り → repairかけているNodeとその前後Nodeのデータが肥大しまく る （2～3倍くらいに膨れ上がる） 主に特定の１つのcolumn familyが激増 ・肥大しまくっているデータをなんとか小さくしないとやばい 状態 → メジャーCompactionすれば容量が減ることが判明 → メジャーCompaction祭り ※このころのrepairは5時間くらいで終わっていた ※このころはメジャーCompactionは8時間くらいで終わっていた ※肥大しても1台あたりのロードデータは200GBくらいだった 肥大してない場合は100GB以下
- 10. ２月 2/8 85号機障害 → SSDがオフライン現象発 生 2/15 89号機障害 → SSDがオフライン現象発 生 → HDDのみの筐体に変更 2/24 85号機障害 → SSD死亡 → HDDのみ筐体に変更 2/7 86号機障害 → SSDがオフライン現象発 生 → removetokenに3時間くら い 2/12 90号機障害 → SSDが死亡 → HDDのみの筐体に変更 2/16 86号機障害 → SSDがオフライン現象発
- 11. ２月 • バックアップサーバ（17TB）にスナップショット退避しまくってい たら容量が足らなくなる → 50TBのサーバ借りて助かる • repairする→余計なデータ増えた状態 →メジャーコンパクションすれば消えたけど、その前に近隣ノードが 障害 →復帰して周囲が余計なデータ持っている状態でrepair →また余計なデータ増えるの繰り返しで１Nodeのロードデータが 700GB超えた。。。＞＜ （特にでかいのは特定の１つだけ。本来はロードデータ100～200GB程 度のはずなのに。。） とにかく特定の１つだけがでかい。。 特定の１つだけのSSTableの容量が800GB近くある。。＞＜
- 12. 2月 • 86－90レンジのノード全部のディスク容量が90%超えに。。＞＜ 1回あたりの差分スナップショットの容量が300～400GBくらいに。。。＞＜ （通常は数GBくらいなのに。。） • 86－90間のノードで同時並列でとにかくメジャーCompactionかけまくる メジャーCompaction祭り開催 ついでにCleanupもかけまくる ※このころはこのオペやっても問題なかった。。 • 87号機の特定の１つだけのメジャーCompactionが2日たっても終わらない現象発 生。。。 （他Nodeだとだいたい10時間くらいかかる。。） • 全台再起動やったらレンテンシがちょいちょい跳ねる現象発生。。。 • 実は特定の１つだけの過去データが消えてなかったことが判明。。 本来であれば1カ月以前のデータは自動で消えているはずだった。。orz アプリ側を修正してもらって、過去データはバッチで徐々に消してもらう。。。
- 14. 4月 04/01 89号機障害 → ボードとかのHW障害 → 筐体変更して復活 repairかけたら100GB増加する 処理終わるのに7時間かかる とにかくrepairしたら容量問題にぶちあたる。。。 04/04 86号機障害 → SSD死亡 → HDDのみ筐体に変更
- 17. 4月 04/19 → 88号機応答なし障害 full gcで死亡 ※82号機で同じオペレーションしても障害はなかった 今度は90号機が応答なくなったので、再起動。。orz 87号機障害 → 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でふっとぶ。。。
- 21. 5月 05/08 88，89号機メモリリークで障害 再起動しても復旧せず ヒープを12GBにして再起動で復旧 05/09-10 83－90の間に予備機7台をクラスタにJoinさ せてデータを分散させる
- 22. 今後 • バージョンアップする（1.2系へ） • クラスタを分割（でかいCFが負荷高いの で他に逃がしたい） • 検証（障害頻発環境を再現させてバー ジョンアップ等で改善するかと か。。。）
- 24. 最後に一言