2017/08/30

AHVのネットワークの新機能

本記事の原文はNutanixコミュニティのブログNutanix Connect Blogの記事の翻訳ヴァージョンです。原文の著者はNutanix社のStaff Solutions ArchitectであるJason Burns氏によるものです。原文を参照したい方はWhat's New in AHV Networkingをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

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

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

アプリケーションの展開にすごく時間がかかっていませんか? マニュアルでの手順と繰り返されるアプリケーションチームとネットワークチームの行ったり来たりのやり取りは単一のアプリケーションの展開の時間を数時間で済むものから数週間にまで引き伸ばしてしまうこともあります。もしもネットワークがブラックボックスのようなものだったら? もしくはアプリケーションの管理のプロジェクトがどんどん長引いているように思ったら? Nutanix AHVのネットワーキングのツールセットを利用することでネットワーク運用をシンプルにし、アプリケーションを迅速に、そしてセキュアに起動して稼働させることができます。

アプリケーションはこれまで以上にネットワークに依存するようになってきています。アプリケーションの設計のベストプラクティスは複数のコンテナ、仮想マシンもしくはホストを利用してそれ以上分けられない機能毎に分離することを呼びかけています。これによって拡張性と簡単なメンテナンスが実現するからです ー そしてこれらの分割されたかけらはネットワーク越しに相互に接続されるのです。アプリケーションを展開するプラットフォームに関係なく、ネットワークはアプリケーションの一部になっているのです。もしもネットワークに問題があればアプリケーションですぐにその問題が顕在化します。アプリケーションを成長させる、または新しいサービスを追加する必要がある祭に、物理の、そして仮想のネットワークを構成し、新しいコンポーネントが既存のコンポーネントと会話ができるようにしなくてはなりません。もしも攻撃者がアプリケーションの一部に入り込んだとしたら、攻撃者はその同じネットワークを通じてアプリケーションが接続されているすべてのコンポーネントにアクセスができてしまいます。

複雑さの絡むアプリケーションネットワークの展開と管理をうまく行うには3つのことがとても重要です:

  • 可視化
  • 自動化
  • セキュリティ

このブログのシリーズではこうしたネットワークの要件を紐解いていき、Nutanix .NEXTで発表されたワンクリックネットワークを作成するためのAHVの機能を取り上げていきます。

パート 1: AHV ネットワーク 可視化 (本記事)

パート 2: AHV ネットワーク 自動化と統合

パート 3: AHV ネットワーク マイクロセグメンテーション

パート 4: AHV ネットワーク ファンクションチェイン

 

パート 1: AHV ネットワーク 可視化

アプリケーションを仮想環境へと抽象化すると、アプリケーションのパーツ同士のネットワーク接続の可視性を失うことになります。この可視性は、問題を迅速に解決したり、ネットワークが期待通りに動作しているのかをひと目で確認したりするために非常に重要です。

AHVではネットワークのパスの統計や接続状況をPrism ウェブコンソールで追うことができるようにしてあります。単一のインターフェイスから管理者は仮想マシンを単独またはグループで仮想そして物理のネットワークパスに沿って確認することができます。Prismで仮想マシンの上の仮想NICからハイパーバイザーを経由して物理スイッチに至るまでを単一の見やすいポータルで確認することができます。この表示では異なる仮想マシン間の共通するパスを確認でき、以下の図に示すとおり、問題の切り分けを行うことができます。

Fig273

例えば、メールボックスサーバ1と2のネットワークパスがいずれも同じ物理スイッチを利用していることがわかります。パスの全てのホップにおいて、スループットとパケットエラーなどの統計情報を見ることができます。さらに、物理スイッチについてはSNMPを利用してその統計情報を取得し、情報をPrismインターフェイスで閲覧することができます。これらの統計情報によって、これらのメールサーバで共有されているスイッチ、上の例ではEthernet8がエラーを起こしているなどを見抜くことができ、ケーブルの交換を考えることができます。

パスと接続状況を確認することは可視化の素晴らしい第一歩です、そして、ネットワーク接続と状態についての概要をよく示してくれます。しかし、アプリケーションを本当に稼働させているのはネットワークのフローです。

ネットワークフローはIP、ポート、そしてプロトコルについて言及されることがほとんどで、アプリケーションとは完全に切り離されています(が、ファイヤウォールのルールを作るときには必要とされます)。Nutanixのアプリケーションポリシーとフローの可視化はこうしたフローをネットワークの文脈ではなくアプリケーションの文脈で言及してくれます。

以下の図にある通り、我々はExchangeアプリケーションへは定義されたグループからのトラフィックしか受け付けないというルールを作成しています。Nutanix AHVのフロー可視化はポリシーで定義されていないトラフィックの発生元が多くあることを示してくれます。ですから、ポリシーを変更して実際にアプリケーション内で送信、または受信すべきものだけに絞ることができます ー これは実際に有効にする前に実行できます。そして、ポリシーに違反するトラフィックのフローも簡単に見つけることができます。

Fig274

可視化によって、新しく定義しようとしているポリシーの影響範囲を確認することもできますので、実際にそれを適応する前に迅速に修正することもできます。 

後のマイクロセグメンテーションとセキュリティの記事でアプリケーションポリシーの作成については詳細をお話する予定です。 次の記事では自動化と統合を取り上げます。これを利用することでアプリケーションをネットワーク内に簡単に展開し、ネットワークと仮想化チームの間を長くたらい回しになるようなことにならずにすみます。

© 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. 

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

Ntc2017_2

さて、ネットワークについての記事です。NutanixのPrismが見やすい直感的なインターフェイスで、私がそれを大好きなことはこちらこちらでも取り上げています。特にネットワークについては近年の技術の革新も著しいですし、ネットワークの専門家でないのであれば、なかなかトラブルに出くわしたときにその問題の切り分けや原因を探していくことが難しいと思います。

そもそもネットワーク機器ベンダーさんの管理ツールが専門知識を前提にしすぎている、ということもあるかもしれません。

それを解決してくれるのがNutanix AHVのネットワーク可視化機能です。可視化されていることで何がどう間違っているのかはもちろんですし、フローの可視化の方はどんな通信が実際に行われているのかなどもわかりますのでとても直感的です。後の記事に出てくるようですが、表示されている本来は行われるべきでないトラフィックフローを遮断することもできます。非常に直感的ですね。

2017/08/23

HCIとパフォーマンス計測の美学 ー パート2 ー Microsoft SQL Server

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

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

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

Fig271

本シリーズのパート1で、Enterprise Strategy Group(ESG)と共同で行った、Nutanixエンタープライズクラウドプラットフォーム上での4つのエンタープライズクラスでミッションクリティカルなアプリケーションのワークロードについてのパフォーマンスの一貫性、予測性、そして拡張性についての背景を共有いたしました。他のベンダーが公開しているような人工的に生成された単純なI/Oを用いる「英雄の数字」とは異なり、我々は業界の標準となるアプリケーション検証ツールを利用して、現実的なワークロードを使うことにフォーカスしていたことを思い出して下さい。パート2では、我々はMicrosoft SQL Serverを利用した検証について、更に奥深く分け入りたいと思います。

検証のためのワークロードを選ぶ際に我々はデータとお客様からのフィードバックに大きく依存しています。SQL Serverは最も展開されているエンタープライズ・アプリケーションのリストのトップにおり、これは大した驚きでは無いでしょう。様々な場面で利用されていますから、そのパフォーマンスの要件も幅広いものとなります。ですから、検証のためにリファレンスとしての標準が必要となります。幸い、オンライントランザクション処理(OLTP)のような一般的なデータベースのワークロードのための優れたツールが開発されており、検証のパラメーターとそれがどのように実環境のワークロードとして適応されるのかを理解していればその実行はさほど難しいものではありません。最終的にはQuestのベンチマークファクトリーを利用することにし、更に業界標準のTPC-Eワークロードを利用することにしました。Questのドキュメントに検証のためのTPC自体の説明書きがあります:

「TPC-Eベンチマークはデータベースを証券ファームのお客様が利用することをモデルとしており、取引や会計審査、市場調査などのトランザクションを生成します。証券ファームは金融市場とやり取りし、お客様の代わりにオーダーを実行し、対応する金融情報を更新します。

このベンチマークは「拡張性」があります。つまり、証券ファームの顧客数は証券ファーム毎に様々に定義でき、ビジネスの規模はそれに応じて変化するのです。このベンチマークではベンチマーク内で実行されるトランザクションの混合具合も定義する必要があります。TPC-Eの計測は毎秒のドランザクション数(tps - tranaction per second)で与えられます。この値はサーバが一定の期間内でどれだけの取引結果のトランザクションを実行できたかという値となります。」

4台のWindows Server 2012 R2の仮想マシンで、SQL Server2016を稼働させた(物理ノードあたり1つずつ)後、我々はNutanix上におけるアプリケーションのベストプラクティスを参照して適切に構成を行いました。SQL Serverのための手引にはデータベースを作成する際に1つ以上のデータファイルを作成し、それぞれのデータファイルを別々のおライブへ割り当てます。完全な詳細についてはMicrosoft SQL Server Best Practices Guideをご参照下さい。オールフラッシュのNutanixクラスタが適切に構成されているため、OLTPデータベースの検証は大抵はCPUによって決まります。我々はホストのCPUに適切な余力を残しながら、仮想マシンに適切なvCPUの構成を入れることに重点的にフォーカスして、最大の毎秒のトランザクション数が一貫して提供ができるようにしました。ホストのCPUの利用率はほとんどの本稼働系システムの場合で最大でも80%であると考え、この閾値を下回ることが無いように検証をチューニングしました。

OLTPデータベースを検証する際には様々な検証構成のパラメーターがあり、これが結果に大きく影響します。それらのうちの一つがデータベースのサイズであり、ベンチマークファクトリーでは「scale factor」として設定できます。非常に小さなデータベースを使って検証することでtpsのスコアを釣り上げることもできましたが、我々は現実的なサイズである300GB(scale-factorは32)をそれぞれのデータベースインスタンス毎に設定しました。データベースを完全利用するため、我々は最終的にはエージェント仮想マシンから各々のデータベースに対して80同時ユーザーで付加生成しました。テストのパラメーターとしては「no think time(考えている時間は加味しない)」を設定しています。

ハイパーコンバージドインフラストラクチャの検証においてパフォーマンスの拡張性は非常に重要です。ESGは特にOLTPのパフォーマンスの拡張性とより多くの仮想マシンとインスタンスをクラスタに追加した際のワークロードの分散に興味を持ちました。ですから、単一仮想マシンとSQLサーバインスタンスの最適な構成を決めるための様々な事前検証を終えた後、検証はそれぞれの仮想マシン数で実行されており(1から4)、仮想マシンとインスタンスを追加する毎に予測通りのパフォーマンスの拡張がなされることを確認しています。以下の画像で確認できるとおり、tpsがリニアに拡張されるだけでなく、平均トランザクション応答時間は低く、さらに特筆できるほどに安定しています。

Fig272

テストの結果、インスタンスあたりの毎秒のトランザクション数の総計は2,635~2,703と非常に狭い幅に収まっており、平均すると2,658です。ワークロードをスケールさせると、ESGは特にそのレスポンスタイムに感心していました。「ESGにとって更に印象的だったのは平均トランザクション応答時間でした、これは単なるストレージのレイテンシ以上のものだと考えることができますが、データベースの応答についてはコンピューティングが決定因子であるということがわかります。Nutanixのソリューションは一貫してワークロードが動作している4ノード全てで、0.031秒という超速のトランザクション時間を提供しているのです。」

パート1で言及したように、我々の検証はアプリケーションレベルでのパフォーマンスにフォーカスしていますが、その下のストレージのパフォーマンスに全てついても監視を行っており、平均のストレージのReadとWriteのレイテンシはそれぞれ0.95と1.59ミリ秒であったと記録されています。この低遅延によって、適切にCPUを稼働させることで最良の結果になるということがはっきりとわかります。この結果をより良い文脈で理解するために、これはOLTPでの検証だということを忘れてはいけません。すべての検証は継続的に行われたものです。言い方を変えるとターゲットとなるパフォーマンスは最高でかつ、少しの変動はありながらも安定的なものであるということです。もしも適切に構成されていればtpsの結果は狭い幅に「収まる」のであり、そのポイントに一貫してテストを停止するまであり続けます。これは実環境におけるパフォーマンスの能力を現実的に図っているといえることになります。

我々の検証に先駆けて、ESGは現在のハイパーコンバージドの市場を調査し、いくつかの結論に至っています。そのうちの一つが「コンピューティングおよびストレージの両方を活用するトランザクションヘビーなアプリケーションという観点からは、ハイパーコンバージドソリューションは予測性のある一貫したパフォーマンスを拡張時に提供することができない」というものでした。我々の検証をもとにすると、彼らは残念なことにその誤った概念を認めなくてはなりませんでした。つまり「・・・[Nutanixの]OLTPデータベース環境はデータベースインスタンス数が倍になっても予測性のあるパフォーマンスを提供できる、加えてクラスタ全体にIOPSが分散したとしても応答時間は一貫して低く、さらにデータがより大きくなったとしてもそれが実現できる」

個人的にこの結果を見直した際に、私は更に幾つか思うところがありました。自身のキャリアを最近はストレージのパフォーマンスやフラッシュ関連の現場に費やしているため、私はオールフラッシュのソリューションを導入することでデータセンタに一貫した、継続的なパフォーマンスをも足らせる可能性があるということは知っていました。しかし、このオールフラッシュを完全に利用するとなると、従来のメディアに加えてより多くのCPUサイクルが必要になります。CPUをより多く利用するSQL Serverのようなアプリケーションの要件を考えあわせるとこれはパフォーマンスについての麻薬のようなものになりかねません。最終的に我々は超低遅延をホスト内のストレージ(データローカリティ)で実現することができることを示し、さらにあらゆる他のオーバーヘッドを排除できることも示すことができました。ほぼリニアなIOPSと拡張しても低遅延を維持できることが合わさっていることがNutanixプラットフォームのパフォーマンスの秘伝のタレなのです。

SQLの検証とパフォーマンスの数字の詳細についてはESGのレポートを入手して下さい。そして、Nutanix Nextコミュニティでどう思ったのか教えてください、そして更に会話を続けましょう。

レポートはこちらからダウンロードできます。

議論しましょう : 我々のコミュニティのフォーラムで会話をづづけましょう。  

© 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さん、やっぱり訳しにくい!(笑) 今回は前回のパート1に引き続いて、SQL Serverのパフォーマンスについて更に詳細が明かされます。ですが、記事を読んで分かる通り、問題はストレージではなくCPUです。Nutanixには強力なCPUを搭載することができますが、その強力なCPUを用いてさえ、オールフラッシュ構成のNutanixのストレージパフォーマンスを圧倒することは(OLTPでは)できません。

Andyさんが言うように、アプリケーションのことを考えるとHCIをストレージとして評価することがどれだけ愚かなことなのか、そしてその評価でものを買ってしまうと・・・ゾッとしますね。

また、NutanixのスケーラビリティについてもESGの当初の想定を覆すほどの結果だったということも重要です。Nutanixはローカリティがありますので仮想マシンから見たときに、そのI/O性能を決めるノードはわずか、2(RF2の場合、RF3なら3)ノードです。どんなにクラスタが大きくなってもこの鉄則は崩れることがありません。スケーラビリティというより、実際にはスケールアウトしても影響範囲が限定的なのでリニアに性能を伸ばしていくことができるのです。この考え方はAndyさんの古巣のPernixDataと同様ですね。

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とのセットでの連投になりそうです、後々の事も考えて、一日開けて投稿します。