Home > Blogs > Japan Cloud Infrastructure Blog > 月別アーカイブ: 2014年11月

月別アーカイブ: 2014年11月

仮想化への移行

皆さん、こんにちは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) をご紹介しました。次回以降は実機検証の結果を元にブログをご紹介していく予定ですので、是非、お楽しみに!

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 と同様のセッションが数多く講演されますので、ぜひご来場ください ( お申し込みはこちらから )。

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