Tiger Bridgeは本ブログの記事「Tiger Bridgeって何？」にあるようにクラウドオブジェクトストレージと密に連携に特徴を持つバックアップソフトウェアです。強みとしてクラウドオブジェクトストレージとの連携がありますが、それ以外にもストレージ管理のための多くの機能を備えています。本記事は「Tiger Bridgeって何？ その２」として「Tiger Bridgeって何？」では伝えきれなかった以下の機能について説明します。
- ペアリングとポリシーの関係
- Global Policyと個別ペアリングのPolicyについて
- Replication（データ複製）とReclaim space（スペースの再利用）の動作
- スタブファイルのOn demand Retrieve（データアクセスによる自動書き戻し）
- 個別ポリシーによるGlobal policyの上書き動作
本記事を読む前に本ブログの記事「Tiger Bridgeって何？」を参照されるとより理解は深まると思います。
ペアリングとポリシーの関係
Tiger Bridgeは下図のように複数のSource StorageとTarget Storageをペアリングすることができます。
この図が表しているTiger Bridgeの機能、特徴を以下に挙げます。
- Source StorageとTarget Storageのペアリングは複数設定することが可能です。
- Target StorageにはペアリングごとにNAS, Local Storage, Cloud Storage等の複数種のストレージを設定することが可能です。
- ペアリングが異なれば、ペアリング毎に異なるCloud Storageを設定することが可能です。この場合に置いては、AWS S3とMicrosoft Azure Blob Storage等の異なるサービスプロバイダーを混合で設定することが可能です。
- ペアリングごとに異なるポリシーを設定することができます。
- ペアリングごとのポリシーとは別にすべてのペアリングに共通なGlobal Policyを設定することが可能です。
ペアリングとポリシーの設定例
ペアリングとポリシーの例として３つのSource Storageを２つの異なるサービスプロバイダーのクラウドオブジェクトストレージと、１つのLocal Storageとペアリングし、ポリシーを設定してみます。
以下のブロック図が今回設定した構成です。Eドライブ上の３つのフォルダー（E:¥Source01, E:¥Source02, E:¥Source03：以下それぞれをSource01, Soource02, Source03とします）をSorurce Storageとして、それぞれをAWS S3、Wasabiオブジェクトストレージ、ローカルディスクのF:¥Target03（以下Target03とします）とペアリングします。
3つのペアリングに対して全体にGlobal PolicyとしてReplication Policy（データの複製）を設定し、Source01にはReclaim space policy（スペースの再利用）、Source03にはReplication policyを設定します。Global PolicyとSource03は同じReplication policyですが、データ複製の契機（アクセスがない時間）をそれぞれ3分と10分の異なる時間に設定してます。Replication policyとReclaim space policyの詳細については本ブログの記事「Tiger Bridgeって何？」を参照してください。
このブロック図に基づいたTiger Bridge Configurationの設定は以下のようになります。GUIを使用してそれぞれのペアリングとポリシーの設定を行いました。ブロック図と比べてみてください。ペアリングとそれらに伴うポリシーの設定をこのように実現することが理解できたと思います。
次の項目からはこれらの設定でどのような動作が行われるか説明します。
Global Policyと個別ペアリングのPolicyについて
前項のブロック図の説明のところでGlobal PolicyとSource03は条件が異なるReplication policy（複製）を設定したことを説明しました。また、Source02とWasabiオブジェクトストレージのペアリングにはポリシーを設定していません。
Global Policyはすべてのペアリングに対して共通の設定になります。従ってSource01, Soource02, Source03すべてに対して原則有効です。ただし、この原則には例外があります。それがSource03の設定です。Global Policyと個別のペアリングのポリシーに同じものが（この場合はReplication policyを設定）設定されている場合は個別ペアリングの設定が上書きされ優先されます。今回の設定の場合は以下のような動作になります。
- Source01：3分間更新されないファイルをターゲットに複製します（Global policy）、10分間アクセスがないファイルをスタブファイルに置き換え、ソースストレージ上の領域を解放し、再利用可能な状態にします。（個別ポリシー）
- Source02：3分間更新されないファイルをターゲットに複製します（Global policy）
- Source03：30分間更新されないファイルをターゲットに複製します（個別ポリシーがGlobal policyに優先します）
この環境を使用してそれぞれのポリシーの動作を説明します。
Replication（データ複製）とReclaim space（スペースの再利用）の動作
Replication（データ複製）とReclaim space（スペースの再利用）の動作をSource01とSource02を例に動画を使って説明します。
- Source01とSource02のターゲットであるAWS S3とWasabiオブジェクトストレージが空であることをAWS CLI1で確認します。
- Souce01 とSource02のそれぞれにファイルを16時12分にコピーします。
- Global policyの設定（３分更新が無ければターゲットにReplication：複製）がSource01とSource02で実行されます。（16時15分）
- ターゲットのAWS S3とWasabiオブジェクトストレージに複製ができていることを確認できます。
- Souce01に設定しているReclaim space policy（ファイルにアクセスがない場合は10分後にスペースの再利用）が実行されます。（16時22分）
- Reclaim space（スペースの再利用）が実行されたSource01のファイルのディスク上のサイズは0バイトになります。Source02は複製のみなので、ディスク上のサイズも300MBのままです。
動画の中で説明していますが、Tiger Bridgeをインストールするとファイル、フォルダーのアイコンにファイルの状態を示す以下の印が付与されます。
- Replicationされたファイルとフォルダーには緑にチェックの四角が付与されます。（16時22分以降のSource02のファイル、または、下図の左）
- Reclaim space（スペースの再利用）の状態でディスク上のサイズが0バイトのフォルダーとファイルには青に十字の四角が付与されます。（16時22分以降のSource01 のファイル、または、下図の右）
スタブファイルのOn demand Retrieve（データアクセスによる自動書き戻し）
前述のようにSpace Reclaim（スペースの再利用）により生成されたスタブファイルはディスク上のサイズは0バイトであり、そのままでは編集やコピーの対象にすることはできません。
Tiger Bridgeはアプリケーションからのファイルアクセスを常時モニターし、ファイルアクセスがあった場合に自動的にターゲットからソースに対して当該ファイルのみを書き戻す（Retrieve）機能を持っています。この機能により、ユーザーはスタブファイルであることを意識せずにファイルにアクセスすることが可能です。
スタブファイルに対してコピーペーストでアクセスした場合に自動的に被コピーファイルがターゲットストレージより書き戻される動作（On demand Retrieve）を動画を使用して説明します。
- Explorerで、1つのスタブファイル（300MBC2）をコピーし、同じフォルダー内でペーストします。この処理の際、当該ファイル（300MBC2）はアプリケーションよりアクセスされたことになり、Tiger Bridgeにより自動的にターゲット（Wasabiオブジェクトストレージ）から書き戻されます。
- ファイル300MBC2をTigerBridgeがターゲットから書き戻しているので、イーサネットの受信速度が200Mbps以上を示しています。
- 300MBC2のファイルはターゲットから書き戻されたので、複製されたファイルを示す緑の四角がアイコンに付与されます。（動画中では緑のアイコンと呼んでます）書き戻されているので、300MBC2のファイルのディスク上のサイズは300Mバイトになっています。
- コピーペーストの処理が問題なく行われたので、新しいファイル（300MBC2 – コピー)が同じフォルダー内に生成されました。
個別ポリシーによるGlobal policyの上書き動作
前述の「Global Policyと個別ペアリングのPolicyについて」でGlobal policyと個別ペアリングのポリシー（以下個別ポリシーとします）に同じポリシー（たとえばReplication policy）を設定した場合は個別ポリシーを優先（上書き）することを説明しました。
上図の設定では、Source02は個別のポリシーを設定していないのGlobal policyが有効になり、ファイルの更新3分後にターゲットに当該ファイルがコピーされます。Source03は個別ポリシーでファイル更新後30分でターゲットに複製するように設定しているので、Global policyを上書きし、30分が有効になります。各ポリシーの動作の様子を動画で説明します。
- 16時8分に空のSource02とSource03のフォルダーに100MBのファイルのが3つ入ったfolder300MBをコピーします。
- Source02は個別ポリシーを設定していない、Global policyが有効になり、データ更新（コピー）の3分後である16時11分にターゲットに複製されます。
- AWS CLIでターゲットのWasabiオブジェクトストレージの内容を見るとファイルの複製ができていることがわかります。（WasabiオブジェクトストレージはAWS CLIに対応しています。2）
- Source03は個別ポリシーがGlobal policyを上書きするので、データ更新（コピー）の30分後である16時38分に複製されます。
- Source03のターゲットストレージはローカルディスクのF:¥Target03に設定しています。そのF:¥Target03のフォルダーを確認するとデータのン複製ができていることを確認できます。
YouTube MIC Associatesチャンネル
本記事と連動した動画をYouTube MIC Associatesチャンネルにアップロードしています。この記事と合わせて閲覧するとより理解が深まると思います。
字幕を表示してご覧ください。
| 00:00 | Tiger Bridgeの概要説明 |
| 01:06 | ペアリングとポリシー |
| 04:22 | ポリシーの動作（Replication, Reclaim space） |
| 07:30 | スタブファイルのOn demand Retrieve |
- AWS CLIについては本ブログの記事「AWS CLIとは？」を参照してください。 ↩︎
- WasabiオブジェクトストレージのAWS CLI対応については本ブログの記事「WasabiにもAWS CLI」を参照してください。 ↩︎
