CloudTierとは
CloudTierを利用すると、Cohesityのストレージ領域をクラウドに拡張することができます。(本機能を利用するにはオプションライセンスが必要です。)
頻繁にアクセスがあるデータはCohesityのローカル、アクセス頻度の低いデータはクラウド上に配置するというような使い方ができます。さらにローカル⇔クラウドのデータの行き来はCohesityが自動で処理してくれます。
CloudTierにおいて、Cohesityはデータを以下の3つに分類しています。
・Coldデータ： 指定された期間内にアクセス(Read / Write)されなかったデータ
・Warmデータ：指定された期間内にアクセスされた(または新規作成された)データ
・Hotデータ：外部ターゲットに存在するデータで、アクセスが発生したためにCohesity Clusterのローカルに戻す必要があると判断されたデータ
このうち、「Coldデータ」となったものがクラウドへ送信される対象です。
さて、実際にCloudTierを利用する際には以下の2つの設定の意味を押さえておく必要があります。
・データポリシー(Data Policy)： 前述の「指定された期間」のこと。 最終アクセスからどのくらい時間が経過するとColdデータとみなすかの基準(デフォルト60日)
・しきい値(Threshold)： Cohesityローカルの容量に対する消費容量のパーセンテージ(デフォルト80%)をしきい値とし、これを超過するとColdデータをクラウドへ送信する (物理クォータが設定されている場合はこれに対する消費容量を計算)
加えて、どのような場合にデータがCohesityローカルと外部ターゲットの間を行き来するかも確認しておきましょう。
⬛Down-tier (Cohesityローカルから外部ターゲットへ移動)
データがColdデータになっているか、また「しきい値」を超えていないか4時間ごとにスキャンが行われます。 Coldデータがあり「しきい値」を超過した場合、そのデータはCohesityローカルから外部ターゲットへ移動(=Down-tierが発生)します。 Cohesityローカルの空き容量が増えてしきい値を下回ると、Down-tierは停止します。 必ずしも全てのColdデータがDown-tierされる訳ではないということですね。
■Up-tier (外部ターゲットからCohesityローカルへ移動)
外部ターゲットに存在するデータがHotデータになると、外部ターゲットからCohesityローカルへ移動(=Up-tierが発生)します。短時間のうちに何度もRead / Writeが発生するとHotデータと判定されますが、具体的な判定条件は非公開になっています。
なお、Down-tier / Up-tier はChunk単位で行われます。(Chunkについては以前にこちらでご紹介しました。)
例えばオンプレのCohesityにChunk A,B,Cから成るFile-1と、Chunk A,B,Dから成るFile-2があったとします。
CloudTierの設定・動作確認
いよいよCloudTierを行ってみましょう。 下図のようにCohesityのViewにランダムテキストファイルを配置して、CloudTierの動作を確認してみます。 なお、今回もクラウドストレージとしてAzureのBlobを利用します。
CloudTierの設定はStorageDomain単位で行います。(StorageDomainについてはこちらの記事でご紹介しました。) このため今回はCloudTier用に新しいStorageDomainを作成しました。 (StorageDomainを一度作成した後、削除・名前の変更する場合にはCohesityサポートへ依頼が必要になりますのでご留意ください。)
前述の通り消費したストレージ容量をしきい値としてCloudTierが動作しますので、数値を分かりやすくするため以下のように設定しています。
・「重複排除」や「圧縮」はOFF
・「物理クォータ」で210GiBを設定
・「フォールトトレランス」はRF2を設定 (※RF2についてはこちらでご紹介しました)
今回は動作確認が目的ですので、この時点ではCloudTierもまだ有効化していません。(日本語表示のDashboardでは、CloudTierは「クラウド層」と表示されます。) 単純にCloudTierを行いたいということであれば今の時点で「クラウド層」をONにしてしまってもよいと思います。
さらにこのStorageDomainにViewを作成して前述の通りランダムテキストファイルを配置し、2日以上Read / Write していない状態にしました。
この時点では、このStorageDomainの容量消費は以下のようになっています。
以降、この環境に対してCloudTierを行ってみます。
(0) 事前準備 (Azure Blobの作成、アクセスキーの確認)
事前準備としてAzure側で以下のようにBlob(Hot Blob – Standard)を作成しておきました。
(1) 外部ターゲットの登録
外部ターゲットの登録については「第1回 CloudArchive編」でもご紹介しました。 ただし今回はCloudTier用の外部ターゲットですので、「目的」として「ティアリング」を指定しています。
(2) StorageDomainのCloudTier設定
いよいよStorageDomainのCloudTierを有効化してみます。 なお一旦CloudTier(クラウド層)設定を有効化すると無効化できない点にご留意ください。
設定の有効化は簡単です。 StorageDomainの詳細設定で「クラウド層」のトグルをONにして、手順(0)で登録した外部ターゲットを指定します。
「指定期間内でアクセスされていないデータをティアリング」が前述した「データポリシー」に該当します。 デフォルトでは2月(=60日)になっていますが、今回は動作確認が目的ですので「2日」に設定しました。
(3) ストレージ消費状況の確認
データをDown-tierするかどうか判断するプロセスは4時間ごとに走りますので、StorageDomainの設定更新から4時間以上経ったところで、StorageDomainの状況をもう一度見てみましょう。
青枠がCohesityローカルの消費容量、オレンジ色の枠がCloudTier(クラウド層)の消費容量です。ローカルは200GiBから167.9GiBに減っています。一方でクラウド側は0bytesから11.8GiBに増えているのが分かります。 物理クォータが210GiBですから、現在のローカルの消費容量は 167.9 / 210 * 100 ≒ 79.95% です。 しきい値の設定は80%でしたので、これをわずかに下回ったところでDown-tierの実行が停止されたようです。
また、ローカル・クラウドの合計容量が179.6GiBに減っています。これは手順(0)で外部ターゲット登録時に「圧縮」をONにしたためです。CloudTierに存在するデータが圧縮されたため総容量が減ったという訳ですね。
なお、残念ながらどのChunkがどのタイミングでDown-tier / Up-tier されたかについてはDashboardからは見ることはできません。 ChunkはあくまでCohesityが内部的に扱うデータの単位であり、利用者から見えるものではありませんので、特に確認が必要になる場面は無いということかと思います。
CloudTierの設定・動作確認は以上です。 なお、View内に存在していたファイルについては特に変わったところは見当たりませんし、以下のようにファイルオープンも可能です。
以上、CloudTierの機能や設定方法をご紹介しました。 長期間アクセスされていないデータをパブリッククラウドへ逃がすことでTCO削減が期待できそうです。 また、CloudTier利用開始時の設定だけ行えばあとはCohesityが設定値に基づいて自動的に Down-tier / Up-tier してくれますので、人の手に頼らず運用できるのも嬉しい機能です。