皆さんこんにちは！
ネットワールドのストレージ担当の片山です。
今回もDPS系のネタになります！皆様Power Protect DD(以後DD)ネイティブで搭載している機能である”Cloud Tier”を知っていますか？
現在はストレージ単体でクラウド連携が可能なことが一般的にはなってきていますが、実はDD単体としてもクラウドへデータ連携をする機能を持っています。操作がシンプルで複雑なことをする必要がないDDですが、私自身もCloud Tierという名前と機能概要は知ってはいましたが、実際のCloud Tierについて取り上げられている情報が少ない？と思ったため、今回はブログ記事として取り上げてみました！
また、今回検証で連携させるクラウドストレージは、Wasabi Hot Cloud Storageです！Wasabiについては情報通な皆様は既にご存じだとは思いますが、もし知らない方は弊社でも取り扱いのあるこちら！WasabiはAWS S3互換のオブジェクトストレージで、直近で、Dell社の製品互換性が確認できるE-lab NavigatorからCloudTier項目で確認するときちんと記載されていました！
機能については名前の通りクラウドへのデータ連携機能ですが、個人的な印象で「使ってはみたいけどクラウドと連携って、お高いんでしょう…？」というイメージがあります。
ですが、なんとDD6400には無償でCloud Tierのライセンスが含まれています！そのため機能としてはすぐ利用することができるんです！残念ながら現時点でのエントリークラスのDD3300やDD6400以外の上位モデルにはライセンスが含まれていないため、その場合は別途購入が必要となります。
＜CloudTierとWasabi検証環境＞
今回は、仮想上に評価版DDVEとWasabiを使ってCloud Tierを検証していきたいと思います！検証環境のイメージ図は以下の通りで、検証環境にはvSphere8.0の評価環境を利用しています。
Cloud Tierを大まかに説明しますと、DDのMtree単位で保存した実データをクラウドへ保存する機能です。その際にローカルのDD上にはメタデータのみ、クラウド上へは重複排除された実データとメタデータの両方を保存し、ローカルのデータ保存領域を節減させることができます。
DDのモデルによりクラウドへの最大保存容量、ローカルのメタデータ保存領域(Cloud Tier)の必要容量も変わってきますので、使ってみたい方はメーカー最新情報をご参照いただく、もしくは是非ネットワールドへご相談ください！
さて、概要説明も終わったところで、そろそろ設定していきましょう！
＜Wasabi側の設定＞
まずは"Wasabi Console"というWebコンソール画面から、バケットを作成していきます。（ほぼAWS S3同等）、Wasabi側のバケット作成に関する操作は割愛しますが、AWS S3などと同様にリージョンやその他オプションを指定してバケットを作成して、事前にルートユーザーまたはユーザーを作成、アクセスキー、シークレットキー情報も控えておきます。Wasabi Console自体は日本語対応で非常にわかりやすいですね！
＜CloudTierの設定＞
次はDD側の操作を実施していきます。Cloud Tierを利用する場合は、先にも説明した通りDD(ローカル)側にもCloud Tierに利用するための専用の領域を用意する必要があります。仮想マシンで作成する場合でも、ユーザーが利用するActiveTierの領域、クラウド領域のメタデータ格納領域として利用するCloud Tierの2つの領域を作成しておく必要があります。
DDVEをデプロイする場合は、デプロイ時のテンプレートのスペックを選択していきます。本検証では選択肢の中で左記に“Cloud“との記載がある【Cloud 6TB Configuration CPUs:4 Memory32GB】を選択しています。
※ VMスペックが不足している場合は、CloudTierは有効化できません
仮想マシンの設定では2つの仮想ディスクを作成しておき、一方は500GBをActive Tier、もう一方は500GBをCloud Tierとして準備しました。画面では容量節約のため仮想ディスクはシンプロビジョニングにしていますが、基本的にバーチャル版の仮想ディスクはシックプロビジョニングでないとサポートされませんので注意です！
DDVEのデプロイが完了しました。IPアドレスなど基本設定等については割愛します。今回は検証が目的なので少な目で500GBｘ２の仮想ディスクを接続しています。１つはActiveTier、もう一つはCloudTierに割り当てるために利用しようと思います。それではDDVE側の設定でDD File System、Cloud Tierで其々500GBを割り当てていきます。
デプロイ直後はFile Systemが存在しないため、【File System】メニューの【Create】のウィザードからFile Systemの作成ウィザードが開始できます。本検証では割り当てた仮想ディスクについてはDDFS（Data Domain File System）には“dev3“を使用、Cloud Tierには“dev4“を追加すると【Enable Cloud Tier】のチェックが自動的に付きます。次にクラウドとの暗号化に使うためのパスフレーズを設定していきます。
作成には少しだけ時間がかかりますが(初期構築であれが2～3分程度)、すぐにFile SystemとCloud Tierの作成が完了します。File Systemのサマリーを確認すると、Cloud Tierという新たなTierが追加されたことが確認できるかと思います。これでクラウドのオブジェクトストレージを指定するためのDD設定であるCloud Unitを追加する下準備ができました。
＜クラウド証明書／Cloud Unitの設定＞
次の設定として、File Systemのメニュー内のCloud Unitタブをクリックします。Cloud Unitとは先にも説明した通りクラウドのオブジェクトストレージでいうバケットのことです。ユニットを追加をするためにはクラウドのルート証明書を追加する必要があります。証明書の入手には「https://www.digicert.com/kb/digicert-root-certificates.htm」というサイトからPEMファイルとしてダウンロードできます。サイト内からRoot CA: DigiCert Global Root G2をダウンロードします。
【Manage Certificates for Cloud】メニューから【Add】から証明書を追加します。
※pemのファイル名にドットが入っているとエラーになったため、証明書の追加前にファイル名を変更しています
最後にCloud Unitを追加していきます。WasabiはS3互換のクラウドストレージなため、Cloud Providerは”AWS S3”ではなく【Flexible Cloud Tier Provider Framework for S3】を選択します。
以降、バケットを登録するための必要情報を入力して、問題なければ【Verify】をクリックして正常であれば【Add】をクリックしてCloud Unitを追加します。（詳細は画像内の入力項目を参照）
＜WasabiへのData-Movement実行＞
Cloud Unitを追加後にはいよいよCloud Tierの設定が可能です。Cloud Tier設定はMtree単位のため、Mtreeの設定を開きます。少し下の方に【Data Management Policy】という設定項目があり、本検証でのDDVEは【All Ages】を選択しました。
この設定では何日前のファイルなどではなく、すべての世代のファイルをクラウドへすぐに移動するというポリシー設定になります。本設定をした上で、スケジュール設定をすることでスケジュールに従って自動的にPolicyに従って、Cloud Tier設定をしたMtree上のファイルはクラウドへ移動させることができます。
※ DD6400では14日間が最小保存日数とDDVE評価版とは異なります
もし手動でクラウドへData-Movementを実行したい場合はコマンドもしくは、GUIで実行することが可能です。System Managerでは【File System】メニューから、左上の[Start]ボタンを実行するとすぐにクラウドへのData-Movement処理が開始されます。
ちなみにCLIでも、“data-movement start”コマンドでも手動での実行が可能です。また、Data-Movementの状況の詳細をチェックしたい場合は“data-movement watch“で確認することもできます。
Data-Movementの時間ですが、インターネット回線とデータの容量次第である程度は時間がかかります。弊社環境では50GBで15~20分ぐらいでした。Data-Movementが完了した後に、実際にWasabi上にデータが保存されているかを確認してみます。
WasabiはS3互換があるため、AWSのフリーツールである"S3 Browser"でも接続することができ、バケットの内容を確認することができますので、S3 BrowserでWasabiへ接続してプロパティで容量を確認してみたところ、DD上でのCloud Tierの容量と一致していますね！きちんとデータがクラウドにも保存されていました。
次に、実際にDD上のMtree上のファイルにアクセスがどうなるかを確認しています。クラウドへMoveされたDD上のMtreeにはファイルの実体はなくメタデータのみになるため、プロパティのファイルの属性情報等はありますが、実ファイルへのアクセスはできませんので、その点はご注意ください。
＜Recallの実行＞
最後に”Recall”を試してみます。その名の通りクラウド上のデータをオンプレミスへ取り戻す処理です。Recallも【File System】メニューに【Recall】ボタンがありますのでクリックしていきます。Recallの単位はMtree単位、もしくはファイル単位でクラウドからデータの取戻しが可能です。検証ではMtree単位でRecallを実行しています。もちろんファイル単位でも可能でした。
RecallにはData-Movementと同様に時間がかかります。Recallが完了すると、実体のファイルがオンプレミスのDD上にも戻ってくるため、ファイルにも読込、書込みできるようになりました。これにてクラウドにあった実体データがきちんとオンプレミスへ移動したことが確認できるかと思います！
さて、どうだったでしょうか？
ハードウェアでのCloud連携というと、動作が複雑で設定の敷居が割と高いイメージがありますが、DD Cloud Tierについては設定が非常にシンプルに扱うことができます！DDはオンプレミスでのバックアップデータ保存先という王道もあるかと思いますが、是非、一度DD機能でCloud連携試してみてはいかがでしょうか！？
また、Cloud Tierでは対応したソフトウェア以外では、基本的にクラウド上のデータにアクセスする場合はRecallをする必要がありますので、Wasabiの場合、容量ライセンスを購入いただければ、Egress、APIリクエストなどの追加費用がかかりません！そのため用途により逐次データをRecallしたりする必要がある場合には、Cloud Tierとは非常に相性がいいと思います！
Wasabiについては、その他にもPowerScaleのCloud Pools連携など、“ネットワールドらぼ“の別記事でも検証していますのでご興味がある皆様は是非ご確認いただければと思います。
また、お問合せなどがございましたら、気軽に製品についての是非！ネットワールド社に一度ご相談ください。
今回の記事が皆様のお役に少しでも立てたら幸いです。
それでは！！
