SB C&Sの最新技術情報 発信サイト

C&S ENGINEER VOICE

Cohesity クラウド連携機能のご紹介 - 第3回 CloudTier編

データマネジメント
2020.03.09

こんにちは。SB C&S 中原です。
連載形式でCohesityのクラウド連携機能をご紹介しています。
Cohesity Dashboardではデータがクラウド / オンプレのどちらにあったとしても分かりやすく扱えるようになっています。クラウド連携機能をひとつずつピックアップしながら、その様子を詳しくご紹介できればと思います。

-------------------------------------------------------------------------------------------
 Cohesity クラウド連携機能のご紹介
  第1回 CloudArchive編
  第2回 CloudRetrieve編
  第3回 CloudTier編
-------------------------------------------------------------------------------------------

今回は「第3回 CloudTier編」です。 CloudArchiveやCloudRetrieveはバックアップに関連した機能でしたが、CloudTierはその名の通り"Tiering(ティアリング)"の機能です。 (CloudArchiveとCloudRetrieveは相互に関連した機能でしたが、CloudTierはこれらとは全く別の独立した機能です。)
まずは機能概要やCloudTierで使われる用語についてご説明し、その後で実際の設定・操作画面をご覧頂きたいと思います。

 

CloudTierとは

連載「かんたんCohesity」第3回でCohesityをNASとして利用できることをご紹介しました。 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が動作しますが、データポリシーが60日(デフォルト)ですと、ここでDown-tierされる可能性があるのはChunk Dのみです。
Chunk A,BはFile-2を成すChunkではありますが、少なくとも2日前にアクセスがあったということになりますのでDown-tierの対象にはならないという訳です。

 

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の容量消費は以下のようになっています。
保存したランダムテキストファイルの容量としては100GiBですが、RF2で書き込んでいますので二重書きされて合計200GiBになっています。 物理クォータが210GiBですから、200 / 210 * 100 ≒ 95%ほど容量が消費されています。 さらに「クラウド層」はこの時点では0bytesになっていることも確認できます。

以降、この環境に対して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 してくれますので、人の手に頼らず運用できるのも嬉しいですね。

 

今回で連載「Cohesity クラウド連携機能のご紹介」は完結です。 お読みくださりありがとうございました。Cohesityは名称に"Cloud"が付く機能が複数ありますので、それぞれの差異など混乱された方もいらっしゃったかもしれません。 本連載がCohesityの機能を活用頂くための一助となりましたら幸いです。

今後も随時Cohesityのブログ記事を更新予定です。「この機能を解説してほしい」といったご要望がございましたら可能な限りご対応したいと思いますので、お気軽にお声がけください。


 

 

※ 今回使用した環境はCohesity Softwareバージョン6.4.0です。サービスや製品の仕様ならびに動作に関しては、予告なく改変される場合があります。

Cohesity関連記事の一覧はこちら

著者紹介

SB C&S株式会社
技術統括部 第1技術部 2課
中原 佳澄