Home > Blogs > Japan Cloud Infrastructure Blog

VMware vSphere 6.0 の新機能 vMotion編

こんにちは、パートナーSEの川﨑です。今回は VMware vSphere 6.0 のリリースに伴う、VMware vSphere vMotion の機能アップデートについてご紹介いたします。vMotion の機能拡張は今回のアップグレードの目玉の一つとなっておりますので、ぜひご注目ください。

 

■クロス vCenter vMotion( vCenter Server システム間のvMotion )

クロス vCenter vMotion とは、異なる vCenter Server の配下にある ESXi ホスト間で vMotion を可能にする機能です。これまで、vSphere 5.5 まででは、vMotion は同一の vCenter 下でしか行うことができませんでした。今後は、図1のイメージのように、異なるvCenter に所属するホストやクラスタを移行先として vMotion で移行することが可能です。(図1では、”CentOS2” という仮想マシンを ”172.16.119.132” の vCenter 下の ”Cluster2” というクラスタから、”172.16.119.131” の vCenter 下の ”VSAN” というクラスタへの移行を示しています。)

図1.クロスvCenter vMotion での移行イメージ
図1.クロスvCenter vMotion での移行イメージ

クロス vCenter vMotion の実施方法は通常の vMotion となんら変わらず、図2のように仮想マシンを選択して、アクションとして”移行”を選択し、”計算リソースのみ変更します”または”計算リソースとストレージの両方を変更します”を選択してウィザードを進めることで、通常の vMotion 同様に移行を行うことが可能です。

なお、異なる vCenter 間での移行時の要件については弊社ドキュメントの下記ページをご参照ください。

http://pubs.vmware.com/vsphere-60/index.jsp?topic=%2Fcom.vmware.vsphere.vcenterhost.doc%2FGUID-897E10D6-A413-4699-B3C6-498AA80CB9ED.html

 

図2.クロスvCenter vMotion の実施方法

図2.クロスvCenter vMotion の実施方法

クロス vCenter vMotion が可能となったことで、これまで vCenter の管理範囲ごとに区切られていた仮想基盤が vCenter の縛りを超えて一つの共通プラットフォームとして扱えるようになります。データセンターごとに vCenter を分けていたケースなどでは、今回初めて vMotion での移行が可能になり、嬉しい機能拡張ではないでしょうか。

vCenter Server を超えた際に気になる点の一つとして、仮想マシンに関する様々な情報は引き継がれるのか、といった点があります。実際には多くの情報は引き継がれ、仮想マシンの MAC アドレスや、タスクの履歴、シェアや予約値といったリソース設定、HA・DRS の設定等は引き継がれますが、パフォーマンスデータは引き継がれない仕様となっております。詳細は補足として、記事の最後に記載いたします。

■長距離 vMotion 移行

長距離 vMotion 移行は、長距離に離れたデータセンター間など、遅延が大きい環境間での vMotion を可能にします。通常の vMotion で許容される RTT (=round trip time) は 5ms ですが、これが Long Distance vMotion では 150ms まで許容されます。これにより、アメリカであれば大陸の東西、日本であればシンガポールまでの距離であっても、vMotion で仮想マシンを移動させることができます。 (*レイテンシは実際に利用する回線の品質にも依存します。上記はあくまで一例とお考え下さい。)

http://kb.vmware.com/kb/2106949

 

図3.長距離vMotion移行の実施イメージ

図3.長距離vMotion移行の実施イメージ

■vMotion ネットワーキング

vMotion のネットワーク周りについてもアップデートがあります。一つは、TCP/IP スタックが複数構成できるようになったことにより、vMotion についても専用のTCP/IP スタックが構成可能となりました。VMKernel アダプタの作成時に、TCP/IP スタックとして ”vMotion” を選択することで設定することができます。(図4)

 

図4.vMotion専用TCP/IPスタックの設定

図4.vMotion専用TCP/IPスタックの設定

TCP/IP スタックが vMotion 専用で構成できるようになったことに伴い、vMotion 用ネットワークが異なる L2 セグメントに跨る場合にも柔軟に構成できるようになりました。従来は vMotion 用トラフィックが有効化された VMKernel アダプタ も管理ネットワークと同一の TCP/IP スタックを利用しましたが、vSphere 6.0 では個別にデフォルトゲートウェイやルーティングテーブルの構成を持つことが可能です。なお、仮想マシンの接続されるネットワークについては同一のL2ネットワークセグメントへの接続が必要です。(図5では青線が vMotion 用ネットワーク、緑線が仮想マシン用ネットワークを示しています)

図5.vMotionネットワークの構成例

図5.vMotion ネットワークの構成例

次に、クロス vSwitch vMotion について触れます。vSphere 5.5 まででは、vMotion 時には接続前後で接続する標準仮想スイッチ(vSS)、または分散仮想スイッチ (vDS) の仮想マシンポートグループを選択することはできず、移行前後で同じ仮想マシンポートグループ(vSS の場合は同じラベルのポートグループ)に接続する必要がありました。vSphere 6.0 では、移行後に接続する仮想マシンポートグループの選択が可能となり、例えば vSS の仮想マシンポートグループに接続されていた仮想マシンを vDS の仮想マシンポートグループに接続することも可能となりました。ただし、vDS から vSS への移行は選択できない点と、移行前後で IP アドレスの変更はされないため、仮想マシンのネットワーク接続確保のためには同一の L2 ネットワークに接続し続けることが必要な点には注意が必要です。

 

図6.vMotion移行ウィザード中でのネットワーク選択

図6.vMotion 移行ウィザード中でのネットワーク選択

■補足:クロス vCenter vMotion で引き継がれる情報、引き継がれない情報について

下記で、クロス vCenter vMotion での移行前後で、引き継がれる情報と引き継がれない情報を整理いたします。内容については、一部検証結果に基づく情報であることをご承知ください。

①UUID

uuid.bios と vc.uuid は保持され、uuid.location は変更されます。これらは vmx ファイルを参照することで確認可能です。

x-vc_uuid

②MACアドレス

MACアドレスの変更はありません。また、移行元の vCenter Server では、 MAC アドレスをブラックリストに追加して、新しく作成された仮想マシンにその MAC アドレスが割り当てられないようにします。

x-vc_mac

 

③HA/DRS ルール

基本的には下記ルールはクロス vCenter vMotion 後も保持されます。

  • アフィニティルール
  • VM ごとのオーバーライドルール
    • 自動化レベル
    • 起動優先順位
    • ホスト分離時の対応

x-vc_affinity_ok1x-vc_affinity_ok2

ただし、下記の場合は例外的に保持されないことが社内の検証で確認されています。(判定は VM ごとに行われます)

  • アフィニティルール
    • VM ごとのオーバーライドルールが設定されている場合
      x-vc_affinity
  • VM ごとのオーバーライドルール
    • 移行先のクラスタの設定と同じ設定がされている場合
      x-vc_override

*アフィニティルールは VM 間で設定している場合、適用には双方の VM でルールが保持される必要があります

 

④リソース設定

仮想マシンに対する CPU、メモリリソースのシェア、予約、制限値は保持されます。

x-vc_resource

 

⑤タスクデータ

タスクデータは引き継がれます。

x-vc_task

 

⑥パフォーマンスデータ

パフォーマンスデータは移行の前後で引き継がれません。

x-vc_performance

 

⑦vRealize Operations Manager 上のデータ

vRealize Operations Manager 上のパフォーマンスデータは移行前後で引き継がれません。

x-vc_vROps

 

■終わりに

vSphere の基本的な機能の一つである vMotion ですが、vSphere 6.0 では更なる機能拡張がなされました。上記のアップデートを踏まえて、更に vMotion を使いこなしていただけたらと思います。最後までお読みいただきありがとうございます。

VMware vSphere Virtual Volumes (VVols) のご紹介

はじめに

VMware vSphere Virtual Volumes は、VMware vSphere 6.0 に初めて搭載されたストレージの機能です。VMware が十数年に渡り提供してきた Hypervisorである、ESX / ESXi はブロックストレージとして、LUN + VMFS の仕組みを踏襲してきました。VVols はこの枠組みを超える革新的な機能で、vSphere ユーザーに多くのメリットを提供します。今回は、この魅力溢れる新機能についてご紹介いたします。
なお、"Virtual Volumes" や "VVols" という言葉ですが、仕組み全体を指す場合と、仮想マシンのオブジェクトを指す場合、またボリュームをマウントする際のデータストアとしての3通りの意味があります。混乱を避けるため、本Blogでは以下のように使い分けたいと思います。(一般的な使い分けではありませんのでご了承下さい)

  • 全体的な仕組みとしての VVols・・・Virtual Volumes
  • オブジェクトとしての VVols・・・ VVols もしくは VVol(特定の単一オブジェクトを指す場合)
  • データストアとしての VVols・・・VVol データストア

Virtual Volumes 登場の背景

ESX / ESXiが長らく踏襲してきた LUN + VMFS という形、とりわけ、VMFS は軽く高機能なクラスタファイルシステムで、バージョンアップと共に、SCSI Reservation の最適化や取り扱える最大ファイルサイズの拡張、VAAIで代表される各種オフロードなど、より大規模環境をハイパフォーマンスでストレス無く扱えるようその機能を拡張してきました。しかしながら、様々な Tier (パフォーマンス要件や可用性要件) を持つシステムが仮想環境に混在するようになると、あらかじめパフォーマンス、可用性、必要容量などを想定して切り出す必要のある LUN という概念では時として柔軟な対応が出来ず、例えば、データストアに空き容量はあるけど要件にあわない・・・、など無駄が生じたり、必要な機能を持つ LUN を新規に切り出すために時間を要したりなど、仮想環境の利点である迅速性を阻害するリスク要因の1つにもなってきました。

また、様々な Tier をサポートするために、同一ホストへの(NFSとFCなどの)異なるストレージ装置や、異なるRAIDレベル、異なるディスクデバイス(SSD、FC、NL-SAS等)が混在して接続されるケースも多くなり、管理者がそのストレージ特性を理解して仮想マシンを最適に配置しなければならない、という管理負荷の面での問題点も顕在化する可能性がありました。


この問題に対処するため、Virtual Volumes では、あらかじめ予測と準備が必要な LUN という仕組みを廃止し、各仮想マシンディスクを1個のVVolオブジェクトとしてストレージが直接管理する仕組みを提供します。このVirtual Volumes の管理側のメリットは大きく、例えば以下のようなことが可能となります。

  • ストレージ側で、あらかじめ容量や可用性などを定義したLUNを作成する必要はない
  • 仮想マシン作成時に必要な容量、可用性を担保したVVolsがダイナミックに切り出される
  • 仮想マシンに必要なストレージの機能が、vSphere側からポリシーとして定義可能
  • 豊富なストレージ機能を直接仮想マシンディスク(VVols)に作用させることが可能
  • ストレージの機能を利用した、仮想マシンディスク毎のバックアップリストアが可能

Virtual Volumes 全体像

Virtual Volumes はいくつかのコンポーネントが連携して動作します。全体像は以下の通りです。


  • VASA プロバイダ
    • ストレージベンダー提供のコンポーネント
    • VVols の作成や複製、削除に関わるコントロールプレーンの機能を提供
      仮想マシンの作成、電源オン、スナップショット作成などの操作の際、必要な VVols を作成する
    • ストレージに実装された機能をvSphere側から把握するためのアクセスポイント
      一つの VASA プロバイダーから複数アレイ管理も可能
    • 実装方法はベンダー依存
      専用管理サーバー(仮想アプライアンス)
      ストレージ Firmware
    • ESXi と vCenter Server は VASA プロバイダーと接続
  • プロトコルエンドポイント
    • ストレージ管理者が定義する、ESXi からのI/O アクセスポイント
      ラウンドロビンやMRU 等のパスポリシーもプロトコルエンドポイントに対して設定される
    • 容量提供を目的としない管理 LUN / NFS 共有の位置づけ
      実容量を持つ、各仮想マシンの VVols は、プロトコルエンドポイントの後ろに存在するサブLUNとして存在
    • 各LUNに対してI/Oパスが定義される従来の方法に比べ、アクセスポイント数を大きく削減
    • SAN と NAS のすべてのプロトコルと互換性

      iSCSI、NFS v3、FC、FCoE

  • ストレージコンテナ
    • ストレージ管理者が定義する、VVols を収容する論理的プール
    • プロトコルエンドポイントの背後で容量を定義
    • 定義や最大コンテナ数はストレージ装置に依存
    • vSphere 管理面からはデータストアの概念

上記の他、データサービスとしてストレージの機能を定義する領域があります。定義された機能は VASA プロバイダ経由で vCenter Server へ通知され、仮想マシン作成の際利用されます。

既存の LUN + VMFS と、Virtual Volumes におけるコンポーネントの実装の比較は以下の通りです。I/O アクセスや容量、サービスレベルを画一的に定義していた LUN を、それぞれプロトコルエンドポイント、ストレージコンテナ、ストレージポリシーに分解、定義していることが分かります。また、繰り返しになりますが、LUN は事前に作成され、複数の仮想マシンを収容しますが、Virtual Volumes では、仮想マシン作成の際に VVols が直接ストレージに作成され、オブジェクトの粒度も仮想マシンディスクそのものとなります。


Virtual Volumes セットアップ

Virtual Volumesは、ストレージと連携した機能です。このため、Virtual Volumes 利用には対応したストレージが必要となります。Virtual Volumes をサポートするストレージに関しては、こちらをご確認下さい。また、Virtual Volumes が利用可能な vSphere の License に関しては、こちらからご確認いただけますが、Standard 以上となっています。
セットアップの際も、まずはプロトコルエンドポイントや VASA プロバイダ、ストレージコンテナ等をストレージ装置側で設定しておく必要があります。セットアップ方法はストレージ装置毎に様々で、例えば VASA プロバイダが、ストレージコントローラに内蔵されていて、サービスを起動させるのみという簡単セットアップというストレージ装置もあれば、仮想アプライアンスをデプロイしてセットアップを完了させるストレージ装置もあります。ストレージコンテナも、装置丸ごと1つ見せることを基本とするストレージ装置もありますし、最初から細かくストレージコンテナを定義できる物もあります。これらの設定方法に関しては、各ストレージベンダーのマニュアルをご確認下さい。

ストレージ装置側で、上記コンポーネントの定義や、ストレージ装置へのESXiホストの登録などが完了すれば、そこから先は vSphere 側からセットアップを進めることが出来ます。

 

1. VASAプロバイダをvCenter Serverに登録します。

VASAプロバイダの登録自体は非常に簡単です。登録も各ストレージ装置毎に方法が異なりますが、HP社の3PAR StoreServ (以下3PAR)におけるVASAプロバイダ登録画面は以下の通りです。


2. プロトコルエンドポイントの認識

通常の HBA のリスキャンを実行することにより、ESXi ホストにプロトコルエンドポイントが見えてきます。


こちらもストレージ装置により様々ですが、ブロックデバイスでは、プロトコルエンドポイント用に非常に小さな LUN が1つ見えます。3PAR の場合はLUN番号が 256 で、512 Byte の小さなLUNとなっています。


ラウンドロビンや MRU 等のパスポリシーもプロトコルエンドポイントに対して設定されていることが分かります。プロトコルエンドポイントがホストから見えると、自動的にその裏側にあるストレージコンテナもホストから見える様になり、データストアとしてマウントすることが可能となります。


 

3. VVol データストアのマウント

ストレージ装置で作成されたストレージコンテナをVVol データストアとしてESXi ホストにマウントすると仮想マシンの作成が可能となります。仮想マシン作成の際、指定を行うストレージポリシーに関するご説明はこちらをご確認下さい。なお、定義可能なストレージポリシーはストレージ装置により異なります。


VVols オブジェクトの種類と仮想マシン作成時の動作

仮想マシンを作成すると、仮想マシンオブジェクトとして複数の VVol が作成されますが、この VVol にはいくつかの種類があります。この種類と実際のVVol 作成の動作についてご説明します。まず種類ですが、以下の5種に分類されます。

  1. Config-VVol・・・仮想マシン構成(vmx ファイル)、ログ
  2. Data-VVol・・・VMDK やスナップショット
  3. Swap-VVol・・・Swap ファイル(仮想マシン起動時のメモリスワップ領域)
  4. Mem-VVol・・・メモリー付きスナップショット取得時やサスペンド等、仮想マシンのメモリデータ
  5. Other-VVol・・・その他ソリューション用途


仮想マシンを作成すると、仮想マシン基本VVolである、1. Config-VVol と、2. Data-VVol が作成されます。次に仮想マシンの電源を On すると、3. Swap-VVol が作成されます。上記キャプチャは、仮想マシン作成の後、PowerOn し、さらに、仮想マシンのメモリ付きスナップショットを取得したときに作成される5個の VVol を示しています。この様に、1つの仮想マシンに対して複数の VVol が作成されますが、データストアブラウザで見ると通常の VMFS ボリュームに作成された仮想マシン同様、1つの仮想マシンのパスの中に各データが保存されているように見えます。つまり、仮想環境の管理者が直接 VVols オブジェクトを意識する必要はありません。


VVols のバインド

直接管理者の目に触れる部分ではありませんが、プロトコルエンドポイント背後に存在する、各 VVols が ESXi ホストからアクセス可能となる仕組みをご説明します。仮想マシンの作成やパワーオン操作に伴い際に作成された VVols はプロトコルエンドポイントのサブ LUN として定義され、バインドという処理を介して ESXi からアクセス可能となります。簡単に申し上げると、バインドはアクセスを必要とする ESXi に対しストレージ装置が作成した VVols オブジェクトを見せてあげる処理、ということになります。具体的には以下の通りです。

  1. ESXi が VASA プロバイダ経由でバインド処理を発行
  2. ストレージ装置はプロトコルエンドポイント ID と実際の I/O 発行先であるサブ LUN ID (VVols オブジェクト ID )を応答*
    *NFSの場合は、ファイルパスとなります
  3. ホストよりアクセス可能(1:1のマッピングにより排他処理)となります


この処理の実行により、ESXi ホストは対象 VVols に対して I/O の実行が可能となります。

Virtual Volumes のメリット

Virtual Volumes のメリットは以下の通りです。

  • 豊富なストレージ機能を直接仮想マシンディスク(VVol)に作用させることが可能
    スナップショット、クローン、フラッシュキャッシュ、重複排除、暗号化、リモートレプリケーション...etc
  • 仮想ディスク毎に必要なストレージの機能を、vSphere 側からポリシーとして定義可能
  • アクセスポイントをプロトコルエンドポイントに集約することにより、最大 LUN 数の問題を回避

    多数の RDM を運用されているユーザには大きなメリットとなります

例えば、vSphere Web Client 上から仮想マシンのスナップショットを取得すると、VMFS 上の仮想マシンであれば、VMFS がサポートする Redo log ベースのスナップショットとなりますが、Virtual Volumes の場合は、同一のオペレーションでストレージベースのスナップショットとなります。特に I/O 要件の高い仮想マシンのバックアップに、VADP + VMFS ベースのスナップショットを利用している場合にはこのメリットは極めて大きく、スナップショット作成時、削除時にほとんどパフォーマンスの劣化の無い安定したバックアップの取得が可能となります。*

 *ストレージがサポートするスナップショットの機能に依存します。

まとめ

リリースされたばかりで対応ストレージがまだ少ない点、ポリシーで定義可能な項目が本来のパフォーマンスや可用性を伴っていない点など、現状では課題も垣間見えるのですが、Virtual Volumes は非常に将来性豊かなストレージの新機能です。また、vSphere の Standard License から利用可能というところも見逃せない点です。今後の機能拡張にもご期待下さい!

Hiroshi Okano

岡野 浩史

リードシステムズエンジニア (VCP3/4/5-DCV, VCP-NV, VCAP4/5-DCA, VCAP4/5-DCD)
エコシステム含めたパートナービジネスの拡大をミッションとしているエンジニアです。前職ではx86ベンダーやCPUベンダーといったハードウェアエンジニア畑を歩んできましたので、デバイスレベルの動きやHPC等のベンチマーク等に深い知識を持ちます。PartnerExchange や vForum などのイベントでは、リリース前の vSphere Core の機能紹介や Virtual SAN のセッションを担当する機会も多いので、”どこかで見たことのある顔”と思われる方もいらっしゃるのではないかと思います。今後もこの様な活動を続けていく予定です。よろしくお願いします!

これだけは押さえておきたい!マルチクラウド運用管理

みなさん、こんにちは。

VMware vRealize Operations Manager (vR Ops)の主な得意分野は、仮想基盤のキャパシティ管理や健全性管理ですが、他社の運用管理製品と連携することによって、vR Ops単体では不十分な機能を相互に補完し合う事が可能です。

今回は株式日立製作所の運用管理製品「JP1」、およびストレージ管理製品と連携してクラウド基盤全体、およびその上で動くサービスや業務を安定的に運用する方法について、株式会社日立製作所の坂川博昭様と同 長江亮介様にご紹介していただきます。それでは坂川様、長江様よろしくお願い致します。

 

hitachi_apr2015_sakagawa_banner

こんにちは。株式会社日立製作所 ITプラットフォーム事業本部 JP1ビジネス推進センタの坂川(さかがわ)(以下、坂川)です。私は、JP1のモニタリング製品を中心に拡販活動をしています。今回は、最近よく話題になっているクラウド環境についてお話をさせて頂きます。特に、さまざまなクラウド環境でも、一つにまとめて管理できる統合運用管理製品JP1のご紹介をしたいと思います。

hitachi_apr2015_nagae_banner

皆さん、こんにちは。同じく日立製作所 プロダクトビジネス推進部の長江(ながえ)です(以下、長江)。僕は、プラットフォーム製品、サーバ・ストレージ含めた装置周りの運用管理ソフトウェアの拡販に従事しています。これまでは特にストレージ運用管理を担当していましたので、その観点で最近のマルチクラウド環境のストレージ運用まわりの課題への新しい解決案をご説明したいと思います。

専用ツールがネックになる?マルチクラウド運用管理の落とし穴

hitachi_apr2015_sakagawa_icon (坂川)最近クラウドって言葉がはやっていますけど、さまざまな会社がクラウドサービスを提供しています。それぞれのクラウドを管理する時には、それぞれ専用ツールを使って管理をするのが一般的です。それだと、それぞれのツールの使い方を覚えないといけないですし、UIも異なるので、管理者には負担が大きいという問題があります。

日立の統合運用管理製品JP1を使いますと、複数のクラウド管理が、一つの製品でまとめて管理できるというメリットがあります。運用コストも低減できますし、管理者も運用が楽になるというメリットがあります。

hitachi_apr2015_nagae_icon

(長江)確かにそういう負担はありますよね。それぞれのクラウド環境で用意されたツールを使わないといけないですし、使いやすさの面で、ネックになることが多いですよね。ですから、そこを統合的に管理できるツールがあれば、ぐっと楽になりますよね。

 

hitachi_apr2015_sakagawa_icon(坂川)そうですね。JP1を使いますと、マルチクラウド環境の一元管理ができます。構成情報に関しては、JP1/Integrated Management(以下JP1/IM)でさまざまなクラウド環境の構成情報を取得することができます。

hitachi_apr2015_jp1-vrops_rev2

稼働監視については、JP1/Performance Management(JP1/PFM)を使うと、さまざまなクラウド基盤が混在していても情報を一つの画面で確認することができます。今どうなっているのか、リソースの使用状況はどうなのかを俯瞰することができます。

クラウド上で稼働している業務については、ジョブ管理製品であるJP1/Automatic Job Management System 3(JP1/AJS3)を使うことによって、クラウド上での業務を自動化できます。

クラウド種別を問わずに、監視や業務で発生するイベントをJP1コンソール画面で一元管理をすることができます。この画面では、マルチクラウド環境で発生するイベント、それから監視で発生するイベント、業務で発生するイベントを「統合監視」できます。

hitachi_apr2015_nagae_icon

(長江)最近はお客さまがクラウド管理をされることが多いですし、例えば、従来ではストレージは管理していなかったのに、今はサーバ・ストレージを含めた全体的な管理の必要にせまられているお客さまが増えてきています。クラウドの実績が豊富なVMwareとストレージ間での課題もありますよね。

 

hitachi_apr2015_sakagawa_icon

(坂川)そうですね。他にも、クラウドを利用していて動作が重くなった時に、どこに問題があるのかを分析するのも結構大変になってくるのかなと。そういう時に、ツールを使って仮想のリソースが足りないのか、それともサーバなどのハードウェアのリソースが足りないのか、もしくはストレージに何かボトルネックがあるのかとか、そういう分析をする作業もすごく大変ですよね。

VMware社の管理ソフトであるvRealize Operations Manager(以下vR Ops)を使うと、どこに問題があるのかをヒートマップで表示してくれて、「ストレージのどこどこの箇所でI/Oネックが発生している」といった事象がわかる仕掛けになっています。このvR OpsとJP1を連携させると、管理者にとってさらにやさしい運用ができるようになります。例えば「リソースが足りなくなっているよ」というイベントをJP1で検知して、じゃあその問題はどこにあるのかをvROpsで分析するといった感じですね。

ストレージの観点でも、いろいろと課題はありますよね?

hitachi_apr2015_nagae_icon

(長江)そうですね。VMware製品を使われている方は、管理対象をVM単位とすることが多いと思いますが、やはり従来のストレージだと、LUN(Logical Unit Number、ストレージの論理ユニットを識別するための番号)単位、ボリューム単位の管理になってしまうので、ストレージとサーバで管理したい粒度が異なったりと、課題はありますね。

例えば、従来の環境だと「VMがなんだか遅いなあ」という時に、まずはVMを構成しているデータストアを調べて、そのデータストアがどこのストレージにつながっているかを調べて、そのデータストア上に乗っているVMのどれが影響を与えているかを調べなきゃいけなかったので、非常に大変でした。

それに、LUNの上に載っているVMが複数あれば、どのVMに原因があるかの特定も難しいですし。やはり、ストレージはLUN単位、サーバはVM単位で管理しているところに、管理対象のギャップがあり実運用上で課題となりますね。

hitachi_apr2015_sakagawa_icon

(坂川)仮想基盤のVMware製品の部分は、vR Opsと連携することによって、検知したイベントも一元管理ができるようになります。これにより、vR Opsでとらえたストレージまわりの異常や、仮想環境で発生するイベントも合わせて見られるようになります。

vR OpsとJP1/Base間の連携に関してはクラウド連携設計支援のための商品をご用意していますので、それを組み込むことによって、シームレスにイベントが通知されるようになります。

hitachi_apr2015_nagae_icon

(長江)さきほどもお話しましたが、ストレージで管理したい単位と、サーバで管理したい単位とでギャップがあるので、そこが運用管理のネックとなっています。

具体的にいうと、一つのLUNに、複数のVMがくくりついています。これがどういう問題を生むかと言うと、例えばLUNでバックアップを取って、一つのVMだけを戻したいとします。でも、LUNの単位でのバックアップなので、すべてのVMが昔の状態に戻ってしまいます。そこで、これまではサーバ側から、スナップショットやクローンを作って対処していました。

それを変えてしまうのが、2015年3月にリリースされたVMware vSphere 6 のVirtual Volumes(以下VVOL)です。VVOLを使うことで、これまでサーバ側でやっていたスナップショットやクローン処理を、ストレージにオフロードできますので、性能が早くなるとか、管理の単位が楽になるという大きなメリットがあります。

そして、VMが遅くなった時でも、どこで遅くなっているのかが特定できますので、分析の精度が向上し、管理者の負担も減るというメリットがあります。将来的にはVVOLの情報もvROpsに表示されるようになり、ユーザの使い勝手がよくなればよいな、と思っています。

また、これまでは、こういう管理をしたい場合はVMとLUNを1対1で構築するケースもありました。その場合だと数が増えてしまって管理が大変だったり、1つのサーバに割り当てられるLUNの数にも制限がありました。

こういった問題にも、VVOLを使いますと、プロトコルエンドポイント(サーバとストレージ間のアクセスポイント、以下PE)と呼ばれるLUNをサーバに割り当てて、それ以外のLUNはすべてPE経由でアクセスすることで数の制限もなくなりました。

今までは、ストレージの管理者がLUNの割り当てまでを担当していたのですが、サーバの管理者がLUNを割り当てたり、スナップショットを操作したりすることができるようになりますので、ストレージ管理者とサーバ管理者のやりとりも減りますし、VMが必要になった時に、すぐに構築できるので機敏性が増しますね。

こういったVVOLに対して、日立ではHitachi Command Suite(以下、HCS)を使って、VVOLを使うために必要なストレージの設定や、ストレージコンテナの作成、ケーパビリティ(Capability、ストレージを管理するためのパラメータやルールのセット)を作ったり、VM単位の性能分析を実行したりと、運用管理を楽にする工夫をしています。

実際にはこのような画面で管理します。

hitachi_apr2015_storagecontainer

※開発中の画面のため予告なく変更となる場合があります。

詳しくは、2015年5月14日にセミナーを開催予定ですので、そちらでご紹介します。(セミナーの詳細はページ下部をご覧ください。)

日立が目指す運用管理

hitachi_apr2015_nagae_icon (長江)長々とお話してしまいましたが、最後に一つだけ。

VVOLにおけるストレージ側の実装については、ストレージベンダの依存になるところが大きいので、そこでいろいろな独自性を出していけるのかなと思っています。ですから、日立ではより使いやすくなるようにエンハンスを行っていく予定です。マルチクラウド運用に対して、ユーザは使い勝手を意識しなくても、楽に使えるようなものを順次提供していけたらなと。

hitachi_apr2015_sakagawa_icon

(坂川)そうですね。JP1もそうです。JP1はおかげさまで20周年を迎えることができました。今後も皆様のご要望を受けつつ、より使いやすく、皆様の役に立てるような運用管理製品を目指して、エンハンスをしていく所存です。

 

hitachi_apr2015_nagae_icon

(長江)それでは、今回ご紹介した内容を2015年5月14日に予定しているセミナーでご紹介します。 ぜひお越しください~!

 

 

hitachi_apr2015_sakagawa_icon

(坂川)浜松町で僕と握手!

無料セミナー開催のご案内

いかがでしたか?マルチクラウド運用管理、おわかりいただけたでしょうか? もっと詳しく知りたい!という方に、坂川と長江が今回ご紹介しきれなかった運用管理のコツを詳しくご説明いたします。

マルチクラウド運用にお困りの方へ ~最新の運用管理のご提案~

  • 日時:2015年 5月 14日(木) 14:00 - 17:00 (受付開始 13:30)
  • 会場:ヴイエムウェア株式会社 本社(東京都港区浜松町1-30-5浜松町スクエア13F)
  • 参加費:無料(事前登録制)
  • お申込み:http://info.vmware.com/content/APAC_JP_ev_joint_ht

皆様のご参加を心よりお待ち申し上げております。

関連リンク

vSphere ユーザー向け技術資料2種 「事例に学ぶ仮想化導入成功ノウハウ」&「10の技術ポイント」のご案内

こんにちは。マーケティングを担当している坂本です。本日はvSphere をお使いの方向けの資料2種、「お客様の管理画面を公開!事例に学ぶ仮想化導入成功ノウハウ」Ebookと「vSphere を管理する10の技術ポイント」という2つの資料をご紹介します。是非ダウンロードして御覧ください。

Ebookは vSphere with Operations Management を使い、自社の仮想化環境の運用を効率化された方のお話を元に作成いたしました。

  • IT 部門の課題とそれを解決した VMware ソリューション
  • Q&A 形式でご紹介するお客様の声
  • 管理ダッシュボードのカスタマイズ例

という3つのステップでそれぞれの特長を紹介しており、vSphereを管理されている方には参考になると思います。  (ダウンロードはこちら

eBook

また、 「vSphere を管理する10の技術ポイント」では、潜在的な課題を事前に検知して問題解決を効率化する10のポイントを、

  • 健全性監視とパフォーマンス分析
  • キャパシティの管理と最適化
  • 直感的に操作可能な運用ダッシュボードと根本原因の分析

という3つの軸に注目して紹介しております。是非御覧ください。(ダウンロードはこちら

Tech Tips
これらの資料は米国VMware 作成の資料の翻訳版です。翻訳のご要望はこのブログのコメントやTwitter  https://twitter.com/VMware_Japan へのメンションでお受付しております。 ご要望もお寄せください。

ネットワーク仮想化をネットワークの基本から理解する 〜 第2回:論理スイッチ(VXLAN) –Layer2 の世界

■はじめに
「ネットワーク仮想化」をセールスやマーケティングではなく、エンジニアとしてアーキテクチャを正しく理解することが、今回のブログシリーズ「ネットワーク仮想化をネットワークの基本から理解する」のテーマです。「第2回 論理スイッチ(VXLAN) –Layer2 の世界」では、ネットワーク仮想化環境のL2 ネットワークサービスを見ていきます。

論理スイッチは、VMware NSX の提供するL2 ネットワークサービスです。オリジナルのイーサネットフレームにハイパーバイザでVXLAN ヘッダを付加することで、物理ネットワーク上にオーバレイのL2 ネットワークサービスを提供します。論理スイッチを使用することで、物理ネットワークに手を加えることなくL2 ネットワークを追加できます。

NWV02-01-02

論理スイッチの設定はNSX の管理画面から行います。物理サーバや物理ネットワーク機器数十台にまたがるようなL2 ネットワークを構成する際も、個々の物理コンポーネントに設定を行う必要はありません。

NWV02-02

上記の通りGUI から簡単に設定を行うことができますが、APIを介した設定も可能となり、クラウドコントローラと連携することで設定作業を自動化できます。

 

■物理ネットワークにおけるL2スイッチのアーキテクチャ
論理スイッチのアーキテクチャの説明に入る前に、物理ネットワーク環境の説明を行います。物理ネットワーク環境において、端末間での通信を制御するテーブルは2種類あります。端末側で管理するARPテーブルと、物理スイッチ側で管理するMAC アドレステーブルです。

NWV02-03-02

ARP テーブルは、IPアドレスとMAC アドレスを対応させたテーブルとなり、各エンドの端末が保持しています。端末は、ARP テーブルを参照し、通信を行いたい宛先IP アドレスに対応したMAC アドレス宛てにパケットを送信します。

> arp –a(端末Aで実施)
  インターネット アドレス			物理アドレス     			種類
  172.16.10.2(端末BのIP)	BB-BB-BB-BB-BB-BB(端末BのMAC)	動的

MAC アドレステーブルは、端末のMAC アドレスと物理スイッチのポート番号を対応させたテーブルとなっており、物理スイッチが管理しています。物理スイッチは、受信したフレームの送信元MAC アドレス情報を学習することで、テーブルをダイナミックに作成していきます。MAC アドレステーブルはVLAN 毎に管理されており、物理スイッチは受信したパケットの宛先MAC アドレスに対応したポートにパケットを転送します。

> show mac address-table(物理スイッチ上で実施)
Vlan	Mac Address			Type		Ports
----	-----------			--------	-----
10	AAAA.AAAA.AAAA	(端末AのMAC)	DYNAMIC		Gi1(ポート1番)
10	BBBB.BBBB.BBBB	(端末BのMAC)	DYNAMIC		Gi2(ポート2番)

このテーブルにエントリがない宛先MAC アドレスのフレームを受信した場合、物理スイッチは対応するVLAN に所属する全てのポートにフレームを転送します。MAC アドレステーブルのエントリを管理することで、トラフィックを抑制することが可能になります。物理スイッチが提供しているL2 ネットワークサービスを、ネットワーク仮想化環境では論理スイッチとして実装しています。論理スイッチのアーキテクチャについて、「テーブル」に注目する形でこの後見ていきます。

 

■ネットワーク仮想化環境における論理スイッチのアーキテクチャ
ネットワーク仮想化環境において、端末の送信したフレームをカプセル化(VXLAN ヘッダを付加すること)するポイントを、VTEP(VXLAN Tunnel Endpoint)と呼んでいます。VTEP の理解が論理スイッチ理解の第1歩です。

VTEP の実態は、vSphere の視点で見ると、ハイパーバイザの中にある仮想スイッチ(分散スイッチ VDS)上に作成されるVMkernel ポートになります。VMkernel ポートはIP アドレスを持ち、このIP アドレス間でVXLAN のオーバレイ通信を行います。VTEP は分散スイッチ上にVMkernel ポートとして展開されるため、論理スイッチの実装には分散スイッチが必須となります。


ポイント1:VTEPの実態は、ハイパーバイザ上に作成される仮想スイッチのVMkernel ポート

NWV02-04

VTEP 間をVXLAN でオーバレイすることにより構成される論理スイッチの実態は、vSphere の視点で見ると、仮想スイッチ上に作成されるポートグループになります。サーバ仮想化環境では、物理ネットワークのVLAN ID に対応する形でポートグループ作成をするケースがありますが、ネットワーク仮想化環境では論理スイッチのVNI(VXLAN Network Identifier物理環境のVLAN IDに相当)に対応したポートグループが自動的に作成されます。


ポイント2:論理スイッチの実態は、ハイパーバイザ上に作成される仮想スイッチのポートグループ

NWV02-05

仮想マシンから論理スイッチは単にポートグループとして見えています。仮想マシンを論理スイッチに対応したポートグループに接続することで、VXLAN でオーバレイしたネットワーク経由で通信を行うことが可能になります。

この後は、論理スイッチに接続された仮想マシン間で、通信がどのように成立するのかを見ていきます。ネットワーク仮想化環境で通信を成立させるために、3つのテーブルがでてきます。これらのテーブルがどのようなメカニズムで通信を成立させるか確認していきます。

VTEP テーブル:VNI(VXLAN Network Identifier)とVTEP を対応させたテーブル
MAC テーブル :VNI、VTEP、仮想マシンのMAC アドレスを対応させたテーブル
ARP テーブル :仮想マシンのIP アドレスとMAC アドレスを対応させたテーブル

補足情報:論理スイッチを構成する際、VTEP間の通信にマルチキャストを使用するモード(マルチキャストモード)と、使用しないモード(ユニキャストモード)、及び併用するモード(ハイブリッドモード)を選択できます。この後の説明は、ユニキャストモードを前提に進めています。ユニキャストモードでは、コントローラでVTEP テーブルを集約して管理することで、物理ネットワークでマルチキャストを運用する必要がありません。

 
----------
STEP0: ネットワーク仮想化環境は、ハイパーバイザとコントローラ間で各種テーブル情報を交換するコントロールプレーンと、VTEP 間で仮想マシントラフィックを転送するデータプレーンから構成されています。2台のESXi ホスト上でVNI(VXLAN Network Identifier 物理環境のVLAN IDに相当)5001 に接続している端末間の通信を確認してみます。端末A,B は、論理スイッチ VNI 5001 に対応するポートグループに接続し、電源がOFF の状態になっています。

NWV02-06


補足情報:ハイパーバイザとコントローラ間のコネクション(コントロールプレーン)は、下記で確認できます。ハイパーバイザの管理用IP アドレスからコントローラ(192.168.110.201, 192.168.110.202, 192.168.110.203)に接続していることが確認できます。

コントローラクラスタとの接続確認
# esxcli network ip connection list | grep 1234
Proto	Local Address		Foreign Address		State		World Name
-----	--------------------	--------------------	-----------	----------
tcp	192.168.210.51:59453	192.168.110.201:1234	ESTABLISHED	netcpa-worker
tcp	192.168.210.51:61471	192.168.110.202:1234	ESTABLISHED 	netcpa-worker
tcp	192.168.210.51:61397	192.168.110.203:1234	ESTABLISHED 	netcpa-worker

仮想マシン間のデータの転送は、データプレーンを使用します。データプレーンには VTEP(VMkernel ポート)が存在し、VXLAN のオーバレイ通信を行います。

NWV02-07


補足情報:データプレーンのVTEP(VMkernel ポート)はESXi ホストにおいて他の管理系ネットワークから独立したTCP/IP スタック(メモリ領域、ルーティングテーブル、ARPテーブル)を持ちます。

ルーティングテーブル確認方法(VXLAN TCP/IP スタック)
# esxcli network ip route ipv4 list -N vxlan
Network        Netmask        Gateway        Interface  Source
-------------  -------------  -------------  ---------  ------
default        0.0.0.0        192.168.250.2  vmk3       MANUAL
192.168.250.0  255.255.255.0  0.0.0.0        vmk3       MANUAL
ARP テーブル確認方法(VXLAN TCP/IP スタック)
# esxcli network ip neighbor list -N vxlan
Neighbor       Mac Address        Vmknic  Expiry    State  Type
-------------  -----------------  ------  --------  -----  -----------
192.168.250.2  00:50:56:01:1e:3d  vmk3    1194 sec         Autorefresh
VTEP 間の疎通確認方法(VXLAN TCP/IP スタック)
# ping ++netstack=vxlan -I vmk3 -d -s 1572 192.168.150.51
PING 192.168.150.51 (192.168.150.51): 1572 data bytes
1580 bytes from 192.168.150.51: icmp_seq=0 ttl=63 time=1.745 ms

 
----------
STEP1: 仮想マシンの電源をON にすると、ハイパーバイザ内にVTEP テーブル情報が作成されます。VTEP テーブルは、VNI と、対応するVTEP のIP アドレスで構成され、VTEP テーブル情報はコントローラに送付されます。コントローラは、収集したVTEP テーブル情報を、各ハイパーバイザに通知します。この動作により、各ハイパーバイザでVNI に対応するVTEP のIP アドレスを学習することができます。


ポイント3:ハイパーバイザでVTEP テーブルを管理することにより、VNI に対応したブロードキャスト、宛先不明のユニキャスト、及びマルチキャストを転送するVTEP を把握できる

NWV02-08


補足情報:ブロードキャスト、宛先不明のユニキャスト、マルチキャストを略してBUM トラフィックと呼びます。宛先不明のユニキャストとは、ハイパーバイザ内に後述のMAC テーブル情報のないトラフィックのことです。

コントローラでの確認方法
# show control-cluster logical-switches vtep-table 5001
VNI	IP(VTEPのIP)		Segment			MAC(VTEPのMAC)
5001	192.168.250.51(ESXi01)	192.168.250.0		01:01:01:01:01:01
5001	192.168.250.52(ESXi02)	192.168.250.0		02:02:02:02:02:02

上記よりコントローラではESXi01、ESXi02 のVTEP を認識していることが分かります。

ハイパーバイザでの確認方法
ESXi01 # esxcli network vswitch dvs vmware vxlan network vtep list --vds-name=Compute_VDS --vxlan-id=5001
IP(VTEPのIP)			Segmant ID		Is MTEP
--------------			-------------		-------
192.168.250.52(ESXi02)		192.168.250.0		false

上記よりESXi01 が、VXLAN5001 の転送先としてESXi02のVTEP を認識していることが分かります。

 
----------
STEP2: 仮想マシンから通信が発生した際、カーネルモジュールが通信の送信元MAC アドレスから、仮想マシンのMAC アドレスを認識します。認識した仮想マシンのMAC アドレス情報をコントローラクラスタに通知します。

NWV02-09

コントローラでの確認方法
# show control-cluster logical-switches mac-table 5001
VNI	MAC(端末のMAC)			VTEP-IP			
5001	AA:AA:AA:AA:AA:AA(端末A)	172.16.250.51(ESXi01)
5001	BB:BB:BB:BB:BB:BB(端末B)	172.16.250.52(ESXi02)

上記よりコントローラでは端末A,BのMACアドレスと、対応するVTEP を認識していることが分かります。

 
----------
STEP3: 仮想マシンのIP アドレス情報を含む特定の通信(ARP ResponseもしくはDHCP ACK)から、カーネルモジュールが仮想マシンのIP アドレスとMAC アドレスを認識します。認識した情報をコントローラクラスタに通知します。ARP 抑制(ARP Suppression)が有効な場合、このステップが実施されます。

NWV02-10

ARP 抑制はデフォルトで有効となり、論理スイッチの設定画面「IP検出の有効化」のチェックボックスで有効化、無効化を行います。以降の説明はARP 抑制が有効化されている前提で進めていきます。

コントローラでの確認方法
# show control-cluster logical-switches arp-table 5001
VNI	IP(端末のIP)		MAC(端末のMAC)
5001	172.16.10.11(端末A)	AA:AA:AA:AA:AA:AA(端末A)
5001	172.16.10.12(端末B)	BB:BB:BB:BB:BB:BB(端末B)

上記よりコントローラでは端末A,B のARP テーブル情報を認識していることが分かります。

 
----------
STEP4: 端末A が端末B に対しARP リクエストを送信します。端末A からのARP リクエストをESXi01 のカーネルモジュール が受け取ります。ESXi01 は、リクエストをコントローラに問合せ、端末B のARP テーブル情報をコントローラから受け取ります。ESXi01 は端末A にARP リプライを返します。


ポイント4:ハイパーバイザでARP テーブルを管理することにより、仮想マシンからのARP リクエストに代理応答し、物理ネットワークを流れるトラフィック(ARPブロードキャスト)を削減できる

NWV02-12

ハイパーバイザでの確認方法
ESXi01 # esxcli network vswitch dvs vmware vxlan network arp list --vds-name=Compute_VDS --vxlan-id=5001
IP(端末のIP)		MAC(端末のMAC)	
------------		-----------------		
172.16.10.12(端末B)	BB:BB:BB:BB:BB:BB(端末B)

上記よりESXi01 がARP テーブル情報(端末BのIP アドレスとMAC アドレスの対応)を認識していることが分かります。


補足情報:コントローラで端末B に対応するARP テーブルを保持していない場合、ESXi ホストはARP リクエストを通常のブロードキャストトラフィックとして処理します。VTEP テーブルを参照しVNI 5001 に対応するESXi ホストに送信します。

 
----------
STEP5: ESXi01 は、端末B に対応するMACテーブルをコントローラクラスタに問合せ、端末B のMAC テーブル情報を取得します。

NWV02-13

ハイパーバイザでの確認方法
ESXi01 # esxcli network vswitch dvs vmware vxlan network mac list --vds-name=Compute_VDS --vxlan-id=5001
Inner MAC(端末のMAC)		Outer MAC(VTEPのMAC)		Outer IP(VTEPのIP)
-----------------		-----------------		-------------	
BB:BB:BB:BB:BB:BB(端末B)	02:02:02:02:02:02(ESXi02)	172.16.250.52(ESXi02)

上記よりESXi01 は、ESXi02 上に端末B が存在することを認識していることが分かります。

 
----------
STEP6: ESXi01 からのARP 応答(STEP4 で実施)により端末A は端末B のMAC アドレス情報を取得し、端末B に対する通信を開始します。ESXi01 はMAC テーブル(STEP5 で取得)を参照し、VXLAN でカプセル化したパケットを、ESXi02 のVTEP へ送信します。ESXi02 では、パケットを受信した際に端末A に対応するMAC テーブルを作成します。その後VXLAN ヘッダを取り除き、端末B にオリジナルのフレームを転送します。


ポイント5:ハイパーバイザでMAC テーブルを管理することにより、宛先の仮想マシンが動作しているホストのVTEP を把握し、物理ネットワークを流れるトラフィック(宛先不明のユニキャスト)を削減できる

NWV02-14


補足情報:STEP5 において、コントローラで端末B に対応するMAC テーブルがなく、ハイパーバイザ内にもMAC テーブルがない場合、ESXi01 は端末B に対する通信を宛先不明のユニキャストとして処理します。VTEP テーブルを参照しVNI 5001 に対応するESXi ホストに送信します。

 

■物理ネットワーク環境とネットワーク仮想化環境の比較
ポイント1-5を再掲します。


ポイント1:VTEPの実態は、ハイパーバイザ上に作成される仮想スイッチのVMkernelポート


ポイント2:論理スイッチの実態は、ハイパーバイザ上に作成される仮想スイッチのポートグループ

上記2つのポイントはサーバ仮想化エンジニアの方はイメージしやすいのではないでしょうか。


ポイント3:ハイパーバイザでVTEP テーブルを管理することにより、VNI に対応したブロードキャスト、宛先不明のユニキャスト、及びマルチキャストを転送するVTEP を把握できる


ポイント4:ハイパーバイザでARP テーブルを管理することにより、仮想マシンからのARP リクエストに代理応答し、物理ネットワークを流れるトラフィック(ARPブロードキャスト)を削減できる


ポイント5:ハイパーバイザでMAC テーブルを管理することにより、宛先の仮想マシンが動作しているホストのVTEP を把握し、物理ネットワークを流れるトラフィック(宛先不明のユニキャスト)を削減できる

上記3つのポイントについて「テーブル」の観点から、物理ネットワーク環境とネットワーク仮想化環境を比較してみます。

NWV02-15

ARP テーブルの役割は物理ネットワーク環境と全く同じです。テーブル情報を、端末だけではなく、コントローラで集約して管理を行い、端末からのARP リクエストにハイパーバイザが代理応答することで、物理ネットワークを流れるトラフィックを削減しているのがネットワーク仮想化環境の特徴となります。

MAC テーブルは、物理ネットワーク環境のMAC アドレステーブルと同等の役割を果たしています。ハイパーバイザは、MAC テーブルを参照することで、VTEPの先にある端末のMAC アドレスを把握し、物理ネットワークを流れるトラフィックを削減することができます。

VTEP テーブルは、物理スイッチにおけるポートのVLAN 設定に対応します。VTEP テーブルを参照することでブロードキャスト、宛先不明のユニキャスト、及びマルチキャスト(BUM トラフィック)を転送する先を判断することができます。ユニキャストモードではVTEP テーブルをコントローラが集約して管理することで、マルチキャストに依存しないVXLAN の運用を可能にしています。

NWV02-16

論理スイッチの管理するVTEP テーブルとMAC テーブルを合わせ、VTEP を物理スイッチのポートに置き換えて考えると、論理スイッチはネットワーク仮想化環境において、物理スイッチと同等の機能を提供していることが分かります。

ネットワーク仮想化環境では、L2ネットワークを管理するための各種テーブルを物理ネットワーク機器から切り離し、ハイパーバイザで管理することにより、物理ネットワークと同等のサービスを、物理ネットワークに依存しない形で柔軟に展開することを可能にします。さらにコントロールプレーンを実装し、コントローラで各種テーブル情報を集約することで、マルチキャストに依存しない論理スイッチ(VXLAN)の展開や、物理ネットワークを流れるトラフィックを削減する運用を可能にしています。

 

■補足情報 論理スイッチ(VXLAN)を提供するVMware NSX のコンポーネント

NWV02-17

・NSX Manager(マネジメントプレーン)
NSX を構築する際に最初に展開するコンポーネントで、仮想アプライアンスとして提供されています。NSX Manager は初期構築時の ESXi ホストへのカーネルモジュールのインストールや、論理ルータコントロールVM やNSX Edge といった仮想アプライアンスの払い出しを担います。また、NSX Manager はAPI のエントリポイントとなり、GUI だけでなくAPI 経由でNSX 環境の設定を可能にします。

・NSX コントローラクラスタ(コントロールプレーン)
NSX コントローラクラスタは、現時点で3台の仮想アプライアンスで構成することを推奨しており、論理スイッチにおいて、各種情報(VTEP テーブル、MAC テーブル、ARP テーブル)を集中管理するポイントになります。VXLAN のVNI 毎に担当するコントローラが決められ、例えばVNI 5000はコントローラ1番、VNI 5001 はコントローラ2番というように役割が割り当てられます。テーブル情報は、担当するコントローラのみが保持します。なお、論理スイッチ(VXLAN) をマルチキャストモードで実装する場合は、コントローラクラスタは必要ありません。

3台のコントローラ(192.168.110.201, 192.168.110.202, 192.168.110.203)で構成されている環境で、VNI 5001 の情報を確認する手順は下記のとおりです。

VXLAN VNI 5001 を管理するコントローラの確認
# show control-cluster logical-switches vni 5001
VNI	Controller		BUM-Replication		ARP-Proxy
5001	192.168.110.202		Enabled			Enabled

この出力結果から、192.168.110.202 のコントローラがVNI 5001 の情報を管理していることが分かります。VNI 5001 の各種テーブル情報を見るためには、該当のコントローラ(192.168.110.202)にログインする必要があります。

VXLAN VNI 5001 のVTEP テーブルの確認
# show control-cluster logical-switches vtep-table 5001
VNI	IP(VTEPのIP)		Segment			MAC(VTEPのMAC)
5001	192.168.250.51(ESXi01)	192.168.250.0		01:01:01:01:01:01
5001	192.168.250.52(ESXi02)	192.168.250.0		02:02:02:02:02:02
VXLAN VNI 5001 のMAC テーブルの確認
# show control-cluster logical-switches mac-table 5001
VNI	MAC(端末のMAC)			VTEP-IP			
5001	AA:AA:AA:AA:AA:AA(端末A)	172.16.250.51(ESXi01)
5001	BB:BB:BB:BB:BB:BB(端末B)	172.16.250.52(ESXi02)
VXLAN VNI 5001 のARP テーブルの確認
# show control-cluster logical-switches arp-table 5001
VNI	IP(端末のIP)		MAC(端末のMAC)
5001	172.16.10.11(端末A)	AA:AA:AA:AA:AA:AA(端末A)
5001	172.16.10.12(端末B)	BB:BB:BB:BB:BB:BB(端末B)

・論理ルータコントロールVM(コントロールプレーン)
論理ルータコントロールVM は論理スイッチに関与しません。(第3回分散ルーティングで解説を行います)

・ハイパーバイザ カーネルモジュール(データプレーン)
NSX 環境を構築する際、ホストの準備のステップで各ESXi にインストールされるカーネルモジュールとなります。VIB(vSphere Installation Bundle)ファイルとしてインストールされ、論理スイッチの機能はカーネルモジュール(vdl2)としてロードされます。 カーネルモジュールは、ハイパーバイザ内で論理スイッチ(VXLAN)のテーブル情報を管理します。

ハイパーバイザからは、NSX コントローラクラスタと、NSX Manager にコネクションを張り、各種情報のアップデートを行います。NSX コントローラクラスタへのコネクションはハイパーバイザ内のUWA(User World Agent)netcpa(TCP/1234)を介して確立し、NSX Manager へのコネクションはUWA vsfwd(TCP/5671)を介して確立します。

NWV02-18-02

コントローラクラスタとの接続確認
# esxcli network ip connection list | grep 1234
Proto	Local Address		Foreign Address		State		World Name
-----	--------------------	--------------------	-----------	----------
tcp	192.168.210.51:59453	192.168.110.201:1234	ESTABLISHED	netcpa-worker
tcp	192.168.210.51:61471	192.168.110.202:1234	ESTABLISHED 	netcpa-worker
tcp	192.168.210.51:61397	192.168.110.203:1234	ESTABLISHED 	netcpa-worker

上記出力より、ハイパーバイザの管理用IP アドレスから3台のコントローラ(192.168.110.201, 192.168.110.202, 192.168.110.203)に、netcpa を介して接続していることが確認できます。

NSX Manager との接続確認
# esxcli network ip connection list | grep 5671
Proto	Local Address		Foreign Address		State		World Name
-----	--------------------	--------------------	-----------	----------
tcp	192.168.210.51:23251	192.168.110.42:5671	ESTABLISHED	vsfwd

上記出力より、ハイパーバイザの管理用IP アドレスからNSX Manager に、vsfwd を介して接続していることが確認できます。

論理スイッチのカーネルモジュールは、ハイパーバイザ内でVTEP, MAC, ARP テーブルを管理します。

VXLAN VNI 5001 のVTEP テーブルの確認
ESXi01 # esxcli network vswitch dvs vmware vxlan network vtep list --vds-name=Compute_VDS --vxlan-id=5001
IP(VTEPのIP)			Segmant ID		Is MTEP
--------------			-------------		-------
192.168.250.52(ESXi02)		192.168.250.0		false
VXLAN VNI 5001 のMAC テーブルの確認
ESXi01 # esxcli network vswitch dvs vmware vxlan network mac list --vds-name=Compute_VDS --vxlan-id=5001
Inner MAC(端末のMAC)		Outer MAC(VTEPのMAC)		Outer IP(VTEPのIP)
-----------------		-----------------		-------------	
BB:BB:BB:BB:BB:BB(端末B)	02:02:02:02:02:02(ESXi02)	172.16.250.52(ESXi02)
VXLAN VNI 5001 のARP テーブルの確認
ESXi01 # esxcli network vswitch dvs vmware vxlan network arp list --vds-name=Compute_VDS --vxlan-id=5001
IP(端末のIP)			MAC(端末のMAC)	
------------			-----------------		
172.16.10.12(端末B)		BB:BB:BB:BB:BB:BB(端末B)	

・NSX Edge(データプレーン)
NSX Edge のインターフェイスを、論理スイッチに接続することでNSX Edge の持つ各種ネットワークサービス(ロードバランサ、ルーティング、NAT、ファイアウォール、VPN、 DHCP 等)を論理スイッチに接続した仮想マシンに対して提供します。論理スイッチの提供するL2ネットワークサービスには直接関与しません。

 

■関連リンク
今回ご紹介した内容をオンラインのハンズオン環境上で確認いただくことができます。コマンドラインの出力はハンズオン環境をベースに作成しています。
VMware HOL Online
HOL-SDC-1403 - VMware NSX Introduction

NSX の機能全般及び、ネットワーク仮想化環境の設計に興味のあるかたは下記テックペーパーを参照ください。
VMware® NSX for vSphere (NSX-V) Network Virtualization Design Guide

ネットワーク仮想化をネットワークの基本から理解する
第1回:理解するために必要なことを整理する
第2回:論理スイッチ(VXLAN)–Layer2 の世界
第3回:分散ルーティング –Layer3 の世界
第4回:分散ファイアウォール -Layer4 の世界

VMwareテクニカルトレーナーよりワンポイントアドバイス~シェアと予約をおさえよう!~

こんにちは。VMware EducationのテクニカルトレーナーのSatokoです!!!
前回は、物理のCPUやメモリがどのように仮想レイヤと紐づいているか、お話させていただきました。その中で仮想環境では物理的なリソース量に対して、その物理量を超えた仮想マシンを載せることができること  (= 設定時におけるオーバーコミット状態 ) についても触れました。今回は、多くの仮想マシンを載せてしまったが、実際運用時ではどのようにリソース制御をすればよいか?の基本をお話します。

■物理リースを超えた仮想マシンのリソース総量

例えば、VMware ESXi ホスト ( ESXi ) 上に、Webサーバ、Appサーバ、DBサーバ、Fileサーバ等の仮想マシン(仮想マシン)を構成しています。

図1

 

図1 が示すように、
40GB(ホストの持つメモリリソース)  <  43GB(仮想マシンに設定されたメモリリソースの合計)
となり、ESXi ホストがもつ40GBメモリーリソース以上に仮想マシンのメモリリソース合計が設定されている状態です。この状態はどうかといういうと、設定されている値 (ここでは43GB )をすべて使用するとは限らず、必要な分だけ各仮想マシンに割り当てられていますので、物理のリソースを超えた設定自体がパフォーマンスに影響を与えるものではないことを、前回もお話しました。

続いてCPUリソースをみていきましょう

図2

図2

 

こちらもvCPU数が物理のコア数を超えていても、それぞれの仮想マシンが必要な時に必要なCPUリソースを配分されることで、パフォーマンスに影響なく複数のサービスの提供が可能です。そのため、設計時にそれぞれの仮想マシンのリソース消費のピークが重ならないように組み合わせを考慮することが重要になります。

図3

図3

図3のように、CPUリソースが競合した場合には、処理の遅延が発生することでパフォーマンスへの影響が懸念されます。
メモリリソースもCPUリソースもオーバコミットしていること自体パフォーマンスへの影響はないのですが、リソースを有効に使用する!という仮想基盤の特性上、このリソース競合とどう付き合っていくか?がとても大事になってきます。今回は、その仮想基盤の特性上欠かせない、リソース制御の「シェア」と「予約」の基本についてみていきます。

■CPU/メモリリソース制御における「シェア」を押さえよう

CPUのシェアの考え方

まず、CPUのシェアをみていきましょう。シェアはリソースが競合してしまったときに、設定した「シェア値」でリソース配分を決めることができます。

図4

図4

 

上記の図4で、CPUリソースの割り当てを具体的に見てみましょう。

物理CPU:3GHz×1
各仮想マシンvCPU:3GHz×1

1つの物理Coreを2つの仮想マシンvCPUで共有しているパターン(合計2vCPU)です。

リソースが競合した場合、シェアの値によって、リソースが割り当てされます。
デフォルトであれば、各vCPUは、1.5GHzのCPUリソースが均等にハイパーバイザによって割り当てられます。もちろん共有している物理CPUは1つなので、所有できる時間をシェアの値によって優先度を変えています。

例えばシェアの値を変えてみましょう。シェア値を大きくすることによって、特定の仮想マシンに対してより優先的にリソースを分配することが可能なのです。(図5)

図5

図5

メモリシェア編

同様に図6で、メモリシェアの割り当ても具体的に見てみましょう。

図6

図6

ESXi ホストの持つ 6GB の物理メモリを2つの仮想マシンで共有しているパターンです。
この例では、6GB の物理メモリリソースでは、各仮想マシンに設定された4GBが割り当てられるわけではなく、仮想マシンでのメモリ使用量合計が 6GB を超えた場合 (= 競合状態) にシェアの値が働きます。シェア値がデフォルトであれば、各仮想マシンは、3GBずつのメモリリソースが均等にハイパーバイザによって割り当てられます(左図)が、 シェア値を大きくすることで、優先的にリソースを分配することが可能です(右図)。

リソースの競合が起きたとき、デフォルトでは、均等にリソースは割り当てられますが、競合時にCPUメモリリソースを優先的に割り当てたいシステムは存在します。 競合発生時、それぞれのサーバが必要とするリソースが均等ではないのであれば、ここは、管理者が優先度に従い、割合を指定していくことで柔軟にリソースの割り当てを実施していきます。

 

■「予約」の基本 ~CPU編~

シェア値の設定によって、リソース競合時の優先度を定義できるのですが、シェアは、あくまでも割合の指定です。
例えば、Applicationのために十分なパフォーマンスを確約したいということであれば、具体的な数値で指定する「予約」の値を指定することで、より確実に指定したリソースを担保することも可能です。

図7

図7

CPUリソースの予約を指定した場合を見てみましょう。

1Coreを4つの仮想マシン(vCPU)で共有しているパターン(合計 4vCPU )です。
予約の値はデフォルト設定されていません。予約の値を設定することで、CPUリソースは、起動時や運用時のCPUリソースの割り当てを担保することができます。
CPUリソースは、ハイパーバイザによって割り当てられます。CPUリソースは、指定した予約の値のCPUリソースを使用していない時は、別の仮想マシンにCPUリソースが割り当てられ、より柔軟にCPUリソースは活用されます。

■「予約」の基本 ~メモリ編~

続いてメモリリソースの予約を見ていきましょう。

図8

図8

ESXi ホストの持つ物理メモリ 6GB を4つの仮想マシンで共有しているパターンです。

CPUリソースと同様に、デフォルトでは予約は設定されていません。A_VMの予約値を2GBと指定することで、2GB が起動時にハイパーバイザによって確保されます。A_VMが予約されたメモリリソース以上のメモリリソースが必要な場合は、残る共有リソースから割り当てられることになります。
予約は特定の仮想マシンがリソースを占有することになります。すなわち、仮想化のメリットであるリソースの共有を最大限に生かすのであれば、予約値を必要最低限にしておくのがコツです♪

 

■設定してみよう!

それでは各仮想マシンに対するシェアと予約の設定方法を見ていきましょう。各仮想マシンを右クリックして「リソース設定の編集」を開きますデフォルトの設定では、下記のように、シェアは「標準」、予約は「0」となっています。

図9

図9

CPUを例にシェアの値を指定してみましょう。仮想マシンに割り当てたシェアの値を、ESXi ホスト側からも確認することができます。この例の場合、CPUのシェアが4 (高): 2 (標準): 1 (低)になっていることが分かります。このように優先順位が指定されます。予約に関しても同じ画面で設定することができますので、設定自体はとても簡単ですね♪

 

図10

図10

今回は、リソースの制御方法である「シェア」と「予約」を見てきました。 安全に多くの仮想基盤を運用するには、このリソース管理の考え方が基本になってきます。ここでは、単体のESXi ホスト上でのリソース制御を紹介しましたが、クラスタ(複数のESXiホストをグループ化)のリソース制御では、リソースプールが利用できます。それはまた次の機会にお話したいと思います!

VMwareテクニカルトレーナーよりワンポイントアドバイス
第1回:VMware vSphereにおけるCPU・メモリの考え方編
第2回:シェアと予約をおさえよう!(本記事)

ネットワーク仮想化をネットワークの基本から理解する 〜 第1回:理解するために必要なことを整理する

■ はじめに
「ネットワーク仮想化」をセールスやマーケティングではなく、エンジニアとしてアーキテクチャを正しく理解することが、今回のブログシリーズ「ネットワーク仮想化をネットワークの基本から理解する」のテーマです。このシリーズは、VMware 社内でネットワークのバックグラウンドを持ったエンジニアが行った小さなワークショップがベースになっています。ワークショップ中ではホワイトボードを使用して通信の仕組みを理解し、実際のネットワーク仮想化環境でコマンドラインを使用し出力される情報と比較しながら、ネットワーク仮想化環境の特徴的な機能を1つ1つ確認していきました。

「第1回 理解するために必要なことを整理する」では、エンジニアがネットワーク仮想化を理解するために必要となる技術スタックを明確にし、第2回以降で各技術スタックの具体的な解説を行っていきます。

 

■ ネットワーク仮想化の出てきた背景
VMware の提唱する「ネットワーク仮想化」は、データセンタネットワークのオペレーションを劇的に改善する革新的なテクノロジーです。ネットワーク仮想化環境では、ネットワークサービスを物理インフラストラクチャから切り離すことで、サーバ仮想化環境の仮想マシンと同じように、各種ネットワークサービスを迅速に展開できるようになります。

NWV01-01

図:データセンタ内の仮想ポート数

上のグラフはデータセンタのサーバが、物理スイッチもしくは仮想スイッチどちらのポートに接続されているかを示したものです。2012 年の時点で、仮想スイッチのポート数が物理スイッチのポート数を超えていることから、各種ネットワークサービスやセキュリティポリシーを適用する最適なポイントが、物理スイッチから、ハイパーバイザの中で動作する仮想スイッチに移ってきていることが分かります。このような背景の中、VMware はネットワーク仮想化環境を提供するVMware NSX の提供を開始しました。

 

■ 理解するために必要なことを整理する
ネットワーク仮想化のセミナーに参加いただくのは、当初サーバ仮想化に関わるエンジニアが多かったのですが、最近の傾向としていわゆるネットワークエンジニアに参加いただくことが多くなってきているように思います。「ネットワーク仮想化」を理解するためには、サーバ仮想化と、従来のネットワークと両者にまたがった知識が必要となります。

NWV01-02

両者の交差する領域には具体的にどういったものがあるでしょうか。仮想化環境で提供されている機能を考えたときに、ハイパーバイザの提供するvMotion、HA、FT などの機能は従来通りサーバ仮想化エンジニアが担当し、ロードバランサ、VPN といった各種ネットワークサービスに関してはネットワークエンジニアが担当することで、従来の役割分担と大きく変わるところはないと考えています。

NWV01-03

中心にある3つのスタックは、両方のエンジニアの交差する領域となり、ハイパーバイザの中で各種ネットワークサービスが提供される部分になります。この中で論理スイッチ(L2) の部分はネットワーク仮想化環境を理解するための重要なベースになると考えています。加えて分散ルーティング(L3)及び、分散ファイアオール(L4)は、ネットワーク仮想化環境の特徴的な機能で、既存のデータセンタネットワークの課題を解決します。

ネットワーク仮想化のセミナーを行う中でいただく質問を通して、バックグラウンドによって分かりにくいポイントが異なっていることが分かります。サーバ仮想化エンジニアの方は、遠回りに見えるかもしれませんが、物理ネットワーク環境の端末間で通信が成立する基本的なメカニズムを理解したほうが、結果的にネットワーク仮想化環境の理解が早まります。例えば、下図のようなL2SWに端末を2台接続した環境において、端末間A – B 間で通信が成立するメカニズムをきちんと説明できる方は意外に少ないように思います(決して難しいことではなく、IT 関連の新入社員研修にこの説明は必ず含まれていますと思います)。

NWV01-04

端末間の通信を成立させるためには、各種「テーブル」が深く関わってきており、それはネットワーク仮想化環境になっても全く同じです。ネットワークエンジニアは前述の物理ネットワークでの通信については良く理解していますが、サーバ仮想化環境のオペレーションに慣れている方はまだ少ないように思います。そのため、特にハイパーバイザの中がブラックボックスになってしまい、管理されている情報が不明確になってしまいます。

1. 物理ネットワーク環境で管理されている各種「テーブル」
2. ネットワーク仮想化環境で管理されている各種「テーブル」

上記2つの基本的なポイントをおさえることで、サーバ仮想化エンジニア、ネットワークエンジニア共に、ハイパーバイザでネットワークサービスを提供するメリットと、実現するためのアーキテクチャを明確にすることができます。

ネットワーク仮想化は、データセンタネットワークのオペレーションを劇的に改善しますが、決して既存のテクノロジーと断絶したものではありません。既にあるサーバ仮想化とネットワークアーキテクチャの延長線上にあり、既存の物理インフラストラクチャの上で動作します。第2回からは、既存の物理ネットワーク環境と対比し、特にネットワークを制御する各種「テーブル」に注目することで、物理ネットワーク環境との共通点と差異を明確にしていきます。

 

■ 今後の展開
ハイパーバイザの中をブラックボックスにしないために、何が行われているかを文章だけではなくコマンドラインを中心とした実環境での確認方法と合わせて解説していきます。

第2回 論理スイッチ(VXLAN)ではNSX の提供するL2 ネットワークサービスの説明をします。物理環境でL2 スイッチが持っている「MAC アドレステーブル」が、ネットワーク仮想化環境でどう変わるかに注目します。

NWV01-05

第3回 分散ルーティングでは、NSX の提供するL3 ルーティングサービスの説明をします。物理環境でルータや、L3 スイッチが持っている「ルーティングテーブル」が、ネットワーク仮想化環境でどう変わるかに注目します。

NWV01-06

第4回 分散ファイアウォールでは、NSX ので供するL4 ファイアウォールサービスの説明をします。物理環境でネットワーク機器が持っている「ルールテーブル」が、ネットワーク仮想化環境でどう変わるかに注目します。

NWV01-07

 

■ 補足情報 ネットワーク仮想化を提供するVMware NSX を構成するコンポーネント

各機能で使用するコンポーネントが異なるため、各回でどのコンポーネントがどういった役割を果たしているのか補足情報として解説を行います。今回は各コンポーネントの概要を説明します。

NWV01-09

・NSX Manager(マネジメントプレーン)
NSX を構築する際に最初に展開するコンポーネントで、仮想アプライアンスとして提供されています。NSX Manager は初期構築時の ESXi ホストへのカーネルモジュールのインストールや、論理ルータコントロールVM やNSX Edge といった仮想アプライアンスの払い出しを担います。また、NSX Manager はAPI のエントリポイントとなり、GUI だけでなくAPI 経由でNSX 環境の設定を可能にします。

・NSX コントローラクラスタ(コントロールプレーン)
NSX コントローラクラスタは、現時点で3台の仮想アプライアンスで構成することを推奨しており、論理スイッチ(第2回)と分散ルータ(第3回)において、各種テーブルを集中管理するコンポーネントになります。なお、分散FW(第4回)はコントローラクラスタを使用しません。

・論理ルータコントロールVM(コントロールプレーン)
論理ルータコントロールVM は、仮想アプライアンスとして提供され、分散ルーティング環境において、ルーティングの処理を集中して行います。テナント単位でスタティックルーティング情報や、ダイナミックルーティングプロトコル(OSPF, BGP)経由で学習したルーティング情報を管理し、コントローラクラスタ経由でESXi ホストに配信します。

・ハイパーバイザ カーネルモジュール(データプレーン)
NSX 環境を構築する際、ホストの準備のステップで各ESXi ホストにインストールされるカーネルモジュールとなります。今回のシリーズで解説する各機能を担い、ハイパーバイザの中で下記のネットワークサービスを提供します。
a.論理スイッチ(vdl2)
第2回で解説する論理スイッチの機能を担います。
b.分散ルータ(vdrb)
第3回で解説する分散ルーティングの機能を担います
c.分散FW(vsip)
第4回で解説する分散ファイアウォールの機能を担います。

・NSX Edge(データプレーン)
仮想アプライアンスとして提供され、単体で各種ネットワークサービス機能(ロードバランサ、ルーティング、NAT、ファイアウォール、VPN、 DHCP 等)を提供する「スイスのアーミーナイフ」のようなコンポーネントです。従来の物理のネットワーク機器が仮想アプライアンスとして置き換わったイメージです。機能スタックのネットワークサービスに該当し、今回のシリーズでは解説を行いません。

 

■関連リンク
ネットワーク仮想化をネットワークの基本から理解する
第1回:理解するために必要なことを整理する
第2回:論理スイッチ(VXLAN)–Layer2 の世界
第3回:分散ルーティング –Layer3 の世界
第4回:分散ファイアウォール -Layer4 の世界

速報!VMware vSphere 6.0 新機能の概要

2015年3月12日に、vSphereの次バージョンとなる、VMware vSphere 6.0(以下vSphere 6.0)が公開されましたので、こちらのバージョンで追加された新機能・特徴の概要をご紹介します。

ただしこのBlogは、製品出荷前のバイナリ及びマニュアルを参照して記載しています。出来る限り正確な情報をお伝えするよう努めておりますが、実際に製品に搭載される機能や表示とは異なる可能性があります。あらかじめご了承の上、ご利用下さい。

 

1.スケーラビリティ

以前のバージョンに比較して、ESXiホスト/仮想マシンのスケーラビリティが大きく拡張しております。

vCenterに関してもWindows版/アプライアンス版ともに下記の通り、管理可能なホスト数や仮想マシン数が拡張しております。

詳細な「構成の上限」に関する情報は、弊社ドキュメントを参照下さい。

 

2.プラットフォーム機能

  • ローカルの ESXi アカウントおよびパスワード管理の強化・・・ユーザーのアカウントのロックアウトや詳細設定による、複雑なルールが設定可能になり、ESXi の管理操作の監査性が向上しました。
  • Microsoft Cluster Service (MSCS) の機能拡張・・・MSCS 仮想マシンの vMotion をサポート。

 

3.vCenter Server

  • Platform Services Controller の導入・・・Platform Services Controller (以下 PSC)が導入され、単なるシングル サインオンの機能に加えてライセンス、証明機関の役割を持ちます。これにより柔軟な構成が可能になります。
  • 拡張リンク モードの使用・・・拡張リンク モードを使用することにより、すべてのリンクされた vCenter Server システムを表示し、まとめて検索することができます。

  • vCenter Server と ESXi の証明書ライフサイクル管理・・・vSphere 6.0 以降では、VVMware 認証局 (VMCA) が証明書を使用して環境のプロビジョニングを行います。これには、安全な接続用のマシン SSL 証明書、vCenter Single Sign-On への認証用のソリューション ユーザー証明書、vCenter Server に追加された ESXi ホスト用の証明書が含まれます

 

4.コア機能の強化

  • VMware vSphere vMotion(以下 vMotion)

vMotionについては、主に下記点で機能強化・改善が行われております。

 

・Cross vSwitch vMotion(別の仮想スイッチへの移行)・・・異なるタイプの仮想スイッチ間で仮想マシンを移行が可能です、但しDistributed Switch から標準スイッチへの vMotionは不可となります。(標準から標準または Distributed Switch に、および Distributed Switch から別の Distributed Switch に仮想マシンを移動することができます。)

・Cross vCenter vMotion(別のvCenter Server システムへの移行)・・・異なる vCenter Server インスタンス間で仮想マシンを移行。

・Long Distance vMotion(長距離 vMotion 移行)・・・ネットワークの最大往復待ち時間は 100 ミリ秒までの環境下で仮想マシンを移行。

・vMotion ネットワークの柔軟性の向上・・・vMotion TCP/IP スタックを使用して、vMotion のトラフィックを隔離し、このトラフィックの専用デフォルト ゲートウェイ、ルーティング テーブル、および DNS 構成を割り当て可能。

 

  • コンテンツライブラリの導入・・・仮想マシン テンプレートと vApp を簡単かつ効率的に管理が可能になります。

 

  • vSphere Fault Tolerance (FT)・・・vSphere Fault Tolerance は、最大で 4 つの vCPU を持つ対称型マルチプロセッサ (SMP) 仮想マシンに対応できます。以前のバージョンの vSphere(vSphere5.5以前) とは、Fault Tolerance に異なる技術が使用されております。

 

  • vSphere HA・・・仮想マシンのコンポーネント保護 (VMCP) の導入により、vSphere HA はデータストアのアクセス障害を検出して、影響を受ける仮想マシンの自動リカバリを実行できます。

 

5.仮想マシン

  • サポートゲストOSの拡張(詳細は互換性ガイドを参照ください)
  • ハードウェアバージョンのアップデート(ESXi 6.0以降:Virtual Hardware version 11)
  • 仮想マシンは、最大128個の仮想CPUと、4 TBの仮想メモリをサポート

 

6. Client

  • Web Clientの応答性が向上

 

7.ネットワーク

  • Network I/O Control バージョン 3・・・ホスト上の物理アダプタのキャパシティに基づいて、システム トラフィックのバンド幅を予約するメカニズムを導入しています。これにより、CPU およびメモリ リソースの割り当てに使用するモデルと同様に、仮想マシン ネットワーク アダプタ レベルでリソースを詳細に制御できます。

 

8.ストレージ

  • vSphere Virtual Volumes・・・外部ストレージアレイを仮想マシン単位で管理することができます。
  • 仮想マシン ストレージ ポリシー・・・ストレージ情報およびデータストアの特性を、特定のデータストアタイプ共通の管理機能を提供します。これにより、仮想マシンの配置について適切に決定し、ストレージ環境を監視することができます。
  • VMware Virtual SAN 6.0
・All Flash のサポートによるパフォーマンス・スケーラビリティの向上。
・ユーザビリティの向上(vSphere Web Client UIでサポート)。
・信頼性向上。

 

9.その他

  • VMware vSphere Replication

・End-to-End でのネットワークの圧縮・・・帯域幅の要件をさらに削減

・ネットワーク トラフィックを管理ネットワークから分離・・・帯域幅を制御し、パフォーマンスとセキュリティを向上

・Linux ファイル システムの静止機能 (quiescing)・・・Linux 仮想マシンをリカバリする際の信頼性を向上

 

次回から、各機能の詳細な情報をご紹介していきます。

VMwareテクニカルトレーナよりワンポイントアドバイス~VMware vSphereにおけるCPU・メモリの考え方編~

こんにちは!VMware EducationのテクニカルトレーナーのSatokoです!!
みなさん、「Tech Day」というイベントをご存知でしょうか?すでにVMware製品をお使い、または導入検討されているエンドユーザ様に無償で提供している大人気イベントです。(今年も2月に実施予定です) TechDayでは実際QAタイムを設けて、実際に今困っていることや今更聞けない基本的なこと等、機能や使い方に関して、多くのご質問をいただいています。その中で多いご質問が、CPU、メモリリソースに関してのご質問です。
今回は、この場をお借りして、vSphere環境におけるCPUやメモリの見え方や考え方を復習していきます。

§1.vSphereにおけるリソースの扱い方~CPU編~

まず物理CPUにおける用語 「ソケット」 「コア」 「スレッド」をみていきます。

図1

ソケットとは、コアをマザーボードに装着するための、穴の空いた板状の部品で、ピンを差し込んで固定して使用します。
コアは、実際に演算を行う部分です。昨今ではソケットに複数のコアを搭載しているタイプが多いです。スレッドは、一連の命令が順番に処理されていく流れ(最小の処理単位)のことです。スレッドは、「LCPU」とも呼ばれます。仮想マシンはこのLCPUをあたかも自分が認識している”CPU”として扱います。では、物理のCPUと仮想マシンで認識するCPU = vCPUとの紐付きを確認していきましょう。

 

 

図2

 

上記の図2 1ソケットに4コアあるCPUでは、仮想マシンで構成できるvCPUの数は最大4つとなります。仮想マシンに割当てるvCPUは物理の持つコア数を超えない範囲で割当て可能です。例えば、1ソケット4コアを搭載している物理サーバの場合、その上で動作する仮想マシンに割当てられるvCPUの上限は4つになります。その上限の中で、各仮想マシンにvCPUの割り当てが可能になります。上の例ですと、向かって左からVM1,2にvCPUが4、VM3にvCPUが2、VM3にvCPUが1割当られ、合計11個のvCPUが割当てられてます。
※ハイパースレッドが有効な場合は、ハイパースレッドがLCPUとなります。

図2のように物理ソケットx1 コアx4コア構成で、仮想マシンに割当てられているCPU数(vCPU)合計は11個となっております。これがよく言われる仮想基盤特有の"オーバコミットされている状態"であり、物理リソースを有効にしようする為の考え方になります。

 

§2.どのように物理CPUが仮想マシンに割り当てられているのか?

では、実際にこの“仮想が物理を超えている状態”で内部的にはどのように動作しているのかを見ていきます。基本動作は、空いているLCPUをハイパーバイザがスケジュールしながら、仮想マシンに割当てしていく、というシンプルなものです。

ただし、vCPUに割当てられている全てのvCPUを必ず同時に割当てることを前提にすると、必要なvCPU数分のLCPUが空いていない割当てられない!事態になってしまいますが、そこはご安心ください。ハイパーバイザレベルで仮想マシンのCPU処理を矛盾なく行うよう最適化されております。オーバコミットの比率が高ければ高いほど、スケジューリングの処理が重くなってしまうこともありますので、まずは必要最小限のvCPU数で仮想マシンを構成することをおススメしております。

 

§3.vSphereにおけるリソースの扱い方~メモリ編~

次に、メモリリソースの扱い方をみていきましょう。
例として、800MBのメモリが割当てられている仮想マシンにアクセスします。「仮想マシン」→「監視」→「リソース割り当て」でメモリ情報をみると 「ホストメモリ」 と 「ゲストメモリ」 が見えてきます。

図4:ホストメモリとゲストメモリ

 

この「ホストメモリ」「ゲストメモリ」ちょっとわかりにくいのですが、例えていうならば、どこから仮想マシンを眺めるか?という目線だとイメージしやすいかもしれません。

ホストメモリ:ハイパーバイザから仮想マシンを眺めている目線
ゲストメモリ:仮想マシンの中で眺めている目線

この仮想マシンをPoweronして「ホストメモリ」の状態をみてみましょう。

図5:仮想マシンPoweron/ホストメモリ

 

消費:443MB、オーバヘッド 25MBとあります。これはこの仮想マシンが物理メモリを443MB使用している状態を示しています。(物理メモリ800MB丸々使用してるわけではありません!)オーバヘッドとはこの仮想マシンを動かすためのリソースであり、ハイパーバイザから眺めているからこそ見える値です。このオーバヘッドの値は仮想マシンの構成や負荷によって変動するものです。

 

図6:仮想マシンPoweron/ゲストメモリ

 

一方上の図は「ゲストメモリ」(=仮想マシンの中から眺めている)になりますが、図中の"プライベート"の値が418MBとなっております。これはちょうど443MBからオーバヘッドの値を引いた値となっておりますね。すなわち、純粋に仮想マシンが使用しているメモリ量です。そのプライベートをつかさどる値も 「共有」 「バルーン済み」 「圧縮済み」 「スワップ済み」 等から構成されております。それぞれをざっくりですが、簡単に紹介します。

共有:メモリページを仮想マシン同士で共有する仕組み 透過的ページシェアリング(TPS)
※ 共有(TPS)はバージョンによってデフォルトの設定が異なります。http://kb.vmware.com/kb/2097593
バルーン済み/圧縮済み/スワップ済み:仮想マシン同士でメモリを有効に再利用する仕組み
有効なゲストメモリ:現在アクティブ状態のメモリ値

メモリリソース用語の詳細は、以下のKBを参照ください

http://kb.vmware.com/kb/2017642

§4.メモリをより有効に活用する

CPUと同様、メモリも物理メモリ以上に仮想マシンにメモリを割当てることが可能です。下の例は検証環境なので、とても小さいESXiホストですが、物理メモリ約5GBを搭載しています。ここに仮想マシン割当てメモリ合計約7Gの仮想マシンがPoweronしております。

図7:オーバコミット状態におけるPoweron

ESXiホストの持つ物理メモリリソース(5GB) < 仮想マシンに割当てられたメモリリソースの合計 (7GB)

仮想マシンに割当てられたリソース量が、物理メモリリソースの合計値が上回ったとしても、それ自体が問題になることはありません。もちろん、"盛りすぎ"はパフォーマンスに影響がでてしまいますのでその辺をどう加減していくかが仮想基盤を有効使用していく為の肝になります。

このように仮想環境では、仮想マシンへのリソース割当てを実際の物理リソース以上に割当てることが可能となり、物理環境と比較して、より物理リソースを有効に使用できる仕組みを備えています。そこが仮想環境のメリットでもありますが、逆にリソース管理が難しい側面も持ち合わせております。

次回はリソース管理の仕組みを少しお話させてもらいますね♪

エンドユーザ様向けTech Day 2015のお知らせ

Techday2015
今年は2/10東京、2/13に大阪で開催!

VMware TechDay は、ユーザー企業・団体の方向けに認定教育コースの講師が実施する 1日の技術セミナーです。VMware vSphere を使用されている方や、評価を開始されている方を対象に、vSphere を使いこなすことで、その価値を十分に享受いただくことを目的としております。本ブログの内容もお話させていただきますので、ぜひご参加くださいネ!
※ユーザー企業・団体の方に限定させていただきます。あらかじめご了承ください。

VMwareテクニカルトレーナーよりワンポイントアドバイス
第1回:VMware vSphereにおけるCPU・メモリの考え方編
第2回:シェアと予約を押さえよう!