【Commvault】意図しない残存ジョブによりライブラリが逼迫した話

こんにちは、キクです。

先日、Commvaultに登録しているライブラリの空き容量が逼迫していました。
そこで、取得済みジョブの一覧を確認してみると明らかに古いジョブが残っていました。

エージングされるはずのジョブがなぜ残存しているのか？

本記事ではそんな体験の内容を整理していこうと思います。
というわけで、今回は『意図しない残存ジョブによりライブラリが逼迫した話』をテーマに書いていきたいと思います！

それでは、よろしくお願いします。

ちなみに、今回の内容は僕がこれまでCommvaultに触れてきた経験から「こんな動きをしているのではなかろうか」という推測となりますのでご了承ください。

はじめに

冒頭でも触れた通り、今回発生した事象としては「削除されるはずのバックアップジョブが削除されずに残っていた」というもの。

通常であれば、取得された各バックアップジョブはストレージポリシーに設定された保持サイクルによって世代管理されるものですが、今回は一部のジョブでそれが機能していませんでした。
その結果、本来存在しない（ = 削除されている）はずのジョブがリソースを消費してライブラリが逼迫してしまったわけです。

具体的には、以下の図のような状況になっていました。

詳細については後ほど触れますが、対象サブクライアントのバックアップサイクルを考えると、一週間で1サイクルのジョブが取得され、設定した世代以上のジョブが保持された段階で一番古い世代のジョブは削除されるはずでした。

しかし、実際には明らかに古い「一ヶ月以上前のジョブ」が残っていることが分かります。
その上、1世代すべてではなく、増分ジョブが2つだけ残っているという中途半端な状態でした。

なぜこのような状態になってしまったのか？

そこにはAUXコピーが深く関与していると考えています。

背景

今回の事象が発生したライブラリでは、データ移行対応としてAUXコピーを実施していました。

本記事の本題からは外れるので詳細は割愛しますが、以下のステップでデータ移行をしていました。

1. 移行先ライブラリBの登録
2. 移行先ライブラリBをストレージポリシーに「同期」として登録
3. AUXコピー（1次 → 同期）の実施
4. ストレージポリシータイプ「同期」の昇格
5. 様子見期間（一ヶ月程度）
6. ストレージポリシータイプ「同期（ = 旧1次）」の削除
7. 移行元ライブラリAの削除

今回の事象が発覚したのは、上記の「5. 様子見期間」のタイミングでした。
つまり、以下のような状態ということになります。

AUXコピーとは

AUXコピーについてですが、こちらは以前書いた記事で同じ内容をご紹介しているので、気になる方はそちらも読んでみてください。

関連記事：【Commvault】AUXコピーで発生したジョブ数不一致の謎

要点だけお伝えすると、AUXコピーとはCommvaultの機能の1つで、同一ストレージポリシーに登録された｢1次 / 同期｣の関係を持つライブラリ間でデータを同期(コピー)することができる機能になります。

なぜエージング対象ジョブが残ってしまったのか（考察）

ここからは「エージングされるはずのジョブがなぜ一部だけ残ってしまったのか」について触れていきます。

以下は対象サブクライアントのバックアップ取得設定になります。

上記スケジュールの場合、一週間で1サイクル（フル：1個 / 増分：6個）のジョブが取得され、3世代目のフルバックアップが取得された段階で1世代目のジョブがエージング対象になります。

しかし、既に触れている通り今回は1世代目の一部ジョブ（増分：2個）だけがエージングされずに残っていました。
以前の記事でも触れたのですが、AUXコピーに関連するジョブは状況によってエージング対象から外れることがあります。

例えば「1次側のジョブが同期側に部分的にコピーされている状態の場合、そのコピーが完了するまでエージングされない」などです。
今回もそれに近い事象に該当しているのではないかと考えました。

下図は1次側と同期側に保持されているジョブの全容になります。

今回残存してしまったジョブは「増分#1-5」と「増分#1-6」になりますが、これに対応する同期側のジョブを確認すると｢コピー予定｣となっています。
それ以前のジョブについては、1次側ではエージングされて残っていませんが同期側では｢使用可能｣として残っています。

ここから次のような仮説を立てました。

しかし、この仮説では問題があります。
それは｢AUXコピー実施後に取得されたすべてのジョブが残り続けてしまうことになる｣ということです。
実際には4/23(日)～5/27(土)までのジョブは世代管理に従ってエージングされているので、単純にコピー予定となっているジョブのソースジョブがエージング対象外となるわけではなさそうです。

ここで、ひとまず想定通りエージングされているジョブの処理サイクルを整理してみます。

1. 新規バックアップジョブが1次側に保存される（使用可能）
2. 同ジョブの情報が同期側に｢コピー予定｣として認識される
3. 1次側に3世代保持された段階で、1次側にある1世代目のジョブがエージングされる
4. 上記3に伴い同期側の｢コピー予定｣ジョブもコピー対象から外れる

これらの処理サイクルと残存ジョブの違いは何なのか？

次のような仮説を立てました。

少しややこしいですが、｢同期側の使用可能ジョブが邪魔しているのでは？｣ということになります。
この仮説2を実証すべく以下の作業を実施しました。

1. 同期側の｢使用可能｣ジョブを削除
2. データエージングを実施

結果としては、想定通り1次側の残存ジョブのエージングに成功しました。

処理内容まとめ

今回の1次側に残っていた残存ジョブは2段階のいわば「ロック状態」になっていたと考えられます。

1. 同期側の「使用可能」ジョブとそれ以降の同世代ジョブ（コピー予定）がロック状態となる
2. ロック状態のコピー予定ジョブが同期側にあることで、1次側のソースジョブもロック状態となる

作業1で同期側から｢使用可能｣ジョブを削除したことで、同世代の｢コピー予定｣ジョブのロックが解除され、それに伴い1次側のソースジョブ（残存ジョブ）もエージング可能な状態になったと考えられます。

そして、1次側では残存ジョブも含めて3世代のジョブを保持しているため、この状態で作業2のエージングを実施したことで残存ジョブが削除されたと考えられます。

今回の反省と教訓

自分事で恐縮ですが、今回の反省と教訓について記しておこうと思います。

今回AUXコピーの1次 / 同期切り替え後には、1ヶ月の様子見期間を設けていましたが、1次および同期のジョブ保持状況を日々確認することはしていませんでした。
そのため、削除されるべきジョブが残存してしまっていることに気付くまでに時間がかかってしまいました。

また、残存ジョブによってライブラリのリソースが余分に消費されている状態でした。
様子見期間を設けること自体は問題ありませんが、移行完了後も定期的にジョブの保持状態等を確認して、残存ジョブの発生など予期せぬ状態になっていないかを確認することが大切だなと感じました。

事前に全ての動作を把握することは難しいですが、今回の経験を経て「ロック状態になるかもしれない」といった可能性も考慮しつつ、今後は作業していければと思います。

おわりに

いかがだったでしょうか。

今回はCommvaultでのエージング対象想定ジョブの残存がテーマでした。

単純に「様子見期間」として考えていたのに、気付いたらリソースが逼迫気味になっていたのは焦りました。

しかし、そのお陰でジョブ同士が見えない繋がりを持っているということを意識する良い機会になりました。
今回はたまたまジョブが残っていることに気付くことができましたが、日々ジョブの取得状況に目を向けることも大切だなと改めて感じました。

本記事を最後までお読みいただき、ありがとうございました。
ではでは！