ファイルサーバー Cohesity DataPlatform 導入記

みなさんこんにちは、はじめまして。
情報システム部の新澤です。

この度、ファイルサーバーとして ”Cohesity DataPlatform” を導入しました。

日本国内でも、バックアップ用アプライアンスとしてはCohesityの事例を見かけるようになりましたが、グリーではファイルサーバーとしての利用、更にCisco社の認証済みハードウェアへの搭載という形で導入しています。

本日は、検証と運用をしてみての感想をお話しさせて頂きます。
わずかながらでも、Cohesityを検討中の方々（主に情シスかな？）のお役に立てれば幸いです。

 

グリーにおけるファイルサーバーの歴史

グリーにおける現ファイルサーバー環境と役割は以下の3つに分類されます。

a. Box
日常的に使うデータ
外部共有が必要なデータ

b. オンプレミスファイルサーバー
クラウドストレージには向かない大容量のデータ
複数人で同時編集が必要なプロジェクトデータ
極秘データ

c. Google Drive
Google のアプリケーションデータ
社内のみでのデータ共有

2015年に、それまでメインで利用していた100TBのオンプレミスファイルサーバーからBoxに移行しましたが、オンプレミスのファイルサーバーの必要性は一部で要求されていたため、オンプレミス環境は30TBの比較的安価なファイルサーバーにリプレイスして残し、これまで運用してきました。

今回、現行のファイルサーバーのEOLだったり、オンプレ要件の増加(大容量のアセットデータをチームで共有したいなど)があったため、機能を見直しリプレイスしました。

グリーでは、ファイルサーバーの秩序維持のため、最上位階層にフォルダを自由に作成できる仕様にはしていません。権限が適正に管理されていることが誰からもわかるように、これまでは、intra-mart上で構築したアプリケーションから、申請制で、必要なフォルダが自動作成される仕組みを提供していました。

今回のリプレイスでは、後述しますが、ServiceNowにて同様の仕組みを実現しています。

※intra-mart : NTTデータ イントラマート社のWebアプリケーションプラットフォーム。先代のファイルサーバ導入当時に、申請画面とワークフローに利用していました。

 

要件

検討中に考えていた必須要件は、オンプレミスストレージ容量の枯渇問題を解決するため、ストレージ使用率が閾値を超えた場合、利用頻度の低いデータをクラウドストレージに移動させる機能を持つことでした。

そのため、クラウドストレージのフロントキャッシュとして、動作することが求められました。

いくつか候補に上がったストレージ製品はどれも要件は満たしていましたが、その中でもCohesityを選定したのは以下の理由からでした。

• REST APIにより外部サービスから操作するためのインターフェースが用意されている
• リファレンスが充実している
• Kubernetesコンテナの利用により、ファイルサーバーにアプリケーションとして機能を追加することができる

 

各種機能について

【ローカル <-> クラウド】

閾値を超えたデータの自動転送 - CloudTier

ローカルクラスタのデータ量が閾値を超えると、クラウドストレージに転送してくれるCloudTier、エンタープライズ向けストレージではよく見かけるようになりました。

もう休日に届く「ストレージがいっぱいです」警告メールに怯えなくていいんです。情シス的にはすごく嬉しいことだと思いませんか！？

ただし「クラウドにデータがあると、レスポンス悪くならない？」という懸念があったため、ファイルがCohesityローカルストレージに存在する場合、クラウドに存在する場合で速度の比較検証を行いました。

ネットワーク構成

ハードウェア

Cohesity : データセンター設置 (上位 Switchに10G接続)
クライアントPC : 社内有線LAN接続(1G NIC)

ネットワーク

Azure to データセンター : Equinix Cloud Exchange Public
データセンター to 社内 : 専用線 2Gbps
社内 : 有線LAN 1Gbps

検証内容

以下の状態で転送時間の比較を行う

1 - Cohesityローカルストレージにデータがある状態で、クライアントPCにファイルをダウンロードする
2 - クラウドストレージにデータがある状態で、クライアントPCに同じファイルをダウンロードする

設定値

・Physical Quota 1GB
物理クォータ上限を1GBにする

・Tier data when not accessed after : [1]days
アクセスされなくなって1日以上経過したデータをクラウドに転送する

・Space Utilization Threshold : 2%
物理クォータサイズの2%を超えた分をクラウドに転送する

(運用環境では、もっと大きな値を設定しています)

この状態でファイルを置いた直後、更に1日以上経過してクラウドに転送された後で、それぞれの速度を計測しました。

予想される結果

クラウドストレージにデータがある場合、Cohesityローカルストレージよりも転送時間が必要とされる。

検証結果

ファイル容量 206MB
Cohesityローカル 3.12秒
クラウド 4.11秒

ファイル容量 890MB
Cohesityローカル 14.2秒
クラウド 20.06秒

所感

Cohesityクラスタを運用する環境、クライアントPCが存在するネットワーク環境にもよりますが、グリーではCohesityを設置したデータセンターと、クラウドストレージをプライベート接続していることもあって、200MB程度のファイルでは大きな差は生まれませんでした。

1GB弱のファイルになると10秒以上の待ち時間が発生します。しかし元々待たされていたので、クラウドにデータが移動していても、体感としては「どっちにしても待ち時間がある」わけで、個人的には気になりませんでした。
待ってる間にでお茶でも淹れてきます。

 

運用自動化のための機能 - REST API

今まで運用していた既存のファイルサーバーでも、申請からフォルダ開設までは自動化がされていましたが、今回のCohesityからサーバー管理にREST APIを利用できるようになりました。

このREST APIは、ユーザーからの共有フォルダ申請にも使っている、ServiceNowからAzure Automationを経由して実行しています。

また、既存のシステムとインターフェースを似たものにすることで、ユーザーの学習コストを低く抑えようと考えました。
同じ情報システム部のメンバーと、協力して作成した申請画面がこちらです。

グリーの運用では、フォルダの上限サイズを1TB以上にした場合、上限サイズごとにプロジェクト負担として利用料チャージが行われます。
このチャージ制により、使ったら使った分だけ払うという公平感と、無駄に使わないという抑止力を持たせています。

管理責任者の他、ファイル共有名、クォータサイズ、アクセス権を付与するユーザーなど指定して申請すると、処理が開始されます。
完了後、Slackで自動通知されると、ファイルサーバーを利用できるようになっています。

ちなみにこちらが既存のファイルサーバ利用申請を行う、intra-martの画面です。

詳細は異なりますが、利用目的、ユーザーアクセス権限、管理責任者を設定するなど、することはほぼ同じなので機能は似通っています。

ServiceNowで構築した新申請画面では、これに利用料チャージ設定が追加になっています。
細かいところですが、ユーザーアクセス権限は、ユーザー追加・削除フィールドが一箇所になりました。更にユーザーアカウント名をコピペや直接入力で一括登録できるテキストフィールドを利用することもできます。
手前味噌ではありますが、これはかなり利便性アップしたと言っていいのではないでしょうか。

公式リファレンス

REST APIを提供しているシステムではよくみかけますが、Cohesityの公式リファレンスでも、curlコマンドを自動生成してもらえます。

ただし、前述のAzure Automation Hybrid Runbook Workerでは、PowerShellを利用して REST API を実行しています。

そのため生成されたcurlコマンドをそのまま転記しても動きません。公式リファレンスを参考に、同じことをInvoke-RestMethodコマンドレットで実装しています。

 

ここは困った / 混乱したポイント

CloudTierのデータ削除時、挙動がゆっくりしていることがある

閾値を超えた分、古いファイルがクラウドに上がり、クライアントからファイルを消せば、クラウドからも消えます。

しかしながら、その消えるタイミングがとてもゆっくりでした。

プロセスの優先順位が影響していたのですが、ファイルを消してもクラウドの使用量が、なかなか減りません。実際に減りはじめるのは数日から2週と、タイミングに開きがあります。

サポートに
「これ本当に動いてます？クラウドストレージ容量がふえるだけで減らないんです」
と問い合わせてしまうほど不安になりました。

たまにREST APIリファレンスに誤りがある

前述のcurl自動生成は、まれにですが記号がURLエンコードされて、そのままコピペしても動作しないものがありました。
注意すればすぐに気づきますが、実行前にはコマンドをチェックしましょう。ぼんやり運用は事故のもと。

 

最後に

実はCohesityの導入は、私がグリーに入社して始めての大仕事でした。

この場を借りて、物理&初期セットアップとAzure Automation Hybrid Runbook Workerを構築してくれた我がIT基盤チームのエース、またServiceNow申請画面をユーザーフレンドリーに仕上げてくれた若き開発スタッフ、そして、右も左もわからない私を引き回してくれた同僚のみなさんに御礼申し上げます。