VMwareな日々

VMware環境関連の管理者/導入/トラブルシュートなどに役立ちそうな情報を備忘録として掲載とその他を少々投稿していくブログ

ESXi ホストの電源管理による仮想マシンのパフォーマンス向上

今回は久しぶりにvSphereのお話です。

案外知られていない小ネタとしまして、vSphereでは仮想マシンのパフォーマンスを最大限に発揮をするために、電源ポリシーのセッティングについてベンダーごとに指定があることをご存知でしょうか?

f:id:instructor8010:20180423215533p:plain

最近のx86サーバーやコンピューターはプロセッサによる電力管理機能が搭載されており、それらは主に省エネを目的としています。

しかしながら、仮想マシン上のアプリケーションに対し、最高のパフォーマンスを期待する場合、時にこれらの機能が阻害要因となるケースがあります。

大雑把に言えば、仮想マシンのパフォーマンス向上のために、電力を最大限に利用するポリシー設定にしましょうというものになります。

以下のKBでは、HPとDellサーバーを例に挙げた形で、BIOS画面上でパフォーマンスを最大限に発揮するための設定値の紹介がなされています。

 

Virtual machine application runs slower than expected in ESXi (1018206)

https://kb.vmware.com/s/article/1018206

ESXiでの仮想マシンのアプリケーションが予想よりも遅く実行されます (2032716)

https://kb.vmware.com/s/article/2032716

Configuring Power Management Options in Dell PowerEdge servers specific to VMware vSphere Environment

http://en.community.dell.com/techcenter/b/techcenter/archive/2013/06/04/dell-poweredge-powermanagement-options-in-vmware-esxi-environment

 

勿論この設定自体は、パフォーマンスの最大化のために行うものであり、電力を消費する行為は、電気代を始めとしたコストと引き換えとなりますのでご注意下さい。

Vmware Vsphere 6.5 Host Resources Deep Dive

Vmware Vsphere 6.5 Host Resources Deep Dive

 

L2延伸とは、L2延伸のメリット、必要性に迫る(VMware NSX VXLAN, サイト間接続)

VMware NSXを語る上で、VXLANという機能は”L2延伸”や”拠点間L2接続”などの目的で登場します。(勿論VMware NSXにおけるL2機能の利点はこれだけではありませんが)

 

例えば、VXLANを利用することで拠点間での仮想マシンのvMotionを行う際に、通常であればサイト毎にIPアドレッシングが異なる場合があるが、VXLANを利用することで、サイト間接続時もIPアドレスを変更せずとも、シームレスな移行が可能となります。

 

この様に上記で、拠点間での通信を例に挙げられてもなかなかピンと来ないケースもありますので、段階を追って説明をしたいと思います。

まず、1つ目の例です。

f:id:instructor8010:20180423204744p:plain

ケース1:1つのスイッチに2つの端末が接続された例(同一サブネット)

この例では、Host1と2は相互にPingコマンドによる応答性があると言えます。
結論:同一のIPサブネットは、L2ネットワーク上で構成することが出来る。

 

続いて2つ目のケースです

f:id:instructor8010:20180423205108p:plain

ケース2:1つのスイッチに2つの端末が接続された例(異なるサブネット)

この例では、Host1と2は相互にPingコマンドによる応答性が無いと言えます。
結論:異なるIPサブネットによる疎通環境は、L2ネットワーク上で構成することが出来ない。 

 

3つ目のケースです

f:id:instructor8010:20180423205555p:plain

ケース3:1つのルーターに2つの端末が接続された例(異なるサブネット)

一般的には、ルーターに対して直接エンドデバイスが接続されるケースは少ないかと思いますが、異なるIPサブネット間の通信は、”ルーティング”が実行されることにより実現されます。

結論:異なるIPサブネット上にあるデバイス間での通信には、必ずルーターが必要である。

 

ここまでの話を整理すると次の通りです。

  • 同一のL2スイッチ上に存在するデバイス達は、同じIPサブネットに属している事で通信が相互に可能である。
  • 言い換えれば、各デバイス達を同一のIPサブネットに属するようにするには、同一のL2ネットワークを形成する必要がある。
  • 異なるIPサブネットに属するデバイス間の通信には”ルーター”が必要である。
  • 言い換えれば、ルーターは、複数のIPサブネットに属しているとも言える。

これらの事実は、VMware NSXに関係なく一般的な話であると言える。

 

これらを踏まえると次のような環境はどうだろうか?

f:id:instructor8010:20180423210909p:plain

Quiz:どのようなデバイスが?に入れば、サイト間通信が出来るでしょうか


Site AとSite Bは、異なるサブネットを持っているワケですから、正解は”ルーター”ですよね。

f:id:instructor8010:20180423211152p:plain

異なるIPアドレスを持つ環境同士を繋ぐには、ルーターが必要ですよね!

さて、ここで仮想環境ならではの状況を考えて見ましょう。

"vSphere vMotion"による仮想マシンのサイト間移動が発生したとします。

f:id:instructor8010:20180423211514p:plain

果たして、仮想マシンHost1は、Host 3やHost 4と通信が出来るでしょうか?

これまでの点を踏まえますと、Site B内の状況は、以下の状況が置きていると言えます。

f:id:instructor8010:20180423205108p:plain

再掲:異なるIPサブネットのデバイス同士は、同一スイッチ上で相互通信は出来ません

こうなってしまっては、手動でHost1のIPアドレスを変更してやるか、他のHostのIPアドレスを全て変更するなど手動での作業が余儀なくされます。

 

つまり次のように、マニュアルでのIPアドレス変更によりサイト間以降後のサービス継続性が約束されると言えます。

f:id:instructor8010:20180423211909p:plain

手動でのIPアドレス変更後に、ようやくサービス提供が可能と言えます

しかし、毎回手動でIPアドレスの変更をするというのは、管理工数の増大や作業ミスなど多くのリスクがあると言えます。

実際には有りえませんが、物理サイト間に跨るような巨大なスイッチでもあれば、次のようなことも出来ると言えます。

f:id:instructor8010:20180423212422p:plain

現実には有りえませんが、サイト間に跨るL2スイッチでもあれば...

さて、ということで、巨大なネットワークスイッチというのはどこにも売っていないわけですが、物理的に巨大なスイッチに拘りさえしなければ、現実には次のような手法があると言えます。

本記事では、ここまでの内容の締めとしまして、次の通りです。

1. vSphere vMotionによるサイト間移動後には、サイト間で異なるIPサブネットを利用している場合、仮想マシン移動後に手動でIPアドレスの変更が必要なケースがある

2. もし、L2延伸ネットワークを持った環境で、サイト間の仮想マシン移動を行った場合はIPアドレスの変更なく、シームレスな仮想マシンの移動(場合によってはサイト間フェイルオーバーかもしれない)が出来ると言える

 

vSphereの登場により"vMotion"による仮想マシンの可搬性がメジャーとなり、

vSphere 6.0より”複数のTCP/IPスタック”と”Long Distance vMotion"のサポートに伴い、サイト間移行にもvSphere vMotionが利用出来る今だからこそ、L2延伸がなぜ必要であるか、という点にフォーカスしてみました。

5行で学ぶ!vSphere 6.7

vSphere 6.7がリリースされて数日が経過しましたが、多くの素晴らしい記事が世の中に出ていますね。詳細な説明が成されているものが多いですが、私は逆にシンプルに短く製品について説明をしたいと思います。

f:id:instructor8010:20180421112850p:plain

<所感>

パフォーマンス、メンテナンス、拡張性、安全性の強化がテーマのように感じるアップデートです。(vSphere 6.5との比較)

vSphere HAやvMotionのような有名かつ派手めな機能の拡張や追加ではなく、より速く、より安全、より効率よくというような縁の下の力持ちのような機能が増えたなと思います。(個人の感想です)

 

<vSphere 6.7の特徴>

  • vCenter Server Applianceが軽い(消費リソースがx2, x3の利用効率)
  • vSphere Client HTML5がサポートする機能が増えた(vSAN, NSXなど)
  • ハイブリッド クラウド向けのセキュリティ及び可搬性機能の強化(仮想マシンレベルでのTPMの利用や、暗号化されたvMotionの強化)
  • 不揮発性メモリを利用したパフォーマンスの高速化
  • メンテナンスに伴う再起動回数と時間の削減(Quick Boot/Single Reboot)

なお、本記事以外にも、vSphere 6.7のまとめ記事を掲載しておりますので、そちらも合わせてご覧ください。

instructor8010.hatenablog.jp

 

Vmware Vsphere 6.5 Host Resources Deep Dive

Vmware Vsphere 6.5 Host Resources Deep Dive

 

vSphere 6.7とは (情報まとめ、KB、ダウンロード、リリースノート)

以前より少しずつ情報が出ていましたが、とうとうvSphere 6.7がリリースされましたね!!

 ãvSphere 6.7ãã®ç»åæ¤ç´¢çµæ

これでまたvSphere Install, Configure, Manageコースも恐らく6.5から6.7になるんだなと思うと楽しみで堪りません:)

 

さて、vSphere 6.7に関連する情報まとめを作成致しましたのでご覧ください。

なお、まとめについては更新日時に基づいた時点での最新となることをご容赦下さい。最新情報を確認しかつ不定期での更新を行うことを想定しておりますので、その点をご容赦の上本記事をご利用頂きますことをよろしくお願い致します。

VMware徹底入門  第4版 VMware vSphere 6.0対応

VMware徹底入門 第4版 VMware vSphere 6.0対応

 

vSAN Specialist 2017取得 & vSAN Speciialist 対策のポイント

最近ですが、やっとvSAN Specialist 2017を取得することが出来ました。

ということで、Acclaimよりバッジも無事公開されたため共有致します。

www.youracclaim.com

f:id:instructor8010:20180325202747p:plain

スコアレポート!とうとうやりました!


<受験後の感想>

もっと早く受験しておけばよかった!の一言に尽きました(笑)

というのも、”vSANの基本さえ知っていれば合格は簡単”だからです。

※勿論”簡単”という価値観や”基本”ってどこまでを言うのか、というのは各個人で捉え方の差はあると言えます。

 

私から今後の受験を控える皆様へアドバイスとして次のことを紹介したいと思います。

※本アドバイスは試験合格を約束するものではありません。

※本アドバイスは学習指針をより明確化するためのものです。

※テストの内容については守秘義務があるためお伝えは致しません。

 

<vSAN Specialist 2017受験のためのアドバイス>

  1. ”ディスク グループ”の基本を押さえよ!
    どのような構成が組めるのか?(最小構成/構成の上限について)
    複数のディスク グループを構成する利点は何であるか?
    ディスク グループのデザインの違い毎のメリット/デメリットなどを説明出来るとなお良いと言えるでしょう。
    (例)ホスト内に1つのDGがある場合と2つのDGがある場合の違い)

  2. ”ディスク グループ”内のキャパシティ層とキャッシュ層の基本を押さえよ!
    ハイブリッドvSANとオールフラッシュvSANでは、各レイヤーの動作はどの様に違うか?他者に説明が出来るようにすると良いでしょう。

  3. vSANデータストア キャパシティのサイズ計算スキルを身に着けましょう!
    vSANを構成する際、"ディスク グループ”をベースとし容量をサイジングしますが、例えば自分で”ディスク グループ”を構成してみて、どれくらいの容量がデータ保存領域で利用可能で、キャッシュの容量はどれくらいか?

    次のように、自分である程度の構成を想定し、容量計画を的確に行えるように練習してみると良いでしょう。
    例)3ノードvSANを構成する際、各ホストが2つのディスク グループを保持し、各ディスク グループはキャッシュ用SSD◯◯GBを1本、キャパシティ用HDD◯◯GB3本を保持しています。この場合データ保存に利用可能な容量は◯◯GBである。

  4. ストレージ ポリシーと消費容量の関係性についての基礎を身に着けましょう!
    耐障害性のためのストレージ ポリシーを利用した仮想マシンの場合、vSAN FSから消費される容量に、データ保護のためのオーバーヘッドも加味する必要があります。これに伴う容量計算スキルを持っておくことで、運用に際する容量不足などを防止出来るため、是非身につけていただきたいスキルと言えるでしょう。

    ※オーバーヘッドとは・・・
    例えばRAID1(ミラーリング)に於いて、100GBのデータを
    障害から保護するためには、
    追加で100GBの容量を利用しデータの二重化をする際に発生する”追加分の100GB"を指します。


  5. 障害シナリオと各シナリオごとの障害点や挙動の基礎を身に着けましょう!
    vSANでは”Absent"と”Degraded"と呼ばれる代表的な障害ケースがあります。
    この2つの違い、発生時の動き、発生条件を、vSAN環境管理者は抑えておく必要があります。是非この点をしっかりと抑えておきましょう。
    例えば、3ノードvSAN環境と4ノードvSANでは、同一の障害ケースであっても耐障害性のためのリカバリー動作に違いがあるか等、こうしたスキルも重要だと言えます。

  6. ストレッチ クラスターのアーキテクチャを身に着けましょう!
    一般的な単一データセンター内で完結するvSANクラスターとは異なり、サイトを跨いだ形でのvSAN クラスターが"ストレッチ クラスター”ですが、これを構成する要素や条件を押さえておきましょう。一般的なvSANとストレッチ クラスターでは”Read/WriteのIOのフロー”や”トラフィックの構成要件”などの違いがありますので、これらの違いであったり、この機能のコンセプト(利点、目的)も勿論説明出来る必要があります。

  7. vSAN環境を管理、監視するツールに慣れておきましょう!
    vSphere Web Clientを始め、いくつかのツールを使ってvSAN環境を管理出来ますが、各ツール毎に特徴があります(このツールだと、この情報が参照出来る、など)
    逆に、”vSAN内のキャパシティ内のデータ種別の内訳はどこでみるか?”などみたい情報が閲覧出来るツールはどれか?という視点でそれぞれのツールを見てみるとより理解が深められると言えます。

  8. 他の機能との連携について、どのような機能が存在するか、どのような動きをするかを把握しておきましょう!
    例えばvSphere HA/Oracle RAC/Horizon View/暗号化/iSCSI ターゲットはvSANと併用することでより環境の利便性を向上させてくれます。
    これらを利用することの利点や、各機能を利用する上で前提となる利用条件、機能の仕組みなどについて把握をしておくことで、よりvSANを便利に利用出来るようになると言えます。

以上のようなポイントを確認頂ければvSAN Specialist合格の道が見えてくると言えます。最後になりますが、私が以前に作成した問題集内でも、実際に上記を振り返るために有用な問題もありますので是非チャレンジをしてみて下さい。

instructor8010.hatenablog.jp

非常にありがたい話ですが、上記練習問題を利用頂いた方で、"vSAN Specialistに受かることが出来ました!有難うございます”とお礼も頂けました。

是非皆様のvSANライフのプラスになれば幸いです。

vExpert 2018を頂きました

皆様、お久しぶりです。本年も無事vExpert 2018に選ばれました。

f:id:instructor8010:20180310101338p:plain

まずは私のVMware製品に関する活動を日々支えて頂いている皆様、VMware社の皆様、そして何より本ブログでのアウトプットがこの賞に対するメインの活動とも言えます。

いつも閲覧を頂いている皆様、有難うございます。

 

今年からvExpert用のページが登場したのですが、バッジという機能が加えられています。https://vexpert.vmware.com/

f:id:instructor8010:20180310101735p:plain

こちらが私のvExpertプロファイルです。https://vexpert.vmware.com/directory/1668

 

さて、私のブログについてですが最近ではDailyでの閲覧数も300 オーバーは当たり前、400を超える日も徐々に出てまいりました。口コミを基本に増やしていった割には、とても満足な結果です。

f:id:instructor8010:20180310101121p:plain

昨年の3月末にブログを初めて1年経過を前にこれだけの数字を出すことが出来ました。

instructor8010.hatenablog.jp

 

以下のページに、今回のアナウンスについてとセカンドハーフ(vExpertは年2回の応募が可能)について記載があります。

blogs.vmware.com

 

記事より抜粋ですが、5月または6月当たりにセカンドハーフの申込みが開始のようですね。

We will open the second half 2018 applications around May / June which will only allow for two voting periods this year

 

是非皆さんも奮ってチャレンジをしてみては如何でしょうか?

 

 

VMware NSX 6.3 障害シナリオ:NSX Managerでの障害ケース

VMware NSX Install, Configure, Manageのコース提供が既に複数回決定しており、準備を進めていく中で、見つけた内容の備忘録として、今回は記事を投稿します。

 

VMware NSXは、vSANやvSphereとは違い、複数の仮想アプライアンスとVIBファイルによって動作するネットワークの仮想化製品であることはよく知られていますね。

 

例えばトレーニングなどで、”◯◯の仮想アプライアンスが停止すると、既存インフラにはどのような影響が出ますか?”など聞かれるだろうと想定しています。

※vSphereのコースであれば、”vCenter Serverが停止するとどのような影響がありますか?”とよく聞かれることがあります。

 

そこでVMware ドキュメントを確認した所、次のページを確認出来たのでご紹介致します。本回以降、以下のナレッジをベースに私のコメントも込めながら記事を書き上げていこうと思います。

NSX のルーティング サブシステムの障害の状況と影響

 

ソースは、VMware NSX 6.3(2017/8月)時点のものですね。

f:id:instructor8010:20180216180412p:plain

 

NSX Managerは、全てのNSXの環境構成情報の保持とファイアウォール ポリシーの配布をしている仮想アプライアンスです。

f:id:instructor8010:20180216180539p:plain

NSX Managerの利用不可ケースは、いずれのケースにおいても制御層でのIO自体の停止は引き起こさないと記載がありますね。(元々レイヤーが異なるので想像しやすい結果だと言えます)

また、NSX Managerの接続性が失われる、あるいはそれ自身がダウンしている間は、既存の設定変更は一切出来ません。(これはvCenter Serverがダウンした際に、vCenter Serverに纏わる設定変更が出来ない状況と近いと言えますね)

 

一番下に掲載がある、NSX Manager仮想マシンの破壊シナリオですが、赤枠箇所の日本語がわかりづらいので英文と並列掲載します。

f:id:instructor8010:20180216181146p:plain

要は、NSX Managerが完全にロストされた際はリストアで戻す事を想定していますが、

取得バックアップが著しく古い場合は、取得時と障害発生時点ではコンフィグ情報にギャップが有る可能性があるため、その点は差分を手動で戻して下さい、という事での記載に読めます。

 

以上です。NSX Managerは他のアプライアンスと違い、コンフィグレーションを保持するという点が大変重要となりますので、定期的なバックアップの取得は大変重要ですね。是非こちらのナレッジも合わせてご確認下さい。

VMware NSX for vSphere 6.x コンポーネントのバックアップとリストア (2145635)