*VMware Feed

2017/09/06

HyperFlexのバックアップはVeeamにお任せ!2017

シスコ社のHCIであるHyperFlexのバックアップにはVeeam Backup & Replication(以下、VBR)で間違いないことは、前回お伝えしましたが、最新のVBR 9.5 Update 2では、更に進化し、HyperFlexのネイティブスナップショットとの連携が可能になりました!

VBRの特徴の1つであるストレージスナップショット連携は、これまでもDell EMC/NetApp/Nimble/HPE などのハードウェアストレージには対応しておりましたが、HCIのSDS(Software-Defined-Storage)としては、HyperFlexが初の対応です。

そんなHyperFlexですが、7月末にHyperFlexの最新バージョンである2.5がリリースされました。早速、HyperFlex 2.5(1b)とVBR 9.5 Update2の組み合わせでHyperFlexのネイティブスナップショットとの連携によるバックアップを試してみましたので、ちょっとご紹介しましょう。


まずは、HyperFlexの登録です。VBRの管理コンソールを起動し、[STORAGE INFRASTRUCTURE]で [Add Storage]をクリックします。 
Vbrhx01_3



「CISCO HYPERFLEX」をクリックします。
Vbrhx02_3



HyperFlexの管理用のIPアドレスを入力し、[Next]をクリックします。
Vbrhx03_3



HyperFlexの管理者ユーザー(admin)の認証情報を設定し、[Next]をクリックします。

Vbrhx04



そのまま[Next]をクリックします。

Vbrhx05



サマリーを確認して、[Next]をクリックします。HyperFlexのバージョン情報(2.5.1b-26284)も認識しています。
Vbrhx06



登録処理が実行され、登録が完了します。Vbrhx07_4



バックアップを実行してみたところ、HyperFlex スナップショットの作成と削除のメッセージが表示され、スナップショット連携のバックアップが成功しました。 

Vbrhx09

 

バックアップ中に仮想マシンのスナップショットを確認すると、「SENTINEL」というスナップショットが作成され、その下にVeeamによるテンポラリのスナップショットが作成されています。「SENTINEL」というスナップショットはHyperFlexのネイティブスナップショットを使う際に最初に作成されるスナップショットのため、VeeamからHyperFlexのスナップショットを呼び出していることが分かります。

Vbrhx10a_2


何故、HyperFlexのネイティブスナップショットと連携できると良いのか?HyperFlexとVBRを組み合わせるとどんなリットがあるのか?ピンと来ていない方は、下記のセミナーに参加いただけると、きっとお分かりいただけると思います。東京・名古屋・大阪・福岡で開催しますので、是非ご参加ください!

シスコの爆速堅牢なハイパーコンバージドインフラご紹介セミナー

https://networld.smartseminar.jp/public/seminar/view/814


このセミナーでは最新のHyperFlex 2.5の情報もお伝えします。HyperFlex 2.5では専用の管理ツールのHyperFlex Connectやレプリケーション機能など新機能が盛り沢山ですので、ご期待ください。これからHyperFlexを提案や導入しようとしている方は必見ですが、既にHyperFlexをご利用いただいている方のご参加もお待ちしております。

Vbrhx11_2



最後に、Ciscoと Veeamと言えば、アプライアンスの下記キャンペーンも好評につき、キャンペーン期間を延長しましたので、こちらも併せて宜しくお願い致します。http://www.networld.co.jp/campaign/cisco_veeam_backup/

 担当:臼井

2017/08/31

VMware Cloud on AWS 技術概要

本ブログエントリーはVMware社のR&DでSenior Staff Architectを務めているFrank Denneman氏のブログの翻訳版です。 Frank氏について、詳しくはこちらもご参照ください。

本記事の原文はVMware Cloud on AWS Technical Overviewで閲覧可能です。

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

昨日我々はVMware Cloud on AWSサービスを立ち上げました。VMware Cloud on AWSはVMware vSphere上で動作するプライベート、パブリック、そしてハイブリッドクラウド環境上でのアプリケーションの稼働ををAWSサービスへの最適化されたアクセスと同時に実現します。このCloud SDDCはvSphere、NSXそしてvSANのテクノロジーによって構成され、みなさんが現状でお持ちのスキルセットで管理、運用できるため、非常に馴染み深いものとなります。AWSインフラストラクチャのベアメタルを活用し、このCloud SDDCはこれまでにない方法で拡張することができます。

VMware Cloud on AWSはサービスです。これはサービスに関して言及する際に製品のヴァージョンを利用しないということを意味します。その代わりに我々はこのサービスが最初に利用できるようになったものをファーストリリースと呼ぶことになります。その後の全てのリリースについてはフューチャーリリースと呼ぶことになります。VMware Cloud on AWSはVMwareによって運用されています。これは短く言うとVMwareがインフラストラクチャリソースに責任を負い、お客様はリソースの消費を担当するということです。この記事は最初に利用時のCloud SDDCのリソースキャパシティを探検するものとなります。

VMware Cloud on AWSのコンピューティング

最初の利用時、VMware Cloud on AWSの構成には4台のホストが含まれています。それぞれのホストは512GBのメモリと2つのCPUで構成されています。これらのCPUはカスタムビルドのIntel Xeon Processor E5-2686 v4 CPUです。それぞれのCPUは2.3GHzで動作する18のコアを内包しています。結果として物理クラスタのコア数は144となります。ハイパースレッディングが有効になっているため、仮想マシンは288のロジカルプロセッサを標準のCloud SDDCの構成として利用ができるようになっています。VMware Cloud on AWSは単一の固定のホスト構成で提供されており、ホスト構成へのコンポーネントの追加オプションは現時点では提供されていないことにご注意下さい。ですがスケールアウト型での拡張が最大で16ホストまで利用できるため、結果として576 CPUコア、8TBまでのメモリを利用することが可能です。

vSphere DRSとvSphere HAが有効になっており、最高の可用性とリソース利用効率を提供します。vSphere DRSは完全自動で、移行のしきい値は標準のvSphere DRSのレベルに設定されており、vSphere vMotion操作が過剰に行われないようになっています。クラスタリソースの高可用性がvSphere HAで提供されており、ハードウェアの自動復帰が行われます。

vSphereの高可用性はESXiホスト障害時の仮想マシンの再起動中にもリソースを保証するためにも利用されます。ESXiホストは監視されており、障害イベント時には障害ホスト上の仮想マシンが代替となるクラスタ内のESXiホストで再起動されます。オーバーヘッドを最小化しながら、生産性を最大化するため、クラスタのvSphere HAの設定は1台のESXiホスト分と等しく構成されています(%ベースのアドミッションコントロールポリシーで25%)。ホスト孤立時の対応は仮想マシンの電源を落とし、仮想マシンを再起動するにセットされています。

Vmcaws_fig1

ホスト障害の修復についてはVMwareが担当します。ホストの障害が恒久的なものであれば、VMwareはESXiホストの交換をユーザーを煩わせること無く行います。障害を起こしたハードウェアの自動的な交換は恒久的なホスト障害による長期間に渡るリソースの減少からの影響を削減します。Cloud SDDCは2つのDRSリソースプールで構成されています。一つ目のリソースプールはCloud SDDCを運用するための管理用の仮想マシンが置かれており、もう一つはお客様のワークロードを管理するためのリソースプールのトップレベルのプールです。お客様は子リソースプールを作成することができます。

Vmcrp720p

VMware Cloud on AWSのストレージ

SDDCクラスタはオールフラッシュのvSANを含んでおり、それぞれのホストは合計で仮想マシンが利用するための10TBの物理キャパシティを供給します。標準のCloud SDDCクラスタでは40TBの物理キャパシティを提供します。仮想マシンのキャパシティの消費は構成されているストレージポリシーに依存します。標準ではRAID-1障害許容の手法が適応されます。ですが、お客様はストレージプロファイルを作成し、よりオーバーヘッドの小さなRAID-5やRAID-6という障害許容手法を利用することもできます。RAID-6の障害許容手法を利用する際には最小でCloud SDDCクラスタ内に6ホストが必要となることにご注意下さい。

それぞれのESXiホストは8つのNVMeデバイスを保持しています。これらの8つのデバイスはvSANディスクグループをまたいで分散されています。単一のディスクグループ内では、1台のNVMeデバイスの1.7TBのストレージがWriteキャッシュ層として利用されます。ストレージキャパシティ層には他の3台のNVMeデバイスが利用され、合計すると5.1TBのストレージとなります。

Vmcaws_fig2

ストレージ暗号化

vSAN暗号化によるデータストアレベルの暗号化またはvSphereの仮想マシン暗号化による仮想マシンレベルの暗号化はVMware Cloud on AWSの最初のリリースでは利用できません。データセキュリティについては全てのストレージNVMeデバイスがAWSによってファームウェアレベルで暗号化されています。この暗号キーはAWSによって管理されており、公開されることも、VMwareやVMware Cloud on AWSのお客様が制御することもありません。

Cloud SDDCの構成

最初のリリースではCloud SDDCはAWSの単一のリージョンと可用性ゾーン(AZ)に限定されています。ハードウェア障害は自動的に検出され、自動修復によって、障害ホストは他のESXiホストへと入れ替えられます。もしも必要な場合にはvSANデータストアがユーザーを煩わせること無く自動的にリビルドを行います。

将来のVMware Cloud on AWSのリリースではVMwareとAWSのパートナーシップを通じてマルチ-AZでの可用性が2つの同一リージョン内の2つのAZをまたいでクラスタをストレッチすることで初めて実現される可能性があります。このまたとない機能によって、従来からのアプリケーションをAWSインフラストラクチャ上で高可用性を得るためにリファクタリングする必要はなくなります。その代わり、同期WriteレプリケーションがAZをまたいで活用されることになり、復元目標点(RPO - recovery point object)はゼロとなり、復元目標時間(RTO - recovery time object)はvSphere HAの再起動時間次第となります。

Spanningaz

VMware Cloud on AWSのネットワーク

VMware Cloud on AWSはNSXを中心として構成されています。このネットワークはCloud SDDC内の仮想マシンのネットワークの提供に最適化されている一方で、Amazon 仮想プライベートクラウド(VPC)ネットワークを抽象化しています。仮想マシンへの論理ネットワークの提供とクラスタスケールアウト時の新しいホストと論理ネットワークVMKernelネットワークとの自動的な接続によって簡単な管理を実現します。最初のリリースではユーザーはVMware Cloud on AWSにレイヤ3のVPN接続で接続します。しかし、将来のリリースのVMware Cloud on AWSではAWSのダイレクト接続とクロスクラウドのvSphere vMotion操作ができるようになります。

オンプレミスのvCenterサーバインスタンスとCloud SDDC内のクラスタ上で動作している管理コンポーネントとの接続にはIPsecのレイヤ3VPNがセットアップされます。またもう一つのIPsec レイヤ3 VPNが作成され、オンプレミスのワークロードとCloud SDDCのクラスタ内で動作している仮想マシンとの接続に利用されます。NSXは全てのネットワークとセキュリティに於いて利用され、Amazon VPCのネットワークから分離されています。コンピュートゲートウェイとDLRは暗黙的なネットワークトポロジの一部として事前に構成されており、お客様が変更することはできません。お客様はご自身のサブネットとIPの範囲を提供するだけです。

Vmcaws_fig4

VMware Cloud on AWSは皆様のワークロードに対応

VMware Cloud on AWSは皆様の現在のスキルセットとツールセットを使いながら利用できるクラウドのリソースを提供します。それぞれのCloud SDDCは今日最も要件の高いアプリケーションを動作できるだけの十分なリソースをご提供します。世界最高のエンタープライズソフトウェアが世界最高のクラウド事業者と融合し、これまでにない方法でデータセンタを稼働、拡張することを実現するのです。

更に詳しくは こちらへ https://cloud.vmware.com/vmc-aws/resources

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

Screenshot20141105at0820381

業界はVMworldで盛り上がっていますね。ちょっと時間がうまく取れなかったのでもっとタイムリーに翻訳記事を公開したかったのですが、少し遅れてのリリースです。これまではあまり語られてこなかった、VMware Cloud on AWSを契約するとどうしたリソースが利用できるのか?今回はこれが明らかになりました。すごいスペック・・・。2TB、288スレッドのクラスタ・・・以上に私がびっくりしたのはNVMeを8本も搭載し、うち2本=3.4TBもをWriteキャッシュに振り当てるという豪華っぷり!

NSXでAmazon VPCのネットワークをきれいに隠してしまうのもVMwareユーザーにはうれしいですね。マルチAZでのストレッチにもチャレンジしていくとのこと、ワクワクします。日本に来るのが待ち遠しいですね!

追記 : お値段は?という方がおられましたので、こちらです。米国の価格なのでそのまま日本に来るとは限りませんが、ご参考まで。 https://cloud.vmware.com/vmc-aws/pricing

2017/08/02

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

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

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

Release Notes for Veeam Backup & Replication 9.5 Update 2

 Platform support
   -VMware vSAN 6.6 support.

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


■検証構成

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

 Config1_3

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

Vsan1_3

■バックアップ

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

Vsan3_2

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

Vsan4_2

■リストア

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

Vsan5_2

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

Vsan6_2

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

Vsan7

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

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

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


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

■参考

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

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

Configuration for VMare VSAN

 担当 臼井

2017/07/31

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Vmcresizecluster

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

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

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

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

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

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

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

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

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

2017/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操作でできるようになり使いやすくなったので、胸を張って紹介できます!

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

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さん、いつもありがとう!