前回、以下の様な構成を作り、ようやくテープ装置のSAN共有状態を作る事が出来た。ということで、SAN共有オプションをBackup Execで使用し、その動きを追跡してみる。

Backup Exec SAN Shared Storage Optionを使用すると、例えばテープデバイスは以下のように見える。

KUNUGIがバックアップサーバ1、SAZANKAがバックアップサーバ2である。上記のとおり、2代に同一構成のライブラリとDATドライブが参照できるかと思う。この中に格納されているメディア情報もきちんと一貫性を保つ形で格納されており、1台のライブラリを2台で共有して動作させたりすることが可能となる。ただ、当方の環境ではライブラリは1ドライブしかないのであまり意味がないんだけれども・・・・・

仕組みはこうだ。

SSOを導入する際、そのサーバはプライマリサーバとして構成するか、セカンダリサーバとして構成するかを選ばされる。これは、上図のようにどこが正情報としてその情報を所有するかを決定している。プライマリサーバにはBackup Execの管理情報DBであるBEDBとメディアカタログ情報を格納したフォルダが配置され、基本的に他のセカンダリサーバはこれを参照するだけとなる。

こうして、プライマリサーバが他のサーバの情報を格納してデバイス情報であるADAMMを単一で保持することによって、デバイス競合状態を回避する事が可能となっている。

ただ、以下の状況が懸念される。

プライマリサーバがダウンすると、想像通りというか、BEDBもカタログ情報も参照できない状態となる。つまり、冗長性は全く担保されていない。それじゃぁ、障害が復旧しないとそのまま死んでしまうの？と言うと必ずしもそうではないようで。以下の対処方法がある。

まず、事前にBEDB保守処理の時間帯を設定しておき、この保守処理が実行された段階で、CatalogsフォルダとBEDB.BAKと呼ばれるファイルを他のサーバへコピーしておく。

Catalogsフォルダ：デフォルトではC:\Program Files\Symantec\Backup Exec\Catalogs

BEDB.BAKファイル：デフォルトではC:\Program Files\Symantec\Backup Exec\Data\BEDB.BAK

サーバが障害となった場合、

• メンテナンスソフトであるBEUTILITYを使用してSecondaryサーバ指定をPrimaryサーバ指定に変更する（図が間違っている）。
• Backup Execサービスを一旦停止する
• BEDB.BAKを使用してDBのリカバリー処理を行い、プライマリサーバのデータをセカンダリサーバに復元する。
• コピーしておいたCatalogsフォルダを自前のCatalogsフォルダに上書きを行う。
• Backup Execサービスを起動する。

と言う手順を踏む事で無事復旧となる。ただ、かなり無理のあるやり方の様で、当方で試したところ両方のサーバがPrimaryとなってしまい、正常動作が出来ない状態となってしまった。おかげさまでいまだにジョブ設定が復旧しきれていません・・・

こうしたSAN共有オプションは相手のストレージが途方もなく巨大な場合に用いられる事が多い。1台のメディアサーバでは管理が困難になる可能性が高く、用途に応じてバックアップサーバを複数立て、SAN共有する事で管理の利便性を引き上げると言うもの。だけど現実には、1台が倒れたら全滅すると言う危険性をはらんでいる事もあり、気軽に使えるツールではないな・・・・と言うのが正直なところ。

余程の理由がない限り用いたくない製品かな・・・・・とは正直思う。