Home > Blogs > Japan Cloud Infrastructure Blog

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!

    V2V! Hyper-V上の仮想マシンをvSphere環境に移行する方法

    皆様こんにちは。
    本エントリでは、ブログ[仮想化への移行]シリーズの第一弾として、VMware vCenter Converter Standalone(以下Converter)を利用した、Hyper-V環境からvSphere環境への仮想マシンのV2V(Virtual 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 への移行←Comming soon!!

     

    事前の確認さえ怠らなければ、Converterを使用したV2Vの作業はそれほど難しいものではありません

    -事前準備-
    1)   Converterを入手しましょう!

    ConverterはMy VMwareのアカウントさえ作成すれば、どなたでもダウンロード可能です。My VMwareのアカウント作成方法はこちら。 Converterのダウンロードページはこちら

    converterDL

    2)   ドキュメントを確認しましょう!

    Converterの公式ドキュメントは、主にUser’s GuideとRelease noteです。こちらから参照できますので、できるだけ確認しておきましょう。英語で心が折れそう…という方のために(私もですが)、この先の作業でドキュメントのどこを確認すれば良いかは、できるだけお伝えしていきます。

    Converter関連のKBもいくつか出ていますが、以下のKBについては事前にご確認いただくことを推奨します。
    VMware Converter の使用とトラブルシューティングに関するベスト プラクティス (1033253)

     

    3)   Converterをインストールしましょう!

    Converterを作業用のWindows端末にインストールします。
    ConverterをインストールできるOSは、こちらのRelease note内、[Platforms]の項に記載があります。

    注意 : Windows Server 2008 R2のHyper-V上に存在する仮想マシンをV2Vしたい場合に、ペアレントOSであるWindows Server 2008 R2に直接Converterをインストールしないでください。作業の途中で、Converter agentの送り込みに失敗する場合があります。

    converterinst

    4)   Converterでの移行がサポートされるゲストOSを確認しましょう!

    こちらのUser’s Guide内、[Supported Operating Systems]に対応するOSの一覧がありますので、移行対象の仮想マシンのOSがConverterでサポートされているか、事前に確認しておきましょう。Windows ServerであればR2やSPxxの部分までしっかりと確認が必要です。

     

    それでは、実際の移行作業をご説明します。
    作業自体は 、こちらのブログにあるようなP2Vの方法とほとんど同じですが、Hyper-V上の仮想マシンを移行する場合には2パターンの方法があります。

    ①移行元として、Hyper-Vを指定する方法
    ②移行元として、Hyper-V上のパワーオン仮想マシンを直接指定する方法
    ①、②について、これから解説していきます。

     

    ①移行元として、Hyper-Vを指定する方法

    こちらのUser’s Guide内の [Supported Source Types]の[Hyper-V Server virtual machines]に記載のあるものは、Hyper-Vを指定する方法が使えます。

    主な注意点としては
    ・Hyper-V上の移行対象仮想マシンがパワーオフ状態であること(コールドクローン)
    ・本エントリの執筆時点では、Converterが対応しているハイパーバイザーはWindows Server 2008 R2 のHyper-Vのみであること
    ・移行対象の仮想マシンは、事前にIPをDHCPに設定しておくこと(移行後に非表示のデバイスがIPを保持してしまうことがあるため)
    等が挙げられます。2008 R2以外のHyper-V上で動作している仮想マシンを移行したい場合は後述する②の方法、または今後リリース予定のI2Vブログを参考にしてください

    それでは、①の作業を見ていきましょう
    STEP1: 移行対象の仮想マシンがパワーオフ状態であることを確認します

    2008Hyper-V

    STEP2: 作業端末上でConverterを起動し、Convert Machineをクリックします

    ConverterOpe01

    STEP3: 移行元を指定します。ここで、Select source typeから [Hyper-V Server] を選択し、Hyper-VのペアレントOSであるWindows Server 2008 R2のIPを指定します。ホスト名で指定することも可能ですが、上述のKBにも記載のある通り、DNS関連の不要なトラブルを回避するためにIPを指定しましょう

    ConverterOpe02 ConverterOpe03

    STEP4: 移行完了後にConverter agentを自動で削除するか、手動で削除するかを選択します。特に理由がなければ、自動での削除を選択しましょう。Nextをクリックすると移行元のWindows Server 2008 R2に対して、Converterがagentを送り込みます。ここでagentの送り込みに失敗する場合は、こちらのKBを確認してみてください

    agentpush

     

    STEP5: 対象のHyper-V上に存在する仮想マシンの一覧が表示されますので、移行したい仮想マシンを選択します。パワーオン状態の仮想マシンは選択できません

    ConverterOpe05

    STEP6:  移行先となるESXi (ESXiがvCenterの管理下に存在している場合はvCenter)のIP、ユーザ名、パスワードを入力します

    ConverterOpe06STEP7: Security Warningが出た場合は、[Ignore]をクリック

    ConverterOpe07STEP8: 移行先で仮想マシン名を変更したい場合は、[Name]に新しい仮想マシン名を入力します

    ConverterOpe08STEP9: 移行先のESXiが複数のデータストアを持っている場合は、ここで仮想マシンのデータストアを選択します

    ConverterOpe09STEP10: 移行のタイミングで仮想マシンのディスクサイズや割り当てるCPU数、メモリサイズ等を変更したい場合は、[Edit]から変更することができます

    ConverterOpe10

     

    STEP11: 最後に確認画面が出ますので、[Finish]を選択すれば実際の移行が始まりますConverterOpe11STEP12: 移行の状況は、Converterの画面上で確認できます。もしここで移行に失敗する場合は、VMwareのKBでエラーメッセージ等を調べてみてください

    ConverterOpeP07

    STEP13: 移行が完了すればESXi上に仮想マシンが見えていますので、仮想マシンをパワーオンしてみましょう

    vSphere1STEP14: 仮想マシンをパワーオンすると、ドライバをインストールするOSの処理が開始されますので、完了を待ってから、1度仮想マシンを再起動しておきましょう

    以上で①移行元として、Hyper-Vを指定する方法の解説は終了となります!

     

     

    ②移行元として、Hyper-V上のパワーオン仮想マシンを直接指定する方法

    こちらの方法では、Hyper-V上のパワーオン状態の仮想マシンを移行対象として直接指定します。
    移行対象の仮想マシンを[物理サーバ]と見なして、P2V (Physical to Virtual)とまったく同じ手順で移行を実施します。
    パワーオン状態で仮想マシンを移行することをホットクローンと呼びます。ホットクローンについての説明はこちらのブログに説明がありますが、重要なポイントとして、OS は起動していますが基本的には利用者にサービスを提供したまま移行を継続できるといった機能ではないという点にご注意下さい。

    それでは、②の作業を見ていきましょう。作業の大半は①の方法と同じです。

    STEP1: 移行対象の仮想マシンがパワーオン状態であることを確認します。

    2012

     

    STEP2: 作業端末上でConverterを起動し、Convert Machineをクリックします。

    ConverterOpe01

    STEP3: Select source typeで[Powered-on machine]を選択し、移行対象の仮想マシンが持っているIPとユーザー名、パスワード、OS種別を入力します。

    ConverterOpeP01

    STEP4: 移行完了後にConverter agentを自動で削除するか、手動で削除するかを選択します。特に理由がなければ、自動での削除を選択しましょう。Nextをクリックすると移行対象の仮想マシンに対して、Converterがagentを送り込みます。ここでagentの送り込みに失敗する場合は、こちらのKBを確認してみてください。

    agentpush

     

    ここから先の手順は、上述の①移行元として、Hyper-Vを指定する方法内のSTEP6以降とまったく同じなので、そちらを参照してください。

     

    いかがでしたでしょうか? Converterを使用すれば、このように簡単にHyper-V上の仮想マシンをvSphere環境に移行することができます!
    次週以降で、下記の[仮想化への移行]シリーズを投稿していきますので、こちらもお楽しみに!

    [仮想化への移行]シリーズ
    ・はじめに
    -移行計画、準備段階でのポイント
    • 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 への移行←Comming soon!!

    【SE必見】vSphere 最新バージョンを使おう!~簡単移行方法のご案内~メリット編

    こんにちは!VMwareの中村です。

    突然ですが、皆様お使いのVMware vSphereですがどのバージョンをお使いでしょうか?
    現在(執筆時点)VMware vSphereの最新バージョンは5.5 u2ですが、VMware vSphere 4.x をお使いのユーザ様も多いのではないのでしょうか?HWとして実装するとコスト高になってしまう機能も、VMware vSphere 5.5 環境では、その機能をVMware vSphereで実装することにより、コスト的に敷居が下がるかもしれません。とはいいつつも移行するのは大変ですよね。本記事ではまずVMware vSphere 5.5 においてどのようなことができるのか?をご紹介し、シリーズ2回目以降に簡単な移行方法をご紹介していきます。

    〜第1回ブログの内容〜
    ★vCPU数の制限緩和について
    ★VMware vSphere 4.x をお持ちの方は…(特にstandard エディションをお持ちの方)
    ★サポート期間について
    ★主な新機能やエンハンス機能について 
    ★データ保護機能
    ★消費電力の違い…

    では、改めて….になりますが、VMware vSphere 5.5 で何ができるようになったのか?等ご紹介していきます。

    ★vCPU数の制限緩和について

    まずVMware vSphere 5.5ではvCPU数の制限が緩和された事をご紹介します。
    VMware vSphere 5.5 からvCPU数(仮想マシンで認識できるCPU数)の制限がなくなっております。
    古いバージョンですと、ライセンスのエディションに依存したvCPU数制限がありましたが、
    VMware vSphere 5.5ではエディションに依存した制限がなくなっております。
    kb.vmware.com/kb/2001113

    vCPU数1-1
    図1 vCPU数について

    ★VMware vSphere 4.x Standard をお持ちのお客様は….

    VMware vSphere 5.x に移行していただくと、Storage vMotionの機能が使用できます。VMware vSphere 4.x ですと
    Storage vMotionの機能はStandardエディションでは使用できませんでしたが、VMware vSphere 5.x 以上では使用できます♪
    この機能は仮想マシンをストレージ間(データストア間)で無停止移行することができる便利な機能です。VMware vSphereで
    よく使用されている機能の一つとなっております。

    また VMware vSphere 5.1 からクロスホストvMotionといって、共有ストレージがない環境でもvMotionをすることが可能です。

    ★サポート期間について

    vSphere 5.5 に移行することによって、サポート期間が更新されます。このサポート期間についても少しみていきましょう。
    ジェネラルサポートはメジャーリリースの一般発売日から指定された期日で終了します。
    vSphereの場合、このジェネラルサポートは5年となっておりvSphere 5.0 / 5.1 のお客様において、ジェネラルサポートの終了が
    2016年8月24日となっておりますが、vSphere 5.5 においてはメジャーリリース扱いとなっておりますので、ジェネラルサポートの終了が2018年9月19日までとなっております。

    サポートポリシーのフェーズについて
    製品ライフサイクルマトリックス

    図2 vSphere 5.5 サポート期間
    図2 vSphere 5.5 のサポート期間

    ★主な新機能やエンハンス機能について

    ここではvSphere 5.5 から加わった新機能3つをご紹介します。
    -パフォーマンスの向上:vFlash Read Cache (vFRC)
    -アプリケーションまで監視: App HA
    -ESXiのメモリ信頼性の向上: Reliable Memory

    VMware vSphere 5.5から新しい機能として主に上記の機能が加わっております。
    vFRC についてはホストでキャッシュしパフォーマンス向上をはかる仕組みです。
    また可用性の向上としてアプリケーションの状態まで監視できる App HA という機能も加わっております。
    インフラレベルではPSOD (Purple Screen of Death) の予防として Reliable Memory の機能が追加されております。

    パフォーマンスの向上や信頼性の向上、という意味では他の方法で実装することもできますが、vFRC や App HA 等
    vSphere = ソフトウエアで実現することによって、よりコスト的に敷居が下がるかもしれません。
    是非VMware vSphere 5.5 で実装できる機能をご活用ください。
    vSphere 5.5 の機能概要過去ブログ

    ★エンハンスされたデータ保護機能概要

    vSphereにはデータ保護機能がありますが、vSphere 5.5からエンハンスされた内容をみてみましょう。
    -管理DRの実現: vSphere Replication (vR)
    -データ保護の実現: vSphere Data Protection (vDP)

    大分おなじみになってきた vSphere Replication。
    仮想マシン単位に遠隔地へデータをコピーし、システムに何かしら不測の事態が起きた際等に
    瞬時に切り替える機能です。こちらはvSphere 5.5 から複数の復帰ポイントが保持できるようになっております。
    これにより、どの時点のイメージで切り替えたい等、柔軟なオペレーションができるようになっております。

    またvSphereに盛り込まれているバックアップ機能vSphere Data Protection (vDP) では
    バックアップ開始時間のスケジューリングが分単位で設定できるようになっております。
    -簡易DRを実現する、vSphere Replicationの概要
    -データ保護を実現するvSphere Data Protectionの概要

    ★VMware vCenter Server Appliance (vCSA) のエンハンス

    vCenter Appliance (vCSA) も5.5からパワーアップしております。vCSA 5.1 まではあくまでも小規模向けでしたが
    vCSA 5.5はそこそこの規模 (ESXi 100台/仮想マシン規模3000台)をカバーできる仕様になっております。
    もちろん、データベース、AutoDeploy Server やSyslog Collecter もはインストールされております。また Windows 版の vCenter に関しては、OS部分に関するパッチ適用作業も必要になるかと思いますが、その作業も減らすこともできますので、運用にもやさしいです。VMware vSphere 5.5 になってから、この vCSA を使用されるお客様が増えてきております。

    ★注目の VMware NSX の機能を使うためには?

    また、いま注目度No1のネットワーク仮想化におけるNSXですが、NSXをご使用するには vCenter のバージョン 5.5が必須です。
    また推奨としては分散仮想スイッチバージョン (vDS) も5.5となりますのでNSXが気になる…という方は是非こちらもご検討ください。

    ★最後に

    あまり話しにでることが多くはないのですが、vSphere 5.5 は消費電力にも優しいです。負荷によっては、節電効果も大きくなってきております。台数が多くなればこちらの効果も大きくなってきておりますので、こちらもぜひご参照ください。

    図3 消費電力

    図3 各vSphereにおいて負荷と消費電力の関係
    参照:http://www.vmware.com/files/pdf/techpaper/hpm-perf-vsphere55.pdf

    vSphere 5.5 にするとどのようなことができるようになったのか?を簡単にご紹介してまいりました。
    では次回からは実際にどのように5.5 環境へ移行するかをご紹介してまいりますのでお楽しみに!!

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

    仮想化への移行

    皆さん、こんにちはVMwareの北村です。

    昨今、企業のITインフラにおいて仮想化技術を使用したサーバ統合は欠かせない選択肢の1つとなっており、既存インフラの延命や新規インフラの整備において仮想化基盤を構築するケースも珍しい事ではなくなってきています。また、既に仮想化基盤を運用してはいるものの何かしらの理由で他社製仮想化基盤への移行を余儀なくされたり、現在の仮想化基盤とパブリック・クラウドの併用を行う必要が出てきた、など、単なる仮想化基盤の構築だけにとどまらず、仮想化への移行に以前と比べ選択肢が増えてきたのも事実です。この際に、既存の物理サーバ環境をどの様に仮想環境へ移行していくか、また、既に構築済みの仮想環境を他社製仮想化基盤へ移行するか、はたまた、オンプレミスの仮想化基盤からいかにクラウドへ移行するか、という点は移行を検討する上で重要なポイントだと言えます。

    そこで、“仮想化への移行” として、次回以降、実機検証の結果を元に次のテーマでブログをご紹介していく予定です。

    • 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 への移行

    補足:
    “仮想化への移行” としては、2つのブログ ”VMware vCenter Converter で P2V, V2V ~ 第1回 仮想環境におけるサーバ移行 (P2V, V2V) の基本“ と ”VMware vCenter Converter のインストールと Windows 2003 のP2V“ を投稿してきていますが、期間がしばらく空いてしまった事もあり、内容を再考し、年内に上記のポイントでご紹介していく予定です。

     

    今回は仮想化への移行全般に関わる次の各フェーズについて、ポイント (ベストプラクティス、および、TIPS) をご紹介します (以下のポイントは、VMware vCenter Server Converter Standalone を使用した P2V、V2V、および、サードパーティ製ツールを使用した I2V を前提としていますが、仮想化への移行を検討される際のヒントとして活用して頂ければ幸いです)。
    step0

     

    移行計画:
    step1
    • 計画段階で検討すべき項目
      - 対象台数は何台
      - いつまでに移行させるか
      - 移行対象の OS の種類
      - 移行方法は何を使うのか
      - P2V できなかった場合の対応 (サードパーティ / 移行しない / 新規構築)
      - 移行対象のデータ容量
      - サービス(業務)停止許容時間
      - 使用アプリケーションの仮想環境上でのサポート有無
      - 使用アプリケーションのライセンス認証方法 (MACアドレスやドングル等)
      - 使用している周辺デバイスの有無と物理マシンへの接続方法
      - 既存物理環境でのパフォーマンスやスローダウンなどの問題があるか
      - 移行先の仮想環境のキャパシティ
      - 移行後の管理手法 (監視・バックアップ)

     

    事前テスト:
    step2
    • 事前に物理マシンのタイプをグルーピングし、グループ単位でテストを行い確認する
      - ハードウェア構成ごと
      - オペレーティングシステムの種類ごと
    • テストで確認すべき項目
      - 作業手順の流れの確認
      - 移行作業にかかる時間
      - P2V 時に使用されるポートでの通信可否確認
      - 停止するサービスの確認
      - 物理ハードウエア監視ツールによる P2V への影響確認
      - 既存ネットワークを使用する場合、P2V 時のネットワークへの影響確認
      - P2V 作業後の確認 (削除するデバイス、アプリケーション、ドライバ等)
      - 正常性を確認する手順
     など

    正常性確認のためのヒント:
    • インフラ側では OS レベルの正常性確認までの確認が一般的
      - OS の正常起動
      - イベントログ確認 (エラーが出ていないこと)
      - 通信確認 (仮想マシン外部ネットワーク)
    • アプリケーションはアプリ担当やアプリベンダでの対応が必要
      - アプリケーションとしての動作確認
      - 業務システム視点での動作確認
    • 異常と言われることが多いもの
      - 遅くなった⇒物理環境でも同様のことが発生していないか確認
       - 物理で起きていることは仮想にしても発生する
       - 物理で発生していることで仮想マシンリソースを増やせば改善することが予測される場合、
        その場で対処せず P2V 完了後に対策を行う

     

    移行準備:
    step3
    • 事前実施 (万が一の場合の復旧のために行うことを推奨)
      - 移行元のバックアップ
      - バックアップ後のイベントログ/Syslog を確認し再起動を実施
      - 再起動後のイベントログ/Syslog を確認し、P2V 後の問題切り分けの情報とすると共に、P2V自体によって発生した
       メッセージかどうかを見極めることで P2V 作業による責任範囲を明確にする
    • 事前準備
      - VMware vCenter Converter Standalone
      - Windows の場合、移行予定の OS のメディアとライセンスキー (物理サーバ付属の OEM ライセンスは、当該サーバ上で
       仮想化する場合にのみ使用できるものなので、他の物理サーバに移行させる場合は別途ライセンスが必要)
      - 作業手順書
      - 既存マシン設定パラメータシート (IPアドレス、ホスト名、ライセンスキー等)
      - 作業チェックシート
      - 既存ネットワークから独立させて作業をする場合、ネットワークケーブルとスイッチ

     

    移行作業:
    step4
    • 移行作業に入る前に
      - 既存環境の情報収集
       - ネットワーク設定を既存マシン設定パラメータシートに転記 (P2V 後はアドレスがクリアされる)
       - イベントログ / syslog 取得 (再起動して起動時に発生するエラーも事前に確認しておく)
        - 事前状態の保存
        - 元々出ていたエラーの切り分け
        - 古い物理マシンの場合、再起動できなくなるリスクもあることも注意する
    • 移行作業の実行
      - 以下のツールなどを利用した移行の実行
       - VMware vCenter Converter Standalone
       - 3rd Party Image/Backup Tool
    • 移行作業後に始めて仮想マシンを起動する前に行う作業
      - 仮想マシンスナップショットを取得 (セーブポイントの作成)
      - 仮想マシンハードウェアから必要ないデバイスを削除 (USB コントローラ、シリアルポート、パラレルポート、フロッピードライブ)
      - SCSI コントローラを確認・変更 (LSI Logic にする)
      - ネットワーク接続を「起動時に接続」オプションをはずす (コンフリクト防止)
      - ハードウエアベンダによっては、ハードウエア監視ツールが仮想化後に残っていると仮想マシンの起動に時間が掛かるなどの
       問題が発生することがあるので、可能であれば外す
      - P2V 作業時に不要なサービスを停止する
       - エージェントの導入後に再起動が入る可能性があるので、可能であればサービスを手動に変更して起動しないようにする
       - 変更したサービスは既存マシン設定パラメータシートに記入し、P2V作業後にサービス設定変更漏れが出ないようにする

     

    移行完了後のクリーンナップ作業:
    step5
    • 仮想マシンを起動してから行う作業
      - 不要なアプリ・デバイス・ドライバを削除 (H/W 監視ツール、RAID 管理ツール、チーミングドライバ、H/W ベンダーのその他
       ツール・ユーティリティ、バックアップソフト、ビデオカードドライバ、サウンドカードドライバ、その他不要なデバイスなど)
      - 上記はクリーンインストールした仮想マシンと比較するとわかりやすい
      - VMware Tools のインストール
      - 既存マシン設定パラメータシートを参照しネットワークの設定を行う
      - 既存マシン設定パラメータシートを参照しサービスの設定の復旧を行う
      - ログの確認とスナップショットの削除で完了 (スナップショット取得以降に発生した変更差分の領域が想定外のディスク容量が
       消費されてしまい、システムに影響を与える可能性があるため、スナップショットを取得した際には忘れずに削除する事)

     

    まとめ:
    • 事前に移行部門と調整し、停止時間の調整から移行後の確認検証なども協力を得られるようにしておく
    • 移行作業手順をあらかじめ作成し、漏れやミスが無いように対策する
    • 移行作業時間はトラブルも考慮し余裕を持って計画する
    • 移行を行う物理マシンの情報を事前にしっかり把握し、対策をしておく
    • いくつかの物理マシンのコンバートを平行作業で行う場合、移行先ホスト及びストレージの I/O 負荷も考慮する
    • 使用するネットワークの帯域や負荷などによる作業への影響も考慮する
    • 移行トラブル時にどうするかをしっかり決めておく (別手段、P2V 除外など)
    • 可能であれば事前にテスト移行を実施しておく
    • 移行対象物理サーバは、移行作業実行前に必ずバックアップを取っておく
    • 移行対象物理マシンでは、全てのサービスは提供しない状態で実施する
    • ハードウエアに依存した監視ツールは事前に削除しておくか、コンバート後に起動しないようサービスの設定を変更する
    • 仮想マシンに移行できたら、設定変更した部分は元に戻すのを忘れない

     

    今回は仮想化への移行全般に関わる各フェーズと各フェーズにおけるポイント (ベストプラクティス、および、TIPS) をご紹介しました。次回以降は実機検証の結果を元にブログをご紹介していく予定ですので、是非、お楽しみに!