本記事の原文は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記載の例は下記のとおりです :
シナリオの記述については内部的にVM Groupと呼ばれるコンセプトを利用します。VM Groupは仮想マシンの数、配置、そしてその検証に利用する内部のゴールドイメージの場所が記載されたものです。この例ではX-Rayに2つのゴールドイメージが格納されています:
仮想マシンにアサインされたワークロードの詳細は指定するワークロードとしてFIOの構成ファイルとして記述されます。こうすることですべてのグループの仮想マシンが同じFIOのワークロードで動作するようにすることができます。FIOの構成は特定の仮想化ディスクの構成を想定しているため、とあるワークロードでは特定のゴールドイメージを使う必要があり、そのためのVM Groupをワークロードに紐付ける必要があります。
シナリオのステップはワークフローで実装します : ワークロードの実行、スナップショットの取得、仮想マシンの移行、ノード障害などです。シナリオのステップは2つのフェーズに分解されます。Setupとrunです。Setupはシナリオのステップのみに利用し、検証の計測の一部とは考えないで下さい。Setupステップでは大抵、最初の仮想マシンのクローンや仮想マシンの電源On、動作中のワークロードのウォーミングアップなどが実施されます。Runステップでは典型的には障害やその他のイベントを実行しながらの実際のワークロードのスタートと計測が行われます。それそれのステップはコード内に特別な関数として設定されており、これによってどのAPIやAPIセットがステップの完了のために呼び出されるか判断されています。
ユーザーがご自身でシナリオをYAMLで記載することができなかったとしても、そのシナリオが何をしており、YAMLに何が記載されており、どのような検証に利用できるのかをそのデータとともに共有します。
X-Rayのアーキテクチャ
X-Rayは単一の仮想マシンとしてパッケージされており、X-Rayソフトウェアと共に必要なゴールドイメージが含まれています。X-Rayのアーキテクチャは3つの主要コンポーネントに分解することができます : 1) UI(インターフェイス)、2) X-Ray サーバ 、 3) Charon です。
下から順を追って説明しましょう。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)
前回はなぜX-Rayを使うのか?という内容でしたが、今回はその中身のご紹介です。なんとFIOを使っています。しかし、FIOで単純にピークパフォーマンスを図るのではなく、FIOで一定の負荷をかけている際にノードが障害を起こしたら、ファームウェアのアップグレードが行われたら、仮想マシンの数が増えたら･･･と現実的に起こるシナリオをシミュレーションしながらそのパフォーマンスへの影響を観察できるツールになっています。
なんともいいますが、車のアクセルをいっぱいに踏んだら何Km/h(MPH)でるのか?にもはや意味はありません。渋滞や工事の状況を見極めながら最適なドライブルートを描き出すカーナビのようなものでしょうか。
アクセルいっぱい(当然高い!)ではなくできるだけ目的地に早く着く(または安く着く)などの本来の重要な目的に目を当ててほんとうに必要な検証、ひいてはNutanixの購入をご検討下さい。以前のブログにも出てきていますが、Nutanixはたくさん買ってはイケナイ！です。
