2017/04/19

Nutanix OpenStackとPlatform9とLiberty

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSolutions MarketingであるChris Brown氏によるものです。原文を参照したい方はNutanix OpenStack with Platform9 and Libertyをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

OpenStackはプライベートクラウドを管理するための強力なツールですが、その強力さは従来コストや複雑性の元にもたらされるものでした。本日、我々はPlatform9社のマネージドOpenStack製品を利用する新たな方法ですべてのNutanix OpenStackのユーザー様の展開、アップグレード、監視、そしてサポートにおける複雑さを取り除くことができるというアナウンスができることを大変うれしく思います。

Nutanix OpenStack ドライバー : リリース 2.1.4

Nutanixはそれぞれのリリースで、多くの新機能が利用できるようになります。Nutanix OpenStack ドライバーも例外ではありません。以前のこちらのブログを確認して、どのようにドライバーが動作するのか見てみてください。新しいリリースのハイライトはこちらです:

- ネイティブのOVM HAサポート : 今回の新しいリリースでは、Nutanix OVMをクラスタ構成として展開できるようになっており、追加で他のツールを使うことなく単一障害点を避けることができるようになっています。

- 柔軟な展開オプション : 新たな接続性とポートの選択のオプションによってドライバはより多くのOpenStackのネイティブな環境との接続ができるようになっています。

- OpenStack Libertyのサポート : OpenStack Libertyはコアサービスにフォーカスしており、運用能力を改善させています。今回のアップデートによって、Nutanix クラスタは容易にLiberty環境と統合することができるようになりあらゆるOpenStack環境のIaaSコアを提供できるようになりました。

Fig202

更に重要な事ですが、LibertyへのアップグレードはLibertyをベースとしてOpenStackを提供しているベンダー、例えばPlatform9などと統合ができるようになったということです:

Platform9 は Nutanix Readyです!

Platform9は完全にSaaSで管理されたOpenStackによって強力な波を起こしてきました。Platform9 Managed OpenStackはOpenStackの複雑さの部分を覆い隠し、ご自身のインフラストラクチャをOpenStackに簡単に統合できるようにしてくれるソリューションです。手動でOpenStackを展開する必要はありません ー Platform9は瞬時に展開され、OpenStackの管理、アップグレード、監視を行ってくれます。すぐに使い始められるというだけではなく、追加での運用やメンテナンスのためのオーバーヘッドもありません。こうした幅広い範囲をカバーしながら、Platform9は後半に分散したインフラストラクチャの一元管理とポリシーベースのアクセスコントロールを提供しています。

NutanixのエンタープライズクラウドプラットフォームをPlatform9 Managed OpenStackと結合することで2つの世界のいいとこ取りをすることができます。つまり ー 様々なパブリッククラウドのように動作し、管理されている簡単に利用できるスタックを利用できるのです。Platform9は皆さんや皆さんのユーザーの展開作業やアプリケーション利用をシンプル化してくれ、Nutanixはその下のインフラストラクチャの運用をシンプルにします。

NutanixをPlatform9と統合して利用することで以下の主なメリットが得られます:

- 予測的分析 : Nutanixは成長に関する予測的な分析やWhat-if分析を提供しています。つまり、より多くのユーザーがワークロードの展開をPlatform9経由、もしくはビジネス部門からの要求によって追加することがあっても(「もしも(what-if)、買収のために来月500仮想マシンを追加でサポートしなくてはならなくなったら?」)、Prismは即座にインフラストラクチャがそれを動作させることができるのか、もしくはそうする前にどんな準備が必要なのかを教えてくれます。

- 運用のシンプル化 : ゾーニング、マスキング、RAIDグループ、その他の構成は不要です。Nutanixのインフラストラクチャは数分で展開され、Platform 9と結合し、なにもないところから完全なOpenStackクラウドをこれまでにないスピードで利用することができるようにします。このメリットは展開時のみにとどまりません。統合されたワンクリックファームウェア、ストレージ、ハイパーバイザーアップグレードによって古いコードにとどまり続ける必要も、何週間にも及ぶアップグレードのための計画のために昼夜を費やす必要もなくなります。あなたの週末を取り戻しましょう!

- クラウドネイティブインフラストラクチャ : Nutanixは今日のパブリッククラウドと同じ哲学のもとに設計されていますが、更にあらゆる規模で利用が可能です。リニアな拡張が実現されているため、スモールスタートして必要に応じて成長させることができ、オーバープロビジョニングの必要はなくなります。また、ネイティブな自己修復機能によってハードウェアの障害時も緊急事態招集をかけるのではなく、自身のスケジュールで行動することができます。

ご理解のとおり、NutanixはPlatform9のための又とない基盤です。Platform9のOpenStackの複雑性の排除とNutanixのデータセンタインフラストラクチャの複雑性の排除によって、これまでにないスピードで完全なクラウド体験を実現できるのです。twitterで我々をフォローし、Next forumsで今回の、もしくは別の話についての会話に花を咲かせましょう!

Nutanix ReadyはNutanixが提供するインフラストラクチャ上の信頼できる推奨アプリケーションとソリューションを認定するものです。Nutanix Readyとして紹介されているすべての製品は完全に検証によって実証されており、ジョイントソリューションは完全な互換性を持って提供されます。後の業界を牽引するアライアンスとパートナーエコシステムによって、Nutanix Readyは様々なビジネスニーズに合うように設計された信頼できるソリューションのショーケースとなります。Nutanix Readyは現在利用可能な製品の互換性、継続した業界における関係性、そして相互運用性を顕しています。

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

今回はいきなりOpenStackの話になりましたが、ここで紹介されているPlatform9社はなんと私(三好)がネットワールドで旗を振っているベンダー様でもあります。Platform9社はKVMもしくはvSphere環境に小さなモジュールを追加するだけで、その上で動作しているワークロード(仮想マシン/アプリケーション)をOpenStackへと移行させるソリューションです。OpenStackのインストールだけで何十通りもの手引書が検索にかかるぐらい難しいOpenStackのインストール、Platform9では失敗することはありません。また、インストールだけではなくその後の運用、トラブル対応、OpenStack自身のヴァージョンアップなどもすべてSaaSつまり、Platform9社が行ってくれます。つまり難しいことは見えなく(インビジブル)してしまい、必要なこと(ビジネスへの対応)に集中する事ができるのです。全く異なるアプローチのNutanixとPlatform9ですが、本質的なメッセージは同じですね。全く異なるアプローチの2社だからこそきれいに組み合わさって完全なOpenStackがおそらく1日もかからずに構成できてしまいます。OpenStackの決定版!ここに極まりました!

2017/04/18

【CommVault】管理コンソールの言語表示の切り替えってできるの?

こんにちは。

先月、CommVault v11 の最新サービスパック(SP7) がリリースされました。

CommVault v11 SP7 の新機能概要は、CommVault 社の技術ドキュメントのサイトで公開されていますので、ご興味のある方は、ぜひご覧ください!SP7 の適用により、Virtual Server Agent での VMware vSphere 6.5 環境の仮想マシンの保護がサポートされました。技術ドキュメントのサイトは、こちらをクリックしてください。

 

さて、今回は、ちょっとした技術的な Tips を紹介したいと思います。

製品のご提案の際に、お客様から管理コンソールは日本語で対応しているの?ということをよくご質問をいただくことがありますが、CommVault 管理コンソール (CommCell Console) は、もちろん日本語に対応していますので、ご安心ください。

 

CommVault 管理コンソールは、通常、管理サーバ CommServe 上に一緒に導入します。国内のユーザー様の多くは、日本語 OS 環境で CommServe を導入されていると思いますので、CommVault 管理コンソールの言語表示は、日本語がベースとなります。

 

実は、CommVault 管理コンソールの言語表示は、日本語の他に、様々な言語に対応していて言語を切り替えて表示することができます。サポートする言語については、以下の言語となります。

 

  • English (United States)
  • Chinese (Traditional)
  • Chinese (Simplified)
  • French (Canada)
  • French (France)
  • German (Germany)
  • Italian
  • Japanese
  • Russian
  • Korean
  • Portuguese (Brazil)
  • Spanish (Mexico)
  • Spanish (Spain)

 

既にユーザー様の中には、管理コンソールの言語表示を切り替える方法をご存じの方もいらっしゃると思いますが、以下の手順で言語表示を切り替えることができますので、試されたことが無い方は、お試しください!

 

  1. CommServe のデスクトップ上に [CommVault CommCell Console] のショートカットのアイコンをコピーします。
    (ショートカットのアイコンは、C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Commvault\Instance001 に格納されています)

  2. ショートカットのアイコンを右クリックし、プロパティを表示します。(screen_capture_property.PNGをダウンロード)

  3. リンク先のパスの -jar の前にCommVault がサポートするISO言語と国コードを追加し、[OK]をクリックします。

    [リンク先(Default)]
    %JAVA_HOME%\bin\javaw.exe -jar cv.jar commserve_host.company.com 8401 -oemid= 1

    [リンク先の追加例:英語表示]
    %JAVA_HOME%\bin\javaw.exe -Duser.language=en -Duser.country=US -jar cv.jar commserve_host.company.com 8401  -oemid= 1

    [リンク先の追加例:スペイン語表示]
    %JAVA_HOME%\bin\javaw.exe -Duser.language=es -Duser.country=MX -jar cv.jar commserve_host.company.com 8401 -oemid= 1

    その他の言語のISO言語と国コードは、Can I launch the CommCell Console in different languages? (英文) を参照ください。

  4. ISO言語と国コードを追加した[CommVault CommCell Console] のショートカットのアイコンをだダブルクリックして管理コンソールを起動します。英語とスペイン語の管理コンソールの表示例は、以下のダウンロードリンクをクリックしてご確認ください。

    CommCell Console 英語表示ログイン画面 : connect_to_commcell_english.PNGをダウンロード
    CommCell Console 英語表示 : commcell_english_display.PNGをダウンロード  
    CommCell Console スペイン語表示ログイン画面 : connect_to_commcell_spanish.PNGをダウンロード 
    CommCell Console スペイン語表示 : commcell_spanish_display.PNGをダウンロード

 

CommCell Console の英語表示は、CommVault 社の Documentationサイト での設定手順の確認 KBサイト のエラーなどの検索の際に役立つと思いますので、活用してみてください!

 

Edit by :バックアップ製品担当 松村・安田

 

【過去の記事】

 

メーカのサイト:
Simpana早わかり講座

 

CommVault Simpana:番外
CommVault Simpana:番外 クライアントPCのバックアップ バイナリ作成編
CommVault Simpana:番外 クライアントPCのバックアップ パッケージカスタマイズ(Mac OS)編
CommVault Simpana:番外 クライアントPCのバックアップ インストール(MacOS)編

 

導入編:

【連載】第1回 始めてみよう!CommVault Simpana インストール編
【連載】第2回 始めてみよう!CommVault Simpana インストール後の作業とバックアップ編
【連載】第3回 始めてみよう!CommVault Simpana VMwareバックアップ編
【連載】第4回 始めてみよう!CommVault Simpana VMwareバックアップ応用編(1)
【連載】第5回 始めてみよう!CommVault Simpana VMwareバックアップ応用編(2)とリストア
【連載】第6回 始めてみよう!CommVault Simpana データアーカイブ機能を活用してみませんか?

 

製品紹介編:

第一回、最新!データ統合管理ソリューション CommVault Simpana のご紹介!
第二回、データ統合管理ソリューションCommVault Simpana 基本構成
第三回、データ統合管理ソリューションCommVault Simpana Backup
第四回、データ統合管理ソリューションCommVault Simpana Deduplication
第五回、データ統合管理ソリューションCommVault Simpana SnapShot Management
第六回、データ統合管理ソリューションCommVault Simpana Virtualization

 

Tips編:
【CommVault】次期バージョン v11の国内提供が始まりました! 
【CommVault】管理コンソールの言語表示の切り替えってできるの?

2017/04/12

Nutanixのリモートオフィス・ブランチオフィスソリューションについて知っておくべき10の事

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSr. Solutions Marketing Managerを務めるRachna Srivastava氏によるものです。原文を参照したい方は10 Things to Know About Nutanix Remote and Branch Office Solutionsをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

Fig201

次なるトップ10シリーズはリモートオフィスとブランチオフィス(ROBO : remote office / Branch office)についてのNutanixソリューションについてのものです。今回は我々のROBOソリューションの10の最も重要な機能、能力、そしてメリットについてご紹介いたします。

ROBO環境は変化し、成長していくビジネス要件にペースを合わせられるように柔軟でなければなりません。しかし、リモートとブランチオフィスは適切なスタッフ配置や投資が行われないことで脇役に追いやられていることもよくある話です。これがROBOでミッションクリティカルなアプリケーションを動作させている際の問題となりえます。例えば、倉庫や配送設備を世界規模で展開している会社が何千ものトランザクションを処理するデータベース上でアプリケーションを利用しているとしましょう。

こうしたアプリケーションはパフォーマンス上の理由からローカルで動作させなければなりません。そして情報システム部門としてはそれぞれの場所において、適切に高可用性と将来のための拡張性を確保する一方で、コストは常にチェックしておかねばなりません。殆どのIT組織は継続的に運用のためのコストを削減しながらROBOの数が増加していくのに合わせて成長のペースを合わせていかなくてはならないのです。

設計からシンプル、俊敏性、そして拡張性をROBOへ提供するため、Nutanixはエンタープライズクラウドプラットホームを提供し、コストや限られたITスタッフそして、バックアップソリューションの管理などの共通の課題を解決いたします。ROBOで必要なインフラストラクチャを劇的にシンプル化し、NutanixはROBOへ配置するインフラストラクチャの経済原理を完全に変えてしまうのです。更に詳しく見ていきましょう。

以下は皆様のお役に立つNutanixのROBOソリューションの最も有用な10の機能です:

1. NutanixエンタープライズクラウドプラットホームのNX-1000シリーズは設置スペースの限られたROBO環境のために作られたもので、2Uのフォームファクタ内にそれ以外のNutanixのポートフォリオで利用されるソフトウェア機能、例えば仮想化の自由な選択(VMware、Hyper-V、AHV)、ネットワークの可視化、ファイルとブロックのストレージサービス、セキュリティ機能、そしてエンタープライズクラスのストレージ機能など、同等のものを備えています。我々のお客様はROBOであってもメインオフィスであっても関係なく、一貫したエクスペリエンスで利用することができるのです。

2. NutanixのROBOソリューションはエンタープライズクラウドプラットホームとしてインテリジェントな階層化、重複排除、イレイジャーコーディング、圧縮、分散自己修復などの優れたエンタープライズストレージを提供します。

3. NutanixのROBOソリューションは様々なハードウェアプラットフォーム上でサポートされています。お客様はNXシリーズ、Dell XCシリーズ、Lenovo HXシリーズ、そしてCisco UCSプラットフォームの中から柔軟に選択をすることができます。

4. すべてのポートフォリオで統合されたNutanix AHVハイパーバイザーがサポートされています。それだけにとどまらず、NX-1000シリーズは混在ハイパーバイザー環境をサポートしており、2ノードでVMware vSphereそして3番目のノードではAHVを動作させるということも可能です。最も大きなメリットは数十、数百にも及ぶROBOサイトでどんどんと追加されてしまうハイパーバイザーのライセンス費を抑えることができるということです。

5. お客様はバックアップに関する戦略を定型化したいという際に、選択肢の中から選ぶことが可能です。WAN越しにNutanix Cloud Connectを利用してセンターサイト経由でAWSまたはMicrosoft Azureに送ることができます。オンプレミスのプライマリクラスタ内でNutanix ROBOソリューションではソフトウェアの構成ミスやウィルスによる攻撃などの際にクラスタ上での復元を実現するTime Stream機能を統合されたバックアップとして利用することができます。ROBOのためにそれ専用のサードパーティのバックアップを買う必要はありません。

6. NX-1155-G5モデルはローカルのNutanixネイティブのスナップショットの1ノードレプリケーションターゲットです。これはお客様がもはやバックアップを管理するために3ノードの別のソリューションを選択する必要はないということになります。それだけではなく、1ノードレプリケーションターゲットはAHVで動作するため、ローカルのROBOソリューションの中で膨らんでゆくライセンス費を排除することができます。NX-1155-G5は2枚のSSDと複数のHDDでローキャパシティとして40TBちょっとの容量で利用することができます。1ノードだとはいえ、データの復元性はドライブのレベルで冗長化されており、堅持されています。

7. ストレージヘビー構成のNX-6000シリーズのキャパシティを利用するなど、異なるタイプのノードを自在に組み合わせて効率性とストレージ容量の適切なバランスを実現することが可能です。更にNutanix Acropolisファイルサービスもあります。この機能によって大きなキャパシティのファイルストレージのために別のファイルサービスを利用する必要はなくなります。

8. グローバル重複排除によって高価なWAN接続バックアップのためのWAN帯域を節約することができます。サイトが地理的に離れていたとしても、グローバル重複排除の機能によって同じデータブロックが異なるROBOサイト間を何度も飛び交うということはありません。

9. Nutanix Prismは数百にも及ぶROBOサイトのプライマリクラスタとデータ保護ポリシーの両方を単一管理画面から集中管理することができます。1-クリック運用やアクション可能な分析結果、キャパシティプランニングなどの機能はすべてセンターサイトで利用することができます。お客様はROBOの運用をITスタッフなし、またはほんの少数で管理することができるのです。

10. Nutanix Prismはこちらのビデオでもでもされているように検索機能も提供しており、これによってクラスタや仮想マシン、そして機能の特定に様々なメニューやスクリーンあちこち探し回ることなくシンプルに実施することができます。

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. Please send us a note through the comments below if you have specific feedback on the external links in this blog.

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

Ntc2017_2

10のシリーズが帰ってきました! 今回はROBOソリューションとして説明がされていますが、小さな環境でNutanixを利用する際のアイディアがいくつも詰め込まれています。例えばNX-1000シリーズでESXiを2台+AHVを1台としてクラスタを組む事もできるという記載がありますが、これを知っているか、知らないかでTCOが全く変わってきます。もちろんPrismのサーチ機能もリモートサイトが多くなってくればその能力を存分に活用できますね。

2017/04/05

HCIとパフォーマンス計測の美学

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSenior Technical Marketing Engineerである Andy Daniel氏によるものです。原文を参照したい方はHCI and the Art of Performance Measurementをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

Fig200

私がNutanix社にPernixDataの買収によって入社することになったのは2016年の夏のことでした。その時がAcropolis分散ストレージファブリックの「中身」について、私が深く触れた最初のときです。私は過去の3年半、ストレージのパフォーマンスの問題をサーバサイドのソフトウェアとフラッシュで解決することをなりわいとしていました。ですからNutanixがデータローカリティとフラッシュを理解してうまくやっているということはなんとなく知っていました。もちろん、Nutanixを現場で知っているということで、私にとてNutanixは「ワンクリック」での管理の簡単さについてよく知っていただけで、パフォーマンスについてはさほど知っているわけではありませんでした。

ビジネスクリティカルアプリケーションについてのリファレンスアーキテクチャやそれに相当するようなMichael Webster氏、Josh Odgers氏、それ以外にも様々なチームによるブログの記事などがありますが、オフィシャルにパフォーマンス関連での情報は少ないと感じていました。これはNutanix上では優れたパフォーマンスが得られるというのに不思議に感じることでした。更に劇的なHCIへのシフトやエンタープライズクラウドの隆盛のさなかで私の頭は砂に埋もれてしまったのではないかということも考えたりしました。

この分野の先駆者として、本当のストレージパフォーマンスを評価するということがとても難しいということは理解しています。何年もの間、私は数え切れないほどのお客様やその候補者にfioやIOMeterを利用することをやめてほしいという活動を推敲を重ねたブログの記事などで一つ一つ続けてきました。ですが、結果は期待ほど芳しいものではありません。ベンチマークツールはそれを使うのが適切な状況においても構成が難しいものです。お客様がそれが何であるのかを理解していない場合、最初から間違いを犯してしまうのです。不幸なことに殆どのシステムは実世界の仮想化ワークロードのために適切に設計されているのですが、単純なI/O生成ツールでの検証のためには適切な題材ではありません。ですが、現実は違います。どこで方向転換すべきなのでしょう?

私がNutanixに入社したときに、同じような質問が社内の至る所で会話されているということに気が付きました。インフラストラクチャ全体でそのリソースが共有されているため、ハイパーコンバージド環境のパフォーマンスの評価は更に難しくなります。私の元々のNutanixのパフォーマンスについての疑問はそれぞれのフィールドで活動しているエキスパートたちのそれとは目線、そして意見が異なっています。

ソリューションとパフォーマンスのエンジニアはソフトウェアを日々チューニングし、夜にはバイト位置指定可能な永続メモリ(高速な不揮発性メモリ)の夢を見ており、上で述べたようなベンチマークについての説明をするでしょう。それと同時に、プロダクトマーケティングは競合との比較の観点で話を始めるでしょう。

現実問題、フラッシュストレージのハードウェアは、これまでと比較して膨大とも呼べるようなIOPSを紡ぎ出すことができます。競合他社は誇らしげに胸を張り、人工的に生成した「英雄の功績」をあげてくるでしょう。お客様がそれによって心を揺さぶられ、現場では誤解が産まれます。狂宴に参加し、あごが落ちるような数字で注意を引くのはとても簡単なことです。

ありがたいことに、こうした状況の中、私は会話に参加することができました。Nutanixは第三者機関のエキスパートに解答を委ねることにしたのです。そのエキスパートはEnterprise Stratecy Group(ESG)で特にシニアアナリストのMike Leone氏です。私は私のこれまでの蓄積と(Nutanixにとっては)新参者ということと、チャレンジ好きということがあって、バトンをもらってMike氏とリエゾンとしてプロジェクトチームをつなぎ、直接やり取りをしてきました。社内の議論をうまく調停できたというだけではなく、私自身はこっそりとですが、自身のパフォーマンスについての疑問への解答を最前線で聞くことができるのも楽しみにしていました。

本日、我々のコラボレーションの結果のレポートをここでアナウンスできることをたいへん誇らしく思います。ESGの協力を得て、我々はパフォーマンスの一貫性、予測性、拡張性について4つのエンタープライズクラスのミッションクリティカルアプリケーション(Microsoft SQLサーバデータベース、Oracleデータベース、Microsoft Exchange、そしてCitrix XenDesktop VDI)のワークロードについて検証をNutanixエンタープライズクラウドプラットホーム上で行いました。

単に人工的にI/Oを生成して記録する他のベンダーが提示しているような「英雄の功績」とはことなり、我々はSLOB、JetStress、そしてLoginVSIなどの業界標準のアプリケーション検証ツールで実ワークロードでの検証にフォーカスしました。Mike氏はこれをうまく表現しています:

「すべてのケースにおいて、コンピューティングとストレージリソースの両方に負荷がかかっています。ですから、コンピューティングとストレージのリソースを共有しているHCIソリューションにおける実世界でのパフォーマンスを模した検証を行っています。すべての検証と結果は本番環境において優れたアプリケーションパフォーマンスが得られるということを裏付けています。」

これと同時に、我々は他社が業界においてIOPSとレイテンシについても明示していることを受け、レポートで比較をしていただくためにNutanixエンタープライズクラウドプラットホームでの検証時の、業界標準の比較対象であるストレージのIOPSとレイテンシの結果を表示しています。これらの結果を見るとアプリケーションの利用される状況が最も結果に影響を与えるということと、Nutanix上のパフォーマンスが十分であるということを示しています。

それぞれの検証について今後数週間かけて更に詳細な内容とどうしてそれぞれのワークロードを選んだのか、ということをお届けしていきますので、ご期待ください。砂の中から私の頭はしっかりと戻ってきました。パフォーマンスに関する会話についても準備が完了しています。ESGのレポートを是非ダウンロードし、どう思ったのか教えて下さい。そしてNutanix Next Communityでの会話を続けましょう。

レポートのダウンロードはこちらから。

議論しましょう! : コミュニティフォーラムに参加してください!


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. Please send us a note through the comments below if you have specific feedback on the external links in this blog.

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

Ntc2017_2

私を含め、皆さんの大好物(?)のパフォーマンスに関する投稿が上がっておりましたので翻訳しようとしたら、なんと、元PernixDataのAndy氏の記事でした。今回第三者機関のESGでの検証レポートがダウンロードできるようになっています。必読! DB系はSLOBで負荷掛けをしていますが、オールフラッシュモデルで、ExchangeはJetStress、こちらもオールフラッシュ、そしてVDIはLoginVSIでハイブリッドモデルでの検証になっています。PernixDataの頃から様々なパフォーマンス関連の記事を翻訳してきましたが、重要なのは「現実に即した検証を行うこと」、これは変わっていません。特にHCIはコンピューティングとストレージのリソースが融合(コンバージド)していますので、ストレージだけとしての検証をおこなっても現実的な話になりませんよね。

今後シリーズとして各検証を掘り下げていくよ、とのことですので当ブログでも追いかけていきたいと思います。

2017/03/29

Nutanixはたくさん買ってはイケナイ!

本記事はNutanix社のオフィシャルブログの翻訳版です。原著者はNutanix社のVP of Client Strategyとして活動しているSteve Kaplan氏です。

原文を参照したい方はBuy Less Nutanix!をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

Fig192「それはつまり・・・Nutanixをたくさん買ってはイケナイと言っているのですか?」

東京でとあるCIOが私が経済的なモデル化の方法を説明した後に私に言った言葉です。私の隣には営業マンが座っていましたので、ちょっと具合が悪かったのですが、私は「そうです、経済性のモデルの観点から言うと、どうして必要以上にNutanixを買う必要があるのでしょうか?まず一つに、将来的に買収されたりすることもあるかもしれませんし、そうでなくても追加で購入するという必要性は出てきます。それ以上に今の実装が気に入ったとして、それを拡張したいと思うはずです、そのときには実際に製品が必要なタイミングまで待てばいいのです。最初にまとめて購入するときよりも、より少ないノード数で住むようになっているはずです。」

Nutanixの営業チームはなぜNutanixのエンタープライズクラウドがゲームを変える技術であるかをよく理解して、組織への提案を行います。クライアント戦略チームの役割はNutanixがどのようにゲームの経済原理を変えるのかをお見せすることです。

NutanixはITの経済原理と運用のあり方を無数の方法で再構築し、そのうちの多くが様々なアナリストのレポートとしてドキュメント化されています ー IDC(TCO/ROI)、IDC(組織の変革)、そしてESGなのです。もっとも強力な経済的なメリットはNutanixの1クリックのソフトウェア定義のアップグレードと段階的な消費の能力をムーアの法則と関連付けられて語られる継続的な技術の進歩と組み合わせたところにあります。

段階的な消費

オールフラッシュ装置を含むSANは拡張性に制限を持つこと以外にもいくつかの経済的な課題を抱えています。従来型の3階層のインフラストラクチャ(集中化されたストレージ+ストレージネットワーク+コンピューティング)では、新しいストレージを追加することは新しいインフラストラクチャのサイロの追加と苦痛を伴うデータの移行作業が必要になります。

結果としてSANを購入した場合には大抵、必要な以上に最初から多くの容量を購入して置かなくてはいけませんが、これはラックスペースや電力そして空調のコストが嵩む上に、余分なハードウェアの減価償却まで行う必要が出てきます。そして、必要以上のSANの容量があるにも関わらず、決められた製品の更新日時までには会社はフォークリフトアップグレード(機材の全取替)を行う必要があるのです。

Fig193

Nutanixはマウスを1回クリックするだけで追加ノードをクラスタに追加でき、古いノードはかんたんに退役、もしくは目的を変更することができるという根本的に異なる利用体験を提供します。これによってクラスタは「成長」し、サイロと苦痛を伴いデータ移行はなくなるのです。

Nutanixのキャパシティのフォーキャスティングとモデル化の能力によって、今後の需要を予測はとても簡単になります。そして一口で食べ切れるだけのサイズのインフラストラクチャを購入するほうが大きな単位での購入するよりもチャージバックもしくはショーバックシステムのセットアップは簡単になります。

1クリックのソフトウェア定義のアップグレード

もう一つのSANが抱える経済的な課題はファームウェアとその下のプロプライエタリハードウェアの密な連携の結果です。SANを利用しているお客様はSANのファームウェアの新しいヴァージョンをダウンロードすることができず、3年間経年した古い装置が新しい装置として振る舞うことはありません。

Fig194一方でNutanixを利用しているお客様では、それをまさに行うことができます。1クリックでいつ導入したのか、どこにあるのかにかかわらずノードをアップグレードすることができ、最新のNutanix Acropolis オペレーティングシステム(AOS)にするだけではなく、サーバのファームウェアやハイパーバイザーさえもアップグレードすることができます。これらのアップグレードは基本的に自動化されており、ローリングで行われ、1つのノードがオフラインになり、アップグレード検証されて、オンラインに戻り、次のノードへという動きをアップグレードが完了するまで繰り返します。

以下の写真は自身のNutanixノードをテスラ(電気自動車)からアップグレードしている際につぶやかれたツイートです。私は一度、あるお客様がビーチでバケーションを楽しんでいる最中にiphoneから本稼働環境をアップグレードしたと言っているツイートを見たこともあります。こうしたことをNutanixはベスト・プラクティスとして推奨しているわけではありませんが、1クリックアップグレードはそれができるほどにシンプルなのです。

Fig195

すべてのノードが同じAOSで動作し、単一のPrism管理画面から管理できるだけでなく、AcropolisブロックサービスやセルフサービスポータルなどのAOSの最新のリリースで登場した新しい機能を利用することも可能です。そしてNutanixは継続的に、そして劇的にそのソフトウェアを改善し続け、パフォーマンスとキャパシティの双方を改善させます。

先に出てきたMattias Sundling氏のツイートはその一例で、ディスク容量をTBの単位で改善させました。以下のHugh Devaux氏のツイートはAOS 4.5から4.72へのアップグレードの際にIOPSが40%も向上し、レイテンシが50%も低減したというものです。

Fig196このパフォーマンスとキャパシティの改善はノードあたりの仮想マシンの密度を更にあげられるということを意味します。Nutanixのお客様は、追加のコストなく ーそもそも全くハードウェアに触ることすらなくー保持しているノード全体で動作させられる仮想マシンの数を増やすことができるということです。Nutanixの環境を拡張するにつれて、徐々にSAN(英語?フランス語?の洒落・・・日本語にできませんでした・・・)時代に必要だったノード数よりも少ないノード数しか必要となくなり、1クリックアップグレードでそれが更に改善されていくのです。

ムーアの法則

ムーアの法則はプロセッサ上のトランジスタの数が18ヶ月ごとに倍になるということを宣言したものであり、長きに渡ってIT産業を牽引してきました。ノートPC、ワールドワイドウェブ、iPhone、クラウドコンピューティングそして、直近ではソフトウェア定義のインフラストラクチャがその例で、これまでにないスピードのCPUによって実現されてきました。

様々な懸案にもかかわらず、技術革新による継続的なパフォーマンスの向上に終わりは見えません。これはパフォーマンスをどのように達成するかという原理が例えばコアをより増やすこと、光通信やメモリスタなどと、当初と変わってきていたとしてもです。例えばNVMeはすでに利用できますし、3DXPointがすでに地平線から昇ってきつつあります。

Nutanixのお客様はご自身のプロジェクトを何年も先まで継続して拡張することができます、ハードウェアがその密度を上げ、同じワークロードを動作させるのに必要なノード数が減少していきます。この数字はソフトウェア定義の1クリックアップグレードで既存のノードの密度も追加することもできるため、より少なくなっていきます。

以下のテーブルはどのぐらいの能力を得ることができるのかということを経験則から導き出したものです。このチャートは組織がVDIへと移行する際のものですが、あらゆる仮想化ワークロード:Splunk、ビッグデータ、プライベートクラウド、サーバ仮想化、災害復旧、拠点、ユニファイドコミュニケーション、SAPまたはOracleベースのERP環境などについて適用することができます。この例では5,000台のPCが5年間かけて入れ替わっていきます。つまり平均して1,000ユーザーが毎年マシンを入れ替えていきます。

更新のタイミングでPCをアップグレードする代わりに、情報システム部門はそれをシンクライアントとして動作するようにロックダウンし、ユーザーは仮想化デスクトップをもらうようになります。この例では最初の1,000ユーザーが更新を迎え、データセンタ内の8ノードのNutanixノードで仮想化デスクトップを動作させています。

Fig197

ソフトウェア定義の1クリックアップグレードとハードウェア定義の技術革新の間で、もしも平均的に密度が毎年25%向上するとすると、次の2年目の1,000ユーザーの更新のためには6台のNutanixノードしか必要でなくなるということです。そして、最後の年の1,000ユーザが5年後に更新を迎えるときには仮想化デスクトップのためのNutanixのノードは3台しか必要なくなっているということになります。

VDIのプロジェクトのための初期導入コストはラックスペース、電源、空調などと関連づいています。ですが、おそらくそれよりも重要な事はNutanixはすべての3階層の構成で購入後に迎えなければならない、新しいSANへの効果で高くつく(すべてのハードウェアの)入れ替えのリスクを排除できるということです。Nutanixのエンタープライズクラウドプラットフォームにはフォークリフトアップグレード(ハードウェアの全入れ替え)は存在しない概念なのです。

プラットフォームを販売し、製品を販売しない

私が事前に多くのNutanixノードを買ってはいけないという私の宣言をした後に、数秒の空白があり、そのCIOは「でも、それって売上を害するよ」と言いました。私は「そう、お考えになるのは最もです、ですが、我々は絶対にそうならないということを知っています」と答えました。

実際、Nutanixのお客様は多くのノードを購入されます - 実際に多く、何度も。例えば2016年の10月31日に終えたNutanixの四半期の終わりに、当社はGlobal 2000のお客様のうちの376社は結果として最初の導入の7.3倍もの購入がなされたとレポートしました。

Fig198私はそのCIOに対して、購入が増える主な理由は2つであると説明しました。最初の原因はお客様がNutanixを新しいユースケースのために導入しますが、すぐに売上が増える、開発者のビルド時間が減る、社員の生産性が改善するなどのビジネスメリットを目にすることになります。その結果だけで情報システム部門がプロジェクトの展開を加速し、何年も全体の実装のために待とうということをしなくなります。

2つ目の原因は単に、Nutanixを最初のユースケースのために展開した後、情報システム部門が環境のシンプル化、ダウンタイムの削減、アプリケーションパフォーマンスの向上などを目の当たりにし、Nutanixのエンタープライズクラウドが組織全体へ広がって、追加のユースケースでのプラットフォームとして採用されていくからです。

少きは多きに勝る

Fig199

私はこの記事の冒頭で我々の営業マンの前でNutanixをたくさん買ってはいけないと言うのが具合が悪かったとちょっとしたジョークを言いました。こうしたタイプのユーモアはお客様が多くの余分なストレージ容量を購入するような典型的な3階層の環境ではもちろんですが、全く同じことが仮想化とそれにまつわる結果としての「シェルフウェア(棚に並べられたソフトウェア)」にも当てはまります。Nutanixは成長するときにだけ支払う(Pay-as-you-grow)モデルをお客様に推奨するだけではありません、我々の営業はRunwayやSizerのようなツールを用いてお客様に現在必要としている以上のものを購入しないようにお客様を誘導します。

そもそもの始まりから、Nutanixは「少きは多きに勝る」という哲学を持っています。インフラストラクチャ、管理、アップグレード、そして仮想化から複雑性を取り除き、クラウドのようにシンプルで俊敏性がありながらも、オンプレミスの統制のある状態を作り出しました。必要とされているだけの購入で済み、プロジェクトが拡張していくほどに必要なノード数が減っていく、お客様には自身のビジネスを変革していくだけの削減効果を残します。

以下もご参照を

Disclaimer: This blog contains 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

3月末公開予定の記事ですので、次年度(当社は12月が期末ですが、一般的な日本企業に合わせて3月期末のつもりで書いています)を始めるにふさわしい記事を持ってきました。「Nutanixはたくさん買ってはいけない!」衝撃的なタイトルですが、Nutanixプラットフォームにおいて、これは当たり前です。売り手側の心理はたくさん売りたいとなるのですが、Nutanixの消費モデルはこの売り手の心理とは真逆、買い手側の最も都合の良いロジックそのままです。この考え方はムーアの法則によるハードウェアの価格の下落とソフトウェアでアップグレードし続けることができるという保証さえあれば永遠に続くロジック・・・そしてメリットです。

Googleはなぜ検索の王者になったか? かんたんに無料で検索ができるというだけではなく、検索結果に挿入される広告ですら、Googleの検索を利用する人にとって都合が良いものであったからだと私は思います。Nutanixの消費モデルも同様で、お客様が理想とするクラウドの利用モデルをいちばん身近なオンプレミスで利用できる。誰もこれに反対する人はいないでしょう。最初のこの記事を読んだときからいつこの記事の和訳を公開しようかと考えていましたが、年度末最後の記事として公開させていただきました!

さて、来年度もエンタープライズクラウドの啓蒙活動をがんばります!

2017/03/22

Nutanix上でのインライン圧縮のパフォーマンスへの影響とオーバヘッドは?

本記事の原文はもともとNutanix社のStaff Solution Architectで、Nutanix Platform Expert (NPX) #001 そしてVMware Certified Design Expert (VCDX) #90(2桁)として活動しているJosh Odger氏によるものです。

原文を参照したい方はWhat is the performance impact & overheads of Inline Compression on Nutanix?をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

よくNutanixのデータ削減機能、例えば重複排除、イレイジャーコーディング、そして圧縮などについて聞かれることがよくありますが、もっとも(そして、特に競合している状況において)よく聞かれるご質問の一つは:

「Nutanixのインライン圧縮のパフォーマンスへの影響とオーバーヘッドは?」

と言うものです。短い回答をすれば、私がNutanixプラットフォームに関して、覚えている限りではメリットがデメリットを上回ります、ということになります。

過去に様々なアプリケーション、ノードの種類、クラスタのサイズそして構成を検証してきました。そしてNutanix(と私)がOracleやMS SQL、そしてMS Exchangeなどのビジネスクリティカルアプリケーションを含む殆どの環境においてインライン圧縮のオーバーヘッドとパフォーマンスへの影響について共有しておくほうが良いと思い当たりました。

今回、MS Exchangeのためのストレージパフォーマンスの検証にはJetstressを利用しています。

(競合によるFUDを避けるため)特段環境に追加の設定を施すことなく、検証はシンプルに行われています。Windows 2012の仮想マシンを1台とJetstressの構成を行いました。そして、3 回、15分で完了するデータベースのチェックサムを取る動作を実施しました。

その3回の検証のあと、インライン圧縮を有効にし、同じテストを3回繰り返しました。

以下の図はNutanix PRISM HTML 5 ユーザーインターフェースがクラスタ全体のIOPS、レイテンシ、そしてスループットをコントローラー仮想マシンのCPU利用率とともに表示したもののスクリーンショットです。

Fig190

見ていただいて分かる通り、6つのテストでのパフォーマンスはCVMのCPU利用率を含め、ほとんど同じです。以下のテーブルはそれぞれのテストでのMS ExchangeのJetstress検証における2つのキー要素であるデータベースのReadのレイテンシとログのWriteのレイテンシを含めたものです。

Fig191

注意 : 上記の数字はNutanixが提供できるピークでも最高の性能でもありません、単に私が走らせた多くの検証シナリオの中の一つに過ぎません。

圧縮なしとインライン圧縮の間の際はほとんどゼロだとわかります。この検証はインラインデータ削減にはI/Oパスにおけるオーバーヘッドがつきものだとみんなが知っているとおりですが、それがアプリケーションのパフォーマンスの低下に影響を与えるというほど重要ではないということを表しています。

今回の場合、Nutanixのインライン圧縮は非常に効率的で、MS Exchangeのようなアプリケーションにおいては素晴らしいデータ効率化を利用しながら、その実、パフォーマンスやCVM上のCPUの追加オーバーヘッドは殆ど無いということです。

おっと、今回、すべてのパフォーマンスはAcropolis Hypervisor(AHV)のものです!

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

Ntc2017_2

今回はインライン圧縮についての記事です。いろいろな会社がインライン圧縮をいかに効率的に行うか、パフォーマンスへの影響がない理由はどうしたアーキテクチャだからだ、という話をお話していますが、Nutanixの実装はこちらをご参照ください。Nutanixのインライン圧縮(Delayなし)では大きな(64K以上)シーケンシャルなWriteデータのみを圧縮し、ランダムWriteは圧縮を行いません(AOS 5.0以降は4K以上のブロックのみ圧縮)。ネットワーク越しにWriteを冗長化する必要が有るため、インライン圧縮を行ったほうがデータを高速に転送できるデータのみを圧縮し、そうでないものはそのままデータを圧縮せずに転送します。とすると、全然データが圧縮されないんじゃないか?という不安が出てくるかもしれませんが、残りのデータの圧縮はあとから(Delayで)実施され、データ永続領域へ書き出される際に実施されます(AOS 5.0では4Kを展開し、64K単位で再圧縮)。

つまりI/Oパスには影響のないところで実施されるので、パフォーマンスへ影響を心配することなく利用できるということになります。このあたり、現在は4Kや64Kという固定長での実施のようですが、買収した会社の特許などを見ていると更にいろんなチューニングが今後出てくる可能性があると思います!

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から圧縮アルゴリズムも変わったということもありますので、インライン圧縮の話を取り上げたいと思っています。

2017/03/08

Acropolis ファイルサービス(AFS)でのデータの分散について

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

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

AFS(Acropolisファイルサービス)で作成の出来る共有(シェア)には2つのタイプがあります。それはホームシェア(Home Share)と一般シェア(General Share)です。一般シェアは作成時には6つのvDiskからなるヴォリュームグループによって形成されています。ホームシェアはクラスタを形成するファイルサーバ仮想マシン毎に5つのヴォリュームグループから構成されています。ですから、小さな構成のAFSでも15のヴォリュームグループでホームシェアを構成することになります。ホームシェアはAFSを展開すると自動的に作成されます。

Fig183AFSで利用されるヴォリュームグループ

ホームシェアはファイルサーバを構成するファイルサーバ仮想マシンのトップレベルディレクトリを分割することでデータを分散します。AcropolisファイルサービスはそれぞれのファイルサーバVMが内部のInsightDBと呼ばれるスケールアウト型データベースを利用してどのディレクトリをどのファイルサーバVMが担当するかのマッピングを行います。

Fig184ホームディレクトリシェアの分散

もしユーザーが「\\FileServer1\Users」というシェアを作成し、その中に「\Bob」、「\Becky」、「\Kevin」というトップディレクトリがあったとすると、「\Bob」はファイルサーバ仮想マシン1上に、「\Becky」はファイルサーバ仮想マシン2に、「\Kevin」は3にと、そのように配置されます。ファイルサーバ仮想マシンはディレクトリ名についての文字列のハッシュアルゴリズムをベースとして、トップディレクトリを分散します。

この分散によって、単一シェアを利用するユーザーが非常に大きくなっても対応が可能です。拡張性による問題から、従来からの設計では管理者はシェアを複数作る必要がありました。例えばその最たるものとしてラストネームがA~Mで始まるユーザーのためにコントローラーを一つ割り当て、N~Zまでの人に別のコントローラーを割り当てるというものです。この設計は管理のためのオーバーヘッドという苦痛を生み出し、不必要にアクティブディレクトリを複雑にしてしまっていたのです。こうした理由から、AFSはクラスタ全体で1つのホームディレクトリしか要らないという実装になっています。もしも1つよりも多くのホームディレクトリシェアが必要な場合、nCLIを利用して作成することが出来ます。

トップディレクトリは終結点となっており、基本的にはショートカットです。前の説明と合わせると、全てのユーザーフォルダをルートディレクトリに作成することで適切なロードバランシングが行えるようになります。ショートカットとして見えるため、シェアのルートディレクトリにはファイルを置くことは出来ないようにしています。また、ユーザーのフォルダを展開する前にシェアのルートフォルダのパーミッションの設定を推奨しています。

一般用途のシェア(ユーザーディレクトリではない)はトップレベルディレクトリでの分散を行いません。一般用とのシェアではファイルとサブフォルダは常に特定の単一のファイルサーバが所有権を持ちます。以下の図は2つの一般用のシェア(例:Accouting(経理)とIT(情報システム)部門)が同一のファイルサーバ上に配置されています。

Fig185

2つの目的の異なるシェアを同じファイルサーバ内に配置

ホームディレクトリシェアとは異なり、シェアのルートにファイルを保管することが出来ます。

気になることがありましたら、コミュニティフォーラムでお話しましょう。ご自身の経験をコミュニティでぜひご共有ください。もちろんTwitterでもご質問を受け付けております。ハッシュタグ「#AskNutanix」をご利用ください。

Disclaimer: This blog contains 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

10のシリーズは一旦終了ですが、今回は社内、社外でよく質問を受けるAFS(Acropolis ファイルサービス)についての記事を取り上げました。AFSはNutanixにネイティブに実装されている、、、結局のところABSをバックエンドにしているため、ヴォリュームグループと言う単位で管理を考える必要があり、Windowsのファイルサーバ仮想マシンを利用する場合の感覚とは少し違ってくる部分があります。ですが記事の中にある通り、巨大なホームシェアを(スケールアウトで!)取り扱うことが出来ますので多くのメリットがあります。実際の操作は仮想マシンを作るのと同じ感覚で作れますので特定のお約束だけ理解していればWindowsを立てるより簡単でしょう。次回もAFSの中身を掘り下げる記事を予定しています。

2017/03/01

ネットワーク可視化について知っておくべき9の事

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のUI Teamによるものです。原文を参照したい方はNine Things you need to know about Network Visualizationをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

「10の知っておくべき事」のブログシリーズを続けていきます。今回の記事で取り上げるのはネットワーク可視化で、我々の5.0ソフトウェアリリースに含まれています。

この新しい機能ではネットワークインフラストラクチャの包括的な表示を一つの画面で提供します。サーバ、仮想化、そしてストレージリソース間を可視化するだけでなく、Nutanixは仮想化の下の物理と仮想ネットワークレイヤについての可視化も行います。 

  1. ネットワーク可視化によって、IT管理者はネットワークのすべての要素とそれらの相互の関係性を視覚的に見ることが出来るようになります。ネットワークの可視化は高度なインタラクティブ性と、Nutanixクラスタ内のすべてのノードのネットワークトポロジの表示を備え、非常に使いやすいものになっています。
  2. 仮想マシンから、仮想NIC、物理NIC、そして物理スイッチのポートに至るまでのネットワーク全体の可視化の能力を備えています。これによってIT管理者はクラスタのネットワークの構成を可視化することが出来、VLANの構成ミスなどのネットワークに関連するトラブルシューティングをシンプルに行なえます。
  3. 管理者は単一の仮想マシンからドリルダウンして、どのホストでそれが動作しているのか、どの物理ネットワーク接続を利用しているのか、そのスイッチポートを利用しているのか、そしてどのVLANに所属しているのかを知ることが出来ます。
  4. 最初のヴァージョンではAHVのクラスタをサポートしており、Prism内の新しいネットワークのページから利用することが出来ます。将来的に我々はこの機能を他のハイパーバイザーへと拡張させる予定です。
  5. ホストのNICとスイッチポート間の関係性を表示して、IT管理者はスイッチポートの状態を含むネットワーク構成の完全な全体像を知ることが出来ます(スイッチ上でLLDPとSNMPを有効にする)
  6. ネットワークのページはフィルタ、グルーピング、そして要素の選択などで便利に使うことが出来、管理者はなにを監視、もしくはトラブルシューティングするのかによってカスタマイズすることが出来ます。
  7. ネットワークの要素それぞれについて掘り下げて表示することができ、各要素についての詳細情報をみることができます。例えば、ノードネットワークトポロジでは標準的な接続情報に加えて、選択可能な要素からインタラクティブに詳細情報を得ることが出来ます。
  8. Prismは階層化され整頓されたネットワーク構成表示を提供し、ユーザーは注目したい物を選択してさらに詳細へとドリルダウンすることが出来ます。
  9. 一般的なトポロジの可視化が組み入れられており、あらゆる関連するコンポーネントの可視化に利用することが出来ます。我々はクラスタ、ホスト、DRサイト、スナップショットなどの他のNutanixのUI部分についてもこれを利用して拡張していく計画です。

Fig182

Forward-Looking Statements

This blog includes forward-looking statements concerning product features and technology that are under development or in process and capabilities of such product features and technology, and our plans to introduce product features, including network visualization and extensions thereof, in a future release. These forward-looking statements are not historical facts, and instead are based on our current expectations, estimates, opinions and beliefs.  The accuracy of such forward-looking statements depends upon future events, and involves risks, uncertainties and other factors beyond our control that may cause these statements to be inaccurate and cause our actual results, performance or achievements to differ materially and adversely from those anticipated or implied by such statements, including, among others: changes in our relationships with our partners, including Dell EMC and Microsoft; failure to develop, or unexpected difficulties or delays in developing, new product features or technology on a timely or cost-effective basis; the introduction, or acceleration of adoption of, competing solutions, including public cloud infrastructure; a shift in industry or competitive dynamics or customer demand; and other risks detailed in our registration statement on Form S-1, as amended, filed with the Securities and Exchange Commission. These forward-looking statements speak only as of the date of this blog and, except as required by law, we assume no obligation to update forward-looking statements to reflect actual results or subsequent events or circumstances.  Any future product or roadmap information is intended to outline general product directions, and is not a commitment, promise or legal obligation for Nutanix to deliver any material, code, or functionality.  This information should not be used when making a purchasing decision.  Further, note that Nutanix has made no determination as to if separate fees will be charged for any future product enhancements or functionality which may ultimately be made available.  Nutanix may, in its own

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

Ntc2017_2

知っておくべき10の事シリーズ、今回は9つですが、Nutanixのネットワーク可視化についての記事でした。今回の記事はUIチームが書いているようですが、今回のネットワーク表示は非常に使いやすく、見てわかりやすいものになっており、正にPrismのど真ん中、という印象です。最後の項目に挙げられているとおり、各要素の相関を上手く可視化することが出来たので、UIチームとしては今後他のところでもこのUIを利用できる部分に適応していくようです。ネットワーク表示が良い、パフォーマンス表示が分かりやすい、など各々の管理ツールの良い部分、悪い部分で製品を選んでおられる方もおられたと思いますが、Prismを作っているチームはこうしたUIのベネフィットを横展開することに積極的ですね。こちらの記事も是非ご参照ください。ぜひ触ってみていただきたいのですが、Nutanixのパートナーになれば誰でも直ぐに触ってみていただくことが出来ます。パートナーになりたいという方は、ぜひ当社へご相談いただければ幸いです。

2017/02/28

空前絶後のォ!超絶怒涛のvSphere6.5対応バックアップ!!(Veeam B&R 9.5 Update1)

昨年11月にリリースされたvSphere 6.5ですが、VMwareを愛し、VMwareに愛された(?)バックアップソフトであり、インスタントVMリカバリやストレージスナップショット連携、全てのエージェントレスバックアップの産みの親とも言える(?)、Veeam Backup & Replication 9.5 (以下、VBR 9.5) が1月にリリースされたUpdate1で早くも対応しました!


◆Release Notes for Veeam Backup & Replication 9.5 Update 1
https://www.veeam.com/kb2222


「vSphere 6.5に対応しているバックアップソフトなら、既に他にあるよ」と思った方もいるかもしれませんが、そういったバックアップソフトはエージェントレスで仮想マシンバックアップするためのAPI(VMware vSphere Storage APIs – Data Protection)のSDKであるVirtual Disk Development Kit(以下、VDDK)が古いバージョン(6.06.0.2)を利用していることが多く、vSphre 6.5をサポートはしているものの、vSphere 6.5の新機能には対応できていません。


※VDDK 6.0.2リリースノート抜粋
https://www.vmware.com/support/developer/vddk/vddk-602-releasenotes.html
The VMware policy concerning backward and forward compatibility is for VDDK to support N-2 and N+1 releases. In other words, VDDK 6.0 and all of its update releases support vSphere 5.1, 5.5, and 6.5 (except new features).


VBR 9.5 Update 1ではVDDK6.5を利用していますので、vSphere 6.5に完全対応しています。そこで、今回はVBR 9.5 Update 1でのvSphere 6.5対応の一部をご紹介しましょう。


■新しいファイルシステムののサポート

vSphere 6.5の新しいVMFSのバージョン6では512eのサポートや領域の自動再利用などの機能追加が行われていますが、VBR 9.5 Update1ではVMFS6にも完全対応しています。他のバックアップソフトではVMFS6の場合、FC SANやiSCSI SANのようなSAN経由でバックアップするSANモードでのバックアップができないことが多いのですが、VBR 9.5 Update1ではVMSF6であってもSANモードでバックアップすることが可能です。

  

Vmfs6_4

                

VMFS5からVMFS6にはインプレースアップグレードができないため、vSphere 6.5を導入する場合には、最初からVMFS6にしておきたいところですが、VBR 9.5 Update 1ならVMFS6で構成しても安心です。最初はVMFS5で構成し、後でVMFS6にしたいという場合でもVMFS5の環境の仮想マシンをVBR9.5 Update 1でバックアップし、VMFS6にフォーマットし直した環境に対してリストアすることもできてしまいます。

また、VMFS6だけでなく、VSAN 6.5にも対応しています。vSphere環境やVSANを利用しているハイパーコンバージドインフラ製品は、今後、vSphere 6.5ベース(=VSAN 6.5)になっていきますが、VBR9.5 Update 1ならVSAN 6.5になっても心配ありません。



■仮想ハードウェアバージョン13のサポート

vSphere 6.5では新しい仮想ハードウェアバージョンの13が提供され、仮想NVMeコントローラやuEFIセキュアブート、VMFS6での自動領域再利用などの新機能を利用する場合には仮想ハードウェアバージョン13が必須となっています。

Vmhw13_4

  

VBR 9.5 Update1は、この仮想ハードウェアバージョン13にも完全対応していますが、VDDK 6.5を使っていないバックアップソフトでは、仮想ハードウェアバージョン13に完全に対応していないため、事前に仮想ハードウェアバージョン13に対応していることを確認しましょう。

■暗号化されたVMのサポート

vSphere 6.5ではハイパーバイザーにビルトインされた仮想マシンの暗号化機能が提供されていますが、VBR 9.5 Update 1では暗号化された仮想マシンのバックアップにも対応しています。

Efi_4

ただし、vSphere側の制限により、SANモードのバックアップは不可で、NBD(要SSL)モードかHotadd(要プロキシVM自体の暗号化)モードのみとなりますので、気を付けましょう。

Vmenc

 

NBDモード利用時の圧縮

vSphrere 6.5ではバックアップでも新機能が実装されています。ネットワーク経由でバックアップデータを転送するNBD(Network Block Device)モードでは、これまではバックアップデータがそのままESXiホストからプロキシサーバに送られてきましたが、VDDK 6.5ではNBDトラフィックの圧縮を有効にする機能が追加されています。

Nbdcomp_4


VBR 9.5 Update 1はNBD圧縮機能に対応していますので、NBDモードでバックアップしている環境では、vSphere 6.5&VBR 9.5 Update1にするだけで、バックアップのパフォーマンが向上するかもしれません。


今回はVBR 9.5 Update1でのvSphere 6.5対応を中心にご紹介しましたが、VBR 9.5自体も前バージョンから多くの新機能や機能拡張が行われていますので、下記のWebinarや資料をチェックして、空前絶後の超絶怒涛のバックアップを感じてください!

https://www.veeam.com/jp/videos/availability-suite-9-5-now-generally-available-9130.html

https://www.veeam.com/pdf/new/veeam_backup_9_5_whats_new_jp.pdf

担当:臼井