9. Cassandra の運用¶

• フラッシュに成功した場合

  通常期待される状態です。フラッシュが実行されているためデータ損失はなく、当然ながら対策を検討する必要はありません。
• フラッシュに失敗した場合

  通常は計画停止した場合はフラッシュが実行され停止時のデータが担保されますが、停止時にフラッシュが失敗する場合があります。

  フラッシュが正常に実行されていないため、メモリ上に存在していたデータが失われます。

• フラッシュが実行されていた場合

  異常停止前にフラッシュが実行される場合があります。

  フラッシュが実行されているためデータ損失はなく、当然ながら対策を検討する必要はありません。
• フラッシュが実行されない、または失敗した場合

  異常停止前には通常フラッシュが実行されません。また、実行されても失敗する可能性があります。

  フラッシュが正常に実行されていないため、メモリ上に存在していたデータが失われます。

コラム

計画停止、異常停止に関わらず、フラッシュ失敗によるデータ損失のリスクが存在します。

• 単一ノードにて構築されている場合

  Cassandraが復旧するまでIMBoxは利用できなくなります。

  コラム

  単一ノードにて運用する場合は、ネットワークが分断した時点で読み込み/書き込みが行えなくなるため、データ損失は発生しません。
• クラスタ構成で構築されている場合

  ネットワークから分断されたノード数により状況が変化します。
  • サービス継続が可能な台数の場合

    例えば「ノード数が３台（レプリケーションファクタが３）」で運用中に１台が分断された場合、サービスは他の２台のノードで正常に行われます。

    分断されたノードが再度ネットワークに接続されたタイミングで不足分のデータがレプリケート（コピー）され、通常の運用状態に復旧します。
  • サービス継続が不可能な台数の場合

    Cassandraが復旧するまでIMBoxは利用できなくなります。

    例えば「ノード数が３台、レプリケーションファクタが３」の場合に２台が分断された場合、サービスが利用不可となります。

    サービスが利用不可になり読み込み/書き込みが行えなくなるため、データ損失は発生しません。

コラム

この対策はあくまでもデータ損失の確率や損失量を軽減する対策になります。

フラッシュ に関してはこちらを参照してください。

コラム

フラッシュ実行の頻度については、運用設計にて要求される条件との調整が必要です。

検討が必要な項目として、以下が考えられます。

• データ損失の可能性が許容される最大の時間
• フラッシュの定期実行によるI/O負荷増加によるサービスのレスポンスやサーバ負荷への影響

• ノード数が２台の場合

  クラスタを構成するノードが２ノードであった場合には、いずれか１ノードが停止した時点でサービスの継続（データの読み込みおよび書き込み）が不可能となります。

  ただし、サービス継続不可能となった時点でデータの書き込みは行われないため、データの損失は発生しません。
• ノード数が３台（またはそれ以上）の場合

  クラスタを構成するノードが３ノード（およびレプリケーションファクタが３）であった場合、いずれか１ノードが停止してもサービスは継続可能です。

  停止したノードが復旧したタイミングで、停止していたノードに対して不足しているデータがレプリケート（コピー）され、レプリケート終了時に通常の運用状態に復旧します。
  ３ノードのうち２ノードが同時に停止した場合にはサービスが継続不可能となりますので、１ノードが停止した段階で復旧処置を行う必要があります。

  ただし、サービス継続不可能となった時点でデータの書き込みは行われないため、データの損失は発生しません。

コラム

専用のジョブ（ジョブネット）を実行することで復元可能です。

詳細については、「 IMBox 仕様書 」-「 ジョブスケジューラ 」を参照してください。

コラム

添付ファイルについてはファイルシステム（PublicStorage）上に保存されているため、システム管理者による復旧が可能です。

添付ファイルの保存先については、「 IMBox 仕様書 」-「 添付ファイル保存先 」を参照してください。