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

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

vCenter Orchestratorを使ってみる(1)

Orchestrator の第3回目です。
今回は、vCenter Orchestrator を実際に操作してみたいと思います。

第2回でご説明致しました通り、OrchestratorはvCenterのライセンスに含まれますので、追加のライセンスコストは不要です。よって、vCenterのライセンスをお持ちの方であればすぐにお使い頂くことが可能です。かつ、Windows環境であればOrchestratorはインストール済みですので、サービスを起動して頂ければすぐに使える状態にあります。

以降は、OrchestratorがインストールされているWindows環境を想定した手順をご説明していきます。

・Orchestratorの構成

まずは、”VMware vCenter Orchestrator Configuration”、”VMware vCenter Orchestrator Server”という2つのサービスを起動します。

Picture1

スタートメニューから、「すべてのプログラム」-「VMware」を選択して、”vCenter Orchestrator Home Page”を開きます。Orchestrator Serverを構成するために、Orchestrator Configurationをクリックします。

Picture2

以下のデフォルトの情報でログインします。
Username  :vmware
Password  :vmware

Picture3

初めてのログイン直後にパスワードの変更を求められるので、新しいパスワードを入力して下さい。
左ペインからネットワークを選択し、IPアドレスのドロップダウンボックスからOrchestratorのIPアドレスを選択し、”Apply changes”ボタンを押下します。

Picture4

左ペインからAuthenticationを選択します。
Windows環境では、Authentication ModeはSSOになっています。(SSO以外の認証方法としてLDAPを設定することができますが、Windows環境では特にSSOから変更する必要はないかと思います。)

Picture5

左ペインからLicensesを選択します。
“Use vCenter Server license”を選択し、vCenterの”Host”、および適切なユーザ名/パスワードを入力して下さい。

Picture6

左ペインからStartup Optionsを選択します。
Authenticationの変更等を行った際には、vCOサーバを再起動して下さい。

ここまでが、Orchestratorを使用する前準備です。

 

・vCenter Orchestrator Clientからの操作

スタートメニューから「すべてのプログラム」-「VMware」を選択して、” vCenter Orchestrator Client”を選択します。Windows環境の標準はSSOですので、SSOで認証が受けられるユーザにてログインして下さい。

Picture7

ログイン後、Workflowsタブを選択すると、事前に構築されたワークフローのライブラリ一覧を確認することができます。vCenterに対する処理のライブラリだけでなく、SSHやSQL等のプラグインによって提供されるライブラリも確認することができます。

Picture8

今回は、vCenterに対して事前定義されたワークフローを実行してみたいと思います。

「Library」-「vCenter」-「Virtual Machine management」-「Snapshot」配下にある仮想マシンに対するSnapshot処理のワークフローを使用します。
「Create snapshots of all virtual machines in a resource pool」を選択して右クリックし、「Start Workflow」を選択します。これにより、特定のリソースプール配下に存在する全てのVMに対して一括してスナップショットを作成することが可能となります。

Picture9

「Not Set」をクリックします。

Picture10

test1、test2が所属するTest-RPを選択します。選択後に「Submit」を押下することで、test1、test2の2台のVMに対してSnapshotが作成されることを確認してみましょう。

Picture11

次に、「Remove snapshots of a  given size」を選択することで、ある一定以上にSnapshotのサイズが大きくなったVMを対象にして、Snapshotを削除することが可能となります。
Snapshotのサイズが大きくなることによるシステムに与える影響は非常に大きいですが、Orchestratorの基本機能を使うことによりvSphere環境を安定的に稼働させることが可能となります。

以下は、Snapshotサイズが100MBを超えた際に、Snapshotを自動的に削除する設定を行った例です。

Picture12

また、スケジュールタスクとしてWorkflowを保存することも可能です。
これによって、定期的にSnapshotサイズをOrchestratorに監視させることで、Snapshot運用時のリスクを最小化することが可能となります。以下は、「Recurrence」を「Every Day」に設定していますので、一日一回Snapshotサイズをチェックするワークフローの構成例となります。

Picture13

・Workflowの実体

事前定義されたWorkflowを選択してSchemaタブを選択すると、そのWorkflow内で実際に行なわれる処理の流れを確認することができます。

以下は、Snapshotを作成するだけの単純な処理となりますので非常にシンプルですが、より複雑なWorkflowの構成になっている処理もありますので、参照してみて下さい。

Picture14

また、createSnapshotをダブルクリックすると、その処理のコードの内容を確認することもできます。実際にSnapshotを作成するためのJavascriptのコードを確認することができるので、何かJavascriptを使って自動化する既存の仕組みなどがあるようであれば、参考になるかと思います。

Picture15

ここまでは、事前定義された2つのワークフローを使用することで、自動化できるSnapshot関連の処理について見て来ました。今回はご紹介できておりませんが、事前定義されたワークフローを複数組み合わせることで、より複雑な処理をOrchestratorによって自動化することが可能です。クラウドの実現に向けた自動化の要件を満たす最適なツールですので、是非一度触ってみて頂ければと思います。

次回以降は以下の内容を予定しています。

4回目:vCenter Orchestratorを使ってみる(2)
5回目:vCloud Automation Centerとのインテグレーション

 

アーカイブ
1回目:プライベートクラウド実現に向けた自動化のニーズ 
2回目:vCenter Orchestratorのアーキテクチャ

 

押さえておきたいvSphereの基本-可用性編 vSphere HA/FT

押さえておきたいvSphere の基本」の可用性編の1回目として、前回、vSphere DRSをご紹介しました。
今回は、2回目として、ホスト障害の際にも仮想マシンの稼働を最大化する機能、vShpere HA、vSphere FTに関して順にご紹介します。

vSphere HA

ESXiホスト上で稼働している仮想マシンは、そのホストが障害で止まってしまった場合、稼働停止を余儀なくされます。
vSphere HAは、ホスト障害により止まってしまった仮想マシンを他の正常なホスト上で再稼働する機能を提供します。

HA-FT-3

例えば3台のホストがvSphere HAで構成されている上記の様なケースで、真ん中のホストが何らかの障害により止まってしまった場合、このホスト上で動いていた仮想マシンは停止してしまいます。この障害を検知すると、他の正常なホスト(上記の場合は左右ホスト)が仮想マシンを自動的に再度稼働させます。vSphere HA を利用することにより、ホスト障害の際にもサービスのダウンタイムを最小限に抑えることが可能となります。

物理環境の仮想化への移行の理由は、有り余る物理ホストのリソースの有効活用と、ホスト集約によるTCOの削減というところが多いのですが、仮想環境へ移行すると、vSphere HA が利用可能となり、可用性が飛躍的に向上するということも大きなメリットの1つです。なお、vSphere HA が利用可能なライセンスに関しては、こちらをご確認下さい。
続きを読む

押さえておきたいvSphere の基本~ネットワーク編 第2回~

「押さえておきたいvSphere の基本」のネットワーク編として、仮想化環境におけるネットワークの基本を3回に分けてご紹介していきます。第2回は、vSphere Enterprise Plus エディションに対応した分散スイッチ(vSphere Distributed Switch 以下vDS と記載)固有の機能のなかから、標準スイッチ(vSphere Standard Switch 以下vSS と記載)にはない下記3つのポイントについて解説を行います。

・複数のホストで使用するネットワークを効率的に管理する
・広帯域ネットワークに各種トラフィックを集約して使用する
・VXLAN を使用しネットワーク仮想化を実装する

■ 複数のホストで使用するネットワークを効率的に管理する
単一のホスト上に構成される標準スイッチ(vSS)に対し、分散スイッチ(vDS)は、複数のESXi ホストにまたがって構成することができます。

vsphere-nw-part2-01

トラフィックの処理を行うデータプレーンは、標準スイッチと同様にプロキシスイッチとして各ホストに配置されますが、管理プレーンをvCenter に配置することでネットワーク構成の一元管理を実現しています。例えば仮想マシン用ポートグループを作成する際、標準スイッチ(vSS)では各ESXi ホスト上で個々に設定を実施することになるのに対し、分散スイッチ(vDS)では、1回設定をするだけで構成が完了します。また、仮想マシンがvMotion によって異なるホストに移行した後も、分散仮想スイッチ(vDS)上では同じポートに接続されていることになり、統計情報やステート情報を引き継ぐことができます。

■ 広帯域ネットワークに各種トラフィックを集約して使用する
10Gbps のNIC を搭載したサーバが普及してきており、vSphere 5.5 からは40Gbps のNIC がサポートされてきています。こうした背景から、ESXi ホストのネットワークを構成する際に、トラフィックのタイプごとに個別の物理リンク(1Gbps)を使用する構成ではなく、1本の物理リンク(10Gbps)のなかに複数の種類のトラフィックを通す構成をとるケースがあるのではないでしょうか。このような構成では、異なる特性を持つトラフィックが単一の物理ネットワークを共有することになるため、トラフィックの特性に合わせた帯域の制御を考慮する必要があります。ESXi ホスト内でトラフィックを制御するための方法として、分散スイッチ(vDS)ではネットワークI/O コントロール(以下NIOC と記載)を提供します。

NIOC は、トラフィックの重要度に応じて使用帯域を制御します。例えば10Gbps の帯域を、NFS, FT, vMotion, 仮想マシンのトラフィックで共有する構成を考えてみましょう。NIOC が無効な環境では、vMotion 実施時に、vMotion のトラフィック(グラフ中の赤線)が他のトラフィックを圧迫します。これにより仮想マシンの提供するサービスに影響が発生し、FT 等遅延に敏感な機能にも影響がでます。

vsphere-nw-part2-02

一方、NIOC が有効な環境では、シェア値に基づいて各トラフィックが制御されるため、vMotion 時にも、FT, NFSといったトラフィックは圧迫されることなく、健全なパフォーマンスを維持します。

vsphere-nw-part2-03

分散スイッチ(vDS)を活用することで、このように広帯域ネットワークを使用する際に必須となるトラフィック管理の機能を実装することができます。NIOC の詳細については、「VMware® Network I/O Control: Architecture, Performance and Best Practices」を合わせてご参照ください。

■ VXLAN を使用しネットワーク仮想化を実装する
VXLAN を使用し、論理ネットワークを展開する際にも、分散スイッチ(vDS)は必須のコンポーネントとなります。VXLAN の論理ネットワーク(vCNS ではVirtual Wire, NSX for vSphere では論理スイッチと呼ばれる)は、分散スイッチ(vDS)上に仮想マシン用ポートグループとして実装されます。また、VXLAN のトンネルを終端するVTEP(VXLAN Tunnel End Point)は、分散スイッチ(vDS)上にVMkernel ポートとして実装されます。

なお、VXLAN の実装のためには分散スイッチ(vDS) の他に、vCNS(vCloud Networking and Security)もしくは、NSX for vSphere が必要となります。下記はNSX for vSphere の論理スイッチを構成する画面となります。

vsphere-nw-part2-06

これらのコンポーネント上で構成をおこなったVXLAN 論理ネットワークが、分散スイッチ(vDS)上に仮想マシン用ポートグループとして動的に展開されます。VXLAN の実装については、ネットワーク仮想化 – VXLAN の設定を合わせてご参照ください。

vsphere-nw-part2-04

さらに、vCloud Automation Center といったCMP(Cloud Management Platform)と連携を行うことで、仮想マシンの展開と同時に必要となる論理ネットワークを動的に作成し、分散スイッチ(vDS)上にポートグループを展開することが可能になります。 ネットワークの仮想化及び、SDDC(Software Defined Data-Center)環境において、分散スイッチ(vDS)は必須のコンポーネントとなります。

次回「押さえておきたいvSphereの基本」ネットワーク編第3回目は、仮想化環境でL3-L7 サービスを提供する 〜vCloud Network and Security編〜 という題目で、vCloud Suiteのコンポーネントとして、ネットワークの上位レイヤーのサービスを提供するvCloud Networking and Security(vCNS)についてご紹介します。

「押さえておきたいvSphereの基本」
~ストレージ編~
1.マニュアル操作でストレージ環境を最適化
2.ストレージと連携してパフォーマンスを最大化
3.優先度の定義付けと自動化

~ネットワーク編~
1.ホスト単位でネットワークを構築する 〜標準スイッチ編〜
2.スケーラブルで高機能なネットワークを構築する 〜分散スイッチ編〜
3.仮想化環境でL3-L7 サービスを提供する 〜vCloud Networking and Security〜

~可用性編~
・物理リソースの有効活用と仮想マシンの最適配置~DRSとリソースプール編~
・システム障害に備える仕組み~vSphere HAとFT編~

vExpert 2014 申し込みが開始されました

 以前のブログエントリで、2013年度のvExpert 受賞者の発表をご連絡させていただきましたが、今回は申し込みが開始されたご案内です。
 
 VMware vExpert は、過去1年間に、VMwareコミュニティー全体に大きく貢献された個人を表彰させて頂く一年更新のプログラムです。ブログや掲示板、Twitterといったオンライン上での貢献の他、社内外への弊社製品技術促進、講演活動、執筆、ユーザ会などで貢献された方を表彰いたします。
 
 vExpert は個人に付与されるものであり、所属組織に対して付与されるものではありません。過去1年のVMwareコミュニティへの貢献や技術普及活動を評価するもので、資格認定ではございませんのでご注意ください。

候補者の方は3つのパスで申し込むことができます。

Evangelist Path:
著書、ブログ、ツール制作者、講演者などで貢献された方が対象となります。

Customer Path:
成功事例、インタビュー記事、事例講演やユーザー会での活動などを行なって頂いた方が対象となります。

VPN (VMware Partner Network) Path:
VMware パートナー企業にお勤めで、技術の習得を欠かさず継続され、技術の普及に貢献された方や講演活動などで貢献された方が対象となります。VMware 社員のリファレンスを推奨いたします。

今年からカテゴリが下記のように分かれており、申し込みは年間を通して可能ですが、四半期毎の終わりに審査・投票がされ、翌四半期に受賞者が発表されます。

  • Hybrid Cloud
  • End User Computing
  • Server Virtualization
  • Network Virtualization
  • Storage Virtualization
  • Security(Fast Track対象者 = 2013年度受賞者のみ)

 申し込み方法は下記いずれかのサイトから自薦または他薦で2013年度の活動について英語で記入する形となります。

申し込みサイト:

Current 2013 vExperts use the 2014 vExpert Fast Track application
(2013年受賞者用Fast Track サイト):http://bit.ly/1ikZ8hi
2014 vExpert application
(2014年vEXPERT 申し込みサイト):http://bit.ly/LMJqB5
Recommend a colleague to apply for 2014 vExpert
(推薦者申し込みサイト): http://bit.ly/1bobFfF

プログラムに関するお問い合わせ先は vexpert@vmware.com となります。
なお、最新情報についてはtwitter アカウント@vExpert (英語)で随時アップデートしていく予定です。

 

このブログエントリは、VMTN blog の下記エントリを抄訳したものです。詳細につきましては原文 vExpert 2014 applications are open をご参照ください。

VMware vCenter Converter で P2V, V2V ~ 第1回 仮想環境におけるサーバ移行 (P2V, V2V) の基本

今回は、仮想環境におけるサーバ移行 (P2V, V2V) の基本的な考え方を、VMware 社が無償提供するツールである VMware vCenter Converter のご紹介を交えながら説明します。

昨今では、仮想化によるサーバ統合は企業の IT インフラにとって欠かせないソリューションの一つとなっており、新規のインフラを物理サーバではなく仮想化基盤を前提に構築するケースも珍しくなくなってきています。このとき、既存の物理サーバ環境をどのように移行していくかは、仮想化を加速させていく上で検討すべき重要なポイントとなります。もちろん、通常の移行作業のように OS やアプリケーションの再インストールやデータ移行などを新しい仮想マシン上で一から行うことも可能ですが、移行作業にかなりの工数と時間、そしてコストがかかってしまいます。

既存の物理環境から仮想環境への移行を効率的、かつ低コストで進めていくために、専用のツールを利用する方法があります。VMware vSphere の環境においても、サードパーティ製のツールの他に、VMware 社が無償で提供する VMware vCenter Converter (以下、vCenter Converter) を使用するケースが多くなっています。

■P2V/V2Vとは?

vCenter Converter の説明に入る前に、いくつかの用語を整理したいと思います。

P2Vとは Physical to Virtual の略で、既存の物理サーバを専用のツールを使って仮想環境上に移行することを言います。これは、物理サーバディスクのバックアップを取得して、異なるハードウェア構成の新しい仮想マシン上にリストアするイメージになりますが、既存の構成は可能な限り維持されます。また、ツールによっては新しい仮想マシンの設定をカスタマイズすることも可能です。

P2V は、サーバ統合の他、テストやトラブルシューティング時、あるいは物理サーバのバックアップを仮想マシンとして取得するといったディザスタリカバリ用途でも使われます。また、ディスクサイズの変更などを目的に利用することもあります。最近では、数百台という単位で P2V を実施して一気に仮想化を進めるケースが多くなってきています。

vi-migration1-1

P2V (Physical to Virtual)

一方、V2V とは Virtual to Virtual の略で、仮想化プラットフォーム間で仮想マシンを移行することを言います。

vCenter Converter では、Hosted タイプのワークステーション製品 (VMware Workstation、VMware Fusion および VMware Player) と vSphere 製品間での移行をサポートしています。

V2V (Virtual to Virtual)

V2V (Virtual to Virtual)

■vCenter Converter 概要

vCenter Converter は、VMware 社が提供する P2V/V2V ツールで、「VMware vCenter Converter Standalone (以下、vCenter Converter Standalone)」 という製品をダウンロードして無償で使用することが可能です(以前は VMware vCenter Server に付属する有償の Enterprise エディションがありましたが、現在は提供されておりません)。

vCenter Converter 製品ページ: http://www.vmware.com/products/converter/

vCenter Converter Standalone

vCenter Converter Standalone

特長として、ウィザードベースの簡単な GUI 操作で利用でき、移行作業の工数を大幅に削減できることが挙げられます。また、例えば VMware Workstation と vSphere 上の仮想マシンのフォーマットは異なりますので、このようなプラットフォーム間で仮想マシンを移行する際の V2V 用途としても使うことができます。

vCenter Converter Standalone の概要

vCenter Converter Standalone の概要

上の図で「Source (移行元) 」として「Third-party Virtual Machines」 「Third-party System Images」 とありますが、このように vCenter Converter では Hyper-V Server 上の仮想マシンや、Acronis TrueImage、Norton Ghost、Symantec Backup Exec System Recovery (LiveState Recovery) といったイメージバックアップソフトのイメージも、インポートして移行できます。

移行元の指定

移行元の指定

なお、サポートする Source のリストについては、製品マニュアルやリリースノート等をご確認下さい。

VMware vCenter Converter Standalone 5.5 Release Notes: https://www.vmware.com/support/converter/doc/conv_sa_55_rel_notes.html

■サポートする移行元OS

vCenter Converter Standalone では、移行元の OS として Windows と Linux をサポートしています。以下に、vCenter Converter Standalone 5.1 および 5.5 においてサポートする OS およびバージョンの一覧を示します(実際にご利用を検討される際には、製品マニュアルやリリースノート、互換性リストなどで最新情報をご確認下さい)。

1. Windows

以下は、Windows OS におけるサポート状況です。

Windows: バージョン毎のサポート

Windows: バージョン毎のサポート

2. Linux

一方、以下は Linux OS におけるサポート状況になります。

Linux: バージョン毎のサポート

Linux: バージョン毎のサポート

■サポート及びライセンス

vCenter Converter Standalone は無償でダウンロードしてご利用いただけますが、弊社サポートは付属しておりません。vCenter Server 製品及び SnS をご購入頂いているお客様は、その中に vCenter Converter Standalone 製品のサポートも含まれます。また、単体でのサポートをインシデント単位で購入することも可能です。詳細は以下の KB をご確認下さい。

Support entitlement for VMware vCenter Converter Standalone 5.0.x (2007410) 

また、バージョン毎の製品サポート情報 (製品ライフサイクル) については以下をご確認下さい。

VMware Lifecycle Product Matrix

vCenter Converter Standalone のコミュニティでは、日々利用者によるディスカッションやフォーラムによる Q/A が活発に行われています。製品を利用する際の有益な情報源となりますので、是非アクセスいただければと思います。

Community: VMware Converter Standalone

■vCenter Converter による P2V 移行 の手法

ここからは、vCenter Converter Standalone による P2V 移行の手法をご紹介します。vCenter Converter Standalone には、大きく以下の手法があります。

  • ホットクローン
  • サードパーティツールによる移行

上記方法で移行できない場合は、他のツールを利用するか、新規構築による通常の移行作業を実施することになります。

1. ホットクローン

ホットクローンは、ターゲットとなる移行元マシンの OS が起動したまま移行処理を行う方法で、専用のサーバ(Windows OS)上に vCenter Converter Standalone をインストールして、そこから移行元と宛先にそれぞれ接続して処理を実行します(「ホット」とは OS が起動している状態を指しています)。その際、移行元マシンにエージェントがプッシュインストールされ、宛先との間でディスクデータのコピーが行われます。

ホットクローン

ホットクローン

この手法の特徴として、OS を起動したまま移行が行われることが挙げられますが、当然移行処理中にOS 上でサービスが稼動していれば、データの不整合が発生する可能性は残ります(VSS との連携はサポートします)。このため、実行時にはできるだけファイルに差分が発生しないようにサービス(特にウイルス対策ソフト、インベントリ管理ソフト、DB ファイルをロックするようなサービスなど)を停止させたり、1回目のコピーが終了した時点で発生した差分を「同期」コピーしたりといった処理が行われます。OS は起動していますが、基本的には利用者にサービスを提供したまま移行を継続できるといった機能ではない点にご注意下さい。

この方式では、ドライバに依存しないということが最大のメリットです( OS が起動している状態では最適化されたドライバが組み込まれていますので、ディスク上のファイルを必ず読み込むことができます)。また、リモートの vCenter Converter Standalone マシン上から複数の物理サーバに対して一元的に移行処理が実行できるため、特に移行対象のサーバ台数が多い場合にも作業をスケールさせることが可能です。環境によっては(十分なネットワーク帯域が確保されているなど)、WAN 越しに移行処理を実行するといったことも考えられます。

なお、既存環境にエージェントがインストールされますが、これによる変更は局所的で、影響はほとんどありません。移行完了後に自動的にアンインストールすることも可能です。

(追記:2014/03/25) WAN越しの変換処理は、Release Notesの「Known Issues」に記載がありますが現在のvCenter Converter Standaloneではサポートされている構成ではありません。

https://www.vmware.com/support/converter/doc/conv_sa_55_rel_notes.html#knownissues

2. サードパーティツールによる移行

これは vCenter Converter Standalone から見れば少し特殊な方法ですが、サードパーティツールで取得したイメージバックアップを仮想環境上に移行することができます。

サードパーティツールによる移行

サードパーティツールによる移行

この方式では、大きく

  • vCenter Converter Standalone を介さない方法
  • vCenter Converter Standalone を介する方法

があります。

一つ目の方法では、あらかじめ仮想環境上に物理サーバと同じディスク構成の仮想マシンを作成し、ここに通常のイメージバックアップソフトの手順でリストアを実施します(この場合は、vCenter Converter Standalone は関係しないです)。

一方、二つ目の方法では、あらかじめ取得されているイメージバックアップを vCenter Converter Standalone にインポートして、仮想マシンに変換します。

バックアップイメージの選択

バックアップイメージの選択

これらの方法の違いは、vCenter Converter Standalone を介する場合は処理の一環としてデータのコピー後のカスタマイズ処理などを実行できることです。

この方式をうまく利用すると、例えば静止点が確保できるツールを使ってイメージバックアップを取得しておいてから仮想環境への移行を実施したり、また vCenter Converter Standalone ではどうしてもエラーが出て移行処理を完了できない場合の代替手段にできる可能性もあります。

ただ、サードパーティツールのライセンスコストが追加でかかること、また vCenter Converter Standalone をそのまま使う場合に比べて追加の作業工数がかかる点は、デメリットといえます。

3. 新規構築による通常の移行

先ほど「上記方法で移行できない場合」と説明しましたが、実は通常の移行作業という選択肢は非常に重要です。P2V を行う場合、何がなんでもツールを使った移行を行うことにこだわってしまいがちですが、時にはトラブルの解決にこだわるあまり、大幅に作業工数を超過した上に移行が完了せず、しかもコストが肥大化してしまうなど、本末転倒な結果になる危険性もあります。

仮想環境への移行において、必ずしもP2Vツールを使う必要はない

のです。vCenter Converter Standalone は銀の弾丸ではありません (P2V では古い物理環境からの移行も多いため、構成上の問題や移行後のパフォーマンス劣化問題など、個別に対処しないといけない問題も発生します)。移行計画では、既存の物理環境のアセスメントと事前テストを十分に行った上で、仮に移行が上手く行かない物理マシンが存在した場合の代替手段を計画しておくことが重要です。移行作業全体としてのトータルコストを考慮して、適材適所でツールを活用して下さい。

(参考1) P2Vにおけるコールドクローン

ホットクローンでは移行中に OS が起動しているため、データ差分(不整合)が発生する可能性がどうしても0にはなりません。対象の物理サーバを一旦シャットダウンして、静止点を確保した状態で移行できればこのような不整合は発生しません(このような方法をコールドクローンと呼びます)が、vCenter Converter Standalone では、P2V におけるコールドクローンをサポートしていません

vCenter Converter でも、以前は vCenter Converter Enterprise の一部として Converter Cold Boot CD というツールが提供されており、CD-ROM から vCenter Converter 起動してコールドクローンする手法がサポートされていました。システムをイメージバックアップするツールと同じように、CD から起動された Windows 上で vCenter Converter のアプリケーションが実行されているイメージになります。

コールドクローン

コールドクローン

この手法では、エージェントを送り込むなどの変更がないため既存環境への影響がないこと、また OS が起動していない状態でコピーが実行されるためデータ整合性が保たれることなどのメリットがあります。しかし、移行対象の物理サーバ一台ごとに ISO イメージをマウントして実行するための工数がかかることや、Boot CD 内に移行対象サーバの RAID Card や NIC のドライバがないと実行できないなど、作業の工数やスケーラビリティ、そして互換性の面でどうしてもデメリットや制約が多くなります。

(参考2) V2Vとコールドクローン

次に、V2V の場合のクローン方法についても補足しておきます。vCenter Converter Standalone で V2V を実行する場合、基本的に仮想マシンが実行中の状態では移行処理を開始することはできず、コールドクローンとなります。

V2Vにおけるコールドクローン

V2Vにおけるコールドクローン

ただし、移行対象の仮想マシンを「物理サーバ」とみなして P2V の移行手順を実行することで、ホットクローンを行うことは可能です。

■移行処理の実行時におけるステージとトラブルシューティング

次の図は、vCenter Converter Standalone による移行処理の実行時におけるステージを示しています。移行処理は大まかに3つのステージに分かれており、それぞれ前半で準備処理および移行先での仮想マシンの作成、中盤でディスクデータのコピー処理、後半で仮想マシンの再構成やカスタマイズなどが実施されます。このステップを理解しておくと、仮に途中で処理が停止した場合にも問題をある程度切り分けることができます。

移行処理実行中の vCenter Converter Standalone の動作

移行処理実行中の vCenter Converter Standalone の動作

一例として、進捗状況が0-5%の間で処理が停止した場合は、ログを確認しつつ移行元、宛先ホストに対してきちんとネットワークの疎通ができているか、移行先のデータストア容量は十分か、などを確認します。一方、処理が中盤まで実行された段階でエラーが発生した場合は、ネットワークケーブルの確認やネットワークの通信状況などを確認し、必要に応じて処理をリトライします。

データ転送にかかる時間は、移行処理を円滑に進める上で重要な要素になります。例えば vCenter Converter Standalone では移行時にディスクサイズの変更が可能ですが、サイズを小さくする場合はファイルレベルのコピー処理となり、サイズを変えない、あるいは大きくする場合のブロックレベルでのコピーより大幅に処理時間がかかります。

デスクサイズの変更

デスクサイズの変更

このように、移行処理にかかる時間は様々な要素によって影響を受けますので、移行計画の時点で要件を洗い出し、事前に十分なテストを行うことをお薦めいたします。これは、移行対象の物理サーバの台数が多い場合は特に重要です。

■まとめ

今回は、仮想環境におけるサーバ移行の基本的な考え方を、VMware 社が無償提供するツールである vCenter Converter のご紹介を交えながら説明しました。ITインフラの仮想化、そしてクラウド化を推進する際の旅のお供として、vCenter Converter を道具箱に加えていただければ幸いです。

次回以降は、以下のようなテーマを 予定しています。どうぞお楽しみに!

  • vCenter Converter Standalone のインストール
  • Windows Server, Linux の P2V
  • Hyper-V からの V2V
  • サードパーティツールを使った P2V, V2V
  • Windows 7 の Fusion/Workstation への移行

押さえておきたいvSphereの基本~ストレージ編 第2回~

~ストレージの能力を最大限に引き出す vSphere~
皆様こんにちは!前回は、vSphereのストレージ機能において比較的小規模環境(約ESXi2~3台)でも使用できる代表的な機能をご紹介しました。一般的に仮想基盤は小規模構成から運用開始することが多く、仮想基盤の運用に慣れていくに伴い、規模を拡張していくことが多いです。規模を拡張するにあたり、物理リソースを単に増やしてしまうとコストメリットがなかなか出しにくくなり、安全に統合率(ESXi上で稼動する仮想マシン数)を上げていくことも考慮していく必要があります。そこで安全に統合率を上げていく際、重要な役割を担うポイントの一つとしてストレージがあげられます。

図2-1
 

図1 仮想マシンの増加とIO増加
仮想マシンの台数が増えると、もちろんストレージへのアクセス(通常のIOに加え仮想マシンの作成、テンプレートから仮想マシンを展開、Storage vMotion等)は増えます。ここで忘れてはいけない点として、仮想基盤は物理リソースを「共有」しているという点です。これはIO競合が発生しやすい状態ともいえ、ストレージがボトルネックになりやすい環境にもなりかねません。ここで管理者は仮想マシンの配置を仮想基盤の特性を十分理解する必要がでてきます。ストレージ側に関してはなかなか手が回らず、余裕の持ちすぎたサイジングになってしまう傾向があります。そういった中、vSphereではストレージとより連携し、そもそもストレージが持っている能力を最大限引き出し、管理者に余計な負荷がからない様、下支えをする仕組みを持っております。

■仮想基盤特有、ストレージのボトルネックを抑える
前回VMFSと呼ばれるファイルシステムをvSphereでは持っているとご説明をしました。複数のホストからアクセスされているような環境では、データの整合性のためにファイルシステムのメタデータの更新が必要となる場合、排他制御の仕組みが必要になってきます。vSphere 環境におけるメタデータの更新が必要となる代表的なオペレーションとしては、仮想マシンを新規作成、仮想マシンの起動/停止、vMotion、仮想マシンスナップショット取得時、等実行するタイミングになります。vSphere では、排他制御のためにSCSI-2のディスクリザベーションを利用しており、「LUN全体をロック」して他のホストからのアクセスを抑制するという動作になります。非常に短い時間ではありますが、他のホストで稼動している仮想マシンは、一時的にI/O ができない瞬間が発生してしまいます。 (図2)

図2-2withoutVAAI
 

図2 排他制御が多くかかってしまうと他の仮想マシンに影響してしまう
1LUN上に多く仮想マシンを配置させた結果、排他制御を多く発生させる仮想マシンがあることにより、同じLUN上にある他の仮想マシンのパフォーマンスを劣化させてしまう可能性がでてきます。そのため管理者は、なるべくこの排他制御の影響が出ないよう多くLUNを作成して仮想マシンの配置を細かく分けたり(=管理の煩雑さ増)、必要最低限のみ仮想マシンを配置(=余剰リソース増)させてしまう手法をとってしまいます。ストレージとしては、まだまだ余裕があるにも関わらず、少しもったいない使い方ともいえます。ここでvSphereで持っているStorage APIs for Array Integration(以下VAAI)を使用し、vSphereとストレージが連携することによって、排他制御の単位をLUN全体ではなく、より粒度の小さい単位でロックすることができます。これにより排他制御処理が発生した瞬間もLUN全体がロックされませんので、多くの仮想マシンを1LUN上に配置しても、排他制御による他の仮想マシンへの影響を少なくすることができます。図3(LUNも必要以上に細かく分ける必要性も減ってきますね)

図2-3 VAAIon
 

図3 VAAIを使用した排他制御 他のホストへの影響は最低限に
■ストレージにお願いできることはストレージへお願いする
もう1つ、VAAIの機能でストレージの能力を引き出す機能を紹介します。仮想化基盤を運用、管理するためには、仮想マシンのIO 以外にストレージに対する様々なIOが発生します。具体的には、テンプレートから仮想マシンを展開したり、前回ご紹介したStorage vMotion があげられます。ストレージから見れば、ファイル(ブロック)を“コピー”したり“移動”するような操作です。そのような操作は通常、図4の左のように複製元のストレージからデータをESXiで読み込んだ後、複製先のストレージにデータを書き込むことになります。もちろんこの動作はESXi自身が実施しているので、ESXi側リソース(CPUやメモリ)、ESXiとストレージ間の帯域を多く消費してしまいます。そこでvSphereではこの動作をストレージと連携してストレージ側にお願い、実施してもらうこともVAAIを通じて可能になります。

図2-4
図4 VAAIを使うとストレージ内でコピーが実施される
ESXi側(ハイパーバイザー)で処理している内容をストレージにお願いすることによって、ESXi側の負荷が減り、その分他の仮想マシンへリソース供給できたりします。またコピー中もVAAIを使用すればESXi~ストレージ間の帯域をほとんど使用しないので、他の仮想マシンへの影響も抑えられます。実際にその効果を見てみましょう。図5は、VAAIの有無によるStorage vMotionの結果になります。

図2-5
図5 VAAIの有無におけるStorage vMotion中の帯域
この結果を見ていただくとわかるように、VAAIを使用することで、データの複製がストレージ内で実施されることになるため、ストレージネットワークには、ほとんどデータが流れていないことがわかります。(青い線)また、ストレージ側のCPU使用率も下がり(赤い線)、Storage vMotion に要する時間も短くなっていることがわかります。VAAIはあまり機能として目に見えない「地味な存在」ですが、vSphereとストレージの連携がより密になり、ストレージにお願いできることはストレージにお願いし、仮想基盤全体としてよりリソースの効率性を上げることが可能になります。
上でご紹介した機能は、Enterprise エディションで提供されているStorage APIs for Array Integrationという機能の一部です。(Storage APIs for Array Integrationを通して他に実現できる機能はありますが、詳細はホワイトペーパ をごらんください)
※VAAIを使用するには、事前にVMwareの互換性リストでストレージがVAAIに対応しているか確認します。現状、主要ストレージベンダーから出荷されているストレージ製品であれば、ほぼこの機能に対応しておりますが、Firmwareのバージョンによって差異ありますので、事前にご確認ください。

■サーバ~ストレージ間のパスを整える
最後にESXi~ストレージ間のパスについてご紹介します。
仮想マシンが増えていくことにより、ESXi~ストレージを結ぶ”パス”をより有効に、安全に使用する必要もあります。vSphereでは標準でマルチパス機能を提供しております。もちろん経路障害によるフェイルオーバー動作であったり、IOの振り分け機能も提供しておりますが、Enterpriseエディションにある“”MultiPath”があることにより、ストレージベンダが提供するマルチパスソフトを使用することが可能になります。提供されているマルチパスソフトにより特徴があり、例えばより高度なIOロードバランシングによる帯域の有効活用が可能になったり、経路上の健全性を常に把握し、プロアクティブに障害検知を実施し影響を最小限に抑える等、ESXi~ストレージ間のパスをより整えることが可能になります。また複数のストレージにデータが分散している際、マルチパスソフト側でどのストレージにどのデータがあるのか把握できるので、目的のデータへ一発でアクセスでき余分なIOを発生させない、という特徴をもったマルチパスソフトもあります。ストレージベンダーが提供するより高度なマルチパスを使用することにより、見逃してしまいがちなリソースである「パス」をより有効に活用していただけることも可能になります。

図2-6
図6 パスの凸凹を整える
■まとめ
今回は主にvSphere Enterprise エディションで提供している機能をご紹介させていただきました。最近のストレージにおいては、ご紹介したVAAIに対応しているストレージが多くなってきております。是非このvSphereとストレージの連携に注目していただき、高機能なストレージの能力をより引き出していただき、仮想基盤を有効に使っていただければ幸いです。次回「押さえておきたvSphereの基本~ストレージ編~」では仮想基盤におけるストレージ環境の優先度の定義付けと自動化、をテーマにお送りします。お楽しみに!!

VMware青山健二/中村朝之

「押さえておきたいvSphereの基本」
~ストレージ編~
1.マニュアル操作でストレージ環境を最適化
2.ストレージと連携してパフォーマンスを最大化
3.優先度の定義付けと自動化

~ネットワーク編~
1.ホスト単位でネットワークを構築する 〜標準スイッチ編〜
2.スケーラブルで高機能なネットワークを構築する 〜分散スイッチ編〜
3.仮想化環境でL3-L7 サービスを提供する 〜vCloud Networking and Security〜

~可用性編~
・物理リソースの有効活用と仮想マシンの最適配置~DRSとリソースプール編~
・システム障害に備える仕組み~vSphere HAとFT編~

vCenter Orchestratorのアーキテクチャ

みなさん、こんにちは。

前回に引き続き Orchestrator に関する 2 回目になります。

今まで仮想化環境の自動化はどう行っていますか。 Power CLI 等個別でスクリプトを作り込んでいたのではないでしょうか。個別でスクリプトを作り込む場合、例えば、データベースへの接続や Active Directory への接続等全てを作り込む必要があるので、非常に工数が必要な作業だと思います。

Orchestrator を使うことにより、個別カスタマイズを極力減らして、自動化の恩恵を受けることできます。

Orchestrator の注目度の高さは弊社のブログの PowerCLI のスレッド数と Orchestrator のスレッド数が比べてみると最近、非常に注目度が高いことがわかると思います。

VMware コミュニティへの新規スレッド数 [PowerCLI VS Orchestrator]

vCO-graph

[出所 URL]
http://technodrone.blogspot.com/2014/01/vcenter-orchestrator-finally-gaining.html

 

上記グラフからもわかる通り Orchestrator は利用者数が伸びており、コミュニティでのやり取りも活発になっています。もし、Orchestrator で探している情報があれば、是非、Orchestrator ブログもチェックしてみてください。

 

VMware Orchestrator Blog (英語)
http://blogs.vmware.com/orchestrator/

また、Orchestrator は既存の PowerCLI を実行することもできるので既存のPowerCLI も無駄にすることなく利用できます。

では、Orchestrator のアーキテクチャに関して以下の項目に沿ってご紹介させていただきます。

 

  1. 利用環境の種類に関して
  2. アーキテクチャ(概要)
  3. プラグイン
  4. ライセンス
  5. 保守

 

利用環境の種類に関して

まずは、Orchestrator の環境をどのように準備するかに関して説明します。

Orchestrator ですが、以下のとおり、Windows 版とアプライアンス版の 2 つが用意されています。

 

  1. Windows 版
  2. アプライアンス版

 

[Windows 版]
Windows 上に vCenter を Simple  Install することにより Orchestrator も自動的にインストールされます。

Windows 版の vCenter をインストールを行った人は既に多くいるかと思いますが、その方々は既に Orchestrator のインストールも完了していることになります。

但し、Orchestrator のサービスは標準では自動的に起動しませんので、利用する際にはサービス (VMware vCenter Orchestrator Configuration / VMware vCenter Orchestrator Server) を手動で起動 (もしくは、自動的に起動するように設定変更) する必要があります。

vCO-service-status

[アプライアンス版]
アプライアンス版に関しては、下記の VMware のダウンロードサイトから ova ファイルをダウンロード・展開することにより利用することができます。

 

https://my.vmware.com/jp/web/vmware/details?productId=352&downloadGroup=VCL-VCOVA_550

vCO-Download

OVA ファイルは Windows 環境を用意することなく非常に簡単に展開することが可能です。

 

アーキテクチャ(概要)

 

vCenter Orchestrator のアーキテクチャの概要に関して示します。

vCO-Architecture

Orchestrator 自身はワークフローの制御を行い、他のシステムとの連携はプラグインで行う形になっています。

その為、Orchestrator 側でのワークフローの作成は連携するシステムが異なっても同一の手順でワークフローを作成することが出来ます。異なるシステムと連携する際には利用するプラグインを変えるだけで利用することができます。

専用の管理画面からシンプルな操作性を実現しておりますので、ワークフローを作成する際には多くの操作をドラッグアンドドロップでワークフローの作成や INPUT や OUTPUT 等の引数の受け渡しを行うことが可能です。

new-workflow

 

プラグイン

Orchestrator がワークフローを管理して、プラグインを経由して外部システム等と連携を取り、様々なシステムに連携したワークフロー簡単に作成することが可能です。

vCO-PlugIn

自動化・統合化の恩恵を最大限に享受するためには他のシステムと連携できるかが非常に重要になってきますが、Orchestrator は非常に多くのプラグインを備えております。

vCenter Server やConfiguration Manger 等の VMware 製品はもちろん、REST や SNMP、SQL、SSH 等の標準プロトコルにも対応しているので様々なシステムと連携することが可能です。

さらに Active Directory や Windows PowerShell 等にも連携しているので、社内システムのワークフローを作成する上でも必要な機能が揃っています。

 

ライセンス

Orchestrator のライセンスは vCenter Server のライセンスに含まれているので Orchestrator 用に追加のライセンスコストは発生しません。

その為、vCenter のライセンスをお持ちの方はすぐに Orchestrator を試すことができます。

 

保守

Orchestrator の製品自体の保守サポートは vCenter Server の保守に含まれております。

但し、SDK/API等の開発に関するお問い合わせは通常の保守窓口ではお受けしておりません。その為、SDK/API 関連のお問い合わせが必要な場合や商用環境や本番環境に関しては、別途、SDK Support Program のご加入をお勧めいたします。

 

VMware SDK Support Program
https://www.vmware.com/support/services/sdk.html

次回以降は、vCenter Orchestrator の実際の画面をいくつかご紹介していきます。

 

次回以降は以下の内容を予定しています。

3回目:vCenter Orchestratorを使ってみる(1)- 自動化を想定した使い方

4回目:vCenter Orchestratorを使ってみる(2)- 統合化を想定した使い方

5回目:vCloud Automation Centerとのインテグレーション

押さえておきたいvSphereの基本-可用性編 vSphere DRS

押さえておきたいvSphere の基本」の可用性編として、2回に分けてvSphereのリソースコントロールの機能と可用性を高める機能のご紹介をしたいと思います。

1回目の今回は、vSphere上でゲストOSを運用する際、特定のESXiホストの負荷が高くなった場合、柔軟なリソースコントロールと稼働ホストの分散により、ゲストOSへの稼働に影響を最小限に抑える機能をご紹介します。

利用ケースとして、複数のESXiホストが稼働している状況で、各ホストのリソースを効率よく活用することにより、ゲストOS間のパフォーマンス劣化を防止することやより高い統合率での仮想環境の運用が可能になります。

その他、サーバリソースを追加した場合、新たに追加されたサーバのリソースの効率的な利用などもあります。

仮想マシンが増えてきた場合、それらの仮想マシンの負荷を想定して、どのサーバー上で稼働させればパフォーマンス最適化が図れるかを設計することは困難ですし、仮に設計が出来たとしても、時間の経過と共に負荷状態は変化していきますので常に最適な状態で運用し続けることは困難です。

そこで、非常に強力な機能としてvSphereにはDRS(vSphere Distributed Resource Scheduler)があります。

DRS5

どのエディションで利用可能かについては「vSphere のエディションの比較」サイトを参照ください。注意点としてDRS機能を有効にするにDRS利用可能なエディションでクラスタを作成する必要があります。

DRSには以下の役割を持っています。

  • ユーザーによる、VMパフォーマンス要件の最適化。
  • VMのリソースの分離と共有を提供。
  • 効率的なインフラストラクチャ活用とリソース管理。
  • 包括的なクラスタ管理。

上記役割を満たすためのメカニズムとして以下の機能があります。

  • 初期配置/ロードバランシング
  • QoSの施行:共有、予約、制限、リソースプール
  • ポリシーの施行:アフィニティルール、アンチアフィニティルール
  • ホストメンテナンス時の退避

1.初期配置/ロードバランシング

DRSの「初期配置/ロードバランシング」を利用する際に、一番重要な考え方となるのが「VM の要求を満たす」つまり「VMやアプリケーションが問題なく稼働する」と言うことです。

1つ例を示します。

図1のようにクラスタ内の特定ホストのリソース(CPU・メモリ)が不足した結果、そのホスト上で稼働するVMが十分な要求リソースを確保出来なくなった場合、DRSにより不均衡解消に働きます。一方、図2のようにクラスタ内のホストが十分にリソースが確保されている場合、ホスト上で稼働しているVM数に少々のバラつきがあっても、DRSは発動されません。

図1.クラスタ内の特定ホストのリソースが不足した場合

図2.クラスタ内のホストは十分にリソースが確保されている場合

では、どのような方法でホストの「負荷」と「ばらつき」を評価するかというと、構成するホストの負荷(ホストの負荷 = (VMの負荷の合計) / (ホストのキャパシティ))のばらつきを標準偏差として管理し、この標準偏差の値が、設定されたしきい値(保守的~積極的の5段階で設定)を超えた場合、vMotionを利用して仮想マシンをほかのサーバーに移行させます。

また、vMotionの実行も自動でVMがホスト間を移動するのではなく、管理者側に判断を仰ぐということも可能となっています(可用性ガイド参照)。

2.QoSの施行:共有、予約、制限、リソースプール

各VMの要求リソースリソースのコントロールをうまく行うことにより、VMの稼働を安定させることが可能となります。その方法としてリソースプールという機能がDRSでは設定可能となっています。

リソースプールの主な特徴は以下となっています。

  • リソースの分離のための、強力なリソース抽象化機能
  • ビジネス要件に応じて、リソースプールを作成可能
  • プール内でのリソース共有と、プール間でのリソース隔離

リソースプールをうまく活用することにより、ホスト毎のリソース管理ではなく、クラスタ単位でリソースの管理が行えます。

このリソースプールは「予約」「制限」「シェア値」の設定により柔軟なリソース管理が可能です。

また、それぞれの設定項目に関しては、次のガイドライン(リソース割り当て設定の推奨事項)に従うことにより、仮想マシンのパフォーマンスを向上させるのに役立ちます。
合計使用可能リソースが頻繁に変化することが予想される場合は、[シェア] を使用して、仮想マシン間で適正にリソースを割り当てます。[シェア] を使用していて、ホストをアップグレードする場合、各シェアがより多くのメモリ、CPU、またはストレージ I/O リソースを表していても、各仮想マシンの優先順位は変わりません (同じシェア数のままです)。

[予約] では、ユーザーが使用可能にしたい量ではなく、条件に合った最小の CPU またはメモリの量を指定します。ホストは、仮想マシンのシェア数、需要予測、および制限に基づいて、使用可能な追加のリソースを割り当てます。予約によって表される具体的なリソースの量は、仮想マシンの追加や削除など、環境を変更しても変化しません。

仮想マシンの予約を指定する場合、すべてのリソースをコミットしないでください (10% 以上を未予約にしてください)。システム内のすべての容量が完全に予約された状態に近づくほど、アドミッション コントロールに違反せずに予約とリソース プール階層に変更を加えることが困難になっていきます。DRS の有効なクラスタでは、クラスタの容量またはクラスタ内の個々のホストの容量を完全にコミットする予約によって、DRS が仮想マシンをホスト間で移行できなくなることがあります。次のガイドラインは、仮想マシンのパフォーマンスを向上させるのに役立ちます。

合計使用可能リソースが頻繁に変化することが予想される場合は、[シェア] を使用して、仮想マシン間で適正にリソースを割り当てます。[シェア] を使用していて、ホストをアップグレードする場合、各シェアがより多くのメモリ、CPU、またはストレージ I/O リソースを表していても、各仮想マシンの優先順位は変わりません (同じシェア数のままです)。

[予約] では、ユーザーが使用可能にしたい量ではなく、条件に合った最小の CPU またはメモリの量を指定します。ホストは、仮想マシンのシェア数、需要予測、および制限に基づいて、使用可能な追加のリソースを割り当てます。予約によって表される具体的なリソースの量は、仮想マシンの追加や削除など、環境を変更しても変化しません。

仮想マシンの予約を指定する場合、すべてのリソースをコミットしないでください (10% 以上を未予約にしてください)。システム内のすべての容量が完全に予約された状態に近づくほど、アドミッション コントロールに違反せずに予約とリソース プール階層に変更を加えることが困難になっていきます。DRS の有効なクラスタでは、クラスタの容量またはクラスタ内の個々のホストの容量を完全にコミットする予約によって、DRS が仮想マシンをホスト間で移行できなくなることがあります。

3.ポリシーの施行

DRSでは仮想マシン間の依存性を、ルール設定により制御が可能となっています。

それぞれの動きの特徴と利用シーンを下表でまとめます。

まとめ

以上のように、DRSをうまく活用していただき、効率よい仮想環境の構築・運用をしていただければと思います。