« Acropolis ファイルサービス(AFS)でのデータの分散について | メイン | Nutanix上でのインライン圧縮のパフォーマンスへの影響とオーバヘッドは? »

2017/03/15

Nutanix Acropolis ファイルサービス(AFS) : 設計からみたパフォーマンスと拡張性

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSr Solutions Performance EngineerであるDan Chiltonによるものです。原文を参照したい方はNutanix Acropolis File Services (AFS): Performance and Scalability by Designをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。本ブログのNutanix関連記事のまとめページはこちら

Fig186

Nutanixは最近Acropolis オペレーティングシステムの ヴァージョン 5.0 をリリースし、それとともに素晴らしいNutanixの製品機能 —Acropolis ファイルサービスまたは短くAFSが正式リリースされました。この新機能はNutanixプラットフォームにアプリケーションのように展開する事が可能です。この機能は堅牢な、エンタープライズでの利用を想定したSMBファイル共有ソリューションをNutanixクラスタ上に展開するというものです。Nutanixプラットフォーム内でこの機能を提供することで、別に単独で動作しているネットワークアタッチドストレージ(NAS)ソリューションをWindowsやSMBファイル共有のために維持していく必要はなくなります。

AFSはクラスタ化された、分散ファイルサーバでNutanixプラットフォーム上で動作するいくつかのファイルサーバ仮想マシンのグループとして動作しています。AFSはその柔軟な設計内にパフォーマンスの拡張性を備えています。ストレージのパフォーマンスを増強する必要がある場合には、AFSは容易にスケールアウト、又はスケールアップすることが出来るうえに、動的なロードバランシングの機能も備えています。AFSの更に奥深い詳細な機能とアーキテクチャについては我々の技術メモをご参照ください。

以下のようなワークロードはNutanixの設計したAFSで動作させるのに上手く合致しています。

  • Windowsユーザーのホームディレクトリ
  • 仮想化デスクトップユーザーのリモートプロファイル
  • 組織の共有領域
  • アプリケーションの共有領域

この記事では、ファイルサーバのパフォーマンス要件と検証方法、そしてAFSがこれらの要件に何故合致し、それ以上のものであるかをお伝えしていきます。

お客様がもっとも知りたいと考えるものの一つが、どんなときにファイルサーバソリューションを検討すべきで、それがどのように動くかというものがあります。私は日々の業務の中でソリューションのパフォーマンスについてお話する事が多い人間ですが、これがどんなに重要かということはよくわかります。ですが、この質問にお答えする前に、我々はまず最初にこのソリューションでお客様が何をしたいのか、ということを理解しなければなりません。お客様がファイルサーバとどのようにワークロードをやり取りするのかということです。

以下はワークロードの例です:

  • ファイルサーバへ1つの巨大なファイルを毎回コピーする
  • ディレクトリ内のファイルのリストを眺め、必要なファイルを読む
  • ファイルをファイルサーバからローカルクライアントのデスクトップへダウンロードする
  • マイクロソフトのWordで文書を編集し、その後に文書を保存する
  • 複数のユーザーが仮想化デスクトップへとログオンするが、そのリモートユーザープロファイルがファイルサーバ上に保存されている

我々は開発とリリースのサイクルを通して、こうしたワークロードや他のワークロードに対するパフォーマンスをテストするツールを利用しており、我々がターゲットとしているユースケースでパフォーマンスが高いことを保証しています。最初のワークロードについては我々はrobocopyつまりコピーアンドペーストを利用しており、2番目から4番目まではMicrosoft File Service Capacity Tool またの名を FSCT、そして 5番目には LoginVSIを利用しています。 

単独ファイルコピーテスト = パフォーマンステストとしてはお粗末

ファイルコピーは非常に簡単なテスト(大きなファイルをコピーアンドペーストするだけ)ですが、これはワークロードがシングルスレッドであるため、発行されるI/Oが多くなく、ファイルシステムのパフォーマンスを測るにはお粗末です。これはファイルコピーのテストではファイルサーバが何を行っているのかを正確にはテストできないという事を意味します。

大抵、現実世界で起こりうる状況としては多くのクライアントもしくはアプリケーションがデータを同時にリクエストしてくるというワークロードが発生します。これは単に私が行っているというだけではなく、MicrosoftのOneDriveチームメンバーであるJose Barrero氏のこのディスカッションを見てみてください

なぜ FSCTをつかうのか?

FSCTはMicrosoftによる実際のユーザーのホームディレクトリでの操作の分析をベースとしたパフォーマンステスト郡です。MicrosoftやNetAppそしてEMCなどのファイルサーバのベンダーがそのパフォーマンスを証明するものとして利用されてきました。FCSTが顧客ユーザーホームディレクトリ環境のシミュレーションを行うという点で優れているポイントは:

Windowsドメインコントローラー、クライアント、ユーザーアカウント、認証、そしてパーミッションなどのアクティブディレクトリ統合を検証してくれます。

  • ユーザーは複数のサブディレクトリのあるホームディレクトリ(270のファイル、フォルダ、~80MBのデータ)に接続
  • ユーザーはファイルサービスのメタデータを作成するシナリオを実行
  • コマンドラインによるファイルのダウンロード/アップロード、Windows Exploererによるファイルの削除、ドラッグ・アンド・ドロップ、MS Wordファイルの開閉、そして保存
  • スループットはIOPSやFileOPsではなく、同時実行ユーザー数で計測されます

我々はAFSがユーザー数が増えるに従ってスケールアップしていくホームディレクトリのためのソリューションであることを発見しました。

  • FSCTの検証から、我々はファイルサーバに制限を設け、必要に応じてファイルサーバ仮想マシン(FSVM)をスケールアップさせることで堅牢性を実現しました。
  • 我々はこのデータをNutanixサイジングツールへと翻訳し、サイジングに関する品質と将来の増強に合わせた幾つかの空き領域もご提案するようにしました。
  • 以下のチャートは単一のAFSファイルサーバノードが同時にヘビーユーザーのワークロードをこなすための能力を示しています。

Fig187

AFSソリューションは最低3つのVMから初められますが、我々は16ノードのクラスタ上の16のAFS仮想マシンへとスケールアウトする検証も上手く行えています。AFSの機能はストレージのキャパシティが余っているところへ追加、もしくは完全にスタンドアローンのファイルサーバクラスタとしても利用が可能です。

小さな4vCPUと16GBメモリのAFS仮想マシンのノードから数千ユーザーがAFSノード全体に分散で負荷をかけるような環境までスケールアウトすることが出来ます。

Fig188

何故 LoginVSIなのか?

我々はLoginVSIをよく利用される、業界標準のVDIサイジングツールとして構成し、仮想化デスクトップユーザーのリモートプロファイルがAFSソリューション上に配置されるようにしています。また、我々はCitrix Profile Management、堅牢なエンタープライズVDI環境のスイートも利用しています。ワークロードはWindows OS自身の操作とMicrosoft Outlookを含むようにしています。

VDIプロファイルとしてはAFSはほとんどの場合ブートのフェーズで利用が行われます。デスクトップがブートしてしまえば、ほとんどCPUとメモリの利用に変わります。ということになりますから、AFSはパフォーマンスの評価としては平均ログイン時間を主な評価軸として利用しています(もちろん、ログオン時間なので短いほうが良いわけです)。我々はローカルのC:\ドライブに格納するよりも、AFSのファイルシェアにクライアントが接続して、プロファイルをブート時に読み込むことでログオン時間が改善することを見たいと思っていました。

結果としては最小構成のAFSクラスタでも400仮想デスクトップ環境を容易にサポートできることがわかりました。以下の図をご参照ください。ローカルのC:\ドライブのログオン時間は7.2秒でしたが、リモートに保存されたプロファイルでは6.8秒に短縮されています。(念のためですが、LoginVSIの仮想化デスクトップの平均ログオン時間を単一のI/Oの応答時間とは混同しないでください。そちらはたいていミリ秒やマイクロ秒の単位です。)

Fig189

なぜAFSを選ぶべきなのか? 設計から見たパフォーマンスと拡張性

  • スケールアウト—AFSは設計レベルで最低3ノードでクラスタ化されており最大で16ノードまでをサポートしています。サイズに関係なくワークロードはNutanixクラスタ全体に分散されます。ストレージやコンピューティングリソースを追加するために更にファイルサーバ仮想マシンを追加することも出来ます
  • スケールアップ—特定のファイルサービスのワークロードには多くの処理能力(CPU)やキャッシュ(メモリ)が必要であるため、AFSのノードは追加のvCPUやRAMを追加して要件に合わせてスケールアップすることが可能です
  • ロードバランシング–ファイルデータが成長するのに合わせて、ストレージや処理の要求は特定ホストへの負荷集中(ホットノード)を生じさせます。AFSではこの問題をデータと処理をノード間でリバランスすることで容易に解決できます
  • 分析ベース—よく練りこまれた分析エンジンがAFSに組み込まれており、ファイルサーバ上で継続的にストレージとパフォーマンス消費の分析を行います。この分析からAFSはスケールアウト、スケールアップもしくはリバランスの必要性を推奨します。この機能は管理の時間とパフォーマンスのためのトラブルシュートを削減しTCOの低減を実現します。

我々の検証はAFSに柔軟性があり、クラスタとして設計されているため、SMBファイル共有について最高レベルの要件を持つようなエンタープライズが必要とするパフォーマンスと拡張性を、別に単独でNASアプライアンスを購入すること無く提供できることを示唆しています。Nutanixパートナーへ相談してAFSのデモを見せてもらい、ファイルストレージとその管理を我々に預けることをご検討ください。

もしもNutanixについてあまり知らないのであればNutanixのエンタープライズクラウドプラットフォームがあなたのIT環境にとってどんな効果をもたらすのかという会話から始めあせてください。info@nutanix.comへメールをくださっても構いませんし、 Twitter をフォローするか、 コミュニティのフォーラムへぜひご参加ください。 

Disclaimer: This blog may contain links to external websites that are not part of Nutanix.com. Nutanix does not control these sites and disclaims all responsibility for the content or accuracy of any external site. Our decision to link to an external site should not be considered an endorsement of any content on such site.

記事担当者: マーケティング本部 三好哲生 (@Networld_NTNX

Ntc2017_2

前回に引き続きAFSの記事となります。AFSってファイルサーバとしてどのぐらいツオイの?コスパどうなの?こうしたところに注目が集まりますので、本当にタイムリーで良い記事だと思い、翻訳させてもらいました。読んでみていただいて分かる通りAFSは超強力なファイルサーバで最低構成でもVDI 400ユーザーの性能が十分に出てしまうほどです。(しかもNutanixのハードウェアの性能はx86サーバの性能とイコールですから、どんどん性能が上がっていき、値段も下がっていきます)

考えてみるとこれまで幅広く使われてきたファイルストレージにはx86サーバには入ってないような特殊な部品が幾つかあり、それは高値安定の希少部品でした。Nutanixは(もちろんFlashデバイスの進化という追い風もありますが)そうした希少部品と同じもしくはそれ以上の性能を大量生産部品(CPU/Memory/SSD/HDD)とソフトウェアだけで実現しているのです。ハードウェアのオープン化と価値のソフトウェアへの移行、どこまでいくんでしょうか。。。

さて、次回は5.0から圧縮アルゴリズムも変わったということもありますので、インライン圧縮の話を取り上げたいと思っています。