http://capside.com/labs/using-aws-virtual-tape-library-vtl-storage-bacula-amazon-web-services-howto/
で紹介されていたBaculaからAWS Virtual Tape Library(仮想テープライブラリ)にバックアップを保存する方法を日本語に翻訳しました。
Special Thanks to L. Alberto Giménez @sysvalve
今回の記事では、オンプレ側(現在稼働しているデータセンター側)で、Baculaから送られるバックアップデータをキャッシュ、バッファさせる Storage Gateway 仮想マシンをセットアップします
Storage Gateway仮想マシンはデータをVTLサービスにアップロードします。コストパフォーマンスの良いバックアップソリューションを構築しつつ、同時にバックアップデータのオフサイトストレージ(DRサイト)も実現できます。
Baculaとは…
Bacula はバックアップを管理する統合ソフトです。 非常に柔軟性が高く(カスタマイズ可能で)、強力なストレージ構成を実現します。バックアップデータをテープ(シングルドライブもしくはメディアチェンジャを利用して)、もしくはローカルのディスクに保存する事ができます。
Baculaのアーキテクチャは分離したプログラムから構成されていてるので、異なるストレージシステムを統合できます。Bacula ディレクター(管理プログラム)1つで、様々なストレージバックエンドをあつかう事ができます。
仮想テープライブラリ(Virtual Tape Library=VTL)とは…
仮想テープライブラリ (Virtual Tape Library=VTL)は Amazon Web Services Storage Gateway(AWS Storage Gateway=ストレージゲートウェイ)の テープベースのストレージソリューションです。VTLサービスを利用し、バックアップデータをAmazon Glacierにアーカイブすれば、オンプレとAWSクラウド間をシームレスに統合できます。
今回の記事における構成は以下の図のようになります。オンプレ側のデータセンターが1つだけである事が例外となります。 (参考情報(AWS)):
Storage Gateway仮想マシンをオンプレ側に構築すると、データのローカルキャッシュエリアを持つメリットを享受できます。最近のバックアップデータには素早くアクセスでき、(オンプレ側の)データセンターとVirtual Tape LibraryのあるS3ストレージ間のバッファーになってくれます。
Storage Gateway内ではアップロードバッファ用、キャッシュストレージ用でそれぞれ独立したディスクデバイス(HDD等)を割り当てる事が推奨されています。 バッファサイズがパフォーマンスに大きく影響します。バッファの主な存在理由はStorage Gateway-AWS間のネットワーク遅延解消だからです。SANのような環境を持っているのであればRAW iSCSIデバイスを利用することもできます。
BaculaからVTLへのコネクション
ご利用いただくLinuxのディストリビューションに合わせたiSCSI イニシエータツール をインストールします (Debian系では open-iscsi
/ Red Hat系では iscsi-initiator-utils
). 今回はDebianを利用します。
ゲートウェイVTL用に定義されているVTLデバイスターゲットを検出するには、『クライアントから VTL デバイスへの接続,』をご一読下さい。簡略化したやり方は以下です:
#以下のコマンドは利用中のiSCSI 修飾名(IQN)を出力します sudo /sbin/iscsiadm --mode discovery --type sendtargets --portal GATEWAY_IP:3260 # 以下によりはVTL仮想マシンによって手配されたデバイスであるターゲットに接続します sudo /sbin/iscsiadm --mode node --targetname IQN_YOU_GOT_IN_THE_PREVIOUS_COMMAND \ --portal GATEWAY_IP:3260,1 --login
標準では皆様の利用いただいているシステムはデバイスを一般的なSCSIデバイスとして認識しますが、Baculaが正しく動作するためには‘
st
‘ドライバーをロードする必要があります。モジュール名を/etc/modules
以下に追加して変更してください。
lsscsi -g
を実行し新しく追加されたデバイスを確認下さい。
# lsscsi -g [3:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st3 /dev/sg5 [4:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st2 /dev/sg3 [5:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st0 /dev/sg2 [6:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st1 /dev/sg4 [7:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st9 /dev/sg12 [8:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st4 /dev/sg7 [9:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st5 /dev/sg6 [10:0:0:0] mediumx AWS Gateway-VTL 0100 - /dev/sg8 [11:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st8 /dev/sg9 [12:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st7 /dev/sg10 [13:0:0:0] tape IBM ULT3580-TD5 0103 /dev/st6 /dev/sg11
10のドライブとメディアチェンジャ1つを確認いただけていると思います。ストレージとバンド幅のキャパシティが十分確保できるならどのような組み合わせを用いる事も可能です。今回私達は1つだけ利用しますが、お望みであれば全て利用する事もできるのです。 昨今のLinuxはudevを用いてデバイスの自動検出しますが、再起動によってデバイス名が変わってしまう事があります。 Bacula の利用にはデバイス名は固定されている必要があるため、udev のルールをメディアチェンジャに一致させるルールを追記し、固有のデバイス名を定義します。以下の行を /etc/udev/rules.d/80-drivers.rules に追記下さい。
# type 8 のデバイスをミディアムチェンジャとして記載します SUBSYSTEM=="scsi_generic", SUBSYSTEMS=="scsi", ATTRS{type}=="8", ¥ IMPORT{program}="scsi_id --sg-version=3 --export --whitelisted -d $devnode", ¥ SYMLINK+="tape/by-id/scsi-$env{ID_SERIAL}-changer"
これで/dev/tape/by-id/
の下に検出されたデバイスを指し示すリンクが作成されます。
例えば
# ll /dev/tape/by-id/ total 0 lrwxrwxrwx 1 root root 9 Mar 11 14:41 scsi-2414d5a4e5f5347572d454632-changer -> ../../sg8
MTX: チェンジャーヘルパー
Baculaはストレージバックエンド非依存です。Bacula自体はメディアチェンジャの管理やテープへの書込みを知りません。BaculaはUnixの基礎をなす哲学でである “全てはファイルである” をベースとしていて、テープやドライブを管理するためにはヘルパーツールを利用します。バックエンドツールの1つがmtx
で、 メディアチェンジャの制御を実行します。しかしながら、もし恒常的な変更をする場合は(例: テープのロード/アンロード等)Bacula consoleで必ずupload slots
コマンドを実行してください
ステータス
Data Transfer Elements (ドライブ)と Storage Elements (スロット) 一覧を表示して下さい 例:
# mtx -f /dev/tape/by-id/scsi-2414d5a4e5f5347572d454632-changer status | head -n 50 Storage Changer /dev/tape/by-id/scsi-2414d5a4e5f5347572d454632-changer:10 Drives, 3200 Slots ( 1600 Import/Export ) Data Transfer Element 0:Full (Storage Element 1 Loaded):VolumeTag = TAP964B33 Data Transfer Element 1:Empty Data Transfer Element 2:Empty Data Transfer Element 3:Empty Data Transfer Element 4:Empty Data Transfer Element 5:Empty Data Transfer Element 6:Empty Data Transfer Element 7:Empty Data Transfer Element 8:Empty Data Transfer Element 9:Empty Storage Element 1:Empty:VolumeTag= Storage Element 2:Full :VolumeTag=TAP944B31 Storage Element 3:Full :VolumeTag=TAPA44B01 Storage Element 4:Full :VolumeTag=TAPA54B00 Storage Element 5:Full :VolumeTag=TAP5B4AFE [...]
3200のスロットがあり、1600のレギュラーなスロットと1600 Import/Exportスロットがある事に気づくでしょう。これらは 仮想テープシェルフへデータをアーカイブする時、逆に仮想テープシェルフからデータを読みだす時に使われます。
ロード/アンロード
手動でスロット(ストレージエレメント)からテープドライブ(データトランスファーエレメント)にロード/アンロードする事が出来ます。
Baculaが通常のオペレーションを妨害しないよう、最適なドライブで動作しているかどうかご注意ください。
例えば、スロット3にあるテープをロードしてドライブ番号9にロードしましょう。
# mtx -f /dev/tape/by-id/scsi-2414d5a4e5f5347572d454632-changer load 3 9 Loading media from Storage Element 3 into drive 9...done # mtx -f /dev/tape/by-id/scsi-2414d5a4e5f5347572d454632-changer status Storage Changer /dev/tape/by-id/scsi-2414d5a4e5f5347572d454632-changer:10 Drives, 3200 Slots ( 1600 Import/Export ) Data Transfer Element 0:Full (Storage Element 1 Loaded):VolumeTag = TAP964B33 Data Transfer Element 1:Empty [...] Data Transfer Element 8:Empty Data Transfer Element 9:Full (Storage Element 3 Loaded):VolumeTag = TAPA44B01 Storage Element 1:Empty:VolumeTag= Storage Element 2:Full :VolumeTag=TAP944B31 Storage Element 3:Empty:VolumeTag=
アンロードの場合も同じです (引数の順序は同じです):
# mtx -f /dev/tape/by-id/scsi-2414d5a4e5f5347572d454632-changer unload 3 9 Unloading drive 9 into Storage Element 3...done # mtx -f /dev/tape/by-id/scsi-2414d5a4e5f5347572d454632-changer status | head -n 30 Storage Changer /dev/tape/by-id/scsi-2414d5a4e5f5347572d454632-changer:10 Drives, 3200 Slots ( 1600 Import/Export ) Data Transfer Element 0:Full (Storage Element 1 Loaded):VolumeTag = TAP964B33 Data Transfer Element 1:Empty [...] Data Transfer Element 8:Empty Data Transfer Element 9:Empty Storage Element 1:Empty:VolumeTag= Storage Element 2:Full :VolumeTag=TAP944B31 Storage Element 3:Full :VolumeTag=TAPA44B01
mtx-changer ラッパー
mtx
ツールはデバイスを手動管理するのに便利ですが、Baculaにはmtx-changer
と言う良いラッパーが付属しています。(Debianでは/etc/bacula/scripts/mtx-changer
内にあります。)Baculaはmtx-changer
を実際に利用します。
このラッパーは利用者の皆様の個別のニーズにマッチするよう設定いただけるように意図されていますが、ほとんどのチェンジャ利用時はそのまま利用可能です。
VTLの特定のケースではこのラッパーにより1600のインポート/エクスポートスロットをフィルターアウト(除去)する事が出来ます。
Bacula コンソールから直接使いたい場合、(例えば新しいテープを作成したり、仮想テープシェルフからアーカイブ済のテープを回収する際に、VTLがそれを利用な可能なI/Eスロットに挿入する等)このラッパーを多少直接操作する必要があります。今回のケースでは mtx
インターフェースを手動で利用する事でインポート/エクスポートのスロットの変更をします。
Bacula コンフィギュレーション
次にBacula コンフィギュレーションを変更し、新しいデバイスを利用できるようにします。2つのファイルを変更します。
bacula-sd.conf
:実際のストレージバックエンド(Baculaがどのように実際にテープに書き込みを行い、メディアチェンジャを使うか)を設定します。bacula-dir.conf
:Storage
リソースを定義し、テーププールに割り当てます。
Storage デーモン
Storageデーモン設定(bacula-sd.conf
ファイル)内にリソースを作成してStorage デーモンを設定をします。リソースの定義を確認し、その後ディレクティブの意味を説明します。
Autochanger { Name = "VTL Autochanger" Device = Drive-1 Changer Command = "/etc/bacula/scripts/mtx-changer %c %o %S %a %d" Changer Device = /dev/tape/by-id/scsi-2414d5a4e5f5347572d454632-changer } Device { Name = Drive-1 Drive Index = 0 Media Type = ULT3580-TD5 Archive Device = "/dev/tape/by-path/ip-GATEWAY-IP:3260-iscsi-YOUR-IQN-tapedrive-01-lun-0-nst" RemovableMedia = yes; RandomAccess = no; AutoChanger = yes }
オートチェンジャ: ミディアム チェンジャのプロパティー定義
- Name: オートチェンジャデバイスに対する任意の名称(識別名)
- Device: オートチェンジャ内で機能するデバイスリスト(コンマで分かれている)
- Changer Command: Bacula が当該のデバイスから/へ、ロード/アンロードする際に利用されるプログラム
- Changer Device: オートチェンジャを走らせるSCSIデバイス。udev ルールによって作成するシンボリックリンクへの名前を記載します。
デバイス: テープドライブ毎の定義
- Name:このデバイスに対する任意の名称(識別名)
- Drive Index: ドライブのインデックス(
mtx
)が利用します) - Media Type: このデバイスが利用する事の出来るテープの任意の識別名。複数のデバイスリソースに対して同じメディアタイプを指定する事が可能です。(これらが互換性があり、VTLを利用するのであれば)。つまりBaculaは個別のドライブによって読み込まれる特定のテープに紐づくのではなく、任意の仮想テープをロードする事が出来れば、任意のドライブで利用可能です。
- Archive Device: Baculaが実際にドライブに書き込む際に利用するデバイス
- RemovableMedia: 抜き出し可能なメディア(ハードディスクにおけるディレクトリーと対応します)
- RandomAccess: テープドライブは性質上リードとライトを同時に行う事が出来ません。テープの必要な部分まで巻き戻し、前に進める必要があります。
- AutoChanger: オートチェンジャに所属するデバイス
Director
We will add a new Storage
and Pool
resources to the bacula-dir.conf
configuration file:
Storage { Name = VTL Address = storage-daemon.fqdn # N.B. Use a fully qualified name here SDPort = 9103 Password = "password" Device = "VTL Autochanger" Media Type = ULT3580-TD5 Autochanger = yes } Pool { Name = Backup Pool Type = Backup Storage = VTL [...] }
重要なディレクティブ(指示)2つは以下です:
1. ストレージ: ジョブ用のストレージ定義
- Name:
Pool
リソース内で使う任意の名称(識別名) - Address: クライアントが解決可能な IP もしくは ホスト名。この文字列(ストリング)はそのままクライアント(デーモン)に引き渡され、どのストレージデーモンを利用しなければならないかを認識させます。
- Password: ストレージデーモン認証で利用します。
- Device: ストレージデーモン設定内の
Autochanger
リソースに付与した名前。 - Media Type: ストレージデーモン内のオートチェンジャ定義からの
Media Type
ディレクティブと合っている必要があります。 - Autochanger: このストレージがオートチェンジャである事を意味します。
2. Pool: Baculaがバックアップを取る際に利用するテープのプール定義
- Name:
Job
リソースで利用する任意の名称 - Pool Type: 今回は単純に
Backup
を利用します。 - Storage:
Storage
リソースに付けた名称
これで全設定が完了しました。 Pool
リソースを利用する事でAWS VTLストレージバックエンドをバックアップジョブで利用できるようになりました。
まとめ
ご覧いただいたように Bacula は非常にパワフルですしかし一見すると設定が非常に複雑に見えます
(何? テープドライブを使うだけなのに2つの異なるファイル内に4つのリソースを定義を加えないといけないだって?)、と思われるかもしれませんが、それに見合うだけの柔軟性を手にしていただく事が可能なのです。
AWS Virtual Tape Library はBaculaのバックアップ先として最適です。
AWS VTLにより、ローカルのアクセスし易い(ローカル側のVLTアプライアンス内のキャッシュバッファ内の)データを持ちながら、同時に安全なクラウドベースのリモートオフサイトバックアップを保持する事が出来ます。またGlacierを利用する事でコスト削減をする事も可能です。