« 2016年11月 | メイン | 2017年1月 »

2016年12月

2016/12/28

NetBackupで仮想マシンの瞬間リカバリ!

はじめまして、宮内と申します。
普段は主にバックアップ製品を担当しています。以後お見知りおきを!

初めてのブログでご紹介するのはVeritas NetBackup
もともと高性能で有名なバックアップソフトウェアですが、最近はアプライアンスの新バージョン登場、ソフトウェア でも12月に新バージョン登場、と注目度が更にうなぎのぼり!(と思います)
こちらのブログでも、重複排除とアクセラレータ、 クラウド連携( API編クラウドゲートウェイ編 )、 SelfService など、過去に何度かホットな機能の紹介をさせていただいていますね。
一方で、便利なのに認知度の低い機能もちらほら。。
そこで!私からは、ちょっとニッチな便利機能を紹介したいと思います。

前置きが長くなりましたが、今回はインスタントリカバリ機能をご紹介します!

インスタントリカバリ(略称IR)とは:
バックアップデータを直接ESXiにマウントして仮想マシンを即座に起動させる機能

こんなイメージです↓

1

バックアップデータをESXiのデータストアに移動させることなく仮想マシンファイルを読み出すので、普通のリカバリよりも迅速に復旧できます。

IRは、以前のバージョンから搭載はされていたのですが、コマンドでしか操作できず、(GUIしか使えない初心者の私にとっては)ハードルの高いものでした。
NetBackup 7.7からはvSphere Web ClientからGUI操作でできるようになり使いやすくなったので、胸を張って紹介できます!
※8.0から搭載されたInstantRecovery for Hyper-Vは従来通りCLI操作です。

インスタントリカバリが使えるようになるまでの道のりはこちら↓

2 もうちょっと設定手順が簡単だといいんですが。。贅沢は言わない。

Webサーバーは既存のものがあればプラグインのインストールのためだけに作成しなくても大丈夫です。

それではインスタントリカバリをしていきましょう!
せっかくなのでNetBackupのプラグインは最新バージョンの 8.0 を入れてみました!!
※スクリーンショットには開発段階のものを含みます。


vSphere Web Client からのIRの流れはこちら↓

3

プラグインを入れた状態でvSphere Web Clientを起動します↓

4 赤いマークが目印です。

5つ並んだボタンの中から「Instant Recovery Wizard」を選んでリカバリ開始↓

5 あ、もちろんですが、リカバリの前に仮想マシンのバックアップはしておいてくださいね!

リカバリしたい仮想マシンを選びます↓

6 右下の"Add Virtual Machines"をクリックします。
左上に現在選んでいる仮想マシンの台数が表示されます。

リカバリするデータとか場所とか名前とか設定します↓

7

8

9

リカバリ前にはチェックが必要です↓

10 チェックが済んだらインスタントリカバリ実行!

すぐに起動してきました!↓

11 今回はIRしたマシンに「○○-irv」と名前をつけています。

12 こちらはNetBackupの管理画面。
今回は2分弱で2台の仮想マシンが起動したことが確認できます。

1台目は約30秒でリカバリできました。ちなみに、同じ仮想マシンを通常のリストアで復旧させたら、1台で約26分かかりました。
IRによって、リカバリ時間が1台あたり約25分の1まで短縮できましたね!
※本検証環境における参考値です。短縮できる時間は環境によって異なることがあります。

なお、NFSがうまく動作していないとリカバリに失敗することがあります。
リカバリ失敗時にNetBackupサーバーではステータスコード「5」が、Web-Clientのタスクでは「無効なデバイスです」といったメッセージがそれぞれ表示されていたら、NFSの不調を疑いましょう。
そんなときはバックアップサーバーで以下のコマンドを実行し、NFSの再起動を行ってみてください。

さて、IRは一時的にバックアップデータをマウントしており、起動した仮想マシンも一時的に使用することを前提としています。
そのため、このままではNetBackupのジョブが終了にならないので、必ずIRの終了処理が必要になります。

13 緑の走っている人のアイコンはジョブが実行中であることを示しています。

IRの終了処理には以下の2つがあります。

  • 仮想マシンを使い続ける:Initiate Instant Recovery Done
  • 仮想マシンを削除する:Deactive

"Initiate~"はvMotionで仮想マシンファイルをESXiのデータストアに移動させていないと選択できないので注意です。

終了処理はInstant Recovery Cleanupボタンから↓

14

ポップアップウィンドウの上部から仮想マシンへの処理を選択します↓

15 今回はvMotionを実行していないため、2台とも"Deactive"処理を行います。

16 リストに仮想マシンが表示されなくなったら全ての仮想マシンに対して処理が完了したサインです。

NetBackupの管理画面でも全てのアイコンが青色(ジョブ終了のマーク)になりました↓

17


以上でインスタントリカバリの操作は一通り終了です。いかがでしたか?

最後に、流れの中で紹介しきれなかったものも含め、インスタントリカバリのメリット・デメリットを書いて終わりにしようと思います。

メリット

  • とにかく仮想マシンの起動が早い
  • 一度に複数台の仮想マシンをリカバリできる(通常のリカバリは1台ずつ)
  • VM管理者(バックアップ管理者以外)がvSphere Web Clientからリストアできる

デメリット

  • インスタントリカバリが使えるようになるまでの設定が面倒
  • 復旧時の設定は通常のリカバリに比べて指定できる項目が少ない

ありがとうございました!皆様良いお年を!

宮内

Nutanix Acropolis ファイルサービスについて知っておくべき10の事

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

当社のNutanix社製品についてはこちら

我々はすばらしい機能それぞれについて、将来のリリースで含まれる機能をご紹介する新しいブログシリーズ「10の知っておくべき事」をスタートします。以前のリリースで、この将来のリリースの機能の登場は多くの素晴らしい機能、例えばAcropolis ファイルサービス、セルフサービスポータル、ネットワーク可視化、その他たくさんなど、は予告されていたものです。ではまずAcropolis ファイルサービス(AFS - Acroplis File Service)についての10の知っておくべき事から初めましょう:

  1. AFSを利用すれば別途ネットワーク接続ストレージ(NAS)アプライアンスを用意する必要はなくなります。AFSはソフトウェア定義のスケールアウト型ファイルストレージソリューションでSMB/CIFSの幅広いユースケースをカバーできるように設計されており、Windowsユーザープロファイルの格納や、ホームディレクトリ、組織間での共有を実現できます。あらゆるAVHまたはESXiのクラスタ上で有効にすることが出来、Nutanixの管理ソリューションであるPrismから2,3回クリックするだけで利用することが出来ます。
  2. AFSは完全にNutanixのエンタープライズクラウドプラットフォームのコアコンポーネントと統合されています。既存のクラスター上に展開すること、スタンドアローンのクラスタに展開することの療法が可能です。スタンドアローンのNASアプライアンスとは異なり、AFSは仮想マシンとファイルストレージを統合することが出来るため、別々のインフラストラクチャのサイロを作る必要はなくなります。AFSも仮想マシンサービスと同様にNutanix Prismから管理を行うことが出来るため、管理の統合、簡素化を実現します。
  3. AFSはそれを支えるNutanixエンタープライズクラウドプラットフォームからインテリジェントな階層化、重複排除、イレイジャーコーディング、圧縮、そして分散化による自己治癒などの優れたエンタープライズストレージの機能を継承しています。
  4. AFSは最低で3台のファイルサーバ仮想マシンを必要とし、それぞれのファイルサーバ仮想マシンは最低 4 vCPU、12GBのメモリを必要とします。AFSクラスタのパフォーマンスは簡単にスケールアップ(vCPUとメモリをさらにファイルサーバ仮想マシンへ追加する)またはスケールアウト(ファイルサーバ仮想マシンを更に追加する)によって、改善することが出来ます。
  5. AFSはSMBをサポートし、Active Directoryと連携して動作します。
  6. AFSはユーザーと共有のクオータをサポートします。
  7. AFSはアクセスベースのイニューメレーション(Access Based Enumeration - ABE)をサポートします。
  8. AFSはWindowsの以前のヴァージョンの復元をサポートしており、ユーザーによるセルフサービスでの復元を実現します。
  9. 共有領域の3rd パーティによるバックアップについてはCommvault社などのベンダーから提供される従来からのファイルバックアップを利用することが出来ます。バックアップは別のNutanixクラスタまたは、パブリッククラウド(AWSとAzure)に対して行うことも出来ます。
  10. AFSでは別のNutanixクラスタへの統合された自動災害復旧を利用することが出来ます。

Fig148

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

さて、ネットワールドらぼではNutanixコミュニティではじまった「10の知っておくべきこと」シリーズの翻訳を行っていきます。まずはAFS。これ自体はファイルサーバの機能を提供するだけ(もちろん、Nutanix流にスケールアウトしますので、サーバ1台単位でのPay-as-you-growなのは魅力です!)なのですが、素晴らしいのはNutanixクラスタ内に共存させることが出来るということです。仮想マシン用のストレージとファイルサーバストレージ、ほとんど似たような(もしくはユニファイドで同じ筐体にすることもあるでしょうが・・・)ソリューションを別々に管理したいとは誰も思っていないはずです。Nutanixではこれに加えて更に仮想環境の管理も統合することが出来ますので、社内のITインフラの管理をあの優れたPrismだけで行うことが出来てしまうのです。

今後も様々なSMB/CIFSのユースケースに対応するようなロードマップがひかれているようですので、今後ファイルサーバ専用機はなくなっていく、、、正にWikibonのServer-SANについての予測を象徴するような機能についての10の知っておくべきことでした。

2016/12/23

NutanixでのVDI/SBCサイジングの実践

こんにちは、ネットワールドの海野です。

Nutanix Advent Calendarということで、 ネットワールドらぼ には初めての投稿です。

今回の記事ではNutanix環境におけるVDIとSBCについて、実践的なサイジングへのアプローチをご紹介しようと思います。

※注1 : NutanixのSizerは定期的にアップデートが行われ、画面や設定内容が変更や調整されます。ご利用時点の最新版とは異なる可能性がございますので、ご了承ください。

※注2 : ここでご紹介する構成やスペック値はサンプルとしてご提供する情報であり、何らかの保証を行うものではございませんので、ご了承ください。

自己紹介

ネットワールド入社当初からCitrixの製品を担当しており、ふだんはXenDesktop(VDI)/XenApp(SBC)のプリセールスSEとしてお問い合わせ対応や構築作業のほか、トラブルシューティングに関するご相談を受けたり、当社で開催しているセミナーや無償ハンズオントレーニングの講師をしています。

よくいただくご相談 : サイジング

その中でよくご相談をいただくのが「XenApp/XenDesktopの推奨スペックとハードウェア構成を教えてください!」というものです。

いわゆるサイジングのお話です。

今年のNutanix Advent CalendarではNutanix島崎さんがSizerに関する記事を寄稿されていますが、このSizerを利用することで複雑と思われがちなVDIやSBCのサイジングや機器選定という課題をシンプルかつスマートに解決することができます。

基本的なSizerの概要や使い方については島崎さんの記事をご覧ください。

Sizerを使ったサイジングの前に…! 要件を整理しましょう

サイジングと機器選定というゴールに向かうためには要件の整理が必要です。

まずは要件を整理し、Sizerへのインプットに落とし込んでいく作業を行います。

私がご相談を受ける際にお客様へお伺いする主な内容としては、以下の項目が挙げられます。

・利用目的と利用形態

・想定負荷とユーザー数

・仮想マシンの展開方法

・冗長性

・接続元

今回のサイジングシナリオはこちら

というわけで、シナリオ(お客様のご要望)を以下のもので想定します。

・利用目的と利用形態 : テレワーク実現のためのXenDesktop(VDI)環境

・想定負荷とユーザー数 : Officeドキュメントの編集やブラウザー閲覧などの300ユーザー

・仮想マシンの展開方法 : Machine Creation Services (MCS)

・冗長性 : あり

・接続元 : テレワーク実現なので、社内以外に社外からも接続する

実践その1 : Sizerにどう入力していくか? (ユーザー用のリソース)

では、このシナリオをもとにSizerに入力していきます。

Sizerを起動し、シナリオの名前(SCENARIO NAME)を入力します。

ここでは「VDI for Telework 300 Users」としました。

01

まずはユーザーさんが業務で利用するためのVDIリソースをXenDesktopのワークロードとして追加します。

02

今回のシナリオでは「Officeドキュメントの編集やブラウザー閲覧など」という使い方を想定しています。

Sizerではその用途にピッタリの"Knowledge Worker"という選択肢がありますので、これが300ユーザー分という入力をします。

なお、ここではワークロードのカスタマイズなどは行わず、冗長性に関する内容もデフォルトのままで進めます。

03

すると、このような結果が表示されました。

今回のシナリオのVDIリソースを賄うには、このNutanixがよいという指針になります。

04

管理コンポーネントのリソースを追加する前に… (コンポーネントの整理と確認)

XenDesktopを利用するためには仮想デスクトップだけを用意すればよいというものではなく、さまざまな管理コンポーネントが必要です。

Sizerを利用して管理コンポーネントのリソースを追加していきましょう。

XenDesktopの管理コンポーネントとして代表的なものをここにピックアップします。

・Delivery Controller

・StoreFront

・SQL Server

・Citrix License Server

今回のシナリオでは、論理的な障害に備えて各コンポーネントを冗長化する方針とします。

さらに、可能な限りWindows Serverの台数を削減するべく、複数のコンポーネントを同居させる構成とします。

それを踏まえ、弊社の無償ハンズオントレーニングでは以下のサーバー構成案をご紹介しています。

・サーバー1 : Delivery Controller / StoreFront / Citrix License Serverを同居

・サーバー2 : Delivery Controller / StoreFront / ウィットネス用のSQL Expressを同居

・サーバー3 : ミラーリングされたSQL Server (プリンシパル)

・サーバー4 : ミラーリングされたSQL Server (ミラー)

では、この1~4のサーバーですがどれくらいのスペックでサイジングをすればよいでしょうか?

詳細は弊社の無償ハンズオントレーニングで解説しておりますが、それぞれ次のようなスペックが目安となります。

・サーバー1 : 4vCPU / メモリ8GB / ディスク100GB 以上

・サーバー2 : 4vCPU / メモリ8GB / ディスク100GB 以上 (サーバー1と同じ)

・サーバー3 : 2vCPU / メモリ4GB / ディスク100GB 以上

・サーバー4 : 2vCPU / メモリ4GB / ディスク100GB 以上 (サーバー3と同じ)

この情報を使ってワークロードを入力してみましょう。

※注3 : 上記のスペックはあくまで一例です。シトリックス社からはサイジングについて以下のホワイトペーパーが提供されていますので、こちらもご参考としてください。

Citrix VDI Best Practices for XenApp and XenDesktop 7.6 LTSR

実践その2 : 管理コンポーネント用のリソースを入力

ここでは入力をシンプルにするために、Workload Typeを「Server Virtualization」で進めます。

ワークロードの名前は「Management Resource」としました。

05

先ほど紹介したスペックの目安を満たすために、Server Profileは「Large」を選択します。

Server Profileについては島崎さんの記事に解説があります。

06

また、ここでもワークロードのカスタマイズなどは行わず、冗長性に関する内容もデフォルトのままで進めますと、入力した結果が反映された内容が表示されます。

07

実践その3 : NetScaler Gateway VPXのリソースを入力

社内でXenDesktopを利用する分には以上の内容で十分ですが、今回の想定シナリオは「テレワーク実現のためのVDI」ということで、社外から社内への接続を実現する仮想アプライアンスであるNetScaler Gateway VPX(以下、NS VPX)のリソースを追加していきます。

なお、NS VPXを利用する場合、ユーザーデバイスに対し画面転送データのみをやり取りするためファイルが手元の端末に残らないような使い方ができるなど、一般的なVPNと比較して非常にセキュアであるということが強力なメリットとして挙げられます。

ここでは、NS VPXのワークロードもServer Virtualizationで入力します。

08

NS VPX バージョン11.1のデフォルトの仮想マシンスペックは、Server Profile : Mediumで満たすことができます。

また、XenDesktop管理コンポーネントと同様に冗長化を考慮して、2台のNS VPXを配置します。

09

最終的なXenDesktop環境のサイジング結果

Sizing Summaryはこのようになりました。

リソースの使用率は上がりましたが、変わらず4ノード構成でOKという結果が表示されました。

検討に必要な材料(要件)があれば、とてもカンタンにサイジングと機器選定ができるということがお分かりいただけるかと思います。

10

XenAppはどうする?ユーザー数の変更はどうする? : シナリオのクローン

Sizerではシナリオのクローン機能を使うことで、簡単にいろいろなパターンを検討することができます。

いま作成したシナリオをそのままXenAppでの300ユーザー構成に置き換えてみましょう。

まず、作成したシナリオのクローンを行います。

ここでは「XenApp for Telework 300 Users」としました。

11

既存のWorkloadsからVDI用に設定した「User Resource」を削除し、新たに「XenApp Resource」を作成します。

Workload Typeは「RDSH/XenApp」を選択します。

12

Windows Server 2012 R2上で動作するXenAppの想定で入力を進めます。

13

ここではサンプルとして以下の値を入力しました。

なお、ドキュメントを編集するユーザーを想定していますので、ユーザープロファイルなどは大きめに見積もっています。

14

そのままデフォルト設定を前提とすると、数クリックでサイジングの結果が出力されます。

15

その他、ユーザー数の変更であれば同様にシナリオをクローンし、ユーザー数を調整するだけでサイジングを行うことが可能です。

まとめ

Sizerを使えばとてもカンタンに複数のサイジングや機器選定のプランニングをすることができます。

XenDesktopやXenAppの基盤をNutanixでご提案いただき、スピード感のあるサイジングと機器選定を試していただければと思います。

 

しかしながら、どのコンポーネントをどういったスペックで組むかというのは、ノウハウや経験が必要な部分であり、難しく感じている方もいらっしゃるのが実情かと思います。

当社では定期的にXenApp/XenDesktop/NetScalerの無償ハンズオントレーニングを実施しており、当社の経験に基づく最新情報をご提供しております。

さらにNutanixについてもイベントを開催しておりますので、今後も当社のイベントにもご期待いただければと思います。

2016/12/21

Nutanix 5.0の機能概要(Beyond Marketing) パート4

本記事はNutanix Advent Calendar 2016への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。当社からは私とSEの工藤が寄稿します。

本記事の原文はNutanix社のPartner Innovation and Vertical Alliances, Sr. Directorを務めるAndre Leibovici氏によるものです。原文を参照したい方はNutanix 5.0 Features Overview (Beyond Marketing) – Part 4をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら

また、以下のセミナーでも本記事の内容を詳しくご説明しますので、是非ご来場ください!

Nutanix/VMware 2大メーカー ヨーロッパイベントからの最前線
ウィーンで開催された「Nutanix .NEXT Conference EUROPE」とバルセロナで開催された「VMworld EMEA」からの情報 2本立て

すでに東京での開催は終了していますが、大阪での開催もございます!

これは本シリーズの4番目の記事です。最初の記事はこちら2つ目3つ目

免責事項 : あらゆる将来の製品又はロードマップ情報は製品の方向性を示すことを意図しており、Nutanixが提供するあらゆる情報、コード、機能に対してコミット、お約束、法的な義務が生じるものではありません。この情報を用いて、購入を決めるべきではありません。また、Nutanixは将来の製品改善、機能が最終的に利用できるようになった際に追加での課金を行うことや、最終的に改善された製品や機能のために別途の課金を行うことを現時点では決定していません。

機能や時間軸についてのオフィシャルな情報についてはNutanixのオフィシャルなプレスリリースをご参照ください。(こちら)

以下はこのブログ記事でご紹介してきた機能です:

  • Cisco UCS B-シリーズ ブレード サーバ サポート
  • Acropolis アフィニティ と アンチ-アフィニティ
  • Acropolis ダイナミックスケジューリング (DRS++)
  • REST API 2.0 と 3.0
  • XenServerのサポート TechPreview
  • ネットワーク可視化
  • 新しいワークロードのためのWhat-if分析と割当ベースのフォーキャスティング(予測)
  • ネイティブのセルフサービスポータル
  • スナップショット - セルフサービスリストアのUI
  • ネットワークパートナーインテグレーションフレームワーク
  • メトロアベイラビリティウィットネス
  • VMフラッシュモードの改善
  • Acropolis ファイルサービス 正式リリース (ESXi と AHV)
  • Acropolis ブロックサービス (CHAP認証)
  • AHVのOracle VM と Oracle Linuxへの認定
  • AHVのSAP Netweaver Stackへの認定
  • Prism サーチの改善(ブール表現のサポート)
  • I/O メトリクスの可視化
  • 1-クリックライセンシング
  • LCM – Lifecycle Manager(ライフサイクルマネージャー)
  • 追加のPrismの改善点
  • AHVの拡張性の改善
  • AHVのCPUとメモリのホットアド(Tech Preview)
  • コールドデータのアドバンスドコンプレッション
  • バックアップベンダーのためのAcropolis チェンジブロックトラッキング(CBT) 
  • 自発的なQoSによる期待通りのパフォーマンス
  • NCC 3.0 の Prism への統合
  • 1-ノード レプリケーションターゲット
  • QoSによる混在したワークロードのサポートの改善
  • SATADOMの交換ワークフローのシンプル化
  • 適応型レプリカ選定によるノード混在のサポート
  • 動的なイレイジャーコーディングのストライプの縮小 - ノードの削除時
  • メタデータ用のノード上の利用可能な複数のSSDをメタデータディスクとしてサポート
  • コンテナにおけるイレイジャーコーディング(EC)のレプリケーションファクタ(RF)の変更のサポート
  • OpLogのインライン圧縮
  • (New) Linux カーネルアップグレード

私はNutanix 5.0の新機能についてのアナウンスは全て終えたと思っていましたが、読者のうちの一人 Tom Hardy氏がAHVのLinuxカーネルアップグレードについて紹介し忘れているよ!と教えてくれました。間違いを犯したときに喜んでサポートしてくれたり、注意をしてくれる素晴らしい読者がいるのはありがたいことです。Tomさんありがとう! 

Linux カーネルのアップグレード

NutanixのAHV(またの名をAcropolisハイパーバイザ) はLinux カーネルをヴァージョン4.4.22へとアップグレードしました(現在のLinuxカーネルは2.6.1です 更新:これは間違いでした、現在AHVのLinuxカーネルは3.10.0-229.26.2でした)。Linux 4.4の全ての新しい機能と改善点はこちらをご参照ください。このリリースの素晴らしい機能はもちろん、様々なバグやセキュリティの修正がKVM、QEMU、そしてlibvirtへと含まれています。

Fig146

カーネルについてのヴァージョン3.10.0とヴァージョン4.4.22の間すべての変更についてはこちら。ですが、AHVの一部としてすべての機能を取り込んでいるわけではなく、NutanixはNutanixソリューションに必要な部分のモジュールのみを取り込んでいます。これは小さく固めることで、攻撃対象ととなりうる部分を減らし、ソリューションとしてより安定、よりセキュアにするためです。

個人的に、カーネルのアップグレードに付随して重要になると考えている幾つかの改善点を取り上げます。 

仮想GPUドライバーによる3Dのサポート

virtio-gpuは仮想化ゲストのためのドライバーで、ホストに搭載されたグラフィックスカードを効率的に利用できるようにするためのものです。今回のリリースでは仮想化ゲストがホストのCPUを3Dのレンダリングの高速化に利用できるようにする機能が含まれています。実際のところ、これは仮想化されたLinuxのゲストOSがOpenGLのゲームをホストのGPU高速化機能を使って動作させる事ができるようにする、というもので、こちらや tこちら でビデオを見ることが出来ます。 (重要 – GPUによる高速化はAOS 5.0ではまだサポートされていません、しかしこのアップグレードによってAHVは今後のサポートのための足がかりを作ることになります。

ヒュージ(巨大)ページのサポート (または ラージページのサポート)

ヒュージページはLinuxカーネルが近年のハードウェアアーキテクチャにおける複数のサイズのページを取り扱うことが出来るようにするメカニズムです。ヒュージページはオペレーティングシステムが標準(大抵の場合4KB)よりも大きなページのメモリをサポート出来るようにします。非常に大きなサイズのページを利用することで、システムリソースの総量を減らし、システムのパフォーマンスを向上させることが出来ます。

ヒュージページは32ビットでも64ビットの構成でも有効です。ヒュージページのサイズは2MBから256MBまで、カーネルのヴァージョンとハードウェアのアーキテクチャに合わせて変更することが出来ます。

One more thing!

ここで親愛なるPlexxiと共に作り上げた素晴らしいソリューションをご紹介したいと思います。Plexxiは自身のファブリックの利用率をNutanix Prismへ統合しまし、Prismを根本的にデータセンタ全体に渡るコンピューティング、ストレージ、そしてネットワークファブリックの単一コンソールにしてくれました。これは実際に非常に賢く、とても優れています。今後テクノロジーパートナーが新しいNutanixのヴァージョン3.0 APIを利用してもっと面白いソリューションが出てくることを期待しています。

Fig147_4

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

Part 3で終わりと思いきや、Part 4があるという。。。Nutanixの機能は底なしです!今回はLinuxカーネルについてのアップグレードですが、ラージページ、GPUなどオープンソースからの恩恵でどんどん良くなっていきますね。GPUについては現在はESXiしか選択肢がありませんが、XenServer、行く行くはAHVでも利用ができるようになりそうです。また、最後のソリューションのPlexxi、ウィーンの展示会場でも見てきましたが、なかなか面白いですね。もともとGoogleのために作っていた、ということでした。何よりPrismがプラットフォームとして他社の製品情報を表示するようになってきていますので、今後はこの美しいインターフェイスだけみていれば良くなる・・・と嬉しいなぁ。プラットフォーム連携しても統一感のあるインターフェイス、ユーザビリティを実現するのは難しいと思いますが、是非頑張ってほしい。

2016/12/20

VMware ESXi - 仮想化環境内のI/Oブロックサイズ

本記事はvExperts Advent Calendar 2016への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。当社からは私とSEの工藤が寄稿します。

本記事の原文はもともとPernixData社のTechnical Support Engineer (TSE)で、現在はPernixData社のNutanix社による買収でNutanix社のSr. Systems Reliability Engineerとして活動を継続しているGuido Hagemann氏によるものです。

VMworld EMEAに参加した際に初めてお会いしましたが、Guidoさんはサポート担当ですので、時間によってはサポートコールを取ってくれて話やメールをした間柄です。

原文を参照したい方はVMware ESXi - I/O Block Size in Virtual Environmentsをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。VMware社製品についてはこちら

この記事は仮想化環境内のI/Oサイズまたはブロックサイズに関するものです。これに会いたいする際にはデータベースや他のシステムへの対応のため、ということがほとんどでしょう。Microsoft SQLデータベースを利用する際には64KBでフォーマットされているヴォリュームを利用するか、NTFSにそのように割当を行うのがベストだということはよく知られていますが、これにストレージシステムまで考慮に入れているでしょうか?まだMicrosoft SQLサーバは64KBのブロックのみで操作を行っているとまだ信じているのであれば、これは間違いでです。実際にはSQLデータベースが何を行っているかによって様々なサイズのブロックが生成されています。I/OサイズとNTFSの割り当てサイズ、VMFSブロックサイズ、NFSブロックサイズの間には明確な誤解が有ります。ヴォリュームに関連付けられたそれを支えるストレージシステムはその更に下の物理ディスクやフラッシュを抽象化した構造になっています。このブロクの記事はこの部分に少しだけでも光を当てたいと思っています。以下の図は64KiBのWrite I/Oが仮想化環境の異なるレベルをどのように流れていくのかを示したものです。

Fig145

図1: I/Oのワークフロー

セクタとクラスタ

Windows NTFSファイルシステムに入る前に、セクタとクラスタを理解しておくことが重要です。セクタは物理ストレージのディスク上のもっとも小さな単位です。標準的なセクタのサイズは512バイトで、ハードディスクドライブの登場から利用されています。市場には4096バイトのセクタをもつドライブも有りますが、それでもほとんどのすべての回転ディスクはセクタのサイズとして512バイトを利用しています。

ディスクデータ構造のオーバーヘッドを取り除くため、ディスク上の継続したセクタのグループをクラスタと呼ぶという概念が導入されました。クラスタはファイルやディレクトリのためのディスク割り当ての単位で、アロケーションユニットとも呼ばれています。論理的には4 KiB(4096バイト)のクラスタには8つのセクタ(8 x 512バイト)が含まれています。

フラッシュデバイスはセクタに良く似たページ(サイズは8KiB)でグループ化されており、さらに物理ディスクの世界のプラッターやスピンドルの代わりにブロックやプレーンでグループ化されています。この後方互換性はフラッシュにFlash Translation Layer(FTL - フラッシュ翻訳レイヤ)という名前で組み込まれており、physical page number(PPN - 物理ページ番号)へとLogical Block Address(LBA - 論理ブロックアドレス)を変換されています。ブロックは通常2MiBのデータを格納しており、256 x 8 KiBのページからなっています。

Windows NTFS

WindowsファイルシステムのNTFSはその下のハードディスクのクラスタサイズ、つまり「アロケーションユニットサイズ」に関連付けられています。クラスタサイズの大きさはファイルが利用できるもっとも小さな領域となっています。標準のサイズは4KiBで、アロケーションユニットサイズはディスクフォーマット時に 512、1024、4096、8192、16384、32768、65536バイトで構成することが出来ます。この リンク をクリックしてマイクロソフトが標準のクラスタサイズについてどのように推奨しているかを確認することが出来ます。最後の3つの選択肢は 16K、32K、64Kとして表されていますが、これはKibibyteを簡略化して記載したものですから16Kは実際には16K(16,000)ではなく、16384バイトもしくは16KiB(2^14)であることに注意してください。アプリケーションが非常に小さな512バイトのファイルを継続的に書き込んでいるという例を見てみましょう。結果としてNTFSファイルシステムの容量は無駄になってしまいます。10,000のファイルがあり、ディスクが512バイトと4KiBのアロケーションユニットで作成されている場合を例に取ります。

  • 10,000 x 512 バイトのファイル =  5,120 KiB のスペース利用 / 4 KiBのアロケーションユニットサイズの場合、40,960KiBが利用される
  • 10,000 x 4 KiB のファイル = 40,960 KiB のスペース利用 / 4KiBのアロケーションユニットサイズの場合、40,960 KiB が利用される
最初の例では、たったの5,120 KiBのデータに40,960KiBが利用されます。これは単に4KiBのアロケーションユニットサイズであるからという理由で、2つ目の例ではファイルサイズが4KiBなので完全に一致します。
パフォーマンスの観点からは、回転するディスクは例えばデータベースなどが殆どの場合において64KiBのI/Oを行っており、アロケーションユニットサイズを64KiBに設定している場合には1つのブロックが1つのクラスタに合致するため、単一の64KiBのI/Oを多くの小さなクラスタに分散して処理する必要が無いために、メリットを得ることが可能です。また、メタデータについても効率がよくなり、オーバーヘッドが小さくなります。フラッシュデバイスの場合、パフォーマンスのペナルティを受けることはありません。アロケーションユニットサイズは4KiBですが、大きなファイルを利用するシステムではメタデータの総量はもっと大きくなります。一般的に、フラッシュではパフォーマンスの違いはさほど大きくなりません。私がお話をしてきたほとんどのお客様は標準のアロケーションユニットサイズを利用していました。私自身も出来る限り標準のままにしておくほうが良いと思っています。個人的な意見ですが、特別な理由がない限りアロケーションユニットサイズは4 KiBのままのほうが良いです。ご自身のヴォリュームのシリアル番号、セクター数、アロケーションユニットサイズなどを知りたい場合にはWindows Server上でfsutilを利用すれば以下のように表示されます:
C:\Windows\system32>fsutil fsinfo ntfsinfo c:
NTFS Volume Serial Number :       0x7498f02e98efed14
NTFS Version   :                  3.1
LFS Version    :                  2.0
Number Sectors :                  0x000000000634f7ff
Total Clusters :                  0x0000000000c69eff
Free Clusters  :                  0x000000000001dae3
Total Reserved :                  0x0000000000000fe0
Bytes Per Sector  :               512
Bytes Per Physical Sector :       512
Bytes Per Cluster :               4096
Bytes Per FileRecord Segment    : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length :           0x0000000015fc0000
Mft Start Lcn  :                  0x00000000000c0000
Mft2 Start Lcn :                  0x0000000000000002
Mft Zone Start :                  0x00000000004f2340
Mft Zone End   :                  0x00000000004f2b40
Resource Manager Identifier :     BC106797-18B8-11E4-A61C-E413A45A8CC7

VMFS

Virtual Machine File System(VMFS - 仮想マシンファイルシステム)は仮想マシンをブロックストレージ上に格納できる高度な拡張が可能なシンメトリックなクラスタファイルシステムです。VMFSはSCSIコントローラを利用したDAS(Direct Attached Storage)と、サーバ内のディスク、またはiSCSI(Internet Small Compuer System Interface)、FC(Fibre Channel)そして、FCoE(Fibre Channel over Ethernet)のいずれもを利用する共有ブロックストレージでサポートされています。VMFSを更に深く知りたいと思った場合にはこのリンクの先のSatyam Vaghani氏(VMwareの元CTOであり、PernixDataの元CTO)の論文をご参照ください(VMFS-3をベースにしていますが、基本的には現在も同様です)。ESXi 5.0で導入されたVMFS-5とVMFS-3がどう違うのかという詳細には触れません。すべての人がVMFS-3からVMFS-5へアップグレードしていないとはわかっていますが、もしもアップグレードしていないのであれば、是非アップグレードしてください。これはVMFS-3には多くの制限があるからです。VMFS-3からのアップグレードですべての機能が利用できるわけではありませんが、殆どの重要なものは利用可能です。VMFS-3とVMFS-5の比較についてはVMwareのKB2003813をご参照ください。以下にVMFS-5の新しい機能の主なものをまとめておきます(ESXi 6.0での構成上の最大値はこちらにあります):

  • ブロックサイズの1 MiBへの統一。 以前のVMFS-3では1、2、4、または6MiBのブロックサイズを指定してヴォリュームの作成が可能でしたが、このブロックサイズによってVMDKの最大のサイズが決まっていました。
  • 大きな単一ヴォリューム。 VMFS-5は単一のVMFSファイルシステムとして64TiBをサポートしています(VMDKの最大サイズは 62TiB)。これは以前は2TiB(マイナス512バイト)でした。
  • より小さなサブブロック。 サブブロックは8KiBとなり、VMFS-3の64KiBと比べると、4,000から32,000までその数が増えています。
  • ファイルカウントの増加。 現行のVMFS-5では130,000ファイルがサポートされており、以前のVMFS-3の30,000と比べて大きく増加しています。
  • ATS の改善。 ATS (Atomic Test & Set)がVMFS-5に含まれており、これによってアトミックアルゴリズムによってロック機構が改善されています。ATS は VAAI (vSphere Storage APIs for Array Integration)の一部として含まれており、以前のVMFS-3のSCSI-2予約と比べて大きく改善されています。
上を見て明らかな通り、VMFS-5は1MiBのブロックを利用してファイルシステムを構成しており、そのサイズを変更することはできません。そして、VMDKの最大サイズは62TBです。1KiBよりもちいさい、メタデータなどを格納する非常に小さなファイルについてはファイルディスクリプタの場所(inodeとも呼ばれます)へ格納されます。サブブロックが1KiBの制限に達すると、最大で8KiBサイズのサブブロックが利用されます。8KiBのサイズが使われると1MiBの標準ブロックサイズへと移行が行われます。サブブロックの数は32,000(VMFS-3では4,000)までに制限されているということにはご注意ください。小さなファイルの例としては .VMSD.VMXF.VMX.NVRAM.LOGなどです。標準で1MiBであるから、ということによってVMDKについての多くの誤解であふれています。覚えておいていただきたいのはファイルシステム自身はファイルネームやファイルのタイプは問題にならず、単にサイズを見てファイルを適切に取り扱っているだけということです。当たり前ですが、ほとんどのVMDKにとってこれはファイルの作成時には行われますが、VMDK自身はflatファイルへのディスクリプタであるということを思い出してください。このファイルは1024バイトよりも大きなものになることはほとんどなく、このファイルの名前はVMDKのディスクリプタファイルですから、inodeに格納されるということは理にかなったことなのです。
ですから、順を追って説明すると:
  • 1024 バイト未満 = ファイルディスクリプタの場所(inode)
  • 1024 バイトより大きく、8192 バイト未満 = サブブロック
  • 8192 バイト以上 = 1 MiB のブロック

vmkfstoolsを利用して、ファイルとサブブロックがどのように利用されているかの他、様々な情報を得ることが出来ます :

~ # vmkfstools -Pv 10 /vmfs/volumes/<your_vmfs_volume_name>/
VMFS-5.60 file system spanning 1 partitions.
File system label (if any): <your_vmfs_volume_name>
Mode: public ATS-only
Capacity 805037932544 (767744 file blocks * 1048576), 468339130368 (446643 blocks) avail, max supported file size 69201586814976
Volume Creation Time: Mon Jun 22 16:38:25 2015
Files (max/free): 130000/129472
Ptr Blocks (max/free): 64512/64009
Sub Blocks (max/free): 32000/31668
Secondary Ptr Blocks (max/free): 256/256
File Blocks (overcommit/used/overcommit %): 0/321101/0
Ptr Blocks  (overcommit/used/overcommit %): 0/503/0
Sub Blocks  (overcommit/used/overcommit %): 0/332/0
Volume Metadata size: 807567360
UUID: 55883a01-dd413d6a-ccee-001b21857010
Logical device: 55883a00-77a0316d-8c4d-001b21857010
Partitions spanned (on "lvm"):
naa.6001405ee3d0593d61f4d3873da453d5:1
Is Native Snapshot Capable: YES
OBJLIB-LIB: ObjLib cleanup done.
WORKER: asyncOps=0 maxActiveOps=0 maxPending=0 maxCompleted=0
findコマンドを利用することで、ファイルとディレクトリの数を知ることも出来ます:
  • 1024バイトより大きく、ファイルで8KiBより小さなファイル: ~ # find -size +1024c -size -8192c | wc -l
  • 1 Kibよりも小さなファイル: ~ # find -size -1024c | wc -l
  • ディレクトリ: ~ # find -type d | wc -l
vmkfstools -D(仮想マシンのディレクトリへ移動して)を利用して実際の個々のファイルのブロックサイズを調べることも出来ます(オーナーが0の並びとして表示されていることが有りますが、それはこのホストがそのファイルをロックしているという場合です)。以下では3つのファイル、vm-flat.vmdk(flat ディスク)、vm.ctk.vmdk(チェンジブロックトラッキング)、そしてvm.vmdk(ディスクリプタファイル)が表示されています。flatファイルは40GiBのサイズで、ctkファイルはおよそ2.6MiB、vmdkのディスクリプタファイルは608バイトです。様々な値を見ることが出来ますが、もっとも重要なものは"nb"であり、これは"New Block(新規ブロック)"という意味です。同様に"bs"はblock size(ブロックサイズ)という意味です。flatファイルは17425の新規ブロックと1MiBのブロックサイズ(おおよそ17425 x 1MiBが割り当て)、ctkファイルは3つの新規ブロックです(2621952 = 3 x 1MiB ブロックが割り当て)、そしてVMDKディスクリプタファイルは新規ブロックはありません。なぜ新しいブロックがないのか? それは1KiB未満の小さなファイルはinode自身を利用するからです。
~ # ls -lat *.vmdk*
-rw-------    1 root     root   42949672960 Nov  7 17:20 am1ifdc001-flat.vmdk
-rw-------    1 root     root       2621952 Nov  1 13:32 am1ifdc001-ctk.vmdk
-rw-------    1 root     root           608 Nov  1 13:32 am1ifdc001.vmdk
~ # vmkfstools -D am1ifdc001-flat.vmdk
Lock [type 10c00001 offset 189634560 v 45926, hb offset 3723264
gen 3447, mode 1, owner 5811dc4e-4f97b2d6-8112-001b21857010 mtime 282067
num 0 gblnum 0 gblgen 0 gblbrk 0]
Addr <4, 438, 131>, gen 45883, links 1, type reg, flags 0, uid 0, gid 0, mode 600 len 42949672960, nb 17425 tbz 0, cow 0, newSinceEpoch 17425, zla 3, bs 1048576
~ # vmkfstools -D am1ifdc001-ctk.vmdk
Lock [type 10c00001 offset 189646848 v 46049, hb offset 3723264
gen 3447, mode 1, owner 5811dc4e-4f97b2d6-8112-001b21857010 mtime 282071
num 0 gblnum 0 gblgen 0 gblbrk 0]
Addr <4, 438, 137>, gen 45888, links 1, type reg, flags 0, uid 0, gid 0, mode 600 len 2621952, nb 3 tbz 0, cow 0, newSinceEpoch 3, zla 1, bs 1048576
~ # vmkfstools -D am1ifdc001.vmdk
Lock [type 10c00001 offset 189636608 v 45998, hb offset 3723264
gen 3447, mode 0, owner 00000000-00000000-0000-000000000000 mtime 406842
num 0 gblnum 0 gblgen 0 gblbrk 0]
Addr <4, 438, 132>, gen 45884, links 1, type reg, flags 0, uid 0, gid 0, mode 600 len 608, nb 0 tbz 0, cow 0, newSinceEpoch 0, zla 4305, bs 8192
仮想マシンが行っているI/Oを理解しておくことは重要です。例えば、4KiBはVMFSファイルシステムのブロックサイズを反映しているものではありません。ファイルディスクリプタは固定長のデータアドレスを用いてデータブロックへアクセスします。ファイルサイズが増えるに従って、ファイルディスクリプタに含まれているものが変わっていき、ファイルディスクリプタはポインタブロックを利用して、間接アドレスを使ってアクセスを行います。それぞれのポインタブロックは4KiBのサイズで1024のアドレスを保持できますので、1 MiBのブロックサイズでは 1 GiBへ全体としてアクセス可能となります。VMFSファイルシステムを通り過ぎるとヴォリュームベースの構造と物理メディアへのアクセスが、本記事の最初の図1に記載されているとおりに行われます。この部分はすべてのストレージベンダーで異なっているため、ここでは詳細には取り上げません。

NFS

バックエンドのストレージへと仮想マシンのデータを格納するには様々な方法があります。NFSは定番の成熟した、高可用性を備えた高性能のストレージ実装です。コスト、パフォーマンス、そして管理の簡単さから非常に早くお客様に受け入れられるようになりました。VMFSと比較した際の機能についてもほとんど同等となり、機能がないためにNFSを利用しないということは殆どなくなっています。当たり前ですが、単一ESXiホストや単一ESXiクラスタ内でVMFSとNFSを一緒に使うということにも問題はありません。NFSは分散ファイルシステムプロトコルでもともとは1984年にSun Microsystemsによって開発されました。システムがネットワークを通じてストレージと接続することを非常に簡単に実現し、新たにFCベースのシステムのようにインフラストラクチャへ機材を追加すル必要もありません。vSphere 6.0では2つのヴァージョンのNFSがサポートされています。古いNFS 3とNFS 4.1です。しかし、殆どのお客様はNFS 3の機能がより完全てあるという理由からまだNFS 3を利用しています。NFS 4.1を使う理由はセキュリティ上の理由でしょう。ESXi内部のNFS ネットワークはレイヤ2のVLANを構成して利用されることが多く、外部から直接アクセスされる可能性はありません。これもNFS 3を使い続けるもう一つの理由です。この違いについては詳しくはこちらのVMware vSphere 6.0 ドキュメントセンターか、vmguru.comのNFSのベスト・プラクティスについての素晴らしい記事 をご参照ください。

ですが、この記事はブロックサイズとI/Oについての記事ですから、NFSベースのシステムのブロックサイズの話に切り替えましょう。VMFSとの違いはVMware自身がファイルシステムをフォーマットするのではないという点です。これはファイルシステムの実装自身がストレージベンダーによるもので、ブロックサイズはNFSサーバやNFS装置のもともとの実装によって異なってしまうからです。ブロックサイズ自身はVMFSと同じで、ゲスト仮想マシンへの依存もありません。これはVMDKが単にNFSサーバ/装置上の単独のファイルだからです。NFS上にはサブブロックもありません。VMFSと同様に、ブロックサイズについてはvmkfstoolsで知ることが出来ます。以下に見るようにNFSサーバは4KiBのブロックサイズを利用しています :

~ # vmkfstools -Pv 10 /vmfs/volumes/<your_nfs_volume_name>/
NFS-1.00 file system spanning 1 partitions.
File system label (if any): <your_nfs_volume_name>
Mode: public
Capacity 536870912000 (131072000 file blocks * 4096), 194154864640 (47401090 blocks) avail, max supported file size 18446744073709551615
UUID: fcf60a16-17ceaadb-0000-000000000000
Logical device: 10.14.5.21 /mnt/<your_nfs_mount>/<your_nfs_volume_name>
Partitions spanned (on "notDCS"):
nfs:<your_nfs_volume_name>
NAS VAAI Supported: NO
Is Native Snapshot Capable: NO
OBJLIB-LIB: ObjLib cleanup done.
WORKER: asyncOps=0 maxActiveOps=0 maxPending=0 maxCompleted=0

結論

この記事が皆様のお役に立ち、ブロックサイズが様々異なるレベルで議論されていることや、アロケーションユニットサイズは実際にはアプリケーションのI/Oには何も介在しておらず、仮想マシン自身はVMFSのブロックサイズについてはまったく関知していないことなどをご理解いただけたとしたら幸いです。個人的な意見ですが、環境は可能な限り標準の設定のままにしておくということが良いと思います。アプリケーションごとにちょっとした容量を削減するためにアロケーションユニットサイズを変更したりするのはよした方が良いです。最終的には標準が理にかなっており、異なる構成を入れたとしても1%くらいしか変わらないのでは無いかと思います。いつもどおり、質問、推奨、懸念などがあればご連絡ください。

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

今回も前回に続きvExpertのAdvent Calenderということで、普段は絶対に訳さないようなテッキーな内容をお届け致しました。仮想化におけるブロックサイズはGuidoさんの言うとおり多くの階層でそれぞれ別々の議論になってしまい、そもそもそこを変えても・・・という話は多く出てきます。物理で役に立っていたベスト・プラクティスは仮想マシンの中でやるべきなのか、それともVMFSやNFSのレイヤでやるべきなのか、そもそもストレージシステムでやるべきなのか、、、そうした議論は尽きません。

Guidoさんの言う通り、ESXiという観点からすると、VMFSやNFSのレイヤを見回してもほとんどパフォーマンスに影響のあるようなパラメーターやチューニング操作はありません。アプリケーションの挙動をある程度変えながら、あとはストレージシステム側でのチューニングということに落ち着く事がほとんどです。

せっかくのアドベントカレンダーなので、よく考えずに今までの慣習でやってしまいがちなI/Oチューニングの間違いについての記事を翻訳致しました。いつもながら、Guidoさん、さすがです!

2016/12/16

vSphere DRSとNutanixの親和性は悪いっていう都市伝説は本当なのかやってみた ~前編~

vSphere DRSとNutanixの親和性は悪いってどういうこと?


弊社でも今年の9月からNutanixの販売を開始しましたが、よくある質問の1つにNutanix上でvSphere DRSを使っちゃいけないの?というものがありました。

私はvSphereもvSANもNutanixもちょっとわかるくらいの知識はありますので色々考えてみたのですが、なんかそんなことを言われる技術的要因もあまり心あたりがないので「都市伝説です!」ということにしています。

ただこんな都市伝説が流れるということは、何か正しく伝わっていないのだろうということで、弊社のWebセミナーのやってみたシリーズでお話した内容をこうしてブログで公開してみたいと思います

vSphere DRSとは?


まずNutanix云々という前にvSphere DRSについておさらいをしてみましょう。
皆さんvSphere DRSの機能というと「vSphereクラスタ内のホストの負荷の偏りをなくすために仮想マシンを自動的にvMotionする機能」と認識していると思います。ところがvSphere DRSがvMotionする条件はなかなか知られていないのが実情です。

例えば、ホストが3台あって、ホストAがCPUが50%、ホストBがCPU利用率が10%、ホストCがCPU利用率が0%の場合、ホストAで稼働する仮想マシンをホストCに移動するのでしょうか?

50:10:0なので不均衡なのでDRSのトリガーとなってホストA上の仮想マシンが数台、ホストCにvMotionされると思うかもしれません。いかがでしょうか?

ところがこの程度の利用率ではDRSが自動的に仮想マシンをvMotionすることはありません

なぜでしょうか?vMotionは確かに無停止で仮想マシンを違うホストに移動することができます。しかし何のデメリットもないわけではありません。

vSphereのバージョンアップでvMotionの進化につれて小さくなっていますが、稼働するホストを切り替えるときに多少の性能劣化が発生するのです。

そのためDRSは性能に困ってない仮想マシンを無理に移動するようなことをして例え瞬間的とはいえ性能劣化を起こすようなことはしないのです。

先ほどの例でいうと、ホストAがCPU90%、ホストBがCPU利用率50%、ホストCがCPU利用率10%というような、特定のホスト上で性能劣化が発生するくらい負荷が
高くなり、クラスタ内にリソースの余裕がある移動先ホストがあるときだけvMotionするのです。非常によく考えられていると思いませんか?

Drs_2

こうしてみると、vSphere DRSは「仮想マシンが遅くなるくらいリソースが不足してきたとき、事前に自動的にvMotionする機能」ということができます。

vSphere DRSは頻繁にvMotionするわけではないということはご理解いただけたでしょうか。なのでもっと皆さん怖がらずに積極的に使ってください…。

こうしたDRSのアーキテクチャの詳細はvSphere 6.5に対応した以下のドキュメントで解説がされています。興味のある方は是非1度読んでみることをお勧めします。
DRS PERFORMANCE VMware vSphere 6.5

では今回はここまでにして次回の最終回で、Nutanix側のアーキテクチャと弊社の検証結果についてまとめたいと思います。お楽しみに!

2016/12/14

Nutanix 5.0の機能概要(Beyond Marketing) パート3

本記事はNutanix Advent Calendar 2016への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。当社からは私とSEの工藤が寄稿します。

本記事の原文はNutanix社のPartner Innovation and Vertical Alliances, Sr. Directorを務めるAndre Leibovici氏によるものです。原文を参照したい方はNutanix 5.0 Features Overview (Beyond Marketing) – Part 3をご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら

また、以下のセミナーでも本記事の内容を詳しくご説明しますので、是非ご来場ください!

Nutanix/VMware 2大メーカー ヨーロッパイベントからの最前線
ウィーンで開催された「Nutanix .NEXT Conference EUROPE」とバルセロナで開催された「VMworld EMEA」からの情報 2本立て

すでに東京での開催は終了していますが、大阪での開催もございます!

これは本シリーズの3番目の記事です。1番目はこちら、そして2番目はこちら。4番目はこちら

免責事項 : あらゆる将来の製品又はロードマップ情報は製品の方向性を示すことを意図しており、Nutanixが提供するあらゆる情報、コード、機能に対してコミット、お約束、法的な義務が生じるものではありません。この情報を用いて、購入を決めるべきではありません。また、Nutanixは将来の製品改善、機能が最終的に利用できるようになった際に追加での課金を行うことや、最終的に改善された製品や機能のために別途の課金を行うことを現時点では決定していません。

機能や時間軸についてのオフィシャルな情報についてはNutanixのオフィシャルなプレスリリースをご参照ください。(こちら)

以下はこのブログ記事でご紹介してきた機能です:

  • Cisco UCS B-シリーズ ブレード サーバ サポート
  • Acropolis アフィニティ と アンチ-アフィニティ
  • Acropolis ダイナミックスケジューリング (DRS++)
  • REST API 2.0 と 3.0
  • XenServerのサポート TechPreview
  • ネットワーク可視化
  • 新しいワークロードのためのWhat-if分析と割当ベースのフォーキャスティング(予測)
  • ネイティブのセルフサービスポータル
  • スナップショット - セルフサービスリストアのUI
  • ネットワークパートナーインテグレーションフレームワーク
  • メトロアベイラビリティウィットネス
  • VMフラッシュモードの改善
  • Acropolis ファイルサービス 正式リリース (ESXi と AHV)
  • Acropolis ブロックサービス (CHAP認証)
  • AHVのOracle VM と Oracle Linuxへの認定
  • AHVのSAP Netweaver Stackへの認定
  • Prism サーチの改善(ブール表現のサポート)
  • I/O メトリクスの可視化
  • 1-クリックライセンシング
  • LCM – Lifecycle Manager(ライフサイクルマネージャー)
  • 追加のPrismの改善点
  • AHVの拡張性の改善
  • AHVのCPUとメモリのホットアド(Tech Preview)
  • コールドデータのアドバンスドコンプレッション
  • バックアップベンダーのためのAcropolis チェンジブロックトラッキング(CBT) 
  • 自発的なQoSによる期待通りのパフォーマンス
  • (New) NCC 3.0 の Prism への統合
  • (New) 1-ノード レプリケーションターゲット
  • (New) QoSによる混在したワークロードのサポートの改善
  • (New) SATADOMの交換ワークフローのシンプル化
  • (New) 適応型レプリカ選定によるノード混在のサポート
  • (New) 動的なイレイジャーコーディングのストライプの縮小 - ノードの削除時
  • (New) メタデータ用のノード上の利用可能な複数のSSDをメタデータディスクとしてサポート
  • (New) コンテナにおけるイレイジャーコーディング(EC)のレプリケーションファクタ(RF)の変更のサポート
  • (New) OpLogのインライン圧縮

さて、法的な免責事項に目を通したら、さぁ、初めましょう!

Prism

NCC 3.0 の Prism への統合

これまでNCCについては全てのやり取りをCVMからコマンドラインで実行する必要がありました。これはCLIに精通していないシステム管理者やGUIを好まれるお客様にとってはフラストレーションの元でした。AOS 5.0に含まれるNCC 3.0についてはNCCが完全にPrismに統合され、多くの改善点が追加されています。

  • NCCの実行にかかる時間は5分以下に
  • 既存のチェックについて多くの改善点が追加
  • バグが修正され、より堅牢なNCCインフラストラクチャに
  • 新しいプラグイン(2.3と3.0で15以上のプラグイン)
  • XenServerのサポート
  • 多くのNCCの機能がPrismから利用できるように
  • 300以上のNCCのチェックがPrism経由で管理できるように
  • 全てのチェックにアラートが関連付け
  • チェックはGUIから手動で実行可能になり、結果がダウンロード可能に
  • ログコレクターもGUIから起動できるように

Fig135

分散ストレージファブリック(Distributed Storage Fabric - DSF)

1-ノードレプリケーションターゲット

SMBのお客様は拠点のためのコスト効果の高いレプリケーションソリューションを必要とされています。AOS 5.0では単一のNutanixノード(NX-1155、1N2U、SSD2本 + HDD 10本)がNutanixクラスタの完全なるレプリケーションターゲットとして利用できるようになりました。このノードはシングルノードのクラスタで耐障害性のない、仮想マシンの起動できないノードですが、サポートされている全てのハイパーバイザのNutanixクラスタと統合しての利用が可能です。

Fig136

QoSによる混在したワークロードのサポートの改善

これは内部奥深くの改善では有りますが、複数の異なるアプリケーションを単一Nutanixノード上で異なるワークロードプロファイルで動作させた際に、システムの能力とパフォーマンスへ大きな影響を与えます。AOS 5.0はReadとWriteのIOキューを分離します。Writeが集中している(もしくはWriteがバーストした)ワークロードがRead操作を阻害しないことを保証、またはその逆を行います。この実現のために、アドミッションコントローラーとOpLogのキューが単一のフェアに重み付けされたキュー、優先順位伝播、最適化されたディスクキューへと置き換わっています。

詳細をご紹介して惑わせるつもりはありません。これは最初テクニカルな内容になり、おそらく別の記事で紹介することになると思います。ですが、この新しい機能はシステムがストレス下にある際にパフォーマンスとI/Oの信頼性を含むIOパス全体を通してパフォーマンスとI/Oの優先順位が維持されることを保証します。

Fig137

SATADOMの交換ワークフローのシンプル化

ホストのブートディスク(SATADOM)の交換は長時間に渡る、Nutanixのシステムエンジニアが行わなければならないマニュアルでの手順が含まれます。AOS 5.0はシステム管理者がPrism内で(ほとんど)ワンクリックで起動できるワークフローによってこれを自動化し、シンプル化します。

Fig138

適応型レプリカ選定によるノード混在のサポート

クラスタのバランスとパフォーマンスについて埋め込まれたもう一つの重要な機能です。AOS 5.0はドライブのキャパシティとパフォーマンスの利用状況を元にスマートにデータをコピーし、常に一定のパフォーマンスレベルと最適化されたリソースの利用率をノードが混在したクラスタにおいても提供します。例 : 通常ノード+ストレージヘビーノード またはNX1000+NX3000ノード。

スマート配置によってそれぞれのディスクのディスクの利用率とパフォーマンス状態を用いて、ディスクフィットネス状態をクラスタ内に作成します。このフィットネスの値はディスクの利用率のパーセンテージとディスクのキューの長さ(ディスクに対して操作中のIO操作の数)の関数として表されます。さらにデータ書き込み用のディスクは振る舞いが固定しないように重みのある乱数投票を用いて選択されます。

Fig139

動的なイレイジャーコーディングのストライプの縮小 - ノード削除時

イレイジャーコーディング(EC)はデータを細切れに分解して展開、冗長性のためのデータによってエンコードし、別々の場所やストレージメディアに保管することでデータ保護を実現する方法です。それぞれのNutanixのコンテナはレプリケーションファクタ(RF)を定義してRF2またはRF3でデータの信頼性と可用性を確保しています。EC-Xについて詳しくはこちら(リンク先は英語)をご参照ください。

AOS 5.0以前はクラスタにECコンテナがある場合にはノードの削除はある意味で制限事項が有りました。これはECのストライプがクラスタ全体に分散しているためです。ノードを削除する場合にはRFが最高で2の場合、最低7ノード、RFが最大で3の場合は最低9ノード必要でした。これを解決するためにはコンテナのECをオフにし、長時間をかけてECではない状態へと変換しなくてはならず、また、クラスタに十分な空き領域が必要でした。

AOS 5.0ではノード削除時もECでの保護を維持しつつ、保護の劣化のオーバーヘッドも限定的にすることが出来ます。ノードがクラスタから削除された場合、動的にECのストライプサイズを減らし、新しノードがクラスタに追加された際にECのストライプサイズを自動的に増やすのです。 

メタデータ用のノード上の利用可能な複数のSSDをメタデータディスクとしてサポート

AOS 5.0はノード内の利用可能なSSD全体(最大で4台)にメタデータを自動的に分散します。複数のSSDへのメタデータの自動的な分散はメタデータディスクを他のシステムコンポーネントが利用するようなピークイベント時のRead/Writeのプレッシャーを緩和に役立ちます。Read/Write負荷を分散することでIOPSが改善、レイテンシも小さくなり、単一SSDでのボトルネックを排除します。もう一つのメタデータ書き込み分さんのメリットはSSDメディアデバイスの摩耗を均一化することが出来ることです。

Fig140

コンテナにおけるイレイジャーコーディング(EC)のレプリケーションファクタ(RF)の変更のサポート

イレイジャーコーディング(EC)はデータを細切れに分解して展開、冗長性のためのデータによってエンコードし、別々の場所やストレージメディアに保管することでデータ保護を実現する方法です。それぞれのNutanixのコンテナはレプリケーションファクタ(RF)を定義してRF2またはRF3でデータの信頼性と可用性を確保しています。EC-Xについて詳しくはこちら(リンク先は英語)をご参照ください。

AOS 5.0ではEC-Xはイレイジャーコーディングが有効なコンテナに対してレプリケーションファクタ(RF)の変更が出来るようになりました。これによってデータ保護のレベルをアプリケーションライフサイクルに合わせて変更したいと考えるお客様はより大きな柔軟性を持って利用ができるようになります。ECが有効なコンテナはRF3からRF2又はその逆へと変更が可能で、ECの円コーディンすは自動的にそれに会うように変更されます。

Fig141

OpLogのインライン圧縮

AOS 5.0では、ランダムなWriteはOpLogへ格納される前に自動的にインラインで圧縮されます。OpLogはファイルシステムのジャーナルのようなもので、ランダムなWriteのバーストを取り回すための一時的な領域として作成されています。ここに格納されたWriteは結合されて、シーケンシャルにエクステントストアのデータへと取り込まれます。

動的な圧縮によって、Nutanixのクラスタはスペース利用率が改善し、継続するランダムWriteのバーストのためのOpLog領域の取り回しを改善します。OpLog領域は継続するランダムなWriteのバーストをより長い時間吸収し続けることが出来るようになったのです。

Fig142

以上が AOS 5.0 の莫大なリリースの中のパフォーマンス、信頼性、可用性、サポート性、それからユーザーエクスペリエンスについての主な改善点です。ほかにも小さな機能がリリースには含まれていますが、それはこの記事でご紹介していくには小さすぎるものです。

PM、R&D、QA、リリース管理、そしてサポートチームのこれらの「ファンタスティック」なプロダクトリリースを提供するための膨大な努力に敬意を評したいと思います。彼らは顧客、そしてパートナーへ私が知りうる限り今日のマーケット内で遥かに抜きん出たHCIプロダクトをもたらすために継続的に革新のための努力を続けています。本当にありがとう!

さて、みなさんはご自身にいつAOS 5.0へワンクリックでアップグレードするか、検討をし始めてください。リリース管理の列車は私にはコントロールできませんし、正確な日付を公開することも出来ません。ですが、それは間近です。さぁ、ご期待ください!!

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

Advent Calenderに参加している都合で公開が遅れますが、翻訳時点(12月6日)ではまだAOS 5.0はリリースされていません。今回は本家更新と同時に訳し始めましたのでタイムリーに公開できるので一安心です。

前回、前々回はプラットフォーム化やUX、ストレージとしての新機能がメインでしたが今回は、内部アーキテクチャの変更に関連する内容が多く含まれています。IOキューの分散のチューニングやインテリジェントなレプリカの選択など、マニア受けとは思いますが、逆にこんなにもマニアック(正確に表現すると緻密に)に作り込まれたHCIも無いと思います。さぁ、5.0のリリースを待ちましょう。

2016/12/12

最新鋭、IBM FlashSystem A9000を大解剖!

IBMの最新鋭の超高速フラッシュストレージ FlashSystem A9000をお借りしちゃいましたっ。


驚きのデータ削減!あらゆる電力喪失に対応する究極の電源機構!
何処をとってもワンランク上のA9000ですが性能も機能も一味違います!!
その噂の真相を確かめるべく、検証も次のステージへっ。

7vocbqxlurq9an61481180153_148118042


ここからはお待ちかねのA9000の持つ機能や性能について
さらに切り込んでいこうと思うっ♪


で、今回はズバリ QoS ですっ♪

クラウド基盤好きには、ハズせないマストアイテムがこのQoS
このA9000!、次のスケジュールもパンパンで、お借りできる期間もあとわずかっ!
限られた時間内(いろいろな検証の合間を縫ってこっそり決行っ!)に出来る限りの検証をおこなってみたよっ♪

ちなみにQoSってなにっ?って人もいると思うので簡単に説明しようっ。
QoSとは Quality of Service(クオリティ・オブ・サービス) の略でザックリ言うと
その名の通り、「サービスの品質!」 要は「ユーザーを満足させられる度」みたいな意味になりますっ。

したがって、ここで言うQoSは「ストレージアクセスの品質」ですねっ♪
例えば、「社内で野放しのワークロードが蔓延りクリティカルアプリケーションに影響がでてる!」のような
他の利用者の大きなI/Oに影響を受けるいわゆる“ノイジーネイバー”問題っ。
QoS 機能はこういった問題を解消するために無くてはならない機能っ!。

A9000/A9000Rの
QoS機能は、接続先ごとのプライオリティーに応じて
柔軟できめ細やかな設定が可能ですっ。
例えばこの図ように「帯域」または「IOPS」を設定したり、また「その両方」を設定することもできます。
もちろん単一ボリューム単位だけでなく、複数のボリュームでシェアしたり
ストレージプール単位での設定だって出来ちゃいますっ♪

A9000qostest001


更にA9000/A9000Rは管理アカウントまで独立したマルチテナンシー機能も搭載され
クラウド基盤、クラウドサービス、そして流行のVDI環境にも最適な一台です!!

それでは、A9000の QoS機能の検証結果をご覧くださいっ♪

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

検証が進むにつれ

筆者はこの「グリッドコントローラー」の完成度の高さに驚いているっ。
特にパフォーマンスに関しては、驚きの結果(本当に想定外です。)を次々とたたき出してますので

そのへん、次回にでもお見せできればと思いますっ。


                        by:まいけル
        

VMware ESXiのロック機構とフリーズした仮想マシンの強制停止方法

本記事はvExperts Advent Calendar 2016への寄稿も兼ねております。是非アドベントカレンダーの他の記事もお楽しみください。当社からは私とSEの工藤が寄稿します。

本記事の原文はもともとPernixData社のTechnical Support Engineer (TSE)で、現在はPernixData社のNutanix社による買収でNutanix社のSr. Systems Reliability Engineerとして活動を継続しているGuido Hagemann氏によるものです。

VMworld EMEAに参加した際に初めてお会いしましたが、Guidoさんはサポート担当ですので、時間によってはサポートコールを取ってくれて話やメールをした間柄です。

原文を参照したい方はVMware ESXi locking and how to kill a frozen VMをご確認ください。情報は原文の投稿時のままの情報ですので、現時点では投稿時の情報と製品とで差異が出ている場合があります。

当社のNutanix社製品についてはこちら。VMware社製品についてはこちら

このブログの記事はフリーズした仮想マシンの強制停止方法についての内容です。テクニカルサポートとして勤務していると「何かがおかしい」としか言いようのないようなケースに出くわすことが有ります。これはストレージの問題であったり、特定のESXiで動作中のプロセスが他の多くの理由からファイルをロックしているということだったりします。この記事では様々なトラブルシューティング、例えばどのホストがロックを取得しているか、APD(オールパスダウン)が起こってはいないか、PDL(Parmanent Device Loss - 恒久的なデバイスの喪失)が起こっていないかなどのテクニックに続けて、どのように仮想マシンを強制停止するか様々な方法を体系立ててご紹介していきます。

まず最初は仮想マシンがどのように動作しているかを見てみましょう。以下の図はESXiの内部の一般的なプロセスを説明したものです:

Fig143

図1: ESXi内部のプロセス

これらのプロセスはそれぞれが別々のコンテキスト(context)から来ているため、別々のグループに分類することが出来ます。左上では仮想マシンがユーザーワールドで動作しているのがわかります。続いて幾つかのホストプロセスが動作していますが、ここでは2つだけを例に取り上げています: Hostdとシェルです。

ESXi シェル

ESXiがLinuxベースのものではないということを理解しておくことが重要です。これは最近ではあまり耳にしなくなりましたが、ほんの少しまでは多くの人々がESXiをLinuxベースだと勘違いして色々と試行錯誤したという話をしていました。理由は単に大抵のシェルコマンド(grep, less, more, ps, catなど)が利用でき、SSHでリモートアクセスしたときの挙動が似ているからというだけだったりするのです。ESXiがLinuxベースではないのだったら、どうしてこのようなLinux/Unix由来のコマンドが使えるんだい?それはとても簡単です。単にVMwareが「Busybox」と呼ばれるソフトウェア実装を利用することにしたからです。これはVMwareによる軽量なシェル実装で、典型的なシェルコマンドの実行をおこないます。BusyBoxはユーザーワールドのプロセスとしてVMKernel上で動作します。つまり、基本的にはWindows上のcygwinに似たようなものです。さて、これで何故コマンドがシェルの中で動作するのかがわかりました。Busyboxのおかげです。

"ps"(process status/プロセスの状態)コマンドを利用すると、特定の仮想マシンのサブコンポーネントがどのような状態かよくわかります。仮想マシンがフリーズしてしまった時、以下の2つを知ることが重要です:

  • 仮想マシンのステータスはどうなっているか?
  • その仮想マシンのロックを保持しているのは誰(何)か?
  • 問題がカーネルなのか、ストレージスタックなのか、それを知るためのコマンド(Commands in Flight - CIF)があるか?

フリーズした仮想マシンを強制停止する

フリーズした仮想マシンの強制停止の方法は多くあります。以下では4つの例を挙げてどのように仮想マシンを強制停止するかをご紹介します。例を上げながら、強制停止する方法をどのように適切なデータで特定しながら行うのかご紹介していきます。どのツールを利用するのが良い、悪いはなく、私は単に何が可能なのか、そのヴァリエーションをご紹介したいと思います。強制終了のパートのあと、更に、VMFSとNFSのロック機構についてもいくらかご紹介致します。

  • シェルツール (ps と kill)
  • esxcli
  • vim-cmd
  • ESXtop
  1. “PS”を“KILL”と組み合わせる

仮想マシンの状態を知るために、以下の"ps"コマンドを利用します(この例では仮想マシン名はam1ifvh029です)。ご覧のとおり、この仮想マシンは8つのvCPUを持つことがわかります。これは8つのvmm0~7、そして同じくvmx-vcpu-0~7と8つの仮想スレッドがmksとsvgaのスレッド以外に存在することからわかります。最後の列はグループID(GID)を示しており、これがメインとなるプロセスです。

~ # ps -jv  | egrep "WID|am1ifvh029"
WID      CID      WorldName                     GID
645172   0        vmm0:am1ifvh029               645137
645174   0        vmm1:am1ifvh029               645137
645175   0        vmm2:am1ifvh029               645137
645176   0        vmm3:am1ifvh029               645137
645177   0        vmm4:am1ifvh029               645137
645178   0        vmm5:am1ifvh029               645137
645180   0        vmm6:am1ifvh029               645137
645181   0        vmm7:am1ifvh029               645137
645219   645137   vmx-vthread-13:am1ifvh029     645137
645220   645137   vmx-mks:am1ifvh029            645137
645221   645137   vmx-svga:am1ifvh029           645137
645222   645137   vmx-vcpu-0:am1ifvh029         645137
645223   645137   vmx-vcpu-1:am1ifvh029         645137
645224   645137   vmx-vcpu-2:am1ifvh029         645137
645225   645137   vmx-vcpu-3:am1ifvh029         645137
645226   645137   vmx-vcpu-4:am1ifvh029         645137
645227   645137   vmx-vcpu-5:am1ifvh029         645137
645228   645137   vmx-vcpu-6:am1ifvh029         645137
645229   645137   vmx-vcpu-7:am1ifvh029         645137
プロセスを終了させるためにはkillコマンドを-9オプションとともに利用します。もしもkillコマンドの別のオプションについて詳しく知りたい場合にはこちらをご参照ください。基本的には-9はカーネルがプロセス自身に何も通知を行わずに終了を行うという意味になります。これは理論的にはプロセスが何をしているかによってはデータを喪失する可能性があり、終了方法ではもっともハードなものになります。もちろん最初は"kill -1"(ハングアップシグナルをプロセスに送る)、"kill -2"(CTRL+Cと同じ)を試した後に行うのが良いでしょう。
~ # kill -9 645137

"kill"コマンドはそれが出来てしまう場合には何も確認を返してこずにプロセスを終了させてしまいます。psコマンドでもう一度プロセスの動作を確認すると、プロセスIDがなくなっているという事になります。

  1. “ESXCLI VM PROCESS”を使う

ESXi上ではesxcliコマンドでハイパーバイザーの低レベルなインフラストラクチャの管理を行うことが出来ます。この先にご紹介するvim-cmdコマンドとは異なり、これは完全にESXiのその下のインフラストラクチャにフォーカスしたコマンドです。このコマンドはただひとつのコマンド(esxcli)に見えますが、様々なネームスペースを利用した広範なサブコマンドをもっています。ありがたく、また以前のesxcfg-コマンドよりも優れていることには、これはツリー階層構造にまとめられていることです。シェルにコマンドを入力し、いつでも利用可能なすべてのオプションを参照することが出来ます。このVMware KB: 2012964でよく使う組み合わせのコマンドを見つけることが可能で、esxcliとvim-cmdとPowerCLIがどのように違っているのかを見ることが出来ます。プロセスを停止させる前にそのプロセスがどの状態になっているのかということを確認してください。esxcliについてはSteve Jin氏によって書かれた素晴らしいブログの記事もあります。

~ # esxcli vm process list | grep -i -A 4 am1ifvh029
am1ifvh029
 World ID: 645172
 Process ID: 0
 VMX Cartel ID: 645137
 UUID: 42 21 23 10 79 c5 62 80-9b 06 74 21 81 9a fc 57
 Display Name: am1ifvh029
 Config File: /vmfs/volumes/55883a14-21a51000-d5e9-001b21857010/am1ifvh029/am1ifvh029.vmx

仮想マシンを強制停止するには"World ID"を利用しなくてはなりません。Worldを強制停止するには別のオプション(--type または -t)が用意されています:

  • soft
  • hard
  • force

~ # esxcli vm process kill -t=soft -w "645172"

なにもオプションを指定しない場合、標準では"soft"にて実行されます。"hard"または"force"を試してみてください。見ての通り、最初の例で"ps"コマンドで見たメインのプロセスIDとワールドIDは必ず同じものになります。これはいつもvmm0のIDです。

  1. “VIM-CMD”を利用して仮想マシンを強制停止する

もう一つの仮想マシンの状態を確認して、停止を行うコマンドはvim-cmdです。これは「hostd」上に実装されており、ESXiとhostdとが統合されているAPIとほとんど同じように利用することが出来ます。vim-cmdは多くの運用タスクにも利用することが可能です。Steve Jin氏によるもう一つのesxcli同様に素晴らしい記事はこちら
ESXi内部のvim-cmdは/bin/vim-cmdに格納されており、これ自身は実際にはhostdへのシンボリックリンクです:
~ # ls -l /bin/vim-cmd
lrwxrwxrwx    1 root     root    10 Mar  4  2016 /bin/vim-cmd -> /bin/hostd

vim-cmdにはいくつかのサブコマンドが有ります。それが何であるかを知るためには単にvim-cmdとシェルに打ち込めばすみます:

~ # vim-cmd

Commands available under /:

hbrsvc/       internalsvc/  solo/         vmsvc/

hostsvc/      proxysvc/     vimsvc/       help


見ての通り、7つのサブコマンド(とhelp)があります。それぞれが何のためにあるのかが分かりますし、ESXiの内部にどれだけの機能やオプションが取り込まれているのかを想像することも出来ます。svc(サービス)を取り除きたいのであれば、基本的にそれぞれのコマンドを利用します:hbr、internal、solo、vm、host、proxy、vimそしてhelpです。実際にはinternalsvcはほんとうの意味のESXiの内部APIではないということは覚えておいてください。

今は仮想マシンについて何らかの作業をしようとしていますので、"vmsvc"コマンドを使うということになります。vim-cmd vmsvcと打ち込むことで以下の結果を得られます :
~ # vim-cmd vmsvc

Commands available under vmsvc/:

acquiremksticket                 get.snapshotinfo
acquireticket                    get.spaceNeededForConsolidation
connect                          get.summary
convert.toTemplate               get.tasklist
convert.toVm                     getallvms
createdummyvm                    gethostconstraints
destroy                          login
device.connection                logout
device.connusbdev                message
device.ctlradd                   power.getstate
device.ctlrremove                power.hibernate
device.disconnusbdev             power.off
device.diskadd                   power.on
device.diskaddexisting           power.reboot
device.diskremove                power.reset
device.getdevices                power.shutdown
device.toolsSyncSet              power.suspend
device.vmiadd                    power.suspendResume
device.vmiremove                 queryftcompat
devices.createnic                reload
get.capability                   setscreenres
get.config                       snapshot.create
get.config.cpuidmask             snapshot.dumpoption
get.configoption                 snapshot.get
get.datastores                   snapshot.remove
get.disabledmethods              snapshot.removeall
get.environment                  snapshot.revert
get.filelayout                   snapshot.setoption
get.filelayoutex                 tools.cancelinstall
get.guest                        tools.install
get.guestheartbeatStatus         tools.upgrade
get.managedentitystatus          unregister
get.networks                     upgrade
get.runtime


今回は仮想マシンの強制終了ですから、実際のvmidの状態を見る必要があります:

~ # vim-cmd vmsvc/getallvms | grep -i 'vmid\|am1ifvh028' | awk '{print $1,$2}'
Vmid Name
4    am1ifvh028
現在の電源状態を得る場合には以下のコマンドを使います:
~ # vim-cmd vmsvc/power.getstate 4

さて、結果として、仮想マシンが動作しているというアウトプットが得られました。

Retrieved runtime info

Powered on

vim-cmdを利用して仮想マシンの電源を切るには以下のコマンドを実行します:

~ # vim-cmd vmsvc/power.off 4

  1. ESXtopを利用して仮想マシンを強制停止する

以下のコマンドを利用してesxtopユーティリティを起動します。
  1. esxtopを実行する(esxtopはCPU表示で起動します、"c"を押すことで別の表示からCPUリソース利用状況の画面へ戻ってくることが出来ます)
  2. "Shift+v"を押すことで、仮想マシンの表示へと限定することが出来ます。これによって時々多くのプロセスが表示されてしまい、仮想マシンについて全く見えないということを防ぎ、可読性が良くなります。
  3. "f"をおして、表示されるリストのフィールドを表示します。
  4. "c"をおして、"Leader World ID"の列を追加します。これはどの仮想マシンを強制停止するのか見極めるために必要です。
  5. 名前とLeader World ID(LWID)から目的の仮想マシンを特定します。
  6. "k"を押します。
  7. そうすると強制停止するWorld(WID)を聞かれます。ステップ5のLWIDを入力し、エンターを押します。
  8. 数秒の後、プロセスが消えてなくなります。

ESXiのロック機構

ですが、上のすべての選択肢が役に立たなかったらどうしたら良いのでしょうか?偶然に、他のホストが仮想マシンをロックしてしまったのでしょうか? もしも仮想マシンが応答しているものの、表示はされており、アクセス不能状態になっている場合には仮想マシンが現在動作しているホストがロックを保持している事になります。この場合、上のすべての方法は動作しません。たまたま、他のホストがロックをまだ保持したままになっているのです。過去に仮想マシンがどのホストで動作していたかということを知ることは常に重要な事です。以下のコマンドでどこに仮想マシンが登録されていたかということをvmware.logsから知ることが出来ます。

~ # find /vmfs/volume -name <vmname>
/vmfs/volumes/<DatastoreUUID>/<vmname>

findコマンドのあとは、当該のディレクトリへと移動するか、grepで検索を行います:


 # grep -i hostname vmware*

vmware-188.log:2016-08-11T14:45:26.065Z| vmx| I120: Hostname=am1ifvh004
vmware-189.log:2016-08-25T14:10:15.054Z| vmx| I120: Hostname=am1ifvh003
vmware-190.log:2016-09-02T01:39:45.934Z| vmx| I120: Hostname=am1ifvh003
vmware-191.log:2016-09-13T05:31:17.699Z| vmx| I120: Hostname=am1ifvh003
vmware-192.log:2016-09-13T15:55:42.495Z| vmx| I120: Hostname=am1ifvh003
vmware-193.log:2016-10-07T15:59:35.317Z| vmx| I120: Hostname=am1ifvh004
vmware.log:2016-10-10T17:04:38.627Z| vmx| I120: Hostname=am1ifvh003

仮想マシンが2016-10-10T17:04:38.627Zから am1ifvh003 ホストで動作していることがわかります。

どのデータストアで仮想マシンが動作していた家を見つけるもう一つの方法は既にご紹介したesxcliコマンドです。クラスタ内のデータストアにアクセス可能なホストのうちの一つから以下の例を使って、どこに仮想マシンが登録されているのか見ていきます。vCenterがダウンしている場合には仮想マシンが最後にどこにいたのかを知るためには上の例を使ってください。.vmxファイルがどこにあるのかは、このファイル自身がESXiからの.lckファイルになっているので2通りの方法があります:

  • esxcliでどこに構成ファイルがあるのかを探す:

~ # esxcli vm process list | grep -i -A 4 <vmname> | grep -i 'Config File' | awk '{print $3}'

--> /vmfs/volumes/<DatastoreUUID>/<vmname>/<vmname>.vmx

  • プロセスが半死の状態で、有益な情報を得られない場合にはlsofコマンドがもう少しだけ助けてくれる場合があります。
~ # lsof | grep -i <vmname>.vmx.lck | awk '{print $NF}'

--> /vmfs/volumes/<DatastoreUUID>/<vmname>/<vmname>.vmx.lck

VMFSのロック機構の説明

  1. 最初はチェックしたい仮想マシンのディレクトリへと移動し、誰がロックを保持しているのかを見ます。
~# cd /vmfs/volumes/<DatastoreName/<UUID>/<vmname>/
  1. vmkfstools -D を利用して2つのことを確認します:
  • どのMACアドレスがロックを保持しているか
  • そのファイルがどのオフセットを保持しているか
~# vmkfstools -D <vmname>.vmx.lck
Lock [type 10c00001 offset 189607936 v 46492, hb offset 3723264
gen 3377, mode 1, owner 57f7c8e2-8f5d86e3-efc8-001b21857010 mtime 110695
num 0 gblnum 0 gblgen 0 gblbrk 0]
Addr <4, 438, 118>, gen 46491, links 1, type reg, flags 0, uid 0, gid 0, mode 600
len 0, nb 0 tbz 0, cow 0, newSinceEpoch 0, zla 4305, bs 8192
  1. 最初の簡単な方はOwner IDの最後の部分001b21857010を確認することです。これはロックを保持しているホストのNICの一つのMACアドレスに関連しています。"esxcli network nic list"コマンドを利用して、誰がそのNICを保持しているのかを調べることが出来ますし、c#のvSphereクライアント、Webクライアント、もしくはシェルでも誰が<vmname>.vmx.lck ファイルのオーナーなのかを確認できます。
~# esxcli network nic list | awk '{print $1,$8}
Name Status
------ -----------------
vmnic0 38:63:bb:3f:19:48
vmnic1 38:63:bb:3f:19:49
vmnic2 38:63:bb:3f:19:4a
vmnic3 38:63:bb:3f:19:4b
vmnic4 00:1b:21:85:70:10
vmnic5 00:1b:21:85:70:11
  1. 2つ目のオプションはowner IDがゼロとして表示された際に利用するものです。この場合、<vmname>.vmx.lckファイルのオフセットを利用します。以下のコマンドを利用してください:
~# hexdump -C /vmfs/volumes/<datastore>/.vh.sf -n 512 -s <offset>
データストアは仮想マシンが動作しているデータストアです、ですから、一段戻ってデータストアレベルで実行してください。オフセットの値は以前のコマンド(上では 3723264)です。
  1. アウトプットの16進数のオフセット(黄色にハイライトしてあります)を利用してESX/ESXiホストのMACアドレスとロックの状態を調べることが出来ます:
~#  hexdump -C /vmfs/volumes/<datastore>/.vh.sf -n 512 -s <3723264>
0038d000  02 ef cd ab 00 d0 38 00  00 00 00 00 31 0d 00 00  |......8.....1...|
0038d010  00 00 00 00 fa 0f e1 f5  ee 00 00 00 e2 c8 f7 57  |...............W|
0038d020  e3 86 5d 8f c8 ef 00 1b  21 85 70 10 81 d1 0c 01  |..].....!.p.....|
0038d030  0e 00 00 00 3d 04 00 00  00 00 00 00 00 00 00 00  |....=...........|
0038d040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
0038d200

7番目から12番目までのバイトがMACアドレスです :00 1b  21 85 70 10

それから"esxcli network nic list"を利用してそのオーナーを調べます。これが特定のホストの物理NICのものになります。こうして、仮想マシンが他のホストに登録されており、ロックされていることが確認できればロックを保持しているホストへと仮想マシンを再度移動させて、仮想マシンを起動させることが出来ます。DRSをマニュアルにしておくということを忘れないで下さい。そうしておかないと仮想マシンは他のホストで間違って起動されてしまいます。ここまでの全てができなかった場合、最終的な手段としてはロックを保持しているホストの再起動になります。

NFSのロック機構の説明

NFSの場合には誰がロックを保持しているのか問うことを確かめるにはちょっと事情が異なります。これはファイルベースのプロトコルですから、当たり前のことです。

  1. 仮想マシンのディレクトリへと移動します。( "esxcli vm process list"コマンドなどで同様にどこに仮想マシンがいるか見つけられます)
  1. VMFSとは異なり、ファイルでのすべての操作は対応する .lckファイルに対してのものになります。VMDKの数が少ない仮想マシンの場合でも、そこそこの数の .lckファイルが表示されます。ですからどれが.vmx.lckなのかを見つけなくてはいけません。".lck-3409000000000000"を例として取り上げましょう。
~# ls -lA | grep .lck-
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-3409000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-3d01000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-4801000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-5301000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-5e01000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-6901000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-7401000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-7f01000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-8a01000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-9501000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-a001000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-ab01000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-e201000000000000
-rwxrwxr-x    1 root     root            84 Oct 19 13:29 .lck-f208000000000000
  1. hexdumpコマンドで各.lckファイルのホスト名を調べなくてはなりません。
~# hexdump -C .lck-3409000000000000
00000000  fd 79 97 00 00 00 00 00  23 01 cd ab ff ff ff ff  |.y......#.......|
00000010  01 00 00 00 61 6d 31 69  66 76 68 30 30 33 00 00  |....am1ifvh003..|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 57 ac 79 10  71 18 c3 9e f3 16 00 1b  |....W.y.q.......|
00000040  21 85 70 10 00 00 00 00  00 00 00 00 00 00 00 00  |!.p.............|
00000050  00 00 00 ff                                       |....|
00000054
  1. 上の例では、このロックファイルがam1ifvh003で保持されています。これでどのホストがこの.lckファイルを持っているのことがわかりました。しかし、.lck-3409000000000000がどのファイルのためのロックなのかがわかりません。今度はエンディアンを以下の図にあるようにひっくり返さなければなりません。

    Fig144

図2: ビッグエンディアンからリトルエンディアンへの翻訳
  1. 次のステップは16進数から10進数への変換です。今回のサンプルでは、エンディアンは必要のない0で多く埋め尽くされています。翻訳はこの通り: 0x934 = 2356 (10進数)
  2. さて、続いて以下のコマンドでどのinodeを参照しているのかを調べます:
~# stat * | grep -B2 2356 | grep File
File: am1ifpt002.vmx.lck

つまり、最初のロックファイルは<vmname>.vmx.lck ファイルということになります。

  1. このコマンドを活用して、自動的に同じことをESXi上で行うことも出来ます。(この例では、エンディアンをひっくり返す必要もなくなります):
~# stat * | grep -B2 `v2=$(v1=.lck-3409000000000000;echo ${v1:13:2}${v1:11:2}${v1:9:2}${v1:7:2}${v1:5:2});printf "%d\n" 0x$v2` | grep File
File: am1ifpt002.vmx.lck

結論

仮想マシンがフリーズしてしまうのには数多くの理由が考えられます。誰がロックファイルを保持しているのかを様々な方法で見つけ出すことができれば、仮想マシンをどのように強制終了させるのか、フリーズした仮想マシンの問題をどのように解決するのか、多くの場合の糸口を見つけることが出来ます。もちろん、最初にご説明したようにストレージシステムやSCSI予約の問題、ストレージシステムのバグによる嘘のinode番号、などが原因ということも有ります。私の記事が気に入った、もっといい提案や推奨したい方法があるなど、いつでもお気軽にご連絡ください。

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

今回はvExpertのAdvent Calenderということで、普段は絶対に訳さないようなテッキーな内容をお届け致しました。実は結構このあたり、お客様で発生したトラブルでPernixDataが悪さをしているという嫌疑をかけられ、その原因調査などで実際に使ったテクニックなんかも含まれていたりして。

いずれにしても、仮想マシンのフリーズ、あまり出くわしたくない事象ですが、万が一出くわしてしまった場合、盲に再起動するのではなく原因を調べ、再発を防ぐために何らか情報が欲しいものです。今回の情報はおそらく他にはないレベルでこれを説明した内容でしょう。Guidoさん、いつもありがとう!

2016/12/08

vRealize Network Insightができるネットワーク仮想化の見える化

皆さん、こんにちは。ソリューションアーキテクトをしている工藤です。この記事はvExperts Advent Calendar 2016に参加しています。

今日はは8月にリリースされたvRealize Network Insightを紹介します。
vRealize Network Insightは元々はスタートアップベンダーであるArkin社を2016年6月に買収して、vRealizeブランドとして製品化されたものになります。画面だけではなかなか伝えきれないこともあるため、各機能の動画を紹介しています。動画をご覧頂きvRealize Network Insightができることを理解いただければ幸いです。

■vRealize Network Insightとは?

vRealize Network Insightは、ざっくり言うとネットワーク版vRealize Operations Managerということができます。サーバ仮想化のリソースを見える化するのがvRealize Operations Managerだとすると、ネットワーク仮想化のリソースを見える化するのがvRealize Network Insightになります。何とかInsightというとvRealize Log Insightの印象がありますが、できることはvRealize Operations Managerに近いのです。

ざっくり言ってしまいましたが、もちろんvRealize Operations Managerだとネットワークの状態がわからない、vRealize Network Insightでは仮想マシンの状態がわからないといったことはありません。あくまでもvRealize Operations ManagerはvSphereのホストや仮想マシンを中心として、vRealize Network Insightはネットワークを中心にそれぞれ必要な機能にフォーカスしているだけですので安心してください。

vRealize Operations Managerは、性能情報仮想基盤のインベントリ情報を組み合わせて見える化します。

1_2

vRealize Log Insightは、ログ情報見える化します。

2_2

vRealize Network Insightは、パケット仮想基盤のインベントリ情報などを組み合わせて見える化することで仮想基盤のネットワーク管理にかかる運用工数を改善する製品です。

3

ではvRealize Network Insghtが実際にどんなアーキテクチャで、ネットワークの見える化を実現しているのか見ていきたいと思います。

■vRealize Network Insightのアーキテクチャ

vRealize Network Insightは現在2つの仮想アプライアンスから構成されます。

4

Proxy VMは、vCenterやNSX Manager、物理スイッチからインベントリ情報や設定を収集する役割と、vSphere上の分散スイッチのNetFlowで送られたフロー情報を収集する役割があります。

このときNetFlowでは通信パケット全てを送るわけではなく、パケットのヘッダ情報だけをやりとりしているためセキュリティ上も安心ですし、転送帯域も膨大には必要ありません。

Platform VMはProxy VMが収集したこれらの情報を解析して見える化する役割と、管理者にダッシュボードを提供する役割を提供します。

vRealize Operations Managerもそうですが、膨大な収集したデータを解析するため仮想アプライアンスに要求されるスペックが大きいので既存環境に追加する際には考慮が必要です。

■vRealize Network Insightで通信の可視化

vRealize Network Insightはこれまでの説明でもあったように、NetFlowを使った通信フローの可視化を行います。分散スイッチのレイヤで通信フローが収集されるため、ゲートウェイを介した通信だけでなく同一セグメントの通信はもちろん、同一ホスト内で物理的にはLANケーブルを流れていない通信まで可視化することが可能です。マイクロセグメンテーションを行う際に利用するVMware NSXの分散ファイアウォールのポリシー設計はもちろん、導入後のセキュリティ監査の目的で利用することができます。

5


YouTube: VMware vRealize Network Insight ネットワークフローの見える化

■vRealize Network InsightでNSX環境の健康診断

冒頭にvRealze Network Insightはネットワーク仮想化におけるvRealize Operations Managerのようなものですと説明しました。

vRealize Operations ManagerがvSphere環境の健康診断が行えるのと同じように、vRealize Network InsightではVMware NSX環境の健康診断を行うことができます。2016/12/1現在の最新版である3.1ではVMware社のベストプラクティスに基づいた40のチェック項目にわたる健全性確認を行い、ネットワーク仮想化基盤のトラブルを未然に防ぐことができます。

VMware vRealize Network Insight NSXの健康診断
YouTube: VMware vRealize Network Insight NSXの健康診断

■vRealize Network Insightで仮想基盤ネットワークのトラブルシューティング

vRealize Network InsightはNSXを導入した際の「NSXと物理ネットワークのトラブルシューティングが難しそう」といった相談を多くうけます。先ほど紹介したNSX環境の健康診断で安定したネットワーク仮想化基盤の維持ができます。

またvRealize Network InsightではNSXが構成するオーバーレイネットワークと物理スイッチが構成するアンダーレイのネットワークを一元的に管理することができます。


YouTube: VMware vRealize Network Insight 仮想ネットワークのトラブルシューティング

■まとめ

vRealize Network Insightを利用することで、VMware NSXが実現するネットワーク仮想化を低コストで運用していただくことが可能になります。
ご興味のある方は、VMware社が提供するオンラインラボを使ったハンズオン環境もありますので是非ご利用ください。
http://labs.hol.vmware.com/HOL/catalogs/lab/2894