*VMware Feed

2017/05/03

vSphere Data Protection(VDP)6.1.4 

初期セットアップTips

vSphere Data Protection(VDP)6.1.4について初期セットアップ時のTipsを2つお知らせします。

1.vSphere Web ClientにVDPプラグインが表示されない場合の対処方法 

-----------

①https://<VDP_IP>:8543/vdp-plugin-package.zip にアクセスしてプラグインをダウンロードします。

②vCenter アプライアンスの下記の階層に
/var/lib/vmware/vsphere-client/vc-packages/vsphere-client-serenity/
vdp-plugin-package.zipをコピーします。

③vdp-plugin-package.zip をunzip すると ファイルとディレクトリに解凍されます。

vxvcenter:/var/lib/vmware/vsphere-client/vc-packages # ls
vsphere-client-serenity
vxvcenter:/var/lib/vmware/vsphere-client/vc-packages # cd vsphere-client-serenity/
vxvcenter:/var/lib/vmware/vsphere-client/vc-packages/vsphere-client-serenity # ls
vdp-plugin-package.zip
vxvcenter:/var/lib/vmware/vsphere-client/vc-packages/vsphere-client-serenity # unzip vdp-plugin-package.zip
Archive: vdp-plugin-package.zip
creating: plugins/
inflating: plugin-package.xml
inflating: plugins/service-plugin-6.1.4.jar
inflating: plugins/vdr-ui-war-6.1.4.war

④サービスを再起動します。(vSphere Web Clientの接続が5分程度中断します。)

# service-control --stop vsphere-client
# service-control --start vsphere-client

2.テストメールは問題ないのに<スケジュールしたステータスメールが送信されない場合の対処方法 

VDPのログは下記にあります。

/usr/local/avamar/var/vdr/server_logs/vdr-server.log

今回ご紹介する対処方法はログに次のメッセージが記録されている場合に有効です。
2017-04-15 20:00:00,186 ERROR [VDP-email-report-timer-task]-schedule.EmailReportTimerTask:
Failed to send the email summary report.
Reason: java.rmi.RemoteException: VI SDK invoke exception:com.vmware.vim25.ManagedObjectNotFound; nested exception is:


①vi でファイル /usr/local/avamar/lib/mcsutils.pmを編集します。 

以下の行を追加します。
. "-Dsecurity.provider.rsa.JsafeJCE.position=last "

追加する行は決まっていて、
. "-Dfile.encoding=UTF-8 "と
. "-Dlog4j.configuration=file://$mcsvar::lib_dir/log4j.properties "; # vmware/axis 行の間に追加します。


②VDPアプライアンスをリブートします。

                             担当:磯前

2017/02/28

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

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


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


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


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


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


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

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

  

Vmfs6_4

                

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

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



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

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

Vmhw13_4

  

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

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

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

Efi_4

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

Vmenc

 

NBDモード利用時の圧縮

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

Nbdcomp_4


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


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

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

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

担当:臼井

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からリストアできる

デメリット

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

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

宮内

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

2016/11/29

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

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

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

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

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

AOS 4.7のリリースから5ヶ月が立ち、Nutanixは多くの新機能と改善点を備えたメジャーリリースヴァージョンをアナウンスしようとしています。AOS 5.0は社内ではエンジニアリングコードネーム「Asterix」と呼ばれていたものです。Nutanixによるその機能や改善のリリースのスピードはAWSやコンシューマー業界としか比べることが出来ないほどで、その素晴らしい更新のペースがユーザーを感動させています。このブログの記事ではもうしばらくでリリースされるNutanixのソフトウェアについてご紹介していきます。もしも以前のリリースについてのアナウンスを見たいのであれば以下を読んで下さい。

※訳注 4.7以外の記事についての和訳予定はありません。

本記事は本シリーズの1番目の記事です。2つ目3つ目4つ目

本記事では以下の機能についてご紹介していきます:

  • 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への認定
  • ・・・さらにパート2で

今後の数週間でプロダクトマネージャやプロダクトマーケティングマネージャチームが数々のブログ記事を書き上げ、もっと詳細なAOS 5.0の情報が出てきます。その一つ目がShubhika TanejaによるTen Things you need to know about Nutanix Acropolis File Servicesです。

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

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

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

プラットフォーム

Cisco UCS B-シリーズ ブレード サーバ サポート

本日、 .NEXT EMEAの中でNutanixは今後のCisco UCS B-シリーズ ブレード サーバのサポートについてアナウンス致しました、以前にアナウンスしたC-シリーズのラックマウントサーバのサポートに加えてのサポートです。

Fig092

現在、UCS B200-M4ブレードは物理容量3.2TBのオールフラッシュストレージに限定されています。フラッシュの制限によってストレージ容量の要件に見合わないという事が多くの場合でいえます。Ciscoや他のハイパーコンバージド製造メーカーは結果としてそのソリューションをラックマウントサーバに限定してきました。

NutanixはB-シリーズブレードのストレージ容量の不足の問題をストレージ専用ノードをB-シリーズのブレードのクラスタに追加することで解決させました。リリース後はオールフラッシュのC240-M4SXのストレージ専用ノードをクラスタに追加することが出来、最大でノードあたり24本まで1.6TBのSSDを追加することが出来ます。Nutanix固有のコンピューティングとストレージを異なった割合で自由自在に組み合わせられるという能力がこれを実現しました。

ストレージ専用ノードはUCSのお客様のブレードとC240間でのバランスのチューニングも実現することになります。更にはコンピューティングとは独立したストレージの拡張も実現します。古い筐体が容量が一杯になる度に新しいストレージ装置に巨大な投資を行うのではなく、お客様は必要に応じて順次環境を拡張して行けるようになるのです。

ストレージ専用ノードはNutanix AHVを利用して動作しています、ですから、追加で仮想化ソフトウェアのライセンスのためのお金が必要になるということはありません。AHVのストレージ専用ノードはESXiのノードと同じクラスタ内に混在させることが可能です。

Fig093

AMF(Application Mobility Fabric - アプリケーション モビリティ ファブリック)

Acropolis アフィニティとアンチ-アフィニティ

仮想マシン-ホストの固定アフィニティ

管理者が特定のワークロードが同一ホスト内で動作する事を保証したいという場合。例えば、多くの会社では、アプリケーションを仮想マシン内で動作させていますが、特定のアプリケーションはライセンシングの規約から、特定のホストに紐付いているということが有ります。管理者は仮想マシンに対してホストアフィニティルールを設定し、これらの仮想マシンを特定のホストで動作させ、他のホストへと移行しないようにすることが出来ます。

  • Acropolisは以下のHAやメンテナンスモードの最中の仮想マシンをサポートすることが可能です。
    • 予約モードのHAでは、仮想マシンの再起動のためのリソースが別のアフィニティホスト上に予約されます。Acropolisはこの予約が保証されない場合には仮想マシンの電源が入ることを許可しません。
    • ベストエフォートのHAの場合、Acropolisは別のアフィニティホスト上で再起動が出来ない場合、仮想マシンの電源をオフにします。
    • メンテナンスモードの場合、Acropolisは仮想マシンが別のアフィニティホストへと退避できない場合には仮想マシンの退避を行いません。

仮想マシン-仮想マシン 優先的アンチ-アフィニティ

特定の仮想マシン同士が同じホストで動作するべきではないと言う場合です。例えば、殆どの組織ではドメインコントローラーはいかなる場合においても最低一つは残って稼働し続けて欲しいという要件があります。このために組織はパフォーマンスの観点からは同じホストで仮想マシンが動作するほうが良い結果になる場合であっても、仮想マシン同士にアンチ-アフィニティルールを設定し、仮想マシン同士が別々のホストで稼働するようにというルールを設定します。

  • 結果として
    • 仮想マシンは優先的アンチ-アフィニティポリシーを持つ。
    • スケジューラーによる配置の最中はポリシーに違反することもある。
    • もしDRSが違反を解消できない場合、警告が発報される。

アフィニティの説明はこちらも参照ください。http://www.virtualizationadmin.com/blogs/lowe/news/affinity-and-anti-affinity-explained.html

Acropolis ダイナミック スケジューリング(DRS++)

システム管理者はDRSのコンセプトは既にご理解いただいていると思います。DRSはコンピューティングワークロードを利用可能な仮想化環境内のリソースでバランスします。- 今日DRSはほとんどの仮想化スタックの一部といえるようになっています。

DRSはキャパシティプランニングと密接に関係しています - キャパシティプランニングはより長い時間軸を対象としたものであるという例外はありますが、DRSによる最適化はキャパシティの制約がある環境で、もっと短い間隔で実行されます。

AHVのダイナミックスケジューリングは最初は既存のDRSの実装とさほど大きく変わるものでは無いかもしれませんが、Nutanixは要素としてコンピューティング、メモリ、そしてストレージのパフォーマンスをも配置決定の考慮に加えます。Nutanixの管理者はAHVのDRSがリソース(CPU、メモリ、そしてストレージIO)の競合やその後の一時的なリソースCPU、メモリ、ストレージIOの競合を事前に回避(または、回避のための推奨事項の生成)して、仮想マシンの電源を入れてくれるので「心の平穏」をもって管理に当たることが出来ます。

REST API 2.0 と 3.0

NutanixのREST APIについての大きな変更が今回のヴァージョンに含まれており、これにはAPIのヴァージョン、後方互換性、APIの衛生化、そして標準化が含まれています。さらに、新しいREST 3.0もプラットフォームの一部として含まれています。

REST 3.0はスケールアウトを意図して作られているAPIであり、組み込みのロードバランサのゲートウェイとして動作します。実装の実際のスキーマ(これは変わる可能性があります)詳細を実現するのではなく、REST 3.0は高いレベルでのユーザーの意図する実際のユースケースのコンセプトを規定するものです。

ユーザーの意図をマッピングすることで ー つまりユーザーが実現したいことをマッピングすることで、NutanixはAPIをパラメーターをセットするだけで与えられた操作を実行できるようにする機会を得ることが出来るのです。Nutanixがここで実現したことは大変なNutanixに固有のビジネスロジックをその呼出元から削除し、Nutanix内部(あるべき場所)へ配置したということです。

新しいNutanix APIポータルは既に利用できるようになっており、開発者は古いものや新しいREST 3.0の意図する仕様を直ぐに見ることが可能です。ポータルではPython、Java、Go言語、PowerShellのサンプルが提供されており、http://developer.nutanix.comまたはhttps://nuapi.github.io/docsでアクセスできます。

Fig094

XenServerのサポート TechPreview

Fig095

これはアナウンスの再掲載となりますが、NutanixはXenServer上で動作しているXenApp、XenDesktop、NetScaler VPXそして、NetScalerを含むCitrixのアプリケーションに対するサポートをNutanixプラットフォームに上で提供することになります。AOS 5.0からXenServerのお客様はXenServer 7をテクニカルプレビューとしてNutanixプラットフォーム上で動作させることができるようになるのです。

プレスリリースについてはこちらをご参照ください。

Prism

ネットワーク可視化

もしもネットワークが誤って構成されたら、アプリケーションの仮想マシンは動作を止めるか、パフォーマンスの低下が起こります。例えばVLANが誤って構成された場合、アプリケーションはそれぞれお互いに通信ができなくなります。ネットワーク構成の不整合、例えばMTUの不整合やリンクスピードの不整合などが起こると、大量のパケットのドロップによってパフォーマンスの劣化が起こります。

ネットワークの問題のトラブルシューティングを難しくしているのは単一のネットワークのパス上にあるすべてのスイッチの構成のミスが原因を作り出す可能性があるからで、管理者はトラブルシューティングを行う際にネットワーク全体の構成を見なくてはならなくなるからです。

これがまさにネットワーク可視化が解決しようとしていることです。各々の仮想マシンから仮想スイッチ、物理ホストのネットワークカード、TOR(トップオブラック)スイッチなどに至るまでのネットワーク全体の表示を提供します。VLAN構成などのネットワーク構成の要素情報も直感的で使いやすいインターフェイスに表示します。管理者は例えば、ユーザーやプロジェクトやホストにグルーピングしながらネットワークを簡単に探索できます。

NutanixはLLDPと/もしくはSNMPを利用してネットワークトポロジを検証します。構成情報をスイッチから取得するためにSNMPを利用します。例えば、ネットワーク状態に加え、それぞれのポートのVLAN情報を収集するためにはSNMPを利用します。一旦仮想と物理のネットワーク要素から構成や統計とともにトポロジの情報を収集し終わると、Nutanixは利用しやすいインターフェイス上にその情報を表示します。(最初のリリースではAHVのみで動作します。)

Fig096

Fig097

新しいワークロードのためのWhat-if分析と割当ベースのフォーキャスティング(予測)

Pay as you go(必要なだけ支払う)

  • クラスタ内であとどれだけの仮想マシンが動作するか?
  • もし1ヶ月後に新しくSQLサーバを追加するとしたら、クラスタは大丈夫か?
  • もし、現在のペースでワークロードが増え続けたらクラスタはいつまで大丈夫か?
  • 一定のワークロードがあり、新しくクラスタを作りたいがどのようなクラスタが必要か?

What-if分析は新しく将来に追加されるワークロードをその追加の時期とともに指定するものです。既存の仮想マシンを例えば、既存の仮想マシンと同じインスタンスが10個追加されたとしたら、という具合に指定することも出来ます。または、既存のワークロードとの差異を%で指定することも可能です。そして、ワークロードの拡張と縮退の両方を指定することが出来ます。そして、ついに、事前定義されたよくあるワークロードをその一つとして指定することが出来るようになりました。

たとえば、ビジネスクリティカルな中規模サイズのOLTPのSQLサーバのワークロードを指定したりすることが出来、what-ifツールはそのワークロードのサイズを見積もることが出来ます。what-if分析ツールは正確なサイジングの見積もりを行うことが出来る理由は、このツールが我々が最初の導入時に推奨構成を割り出すためのNutanixのSizerと統合されているからです。つまり、what-if分析ツールは様々な事前定義されたSQLサーバやVDI、Splunk、XenAppなどのワークロードを利用することができるのです。

Nutanixは既にランウェイ(将来予測)コンポーネント表示を提供していますが、これはキャパシティプランニングのアルゴリズムで異なる様々なリソースのランウェイ(将来予測)を予測し、クラスタ全体のランウェイ(将来予測)を予測しているのです。これを下に、what-if分析は管理者にどうしたノードを追加するべきだという推奨事項を、いつまでに追加するべきだという情報とともに提示することが出来、ランウェイ(将来予測)が本来のランウェイ(あるべき姿)にまで拡張されるようにすることが出来るのです。

一度ワークロードとハードウェアを追加すれば、システムは推奨事項を提示します。what-ifのUIに表示されるものを皮切りに変更やチューニングを行うことも可能です。例えば、様々なハードウェアの推奨構成の追加のタイミングを予算上の制限と調整を行い、ランウェイがどのように変化するのかを見たり、同様にワークロードの追加のタイミングを調整したりすることが出来ます。プライオリティの低いワークロードであれば後からということも有りますよね。あなたにとって最適なワークロードとハードウェアのプランが出来るまで好きなだけチューニングを行うことが出来ます。

Fig098

Fig099

Fig100

Fig101

Fig102

Fig103

Fig104

Fig105

Fig106

Fig107

Fig108

ネイティブのセルフサービスポータル

AOS 4.6ではAHVへのNova、Cinder、Glance、そしてNeutronのドライバーの提供によってOpenStackのサポートが導入されました。OpenStackはマーケットに広く受け入れられつつ有り、Nutanixと完璧に協調動作しますが、OpenStackはネイティブなNutanixソリューションではなく、OpenStackはそれを支えるあらゆるインフラストラクチャとともに動くように作られているため、多くのNutanixの先進的な機能を活用できるようにはなっていません。

NutanixのネイティブなセルフサービスポータルはPrismに統合されており、ITリソースへのアクセス、ポリシー、セキュアなテナントベースのアクセスを実現します。ポータルによってテナントはIT(情報システム部)の介在なくアプリケーションを展開でき、組織は開発者やテナントへAWSのセルフサービスに似たエクスペリエンスを提供することが出来るようになります。

管理者ポータル

  • プロジェクトの作成/管理
  • ユーザーとグループの作成/追加
  • リソースのアサイン
  • アクションのアサイン
  • ショーバックレポートの実行

テナントポータル

  • カタログ(仮想マシンテンプレート、vDisk、Docker Hubのイメージ、アプリケーションテンプレート)からのアプリケーションの展開
  • アプリケーションの監視
  • アプリケーションのリソース利用率の監視

Fig109

スナップショット - セルフサービスリストアのUI

Nutanix AOS 5.0はついに仮想マシンのユーザーがファイルレベルでリストアを行うためのユーザーベースのPrism UIを追加しました。この機能によってユーザーは自身の仮想マシンのファイルやフォルダの復元をセキュアにまた、管理者の手をわずらわせることなく行うことが出来ます。

Fig110

Fig111

Fig112

本日、ウィーンで実施された.NEXTカンファレンスでNutanixはネットワーク接続サービスとネットワークパケット処理サービスを統合、拡張された新しいネットワークのフレームワークについてもアナウンスを行いました。

ネットワーキング、セキュリティパートナーの製品を活用することが出来るサービスの挿入、チェイニングそしてウェブフックの組み合わせによって提供される壮大な可能性を秘めた機能です。

パートナーと共に現在開発中の幾つかのユースケースは:

  • ネットワーク展開のワークフローと対応するNutanix上のワークロード展開のワークフローの自動化
  • パートナースイッチへのオンデマンドでのVLAN展開の自動化
    • アプリケーション(幾つかの仮想マシンの組)がNutanix上で起動する際に、対応する物理ネットワークスイッチが自動的にそのワークロードのための適切なネットワーキングポリシーのもとに構成される
    • Nutanix上からアプリケーションが削除される際に、対応したネットワークポリシーが自動的に物理ネットワークスイッチから削除される
    • Nutanix上の仮想マシンがNutanixクラスタ内の別のホストにライブマイグレーションされる際(同じTORの別のポートや別のスイッチへ接続されている可能性がある)に、対応する以前利用していたスイッチとこれから利用するスイッチの両方に変更を適切にネットワーク構成を行う
  • ネットワークの「仮想マシンからみた表示」をNutanixに収集しパートナースイッチベンダーの情報を元に表示、つまりネットワーク管理者がパートナーのスイッチを管理できるように
  • 「仮想マシン中心」のネットワークの運用表示を提供し、ネットワーク管理者による物理ネットワークのトラブルシューティングをより迅速、より正確なものにする。ネットワーク管理者はパス、フローの追跡、仮想マシン名、タグ、ラベルに対応する統計情報によって根本原因の解析を迅速に行えるようになる。このインテリジェンスはNutanixによって、物理ネットワークデータベースへ仮想マシンの特徴(仮想マシン名と紐付けられたラベル、そして仮想マシンのIPアドレスとMACアドレス情報)として提供されます。
  • LLDPによるトポロジのディスカバリのサポート(Nutanixのノードと対応するTORスイッチノードとのマッピング)

Fig113

単一ネットワークパケット処理(Network Packet Processing - NPP)サービス挿入

NPPはクラスタ全体にサービス挿入し、ネット枠サービスがAHVクラスタ上で動作することを実現するネットワークのフレームワークの一つです。NPPは以下をサポートします:

  • パートナーサービスのイメージとプラグインの登録ワークフロー
  • サービスの展開 - クラスタ全体またはクラスタ内のサブセットに対して
  • ネットワークレベル挿入 - 通信内への割り込みとタップモードでの挿入モード
  • ゲストOSのライフサイクルイベントのプラグイン起動によるパートナーサービスへの通知
  • 対象となる仮想マシンのプロパティの通知 - ネイティブなプロパティ(IPとMACアドレス)とメタデータプロパティ(ラベル、カテゴリ、名前)の両方をサポート
  • サービスへの選択的なトラフィックのリダイレクト(ゲストOSの仮想NICの一部を指定)

パケット処理サービスチェイニングフレームワーク

Nutanixのネットワーキングパートナーは今日ではパケットがAHVネットワークを流れていく際にそれを検査し、変更するか、または廃棄してしまう機能を利用できます。サービスチェインフレームワークはAHVの仮想スイッチを自動構成し、パケットをNutanixパートナーによって提供されてるパケット処理(パケットプロセッサ)仮想マシンイメージやサービスへとリダイレクトするようにします。それによって利用できるサービスは:

  • インライン処理 - プロセッサが仮想スイッチ経由で流れてくるパケットの変更又は廃棄
  • タップ処理 - プロセッサが仮想スイッチ経由で流れてくるパケットを検査する
  • プロセッサチェイン - 複数のプロセッサを利用、同一ベンダまたは複数ベンダで利用できる、別々のサービスを提供するそれぞれをつなげて(チェインして)利用できる

ウェブフックベースのイベント通知(ネットワークオーケストレーション)

Nutanixのネットワーキングパートナーはいつであれウェブフックのイベント経由でクラスタ、ホスト、仮想マシンで発生したイベントの通知を受けとり、すぐに対応することが出来るようになりました。例えば、あるネットワーキングパートナーは仮想マシンネットワークのVLANが変更されたり、仮想マシンがライブマイグレーションして別のホストへ移動した際にパケット検査のポリシールールを適応するようにという警告を上げたいとします。ウェブフックを利用することでパートナーは非常に先進的な問題解決方法を実装し、そのワークフローによって全データセンタを自動化することが出来るようになります。

Fig114

既に統合の終わっているパートナーのデモを幾つか御覧ください。

Brocade

Mellanox

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

メトロアベイラビリティウィットネス

Nutanixのメトロアベイラビリティはデータセンタ全体に及ぶ復旧に対してもシングルクリックで優れた仕事をしてくれます。しかしながら、いくらかのお客様はサイト障害なのか、もしくはネットワーク接続障害なのかが明言できない問題であるため、自動的な復旧についての機能を欠いていると感じておられました。ビジネスクリティカルアプリケーションを利用しており、DR手順を実行できるITスタッフがいない場合にはことさらです。

以前はNutanixは自動復旧の機能を備えていませんでした。これはサイトの障害とネットワークのそれの区別を行うことができなかったからです。AOS5.0はこの問題をウィットネス(証言者)仮想マシンを障害ドメインの外側に置くことで解決しました。このウィットネス仮想マシンはそれぞれのメトロサイトとメトロサイトの内部通信とは異なる通信を行い、メトロアベイラビリティにおける復旧の決断の自動化に役立てます。ウィットネス仮想マシンはメトロクラスタ間で自動的にリーダー選出を行うことで、スプリットブレーンシナリオの回避にも役立ちます。

Fig115

VMフラッシュモードの改善

VMフラッシュモードはPrism UIに戻って、更に改善されました! 仮想マシンフラッシュモードは管理者がハイブリッドシステムにおいて、レイテンシが重要となるミッションクリティカルなアプリケーションが動作している特定の仮想マシンをSSD層に置くことを実現します。改善点はハイブリッドシステムにおいて、重要な仮想マシンにオールフラッシュの一貫したレイテンシとIOPS、サービスプロバイダのためのQoSによる階層化やより高いIOPSを提供することです。以前VMフラッシュモードについて記事を書いていますので、興味があれば詳細はそちらへ。

Fig116

Acropolis ファイルサービス(AFS)

Acropolis ファイルサービスがいよいよ正式リリース (ESXi と AHV)

Acroplis ファイルサービス(またの名をAFS)はDSFにネイティブに統合されたコンポーネントであり、Windows ファイルサーバや外部のNetAppやEMC IsilonなどのNASストレージ装置を不要にするものです。AFSはAOS 4.6、4.7ではTech Preview扱いでしたが、AOS 5.0ではいよいよESXiとAHVハイパーバイザ上で正式リリースとなり、Nutanixのサポート対象として本稼働環境で利用できるようになります。

Acropolis ファイルサービス (非同期-DR)

AFSはNOSの非同期-DR由来のネイティブのデータ保護を提供します。仮想マシンとヴォリュームグループは保護ドメインを利用して保護され、他のすべてのDR関連の操作と同様にスナップショットのスケジュールやポリシーを保護ドメイン自身に適応することが可能です。

Acropolis ファイルサービス (AFSクオータ)

AFSはハード、およびソフトのクオータ制限が利用でき、メールによる警告の設定もできるようになりました。ハード制限を利用している場合、クオータを超えることは出来ず、もしもクオータ制限を超えるようなファイルの書き込みが発行された場合、その書き込みは失敗に終わります。ソフトクオータ制限を利用している場合、警告が利用者に送信されますが、データの書き込みは許可されます。

クオータのポリシーはクオータがユーザーか又はグループに対するものか、クオータの制限(GBでのサイズ指定)、クオータのタイプ(ハード または ソフト)、そしてクオータイベントをユーザーに通知するかどうかというルールの組み合わせて指定します。ポリシーの適応は1人のユーザーまたはADグループを含む特定のグループのすべてのユーザーで行うことが出来、標準ポリシーはユーザーもグループも指定されていない場合に適応されます。

Fig118

Fig119

Acropolis ファイルサービス (アクセスベースの一覧 - ABE)

AFSのアクセスベースの一覧では、ユーザーがアクセスの出来る権限を持つファイルとフォルダのみが表示されます。もし、ユーザーがRead(もしくはそれ相当)の権限をフォルダに対して持っていない場合、Windowsは自動的にそのフォルダをユーザーの表示から隠します。ABEはユーザーの共有フォルダの表示をREADアクセス権限によってコントロールします:

  • FIND(ディレクトリ一覧)を利用した場合の応答でユーザーがアクセスできるファイルシステムオブジェクトのみを表示
  • 機微なファイル、フォルダのタイトルをREADアクセス権のないユーザーから隠す
  • 共有レベルの構成パラメーター("hide unreadable(Read権がなければ隠す)")
  • トップレベルフォルダであるHOMEシェアの特別な取り回し

Acropolis ファイルサービス(パフォーマンスと拡張)

AFSは4CPU/16GBの仮想マシンのVMFSあたり500以上の接続が出来るように最適化されました。小さな3ノードで構成されるAFSクラスタでも最大6千万のファイル/ディレクトリまでのファイルサーバにまで拡張することができます。

Acropolis ファイルサービス(パフォーマンス最適化の推奨)

AFSは分散システムとして実装されているため、他のFSVMはアイドル状態にあったとしても幾つかのノード(FSVM)に負荷が偏る可能性があります。そのアクセス不可をノード間または追加のリソースで再分配することでAFSはクライアントにより良いパフォーマンスを提供できます。AFSは平均CPU利用率、SMB接続の数、メモリ割り当て構成、ヴォリュームグループのRead/Writeの利用帯域などを含むの多くの計測値を利用して利用状況を把握し、負荷のバランスを取って解決方法を決定します。

解決策には以下の可能性がありえます:

  • ヴォリュームグループの移動 : いくつかのヴォリュームグループを「ホットな」FSVMから対比し、負荷を下げる
  • スケールアウト : 既存のFSVMが忙しい場合には新しいFSVMを作成しヴォリュームグループを保持させます
  • スケールアップ : CPUとメモリリソースを全てのFSVMに追加します

推奨事項が生成された後に、「Load Balancing」というボタンがファイルサーバタブのRecommendationカラムに表示されますが、管理者はその推奨事項を選択することも、別のもので上書きすることも出来ます:

  • ヴォリュームグループの移動をスケールアップで上書き
  • スケールアウトをスケールアップで上書き
  • スケールアップの推奨事項は上書きができません

一度ユーザーがロードバランスアクションを選択するとタスクが生成されアクションが実行されます。

Fig120

Fig121

Acropolis ブロックサービス(スケールアウトSAN)

Acropolisブロックサービスは高い可用性、拡張性、そして高パフォーマンスのiSCSIブロックストレージをゲストへと提供します。ABSはAcropolisヴォリュームグループサービス上に構成され、AOS 4.5以降利用が可能です。ヴォリュームグループはブロックストレージを提供し、NFSデータストアではサポートされない、もしくはブロックストレージのインスタンス間での「共有」が要件となるようなエンタープライズアプリケーションにとってはとても重要な機能です。ユースケースとしてはESXi上のMicrosoft Exchange、Windows 2008ゲストクラスタリング、Microsoft SQL 2008 クラスタリング、Oracle RACなどがあります。

Acropolis ブロックサービス (CHAP 認証)

  1. Challenge-Handshake Authentication Protocol(CHAP認証プロトコル)
  2. 共有の"秘密"の認証コードと接続元
  3. 相互のCHAP – クライアントがターゲットを認証
  • CHAPは識別子とその試行値を順次変更し、接続元が「録画再生」型の攻撃を仕掛けてくることに対する防御を提供します。CHAPを利用する場合、クライアントとサーバが平文の秘密鍵を知っている必要があり、もちろんこれはネットワーク経由で送っては絶対にいけません。
  • 相互のCHAP認証。ターゲットとイニシエータが相互に認証しあうというセキュリティのレベル。別々の秘密鍵を相互にターゲットとイニシエータにセットします。

その他のABSの改善点:

  • ダイナミックロードバランシング
  • ヴォリュームグループのフラッシュモード
  • IPベースのイニシエータのホワイトリスト
  • イニシエータの管理
  • 幅広いクライアントのサポート - RHEL 7, OL 7, ESXi 6
  • オンラインでのLUNのリサイズ

ワークロードの認定

NutanixはAHVがABS上でOracle VMとOracle Linuxの認定を得たこと、そしてSAP Netweaver stackの認定を得たこともアナウンス致しました。これはビジネスクリティカルアプリケーションをNutanixプラットフォーム上に移したいと考え、OracleとSAPのサポートを待っていたエンタープライズのお客様にとって恋い焦がれたニュースでした。

Fig122

また、本日NutanixはAHVの1-クリックでのネイティブなマイクロセグメンテーションをあなうんすしています。しかしながらこの機能は今後のリリースに含まれることになります。機能と公式な時間軸についての情報はNutanixの公式プレスリリースをご参照ください(こちら)。

Fig123

なんとまぁ、長い機能リストでしょうか、しかも、これで全部ではないのです・・・。直ぐに更に多くの機能で満載のこの記事の第2弾をリリースします。お楽しみに!

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

久しぶりのAndreさんの記事ですが、ようやく公開することが出来ました。先週までのPrismの記事ではとことんまで突き詰めるコダワリを感じさせるものでしたが、今回の内容は正に怒涛のようにリリースされる新機能の嵐。

記事の最初の方にも有りますが、これほどの機能追加はコンシューマー向けのアプリケーションやAmazon Web ServiceやSales Force.comなどのクラウドでしか見ることが出来ません。ストレージ機能はブロック、ファイルサービスと既存のストレージベンダーを置き換えるものになりつつありますし、新たに加わったネットワーキングについてもかゆいところに手が届いている感じ、これが一番必要だよね、というどストレートな機能を直球勝負です。エコシステムパートナーとの連携を見ているといよいよHCIというインフラを脱して完全に「プラットフォーム」になってきていると思います。

やっと訳し終えたのに、Andreさんはもう次の記事に取り掛かっているそうです。次はタイムリーに公開できるようにがんばります!

2016/11/24

EMC UnityはVeeamファーストで行こう!

今年5月に「EMC VNX/VNXe」の後継として、日本で販売が開始された「EMC Unity」ですが、VMwareのストレージとして既に利用されている方やこれから導入しようと計画している方も多いと思います。そこで、Unityと相性ピッタリのバックアップソフトであるVeeam Backup & Replication (以下、VBR)を一緒に使うと、どのようなメリットがあるのかをご紹介します。


■Unityスナップショットからのリストア

Unity自体にスナップショット機能があり、CIFSのファイルサーバー用途では、WindowsのVSSと連携してファイル単位でのリストアが可能です。しかし、VMwareのデータストアとして利用している場合は、データストア丸ごとのリストアとなってしまい、1つのデータストア上に多数の仮想マシンがある環境では気軽に利用することができません。

Veeam14_7

 

 そんな時に便利なのが、VBRのVeeam Explorer for Storage Snapshotsです。Unityのスナップショットから仮想マシンの中のファイルをリストアすることができます。

Veeam02


Explorerから元の仮想マシンに対して直接リストアすることもできますし、任意の場所にファイルをコピーすることもできます。

Veeam15_3


更に、同様の手順で仮想マシンの中のアプリケーション単位(Active Directory,Exchange,SQL Server,SharePont Server,Oracle)でリストアすることも可能です。

Veeam03_2


例えば、Active Directoryのドメインコントローラの仮想マシンの場合には、ストレージスナップショットからユーザーやグループポリシー、DNSレコードをリストアできます。

Veeam04_3


短い間隔でスナップショットスケジュールの設定をしていれば、より最新のスナップショットデータから簡単にリストアすることができ、同じデータストア上の他の仮想マシンにも影響がないため、気軽にスナップショットを利用できます。


■Unityスナップショットの活用

Veeam Explorer for Storage Snapshotsのメリットは、Unityのスナップショットからのリストアだけではありません。インストタントVMリストア機能と組み合わせて、Unityのスナップショットから仮想マシンを直接起動することも可能です。これにより、仮想マシンに障害が発生した場合でも、リストアするよりも短時間で仮想マシンを立ち上げて、業務を継続することが可能です。

Veeam05


ストレージスナップショットから起動した仮想マシンはVBRのコンソールからStorage vMotionを実行することで、そのまま本番環境として利用することも可能です。

Veeam20_3

 
障害が発生していない場合でもスナップショットから起動した仮想マシンは、本番環境の完全に分離されたコピーになりますので、アプリケーションのインストールやパッチ適用のテスト環境、仮想マシン上で障害が発生している場合には、トラブルシューティング用の環境としての利用など、スナップショットを様々な用途で活用することができます。

最近では、バックアップデータから仮想マシンを直接起動できるバックアップ製品も増えてきていますが、VBRでは2010年にリリースされたバージョン5からインスタントVMリカバリ機能を提供しており、更に他社の上を行くストレージスナップショットからの起動を提供しています。


■Unityのスナップショットと連携したバックアップ

スナップショットは便利な機能ですが、ストレージ筐体そのものに障害が発生した場合には、全てのデータが消えてしまいます。そのため、別の媒体にデータを保存する”バックアップ”を行うことが重要ですが、バックアップにおいてもUnityにVBRを組み合わせるメリットがあります。

それは、Unityのスナップショットと連携してバックアップができることです。他社の仮想環境用のバックアップソフトでもUnity上の仮想マシンをバックアップすることはできますが、他社製品はストレージがUnityかどうかは見ていません。どのストレージを使っていても全て同じです。

しかし、VBRはデータストアがUnityのストレージであることを理解し、vSphereのスナップショットだけでなく、Unityのスナップショットと連携してバックアップをしてくれます。vSphereのスナップショットだけの場合、仮想マシンの容量が大きく、バックアップ時間がかかるケースや、バックアップ中に仮想マシンへの変更が多いケースでは、デルタファイル(Redoファイル)の肥大化やスナップショット削除時のマージ処理で問題が起きる可能性がありますが、Unityのスナップショットと組み合わせれば、このような問題を解決することができます。

バックアップジョブの設定もチェックを付けるだけです(デフォルトでチェックが付いています)ので、意識することなく簡単にストレージスナップショットと連携してのバックアップが可能です。

Veeam19_2

※Unityの接続(FC,iSCSI,NFS)にあわせて、VBRのサーバがUnityのストレージにアクセスできるようにUnity側やVBRのOS側の設定は必要になりますので、ご注意ください。

■どうやってUnityVeeamを組み合わせるの?

Unityと連携するには設定が難しいのでは?と思う方もいるかもしれませが、設定ウィザードに従い、Unityを登録するだけでVBRが自動的にストレージを検出してくれます。ウィザードの流れを見ていきましょう。

 ①[EMC]を選択します。

Veeam17_2


②[Unity]を選択します。

Veeam08_3

 
③Unity管理用のホスト名かIPアドレスを入力します。

Veeam09_2


④Unityの認証情報を入力します。

Veeam10_2


⑤自動でUnityが使用しているプロトコルを認識し、プロトコルにチェックが付きます。

Veeam11_2


⑥Unityの情報がサマリーで表示されますので、Finishで完了です。

Veeam12_2


⑦Unityの作成済みスナップショットと仮想マシンが表示されます。

Veeam13_3

このように簡単にUnityを登録できますが、vSphereとUnity、Veeamと複数の製品が絡むため不安だという方は、弊社の導入サービスをご利用いただければ、vSphere・Unity・VBR全て弊社で設定させていただきますので、ご安心ください!
http://www.networld.co.jp/support/introduction/


ご紹介した全ての機能はUnityだけでなく、VNXやVNXeでも利用できますので、VNX/VNXeを既にご利用の方は今からでも遅くありません。今のうちに、VBRを導入しておけば、何年後かにVNX/VNXeをUnityにリプレースする際にも、引き続き、VBRを利用することが可能です。

VMware環境でEMCストレージをご使用の際には、Veeamを真っ先に思い出していただければ幸いです。

 担当:臼井

2016/10/14

VMware Cloud™ on AWS – 詳細

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

本記事の原文はVMware Cloud™ on AWS – A Closer Lookで閲覧可能です。

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

長きに渡る沈黙を経て、ようやく少しだけ、私がVMwareで何にフォーカスをしてきたかということをお話できるタイミングになりました。(この記事の内容はblogs.vmware.comに掲載した内容の再掲です。)

本日、VMwareとAmazon Web Services(AWS)は完全なVMwareのSoftware Defined Data Center(SDDC)を動作させることが可能なクラウドサービスをAWS上で提供開始するという戦略的なパートナーシップを発表しました。このサービスはvSphere、ESXi、VSAN、そしてNSXを含む皆様がよく親しんだ全てのエンタープライズツールが含まれています。この記事では新しいVMware Cloud on AWS(VMC)サービスの技術的なプレビューを行います、もうすぐリリースされるめちゃくちゃクールなこいつを覗き見していきましょう。

Fig001このアーキテクチャは言わずもがな、夢の取り合わせです。vSphereをこれまでに利用してきた管理者や設計者はアプリケーションを再設計することや、運用手順を再構成することなくAWSの俊敏性を活用することができようになるのです。vCenterが運用の中心となるプラットフォームになりますから、現在オンプレミスのvSphere環境で利用しているvCenterと連携して動作する全てのツールがクラウドのSDDC環境で動作するというのが一つの大きな目玉です。こうした何年もの月日を経て開発されてきたツールや機能が、今後はクラウドの間をワークロードが移動出来る環境で利用することが出来るようになり、その上、新しいレベルでのデータセンタの俊敏性までもが利用可能なのです。

つまり、サインアップを終えて、クラスタのサイズを選択すればご自身のSDDC環境が短時間で作成されるということです。VMware cloudはネイティブなESXが、次世代のAWSのベアメタルインフラストラクチャ上で動作しているということを強調(そして誤解を避けるためにも)しておきます。VMware cloudはAWSインフラストラクチャ上のvSphere ESXiホスト、VSAN、NSXを含むプライベートクラウドとして展開されます。これによって、エンタープライズワークロードがオンプレミスの環境と同じレベルのパフォーマンス、信頼性、そして可用性で今度はAWSアーキテクチャ上で動作するということになります。オンプレミスとクラウド環境の大きな違いはVMwareがVMware Cloud on AWSのインフラストラクチャを管理運用するということです。

Fig002

重要なので、これは完全なマネージドサービスであるということをしっかりとお伝えしておきます。つまり、VMwareがこれを支えるESXi、VSAN、vCenter、そしてNSXのインフラストラクチャをインストール、管理、維持するということです。パッチ適用やハードウェア障害の復旧というような一般的な運用はVMwareがサービス内で実施します。お客様はvCenterのパーミッションなどの権限を受け、管理的なタスクを行うことになりますが、パッチ適用などの特定のアクションについてはVMwareがサービスの一環として提供を行います。これはつまり、VMwareがAWSとのパートナーシップ内でインフラストラクチャのコア部分の面倒を見るということです。

VMware Cloud on AWSはスタンドアローン、ハイブリッドクラウド、そしてクラウド to クラウドの3つの環境で利用が可能です。ハイブリッドとクラウド to クラウドの環境ではvCenterはリンクモードを有効にして構成され、IT運用チームがSDDC環境を集中管理されたコンソールから一元管理できる状態で提供されます。NSXは様々な環境間のネットワークとセキュリティを一貫して俯瞰できるように拡張します。ただし、NSXは要件には含まれません! もしも現在NSXをオンプレミス側で利用していなかったとしてもVMware Cloud on AWSを利用することが出来、その場合にはNSXを利用するハイブリッドクラウドの機能を利用できないというだけです。ネットワークとクラウドにまで渡る機能によって、vMotionでワークロードを様々なクラウドに自在に出入りさせることが出来るようになっています。そう、読み間違えではありませんよ、現在のオンプレミスのvSphere環境からAWSへvMotionすることが出来るのです!

面白いコンセプトとしてイラスティックスケーリング(自在な拡張)があります。イラスティックスケーリングはIT設計者の直面するもっとも難しい課題であるキャパシティプランニングの解決に役立ちます。キャパシティプランニングの重要なポイントは現在と将来のリソース要件、障害復旧キャパシティ、そしてメンテナンスのためのキャパシティです。ワークロードのパフォーマンスと障害復旧のための予約キャパシティのCAPEXとOPEXの低減の適切なバランスを見つけ出すことは難しい問題です。イラスティックスケーリングがvSphereクラスタを俊敏性を備えた発電所へと変えると考えてください。時間のかかる調達を行い、プロセスを自身でインストールする代わりに、拡張性のあるITという考え方とAWSによって提供されるサービスのメリットを受けることが出来るのです。

ESXi4.0以降、vSphere HAはワークロードがクラスタ内の稼働中のホスト上で再起動する事を実現しています。しかし、ホストの不足が一時的なものではない場合、ホストのリソースは利用可能なホスト数の減少によって抑制を受けることになります。ESXiホストが不足している間にもホストのリソースが確保されるような自動修復機構をDRソリューション上に構築することも可能です。ホスト障害が検知された際に、自動修復はクラスタに自動的に別のホストを追加し、ワークロードのパフォーマンスが長期継続するホスト障害からの影響を受けないことを保証します。もしも(ハードウェアの)部分的な障害の場合、自動修復によってその機能不全のホストがクラスタから外れる前にVSANの必要な操作が行われることを保証します。

このフレームワークのもう一つのメリットはメンテナンス時にも同様にリソースを利用するということが出来るということです。メンテナンス運用の最中、クラスタのサイズが減ることはなく、ワークロードはリソースが減ることによる影響を受けずに、通常運用時と同じように動作継続することが出来るのです。

VMware Cloud on AWSサービスの一つの強みは管理者、運用チーム、そして設計者が既存のスキルセットとルールを利用してAWSインフラストラクチャを利用することが出来ることだと考えています。クラウドへワークロード動かす際に、そのクラウド流にプラットフォームを変更する必要も、仮想マシンの変換も、パッケージングの変換も、そして重要なポイントとして、過剰なまでの検証を行うこともなく、単に仮想マシンを移行させればよいのです。もう一つの強みは、AWSが取り揃えている優れた機能セットと現在のワークロードを組み合わせられるという点です。その結果、ITチームは自身のスキルセットを広大なAWSが提供しているサービスのカタログへと拡張していくことが出来るようになります。これによって、オンプレミスのプライベートクラウドと優れたAWSのパブリッククラウドサービスの両方でシームレス動作する環境を作り上げることが出来ます。

もっとご紹介したい素晴らしい機能がたくさんあるのですが、これについてはまた別の記事のために取っておきましょう。

VMworld

もし、今後リリースされるVMware Cloud on AWSサービスをもっと学びたいと思うのであれば、VMworld Europeで、ブレイクアウトセッションINF7849:VMware Cloud on AWS - a closer lookに参加してください。このセッションでAlex Jauchと私はもう少し深くこのサービスの詳細まで潜っていきます。もっと一般的な観点であればINF 7711 VMware Cloud Foundation on Public Cloudsのブレイクアウトセッションへご登録ください。

VMworld Europeでの私のMeet the Expertのスロットも少ないながら有りますので、もしもっとサービスにフォーカスした議論がしたいということであればご登録ください。

もし、ベータへ登録をしたいという場合にはこちらをクリックしてください:http://learn.vmware.com/37941_REG

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

ちょっと本日バタバタしており、タイムリーに翻訳記事を公開できませんでしたが、なんと、Frankのアニキこんなことになっていたのですね! VMwareに戻って活発に活動しているようなのでとても嬉しいです。VMwareがAWS上で動く、まさにFrankさんが言うように「夢の取り合わせ」です。私個人的にはこのところ活動が多角化していたVMwareが本来のソフトウェアカンパニーとしてのイノベーションという原点に回帰したようにも思え、今回の発表はなんだか、心が熱くなります。まだまだ語るべきことがたくさんある!と言う雰囲気ですのでFrankさんの記事はタイムリーに翻訳をかけていきたいと思います。

また、上で紹介されているVMworld Europeですが、今年もネットワールドのメンバーが参加予定になっていますので、また現地からのレポートが届くかも!? 乞うご期待です!