Your SlideShare is downloading. ×
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Cassandraのバックアップと運用を考える
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Cassandraのバックアップと運用を考える

3,783

Published on

0 Comments
12 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,783
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
29
Comments
0
Likes
12
Embeds 0
No embeds

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. Cassandraのバックアップと運 用を考える。 INTHEFOREST とみたかずたか
  • 2. 自己紹介冨田 和孝 (@railute)肩書き: 株式会社INTHEFOREST 代表取締役社長Cassandra商用サポート、Cassandraコンサルティング他Cassandra勉強会主宰2か月に一度程度開催。現在、第24回まで開催。職種:本職はDB・インフラ系エンジニア以前、某レストランサーチのDBA高負荷・大容量・大規模のOracleRACとPostgreSQLとMySQLに苦しめられ続けた経験あり。NLPおよびテキストマイニング始め〼た。(実はもともと言語学(日本語)専攻。)
  • 3. Cassandraサポートサービスサービス プラチナ ゴールド スタンダードサポート※1 無制限 月間80時間迄 月間40時間迄サポート時間 24 x 365 平日9時-5時 平日9時-5時Apache Cassandraへの不 ○ ○ ○具合報告重大インシデント対応 ○ × ×の緊急パッチ提供障害切分け ○ × ×環境構築支援 ○ ○ ×運用支援 ○ ○ ×※1メール中心のサポートとなります。対応時間には問い合わせ対応、構築・運用支援に関する情報提供などが含まれます。
  • 4. Cassandra トレーニングCassandra 概要対象者 Cassandraをこれから使用する方期間 1日間(9:00-17:30)バージョン 1.1,1.0(0.8等も可) •Cassandraの歴史 •Cassandraのアーキテクチャ内容 •Cassandraのインストールと起動停止方法 •Cassandraの利用(設定ファイル、ログの種類) •Cassandra CLI
  • 5. Agenda Cassandraの前提 監視をするということ バックアップをするということ
  • 6. Cassandraの前提各ノードは独立している Cassandraは他のノードのステータスを「管 理」はしない。 ※Seedsは初期接続対象、ないしはGossipの優先選択先なだけ。 初期接続時:スキーマ情報取得など Gossip :毎回必ずSeedをゴシップ対象に加える あのノード落 ちてるらしい よ
  • 7. Cassandraの前提SSTableは Write Once 通常時 不整合時 データの更新は Memtableへ Memtable Memtable※SSTableは常に作 BloomFilter BloomFilter 不整合発生成時以外の更新処 更新理は行われない。 SSTable SSTable SSTable SSTable SSTable SSTable 再構築 Memtable JVMのGC Memtable BloomFilter BloomFilter 不要SSTable削除 SSTable SSTable SSTable SSTable SSTable SSTable SSTableMerg e Compaction時 SSTable削除時
  • 8. 監視をするということCassandraは原則すべてJMXJava Management Extensions(JMX)は、アプリケーションソフトウェア/システムオブジェクト/デバイス(プリンターなど)/サービス指向ネットワークなどの監視・管理のためのツールを提供するJavaプラットフォーム技術の一種。これらのリソースは MBean(Managed Bean)と呼ばれるオブジェクトで表現される。このAPIの面白い特徴として、クラス群を動的にロードしてインスタンス化できる。(Wikipediaより) JVMの握っているハードウェアリソースも取得できる メモリ CPU IO etc……
  • 9. 監視をするということCassandraにおける監視の定義 ステータス管理 • Cassandraにおけるダウンとは?  各ノードはお互いの停止時間の存在を前提とする。  「サーバーが戻ってこない」以外の障害はサービスに対する影 響が少ない リソース管理 • Cassandraに必要なリソースとは? • CPU • IO • ネットワーク • メモリ
  • 10. 監視をするということステータス管理(障害検知) ノードダウンの要因 ハード障害 ⇒ disk障害、メモリ障害、システムボード障害等 ⇒ノード障害 ※むしろ気さくにノード障害にOut of Memory ⇒ ヒープ不足、コンパクション遅延、フラッシュの遅延 ⇒原因の特定とチューニングが必要 ネットワーク遅延⇒パケットロス、帯域不足等 ⇒データの不整合が発生する可能性があるのでrepairを検討
  • 11. 監視をするということリソース管理 何を抑えておくべきか  ノードが落ちるメモリ使用量  データが闇に消えかねないネットワーク系の不具合  Write heavy はCPUバンド  Read heavy はメモリ/IOバンド
  • 12. 監視をするということメモリ使用量 Cassandraはメモリ喰い GCが適切に行われているか Compactionが適切に行われているか Flushが適切に行われているか 上記すべての要因が正常に行われていない とメモリとディスクを圧迫する
  • 13. 監視をするということネットワーク系不具合 Cassandraはノード間のメッセージが10秒 帰ってこないとそのセッションを叩き落 とす ⇒書込みはリードリペアに後を託す メッセージの欠損が発生している場合はrepairを検討 但しrepairは重い処理
  • 14. 監視をするということ Write Heavy はCPUバンド Writeの処理はbloomfilterの演算・Flush・ Compactionなどが入るためCPUを使いまくります。 書 FlushWriter Commitlog MemTable 込 み 命 令 Compaction bloomfilter Manager SSTable
  • 15. 監視をするということ Read heavy はIO・メモリバンド 読 込 MemTable み Cache 命 令 bloomfilter SSTable
  • 16. 監視をするということ Jconsole• JMXの情報取得の基本• JDKに付属している• 目視監視であれば使いやすい
  • 17. 監視をするということ MX4JCassandra起動時にJarを読み込ませることで使用可能。ブラウザでJMXの情報取得や操作が可能に。
  • 18. 監視をするということ OPSCenterDataStax社謹製Cassandraのみを扱う限りはとても使いやすい
  • 19. 監視をするということ Zabbix2.0系からJMXをネイティブサポートCassandra以外も一括管理ができるため運用方法としてはよいかも。※Nagios+RRDtoolもまだまだ使えると思います。(好きなようにgraphを作れるという意味ではRRDToolは捨てがたい。)
  • 20. 監視をするということ監視まとめ 障害のレイヤーがRDBMSとは異なる 気軽にノード障害へ OOMが出た場合は原因に注意 メッセージのドロップが出ていないかを常に監視
  • 21. バックアップをするということバックアップの目的  データリカバリー  オペレーションリカバリー  サーバー移行  監査
  • 22. バックアップをするということ データの整合性に関する考え方 データはこのノードに保存される ハッシュ化:場所確 定 データ {KEY:VALUE}Timestamp:世代確 定 逆説的にデータはこの各ノー ドのデータがどれか一つあれ ば取得できる。
  • 23. バックアップをするということCassandraのバックアップ CassandraのバックアップはSSTableのコピー ※SSTableはWrite Onceなので書込み制限も行 わない Memtable BloomFilter SSTable SSTable SSTable ここをバックアップ
  • 24. バックアップをするということデータリカバリその1クラスター内特定のノードのHDD欠損(バックアップなし) Memtable SSTable BloomFilter SSTable SSTable SSTable Repairコマン ド Memtable 他のノードよりデータを取得 BloomFilter することによりデータリカバ SSTable リ SSTable SSTable SSTable SSTableそのものをコピーする ためネットワーク負荷増
  • 25. バックアップをするということデータリカバリその2クラスター内特定のノードのHDD欠損(バックアップあり) Memtable SSTable SSTable BloomFilter SSTable SSTable SSTable Memtable BloomFilter バックアップSSTableより復旧 古いデータをReadRipairもし SSTable くはrepairコマンドにより復 Memtable 旧 BloomFilter SSTable SSTable SSTable SSTable
  • 26. バックアップをするということデータリカバリその3 キーがストアされてい バックアップSSTableが存在しな るレプリカ分のクラス い場合は復旧不可 ター内のHDD全滅 バックアップSSTableにFlushされ ていないデータはロスト
  • 27. バックアップをするということオペレーションリカバリ 1. 指定のキーで指定のバージョンが格納 されているバックアップSSTableを取得 2. 他のクラスターにリカバリ 3. 希望データを取得 指定のキーが入っ 期待のバージョン ているノードを特 が入っている 定 SSTableのバック リストア Memtable BloomFilter アップを取得 SSTable SSTable SSTable SSTable
  • 28. バックアップをするということサーバー移行 1. 最新バックアップSSTableを取得 2. 他のHWにリカバリ 3. IPを差し替え 4. repair サーバー移行 最新SSTableのバッ 対象ノード Memtable クアップを取得 リストア BloomFilter SSTable SSTable SSTable SSTable
  • 29. バックアップをするということ監査 1. バックアップSSTableを取得 2. S3あたりに流し込みましょう 最新SSTableのバッ Memtable クアップを取得 BloomFilter S3 SSTable SSTable SSTable SSTable
  • 30. まとめ バックアップ  データのある場所を抑える  ノード間でバックアップタイミングをずらしデータの確保を行う  必要なところだけ取得することも可能

×