2017/08/16

クローンの攻撃 - AFS 2.1.1のWhat's new

記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社の社員であるdlink7氏によるものです。原文を参照したい方はAttack of the Clones – What's new in AFS 2.1.1をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

Fig267

NutanixのAFSチームは新しい様々なユースケースに対するお客様の要求に答えるためノンストップでファイルサーバーのクローンのサポートのために活動しています。AFSはもともと全てのAFS環境が単一のバックグラウンドのストレージコンテナを利用するという1対1の関係性を前提として設計されていました。この1対1の関係性は最初は多くの点で理にかなっていると思っていました。というのもPrismからは単一のストレージコンテナだけを見れば私がやりたいことの全ての統計情報を見ることができるからです。これは更にAFSのバックグラウンドのヴォリュームグループがストレージコンテナ/AFSサーバと同じ名前で済んでしまうということでもあります。ファイルサーバ全体の構成をクローンできるようにするということは開発チームはAFSとそれに対応するヴォリュームグループの間の密結合を解き放つ必要が出てきました。

AFS 2.1.1以降、AHVとESXiの両方でファイルサーバのクローンを行うことが完全にサポートされます。これはまた、同一のストレージコンテナ内に1つ以上のファイルサーバが初めて同居して動作することも意味しています。ファイルサーバをクローンする以外に、クローンをしなくてもファイルサーバのリネームするという機能もAFS 2.1.1から搭載されています。

 

この改善によって以下のユースケースをサポートできるようになっています:

 

  • 開発と検証のために全環境のクローンを作成する
  • オリジナルのファイルサーバの動作中に完全なDRの検証を行う
  • アンチウィルススキャンの完全なオフロードを実現する
  • 本稼働系サーバを稼働している最中に分析を回す
  • ROBOサイトのバックアップ 例) オフショアの石油掘削機、リモートオフィスは自身のファイルサーバを本社にレプリケーションし、バックアップを行うためにクローンを作成できます

Fig268_2

稼働中のAFSのクローンを作成することで実現する新たなユースケース

その他のAFS 2.1.1での改善点

AFSのサイジングワークフロー : PrismでAFSクラスタを作成時にワークロードベースのサイジングが利用できるようになりました。マニュアルでの設定のオプションも引き続き利用できます。

Fig269

MMC(Microsoft Management Console)のスナップインもAFSでサポートされています。これによってホームシェアのトップレベルディレクトリのリネーム、再帰的な削除、パーミッションの適用が可能になっています。これでpowershellのスクリプトを使う必要がなくなりました。Windowsエクスプローラーがホームディレクトリがうまく動かない理由は我々のDFSを利用してトップレベルフォルダの照会を行っているからで、他の製品ではこれが使われることはありません。こうした照会は多くのノードにまたがる数万のユーザーが利用する単一ネームスペースを提供することを実現しています。新たなMMCのスナップインはサポートポータルからダウンロードできます。

 

トップレベルディレクトリの管理

 

管理者とバックアップ管理者のサポート : 非ドメインのadminユーザーを管理者、そしてバックアップ管理者としてUIから追加できるようになり、cliを利用する必要はなくなりました。

短く言い換えるとAFS 2.1.1はマイナーリリースではあるものの、日々の運用に大きな影響を与えるものになるはずです。 

Fig270

トップレベルディレクトリの管理

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

Ntc2017_2

画像だけ見て、絶対訳さねばと思っていましたが、他にも色々訳したいものがあって日が空いてしまいました。ファイルサーバをクローンする、この考え方はどちらかと言うとコピーデータマネージメントに似ている気がします。物理のファイルサーバでシェアをクローンするということは当然できていたと思いますが、AFSは分散実装されているファイルサーバです。分散実装されていることならではのこれまでにない面白いユースケースが様々登場してきそうです。

2017/08/09

NVMeについて従来からのストレージベンダーがあなたに知ってほしくない5つの秘密

記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSr. Manager, Technical Marketing EngineeringであるPaul Updike氏、およびSr. Technical Marketing EngineerであるAndy Daniel氏、およびSr. Product Marketing ManagerであるMarc Trouard-Riolle氏によるものです。原文を参照したい方はFive secrets traditional storage array vendors don’t want you to know about NVMeをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

Fig266

Non-Volatile Memory Express(NVMe)は、従来からのストレージ装置が膨大なストレージデバイスを利用し、その駆動のために製品への巨大な投資が必要になるというやり方を破壊しつつあります。どうしてかって? それはNVMeは従来型のストレージアーキテクチャではないからです。実際、フラッシュストレージの最初の波(SSD)もそうではありませんでした。しかし、製品をより市場に早く送り出し、幅広く浸透させるため、ドライブのインターフェイスとプロトコルは変更されませんでした。最初のSSDはフラッシュを従来型のストレージアーキテクチャで利用するために設計されていました。この要件を満たすために、SSDは従来型の回転するハードドライブを模倣しています。データの入出力はハードドライブのインターフェイスを通り、その先に回転するお皿があるかのように振る舞っており、その模倣の持つ制限に縛られているのです。これを心に留めて考えると、以下はNVMeについて従来型のストレージベンダーがあなたに知ってほしくないことなのです:

 

1. NVMe は最初はサーバテクノロジーとして提供される

殆どの新しいテクノロジーと同様に最初のドライブは一般的なデスクトップそしてサーバシステムの内部に搭載されます。今日ではNVMeテクノロジーはほとんどのメジャーなベンダーのサーバー内に搭載して購入することができます。もちろん、Best Buyで個別のユニットを買うということもできます。ゲーマーならそれをデスクトップに搭載しますし、もしも昨年購入したノートパソコンであれば、NVMeはすでに搭載されているかもしれません。残念なことにNVMeと他の多くのマスマーケットを対象にしたテクノロジーはサーバー内で利用されるために設計されており、ストレージ装置で利用されるようになるまでに長い時間がかかります。(Nutanixのハイパーコンバージドインフラストラクチャはサーバーベースのテクノロジーです)

 

2. 新しいアーキテクチャでは高可用性が必要とされる

従来型の装置はSASとSATAインターフェイスを利用するために設計されています。SASは元から1つ以上のコントローラーと同時に接続するためにデュアルポート構成で、装置ベンダーは特殊なトランスポーター(転送機)を利用してSATAでも同じことができるようにしています。NVMeのアーキテクチャはSASまたはSATAのコンポーネントを利用しません。そして、全く新しい設計が必要になります。最初のNVMe 1.1のスペックでは、U.2 デュアルポートのNVMeドライブが2016年の初期にアナウンスされました、しかし、このデュアルポートの能力を持つドライブを出荷しているメジャーなベンダーはありません。デュアルポートのU.2は複数のPCIeレーン(各コントローラーに2つ)が必要だということを覚えておいて下さい。これはスループットを制限する可能性があります。(Nutanix ハイパーコンバージドインフラストラクチャは高可用性のために複数箇所でドライブをマウントする必要はありません)

 

3. NVMe はホットスワップが難しい

NVMeはPCIe上でダイレクトに動作し、PCIeホットスワップがプラットフォームで完全にサポートされていなくてはなりません。ホットプラグ可能として販売されているNVMeドライブはありますが、それは特定の物理プラットフォーム、CPU、オペレーティングシステム、そしてドライバーが揃っている場合だけです。現在のドライバーはサーバープラットフォームとOSのために書かれたものです。繰り返しとなりますが、このサポートにはベンダーの専門性が必要とされます。(Nutanixではワークロードを移行させ、ノードレベルで停止無く修理を行うことができます)

 

4. リモートのNVMeデバイスを完全活用するためにはRDMAが必要となる

複雑怪奇なPCIeのスイッチの設計の他に、リモートのNVMeへ従来型のファブリック(イーサーネットやファイバーチャネル)経由でアクセスするためには遠隔ダイレクトメモリアクセス(remote direct memory access ー RDMA)とNVMe over Fabric(NVMeF)のような新しいプロトコルが必要になります。RDMAでスタックをバイパスせずに、単純なTCP/IPスタックを利用していてはNVMeによるレイテンシーの削減を台無しにしてしまいます。多くの業界のスタンダードと同じように、NVMeFの開発は遅く、現在殆どのストレージベンダーがこれを出荷していません。(NutanixはRDMAを活用する際にNVMeFを利用する必要はありません)

 

5. NVMe をストレージ装置上で利用する場合にはより多くのリスクが集中します

ストレージ装置ベンダーはデータをデータセンタ内で成長、統合させたいため、実際のところ多くのストレージベンダーがこれを推奨しています。多くのベンダーの目的は古い世代のハードウェアの定期的な交換です。これをより早くするため、大きなキャパシティを持つストレージでは同一システム内にデータを固めなくてはなりません。それは「バスケットの中の卵」のようなリスクで、より膨らんでいくのです。(Nutanix エンタープライズクラウドはノードの単位で成長していきます。リスクは集中するのではなく、より分散していきます)

 

NVMEを今すぐに活用するにはどうしたら…

Nutanixは新しいオールフラッシュノードを追加します。NX-9030シリーズプラットフォームはSATA SSDとNVMeを搭載しています。まとめにその方法を記載します: 

1. 我々のクラスターノードはサーバーの標準的なアーキテクチャです

2. 我々の障害と交換の対応はノードレベルで非常に簡単です。NVMeが障害を起こすことも想定済みです。

3. 我々はソフトウェアをNVMeを思慮深く利用するようにカスタマイズし、パフォーマンスを向上させています。

4. 我々は迅速に既存のRDMAテクノロジーを活用する方法を開発しました。これは新たな業界標準には依存しません。

5. 我々のエンタープライズクラウドはリスクを集中させるのではなく分散します。

 

究極的に、Nutanix製品は革新的なソフトウェアです。我々のハイパーコンバージドインフラストラクチャの哲学をベースとした障害前提ウェブスケール設計は迅速な革新的なハードウェアベンダーからの新しいハードウェアテクノロジーの適応を実現します。サーバの革新の波にのることで、我々はお客様がより早くポジティブなビジネス成果をあげることのお手伝いをすることができるのです。

 

© 2017 Nutanix, Inc.  All rights reserved. Nutanix and the Nutanix logo are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s).

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

Ntc2017_2

さて、抽象度の高い記事で、訳しにくいAndy Danielさんも共著のブログですが、割りと今回訳しやすかったです。

ストレージベンダーがNVMeについて知ってほしくない5つの秘密・・・ですが、以前翻訳した「フラッシュにとってネットワークは遅すぎる、どうしたら?」もその一つであると思います。今回はネットワークスピードではなく新たなNX-9030プラットフォームが登場しますので(Readはローカリティで回避、でもWriteでは不可避であった)ネットワークスピードの問題もRDMAで低減してきています。NVMeFを使うとどれぐらい良いのかはこちらなどでも結果が紹介されていますが、リモートへのWriteもローカルとほとんど変わらないようなスピードが実現されています。(これはNutanixを対象とした検証ではありませんし、単にネイティブとイーサーネット、インフィニバンドの比較を行うため、ファイルシステムなども加味されておりません、あくまでどれぐらいのレイテンシなのかということのご参考です)。

2017/08/02

敢えて言おう、VeeamはvSANに対応していると!

VMwareのSoftware-Defined StorageであるVMware vSANは、vSphere 5.5 Update1でリリースされて以降、vSphereのバージョンアップに合わせて、何度かバージョンアップが行われています。最近ではvSphere 6.5dのリリースに合わせて、vSAN 6.6がリリースされました。

そんなvSANですが、vSphere6.5対応やvSAN対応を謳っていても、現在はvSAN 6.5以降には完全に対応できていないバックアップソフトが多い状況ではありますが、Veeam Backup & Replication(以下、VBR)は、前回ご紹介したVBR 9.5 Update1で既にvSAN 6.5に対応しており、更に、5月にリリースされたVBR 9.5 Update2でvSAN 6.6にも対応しているのです!

Release Notes for Veeam Backup & Replication 9.5 Update 2

 Platform support
   -VMware vSAN 6.6 support.

そこで、今回は実際に検証環境でVBR 9.5 Update2を使用してvSAN6.6上の仮想マシンのバックアップ・リストアを試してみました。


■検証構成

論理的には下記のような構成になっており、4ノードvSANで仮想マシンとして構成したVeamサーバがvSAN上の仮想マシンをData Domainにバックアップします。

 Config1_3

実際にはESXiはNestされた仮想マシンになっており、Data DomainもVirtual Edition(仮想アプライアンス)のため、全て仮想環境上で動作しています。vSpheer Web Clientで見ると下のような感じです。ESXiのビルドが5310538 になっていることから、ESXiが6.5.0dであること分かります。vSANは全てSSDでオールフラッシュ構成(エミュレーションですが…)で重複排除・データ圧縮が有効になっています。

Vsan1_3

■バックアップ

まずは、バックアップですが、バックアップ対象の仮想マシンの選択では、データストアでvSANのデータストアである[vsanDatastore]がきちんと見えています。

Vsan3_2

下の図がバックアップを実行した結果は下の図になりますが、「hotadd」と表示されていますので、仮想マシンのVeeamサーバがHotaddモードでのバックアップに成功しています。Nest環境のため、スループットが良くない点はご容赦ください。
 

Vsan4_2

■リストア

次にリストアをしてみましょう。リストアのウィザードではvSANデータストアの中に仮想マシンに別途、割り当てている仮想マシンストレージポリシー(Test-VM-Policy)が表示され、ストレージポリシーの情報含めてバックアップしていることが分かります。

Vsan5_2

リストアも問題なく成功しました。「hotadd」を表示され、リストアでもHotaddモードでvSANデータストアにリストアできていることが分かります。

Vsan6_2

リストアされた仮想マシンの仮想マシンの設定を確認してみると、割り当てていた仮想マシンストレージポリシー(Test-VM-Policy)も戻っていました。

Vsan7

仮想マシンストレージポリシーが戻るのは当たり前と思う方もいるかもしれませんが、vSAN対応を謳っているバックアップソフトでもStorage Policy-Based Management (SPBM) には対応できておらず、リストアすると、デフォルトの仮想マシンストレージポリシー(Virtual SAN Default Storage Policy)が割り当てられ、リストア後に手動で仮想マシンストレージポリシーの再割り当てが必要なものが多いのです。

vSAN環境では仮想マシンストレージポリシーで仮想マシンの冗長化を定義するため、バックアップソフトがSPBMに対応しているかどうかは重要です。また、他のバックアップソフトの場合、バックアップベンダーが独自にvSAN環境でテストを行い、vSAN対応を謳っていることがほとんどですが、VBRは独自にテストをしているだけでなく、VMware社のvSAN認定も取得し、VMware社のKBにも掲載されているほどです!

※vSAN データストアを使用した Veeam のバックアップと複製 (2150856) http://kb.vmware.com/kb/2150856


vSphere 6.5でvSANを利用するとなると、今後はvSAN6.6が前提になってきますが、VBRであれば、vSAN環境やvSANベースのハイパーコンバージドインフラ製品でも安心してバックアップできます。vSANの導入を検討している方や既にvSANを導入済みでvSAN 6.6へのバージョンアップを予定している方で、VBRを検証してみたいという方は、是非、評価版でお試しください!

■参考

Veeam Backup & Replication 評価版ダウンロード

VMware vSphere向け簡易手順書(日本語版評価ガイド)

Configuration for VMare VSAN

 担当 臼井

Nutanix on HPE® ProLiant® is NOW AVAILABLE

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSenior Product Marketing ManagerであるEJ Bodnar氏によるものです。原文を参照したい方はNutanix on HPE® ProLiant® is NOW AVAILABLEをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

Fig265

Nutanixは業界をリードするエンタープライズクラウドソフトウェアが最も幅広く展開されているエンタープライズサーバープラットフォーム上で利用可能になったということをアナウンスでき興奮を禁じえません。

HPE® ProLiant® サーバはNutanixによってNutanixエンタープライズクラウドソフトウェアの動作のための完全な検証そして認証を得ています。HPE® のお客様はNutanixソリューションを活用してエンタープライズクラウドを構築し、パブリッククラウドサービスのシンプルさ、俊敏さをプライベートクラウド環境に必要とされる統制、セキュリティとともに享受することができます。ProLiant®を利用しているお客様はNutanixを業界で最も利用されているハイパーコンバージドソリューションとしたのと同じ、Nutanixのコンピューティング、ストレージ、仮想化、そしてネットワークの機能 ー 更に加えて直感的なコンシューマーグレードの管理機能を手にすることができるのです。

Nutanix エンタープライズクラウドソフトウェアをHPE® ProLiant® ハードウェア上で動作させることでお客様は以下を実現できます:

  • HPE® ProLiant® サーバとNutanixエンタープライズクラウドソフトウェアで完全なインフラストラクチャのスタックを構築
  • 高価で複雑なSANを排除し、データセンタをProLiant® サーバのストレージリソースでシンプル化
  • ワンクリックでのソフトウェアアップグレード、インフラストラクチャの拡張、トラブルシューティングによって、インフラストラクチャの管理を劇的にシンプル化ー ITスタッフを開放し、インフラストラクチャではなく、ビジネスアプリケーションにフォーカスができるように
  • スモールスタートし、ProLiant®を一台ずつ追加することで制限のない拡張を実現
  • Nutanixがネイティブで提供するAHVハイパーバイザーによって仮想化についてのコストを削減、仮想化の管理を統合
  • アーキテクチャや運用を変更すること無くProLiant®サーバに簡単にNutanixのエンタープライズクラウドソフトウェアを追加

 

強い顧客、そしてパートナーからの要求:

NutanixのHPE® ProLiant® のサポートは強い顧客そしてチャネルパートナーからの要求に答えたものです。HPE®認定ディストリビューターそしてリセラーとNutanixはHPE®ハードウェアとNutanixソフトウェアを自身のファシリティまたはお客様先で統合します。IT専門家は他のすべてのNutanixがサポートするハードウェアプラットフォームと同様の素晴らしいエクスペリエンスを享受することができます。

 

サポートされるHPE® ProLiant® サーバには以下が含まれます:

  • ProLiant® DL360-G9  ー 1Uのラックマウントサーバで最大8つのスモールフォームファクタ(SFF ー small form factor)ドライブベイを保持します。これによってオールフラッシュ構成または2x SSD と 最大 6x HDDを組み合わせたハイブリッド構成を実現することができます。DL360はVDI、ミドルウェア、Webサーバそして一般的な仮想化のユースケースに最適です。
  • ProLiant® DL380-G9 12LFF ー 2Uのラックマウントサーバーで最大12のラージフォームファクタ(LFF - large form factor)のドライブベイを保持します。オールフラッシュまたは2x SSDと最大10x HDDでのハイブリッド構成を実現することが可能です。主としてストレージヘビーまたはサーバー仮想化ワークロードをターゲットとしています。
  • ProLiant® DL380-G9 24SFF ー 2Uのラックマウントサーバーでこちらは最大で24のSSFドライブベイを保持します。オールフラッシュ構成および4x SSDと最大20x HDDでのハイブリッド構成を実現することが可能です。MS Exchange、SQL Serverそして、大規模なデータベースユースケースに向いています。

 

どのようにサポートが行われるか:

  • Nutanixはエンタープライズクラウドソリューションが展開された認定済みHPE® ProLiant®システムすべてにおいて、最初のコールを受け付けます。これによってシンプルな、サポートの単一のコンタクトポイントをご提供します。お客様はもちろん、明らかにハードウェアの問題である場合にはもちろん、お客様がHPE® に最初にコールするという選択肢もあります。
  • 初期の切り分けの段階において、もし問題がハードウェア上にあるかもしれないという状況においても、Nutanixのサポートはお客様がHPE® へコンタクトをとることをアシストします。これは必要不可欠な情報をご提供するというための手段ということになります。NutanixはHPE® にお客様の代わりに直接TSANet (TSANet.org)経由でコンタクトをとるという手段もご用意しています。
  • もしも問題がソフトウェアに起因するものであれば、Nutanix サポートはその問題の解決のために稼働します。いずれに場合においても、Nutanixサポートは顧客との合意の元、受け入れ可能な解決がなされるまでケースをクローズしません。

 

ハイパーコンバージドインフラストラクチャを超え、エンタープライズクラウドへ:

ハイパーコンバージドインフラストラクチャはプライベートクラウドに劇的なシンプルさをもたらしました。しかし、エンタープライズのデータセンタがパブリッククラウドのちからを持つにはまだ多くのものが必要です。HPE® ProLiant® 上で動作するNutanix エンタープライズクラウドプラットフォームはパブリッククラウドインフラストラクチャの俊敏性とワンクリックのシンプルさとセキュリティ、統制、想定通りの経済性、そしてプライベートクラウドに必要とされるパフォーマンスも融合されています。ハイパーコンバージドインフラストラクチャををNutanixエンタープライズクラウドで超えていきましょう…

 

Nutanix on HPE® ProLiant® について更に詳しく知りたい場合は こちら: https://www.nutanix.com/dlserver/ そしてNutanixエンタープライズクラウドについて更に知りたい場合には こちら:https://www.nutanix.com/

 

 

© 2017 Nutanix, Inc.  All rights reserved. Nutanix, the Enterprise Cloud Platform, and the Nutanix logo are registered trademarks or trademarks of Nutanix, Inc. in the United States and other countries.

HPE® and ProLiant® are registered trademarks of Hewlett-Packard Development LP and/or its affiliates.  Nutanix is not associated with, sponsored or endorsed by Hewlett-Packard.

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

Ntc2017_2

5.1.1.1のリリースにひっそりと記載されておりましたが、なんとNutanix on HPE ProLiant、すでに正式にリリースされています!Nutanix Washinton D.C.でもひときわ拍手の大きかった発表ですし、本当にこれを待ち望んでいたパートナー、お客様が多くいらっしゃったのですね。年内に動けばいいと思っていましたが、大きく前倒しされてのリリースです。

当社もウェブセミナーのやってみたシリーズなどで取り上げていきたいと思っていますが、ProLiantはGen10もリリースされていますので、そちらがサポートされてからの検証になるかもしれません。

いずれにしてもNutanixは100%ソフトウェアカンパニーであるというその本来の姿を顕しつつありますね。

面白いのが冒頭のイメージです。HPE社のロゴはRectangle(四角)ですが、その外で考えよう!なかなかシャレが聞いています。

2017/07/31

VMware Cloud on AWS ー 想定通りのキャパシティの展開

本ブログエントリーは以前はPernixData社のテクノロジーエバンジェリストとして勤務し、現在はVMware社のR&DでSenior Staff Architectを務めているFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はVMware Cloud on AWS – Predictable Capacity Provisioningで閲覧可能です。

ネットワールドのVMwareに関する情報はこちら

VMworldのセッション LHC2971BU - Managing your Hybrid Cloud with VMware Cloud on AWS(VMware Cloud on AWSでハイブリッドクラウドを管理する)、私はこのセッションをEmad Younis氏と一緒に喋りますが、その旬日をしている際に、以下のような質問をTwitterで投げかけました:

訳: サーバーハードウェアを購入してそれをvSphereクラスタとして運用するまでの平均のリードタイムは今日現在どれ位ですか?

その結果、返信の数は圧倒的なものでした。今回のお話はそれほどでもありません。プロセス内の一つ一つのすべてのステップを自動化しようと我々が奮闘するのは面白いものです。Alan氏、Luc氏そしてWilliam氏のようにESXiホストのインストールや構成するスクリプトをつくるコミュニティを支援する人もいます。一貫性のある、人的ミスのない、迅速なプロセスです。時間のかかるサーバー展開のプロセスから貴重な時間を削り出すことができます。幾つかの会社はvRealizeスイートと連携し、ITサービスのポートフォリオ全体に一貫性のあるユーザーエクスペリエンスを作り上げています。また面白いことに、リードタイムの全体において、最も影響力のあるのが内部的な購入のプロセスです。2つの例を上げましょう :

訳 : 45~60日、最大で90日。10~30日が購入申請、30日が納期、1週間がケーブリングと検証とクラスターへの追加です。

訳 : はは! だったら、わからないよ。購入の承認は完全に予測不能。

訳 : 殆どの待ち時間は見積もり/購入/納期です。実際のセットアップは数分から、数時間。

訳 : 購入が承認されても納期に3週間です。時々クラスタへの追加と稼働まで3週間でいけることもあるけど。

そして、リストはどんどん伸びていきました。殆どの組織においては準備段階が非常に厳格で、よく定義されている手順のようでした。ですが、購入プロセスにおけるリードタイムは想定通りでも、一貫したものでもありませんでした。全てのメッセージがIT組織の俊敏性が縛られているというものでした。

IT組織はビジネスの要求に応じて迅速に反応できなくてはなりません。現状のワークロードのリソース管理ですらむす香椎のです、今後数ヶ月で挑戦しなくてはいけないことを考えてみてください。残念なことに新しいワークロードを追加するということは要求のカーブが線形になるということではありえません。(起こりうる)将来のお客さまのニーズに対応するため、その規模は2倍にもなるかもしれません、それができなければ新しいワークロードの追加はできないことになります。こうなると会社自身の基盤に影響を与えかねませんし、さらにITサービスを適切に運営する能力にも影響を与えかねません。

訳 : いつもの感じだと30~45日程度。管理プロセスに必要となる項目などで「次の」待ち時間を減らすために規模はほぼ倍になっています。

基本的に、サーバーリソースの購入についてのCAPEX(購入コスト)要素は大きくIT組織の実行力に影響もしくは妨げとなります。CAPEX/OPEX(運用コスト)についての戦略は多くの管理者やアーキテクトのフォーカスエリアからは外れています。これ自身は彼ら自身の意味での実行力を低下させるものではありません。多くののツイートがそれを証明してくれたとおり、VMware Cloud on AWSはホストのリソース調達のプロセスをCAPEXからOPEXへシフトさせ、より高速で、一貫性のある、そして想定通りの方法でコンピューティング、ストレージ、ネットワークリソースを提供してくれるのです。AWSの運用モデルを活用し、AWSインフラストラクチャで動作しているSDDCクラスタはボタンをクリックするだけでリサイズすることが可能です。クラスタを右クリックして、リサイズを選択して下さい。

Vmcresizecluster

追加したいホスト数を選択すれば、すぐさま新しい専属の物理ハードウェアがクラスタに追加されます。もう新しいワークロードに必要なリソースが追加されているのです。リサイズは同様にリソースを縮小することができるということも意味しています。もちろん、コストも下がることになります。

AWSとVMCの管理が統合されているため、新しいESXiホストは完全に新しいワークロードを迎え入れられる状態になっています。すべてのVMKernelネットワークと論理ネットワークは自動的に構成され利用できるようになります。vSANデータストアもホストが保持しているNVMeフラシュデバイスをローカルに保持しているホストで自動的に拡張されます。DRSが新しい物理リソースを検出し、自動的にクラスタのリバランスを実施するため、最も最適化されたリソースが利用できるようになります。

Erastic DRSとHAによる自動回復によって、専属のハードウェアリソースの追加と削除は完全に自動化されることになります。ですが、この話については別の記事でご紹介することにしましょう。

リソース管理の観点からは、心構えが完全に異なるものになります。VMCはインフラストラクチャ構成と管理にかける時間を減らし、リソースの消費によりフォーカスを当てられるようになります。今後数ヶ月でクラスタの構成に何が必要でしょうか? バースト時の戦略は?

残念ながら、サービスがまだリリースされていない現在、詳細をお話することはできません。VMworldではVMware Cloud on AWS関連セッションにびっくりするほどのラインアップを取り揃えています。  私自身も2つのVMworld両方でリソース管理についてのmeet the expertを実施します。この素晴らしいテクノロジーについてもっと話をしたいという方はぜひサインアップして下さい。

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

Screenshot20141105at0820381久しぶりにFrank氏がVMCの記事を更新しましたので、翻訳しました。クラスタにリソースを追加するまでに、何ヶ月かかる?そんな問いかけからスタートします。どの会社も購買プロセスが最も時間のかかるプロセスなのですね。

VMC on AWSも、いよいよ準備が整ってきて、VMworld前後には提供開始されるのでしょうか?ホストごとのリソーつ追加ですので、完全にオンプレミスのvSphereの管理の延長上で管理が行えます。

問題は・・・OPEXになるとは言え、リソースの追加の権限をどこまで持てるのか、というところですね。ITは電気屋、水道のようになれるのか・・・? まだまだIT屋がしなくてはならないことはたくさんあるように思います。

2017/07/26

X-Rayの内部 (Nutanix純正ベンチマークツール)

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSr. Manager, Technical Marketing EngineeringであるPaul Updike氏とManager, Performance EngineeringであるChris Wilson氏によるものです。原文を参照したい方はX-Ray Internalsをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

.NEXT 2017で、我々は新しいX-Rayと呼ばれるツールの公開をアナウンスしました。このツールはハイパーコンバージドインフラ上の検証シナリオの解析を自動化するためのものです。X-Rayを利用することでシステムをより現実的に、そしてシステマチックに評価することができるようになります。我々は検証はより再現性が高く、包括的で、システムが一貫しており、信頼性があり、想定通りに動くことを本稼働環境で利用する前に確認できるべきタイミングに来ていると考えています。それが故に、X-Rayは主にハイパーコンバージドクラスタがしばしば出くわす、現実の状況からのシナリオにフォーカスを当てています。

この記事ではX-Rayの内部をある程度ご紹介し、我々がテストシナリオを実装する際にどのようなことを念頭に置いていたのか、より良く理解していただこうと考えています。ですから、X-Rayが示す結果に確信を持って利用していただくことができます。

コアにおけるシナリオ

X-Rayのシナリオはワークロードワークフローというコアコンセプトにもとづいています。ワークロードとワークフローを結合させることで、単にシステムに負荷をかけるだけではなく、システムのライフサイクル内で出くわす現実のイベントをも盛り込むことができ、シナリオを繰り返して実行することができるようになっています。イベントは仮想マシンのスナップショットのリクエスト、単一ノードの障害発生時のモデル、ノードの電源OFFそして新しいワークロードや仮想マシンの追加などに広がっています。

ワークロードの実装に、我々はオープンソースツールであるFIOをShelfのバックグラウンドで利用しています。 多くのオプションを持つため、このツールは非常に柔軟です。X-Rayのもっとも重要な特徴の一つはワークロードを単に他のツールと同様に一定の並列性で動作させるのではなく、固定のレートで動作させるということです。これによって、より現実的な負荷を発生させることができ、単にピーク時のパフォーマンスを見るのではなく、その負荷による影響を見ることにフォーカスすることができます。X-Rayは標準のFIOの構成ファイルを利用して直接FIOを呼び出します。これによってFIOのほぼすべての構成オプションを柔軟に利用することができるようになっています。

シナリオのワークフローの実装について、我々はYAMLで記述を行うようにしました。YAMLには必要十分で自己完結的な繰り返し可能な検証シークエンスを記述できるようになっています。

ノード障害シナリオにおけるYAML記載の例は下記のとおりです :

Fig249

シナリオの記述については内部的にVM Groupと呼ばれるコンセプトを利用します。VM Groupは仮想マシンの数、配置、そしてその検証に利用する内部のゴールドイメージの場所が記載されたものです。この例ではX-Rayに2つのゴールドイメージが格納されています:

 

Fig250

仮想マシンにアサインされたワークロードの詳細は指定するワークロードとしてFIOの構成ファイルとして記述されます。こうすることですべてのグループの仮想マシンが同じFIOのワークロードで動作するようにすることができます。FIOの構成は特定の仮想化ディスクの構成を想定しているため、とあるワークロードでは特定のゴールドイメージを使う必要があり、そのためのVM Groupをワークロードに紐付ける必要があります。

シナリオのステップはワークフローで実装します : ワークロードの実行、スナップショットの取得、仮想マシンの移行、ノード障害などです。シナリオのステップは2つのフェーズに分解されます。Setuprunです。Setupはシナリオのステップのみに利用し、検証の計測の一部とは考えないで下さい。Setupステップでは大抵、最初の仮想マシンのクローンや仮想マシンの電源On、動作中のワークロードのウォーミングアップなどが実施されます。Runステップでは典型的には障害やその他のイベントを実行しながらの実際のワークロードのスタートと計測が行われます。それそれのステップはコード内に特別な関数として設定されており、これによってどのAPIやAPIセットがステップの完了のために呼び出されるか判断されています。

ユーザーがご自身でシナリオをYAMLで記載することができなかったとしても、そのシナリオが何をしており、YAMLに何が記載されており、どのような検証に利用できるのかをそのデータとともに共有します。

X-Rayのアーキテクチャ

X-Rayは単一の仮想マシンとしてパッケージされており、X-Rayソフトウェアと共に必要なゴールドイメージが含まれています。X-Rayのアーキテクチャは3つの主要コンポーネントに分解することができます : 1) UI(インターフェイス)、2) X-Ray サーバ 、 3) Charon です。

Fig251

下から順を追って説明しましょう。CharonはX-Rayの検証を実行するコンポーネントです。CharonはYAMLの記述を翻訳し、シナリオを表すクラスを作成します。検証のインスタンスは検証ターゲット構成とシナリオの組み合わせで構成されます。インスタンスが作成されるとCharonはシナリオを始めから終わりまですべて検証ターゲット、インフラストラクチャ管理サービス(例: vSphereの場合はvCenter)、そしてシナリオの一部として展開された仮想マシンと通信しながらすべてハンドリングします。インフラストラクチャとのすべての通信にはパブリックなAPIを利用しており、それによってシステムにユーザーや環境とのやり取りをシミュレーションできるようになっています。Charonはpythonで記述されており、vSphere SDKのpython実装であるpyvmomiを利用してvSphereのターゲットと通信を行います。AHVのターゲットとはNutanixのREST APIを利用しており、電源管理機能についてはIPMIを利用します。X-Rayに同梱されているゴールドイメージにはCharonのエージェントが埋め込まれています。このエージェントはワークロードを実行する仮想マシンとインフラストラクチャに依存しないインターフェイスで通信を行えるようになっています。

X-Rayサーバはスタックの中央部で、ユーザーインターフェイスと自身が作り出したCharonインスタンスとの通信を含む他の通信対象との通信のためのAPIを提供します。検証のターゲット構成を維持すること以外に検証の結果や分析についての機能も保持しています。検証ターゲットのセンシティブな情報、例えばパスワードなどは暗号化で保護されディスクへ書き込まれます。検証ターゲットを管理する機能として、同時に1つの検証のみが実行されることを保証します。これはサーバに組み込まれた検証の順番待ち機能を実現しています。サーバはUIに表示されているのと同じデータでレポートを作成する機能も備えています。

X-Rayは最終的にはこれまでになかった現実的なシステムのパフォーマンスの評価を行うためにパブリックなAPIによる自動化とオープンソースのワークロード生成器を足し合わせて実装されています。我々はその結果に確信を持っていただくためにもX-Rayに含まれているものがオープンであるということが重要だと考えています。

X-Rayを初めたいのであれば、https://www.nutanix.com/xray/ へ移動して登録してダウンロードを行って下さい。助けが必要、助言を述べたい、他のユーザーや開発者と会話がしたいなどあれば、X-RayのNEXT Forumに参加して下さい。

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

Ntc2017_2

前回はなぜX-Rayを使うのか?という内容でしたが、今回はその中身のご紹介です。なんとFIOを使っています。しかし、FIOで単純にピークパフォーマンスを図るのではなく、FIOで一定の負荷をかけている際にノードが障害を起こしたら、ファームウェアのアップグレードが行われたら、仮想マシンの数が増えたら・・・と現実的に起こるシナリオをシミュレーションしながらそのパフォーマンスへの影響を観察できるツールになっています。

なんともいいますが、車のアクセルをいっぱいに踏んだら何Km/h(MPH)でるのか?にもはや意味はありません。渋滞や工事の状況を見極めながら最適なドライブルートを描き出すカーナビのようなものでしょうか。

アクセルいっぱい(当然高い!)ではなくできるだけ目的地に早く着く(または安く着く)などの本来の重要な目的に目を当ててほんとうに必要な検証、ひいてはNutanixの購入をご検討下さい。以前のブログにも出てきていますが、Nutanixはたくさん買ってはイケナイ!です。

2017/07/21

【CommVault】CommServe データベースの保護ってどうするの?

こんにちは。

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

Salesforceデータのバックアップなど機能追加されておりますので、ご興味のある方は、CommVault 技術ドキュメントのサイト(こちらをクリック)をぜひご覧ください!

 

さて、今回は、CommVault 管理サーバ "CommServe" のデータベースのバックアップについて、ご紹介したいと思います。

 

CommVault では、通常のバックアップジョブとは別に "管理者ジョブ" というジョブのカテゴリが実装されております。CommServe のインストール後、"管理者ジョブ" はスケジュール化されて定期実行されていますが、以下、代表的な管理者ジョブの一部をご紹介します。

 

  • Data Aging (保持期限切れのデータを再利用するため削除処理するジョブ)
  • Data Verification (取得したバックアップデータの有効性をチェックするジョブ)
  • Disaster Recovery Backup (CommServe上で構成されるデータベースのバックアップジョブ) 
  • Report (バックアップジョブのサマリーやストレージ容量のレポートを出力するジョブ)

 

管理者ジョブの中でも重要なのが "Disaster Recovery Backup" ですが、CommServe の有事の際に CommVault 環境を復旧するために必要なバックアップデータを定期的に取得しています。"Disaster Recovery Backup" は毎日 10:00 AM に実行されていますが、バックアップ運用の状況に合わせて一日数回実行することにより、CommServe を最新の状態に近い状態に復旧することができます。

 

"Disaster Recovery Backup" のステップについて、以下の順で実行されています。

 

Commservedr

 

【CommServe DR バックアッププロセス】

  1. 1.CommServe DR バックアップ処理がデフォルトで毎日午前 10:00 に実行 
    CommServe のインストールパス配下の CommServeDR フォルダに SQL DB がダンプファイルがエクスポートされます。

  2. 次に CommServe のインストールパス配下の CommServeDR フォルダの SQL DB のダンプを、Standby CommServe またはネットワーク共有の UNC パスにコピーします。
    (デフォルト: 5世代フル保持)

  3. 最後に、SQL DB のダンプをストレージポリシー CommServe DR のバックアップ先のライブラリにバックアップを取得します。
    (デフォルト: 60日間、60サイクル(フル)保持)

 

SQL DB のダンプファイルは、CommServe のスタンバイ機が準備されている環境があれば、そのスタンバイ機のローカルディスクにコピーする設定を行うことにより、本番機の CommServe の有事の際に、後述で説明する "CommServe Recovery Assistant" (v11 SP6以降で提供) ツールを使用して復旧を行うことができます。

 

"CommServe Recovery Assistant" は、CommServe のインストールパス配下に存在しております。今回は、CommServe の再構築(同じホスト名) を想定した環境にて、事前準備が完了した後の "CommServe Recovery Assistant" の操作をご説明します。

"CommServe Recovery Assistant" の事前準備では、CommVault 関連のサービス停止などが必要になりますので、製品版の実装後、実際に"CommServe Recovery Assistant"を実施される場合、必ず保守窓口に手順をご確認ください

 

【CommServe Recovery Assistantの実行手順】

  1. CommServe 環境にて、Windows エスクプローラを起動し、インストールパスに移動します。移動後、CSRecoveryAssistant.exe をダブルクリックします。
  2. CommServe Recovery Assistant ウィザードが起動します。[Select the operation type] のオプションで [Recovery] を選択し、[Next] ボタンをクリックします。 

    Csdra1_2

  3. [Enter the path to the database dump folder] - dump ファイルが格納されているフォルダの選択し、[Next] ボタンをクリックします。

    Csdra2_2

  4. [Enter the path to extract the database files] - CommServe データベースの dump ファイルの展開先を指定します。

    Csdra3

  5. [Summary] - リカバリ内容を確認して、[Start Recovery] ボタンをクリックします。

    Csdra5_2

  6. CommServe データベースのリカバリタスクがすべて成功(チェックマーク)で完了したことを確認し、[Next] ボタンをクリックします。

    Csdra6

  7. [Provie a license file (Optional)] - デフォルトのまま [Next] ボタンをクリックします。

    Csdra7

  8. [CommServe recovery completed successfully!!] の表示画面を確認し、[Finish] ボタンをクリックしてウィザードを終了します。

    Csdra8  

"CommServe Recovery Assistant" での CommServe データベースをリストアした後、CommValt 関連のサービスを再開し、各 Media Agent 重複排除データベースの再同期(詳細は、こちら) を行って、CommVault のバックアップ環境の復旧は完了です。

  

"CommServe Recovery Assistant" の操作は、いかがでしたか。

CommServe の有事の際は、バックアップ・リストアを行うことができませんので、SQL DB のダンプから CommServe を復旧する際には、"CommServe Recovery Assistant" をご使用ください。

 

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/07/20

Nutanix AFS 2.1.1 リリース

記事の原文はDerek Seaman氏の個人ブログの記事の翻訳ヴァージョンです。著者は記事翻訳時点ではNutanix社のStaff Solutions Architectとして活動中です。原文を参照したい方はNutanix AFS 2.1.1 Releasedをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

Nutanix AFS 2.1.1 (Nutanix ファイルサービス) のリリースを熱いままお伝えします。ご存知でない方のためにお伝えすると、AFSはNutanixクラスタ上で動作するウェブスケールの高可用性構成の「NAS」です。今回のリリースは重要な様々な機能に加え、多くの問題を解決しています。新しい機能にはいかが含まれます:

  • 展開時のAFSのサイジングワークフロー
  • AFSクラスタの名前の変更機能
  • AHV上のAFSのクローン機能(バックアップ、DR検証、復元などに利用できます)
  • AFSの管理にMicrosoft管理コンソールを利用可能に
  • ファイルサーバ管理者権限でのAFSのパーミッションの管理 (この機能はADユーザー、グループと紐付いています)

完全なリリースノートは こちら。新しいパッケージのダウンロードはこちら

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

Ntc2017_2

5.1.1.1のリリースと合わせてAFSも2.1.1となりました。不定期更新シリーズですが、AOSリリースのときはAFSとのセットでの連投になりそうです、後々の事も考えて、一日開けて投稿します。

2017/07/19

Nutanix AOS 5.1.1.1リリース

記事の原文はDerek Seaman氏の個人ブログの記事の翻訳ヴァージョンです。著者は記事翻訳時点ではNutanix社のStaff Solutions Architectとして活動中です。原文を参照したい方はNutanix AOS 5.1.1.1 Releasedをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

本日、Nutanix AOS 5.1.1.1の一般公開をアナウンスできることを大変喜ばしく思います。今回はパッチリリースですが、幾つかの新しい機能も含まれています。期待のとおり、セキュリティパッチ(合計11)と多くの解決済み問題のリストが含まれています。完全なAOS 5.1.1.1のリリースノートはこちら そしてパッケージのダウンロードはこちらです。あらゆるアップグレード際には事前に必ずリリースノートに目を通し、すべての前提条件に合致していることをご確認下さい。よくできたインストールとアップグレードのドキュメントがこちらにあります。こちらも是非アップグレード前に目を通して下さい。

新しい機能としては以下のものが含まれます:

  • Nutanix API v3 テックプレビュー
  • Cisco UCS-B シリーズサーバに対する ソフトウェア Only でのサポート 一般公開
  • vSphere 6.5に対する拡張サポート (例 Dell XC)
  • ESXi 6.5a および vCenter 6.5の完全サポート

いつものように、このAOSのアップグレードはPRISMから1-クリックアップグレードの手順として実行可能です。ダウンタイムはなく、vMotionも必要ありません。多くのお客様はAOSのアップグレードを日中に実施することもあります。このリリースは現時点では自動ダウンロードが有効になっていません(数週間以内にそうなるでしょう)、ですから自動ダウンロードが有効になる前に必要な場合にはNutanixのポータルからgz パッケージをダウンロードして下さい。もしNutanixを触るのが初めてで、これまでにAOSのアップグレードをしたことがないのであれば遠慮なくサポートへお電話下さい。死ぬほど簡単で、100%GUIでの操作ですが、もしも助けが必要であればです。

もし未だに5.1のリリース列車にアップグレードしていないということであれば、今回はまたとない機会でしょう。

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

Ntc2017_2

新シリーズ、と呼ぶべきか迷いますが、こうした情報が日本語化されていると便利だと思いますので、Derek Seaman氏のブログの更新に合わあせて不定期に翻訳していきたいと思います。もちろん多少のタイムラグはご容赦下さい。

5.1.1.1・・・確かに5.1のリリースは列車のようですね・・・。

なぜX-Rayなのか?(Nutanix純正ベンチマークツール)

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のSr. Manager, Technical Marketing EngineeringであるPaul Updike氏によるものです。原文を参照したい方はWhy X-Ray?をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

ネットワールドのNutanix関連情報はぜひ以下のポータルから取得ください(初回はID、パスワードの取得が必要です)。

我々はX-Rayをシンプルに作り上げました、理由はそうあるべきだからです。X-Rayはハイパーコンバージドインフラストラクチャの効率的なパフォーマンスの検証における問題を解決するものです。

この問題を解決せねばならなかった理由は従来型のiometerやvdbench、そしてfioなどのワークロード生成器は従来型の共有ストレージ装置に対する総攻撃的なスピード検証のために設計されているからです。これに付随する様々な問題があるのです:

  • 単にデータのReadとWriteを行うだけ
  • ストレージのパフォーマンスの上限値が本当に重要なときのために作られている
  • 回転するディスクを検証する時代に取り残されている

根本的にストレージのパフォーマンスが最初の導入時に問題となる場合のために作られており、その次代にはストレージへのアクセスの能力がアプリケーションのパフォーマンスを制限していたのでした。

しかし、SSDがこれを変えてしまいました。

フラッシュはストレージのパフォーマンスについての会話を変えました。ほんの僅かなSSDでアプリケーションの要件を簡単に超えてしまいます。もしSSDの能力を活用したければハイパーコンバージドインフラストラクチャ(HCI)はその方法の一つです。殆どのアプリケーションのボトルネックはCPUの待ち時間であり、ストレージではなくなります。これによってシステムの拡張の方法が変わることになります。

HCIは同じシステム上にストレージも同居しているため、ワークロードの拡張に合わせて段階的に拡張させることが可能となります。これによってストレージ装置がどれだけのワークロードをさばくことができるのかを予測する必要はなくなります。大きな単独のストレージを買う代わりに、ワークロードを何度も追加してゆき、ストレージの規模を拡張しなくてはならないときにだけストレージを拡張すればよいのです。もちろん、システムのパフォーマンスについて理解をしておく必要はありますが、それは意味としては大きく変わります。洗練されていないドラッグレース(ストリートレース)のようなワークロード生成器を使うのではなく、ほんとうの意味でデータセンタ運用に必要なだけの物があるかどうか、ということです。

フラッシュによって殆どのアプリケーションの要件は簡単に満たされます、ストレージパフォーマンスはシステム全体を検証することでより完全にそしてコントロールできる値となります。X-Rayは特徴的なワークロードを動作させ、殆どのテストシナリオでスループット要件を一貫した値で維持します。ストレージパフォーマンスの限界値を検証するのではなく、我々はデータセンタ内で出くわす多くのシナリオにおけるパフォーマンスの一貫性と信頼性の維持の方へフォーカスを移したのです。

これらのよくあるシナリオは以下のカテゴリを含みます:

  • ノイジーネーバー(やかましいお隣さん) ー ワークロードを一つの仮想マシンで実行し、別の仮想マシンで新たなワークロードを実行します。最初の仮想マシン内のアプリケーションは影響を受けるべきではありません
  • ワークロードの追加 ー アプリケーションに合理的にワークロードを追加していきます、ワークロードが追加されてもパフォーマンスへの影響は最小に抑えられるべきです
  • ローリングアップグレード ー ハイパーバイザーや仮想化ストレージコントローラーのアップグレードが行われてもアプリケーションはその受ける影響が最小になるべきです
  • ノード障害 ー ノードが障害を起こした場合も僅かな停止(これはアプリケーションやユーザーが気づくことがないほど小さくあるべきです)と障害後のアプリケーションへの影響も最小となるべきです

フェアなシナリオを実行できるツールがあれば、様々な方法で便利に利用できます。わかり易い例がPOC(Proof of Concept=実証実験)です。X-Rayはシナリオのプロファイルとどんな検証を行っているかを公開しており、テストの選定とテストの実装でバイアスがかからないように作成しています。テスト内容はYAMLで定義して記述することができます。テスト内で実際に利用されるパラメーターは簡単に閲覧し、確認することができます。目的は信頼に足るツールを提供することで、そのためにそのツールが何をこなっているのかを公開しているのです。それ以上に、我々はX-Rayに大きな光を当てています。多くのITスタッフが新しいシステム、ハイパーバイザー、そしてストレージの更新などのために多くの時間を利用しています。この努力は障害を想定したものや運用管理までもを含めたものであるべきですが、それをご自身でやるのは大変で、時間もかかります。こうした努力はその完了までに何週間もの時間を費やすことになり、また問題に突き当たった際には初めからやり直しというリスクもはらんでいます。ここでX-Rayが光り輝くのです。

X-Rayの究極の存在意義はその内部のシステムに負荷をかけながら同時に実行されるイベントの自動化とオーケストレーションです。結果として分析されるのはシステムの安定性、一貫性、予測性(期待通りか否か)です。この機能によってIT組織は迅速に、そしてシステマチックにラボ環境を本稼働させる前に作り変えることができるのです。大抵の場合、X-Rayによる検証をすべて行ったとしても2日ほどしかかかりません。例えば、金曜日の朝にテストを開始させて、完全な結果を月曜日には手に入れられるのです。これによって自動化のない検証を何週間にもかけて行う必要がなくなるかもしれません。Dev/Opsのモデルをもっと取り入れたいというお客様はその導入を加速できるという意味になります。

最初の質問へ戻りましょう、「なぜX-Rayなのか?」

  • 従来型のワークロード生成器(ベンチマークソフト)は新しいニーズには合いません(例:SSD)
  • X-Rayは検証の目的を実際のデータセンタのシナリオに沿ったものにします(ピーク性能→安定性、一貫性、予測性)
  • X-RayはPOCやシステム、ハイパーバイザー、OSの品質/確認のための自動化エンジン
  • X-Rayは透明性があり、信頼に足る

X-Rayを試してみたい場合は : https://www.nutanix.com/xray/

 

© 2017 Nutanix, Inc. All rights reserved. Nutanix is a trademark of Nutanix, Inc., registered in the United States and other countries. All other brand names mentioned herein are for identification purposes only and may be the trademarks of their respective holder(s)

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

Ntc2017_2

今回はNutanix純正のベンチマークツールについて、取り上げました。ベンチマークの話題についてはリクエストやアクセスも多く、本ブログでも定期的に取り上げています。ベンチマーク系の話題で常に付きまとうのはピーク性能にどれだけの意味があるのか?ということです。

上で挙げられている従来型のツールは4Kや16K、ランダム・シーケンシャル、Read/Writeの割合を設定して盲目的にI/Oを生成するものですが、これはストレージがケーブルの外側につながっているときには一定の成果をあげられるものですが、様々な記事でこれまた取り上げているようにI/OパスをVM単位でインテリジェントに管理しているHCI/SDSではもはや時代遅れなやり方です。

また、上にかかれているように、このベンチマークの結果は5年後も(もしくは6年、7年ということも・・・?)性能を保証しなければならないという従来型のパラダイムからの圧力があるからなのです。HCIは必要なときに必要なだけ、足りなくなったら足す、増設時はより早いハードウェアを安価に購入できるというパラダイムでうごいていますので、そもそものピークパフォーマンスに意味はないのです。(もちろん、一部のワークロードでは意味がありますが、SSD、そして今後のNVMe/3D XPointなどで、徐々に一部からほんの僅かの・・・殆どない・・・となっていくことでしょう。)

来週は今度はX-Rayの内部を取り上げる予定です。