Home > Blogs > Japan Cloud Infrastructure Blog > 作成者別アーカイブ: isseikawasaki

作成者別アーカイブ: isseikawasaki

VMware Virtual SAN 入門 ~Virtual SAN のハード構成を考えよう~

みなさん、こんにちは!VMwareの川崎です。

VMware Virtual SAN 入門シリーズ第 4 弾となる本エントリでは、Virtual SAN の利用を検討され始める際に、ハード構成をどのようにして考えていけばいいのか、という点について書かせていただきます。”Virtual SAN Ready Node” という検証済み構成が準備されており、サーバ OEM ベンダーおよび VMware に推奨されておりますので、基本的にはこの中から要件に合うモデルをご選択いただければ、そのまま利用いただけます。

ただし、中にはご要望に応じたスペックとなるよう個別にカスタマイズされたい場合もあるかと思いますので、本エントリでは、前半で構成要件として抑えるべきポイント、後半で Virtual SAN Ready Node の探し方を記載いたします。

§1.構成要件

まずは、Virtual SAN を構成する際に検討すべき要件を整理していきましょう。

大きくは2点で、互換性とスペックになります。

§1-1.互換性

個別にコンポーネントを選定して構成する場合、サーバ、ストレージコントローラ(パススルー/RAID0)、SSD、HDD、ブートデバイス(USB、SD カード、HDD等)、NIC について、VMware vSphere または Virtual SAN との互換性を確認します。

図1は、vSphere を Virtual SAN を利用する場合、共有ストレージを利用する場合の確認項目を比較しています。注意点としては、Virtual SAN を利用される際は、ストレージコントローラ / SSD / HDD については Virtual SAN の該当バージョンとの互換性を確認する必要があります。(オールフラッシュ構成の際はHDD→SSDとなります。)

図1.互換性確認項目の比較

図1.互換性確認項目の比較

Virtual SAN との互換性を確認する際には、VMware の互換性ガイドを参照します。(ページへは、 こちら を選択後に ”Build Your Own based on Certified Components” を選択して移動します。vSphere との互換性を確認する際には、こちらより各コンポーネントごとにご参照ください。

§1-2.スペック

CPU、メモリ、ストレージ容量、ストレージ IOPS、ネットワーク帯域の要件を検討します。

  • ストレージ容量
    • キャパシティ階層
    • キャパシティ階層の容量は、実効容量をベースに、許容障害数を考慮して下記のようにトータルで必要となる物理容量を計算します。
    • 仮定:実効容量の20%はFTT=2, 80%はFTT=1のミラーリング
      → (トータル物理容量)=(実効容量)*20% *3 +(実効容量)*80% *2 + バッファ30%

      実効容量=2TB とすると、
      ( 2TB *20% *3 + 2TB *80% *2 ) / 70% = 6.29TB

    • **デザインガイドで 30% を空き容量として残すことが推奨されています。
    • なお、オールフラッシュ構成で 重複排除とデータ圧縮を有効にする際は、容量計算時に考慮ください。
      キャッシュ階層

      実効容量の10%を目安にキャッシュ容量を検討します。これは、必要とするスペックや想定されるIOに応じて容量を検討します。なお、ハイブリッド構成では、70% が Read、30% が Write に使われるのに対し、オールフラッシュ構成では 100% が Write に使われます。

  • ストレージIOPS
    • 必要とされる IOPS を見積もります。
  • CPU
    • 必要な CPU リソース容量を見積った上で、10% をオーバーヘッドとして見込みます。
  • メモリ
    • 必要な メモリ容量を見積った上で、以下の計算式でオーバーヘッドを見込みます。3GB (固定) + ディスクグループ数 * {500MB/ディスクグループ + [ 2MB /SSD GB (ハイブリッド) or 7MB/SSD GB (オールフラッシュ) ] * SSDサイズ }

      ディスクグループ1つ、ハイブリッドモード、SSD 400GBとすると、
      3GB + 1ディスクグループ * { 500MB + ( 2MB/GB * 400GB ) } = 4.3 GB

      ホストのメモリが 32GB を下回る場合、クラスタのホスト数が 32 を越える場合は、一部異なりますので、KB で詳細をご確認ください。
  • ネットワーク
    • ネットワークについては、仮想マシンに必要な帯域を検討した上で、Virtual SAN ネットワークの構成を決めます。ハイブリッドモードの場合は 1GbE の専用物理ネットワークアダプタまたは 10GbE の専用又は共有の物理ネットワークアダプタを利用します。オールフラッシュの場合は 10GbE の専用又は共有の物理ネットワークアダプタで構成します。

§2.Virtual SAN Ready Nodeとは

Virtual SAN のハードウェアは前節で記載した流れでハードウェア個別に選定することが可能ですが、Virtual SAN Ready Node という、テスト済み認定ハードウェアで構成された、Virtual SAN 用検証済みサーバ構成も準備されています。要件に合ったモデルを選択いただくことで、そのままの構成でご利用いただけます。Virtual SAN Ready Node は一覧としてこちらに記載があります。

§2-1.Virtual SAN Ready Node Configuratorの探し方

Virtual SAN Ready Nodeは、互換性ガイドから、Hybrid / All Flash、ESXi のバージョン、ベンダー等の項目を入力して検索することが可能です。

図2.Virtual SAN Ready Node の検索

図2.Virtual SAN Ready Node の検索

この際に、”Ready Node Profile” として、HY 2/4/6/8 または、AF 4/6/8 というシリーズを選択して検索すると、お好みに近いスペックの Virtual SAN Ready Node を見つけることができます。HY 2/4/6/8, AF 4/6/8 という各プロファイルにつきましては、AF がオールフラッシュ、HY がハイブリッドを表し、数字が大きいほどスペックが高い構成になっています。詳細はこちらにございますのでご参照ください。

§2-2.Virtual SAN Ready Node Configuratorの使い方

さて、前節でVirtual SAN Ready Nodeの検索では、検索条件に合致したReady Nodeを一覧で出力しておりましたが、これをスペックベースで選定していける構成のガイドサイトもございます。

図3.Virtual SAN Ready Node Configurator 画面

図3.Virtual SAN Ready Node Configurator 画面

こちらのサイトでは下記の5ステップで、Webページ上で選択していくだけで Virtual SAN Ready Node を選択していくことができます。

①Virtual SANのバージョンを選択します。これは ESXi のバージョンと一対一に対応します。

図4.Virtual SAN のバージョン選択

図4.Virtual SAN のバージョン選択

②プロファイルを AF 4/6/8, HY 2/4/6/8から選択します。AF は All Flash(キャッシュもキャパシティも SSD )、HY はハイブリッド(キャッシュは SSD、キャパシティは HDD )を表します。プロファイルの選択の際には、物理ストレージ容量やキャッシュサイズ、IOPS、サーバとしての CPU、メモリ容量が表示されますので、これをもとに選択できます。

図5.プロファイル選択

図5.プロファイル選択

プロファイルを要件ベースで直感的に選択したい、という場合には ”Profile Selection Wizard” からプロファイル選択のウィザードを開始します。

図6.プロファイル選択ウィザード

図6.プロファイル選択ウィザード

こちらは図のように、CPUのコア数、メモリ容量、ノードあたりの実効容量、IO 負荷のレベルを選択することで、該当するプロファイルを自動的に選択します。ただし、完全に合致するプロファイルは存在しない場合もありますので、選択されたプロファイルのスペックはよくご確認ください。

図7.プロファイル選択済みの状態

図7.プロファイル選択済みの状態

③OEMベンダーを選択します。

図8.ベンダー選択

図8.ベンダー選択

④これまでに選択した条件に合致するモデルが一つまたは複数表示されますので、詳細を確認して希望のモデルを選択します。

図9.モデル選択

図9.モデル選択

⑤”Download Configuration” ボタンから、選択したモデルをPDFファイルでダウンロードできます。

図10.構成のダウンロード

図10.構成のダウンロード

PDFファイルには選択したモデルの詳細が記載されておりますので、保存して検討材料にしていただけます。

図11.ダウンロードされたPDFファイル

図11.ダウンロードされたPDFファイル

**上記では、Virtual SAN Ready Node を探しましたが、Virtual SAN Ready Node を元にカスタマイズしていただくことも可能です。一から構成するよりも互換性の確認が簡単になりますので、大枠は踏襲しつつスペックなどは合うように調整するのがお勧めです。カスタマイズを行った分につきましては改めて互換性の確認をお願いいたします。

§2-3.より詳細なサイジング

より詳細にサイジングを検討したい場合には、“Virtual SAN TCO and Sizing Calculator”というサイトが提供されておりますので、こちらで詳細を検討いただくことも可能です。

§おわりに

ハードの選定が終わってしまえば、構築や拡張は容易に可能な Virtual SAN ですが、はじめての導入ではそもそも何をどう選定すればいいのかも不明確な部分があるかと思います。本エントリでは、基本的なハードウェア選定の流れと、それを大幅に簡略化する ”Virtual SAN Ready Node” を紹介いたしました。Virtual SAN の導入検討の敷居が少しでも下がれば幸いです。

VMware SE 川崎一青

VMware VSAN 入門:
1/4 〜 従来のストレージと VSAN の違い 〜
2/4 〜 信頼性と性能編 〜
3/4 〜 VSAN オンラインハンズオンラボをやってみよう 〜

4/4 〜 VSAN のハード構成を考えよう〜

 

ネットワーク仮想化をネットワークの基本から理解する 第3回:分散ルーティング – Layer3 の世界

■はじめに

こんにちは、パートナーSEの川崎です。本シリーズでは、前回に引き続きネットワーク仮想化をネットワークの基本から理解するという姿勢で、物理環境と比較しながら進めます。第3回となる今回はレイヤ3のルーティングに関して見ていきます。

■  はじめに
■  物理ネットワーク環境におけるルーティング
■  ネットワーク仮想化環境における分散ルーティング
■  物理ネットワーク環境とネットワーク仮想化環境の比較
■  補足情報

 

■はじめに

データセンターにおけるネットワークでは、East-West トラフィックと呼ばれるサーバ間の水平方向の通信が、トラフィック量全体の約7 割を占めていると言われています。分散ルーティングは、ハイパーバイザ内でルーティングの処理を行うことで、この East-West トラフィックを最適化します。

従来のルーティングテーブル(左)と分散ルーティング(右)

従来のルーティングテーブル(左)と分散ルーティング(右)

分散ルーティングの設定は、VMware NSX の管理画面から行います。物理サーバや物理ネットワーク機器数十台にまたがるような分散ルーティング環境を構成する際も、個々の物理コンポーネントに設定を行う必要はありません。

分散ルーティング環境を構成するためには、論理ルータコントロールVMと呼ばれるコンポーネントを作成します。論理ルータコントロールVM は、 NSX Edge の構成ウィザードから、インストールタイプを「論理(分散)ルータ」として構成します。

論理ルータコントロールVM の作成

論理ルータコントロールVM の作成

論理ルータコントロールVM に設定したインターフェイスやルーティングの情報は、各 VMware ESXi ホストに展開されます。例えば論理ルータコントロールVM にルーティング設定を追加すると、その情報が各 ESXi ホスト内の論理ルータカーネルモジュールに展開されることになります。

 

ルーティング情報の展開

ルーティング情報の展開

上述の通り分散ルーティングに関する設定はGUI から簡単に行うことができますが、APIを介した設定も可能であり、CMP(クラウドマネジメントプラットフォーム)と連携することで設定作業を自動化できます。

■物理ネットワーク環境におけるルーティング

分散ルーティングの説明に入る前に、物理ネットワーク環境でのルーティングの説明を行います。

 

物理ネットワーク環境におけるルーティング

物理ネットワーク環境におけるルーティング

ネットワーク環境において、異なるネットワークセグメント内に存在する端末間で通信を行なう場合を考えます。端末A と端末C はそれぞれ、172.16.10.0/24, 172.16.20.0/24のネットワークに存在し、物理ルータ(L3SW)に接続されています。異なるネットワークセグメント間の通信では、ルータによるルーティング処理が行なわれます。

ルーティングを行うのは、ネットワーク機器だけではありません。端末A(172.16.10.11/24) が端末C(172.16.20.11/24) と通信を行うとき、最初に端末A は端末C が異なるサブネットにいることを認識します。端末A は、自身のルーティングテーブルを参照し、デフォルトGW であるルータにトラフィックを転送します。

ルータはそれぞれのネットワークセグメントにインターフェイスF0, F1 を持ち、受信した通信を、別のインターフェイスから送信します。送信するインターフェイスを決定する際にルーティングテーブルを参照します。実際にルータのルーティングテーブルを確かめてみましょう。

> show ip route
C 172.16.10.0/24 is directly connected, F0
C 172.16.20.0/24 is directly connected, F1
S 0.0.0.0/0 via <外部ルータIP>

 

端末C(172.16.20.11)の所属する172.16.20.0/24 は、ルータのインターフェイス F1 に直接接続していることが確認できます。ルータは、インターフェイス F1 から端末C にパケットを転送します。

物理ネットワーク環境では、物理ルータがルーティングテーブルを持ち、単一のポイントでルーティング処理を実施します。また、複数の物理デバイスがある場合は、個々のデバイスに対して設定作業を行うことになります。

ルーティングの考え方及び、端末側の動作はネットワーク仮想化環境になっても変わりませんが、ネットワーク仮想化環境では物理ルータの持つルーティング機能を、分散ルーティングとしてハイパーバイザに実装することができます。分散ルーティングのアーキテクチャについて、「ルーティングテーブル」に注目する形でこの後見ていきます。

 

■ネットワーク仮想化環境における分散ルーティング

ネットワーク仮想化環境でのルーティングを見ていきます。サーバ仮想化環境であっても通常の構成であれば、ルーティング処理は外部のルータで行われることになります。これに対し、分散ルーティングが有効な環境では、各 ESXi ホスト内に論理ルータカーネルモジュールが配置され、ホスト内でルーティング処理を行うことが可能になります。

 

ネットワーク仮想化環境における分散ルーティング

ネットワーク仮想化環境における分散ルーティング

上記は、2台の ESXi ホストが存在し、ネットワーク仮想化と分散ルーティングが有効となった環境を表しています。各 ESXi ホスト内に論理ルータカーネルモジュールが構成され、2つのネットワークが接続されています。論理ルータカーネルモジュールはルーティングテーブルを持ち、異なるL2ネットワーク間の通信が行なわれる際にルーティング処理を行ないます。

分散ルーティングの動作

分散ルーティングの動作

実際に分散ルーティングが行なわれる状況を見てみましょう。上記は同一の ESXi ホスト上に存在する2つの仮想マシン VM-A、VM-C が通信を行なう様子を示しています。VM-A は VXLAN 5001 (172.16.10.0/24) に接続、VM-C はVXLAN 5002 (172.16.20.0/24) に接続しているため、2つの仮想マシン間で通信するためにはルーティングが必要です。VM-A から送信されるパケットは ESXi ホスト内の論理インターフェイス(LIF)を宛先とする L2 ヘッダがつけられて送信され、論理ルータカーネルモジュールに届きます。論理ルータカーネルモジュールは受け取ったパケットをルーティング処理し VM-C  に届けます。

では、実際に分散ルーティング環境のルーティングテーブルを確認しましょう。ここではテーブルの情報がどこから共有されてくるか、という点を確認するために、論理ルータコントロールVM、NSX コントローラ、各 ESXi ホスト内の論理ルータカーネルモジュールそれぞれについてルーティングテーブルを確認します。

論理ルータカーネルモジュールの持つルーティング情報は、論理ルータコントロールVM に設定した論理インターフェイス(LIF)情報、静的に設定されたルーティング情報、動的に得られたルーティング情報が基になっています。論理ルータコントロールVM の論理インターフェイスと静的なルーティングは vSphere Web Client から設定することができ、この情報は NSX Manager を介して論理ルータコントロールVM に伝えられます。動的ルーティングについては、論理ルータコントロールVM が外部のルータとダイナミックルーティングプロトコル(OSPF, BGP)を介して情報を交換します。

分散ルーティング環境でのルーティング情報の伝達

分散ルーティング環境でのルーティング情報の伝達

このようにして得られた論理ルータコントロールVM の持つルーティングテーブルを示します。

 

> show ip route
S      0.0.0.0/0      [1/1]  via <外部ルータIP>
C      172.16.10.0/24 [0/0]  via 172.16.10.254
C      172.16.20.0/24 [0/0]  via 172.16.20.254

ルーティングテーブル(論理ルータコントロールVM)

 

論理ルータコントロールVM が得たルーティングテーブル情報は、NSX コントローラクラスタを介して各 ESXi ホストに伝えられます。コントローラクラスタは役割を分担しており、ある論理ルータコントロールVM のルーティングテーブルはその管理を担う NSX コントローラ のみが持ちます。該当 の NSX コントローラ から、ルーティングテーブル情報を確認できます。

 

# show control-cluster logical-routers routes 0x570d4554
LR -Id      Destination      Next-Hop[]      Preference
0x570d4554  0.0.0.0/0        <外部ルータIP>   1

ルーティングテーブル(NSX コントローラ)

 

# show control-cluster logical-routers interface-summary 0x570d4554
Interface                        Type   Id           IP[]
570d455400000002                 vxlan  0x1388       172.16.10.254/24
570d45540000000a                 vxlan  0x138d       172.16.20.254/24

論理インターフェイス(NSX コントローラ)

 NSX コントローラが持つルーティング情報が各 ESXi ホスト内に存在する論理ルータカーネルモジュールに配信されます。

 

# net-vdr --route default+edge-2 -l
Destination      GenMask         Gateway        Flags   Ref Origin  Uptime     Interface
-----------      -------         -------        -----   --- ------  ------     ---------
0.0.0.0          0.0.0.0         外部ルータIP    UG      1   AUTO    1960358    570d455400000002
172.16.10.0      255.255.255.0   0.0.0.0        UCI     9   MANUAL  1971591    570d45540000000a
172.16.20.0      255.255.255.0   0.0.0.0        UCI     1   MANUAL  1971560    570d45540000000b

ルーティングテーブル(ESXi ホスト)

(補足)上図「分散ルーティング環境でのルーティング情報の伝達」の構成では、論理ルータコントロールVM が、外部ルータに対し、OSPF 経由で内部ネットワーク情報(172.16.10.0/24 及び172.16.20.0/24)を通知しています。これにより、外部ネットワークと内部ネットワーク間の通信が可能になります。

 

■物理ネットワーク環境とネットワーク仮想化環境の比較

物理ネットワーク環境とネットワーク仮想化環境について、ルーティングの面で比較します。

 

物理と仮想の比較

物理と仮想の比較

物理ネットワーク環境では、ルーティングテーブルは物理ルータが持ち、単一のポイントでルーティング処理を実施していました(集中処理)。また、複数の物理ルータがあるような構成では個々のハードウェアに対して設定作業を行うことになります(分散管理)。

一方でネットワーク仮想化環の分散ルーティングは、ハイパーバイザ内でルーティングテーブルを分散して持つことで、複数のポイントでルーティング処理を実施します。

ポイント1 ハイパーバイザでルーティング情報を持ち、同一 ESXi ホスト上の仮想マシン間のルーティングはホスト内で処理することができるため、East-West トラフィックを最適化できる(データプレーンにおける分散処理)

各ハイパーバイザの持つルーティングテーブルの制御は、論理ルータコントロールVM 及び NSX コントローラクラスタで集約して行います。

ポイント2 論理ルータコントロールVM 及び NSX コントローラクラスタでルーティング情報を集中して制御することにより、複数のハイパーバイザ間でルーティングテーブルを共有することができる(コントロールプレーンにおける集中制御)

分散ルーティング環境のセットアップは、NSX Manager を介して、GUI もしくはAPI 経由で簡単に行うことが出来ます。

ポイント3 NSX Manager から一括して設定管理を行うことで、運用管理性を損なうことなく容易に実装できる(マネジメントプレーンにおける集中管理)

ネットワーク仮想化環境における分散ルーティングは、分散処理、集中制御、集中管理のアプローチをとることで、運用管理性を維持しつつ、効率よく East-West トラフィックを処理することを可能にしています。

 

■ 補足情報 分散ルーティングを提供する VMware NSX のコンポーネント

分散ルーティング環境で、NSX を構成する各コンポーネントがどういった役割を果たしているのか解説を行います。

 

 NSX を構成するコンポーネントの役割

NSX を構成するコンポーネントの役割

・NSX Manager(マネジメントプレーン)

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

・NSX コントローラクラスタ(コントロールプレーン)

NSX コントローラクラスタは、現時点で3台の仮想アプライアンスで構成することを推奨しており、分散ルーティング環境において、各種情報(論理インターフェイス、ルーティングテーブル)を集中管理するポイントになります。後述の論理ルータコントロールVM 毎に担当するコントローラが決められ、例えば2つのテナントがある場合、論理ルータコントロールVM (テナントA)はコントローラ1番、(テナントB)はコントローラ2番というように役割が割り当てられます。テーブル情報は、担当するコントローラのみが保持します。

 

マルチテナント環境でのルーティングテーブルの扱い

マルチテナント環境でのルーティングテーブルの扱い

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

# show control-cluster logical-routers instance all
LR-Id      LR-Name            Hosts[]         Edge-Connection Service-Controller
0x570d4554 default+edge-2     192.168.210.51                  192.168.110.201
192.168.110.52
192.168.110.51
192.168.210.52
192.168.210.56
0x570d4553 default+edge-3                                     192.168.110.202

この出力結果から、論理ルータコントロールVM のインスタンスが2つあることが分かります。default+edge-2(0x0x570d4554)は、192.168.110.201 が管理し、default+edge-3(0x570d4553)は、192.168.110.202 のコントローラが管理していることが分かります。論理ルータの情報を見るためには該当のコントローラにログインする必要があります。(192.168.110.201 のコントローラで情報を出力しているため、自身の担当しているインスタンス default+edge-2 に関連する ESXi ホストの IP 情報が出力されています)

論理ルータ default+edge-2(0x0x570d4554)の管理するルーティングテーブルの確認

# show control-cluster logical-routers routes 0x570d4554
LR-Id       Destination        Next-Hop[]         Preference
0x570d4554  0.0.0.0/0          192.168.10.1       1

論理ルータdefault+edge-2(0x0x570d4554)の管理する論理インターフェイスの確認

# show control-cluster logical-routers interface-summary 0x570d4554
Interface                        Type   Id           IP[]
570d455400000002                 vxlan  0x1388       192.168.10.5/29
570d45540000000a                 vxlan  0x138d       1.1.1.254/24

 

・論理ルータコントロールVM(コントロールプレーン)

論理ルータコントロールVMは分散ルーティング環境において、ルーティングの処理を集中して行うための仮想アプライアンスです。設定したスタティックルーティング情報や、ダイナミックルーティングプロトコル(OSPF, BGP)経由で外部のネットワーク機器から学習したルーティング情報を、コントローラクラスタ経由でESXi ホストに配信します。

 

論理ルータdefault+edge-2(0x0x570d4554)の管理するルーティングテーブルの確認

> show ip route
S      0.0.0.0/0        [1/1]    via 192.168.10.1
C      192.168.10.0/29  [0/0]    via 192.168.10.5
C      1.1.1.0/24       [0/0]    via 1.1.1.254

 

論理ルータコントロールVM はテナント単位(ルーティングテーブルの管理単位)で複数たてることができます。

 

・論理ルータカーネルモジュール(データプレーン)

NSX 環境を構築する際、ホストの準備のステップで各 ESXi にインストールされるカーネルモジュールとなります。VIB(vSphere Installation Bundle)ファイルとしてインストールされ、カーネルモジュール(vdrb)としてロードされます。カーネルモジュールは、ハイパーバイザ内で論理ルータのテーブルの管理とルーティング処理を行います。

 

論理ルータ default+edge-2(0x0x570d4554)の管理するルーティングテーブルの確認

# net-vdr -l --route default+edge-2
VDR default+edge-2 Route Table
Legend: [U: Up], [G: Gateway], [C: Connected], [I: Interface]
Legend: [H: Host], [F: Soft Flush] [!: Reject] [E: ECMP]

Destination      GenMask          Gateway          Flags    Ref Origin   UpTime     Interface
-----------      -------          -------          -----    --- ------   ------     ---------
0.0.0.0          0.0.0.0          192.168.10.1     UG       1   AUTO     1724       570d455400000002
1.1.1.0          255.255.255.0    0.0.0.0          UCI      1   MANUAL   1832038    570d45540000000a
192.168.10.0     255.255.255.248  0.0.0.0          UCI      1   MANUAL   2701981    570d455400000002

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

ハイパーバイザと NSX コンポーネント間のコネクション

ハイパーバイザと NSX コンポーネント間のコネクション

コントローラクラスタとの接続確認

# 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

 

上記出力より、ESXi ホストの管理用 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

 

上記出力より、ESXi ホストの管理用IP アドレスから NSX Manager に、vsfwd を介して接続していることが確認できます。NSX Manager からはコントローラのIP アドレス情報を取得します。

なお、論理ルータコントロールVM をホストしているESXi は、VMCI (Virtual Machine Communication Interface) と呼ばれる仮想マシン-ハイパーバイザ間専用のパスを使用し、ルーティング情報を論理ルータコントロールVM から取得、ESXi が取得した情報をコントローラに netcpa 経由で通知します。コントロールプレーンの通信に論理ルータコントロールVM の管理インターフェイスは使用しません。

ルーティング情報の取得と配布

ルーティング情報の取得と配布

・NSX Edge (データプレーン)

仮想アプライアンスとして提供され、単体で各種ネットワークサービス機能(ロードバランサ、ルーティング、NAT、ファイアウォール、VPN、 DHCP 等)を提供する「スイスのアーミーナイフ」のようなコンポーネントです。従来の物理のネットワーク機器が仮想アプライアンスとして置き換わったイメージです。外部ネットワーク機器として論理ルータコントロールVM とダイナミックルーティングプロトコルを使用しルーティング情報を交換する場合がありますが、論理ルータの提供する分散ルーティングの機能そのものには直接関与しません。

 

■コラム

新卒から見たネットワーク仮想化

当初ネットワーク仮想化と聞いて非常に難しそうに感じました。サーバ仮想化もまだ勉強中であり、ネットワークについてはさらに知っていることが少ない状態です。しかしながら、いざ勉強を進めていくと、中心となる L2、L3 の通信はテーブルを参照してパケットが流れていくという点では物理環境とほとんど変わりませんでした。実際、物理ネットワークと比較して抑えていくことで、ネットワーク仮想化が物理ネットワークの再現であり、仮想マシンや流れるパケットからすれば同様に動作できる環境が作られていることがわかってきました。NSX には Manager やコントローラ、論理ルータコントロールVM など複数のコンポーネントがありますが、それぞれの持つ役割を把握することで、スムーズに理解していけるように感じます。皆様もぜひご一緒にネットワーク仮想化を学んでいきましょう。

 

■関連リンク

今回ご紹介した内容をオンラインのハンズオン環境上で確認することができます。コマンドラインの出力はハンズオン環境をベースに作成しています。

http://labs.hol.vmware.com/HOL/

VMware HOL Online

HOL-SDC-1403 – VMware NSX Introduction

 

NSX の機能全般及び、ネットワーク仮想化環境の設計に興味のあるかたは下記テックペーパーを参照ください。

http://www.vmware.com/files/pdf/products/nsx/vmw-nsx-network-virtualization-design-guide.pdf

VMware® NSX for vSphere (NSX-V) Network Virtualization Design Guide

 

ネットワーク仮想化をネットワークの基本から理解する

第1回:理解するために必要なことを整理する

第2回:論理スイッチ(VXLAN)–Layer2 の世界

第3回:分散ルーティング –Layer3 の世界(本稿)

第4回:分散ファイアウォール -Layer4 の世界

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 を使いこなしていただけたらと思います。最後までお読みいただきありがとうございます。

新卒 SE 社員が贈る vSphere のキソ! 第7回 ~ 仮想環境となが〜くお付き合いしていくために ~

こんにちは! とうとう本連載もラストとなってしまいました。 新卒 SE 社員が贈る vSphere のキソ! 第7回は私、川崎( Kawasaki )が担当致します。 今回は、「仮想環境となが〜くお付き合いをしていく」をテーマといたしまして、 VMware vRealize Operations Manager (以下 vR Ops)という製品をご紹介して参ります。

〜仮想環境と長くお付き合いする為に…〜

はじめに、環境の運用管理とは何ができれば上手く行えていると言えるでしょうか。状況を正確に把握し、効果的なアクションをとり、より少ないコストで効率的にパフォーマンスを高く維持できれば、良い運用が行えていると言えるのではないでしょうか。この「状況を正確に把握する」という部分が、物理環境から仮想環境へ移行した際に少し難しくなるポイントです。

 

図1.物理環境と仮想環境でのリソース使用の比較

図1.物理環境と仮想環境でのリソース使用の比較

 

本連載の過去の記事でも触れておりますが、仮想環境ではリソースが仮想化され、複数のOSで同一の物理ホストのリソースを共有します。また、物理ホスト間でもリソースをプール化して、全体としての最適な利用が行える点を紹介して参りました。

仮想環境ではゲストOSから見てリソースの使用率が高くないか、だけではなく、他のOSとはリソースの取り合いによるパフォーマンス低下はどれほどか、物理サーバ間でのリソース融通による最適化の機会はないか、といったことも考える必要があります。実際、既に仮想環境をご利用いただいているお客様の中にも、管理に課題を感じていらっしゃる方は多く、以下のようなお声を頂いております。

      公共系 A機関 ご担当者様

「どの物理サーバでどの仮想マシンが稼働しているかをExcelで管理していましたが、何かが起こった際の影響範囲の特定が非常に困難でした。また、一部のシステムでパフォーマンスが落ちてきた場合に、リソースが不足しているのか、アプリケーションに問題があるのかなどの切り分けが困難で、原因究明までにかなりの時間を要していました。」

      メディア系B社 ご担当者様

仮想マシンの配置やキャパシティプランニングはすべてExcelを使って手作業で行っており、非常に手間がかかっていました。さらに仮想マシンで必要となるリソースの割り当てについても、妥当性の基準が明確化されておらず、システムの健全性やリソース配分の効率性を評価できていませんでした。」

これらのお客様には、vR Ops を導入いただき、こういった課題の解決に役立ていただきました。まずは、vCenter と vR Ops での管理方法を比較することで、vR Ops はどのように役に立つのか見ていきましょう。

 

〜vCenterのみでOK?〜

vCenter のみの場合と vR Ops も利用した場合、どのように変わるか、参考ケースを見ながら比較していきます。

≪参考ケース≫
IT管理者のAさんは、 vSphere をベースとした仮想環境の管理を任されています。担当している物理サーバの数は20台ほどですが、仮想マシンのパフォーマンスが悪い場合には、まずAさんが問題を切り分けて、必要に応じてネットワークやストレージ、アプリケーションの各担当者に連絡して対処をお願いしています。

物理から仮想に移行したことで、追加のハードウェアなしにサーバ数を増加させることができ重宝していますが、最近仮想マシン数の増加とともに環境が複雑になり障害原因の特定に時間がかかるようになってきました。また、来年の予算を考えるにあたって追加リソースの申請が必要ですが、仮想マシンごとに負荷も違うためどう考えればいいかわかりません。

  • 障害原因の特定

ここでは、障害原因の特定を行う際を例にとり、管理方法の変化を見てみます。障害の発生を確認した場合の対処までの流れについて、vCenter Server のみを用いた場合と、vR Ops を用いた場合を比較します。全体の流れの一例を示したのが、図2です。

 

図2.障害対応方法の違い:vSphere Web Client と vC Ops

図2.障害対応方法の違い:vSphere Web Client と vC Ops

 

vCenter Server の管理画面である vSphere Web Client や vSphere Client からもホストや仮想マシンに関する様々な情報を収集することは可能です。しかしながら、その情報は多岐にわたるため、広範囲な参照先から得た情報を管理者が統合して判断に結び付ける必要があります。一方で、vR Ops を用いた場合には、障害の監視、関連オブジェクトの参照、各オブジェクトの詳細情報が一括して得られるような設計となっているため、管理者の判断を助け、対処にとりかかるまでの時間も短縮できます。

  • キャパシティ管理

次に、リソースを追加する際の容量計算の流れを例に、キャパシティ管理方法の違いを見ます。同様に vCenter Server のみを用いた場合とvR Ops を用いた場合を比較します。(図3)

 

図3.キャパシティ管理方法の違い:vSphere Web Client と vC Ops

図3.キャパシティ管理方法の違い:vSphere Web Client と vC Ops

 

vCenter Server を用いた場合、多くの状況ではそのデータをExcel等で集計しなおすことが多いのではないでしょうか。ホストや仮想マシンの割り当て容量をExcelに集計し、vCenter Server で得られるパフォーマンス情報とユーザーからのヒアリングを元に適切な容量を考えます。

そして、それをもとにキャパシティ不足の仮想マシンや追加の仮想マシン用のリソースを計算します。このような流れの問題点は、Excelでの管理に時間がかかる点、また、本当に必要な容量を知ることはかなり困難で、結局のところ安全策として必要以上のリソース割り当てとなりがちな点です。

一方で vR Ops を用いた場合には、現状の把握はダッシュボードから一目瞭然で、適切な容量の計算も、ホストとしては残り容量の表示が、仮想マシンとしてはサイジングの過不足に関する表示があり、クリックするだけで、一覧で見ることができます。

また、追加リソースに関しては、推奨されるオーバーコミット率に従って考え、実際に任意のサイズの仮想マシンとリソースを追加して試算を行うことで、必要な容量であることを簡単に知ることができます。最後にこれらの情報をファイルとして出力して説明の根拠とすることができます。

 

以上まとめますと、vCenter Server のみを用いた仮想環境の管理では、以下の2つの課題がありました。

①  vCenter Server だけでは長年の経験と専門スキルを要する (工数と時間がかかる理由)

② 運用メンバーの管理手法が属人化している (人手で集約・集計している結果)

そしてこれらの課題を vR Ops は次のように解決します。

①  vR Ops 上の表示の確認で済む (工数と時間を短縮)

②  vR Ops が自動で集計・分析する (工数の削減と根拠の明確化)

 

〜vRealize Operations Managerの概要〜

それでは、 vR Ops自体の説明に入って参ります。はじめに、 vR Ops を導入した場合の環境構成から説明いたします。 vR Ops は1つの仮想アプライアンスが展開され、 vCenter Server から収集したデータを解析し、表示します。(図4) vCenter Server は一つまたは複数を対象とすることができます。

図4.vCenter Operations Manager の構成

図4.vCenter Operations Manager の構成

集めたデータは、 vR Ops で解析されます。この解析により、各リソースの数値データは単にグラフ化されるのではなく、仮想環境は良いパフォーマンスを発揮しているのか、何かとるべきアクションはあるのか、といった管理者にとって役立つ情報として表示されます。ダッシュボードと呼ばれる vR Ops の基本画面は以下のような見た目となっております。(図5)

図5. vC Ops ダッシュボード画面

図5. vC Ops ダッシュボード画面

このダッシュボード画面は、左から“健全性”、“リスク”、“効率”の縦3列に分かれており、それぞれ以下のような内容を表しています。

  • 健全性  :「現在の状況」    障害やパフォーマンス低下について
  • リスク    :「将来の予測」    = 今後のパフォーマンス低下要因はないか、リソースは十分か
  • 効率     :「構成の最適化」         = 構成を変更することで、リソース節約の可能性はあるか

これらの指標(“バッジ”と呼びます)によって、管理者はひと目で環境の特徴を把握できますし、必要であれば詳細な情報も掘り下げて見ていくことも可能です。例えば、ある仮想マシンについて性能劣化の要因を調べる際には、関連するオブジェクトを一括して表示することで、どこに原因があるか突き止める大きな助けとなります。(図6)

図6.関連するオブジェクトを一括表示

図6.関連するオブジェクトを一括表示

また、個別のオブジェクトに関してそれ自体の情報を詳細に見る、という意味では、図7のような画面から確認できます。

図7.個別オブジェクトの詳細情報表示

図7.個別オブジェクトの詳細情報表示

他にも vR Ops では俯瞰的な見方から、詳細に特化した見方まで、情報の表示のされ方は豊富に用意されています。これにより、実際の運用管理の場面でも、その時々の目的に応じた情報を得ることが可能となります。   このような vR Ops の機能は、評価版を展開して実際にご使用いただくことで、さらによく確認していただけます。評価版のインストールガイドは操作ガイドとともにリンク先の記事にございますので、ぜひご活用ください。

http://blogs.vmware.com/jp-cim/2014/07/vcops_operations_guide.html

vR OpsとvSOM〜

vSOM という製品をご存知でしょうか? vSOM は、「 VMware vSphere with Operations Management 」の略で、 vSphere と vR Ops のスタンダードエディションが合わさったものになっています。(図8)vR Ops のライセンスは通常「25仮想マシン数単位のライセンス」に対し、 vSOM のライセンスは vSphere 同様CPU単位のライセンスとなります。したがって、vC Ops を利用される際に、「仮想マシン数が将来増加する可能性もあるなぁ…」という場合には、vSOM を入手することで仮想マシン数を意識する必要はなくなります。

図8.vSOM は vSphere と vC Ops のセット製品

図8.vSOM は vSphere と vC Ops のセット製品

詳細は弊社ウェブページをご覧ください。(http://www.vmware.com/jp/products/vsphere-operations-management/

〜第7回まとめ〜

vRealize Operations Manager を紹介して参りましたが、いかがでしたでしょうか?本製品のことが少しでも理解され、使うことによるメリットも感じていただけましたら幸いです。こちらの製品は、ハンズオンラボでも体験可能ですので、ぜひお試しください。(http://labs.hol.vmware.com/HOL/catalogs/  ラボ番号:HOL-SDC-1401)

〜本連載まとめ〜

さて、本シリーズは「新卒 SE 社員が贈る vSphere のキソ!」と題しまして、4名の新卒SEにより全7回でお贈りして参りました。”新入社員の目線”として先輩SEの皆様とは多少異なるテイスト?で連載して参りましたがいかがでしたでしょうか?何はともあれ、本シリーズを通じて少しでもVMware製品の理解を深めていただけましたらとても嬉しいです。

私どもは今年の4月に入社しほぼ知識がないところからのスタートでした。VMwareに関する勉強には少なからず苦労しておりますが、わかってくると楽しく、ついつい時間が過ぎてしまうこともしばしばです。今後初めてVMwareを導入されるユーザ様や提案されるパートナー様におきましては、新しい概念や用語で苦労されるかもしれません。

その際は本連載を読み返していただくと幸いです。私たち自身も日々勉強することも多いですが、皆様のご指導も受けながら一緒に盛り上げていけましたらとても嬉しく思います。vForum 2014でもセッションを持ちますので是非お越しください!

最後になりましたが、お読みいただき誠にありがとうございました。
VMware新卒社員 SE 氏田裕次/川崎一青/椨木正博/野田裕二

新卒 SE 社員が贈る vSphereのキソ!
第1回 vSphereを俯瞰する
第2回 仮想環境におけるネットワークとストレージ
第3回 vMotionとvSphere HA/vSphere FTの違いとは?
第4回 仮想マシンの配置管理はDRSにお任せ!
第5回 様々な仮想マシンが混在&混雑しても大丈夫!?ネットワーク と ストレージの帯域を維持する仕組み
第6回 vSphere でココまでできる!データ保護
第7回 仮想環境となが〜くお付き合いしていく
第8回 ( 追加編 ) まだまだあった!ストレージ関連機能

新卒 SE 社員が贈る vSphere のキソ!第3回~vMotionとvSphere HA/vSphere FTの違いとは?~

こんにちは!

毎週恒例となって参りました 新卒 SE 社員が贈る vSphere のキソ! 第3回である今回は私、川崎( Kawasaki )が担当致します。

今回扱うのは、 vSphere の持つ機能のうち、 vMotion と vSphere HA (以下HA) / vSphere FT (以下FT) です。これらの機能は少し紛らわしい部分がありますので、その違いをクリアにしていきたいと思います。

 

ずばり vMotion と vSphere HA の違いとは!?

はじめに、ずばり vMotion と HA の違いは何か、どんな時に使う機能なのか、ということから触れていきたいと思います。まずは、それぞれがどんな場合に有用な機能なのか見てみましょう。

vMotion の使い時

    •  例えば…物理サーバにCPU予防交換の必要があるため一度停止したいが、そこで稼動しているサービスは平日には止めることができない。土日に出勤してメンテナンス作業を実行する必要がある。
    • 例えば…負荷分散の最適化のためにシステムの構成を変更したいが、日中は仮想マシンを停止できない。夜間に一度仮想マシンを停止して、別の物理サーバに移行することで適正な負荷バランスにしよう。
      ⇓  これが vMotion を用いると…
  • 稼働中の仮想マシンを別物理サーバに移行でき、仮想マシンで動いているシステムを止めずに、物理サーバのメンテナンスや負荷分散が可能!

HA の使い時

    • 例えば…物理サーバが障害で停止してしまったため、その上で動いていたサービスも停止してしまった。早急に復旧が必要だが、データセンターまで出向いての対応には多くの時間を要する。
    • 例えば…仮想化はしたものの、突発的な障害に対処するため土日昼夜を問わず監視をしている。
      ⇓  これが HA を用いると…
    • 月曜の朝来たら物理ホストが一台、障害により停止していた。しかしながら、 HA の機能により全ての仮想マシンは別ホストで問題なく稼動しており、IT管理者は余裕を持って対応できた♪

これらのケースからも読み取れるように、 vMotion は計画的な物理サーバの停止に対応する機能である一方、 HA は非計画的な物理サーバの障害に対応して可用性を確保する機能です。したがって、 vMotion は物理サーバのメンテナンスなど計画的に物理サーバを停止する必要がある場合に使用する移行機能であるのに対し、 HA は機能としては常に有効にしておき、いざ物理サーバに障害が起きた際に自動で保護してくれる復旧の仕組みとなります。

では、それぞれの機能の詳細を見て参りましょう。

 

vMotion ~仮想マシンのホット移行~

vMotion は、起動している仮想マシンをシャットダウンすることなく、動かしたまま別の物理サーバに移動する機能です。(図1)起動したままの移行ということで、”ホット移行”とも表されます。

図1. vMotionによる仮想マシンのホット移行

図1. vMotionによる仮想マシンのホット移行

この vMotion による仮想マシンの移行は、管理画面から仮想マシンを指定し、図2のようなウィザードに従って進めることで数クリックの簡単な操作により完結することができます。(詳細はオンラインラボ、NEE HOL-SDC-1310 http://labs.hol.vmware.com/HOL/catalogs/ でいつでもご確認できます!)

図2. vMotion による移行は数クリックで完了

図2. vMotion による移行は数クリックで完了

 vMotion の機能は、ホストの定期メンテナンスや一部パーツの交換等で、物理サーバを計画的に停止しなければならない際に有効です。 vMotion によって停止する物理サーバから別の物理サーバへ仮想マシンを退避しておくことで、仮想マシンとして、あるいはその仮想マシンの提供しているITサービスとしてはダウンタイムがなくなります。

なお、 vMotion を行うためには、対象物理サーバ (= ESXiサーバ)が vCenter に登録されていること、移行元、移行先の物理サーバのCPU互換性があること、共有ストレージが構成されていることが必要です。CPUの互換性に関しては、同じメーカーかつ同一の互換性グループに属するファミリのもの同士でなければなりません。詳細はこちらをご確認ください。 (http://kb.vmware.com/kb/1991, http://kb.vmware.com/kb/1992)

FAQ ~vMotion~

Q.移行の前後ではMACアドレスやIPアドレスは変わりますか?
A. vMotionによる移行ではMACアドレスとIPアドレスは保持されます。仮想マシンの場合IPアドレスは vNIC ごとに割り当てられるため、これが vMotion による移行前後でそれぞれ保持されることになります。

Q.後日物理サーバを追加していくとCPUの互換性確保ができなくなりそうですが…?
A. Enhanced vMotion Compatibility (EVC) により異なるCPU世代間の vMotion が可能です。クラスタ内で EVC のベースラインを定義することにより、クラスタ内の全ての物理サーバを同一の CPU 機能に統一します。詳細はこちらをご覧ください。(http://kb.vmware.com/kb/2011037

Q.移行先の物理サーバとの間に共有ストレージがありません。
A.vMotion とvSphere Storage vMotion という機能を同時にご利用いただくことで、共有ストレージがない物理サーバ間でも移行することが可能です。(クロスホスト vMotion とも呼ばれます)

Q.移行中に加えられた変更について整合性は保たれますか?
A. vMotion は実行中のメモリおよび全てのシステム状態を移行先の物理サーバにコピーし、移行元の仮想マシンをサスペンドして切り替えます。実行中のメモリトランザクションをコピーした後に移行先で仮想マシンを再開するため、トランザクションの整合性も保たれます。

Q.一般的にvMotionに要する時間はどの程度ですか?
A.ネットワークの状況に依存しますが、数秒から数分程度で完了する場合が一般的です。

 

“クラスタ”の構成

ここで、HA / FT の紹介を行う前に、クラスタという概念について説明いたします。なぜなら HA / FT を利用するためには、クラスタの構成が必須だからです。クラスタは複数の物理サーバを論理的にグループ化したもので、まとめられたサーバはあたかも一つの大きなリソースであるかのように扱うことができます。(図3)

図3.クラスタ構成図

図3.クラスタ構成図

このような物理ホストのグルーピングのメリットは、それらをひと括りに一つの大きなコンピュータのように扱うことで、個別に稼動していた場合を超えるサービス品質を提供できることです。これら複数の物理ホストはクラスタ内で各自の持つリソースを互いに共有するため、各時刻で余剰のリソース能力(CPU, Memory)を最適に配分することで処理能力を上げたり、計画的/非計画的なホストの停止に対応する可用性の確保を実現したりします。

そのクラスタに対して HA 機能を有効にすることで、クラスタ内に含まれる仮想マシンは全て HA により保護されることになります。また、 FT の保護を施したい場合には、仮想マシンを選択して FT を有効化することで、自動でクラスタ内の別ホストにセカンダリが作成されます。なお、 vMotion の利用にはクラスタの構成は不要です。

 

 HA / FT ~物理サーバ障害における可用性を向上~

計画外停止( = 物理ホスト障害)に対して可用性を向上する機能が HA と FT です。 HA は “High Availability” ( = 高可用性) を意味し、アクティブースタンバイの可用性を提供する機能です。 HA を使用しない場合、ある物理サーバが障害等で機能を停止するとその上で起動している仮想マシンも停止してしまいます。それに対し、予めクラスタを構成して HA を有効にしておくことで、同じクラスタ内の別の物理サーバで自動的に再起動することが可能です。(図4)HAの場合、仮想マシンが再起動するまで数分の停止が発生しますが、仮想マシンが自動的に起動するだけでも管理者としては助かります。

HA により仮想マシンを別ホストで再起動

図4. HA により仮想マシンを別ホストで再起動

FT (Fault Tolerance) は、物理サーバ障害が発生しても無停止でサービスを継続する機能です。保護対象となる仮想マシン(プライマリ)に対し、別の物理ホスト上にセカンダリというコピーマシンを作成します。(図5)これらは常に同期し、仮にプライマリ仮想マシンが起動している物理サーバが停止しても、すぐに切り替わってセカンダリで動作し続けることが可能です。これにより物理サーバ障害によるダウンタイムを0にすることができますので、特にダウンタイムが許容されないシステムがある場合はご使用を検討ください。現状では FT 機能が対象とできる仮想マシンはvCPUが1つの仮想マシンに限られています。

 

図5. FT のアクティブなセカンダリによる保護

図5. FT のアクティブなセカンダリによる保護

FAQ  ~ HA / FT ~

Q. HA で仮想マシンが再起動した場合、実行中だったアプリケーションはどうなりますか?
A.仮想マシンが再起動されるため、アプリケーションは一度終了されます。Crash Consistent ( = OSが起動している状態で電源を落ちる状態)ではありますが、仮想マシンの起動とともに特定のアプリケーションが起動するよう設定しておくことで、アプリケーションやサービスの再開までを自動化することも可能です。

Q.クラスタ内に HA に必要なリソースの余裕があるか確認できますか?
A.クラスタで”許容するホスト障害数” を設定したり一定割合を予約したりすることができます。これにより常に物理サーバ障害時に必要なリソースを確保した計画的なリソース使用が可能です。

Q. HA で再起動される先の物理サーバは指定できますか?
A.アドミッションコントロールポリシーにより特定のホストをフェイルオーバーホストとして再起動する物理サーバに指定可能です。(ただし、リソースの空き具合により他のホストで再起動する可能性もあります。)

Q. FT で保護されている仮想マシンのセカンダリに対して操作を行うとどうなりますか?
A.セカンダリに対する操作は行えず、プライマリに対する操作のみが反映されます。

Q. 一度物理サーバの障害に対応すると FT の保護はなくなりますか?
A. プライマリ、またはセカンダリのホストに障害が発生した場合、クラスタ内にある別の物理サーバに新たなセカンダリが生成されて保護状態が継続されます。

 

vMotion と HA の使い分け

これまで見てきたように、 vMotion と HA は、仮想マシンを移行して別のホスト上で動かすという点では共通していますが、移行の際に起動したままか再起動するか、利用シーンが計画的な移行か非計画的な障害対応か、クラスタの構成は不要か必要か、といった違いがあります。このような違いを FT も含めて整理したのが表6です。

表6. vMotion と HA / FT の比較

機能

使用目的

設定対象

仮想マシン停止

ダウンタイム

オペレーション

vMotion

計画停止削減

仮想マシン単位

なし

ゼロ

手動

HA

物理サーバ障害対策

クラスタ単位

あり

数分

自動

FT

物理サーバ障害対策

仮想マシン単位

なし

ゼロ

自動

表にあるような特徴を押さえておくことで、 vMotion と HA / FT の違いを明確に整理しておくことができます。特にそれぞれの機能を使用するシーンや目的は全く異なるため、機能をよく理解することでvSphereをこれまで以上に使いこなしていただけたらと思います。

 

終わりに

以上いかがでしたでしょうか?仮想マシンのホット移行を行うvMotionと、アクティブースタンバイ / アクティブーアクティブの可用性を提供する HA / FT という機能。どちらも vSphere を語る上で外せない重要な機能です。この記事で少しでも理解を深めていただけましたら幸いです。

VMware SE川崎 一青

新卒 SE 社員が贈る vSphereのキソ!
第1回 vSphereを俯瞰する
第2回 仮想環境におけるネットワークとストレージ
第3回 vMotionとvSphere HA/vSphere FTの違いとは?
第4回 仮想マシンの配置管理はDRSにお任せ!
第5回 様々な仮想マシンが混在&混雑しても大丈夫!?ネットワーク と ストレージの帯域を維持する仕組み
第6回 vSphere でココまでできる!データ保護
第7回 仮想環境となが〜くお付き合いしていく
第8回 ( 追加編 ) まだまだあった!ストレージ関連機能