Home > Blogs > Japan Cloud Infrastructure Blog

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

皆様、こんにちは。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 vSpehre 環境への移行
I2V (3rd Party Image/Backup Tool to Virtual)
- 3rd Party Image/Backup Tool から VMware vSpehre 環境への移行←本エントリ
V2C (Virtual to Cloud)
- VMware Spehre 環境から 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環境での詳細移行手順
⇒ 近日公開予定

 

□まとめ

いかがでしたでしょうか?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 vSpehre 環境への移行
• I2V (3rd Party Image/Backup Tool to Virtual)
- 3rd Party Image/Backup Tool から VMware vSpehre 環境への移行←本エントリ
• V2C (Virtual to Cloud)
- VMware Spehre 環境から 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 vSpehre 環境への移行

    皆様、こんにちは。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) から VMware vSpehre 環境への移行 ←本エントリ
    • I2V (3rd Party Image/Backup Tool to Virtual)
    - 3rd Party Image/Backup Tool から VMware vSpehre 環境への移行←Coming soon!!
    • V2C (Virtual to Cloud)
    - VMware Spehre 環境から 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 vSpehre 環境への移行 ←本エントリ
    • I2V (3rd Party Image/Backup Tool to Virtual)
    - 3rd Party Image/Backup Tool から VMware vSpehre 環境への移行←Coming soon!!
    • V2C (Virtual to Cloud)
    - VMware Spehre 環境から 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 vSpehre 環境への移行 ← Coming soon!!
    • I2V (3rd Party Image/Backup Tool to Virtual)
    - 3rd Party Image/Backup Tool から VMware vSpehre 環境への移行←Coming soon!!
    • V2C (Virtual to Cloud)
    - VMware Spehre 環境から VMware vCloud Air への移行 ←Coming 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 vSpehre 環境への移行 ← Coming soon!!
    • I2V (3rd Party Image/Backup Tool to Virtual)
    - 3rd Party Image/Backup Tool から VMware vSpehre 環境への移行←Coming soon!!
    • V2C (Virtual to Cloud)
    - VMware Spehre 環境から VMware vCloud Air への移行 ←Coming 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 vSpehre 環境への移行
    • I2V (3rd Party Image/Backup Tool to Virtual)
      - 3rd Party Image/Backup Tool から VMware vSpehre 環境への移行
    • V2C (Virtual to Cloud)
      - VMware Spehre 環境から 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) をご紹介しました。次回以降は実機検証の結果を元にブログをご紹介していく予定ですので、是非、お楽しみに!

    EMCストレージ EMC Storage Analytics と vRealize Operations Manager の連携をご紹介!

    みなさんこんにちは。
    VMware vRealize Operations Manager (vR Ops) のストレージとの連携機能について、今回は EMC Storage 「EMC Storage Analytics」と連携した機能を vExpert であります EMC ジャパンの吉田 尚壮様にご紹介いただきます。
    それでは吉田様、よろしくお願いいたします。


    こんにちは。EMC ジャパンの吉田です。

    今回は、vR Ops と EMC ストレージを連携させる「EMC Storage Analytics」(以下 ESA)をご紹介いたします。 ESA は、vR Ops 向け EMC ストレージアダプターの名称です。現時点では、下記 EMC ストレージ製品( VMAX、VNX、VNXe および VPLEX)からそれぞれ専用のアダプターが提供されています(図 1)。それらのアダプターを vR Ops にロードすることで、ストレージ内部の情報が vR Ops のダッシュボードに表示できるようになります。

    図1 EMC が提供しているストレージアダプター EMC1

    ※vCenter Operations Manager は、vRealize Operations Manager に名称変更されました。

     

    ESA のダッシュボード

    ESA のアダプターを vR Ops にロードすると、vR Ops のダッシュボードに ESA のタブが現れます(図2)。これらのタブには、予めトポロジーマップやヒートマップ、メトリックグラフなどが仕込まれています(図3)。その後、監視対象のストレージを登録すると、ストレージ内部の様々な情報が vR Ops 上に表示されます。

     

    図2 そのまま利用できる ESA のタブ EMC2

    ※vCenter Operations Manager は、vRealize Operations Manager に名称変更されました。

     

    図3 直感的に状態が把握できるヒートマップ

    EMC3

    ※vCenter Operations Manager は、vRealize Operations Manager に名称変更されました。

     

    ESA の活用例

    システムで性能問題が発生した場合、素早く原因を特定する必要があります。一般的に、ストレージ装置において性能のボトルネックになり易いコンポーネントは、ハードディスクドライブとコントローラーです。ESA を使えば、それらのボトルネックも直感的に識別できるので、短時間で問題の切り分けができます。 例えば、VNX のコントローラー(Storage Processor と呼びます)をスコアボード ウィジェットに登録すると、CPU と Write キャッシュメモリの利用状況が色と数値で判別できたり、Read と Write I/O の数値も表示できます(図4)。もし、Write I/O の比率が高く、且つ Write キャッシュメモリの利用率(厳密には Write Cache Page の値)も高ければ、そこがボトルネックとなっている可能性が高いと判定できます。また、冗長化されている2台のコントローラーのうち、どちらかに I/O が片寄ってしまい、ストレージ全体として想定通りの性能が出ないケースも稀に発生します。ESA であれば、そのような状態も一目で判別できます。

     

    図4 VNXコントローラーの稼働状況

    EMC4

    ※vCenter Operations Manager は、vRealize Operations Manager に名称変更されました。

     

    VM からストレージ内部の各コンポーネントまでの関連性が把握できれば、問題の切り分けと影響範囲の特定に役立ちます。ESA を使って VNX を見てみると、LUN や RAID Group、ディスクドライブだけではなく、FAST Cache (SSDベースの2次キャッシュ機能)や FAST Pool (ストレージ階層化プール)、Tier (ストレージ階層化タイプ)などの情報まで全てアイコンで表示でき、かつ関連性も直感的に見分けられるので、短時間で全体の構成が把握できます(図5)。

    図5 トポロジーマップ EMC5

     

    また、各種コンポーネントの情報は、メトリックを選択すればオンディマンドでグラフ化できます。使用率の高いディスクドライブだけ赤く表示させるようにヒートマップウィジェットを構成しておけば、そこから動的に知りたい情報をグラフ化するということもできます(図6)。仮に、ディスクドライブの負荷が高くなっていれば、ヒートマップ上のタイル(個々の四角い枠)が赤く変化します。その赤くなっているアイコンをクリックして、詳しく調べたいメトリックを選択すれば、それがグラフとして表示されます。グラフのタイムスケールも自由に調整できるので、問題発生前後の変化を視覚的に把握できます。同時に、トポロジーマップを利用して、そのディスクドライブに関係しているLUNや仮想マシンを追跡すれば、影響範囲の特定も短時間で行うことができます。

     

    図6 ヒートマップとメトリックグラフ

    EMC6

    ※vCenter Operations Manager は、vRealize Operations Manager に名称変更されました。

     

    EMC ストレージはメトリックが豊富

    EMC のストレージは、管理者のために非常に多くの構成情報や容量情報、性能情報などが取得できる仕組みを備えています。例えば、VNX のブロックストレージ機能だけでも、150種を超える値が取得できます。通常は、VNX 専用のツールを使ってこれらの値を取得し分析に利用しますが、ESA でも同等の情報が収集できるので非常に便利です(図7)。さらに、ESA であれば、分析に必要なメトリックをピックアップしてグラフ化し、タイムスケールなどを動的に調整できるので、ストレージ管理者の作業効率は確実にUPします。

     

    図7 豊富なメトリック

    EMC7

    ※vCenter Operations Manager は、vRealize Operations Manager に名称変更されました。

     

    まとめ

    ESA を利用することで、ストレージに関連する詳細な情報が収集できるようになり、仮想マシンの視点からストレージを含めた統合的な管理が可能となります。特に、性能問題が発生した際、ボトルネックの切り分けが短時間で行える点は、大きなメリットだと言えます。ESA は、評価ライセンス(期間限定の無償ライセンス)も提供していますので、EMC ストレージをお使いの方は、是非一度お試しください。

    尚、EMC のコミュニティーサイト(EMC Community Network)では、ESA に関する詳しい情報(活用例やセットアップ方法など)を公開しています。そちらも併せてご覧ください。

    VMworld 2014 からの注目セッション 第7回 – SRM と VR について

    皆様こんにちは。VMware の北村と申します。VMworld 2014 からの注目セッションの最終回 (7回目) は、「BCO2629: Site Recovery Manager and vSphere Replication: What’s New Technical Deep Dive」のセッション内容についてご紹介します。

     
    BCO2629-7
    VMware vCenter™ Site Recovery Manager™ (以下、SRM) は、約 6年前の 2008年の 12月に最初のバージョン (1.0) をリリースしましたが、今回の 5.8 は 7回目の大きなリリースとなります (注: スライドでは SRM 4.0.x と 4.1.x が 4.x として記載されていますので、今回の 5.8 が 6回目のリリースに見えますが実際は 7回目です)。
    また、vSphere Replication (以下、VR) は、2011年の 9月に SRM との同時利用のみをサポートした最初のバージョン 5.0 (5.1 以降から VR 単体での利用をサポート) をリリースし、今回の 5.8 は 4回目の大きなリリースとなります。

     
    BCO2629-10
    初めに SRM のおさらいになりますが、SRM は、vSphere 環境のための災害対策を自動化する業界トップのソリューションとして、次の主な機能を提供しています。

    • 数千の仮想マシンのリカバリ プランを集中的に管理
    • 無停止でのリカバリ テスト
    • 自動化された DR ワークフロー
    • VMware の製品スタックに統合

    これらの機能により、次のようなメリットを得る事が可能です。

    • 50% 以上の DR 管理のコストを低減
    • マニュアル操作のリスクと複雑性を排除
    • 迅速で容易に予測可能な RTO を実現
    • 仮想化されたアプリケーションに対しポリシー・ベースの DR コントロールを提供

     
    BCO2629-11
    SRM の典型的なユースケースとしては、こちらのスライドにある様に、災害対策、災害回避、計画移行、などがあげられます。

     
    BCO2629-14
    今回の SRM 5.8 の新機能ですが、次の 3つのカテゴリでそれぞれ機能拡張が行われています (※はアレイ・ベースのレプリケーション使用時)。

      1. SDDC のための DR
    • セルフ・サービス、ポリシー・ベースのアプリケーションの DR 保護として、vCO プラグインを利用した vCAC ブループリントとの統合 (※)
    • DR に対応した SDS として、SRM と VR と Virtual SAN との統合
      1. スケーラビリティの強化
    • 5 倍のスケールの保護:vCenter Server (※) あたり 5,000 までの保護された VM
    • 2 倍のスケールのリカバリ:vCenter Server (※) あたり 2,000 VM まで同時にリカバリ
    • 性能改善:ストレージスタックを改善し、RTO を削減
      1. 運用の簡素化
    • vSphere と UI を統合:vSphere Web Client プラグイン
    • 簡素化された IP アドレス管理:サブネット・レベルでのルール・ベースのカスタマイズ
    • より迅速なインストール:組み込みデータベースのオプション (vPostgre)

     
    BCO2629-33  BCO2629-34
    次に VR です。SRM 同様、最初に VR のおさらいからお伝えします。VR は、vSphere Essentials Plus Kit、および、vSphere Standard Edition 以上で利用可能な、vSphere プラットフォームに統合されたホスト・ベースで仮想マシンをレプリケーションする機能を提供します。主な特徴には以下があります。

    • 仮想アプライアンスとして提供される為、容易なデプロイ
    • UI は vSphere Web Client に統合
    • OS やアプリに関係なく仮想マシンを保護
    • 柔軟な RPO ポリシー (15分から 24時間)
    • 個々の仮想マシンの迅速なリカバリ
    • SRM 為のレプリケーション・エンジン (アレイ・ベースのレプリケーション未使用時)
    • 様々な形態のストレージ (SAN、NAS、ローカル、および、VSAN) とのコンパチビリティ

     
    BCO2629-35
    次に、VR のユースケースとしては以下があります。

    • データ保護、および、災害対策
    • データセンター移行での利用
    • SRM 為のレプリケーション・エンジン
    • VR 単体でのレプリケーション
    • 同じサイト内でのレプリケーション

    VR 5.8 の新機能として、次の 2点の機能拡張がありました。
    BCO2629-36

    • 仮想マシンの vCloud Air へのレプリケーションが追加されました (実は、この機能は VR 5.6 から実装されていますが、UIがローカライズされたのは今回の 5.8 からになります)

    BCO2629-42  BCO2629-43  BCO2629-44

    • vSphere Replication レポーティング機能が強化されました

    BCO2629-48
    新機能ではありませんが、VR の現実のレプリケーション・トラフィックを生み出さずに、仮想マシンのレプリケーションによるネットワークへの影響をモデル化する事を可能にするアプライアンスとして、VMware Labs の Flings に公開されている vSphere Replication Capacity Planning Appliance についての紹介がありました。

    VR の対象としたい仮想マシンをレプリケーションする為に必要なネットワーク・トラフィックをグラフで表示する事が可能で、実際に必要となるネットワーク・トラフィックを計算するのに参考となるツールだと思いますので、ご興味がある方は以下の参考情報を元に是非お試し下さい。

    参考情報:

    • https://labs.vmware.com/flings/vsphere-replication-capacity-planning-appliance
    • http://blogs.vmware.com/vsphere/2014/04/vsphere-replication-capacity-planning-appliance.html

     
    全7回でお伝えしてきました VMworld 2014の注目セッションブログも今回で最終回となります。

     
    最後に、11月5日(水) ~ 11月6日(木) にプリンスタワー東京で vForum 2014 が開催されます。こちらでも、今回の VMworld 2014 と同様のセッションが数多く講演されますので、ぜひご来場ください ( お申し込みはこちらから )。

     
    今後も皆様にとって有益な情報を本ブログ上でお伝えしていきたいと思いますので、是非、お楽しみに!

    VMworld 2014からの注目セッション第6回 – vC Ops の物理環境への拡張 & Hypericによる基幹系

    みなさん、こんにちは。

    今回の記事では、8月末に米国サンフランシスコで開催されたVMworld 2014にて発表された数あるトピックより、vCenter Operationsマネージャーを利用して、仮想環境上でアプリケーションの運用をより効率的に行う方法をご紹介します。

    仮想環境上で稼働するアプリケーションを監視する方としては「Hyperic」(http://www.vmware.com/jp/products/vfabric-hyperic)を利用する方法があります。
    Hypericを利用してゲストOS上にHypericエージェントをインストールすることにより、プロセスやWindows Serviceをはじめ、様々なアプリケーションのメトリックを収集することが可能となります。

    さらにHypericで収集された情報をvCenter Operationsと連携することによりアプリケーションの稼働監視や分析を行うことが可能となります。
    P12-Slide

    VMworld 2014では下記のアプリケーションとの連携について将来バージョンにおける
    連携が発表されております。

    1.MSSQL

    P22-Slide
    ソリューションの特徴は以下です。
    ・自動検知による、MSSQLサービスとインスタンスの登録
    ・クラスタ構成の可視化
    ・デフォルトKPIによる静的および動的な監視
    ・vSphere上で稼働するアプリケーション・コンポーネントの自動の相関関係の発見

    2.Microsoft Exchange

    P27-Slide

    ソリューションの特徴は以下です。
    ・メールボックスとCASロールの自動検知
    ・DAGの検知
    ・関連する全サイトの情報伝搬
    ・デフォルトKPIによる静的および動的な監視
    ・vSphere上で稼働するアプリケーション・コンポーネントの自動の相関関係の発見

    3.vCAC

    P32-Slide

    4.SAP HANA
    P34-Slide
    ソリューションの特徴は以下です。
    ・エージェント不要でデータ収集
    ・SAP HANAシステムへは負荷は軽微
    ・Out-of-the-box ダッシュボードの提供(トラブルシューティング、診断法と分析)
    ・300以上は、SAP HANA Studioの中で入手不可能300以上の判断基準
    ・SAP HANAとvSphereの間の関係マッピング

     

    まとめ
    仮想環境上で稼働する様々なアプリケーションの管理・監視のソリューションについてご紹介いたしましたが、如何でしたでしょうか。

    11/5(水)~6(木)にプリンスタワー東京でvForum2014が開催されます。

    こちらでも、今回のVMworldと同様のセッションが数多く講演されますので、ぜひご来場ください。