Home > Blogs > Japan Cloud Infrastructure Blog

ネットワーク仮想化をネットワークの基本から理解する 〜 第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 を使いこなすことで、その価値を十分に享受いただくことを目的としております。本ブログの内容もお話させていただきますので、ぜひご参加くださいネ!
※ユーザー企業・団体の方に限定させていただきます。あらかじめご了承ください。

V2C (Virtual to Cloud) – VMware vSphere 環境から vCloud Air への移行

VMwareは、2014年11月にパブリッククラウド vCloud Air のサービスを日本で開始しました。本シリーズのエントリでは、物理から仮想化環境への移行P2V(Physical to Virtual) について記載してきましたが、今回はP2V で移行したオンプレミスの仮想マシンを、vCloud Air に移行するV2C(Virtual to Cloud) をご紹介します。

20141226-v2c-01-2

V2C を実施する際にはVMware vCloud Connector(vCC)を使用することで、プライベートクラウドとパブリッククラウド間での仮想マシンの移行をスムーズに行うことができるようになります(vCC は無償で提供されています)。vCC の導入とオペレーションについて、詳細は下記リンクで公開されているドキュメントをご参照ください。

vCloud Connector構築ガイド(Step by Step の構築ガイドで簡単に環境が構築できます)

 

■ アーキテクチャ
オンプレミス環境 – vCloud Air 間をvCC で接続し、ネットワーク経由で仮想マシンのイメージを移行します。vCC はConnector Server と、Connector Node で構成されており、オンプレミスのvSphere 環境にデプロイします。vCloud Air 側は、あらかじめデプロイされているマルチテナント型のConnector Nodeを使用します。

20141226-v2c-02-2

Connector Server(オンプレミス) – Connector Node(Air) 間の通信にはTCP ポート8443 を使用するため、FWで通信を許可する必要があります。データ転送はNode 間で実施します。デフォルトの設定ではデータ転送にTCP ポート8443 を使用しますが、UDT(UDP-based Data Transfer Protocol)を使用する場合はUDP ポート8190 をFW で許可します。

 

■ 構築手順
オンプレミスのvSphere 環境に、Connector Server とConnector Node を展開します。各コンポーネントはOVF 形式で提供されており、vCenter サーバから簡単にデプロイできます。

1. vCloud Connector Node の展開
vCenter Server から「OVF テンプレートのデプロイ」を選択し、OVF 形式で提供されているConnector Node を展開します。展開時にIPアドレスの設定を行います。

2. vCloud Connector Node の設定
展開後にWeb ブラウザから「https://Connector_Node_IP:5480」にアクセスし、vCenter Server を登録します。データ転送にUDT プロトコルを使用する場合は、Connector Node で設定を行います。

3. vCloud Connector Server の展開
vCenter Server から「OVF テンプレートのデプロイ」を選択し、OVF 形式で提供されているConnector Server を展開します。展開時にIP アドレスの設定を行います。

4. vCloud Connector Server の設定
展開後にWeb ブラウザから「https://Connector_Server_IP:5480」にアクセスし、vCenter Server を登録します。オンプレミス側及びAir 側のConnector Node の登録を実施します。

 

■ 移行手順
各コンポーネントの展開及び設定後、vSphere Client の「ホーム」画面からvCloud Connector の管理画面にアクセスできるようになります。Connector のオペレーションは、今後vSphere Web Client でも実装予定ですが、現在はvSphere Clientから実施します。オンプレミス及びAir 側のvCC Node を登録することでセットアップは完了です。移行対象の仮想マシンを選択し、vCloud Air へ「Copy」することで、簡単に移行ができます。

20141226-v2c-05-2

 

■ まとめ
vCloud Connector を使用いただくことで、オンプレミスの仮想マシンを簡単にvCloud Air 上に移行することができます。オンプレミスのvSphere 環境と同様に幅広いゲストOSがvCloud Air 上で動作しますので、P2V を行った古いゲストOSをvCloud Air 上で稼働させることが可能になります。また、vSphere 環境と同じアーキテクチャで動作しますので、仮想マシンのイメージの変換等、異なるアーキテクチャのパブリッククラウドへの移行時に発生する煩雑なオペレーションがありません。

20141226-v2c-04-2

オンプレミス環境とvCloud Air 間のワークロード移行にはvCloud Connector をご活用ください。

vCloud Connector構築ガイド(Step by Step の構築ガイドで簡単に環境が構築できます)

 

[仮想化への移行]シリーズ
・はじめに
-移行計画、準備段階でのポイント
・V2V (Virtual to Virtual)
- VMware vCenter Converter Standaloneを利用した他の仮想化製品フォーマットから VMware vSphere 環境への移行
・P2V (Physical to Virtual)
- VMware vCenter Converter Standalone を利用した物理サーバ (Linux) から VMware vSphere 環境への移行
・I2V (3rd Party Image/Backup Tool to Virtual)
- 3rd Party Image/Backup Tool から VMware vSphere 環境への移行
・V2C (Virtual to Cloud)
- VMware vSphere 環境から VMware vCloud Air への移行 ← 本エントリ

新卒 SE 社員が贈る vSphere のキソ!第8回 ( 追加編 ) 〜 まだまだあった!ストレージ関連機能 〜

みなさん、こんにちは! VMware SE の氏田 ( Ujita ) と申します。
本エントリでは、前回ご好評頂いた新卒ブログの追加編として、VMware vSphere のストレージ関連機能である vFRC 、Multipathing 、VAAI をご紹介します!

 

~ はじめに ~

私は以前、新卒ブログシリーズにて vSphere のキソ!第5回 を担当させていただきましたが、その中でストレージに関する機能として、 SIOC と Storage DRS を挙げさせていただきました。これらはいずれも vSphere 単体による工夫でしたが、ストレージのパフォーマンスを向上させる機能の中には、ESXi サーバ内の SSD や外部のストレージの機能と連携できるものがあります。それが、今回ご紹介する vFRC ( vSphere Flash Read Cache ) 、Multipathing 、VAAI ( vStorage API for Array Integration ) といった機能になります。

 

§ 1 . vFRC ( vSphere Flash Read Cache )

まずは、vFRC からご紹介していきます。vFRC とは、ESXi サーバ内の SSD を仮想マシンの読み取りキャッシュとして利用する機能です。SSD を内蔵している ESXi サーバ上に読み取りパフォーマンスを向上させたい仮想マシンがある場合、仮想マシン単位 ( 正確には、vmdk 単位 ) でキャッシュ領域を割り当て可能です ( 図 1 ) 。

 

vFRC
図 1 . vFRC

 

ESXi サーバには、図 2 のように、SSD を仮想フラッシュリソースとして追加できます。

 

仮想フラッシュリソース管理
図 2 . ESXi サーバにフラッシュリソースを追加
( ※ フラッシュリソースの用途としては、今回ご紹介する読み取りキャッシュの他に、ESXi ホストのメモリスワップ領域として利用する方法もあります )

 

仮想マシンのキャッシュ領域は、このフラッシュリソースから切り出されて提供されます。仮想マシンへのキャッシュ領域の割り当ては、サーバにフラッシュリソースを追加後、インベントリから仮想マシン名を右クリック -> [設定の編集] から簡単に行うことが出来ます( 図 3 )。仮想マシンに特別な変更を加える必要はありません。

 

仮想マシンへ読み取りキャッシュ領域を追加
図 3 . 仮想マシンへのキャッシュ領域の割り当て

 

前回ご紹介した SIOC は、特定のストレージへ I/O が集中した場合、優先的に I/O を通す仮想マシンを設定できる機能でした。これに対し、vFRC では、仮想マシンのストレージパフォーマンス自体を向上させる事が可能です。特に、読み取りが多く、遅延に敏感なアプリケーションを実行している仮想マシンに有効です。キャッシュ内にデータがある場合、ストレージへアクセスする必要は無いので、ストレージの負荷を減らすことができるというのも大きな利点となります。

 

§ 2 . Multipathing

次に、Multipathing についてご紹介します。図 4 に示したように、ESXi サーバ – ストレージ間のパスは複数存在します ( 実際には、ESXi サーバが複数あるためもっと複雑 ) 。Multipathing は、このパスを効率よく利用するための機能であり、仮想マシンが共有ストレージにアクセスする際、どこを通ればパスの負荷を分散できるかを常に考えてくれます。

 

Multipathing
図 4 . サーバ – ストレージ間のパス

 

ご存じの通り、仮想環境では一台のサーバ上でたくさんの仮想マシンが稼働するため、物理環境と比べサーバ – ストレージ間のパスが大変混み合います。従って、サーバ – ストレージ間のパスの負荷を分散させることは非常に重要です。ESXi サーバがどのようにパスを選択するかの基準を、パス選択ポリシー ( PSP : Path Selection Policy ) といいますが、vSphere のデフォルトの機能だと、パス選択ポリシーには、最近の使用ラウンドロビン固定の3つしかありません ( 図 5 ) 。

 

vSphere_PSP
図 5 . パス選択ポリシー

 

vSphere では、ストレージの種類を見て、最適なパス選択ポリシーを自動で設定してくれますが、これら 3 つのポリシーはどれも機械的なものであり、パスの負荷が適切に分散されるわけではありません。特定のパスに負荷が偏ると、レイテンシが発生し、アプリケーションの安定稼働に影響を与える可能性があります。

これに対し、Multipathing は、ストレージベンダが提供する専用のマルチパスの仕組みを利用します。これにより、インテリジェントかつ動的なパスの選択が可能になるため、パスの負荷が平滑化されます。以前、私が書いたブログで NIC の負荷分散機能である LBT ( Load Based Teaming ) をご紹介しましたが、適切なパスを選択して負荷を分散するという考え方は同じです。

Multipathing を利用することで、パスの帯域を最大限有効に使うことができるので、I/O 要求が混み合っている場合でも安定したストレージパフォーマンスを期待できます。

 

§ 3 . VAAI ( vStorage API for Array Integration )

最後に、VAAI についてご紹介します ( ※ VAAI を利用するには、vSphere の Enterprise 以上のエディション、ストレージのファームウェア対応が必要となります )。VAAI を有効にすることで、ストレージが持つ機能と vSphere が連携し、仮想環境におけるストレージパフォーマンスを向上させることができます。

例えば、仮想環境のストレージには、以下の課題があります。

    ( 1 ) 大量の仮想マシンからのアクセス
    ( 2 ) 仮想マシンファイル ( 大容量 ) のコピー、移動が頻発
    ( 3 ) ストレージへの 0 書きが頻発

VAAI は、これら仮想環境特有のストレージ処理を効率よくこなすための仕組みを提供します。以下、それぞれの課題を VAAI がどのように解決するかについてご説明します。

 

( 1 ) 大量の仮想マシンからのアクセス

今までは、たくさんの仮想マシンが同一のストレージを利用することによって I/O が混雑するというお話をしていましたが、実はもう一つ大きな課題があります。それが、ストレージの排他制御です。排他制御はデータの整合性を保つために必要ですが、これはファイルシステムのメタデータを更新する場合にのみ実行されます。しかし、仮想環境では多くの仮想マシンからアクセスが発生するため、排他制御により生じる待ち時間は馬鹿になりません。そのうえ、vSphere の標準機能の場合、排他制御は LUN 全体をロックすることにより行われるため、同じ LUN を利用している仮想マシン全てが待たされる状態でした ( 詳しくは、過去のブログ 押さえておきたいvSphereの基本~ストレージ編 第2回~ をご覧ください ) 。

これに対し、VAAI が有効なストレージでは、LUN 全体ではなく、より細かい単位でストレージをロックします。従って、排他制御の影響を受ける仮想マシンを大幅に減らすことが可能になります。これを実現している VAAI の機能を ATS ( Atomic Test & Set ) と呼びます。

 

( 2 ) 仮想マシンファイル ( 大容量 ) のコピー、移動が頻発

仮想環境には、仮想マシンがファイルであることを生かした便利な機能がたくさんありました。前回のブログでご紹介した Storage vMotion もその一つです。こういった便利な機能を利用するには、大容量の仮想マシンファイルをコピーしたり、移動したりする必要があります。VAAI が有効でない場合、この処理は ESXi サーバの CPU が行います。つまり、 ESXi サーバが対象となるデータをストレージから読み込み ( read ) 、再びストレージへ送って書き込む ( write ) という処理を行う必要がありました。このため、本来仮想マシンによって利用されるべき ESXi サーバの CPU リソースが奪われるうえ、サーバ – ストレージ間の帯域も一時的に逼迫してしまいます。

これに対し、VAAI が有効なストレージでは、ファイルコピーや移動の処理をストレージ単体で行うことが可能になります。ESXi サーバは、ただ一度命令を出すだけで済むので、CPU リソースが奪われることがありません。また、実際のデータは、ストレージ内でのみ流れることになるため、サーバ – ストレージ間の帯域も消費されません。これを実現している VAAI の機能を Full Copy と呼びます。

 

( 3 ) ストレージへの 0 書きが頻発

これまでお伝えしてきたように、仮想環境では、一つのストレージを複数の仮想マシンが利用します。従って、ある仮想マシンが書き込んだ領域を別の仮想マシンが使うということが頻繁に起こります。しかし、ある仮想マシンが過去に書き込んだ情報に別の仮想マシンからアクセスできるというのはセキュリティ上良くありません。そのため、仮想マシンがストレージ上のとある領域に初めてアクセスする場合、まずは 0 書きされるという仕組みになっています。仮想マシンを新たに作成する際にも大量の 0 書きが行われます。VAAI が有効でない場合、この 0 を書く処理は、ESXi サーバの CPU が行います。当然、( 2 ) と同じように、ESXi サーバの CPU リソースやサーバ – ストレージ間の帯域に影響を与えてしまいます。

もうおわかりかと思いますが、VAAI が有効なストレージでは、この処理をストレージ側にオフロードすることが出来ます。従って、ESXi サーバの CPU リソースに影響を与えませんし、サーバ – ストレージ間の帯域にも影響しません。これを実現している VAAI の機能を Block Zeroing と呼びます。

 

図 6 に、VAAI 機能のイメージ図を示します。

 

VAAI
図 6 . VAAI

 

~ おわりに ~

今回は、新卒ブログシリーズのおまけとして、vFRC 、Multipathing 、VAAI をご紹介させていただきました。前回ご紹介した SIOC や Storage DRS も考えると、vSphere にはストレージ関連機能がたくさんあると言うことがおわかりいただけたと思います。機能が多すぎて複雑に見えてしまうかも知れませんが、裏を返せば、それだけストレージが重要視されているということでもあります。皆様には、本シリーズでご紹介したストレージ関連の機能を生かし、仮想化の恩恵を最大限受けられる環境を構築していただけたらと思います。ありがとうございました。

VMware SE 氏田裕次

 

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

3rd Party Image/Backup Tool から VMware vSphere 環境への移行

皆様、こんにちは。VMware の大原と申します。

本エントリでは、ブログ [仮想化への移行] シリーズの第三弾として、VMware vCenter Converter Standalone (以下Converter) でサポートされないバージョンのOSをvSphere環境にP2V(Physical to Virtual)するための手段についてお伝えします。

[仮想化への移行] シリーズ

はじめに
- 移行計画、準備段階でのポイント
V2V (Virtual to Virtual)
- VMware vCenter Converter Standaloneを利用した他の仮想化製品フォーマットから VMware vSphere 環境への移行
P2V(Physical to Virtual)
- VMware vCenter Converter Standalone を利用した物理サーバ (Linux) から VMware vSphere 環境への移行
I2V (3rd Party Image/Backup Tool to Virtual)
- 3rd Party Image/Backup Tool から VMware vSphere 環境への移行←本エントリ
V2C (Virtual to Cloud)
- VMware vSphere 環境から VMware vCloud Air への移行 ←Coming soon!!

 

2015年7月15日のWindows 2003サポート終了に伴い、その上で稼動しているアプリケーションをWindows 2008やWindows 2012といったOSに移行することが急務となっています。しかし、そのアプリケーションを使用しているユーザが少ないケースや、アプリケーションの使用期限(たとえば、あと2年以内に全ユーザを別のアプリケーションへ移行するようなケース)が明確な場合には、コストをかけてアプリケーションを改修するのではなくWindows 2003を延命させることで既存のアプリケーションを使い続けたいというニーズをお持ちのお客様も多くいらっしゃるのではないでしょうか。
一方で物理サーバ上でWindows 2003を稼動し続ける場合、サーバ老朽化に伴う保守パーツ不足により保守サポートが受けられなくなるリスクも発生します。
そういった場合に、既存のWindows 2003に変更を加えることなく、vSphere環境上に移行することを検討する必要があり、それを可能にする製品がVMware vCenter Converter standaloneです。以前のブログでは、Converterを使ってWindows 2003を移行する手順もご紹介していますのでご参照下さい。

しかし、ConverterでサポートされるWindows2003のバージョンはWindows 2003R2SP2のみとなります。それ以前のバージョンでは、Converterを使って移行することはサポートされません。

※Windows2003 R1 SP2の環境をConverterを使って移行を試みましたが、サポートOS外ということでConverterのエージェントのインストールに失敗して移行することができませんでした。

Error_message

そのような環境下では、Windows2003をvSphere環境へ移行するために3rd Partyのソフトウェアを使用してP2Vを行う必要があります。本ブログでは、アクロニス社のAcronis Backupを利用したP2V手法についてご紹介していきます。

以前は、Acronis Backupのようなバックアップソフトウェアで取得したイメージをConverterに読み込ませることでvSphere環境への移行を行っておりましたが、最近ではバックアップソフトウェア側の機能で直接vSphere環境にイメージを戻すことができるようになっています。

Backup_Image

以下にAcronis Backupを使用したWindows2003(およびLinux※)の詳細な移行手順につきまして、アクロニス・ジャパン株式会社セールスエンジニア部の佐藤匡史様にブログを執筆頂きましたのでご紹介させて頂きます。

※LinuxについてもConverterでサポートされるディストリビューションは限定的ですので、Acronis Backupを検討されるケースも多くあるのではと思われます。

 

□Acronis Backupのご紹介

Acronis Backupはイメージバックアップをコアテクノロジとするバックアップ製品です。日本のイメージバックアップ市場ではNo1のシェアを持ち業種、規模によらず幅広く利用されています。

さらにAcronis BackupではWindows、Linux、物理、仮想の集中管理や、アプリケーションに対応したバックアップ、重複除外機能など多くの付加価値を提供します。また様々な保存先が利用できるのでシーンに応じた最適なバックアップ環境を提供します。vSphere環境ではvStorage APIと連携したエージェントレス型バックアップ、仮想マシンへのコンバート、レスキューメディアを利用した簡単P2Vなどお客様のニーズに合わせた利用が可能です。

AcronisBackup

□Acronis Backup によるP2Vの実施

Acronis Backup では、現在利用しているサーバで取得したバックアップを仮想サーバに復元するP2V機能を標準の機能として提供します。物理サーバで取得したバックアップデータをドライバを含めたハードウェア環境から分離し、仮想マシン上に復元して稼働させることができるのです。この作業はWindows/Linux共に直観的に利用可能なGUIを利用し、バックアップと復元という単純な作業により実施できることが特徴となります。また、付加機能を利用することで効率的な作業に貢献します。

Acronis Backup のP2Vは3つのステップで実施します。Step1で移行元においてシステム丸ごとバックアップしイメージ化します(P2I)、Step2ではESXi上に移行先の仮想マシンを任意の構成で作成します。Step3では新規仮想マシンにStep1で取得したイメージを復元します(I2V)。

移行STEP

□イメージバックアップ

OS、アプリ、システムファイルなどすべてをイメージバックアップすることがが可能です。このバックアップは実際にデータが配置されているブロックのみを検知しブロックベースのコピーを行いますので高速なバックアップが可能です。Windowsのダイナミックディスク、LinuxのLVM(ロジカルボリューム)を認識したバックアプ、復元も可能です。また、その保存先としてCD、DVD、テープ、USBメディア、ローカルディスク、ネットワークディスクなど様々な場所に保存することが可能です。P2V実施時、移行元と移行先がネットワークで接続されていない環境などではポータビリティのある外部媒体にバックアップイメージを保存し、搬送するなどの手段が必要となります。このような条件下でもAcronis Backupを活用頂けます。

イメージバックアップ

バックアップ時に利用するレスキューイメージは常に最新のものをWebからダウンロードすることが可能です。このレスキューイメージはAcronisが独自開発しているLinuxベースのレスキューイメージとなり、各社のHWに対応するための汎用ドライバが既に組み込まれ即時利用することが可能です。特殊なHWを利用している場合には汎用ドライバで対応ができないことからレスキューイメージでシステムが起動できない状況が発生します。その場合には任意のドライバを組み込んだWinPEベースのレスキューイメージを作成することも可能です。また、オフラインバックアップにおいて、完全、差分、増分を取得することが可能です。停止時間が限られた移行を計画している場合には事前に完全バックアップを取得しておき、移行作業時は増分のみを取得することでバックアップ時間(つまり停止時間)を最小に抑えることが可能です。

オフラインバックアップ

□Universal Restore(異機種への復元)

Universal Restoreは復元時に機能し、異なる環境へのOSイメージ移行を簡素化します。(本ブログでは、vSphereへのリストア手順をご説明します)

以下に、OS毎のUniversal Restore実施時の動作について記載します。

・Windows

復元時にHAL(Hardware Abstraction Layer)を調整、その後チップセット、ストレージコントローラ用ドライバの変更・インストールを行うことでOSを起動させます。OS起動後プラグアンドプレイもしくは手動で必要なドライバを適用します。

・Linux動作(RHELの場合)

復元時に新たな環境に合わせRAMディスクを作成します。またBootスクリプトを新しいHW、パーティションレイアウトに合わせ調整します。GRUBおよびfstabを修正しOSを起動させます。

これらの処理は各OSに関する専門知識を持ったエンジニアであれば実施可能と思われますが、一般的には実施することがない操作と考えています。また、自身で実施した場合、起動不能、OS破損などの移行後の問題に対処することを考えると得策ではないと思われます。OS起動部分までをメーカサポートが付帯したツールで実施することで移行作業が簡素化され、品質が安定します。

UR

□サポートOS一覧

Acronis Backupでは非常に多くのOSをサポート(※)しています。特徴的なのはWindows2000や無償版のLinuxのサポートです。

(※)移行先でのOSサポートにつきましては、vSphereのサポートOS情報を参照下さい。

・Acronis BackupでサポートされるWindows OS一覧
WindowsSupport

・Acronis BackupでサポートされるLinux OS一覧
LinuxSupport

□Acronis Backupを使用したP2V手順

・レスキューメディアから物理マシンを起動
 移行元の物理マシンにレスキューメディアを挿入し起動します。レスキューメディアが起動すると以下のような画面が表示されます。マウス、キーボードを使って操作が可能ですのでご利用のHWに応じて32ビット用、64ビット用を選択しAcronis Backupを起動します。

移行元

・Acronis Backupによるバックアップの実施
Acronis Backup起動後はP2Iのためのバックアップを実施します。設定項目は大きくは3つ。

①バックアップ対象の指定
Acronis Backupではディスク、ボリューム、ファイルの何れかを指定することが可能です。P2Vであればディスクまたはボリュームを選択します。

②バックアップ保存先の指定
保存先はサポートする任意の保存先を選択することが可能です。GUIに表示される保存先を選択します。UNCを直接入力することも可能ですが “¥” の入力ができませんので “/” を入力します。

③バックアップ方法の指定 
完全、差分、増分の指定が可能です。完全はすべてのデータ、差分は前回取得した完全バックアップから変更されたデータ、増分は前回取得したバックアップから変更されたデータを取得します。バックアップ時間は完全が最長で、増分が最短となります。

移行元バックアップ

・新規仮想マシンの作成とレスキューメディアからの仮想マシンの起動
移行先となるvSphere環境で新規の仮想マシンを作成します。レスキューメディアからAcronis Backupを起動するためにはCD/DVDドライブ、1GB以上の仮想メモリが必要です。ネットワーク共有越しにバックアップアーカイブを参照する場合にはネットワークアダプタが必要です。レスキューイメージを仮想マシンにマウントし64ビット用のAcronis Backupを起動します。

移行先

・バックアップしたイメージの復元
Acronis Backup起動後はI2Vのための復元を実施します。設定項目は大きくは3つ

①復元データの選択
復元するバックアップアーカイブをAcronis Backupから参照すると世代、内部のデータを参照することが可能です。P2Vであれば復元の対象はディスクまたはボリュームを選択します。LVMを利用している場合にはボリュームを選択します。

②復元先の指定
復元するディスク、ボリュームは自動でマッピングされますが、意図しない構成となった場合には手動でマッピングすることも可能です。プロパティから各ボリュームのサイズ変更することも可能です。NTシグネチャは“自動的に選択する”がデフォルト設定となり、P2Vの場合には(新規ディスクへの復元時)は新しいNTシグネチャが生成されます。

③Universal Restore
P2Vを行う場合には必ずこの項目を“使用する”に変更して下さい。このUniversal Restore機能を有効にすると任意のドライバをAcronis Backupに追加することが可能ですが、vSphereへの移行に関しては必要なドライバがAcronis Backupに内包されておりますので手動でドライバの追加を行う必要はありません。

移行先復元

□P2Vの留意点

・IPアドレスについて
移行元のIPアドレスは移行先に継承されません。ネットワーク設定は初期化されますのでOS起動後手動での変更が必要です。

・SIDの重複
このP2Vではデフォルト移行元で利用されていたSIDがコピーされます。移行元と移行先の環境でSIDの重複が発生しないように配慮が必要です。

・ハードウェア監視ツール
RAID管理ユーティリティ、NICチーミング・ドライバなど移行先の環境に適応できずにシステムの起動、動作を阻害する可能性がございます。状況に応じてセーフモードでの起動、不要なユーティリティ、サービス、デバイスドライバ等の停止、削除が必要です。

本ブログ執筆に向け、Windows環境につきましてはHP社のML350G3、Linux環境につきましてはHP社のML350G5、それぞれ物理サーバを使用して詳細な移行手順を作成しました。
以下に、WindowsおよびLinuxそれぞれの詳細移行手順、および注意点を記載しておりますので、是非ご参照下さい。
※お客様情報を入力頂くことで手順のダウンロードが可能です。

Windows環境での詳細移行手順
⇒“実画面でステップを紹介!Acronis BackupによるWindows Server 2003 P2Vガイド”

Linux環境での詳細移行手順
⇒“実画面でステップを紹介!Acronis Backup for Linux ServerによるP2Vガイド”

 

□まとめ

いかがでしたでしょうか?ConverterでサポートされないOSが稼動している物理サーバをvSphere環境へ移行する際には、Acronis Backupのようなツールと連携して移行することをご検討下さい。

 

[仮想化への移行]シリーズ
・はじめに
-移行計画、準備段階でのポイント
• V2V (Virtual to Virtual)
VMware vCenter Converter Standaloneを利用した他の仮想化製品フォーマットから VMware vSphere 環境への移行
• P2V (Physical to Virtual)
- VMware vCenter Converter Standalone を利用した物理サーバ (Linux) から VMware vSphere 環境への移行
• I2V (3rd Party Image/Backup Tool to Virtual)
- 3rd Party Image/Backup Tool から VMware vSphere 環境への移行←本エントリ
• V2C (Virtual to Cloud)
- VMware vSphere 環境から VMware vCloud Air への移行 ←Coming soon!!

VMware Virtual SAN 利用時の vSphere HA 設定に関するベストプラクティス

はじめに

VMware Virtual SAN は、vSphere5.5 Update1 以降のESXiカーネルに組み込まれた魅力あふれるストレージの新機能で以下のような特徴を持ちます。

  • ローカルサーバに搭載されたディスクを利用した共有ストレージ
    大容量安価な磁気ディスクと、高速低遅延なフラッシュデバイスを組み合わせたハイブリッド型 

  • ストレージポリシーによる管理
    可用性やパフォーマンスを仮想ディスクの粒度で定義

  • 柔軟な拡張
    ホスト追加による動的なストレージ拡張(3~32ノードをサポート)

  • Virtual SANでは、コンピューティング機能とストレージの機能を共にサーバで提供しますので、上記の通り非常に拡張性に富んだストレージサービスの提供が可能となるのですが、ストレージサービスをサーバに統合しているが故、主に仮想マシンの可用性に関する面で少しばかり注意が必要となります。本Blogでは、この点にフォーカスを当ててご説明いたします。なお、本Blogでは、Virtual SANの基本的な構成に関する説明は割愛させていただきます。また、vSphere5.5 Update 2 (2014年9月)の情報で作成させていただいており、将来的に変更になる可能性がありますのであらかじめご了承下さい。

    Virtual SANの耐障害性

    ストレージポリシーと仮想ディスクの配置

    一般的なRAIDコントローラでは、Disk障害に対応するためにミラーやパリティを構成しますが、Virtual SANの場合はホスト自体の障害に対応するため、例えば、”許容障害数=2″のストレージポリシーで作成された仮想マシンの仮想ディスクは、3台のホストにまたがって書き込まれます。


    障害時の動き

    Virtual SANは一種のクラスタとして動作します。お互いの死活監視は、Virtual SANネットワークを利用したハートビートのみで実装されています。Virtual SAN ネットワークはチーミングによる冗長化が可能ですし、その重要性を考えると冗長化は必須とも言えますが、万が一冗長化されている Virtual SAN ネットワークが全て切断されてしまうと、ホスト自体が障害で落ちてしまったのか単なるVirtual SANネットワークの障害なのか知るすべがありません。これは、ネットワークのハートビートだけでなく、ハートビートデータストアやゲートウェイへのPingを使って、相手の状態や自分自身の状態をインテリジェントに確認していくvSphere HAとは大きく異なる点なのですが、実は凄く理にかなっています。

    vSphere HAの障害時の優先事項は仮想マシンの稼働を最大化させることです。このため、上記の通りインテリジェントに状態を判断し、仮想マシンへのアクションを適切にハンドリングすることを試みるのですが、Virtual SANが、障害時に最も優先する事項は、”Diskの一貫性を保つ”ことです。



    例えば、上記のような3面ミラーの構成時に、esxi‒01が何らかの障害によりVirtual SANネットワークから切断されてしまった場合、分断されたミラーが共にアクセス可能な状態で放置されると、互いに異なる変更が発生し、ミラーの一貫性が失われる危険性があります。これを防ぐため、Virtual SAN は障害時、片方のミラーオブジェクトを即時にロックすることによりミラーオブジェクトの一貫性を保ちます。これが障害時にVirtual SANが最も優先する事項です。つまり、Virtual SANは、インテリジェントに相手の状態を把握することよりも、ミラーオブジェクトの一貫性を保つために”即時性”を最優先しているといえます。

    オブジェクトロックアルゴリズム

    先述の通りVirtual SANは障害時、必要に応じ特定のディスクオブジェクトをロックします。このロックの判断は、

    “ディスクオブジェクト数” +”監視オブジェクト数”

    がオブジェクト総数の過半数を獲得できたか否かによって判断されます。その結果、過半数の獲得ができなかったオブジェクトがロックされます。例えば、許容障害数 = 1で仮想Diskを作成すると、下記の様に、2面のミラーオブジェクトとは別に”監視オブジェクト(英語名Witness)”があらかじめ作成されます。



     
    この状態でesxi-01のVirtual SANネットワークが何かしら障害を起こしてしまった場合、それぞれのパーティションには、
     
     esxi-01側・・・Diskオブジェクトが1つ
     esxi-02~05側・・・Diskオブジェクト1つ + 監視オブジェクト1つ = 計2つ

    のオブジェクトが存在することになり、過半数を獲得できなかったesxi-01上に存在するDiskオブジェクトがロックされます。一方、過半数を獲得したESXi02~05側のDiskオブジェクトはアクセス可能なオブジェクトとして稼働を続けます。

    このオブジェクトのロックは、どちらのVirtual SANパーティションを生かすかという全体的な判断ではなく、仮想ディスクごとに行われます。例えば、同じ環境に、許容障害数 = 0で作成されていた仮想ディスクオブジェクトが存在していた場合(下記青色のvmdk)、こちらのオブジェクトはesxi-01上でロックされることなく稼働を続けます。


     

    少し話はそれますが、上記した内容を鑑みると、許容障害数 = nの場合、障害時に少なくともn+1個のオブジェクトが正常なホスト側に残る必要があることが分かります。つまり、許容障害数 = n を構成するためには、最低でも

    n + (n+1) = 2n+1 台

    のホストが必要になります。例えば、3面ミラー(許容障害数 = 2)を構成するためには、最低5台のホストが必要ということになります。



    なお、仮想マシンに関するオブジェクトは仮想ディスクファイル(vmdkファイル)の他に、仮想マシンの構成ファイル(vmxファイル)などが含まれるVMホームオブジェクトも存在しますが、VMホームオブジェクトのロックのアルゴリズムも前記した仮想ディスクファイルと同様となります。

    仮想マシンの可用性

    あらかじめ監視オブジェクトを必要数準備しておき、障害時に過半数のオブジェクトが獲得出来なかったオブジェクトをロックするというアルゴリズムは、障害対応の即時性が高く、仮想ディスクのイメージの一貫性を担保する優れたオブジェクト管理の仕組みです。しかしながら、仮想マシンのサービスレベルを守るという面で考えると、ちょっと困ったことが起こる可能性があります。例えば許容障害数 = 1で作成された仮想マシンがesxi-01上で稼働し、仮想ディスクが以下のように配置されている場合の障害時の動きについて考えてみます。



    esxi-01がネットワーク障害で分断されると、以下のことが起こります。

    • esxi-01上のディスクオブジェクトがロックされる(過半数を確保できないため)
    • ロックされていないミラーオブジェクトはesxi-03上に存在
    • esxi-01 上の仮想マシンのI/Oは Virtual SANネットワークがアクセス不可能なため esxi-03 に到達できない

    このため、仮想マシンのI/Oは停止してしまいます。

    この仮想マシンを正常に稼働させるには、esxi-02~05側で仮想マシンを稼働させる必要がありますが、この動きはVirtual SANではなく、vSphere HAにより担保されます。Virtual SANとvSphere HA は共にクラスタに定義するサービスの1つで、同時に利用することも可能です。しかしながら、例えば上記の例の様な場合に、esxi-01側のミラーオブジェクトがロックされ、アクセス可能なミラーオブジェクトがesxi-03にあることをVirtual SANからvSphere HAに通知するような連係機能は現在のところ実装されていません。つまり、”esxi-02~05側で仮想マシンを稼働させる”ために、vSphere HAが独自に Fail Over 動作を起こす必要があります。

    仮想マシンのサービスレベルを守るためのvSphere HAの設定

    Virtual SAN 環境でvSphere HA を利用した場合、vSphere HAのハートビートネットワークはVirtual SANネットワークを利用します。Virtual SAN 有効時、無効時の vSphere HA の初期設定は以下の通りです。



    vSphere HAには以下の通り4つの状態があり、vSphere HAによる仮想マシンのFail Overは、ホスト障害の際、もしくはホストが隔離状態になった場合に発生します。

    • 正常な状態
    • ネットワークパーティションの状態

      互いのハートビートのみが途切れた状態。ハートビートデータストアによりお互いの稼働が確認され、かつ、両者共に隔離アドレスへのPingも成功する場合はこの状態となります。クラスタは分割されそれぞれが vSphere HA クラスタとして機能します。仮想マシンのFail Overは起こりません。Virtual SAN構成の場合、ハートビートデータストアが無い構成も想定されますが、その場合は、vSphere HA レベルのスプリットブレインとなり、仮想マシンの二重起動が起こる可能性があります。

    • ホスト隔離の状態

      互いのハートビートが途切れ、かつ、障害ホストの隔離アドレスへのPingが失敗する場合この状態となります。仮想マシンのFail Overはオプション設定により可能(初期設定は無効)です。

    • ホスト障害

      仮想マシンはFail Overします

    ネットワーク障害の際には、ネットワークパーティションではなく、ホスト隔離の状態にすること、及び、隔離時に仮想マシンのFail Overが起こるよう設定を施しておくことが必要となります。このため、以下の2点の設定変更を実施します。
     
    1.vShere HAをネットワークパーティションではなく、ホスト隔離状態にする
     
    Virtual SANネットワーク障害時に、隔離アドレスへのPing応答を切断する必要があります。
    このため、vSphere HAの詳細オプションを利用して隔離アドレスをVirtual SANネットワーク側に変更します。
     
     das.usedefaultisolationaddress = false
     das.isolationaddressX = <Virtual SAN Networkより確実にアクセス可能なIP>
     
    2.vSphereHAのオプション設定で、ホスト隔離時の対応を、”パワーオフ後、フェイルオーバー”に設定する


    この2つの設定を施しておけば、Virtual SANネットワークが切断された際、vSphere HAが隔離状態となり、隔離されたホスト上の仮想マシンが、正常なホスト上にFail Overされ、仮想マシンサービスが復旧します。

    ハートビートデータストアに関しては必須ではありませんが、もし存在すれば、相手の状態を正確に把握することが可能となるため、仮想マシンの2 重起動を防止することが可能となります。

    設定変更の影響

    上記の設定は必ずしも全ての仮想マシンの稼働の最大化を図る物ではなく、仮想マシンに想定されるサービスレベルを守るための物です。ここで言う、仮想マシンのサービスレベルとは、

    “許容障害数以内のホスト障害であればサービスが継続、もしくは、 vSphere HA の機能で仮想マシンがFail Overしてサービスが復旧すること”

    を意味します。初期設定では、特にネットワーク障害の際にこの期待値に添えない(仮想マシンのFail Overが起こらない)可能性がありますが、前記した設定を施す事により仮想マシンに想定されるサービスレベルを守ることが可能となります。

    ここで1つ心得ておきたいことは、許容障害数を超えてしまった仮想マシンにとっては、必ずしもこの設定が可用性を向上する物ではないことです。例えば、前記した例で、許容障害数 = 0で作成された青色のvmdkファイルは、esxi-01のネットワーク障害時でも稼働は可能ですが、上記設定に変更してしまうと仮想マシンはパワーオフしてしまいます。今回ご紹介した設定は、仮想マシンに想定されるサービスレベルを守るための設定と理解下さい。

    まとめ

    今回は、Virtual SAN の障害時の動き、及び、Virtual SAN 上の仮想マシンの可⽤性を設計者の意図した通りに担保するための設定についてご紹介させていただきました。繰り返しになりますが、Virtual SAN ネットワークはチーミングによる冗⻑化が可能ですし、その重要性を考えると冗⻑化は必須です。その冗⻑化でも対応できない万が⼀の際にも、仮想マシンのサービスレベルを担保するためのデザイン手法として本資料をご利⽤頂ければ幸いです。

    このブログの内容は、こちらからWhitePaperとしてもダウンロードいただけます。是非ご利用下さい。

    参考情報

    VMware Virtual SAN & vSphere HA Recommendations
    http://blogs.vmware.com/smb/2014/10/vmware-virtual-san-vsphere-ha-recommendations.html

    Hiroshi Okano

    岡野 浩史

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


    P2V!! VMware vCenter Converter Standalone を利用した物理サーバ (Linux) から VMware vSphere 環境への移行

    皆様、こんにちは。VMware の内野です。

    本エントリでは、ブログ [仮想化への移行] シリーズの第二弾として、VMware vCenter Converter Standalone (以下Converter) を利用した物理環境上にインストールされている Linux 環境を vSphere 環境へ P2V (Physical to Virtual) するための実際の手順をお伝えします。

    [仮想化への移行]シリーズ
    ・はじめに
    -移行計画、準備段階でのポイント
    • V2V (Virtual to Virtual)
    - VMware vCenter Converter Standaloneを利用した他の仮想化製品フォーマットから VMware vSphere 環境への移行
    • P2V (Physical to Virtual)
    - VMware vCenter Converter Standalone を利用した物理サーバ (Linux) から vSphere 環境への移行 ←本エントリ
    • I2V (3rd Party Image/Backup Tool to Virtual)
    - 3rd Party Image/Backup Tool から VMware vSphere 環境への移行←Coming soon!!
    • V2C (Virtual to Cloud)
    - VMware Sphere 環境から VMware vCloud Air への移行 ←Coming soon!!

     

     

    -事前準備-

    前回のブログに Converter の入手方法等に関しては記載されております。入手方法等はそちらを確認してください。
    また、インストール手順はこちらのブログが非常に参考になると思います。

    Linux 環境特有の注意点としては、

    移行元の Linux は起動しておく必要があります。

    ・SSH を有効にしておく必要があります。

    ・データベースや Web アプリケーション、ウィルスソフト等のサービスはできるだけ停止してから P2V を実施してください。特にファイルをロックするようなアプリケーションは注意が必要です。

    ・GRUB のみサポートしています(LILO はサポートしておりません)。

    ・HelperVM (移行作業用のテンポラリVMです) 用に IP アドレスが別途、必要です。1 VM を P2V するために 1 つの作業用 IP アドレスが必要になります。

    その他の注意点はこちらの資料の  P29 ページをご確認ください。

     

     

    それでは、実際の移行作業をご説明します。なお、今回は RedHat Enterprise Linux 6.0 にて動作確認を行っております。

    まずは、

    1.VMware vCenter Converter Standalone を起動して、[Convert machine] ボタンをクリックします。

     

    Converter1

     

    2. ウィザードが表示されましたら

    Select source type : “Powered-on machine” を選択

    IP Address or name : 物理Linux の IP アドレス

    User name : Linux のユーザー名

    Password : Linux のパスワード

    OS Family : “Linux” を選択

    と順番に選択して、[Next] ボタンをクリックします。

    Converter2

    3. 証明書の画面が表示されるので、[Yes] ボタンをクリックします。

    Converter3

    4. 指定した物理 Linux の名前やバージョン、設定情報が表示されるので、[Close] ボタンをクリックします。

    Converter4

    5. ウィザードの次の画面で移行する vCenter の

    IP アドレス : vCenter の IP アドレス

    user name : vCenter の管理者ユーザー名

    password : vCenter の管理者ユーザーのパスワード

    情報を入力して、[Next] ボタンをクリックします。

    Converter7

    6. 移行先の ESX を選択して、[Next] ボタンをクリックします。なお、こちらの画面で移行先の仮想マシンバージョンや保存先のデータストアの指定を行うことが可能です。

    Converter8

    7. 仮想マシン名を指定して、仮想マシンフォルダを選択して、[Next] ボタンをクリックします。

    Converter9

     

    8.今回、検証した環境では、仮想環境のディスク容量が足りずにエラーが発見されました。そのため、ディスク設定を変更するため、”Edit” をクリックします。

    Converter11

    9. “Advanced” をクリックします。

    Converter23

    10. “Destination layout” タブをクリックして、容量が超えてしまっているディスクを “Thin” ディスクをへ修正します。

    Converter13

    11. “Devices”  の各設定画面は下記の通りです。メモリの容量変更などを行うことができます。

    Converter14

    12.  ”Network” の各設定画面は下記の通りです。ネットワークタイプ等を選択することができます。

    Converter15

    13.  ”Advanced Option” の各設定画面は下記の通りです。”Power on destination machine” と “Power off source machine” 両方のチェックボックスをオンにすると、P2V 終了後、自動的に物理環境の Linux がシャットダウンして、仮想環境の Linux が起動してきます。

    Converter16

     

    15. 最後に [Helper VM network configuration] をクリックして、[Network] タブのネットワーク設定を行います。この設定を行わないと P2V に失敗しますので、ご注意ください。

    Converter24

    ## 補足 ##

    Helper VM の設定を行わない場合、下記の様なエラーメッセージが表示されます。下記のエラーメッセージが表示された場合は Helper VM のネットワーク設定を確認してください。

    Converter22

    16.  最後に設定内容を確認して、[Finish] ボタンをクリックします。Converter18

    17. P2V のジョブが実行 (Running) されたことを確認して、ジョブが終了するまで待機します。

    Converter19

    18. ジョブが成功すると、ステータスが “Completed” になります。

    Converter28

    19. 仮想マシンを起動して、Linux が起動してくることを確認します。その後、設定情報や VMtools 等のインストール等を実施してください。

    Converter30

     

    いかがでしたでしょうか? 私たちが今回、検証した環境では検証環境の物理環境を準備する部分の方が非常に手間がかかり改めて仮想化環境の便利さを再確認することができました。

    VMware vCenter Converter Standalone を使えば、簡単に物理環境の Linux を vSphere 環境に移行することができますので、物理環境の保守切れやシステム更新の際などには P2V 作業を入り口に vSphere 環境で効率適な運用を目指してみてはいかがでしょうか。

    来週はサードパーティー製品を利用したイメージツールからの P2V の実施方法をご紹介させて頂きます。

    [仮想化への移行]シリーズ
    ・はじめに
    -移行計画、準備段階でのポイント
    • V2V (Virtual to Virtual)
    VMware vCenter Converter Standaloneを利用した他の仮想化製品フォーマットから VMware vSphere 環境への移行
    • P2V (Physical to Virtual)
    - VMware vCenter Converter Standalone を利用した物理サーバ (Linux) から VMware vSphere 環境への移行 ←本エントリ
    • I2V (3rd Party Image/Backup Tool to Virtual)
    - 3rd Party Image/Backup Tool から VMware vSphere 環境への移行←Coming soon!!
    • V2C (Virtual to Cloud)
    - VMware Sphere 環境から VMware vCloud Air への移行 ←Coming soon!!

    【SE必見】最新版 vSphere を使おう!~簡単バージョンアップのご案内~vCenter Server 編

    皆様、こんにちは。VMware山口です。

    正常に動いている仮想環境に手を入れる(バージョンアップ)のはあまり気が進まないと思います。しかし新機能は使ってみたい。
    今回は、そんな旧バージョン VMware vSphere (以降vSphere)をお使いの方が、vSphere の最新バージョンに移行するための簡単移行方法をご紹介します。
    あまりに簡単で拍子抜けしてしまうかもしれませんが、それもまたサーバ仮想化の恩恵の一つです。
    最新バーションを利用するメリットは第1回のこちらをご覧下さい。

    公式のアップグレードの方法は、こちらをご参照ください。
    公式のアップグレード方式は基本的にインプレースアップグレード(既存環境そのものをアップグレード)になります。

    今回ご紹介するのは、名付けて” 頭据え替え移行 ”とでも呼びますでしょうか。
    弊社のKBでも紹介されている方式を活用した移行方法となっています。
    詳しくはこちらをご参照ください。

    この移行のメリットは、新旧環境の平行稼働が可能で、仮想マシンを自分のタイミングで移行してみて、
    問題があれば、簡単に戻せる点です。

    逆にデメリットは、旧 VMware vCenter Server(以降vCenter)の リソースプールや HAなどの設定情報が引き継げない点ですがメリットにもある通り平行稼働できますので、前を参考にし、動きを確認しながら引き継げます。
    また、同様にこれまで蓄積したパフォーマンスなどの統計情報が持ち運べないという点です。
    まさに割り切りタイプの移行と言えますので、これを了承頂ける方のみで実施をお願いいたします。

    早速ですが、図の仮想環境例を使って、手順概要を確認していきます。

    ★既存仮想環境例★
    ・vCenter 4.1U1
    ・ESXi 4.1 U1
    ・ホスト3台
    ・共有ストレージ (iSCSI)
    スクリーンショット 2014-11-27 16.23.31

    図1:vSphere 4.1U1 の仮想環境の例
    <ステップ1>
    ①VMware ESXi 5.5 (以降ESXi)をインストールします。
    この例では3ホストあるので、旧環境を縮退させて、1ホストに新しくインストールします。
    注1)お持ちの ESXi ホストが vSphere の最新バージョンに対応しているかは、こちらで確認してください。
    注2)新しくインストールする前に、ESXiは元に戻せるよう、バックアップを取得して実施をお勧めします。
    ESXiホストのバックアップ・リストアはこちらを参考にしてください。

    ②新しくインストールしたホスト上に vCenter 5.5 アプライアンスをインストールします。
    なお、新環境では、vCenter アプライアンスを強くお勧めします。
    Linux ベースの仮想アプライアンスなのでインストールもあっと言う間に終わります。それでいて大規模環境にも対応するスペックを持っています。
    詳しくはこちらをご参照ください。
    スクリーンショット 2014-11-27 16.23.59

    図2:vSphere 最新バージョンのインストール
    <ステップ2>
    ③新vCenter 配下に新ESXiを所属させたら、旧環境のデータストア(仮想マシンが格納されている)を
    新環境に参照させます。
    ④新vCenterより、データストアブラウザを利用して、移行対象の仮想マシンをインベントリ登録します。
    わずかこれだけで、新環境へ仮想マシンを移行したことになります。
    再度、戻したい場合は、旧vCenterで再度インベントリ登録をしてあげればOKです。

    スクリーンショット 2014-11-27 16.24.27

    図3:新旧環境のデータストア共有とインベントリ登録
    <ステップ3>
    ⑤最新バージョンの機能をフルに使う為には、仮想マシンバージョンをアップグレードする必要があります。
    この例ですと、仮想マシンバージョン7−>10にします。
    注3)この操作で旧環境に戻すことが出来なくなるので、旧環境でクローンなどで一時的にバックアップしておくことをお勧めします。

    ⑥最後にデータストアのファイルシステムをアップグレード(VMFS3ー>5)します。
    注4)これも旧環境では参照できなくなりますので必ず仮想マシンの移行がすべて終わってから実施してください。
    スクリーンショット 2014-11-27 16.24.40

    図4:仮想マシンバージョンとVMFSのアップグレード
    最後に、ライセンスですが、お試し頂く場合は、評価ライセンス版の60日で対応お願いします。
    本格的に移行する際、お持ちのライセンスが最新バージョンに対応していない場合は、アップグレードする必要があります。
    こちらを参照ください。

    ★★おまけ★★
    実際の移行オペレーションで重要なポイントを解説動画でご案内します。

    ステップ1:②vCenterアプライアンスインストール時のポイント
    ★初期セットアップ時のIPアドレス設定
    初回アクセスの為に設定するIPアドレスにテクニックが必要です。
    vCenterアプライアンスは初回起動時、IPアドレスが設定されていない為、DHCPクライアントの状態です。
    デプロイされたVM NetworkにDHCPサーバが存在しない場合は、IPアドレスが付与されない状態で起動しますので
    手動設定が必要です。詳しくは、こちらの動画をご覧下さい。

    ★デフォルトパスワード変更
    必ずデフォルトパスワードを変更してください。また、デフォルトですと90日でパスワードが失効するように
    設定されています。失効してしまうと復旧させるのがとても大変なので必要な方はこれを無効にしてください。
    vCenterアプライアンスの管理画面にて、Adminタブ>Administrator password expiresをNoに変更し、Submitをクリック
    詳しくは、こちらの動画をご覧下さい。

    ステップ2:③、④の手順で特にははまりポイントはありませんが、こちらの動画をご覧下さい。
    ★移行後、仮想マシンを初回起動する際に、コピーしたか移動したかの設問があります。

    ステップ3:⑤、⑥のアップグレードはもとに戻せなくなるので注意しながら実施してください。
    ⑤対象の仮想マシンを右クリック>すべてのvCenterアクション>互換性>仮想マシン互換性のアップグレード
    ⑥対象のデータストアを右クリック>すべてのvCenterアクション>VMFS-5へアップグレード
    ★VMware toolsも最新版にあげておくことをお勧めします。

    いかがでしたでしょうか?
    既存環境をさわるのは、ちょっと気がすすまないけど、新しいvSphereの機能は使ってみないなぁー
    という皆様、ご覧の通り平行稼働できますので是非お試しください。

    〜本シリーズの流れ〜
    -第1回 最新版 vSphere を使おう!~簡単バージョンアップのご案内~メリット編
    -第2回 最新版 vSphere を使おう!~簡単バージョンアップのご案内~vCenter Server 編 本記事
    -第3回 最新版 vSphere を使おう!~簡単バージョンアップのご案内~便利ツール vSphere Update Manager 編 Coming soon!