Home > Blogs > Japan Cloud Infrastructure Blog > タグ別アーカイブ: vSphere 5.5

タグ別アーカイブ: vSphere 5.5

新卒 SE 社員が贈る vSphere のキソ!第2回 ~仮想環境におけるネットワークとストレージ~

VMware 新卒 SE 社員が贈る  vSphere のキソ!、第2回目は、内部の仮想マシン同士や外部の世界とやりとりを担う「ネットワーク」、そして仮想化したからこそ成せる様々な機能を実現するために欠かせない「ストレージ」、この2つについて解説致します!

 

§1. ネットワーク編 ~仮想マシンはなぜネットワークに接続できるのか~

第1回の記事では、仮想マシンは1台の物理サーバ上で複数台動作させる事ができるとお伝えしました。一方で物理サーバに搭載する事のできる NIC の枚数は限られていますよね。では、どうやって仮想マシンはネットワーク接続を行っているのでしょうか?

 

§1.1. 仮想マシンのネットワーク概要 ~仮想化されたネットワーク機器~

仮想マシンは、 CPU 、メモリ、ストレージ等が割当てられており、仮想マシンに入っているOS(= ゲスト OS) はあたかも物理サーバ上で動作していると思い込んでいます。ネットワークの接続を行うため、 NIC も他のハードウェアと同様に仮想的なハードウェアとして仮想マシンに搭載する事ができます。この仮想 NIC 「 vNIC 」と呼びます。ゲスト OS は本物の NIC だと思い、 このvNIC に IP アドレスを割り当て、通信を行います。

次は、 ESXi サーバが外部や仮想マシン同士の通信を行うために必要な vSphere の機能について説明を進めます。

vNIC は仮想的な NIC なため、仮想マシンが vNIC から送信しようとする信号を物理ネットワークへ送るためには、 ESXi サーバに搭載された物理 NIC との紐付けが必要になります。しかし前述の通り、1つの vNIC につき1つの物理 NIC を割り当てとなると、 ESXi サーバには膨大な NIC が必要になってしまいます。そこで、 vSphere がどの様なアプローチを取っているかというと、 ESXi サーバの内部で仮想的なスイッチ「 vSwitch = 仮想スイッチ 」を作り、 ネットワークコントロールを行っています(図1)。想像してみてください。まさに物理サーバにケーブルを接続して、スイッチに接続する、という行為をESXiサーバ内部でも実施しているイメージです。

network_1433x1223

図1. 仮想マシンの物理ネットワークへの接続

図 1 の物理 NIC と物理スイッチの2つの「物理」と書かれた機器が実際に「目に見える」機器で、「仮想」と書かれた機器は全て ESXi サーバ内部で実現される「目に見えない」機器です。つまり ESXi サーバ内部では物理ネットワークと同じように仮想的にネットワークの構築に必要な機器を作り上げ、仮想マシンがネットワークへ接続できるようにしています。

 

§1.2. vSwitch ~物理と仮想を繋ぐ装置~
vNIC と vSwitch 、2つの機能についてご紹介させて頂きました。 vSwitch には、vSphere ならではの考え方がありますので補足させていただきますね。 まず、図2 をご覧ください。

 

vSwitch_new

図2. vSwitch のポートの種類(上:概念図、下:実際の管理画面)

 

vSwitch には3種類のポートが存在します。まず、物理 NIC と対応づけられる「アップリンクポート」、 ESXi サーバの管理や vMotion 、vSphere HA 、vSphere FT など vSphere の機能を使用するための 「VMkernel ポート」、そして最後に仮想マシンの vNIC を接続するための「仮想マシンポートグループ」です。

ここで、仮想マシンの接続用ポートだけ、「ポートグループ」とされていることに注目してください。 vSwitch は、各ポートのポート番号で接続を管理するのではなく、ひとまとまりのポート群、「ポートグループ」でポートを管理しています。このポートグループは L2 レイヤのネットワークを形成しており、VLAN ID もポートグループ毎に割当てることができます。

図2 の下の画像は vSphere Web Client からみた vSwitch の管理画面のキャプチャです。 この例では ESXi サーバ内のネットワーク(左側)はポートグループ毎にわかれて vSwitch に接続され、アップリンクポート(右側)には物理 NIC が割り当てられていることが解ります。物理 NIC は「 vmnic0, vmnic1, vmnic2, vmnic3,… 」など、「 vmnic 」というラベルを付けて ESXi サーバが管理していることが確認できます。ここでアップリンクポートに vmnic が2つある理由は、物理 NIC の冗長性を確保するためです。 vSwitch に複数の物理 NIC を割り当てることによって、冗長性を確保する設定を行う事が簡単にできます。

 

§1.3. ネットワーク編、まとめ

ここでは、vmnic、 vNIC、 vSwitch、 vSwitch  内のポートの概念をご紹介しました。vSwitch は仮想環境のネットワーク接続に欠かせない概念です。「 vmnic 」と「 vNIC 」は一文字違いで物理 NIC を指しているか仮想 NIC を指しているかが違う事などが理解できたのではないでしょうか。

今回説明した vSwitch は 「 標準 vSwitch 」と呼ばれ、 ESXi 内部に複数作成することが可能です。 ESXi サーバの台数が増えてしまうと仮想スイッチの管理も複雑になってきてしまうことから、複数の ESXi サーバにまたがって仮想スイッチを一元管理する事ができる 「 vSphere Distributed Switch 」という機能も存在します。これについては今後の連載でご紹介しますね。

 

§2. ストレージ編 ~実際の作業からキーワードを知る~

vSphere には、仮想マシンが動的に他の ESXi サーバに移行する「 vMotion 」や、 ESXi サーバが停止した際に、他の ESXi サーバから仮想マシンを再起動させる「 vSphere HA 」、2つの ESXi サーバで同一の仮想マシンを動作させてダウンタイムなしの可用性を実現する「 vSphere FT 」等、代表的な機能がありますが、この機能の実現にはストレージが大きく関わっています。ここではまず基本に戻って、 vSphere 環境でストレージを使用するまでの手順を追いながら用語と概念を押さえていきましょう。

comp_new

 図3. vSphere の構成とストレージの関係

§2.1. LUN, ボリューム ~ESXiとストレージの接続~

ESXi サーバが新しいストレージを使用するためにはまず、 ESXi サーバがストレージを認識する必要があります。設定を行うと、 ESXi サーバは LUN やボリュームをを検出します。次に ESXi サーバは、検出した LUN を仮想マシンファイル等を収容するための「データストア」として登録します。

LUN

図4. ストレージの検出

図4 は iSCSI ソフトウェアアダプタを確認した際に ESXi サーバに接続された iSCSI ストレージを確認している画面です。画面中央下段の「デバイス」タブにて検出した LUN が確認できます。ここでは45 GB の LUN が見えています。

select

図5. データストアの追加( ストレージの選択 )

次に検出した LUN をvSphereが管理するためにデータストアとして登録します。追加する画面では、図5 の様に ESXi サーバに接続されているストレージを参照する事ができ、この中からストレージを選択してデータストアとして登録します。

また、データストアに追加する際、FCやiSCSIのブロックアクセスストレージであれば 「 VMFS 」というファイルシステム でフォーマットします。(図6)。

 

VMFS_2

図6. データストアの追加( VMFS )

VMFS は、「 Virtual Machine File System 」の略で、仮想マシンを収容するために VMware が開発した仮想環境に最適なファイルシステムです。 LUN、ボリュームを設定されたストレージは VMFS にフォーマットされることでデータストアとして ESXi サーバ 内で使用する事ができるようになります(ストレージのブロックを直接操作する事のできる RDM ( Raw Device Mapping )という方式も存在しますが、簡単のためここでは割愛します)。
VMFS について詳しい内容が知りたい方は、2014年1月20日の記事をご覧ください

登録を終えると、データストアが図7 の様に追加されます。 vSphere からデータストア = 仮想マシン等がおかれる倉庫 として使用されます。

datastore

図7. データストア一覧

§2.2. 仮想ディスク( vmdk ~仮想マシンのディスクもファイル~

データストアとして登録が終了すると、いよいよ仮想マシンのファイルを ESXi サーバから収容する事ができるようになります。第1回目の記事で、仮想マシンの実体は複数のファイルであるとお伝えいたしましたが、ここではそのファイルの中のひとつ、「仮想ディスク = vmdk」について説明します。

「仮想マシンの実体はファイルである」とお伝えいたしましたが、仮想ディスクは「 .vmdk 」という拡張子のファイルとして存在し、仮想マシンにおいてローカルディスクの役割を果たします。この仮想ディスクは Windows であれば 例えばCドライブやDドライブとして認識され、このローカルディスクにファイルを書き込もうとしますが、実際は ESXi サーバが書き込み命令を検知して仮想ディスクファイルに内容を書き込んでいます。

newVM

図8. 仮想マシンのディスク容量の設定

 vmdk

図9. データストアから見た仮想ディスクファイル

図8 の様に、新しい仮想マシン「 kiso 」を、15 GB のディスクを搭載すると設定して作成すると、データストアには約 15 GB の仮想ディスクファイル 「 kiso.vmdk 」が作成されている事が解ります(図9)。

 

§2.3. ストレージ編、まとめ

vSphere におけるストレージをこれから深く学ぶにあたって必要な語句を、 ESXi サーバがストレージを認識して仮想マシンを作成するまでの手順を追って説明いたしました。どのレイヤでどのような語句が使用されているか解っていただけたのではないでしょうか。

 

§3. おわりに

vSphere 環境におけるネットワークやストレージは、見えない分用語の理解とイメージをつかむ事がとても大事になってきます。今回のご説明で vSphere 環境におけるネットワークやストレージの理解が少しでも深まれば幸いです。
次回は川崎君による「 vSphere HA / vMotion / vSphere FT 」の説明です。楽しみにしていてくださいね!!

VMware SE 椨木正博

 

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

やってみよう! vSphere Data Protection(VDP) 環境構築

やってみよう! VMware vSphere Data Protection(VDP) 環境構築

本エントリでは、バックアップ及びリストア機能を提供するVDP の環境構築方法をご紹介します。 VDP は、vSphere のEssentials Plus 以上のライセンスに含まれており、vSphere 上で稼働する仮想アプライアンス(仮想マシン)として、提供されています。

まず、VDPの動作環境がサポートされているvSphere 環境とVDP のova ファイル準備します。 サポートされているのは、以下のような環境になります。

・vCenter 5.1 または 5.5 に対応(vCenter Server Appliance も可能)

・ESX/ESXi 4.0、4.1

・ESXi 5.0、5.1、5.5

詳細はVMware Product Interoperability Matrixes でご確認下さい。

※VDP の最小システム要件は、4つの2GHzプロセッサ / 4GB メモリ / 873GB ディスクとなっております。

VDP のova ファイル は、My VMware にログインしてダウンロードしておきます。 製品のダウンロード方法は、こちらのブログを参考にして下さい。 今回は、Virtual SAN 環境にも対応している最新バージョン5.5.6(vSphereDataProtection-5.5.6-0.0TB.ova)を使用しています。

1. VDP の動作環境にはDNS サーバが必要になりますので、VDP 環境構築する前に、VDPアプライアンスのIPアドレスおよびFQDN 用のエントリをDNS サーバに追加しておきます。

2.vSphere Web Client を使用して、ダウンロード済みの ova ファイルを展開します。 メニューの”OVF テンプレートのデプロイ”を選択します。

VDP_Deploy1

3. “ソースの選択”では、”ローカル ファイル”をチェックし、”参照”ボタンを押して、ローカルに保存している” vSphereDataProtection-5.5.6-0.0TB.ova”を開きます。

VDP_Deploy2

4. “OVF テンプレートのデプロイ”のウィザードに従って進めます。 VDP アプライアンスをデプロイするストレージを選択します。 ここで指定するストレージは、VDP アプライアンスのOS 部分を配置するストレージになります。 バックアップデータが保存されるストレージは、VDP アプライアンの初期起動後に設定します。

VDP_Deploy3

5. ウィザードを進めてネットワークのプロパティを入力し、デプロイに必要な情報の入力を完了させます。 ”終了”ボタンを押すと、デプロイが開始されます。

VDP_Deploy4

6. デプロイが完了したら、VDPアプライアンスの電源をONして、起動が完了するまで待ちます。

VDP_Deploy4.5

7.  VDP アプライアンスの起動を確認したら、VDP アプライアンスが提供するvSphere Data Protection 構成ユーティリティ(https://<IP_address_VDP_Appliance>:8543/vdp-configure/)にWeb ブラウザで接続し、”ユーザ名”に”root”、”パスワード”に”changeme” と入力し、ログインします。 構成ウィザードに従って進めます。

VDP_Deploy5

8. 1. で予めDNS サーバにVDP アプライアンスのエントリを追加しておくと、DNS サーバから情報を取得し、自動的にネットワーク項目が入力されます。

VDP_Deploy5.5

9. ”タイムゾーン”は、”Asia/Tokyo” を選択します。

10. “VDP認証情報” では、デフォルトパスワード”changeme” から変更します。

VDP_Deploy6

11. “vCenter の登録”を実施します。登録に必要な情報を入力し、接続テストを実施してから、次に進みます。

VDP_Deploy7

12. “VDP ライセンス”では、ライセンス キーを登録することで、VDP Advanced の追加機能を有効にできます。 後からでもVDP から VDP Advanced にアップグレードすることも可能なので、今回は入力せずに”次へ”ボタンを押します。

VDP_Deploy8

13. “ストレージの作成”では、バックアップデータを保存するための仮想ディスクファイル(VDP ストレージディスク)を新規に作成します。 ここでは、最小サイズの”0.5 TiB” を選んでおりますが、VDP は1TiB もしくは2TiB の選択が可能です。 ※後から容量を増加させるためには、Advanced へのアップグレードが必要になります。

VDP_Deploy9

14. “デバイスの割り当て”では、VDP ストレージディスクを配置するデータストアを決定します。こちらの例では、”アプライアンスで保存”のチェックを外し、VDPアプライアンスのOSが配置されているデータストア(datastore3)とは異なるデータストア(datastore1)に配置しております。 0.5TB の場合は、256 GiB のディスク3 台で構成されます。

VDP_Deploy10

15. “CPUとメモリ”では、VDP ストレージに対する最小要件が表示されます。

VDP_Deploy11

16. “設定の確認”では、必要に応じてストレージのパフォーマンス分析を実行することが可能です。 今回は字実施せず、”次へ”ボタンを押して、ストレージ構成を開始します。ストレージの構成が完了すると、VDP アプライアンスは自動的に再起動します。 環境に依存しますが、この再起動には時間が掛かります。

VDP_Deploy12

17. VDP アプライアンスの再起動完了を待って、vSphere Web Client にログインします。 再起動前にvSphere Web Client にログインしていた場合には、ログオフしてから再度ログインします。 ログイン後、”ホーム”の中に”vSphere Data Protection 5.5” のプラグインが追加されていることを確認し、接続するVDP アプライアンスの名前を選択し、”接続”ボタンを押します。

VDP_Deploy13

18. VDP アプライアンスに接続すると、バックアップ/リストア/レプリケーションなどを実施することができるようになります。 複数のVDP アプライアンスをvCenter に登録している場合(最大10 台)には、右上からVDP  アプライアンスを切り替えることが可能です。

VDP_Deploy14

以上でVDP 環境構築は完了です。非常に簡単な手順で仮想マシンのバックアップ / リストアができる環境を構築できます。 環境構築同様にVDP を利用したバックアップやリストア手順も簡単に実施いただくことが可能です。本ブログは環境構築のみとなりますが、バックアップ手順に関してはこちらのハンズオンラボのドキュメントを参考にして、是非実施してみてください。

やってみよう!vSphere on VMware Fusion編

本エントリでは、最新のVMware vSphere の機能を理解し、簡単に検証していただくためにご利用いただくための簡単な裏技をご紹介します。機能検証や操作手順の確認のであれば、本ブログで以前ご紹介した(http://blogs.vmware.com/jp-cim/2013/12/hol.html)ハンズオンラボをご利用いただくのも良いのですが、ハイパーバイザーのインストールを含めた構築作業そのものやハンズオンラボのシナリオに無い操作をご体験していただくことができません。

VMware vSphere はVMware Fusion やVMware Workstation, VMware Player を使用するとMac OSX やWindows のPC 上で簡単に構築することができます。
このように、ハイパーバイザー上に仮想マシンを構築し、ハイパーバイザーをインストールしてさらにゲストマシンをインストールする構成を”Nested(ネステッド) ”と呼びます。

nested

nested2

ネステッド構成は、互換性リストに掲載されているハードウェアが準備できない場合等に、手持ちの環境で手軽に検証環境を構築できることがこの構成の大きなメリットです。
なお、下記KBにあるように、ネステッドの構成の場合は本番環境としてご利用いただくことはできませんのでご注意ください。

Support for running ESXi/ESX as a nested virtualization solution (http://kb.vmware.com/kb/2009916)

最近では、このネステッド環境に特化したVMware tools もFling (フリーウェア)として提供されています。

https://labs.vmware.com/flings/vmware-tools-for-nested-esxi

では、早速VMware Fusion を使用してネステッドESXi を構築してみましょう。

1. 仮想マシンライブラリで+(追加)→新規をして仮想マシンを新規作成します。

2. ディスクまたはイメージからインストールを選択します。

仮想マシンを作成_と_仮想マシンのライブラリ

3.「別のディスクまたはイメージを使用」をクリックしてあらかじめダウンロードしておいたハイパーバイザーのインストールイメージを指定します。

新しい仮想マシン_と_nested_と_仮想マシンのライブラリ

新しい仮想マシン_と_nested

4.「仮想マシンの構成が完了しました。」とメッセージが表示されます。

このままだと、デフォルトの仮想マシン構成(vCPU 2コア、4GB RAM 、40GB ディスク)という構成になりますので、適時ご利用いただいている環境に合わせてサイズを変更します。

VMware Fusion でネステッド構成を構築した場合、ネットワークアダプタはE1000 となりますが、vSphere on vSphere の場合はvmxnet3 を利用するとより安定したパフォーマンスが得られます。

新しい仮想マシン_と_nested_と_仮想マシンのライブラリ 2ここまででひととおり完了です。

作成した仮想マシンを起動すると、ESXi のインストーラが始まりますので、通常と同じようにインストールします。Mac の場合に、F11キーが直接入力できませんので、fn + ⌘(Command) + F11 もしくは、仮想マシン→キーの送信→F11 を使用して入力します。

インストールが完了した画面がこちらになります。VMware_ESXi_5

お手軽な検証環境をつかって、操作方法の確認等にぜひお役立てください。

参考KB

Installing ESXi in VMware Fusion (http://kb.vmware.com/kb/2009580) 

Support for running ESXi/ESX as a nested virtualization solution (http://kb.vmware.com/kb/2009916)

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

皆様こんにちは。前回は、vSphere のEnterprise エディションで提供される機能によりストレージの能力を最大に活用する方法をお伝えいたしました。引き続き、「押さえておきたいvSphereの基本」と題して、“ストレージを自動的に整える”方法をお伝えします。

ストレージを自動的に整えるとは、どういうことでしょうか?ストレージの能力/性能が最大限に活用できるようになれば、より多くの仮想マシンをストレージ上に配置できるようになります。しかしながら、仮想マシンのI/Oが競合し、ストレージの能力を超えてしまった場合には、仮想マシンのパフォーマンスは悪化してしまいますので、ストレージに対して性能や容量を整える工夫が必要になってきます。

■ストレージを整える

様々なサービスを提供する仮想マシンは、仮想マシン毎にI/O 数、レスポンスタイム、スループット、容量などストレージに対する要件が存在します。仮想マシンが安定して稼働するためには、きちんと仮想マシンの特性を理解して、バランスよく配置することが求められます。例えば、午前にI/O 要求が高まる仮想マシンと午後にI/O 要求が高まる仮想マシンを同一データストアに配置するという形になります。ところが、実際の仮想化環境というのは時間、分、秒といったもっと細かい粒度で稼働状況が変化していきます。また、仮想マシンの増減やシステムを利用するユーザの増減などによっても、CPUやメモリと同じようにストレージの要件は時間の経過とともに変化していきます。そのため、すべての仮想マシンの稼働状況を把握し、IT管理者の方が手動でバランスよく配置し続けることは作業負荷が重くなってしまいます。vSphere のEnterprise plus エディションでは、そのような課題を解決する機能を提供しております。

具体的な例を見ていきます。こちらの図1では、5つの仮想マシンが3台のホストと1つのデータストア上で稼働をしています。ホストは分散されておりますが、データストアは1つのみであり、5つの仮想マシンはこのデータストア上に配置されています。各仮想マシンは、稼働状況に応じて必要なI/Oを発行していますが、あるタイミングでストレージの能力を超えるI/Oが仮想マシンから発行された場合、ディスクI/Oに関する資源の取り合いが発生し、仮想マシンのパフォーマンスが劣化してしまう、またはそのデータストアに配置される仮想マシン全体に影響してしまうことも考えられます。パフォーマンス劣化する仮想マシンが、重要であればあるほど、問題が大きくなりますので、そのようなことが起きたとしても、影響をできるだけ少なくする必要があります。それが、仮想マシンのI/O優先順位を”整える”という機能(Storage I/O Control)です。

3-11

図1:複数の仮想マシンがデータストアを共有する= IOリソースの共有

この機能はストレージの能力に余裕がある場合では発動しませんが、ストレージの能力が枯渇した際(競合状態)に発動されることになります。図2のグラフは、仮想マシンのI/O優先順位を整えるよう設定した各仮想マシンの稼働状況になります。Phase1~3 は、いずれもストレージの能力が枯渇している時間となっており、単一ホストではなく、複数のホストに跨っていても状況を理解し、優先順位に応じて各仮想マシンからのI/O が整えられています。
各仮想マシンの優先順位は予めVM5(4000) >>> VM3,4(750) > VM1,2 (500) としております。
()内は仮想マシンに設定したシェア値です。

Phase2 の時間帯では、非常に高い優先順位を設定している仮想マシン(VM5)がシャットダウンされたことにより、使えるストレージ資源に空きが生じます。稼働している他の仮想マシンは、Phase1 の時より多くのストレージ資源を使えるようになっているため、各仮想マシンのパフォーマンスが向上しています。そして、再びPhase3 でVM5を起動すると、ストレージ資源が優先的にVM5 に提供されるようになります。仮想マシンのI/Oを整えることにより、ストレージ資源を有効活用し、たとえ枯渇したとしても、vSphereの機能で影響を最小限にすることできます。

3-22

図2:シェア値(優先度)の違いにおける負荷の様子

仮想マシンのI/Oの優先順位を整えるという説明をしてきましたが、Storage I/O Controlはストレージが一時的に資源不足になった際の対応策となります。常時発動されているという状況は配置している仮想マシンに対して、常にストレージの資源が足りていないということになりますので、恒久的な対策が必要になります。
例えば、1つのストレージ(データストア)の能力を上げるという方法もありますが、vSphere のEnterprise plusエディションでは、ホストと同じように複数のデータストアをデータストア クラスタとして、”束ねる”ことができます。データストア クラスタに資源が足りなくなった際、新たにデータストアを追加し、データストア クラスタのトータルの資源を簡単に増加させることが可能になります。例えば、100iops,100GBの資源を提供可能なデータストアが3つ登録されているデータストアクラスタは、300iops,300GBのひとつの資源と考えることができるようになります。

3-33

さらに自動的にこのデータストアクラスタを有効活用できるStorage DRS という機能を使用すれば、データストア クラスタ内(複数のデータストア間)で、過去の統計情報を基に負荷や容量を自動的に整えてくれます。自動的に整えられる際は、第1回でご紹介したStorage vMotion を使用し、システム停止させることなく行われます。※ホストのDRS と同様に手動モードで実施することも可能です。

仮想化環境において、ストレージ環境を整える機能を活用することにより、ストレージの負荷や容量を監視しながらの仮想マシンの配置、移行といったIT管理者の負荷を減らす事ができ、仮想環境の特性を活かしたより有効的な使用ができるようになります。

まとめ
今回、vSphere Enterprise plus エディションで提供している機能(ストレージに対する負荷や容量を自動的に整える機能)をご紹介させていただきました。主にESXiが10台以上となる環境では積極的に使用していただきたい機能になります。人間で例えると骨盤のずれで偏りができてしまうと、肩こりや頭痛など体全体の調整を崩してしまったり、本来のパフォーマンスが出せなかったりすることがあるかと思います。この「ズレや偏り」を治すため、整体やマッサージ等コンディションを整えたりします。ストレージでも同様、IOや容量の偏りが原因でシステム全体に影響がでてしまい、本来もっている能力を出せないことは非常にもったいないことです。是非vSphereの機能を有効活用していただき、仮想基盤のコンディション(すなわちパフォーマンス)をさらに高めていただければ幸いです!!

3-4
VMware青山健二/中村朝之

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

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

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

押さえておきたい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編~

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編~

vSphere 5.5へのアップグレード

vSphere 5.5 へのアップグレードについて その2 ~ ESXi 編 ~

全2回でお送りする vSphere 5.5へのアップグレードに関するブログ、その2はESXi編です。
その1 vCenter Server編はこちら

前回お伝えした通り、vSphereのアップグレードには、以下の段階的な工程があります。 Upgrade Step
今回は、ステップ3〜5についてお伝えしていきます。

 

ステップ3(ESXi) のポイント:

  • ESXi 5.5のハードウェア要件については、[vSphereのアップグレード]のドキュメントの[ESXiのハードウェア要件] を必ず参照して下さい。特にハードウェアの[VMwareの互換性ガイド]は必ず確認してください。以前のバージョンが動作したから5.5でも動作するだろう、と憶測するのは危険です。その他、ESXからESXiへアップグレードする際の注意点や、必要な事前確認項目の詳細については、[ホストのアップグレードの準備]を参照してください。
  • ESXi5.5へのダイレクトアップデートが可能なのは、ESX/ESXi 4.0以上です。ESX/ESXi 3.5からのアップグレードを実施する場合は、1度ESX/ESXiを4.xへアップグレードする必要があります。
  • ESXiの構成が比較的シンプル、かつホストの台数が少ない場合には、アップグレードではなく新規インストールのほうが適している場合があります。
  • 実際のアップグレードでは、CD/DVD/USBを使用する方法や、スクリプトによるアップグレード、vSphere Update Managerを使用する方法などがあります。それぞれの詳細については、[ESXi5.5のアップグレードのオプション]を参照してください。
  • esxcliコマンドを使用してESXiをアップグレードする場合は、VIB、イメージプロファイル、およびソフトウェアデポについて理解している必要があります。これらの詳細については、[VIB、イメージプロファイル、およびソフトウェアデポ]を参照してください。
  • ホストが複数台あり、かつクラスタ環境であれば、アップグレード対象のホスト上から仮想マシンをvMotionで移動させ、ホスト上で仮想マシンが稼働していない状態にしてからESXiのアップグレードを実施する、ローリング・アップグレードを推奨します。ローリング・アップグレードを実施することで、アップグレードに伴うダウンタイムを回避することができます。またUpdate Managerを使用すると、自動的にローリング・アップデートが実施されます。
  • vSphere Install Components

 

ステップ4(仮想マシン) のポイント:

  • vSphereのアップグレートにおいて、仮想マシン側でアップグレードが必要となるのは、①VMware Tools と、②仮想マシンのハードウェアバージョン の2点です。
  • ①VMware Tools や ②仮想マシンのハードウェアバージョン の互換性や、その他アップグレードの詳細については、[仮想マシンのアップグレード]を参照してください。
  • vSphere Install Components
  • 必ず ①VMware Tools のアップグレードを先に実施し、次に ②仮想マシンのハードウェアバージョン をアップグレードしてください。
  • これらのアップグレードは、実際には任意ですが、常にESXiと互換性がある中での最新バージョンにしておくことを推奨します。

 

ステップ5(VMFS) のポイント

  • VMFS-3とVMFS-5の相違点については、[VMFS5 の VMFS3 との相違点]を参照してください。
  • VMFS-5からVMFS-3へのダウングレードはできません。
  • VMFS-5へのアップグレード後は、ESX/ESXi5.0以前のバージョンからはアクセスできなくなります。
  • VMFS-3からアップグレードされたVMFS-5データストアと、新規作成もしくはフォーマットされたVMFS-5データストアでは、仕様が異なる部分があります。詳細は[VMFSデータストアのアップグレード] を参照してください。
  • アップグレードの方法としては、ストレージを準備し、新しい VMFS-5 データストアを作成して、既存の仮想マシンを Storage vMotion で新しい VMFS-5 データストアへ移行する方法を推奨します。
  • VMFS-5へのアップグレードは、vSphere Web ClientやvSphere Clientから、オンラインのまま実施することも可能です。
  • vSphere Install Components

vSphere 5.5へのアップデート、第2回はステップ3(ESXi)とステップ4(仮想マシン)、ステップ5(VMFS)についてご紹介しました。vSphere環境のアップグレードは、作業前の事前確認と事前準備が重要です。繰り返しになりますが、アップデートに際しては必ず[vSphereのアップグレード]ドキュメントをご一読ください。

vSphere 5.5 へのアップグレード

vSphere 5.5 へのアップグレードについて その1 ~ vCenter Server 編 ~

2014年5月21日に vSphere 4.x(vCenter Server 4.x、および、ESX/ESXi 4.x)のジェネラル サポートが終了となります(詳細は、弊社ウェブサイトのVMware サポートポリシー販売終了(エンド オブ アベイラビリティ)タブにある製品のライフ サイクル マトリックス(PDF)を参照してください)。

そこで、2回にわたり「vSphere のアップグレード」のドキュメントの参照ポイントについてご紹介します。

アップグレードを計画する上で、最初に行う必要があるのは、既存のハードウェアや関連ソフトウェア(特に vCenter Server や Update Manager で利用しているデータベース) が vSphere 5.5 でサポートされているかを確認する事です。

それぞれ以下のサイトで確認の上、必要な場合は、ハードウェアのリプレイス (32bit CPU を搭載したサーバの場合) や、関連ソフトウェアのアップグレードを行ってください。その後、vSphere 5.5 へのアップグレード作業を開始してください。

 

vSphere のアップグレードには次の様な段階的な工程があります。
Upgrade Step

ステップ1(vCenter Server) のポイント:

ステップ2(Update Manager)のポイント:

  • Update Manager を使用している場合、vCenter Server を 5.5 にアップグレードした後に、Update Manager も 5.5 へアップグレードする必要があります。詳細は「vSphere のアップグレード」のドキュメントの「Update Manager のアップグレード (サブトピック含め)」を参考にしてください。
  • Update Manager の使用権はvSphereに含まれており、ESX/ESXi ホストへのパッチ適用、および、アップグレード、仮想マシンの VMware Tools、および、仮想ハードウェア バージョンのアップグレードの管理が可能で、手作業でのパッチ適用やアップグレードを実施する際の人的ミスを回避するのに非常に有益な製品です。今までご使用になられていない場合は、vSphere 5.5 へのアップグレードを期に 、是非、Update Manager の新規導入もご検討ください。
  • Update Manager

 

今回は、ステップ1(vCenter Server)とステップ2(Update Manager)の「vSphere のアップグレード」のドキュメントの参照ポイントについてご紹介しましたが、アップグレードに際しては必ず「vSphere のアップグレード」ドキュメントを事前にご一読される事をお勧めします。

次回は ~ vSphere ホスト (ESXi) と仮想マシン編 ~ として、ステップ3からステップ5の「vSphere のアップグレード」のドキュメントの参照ポイントについてご紹介する予定です。

vSphere 5.5 の新機能紹介 VMware Virtual SAN その3

前回、その2では、ストレージポリシーを利用した仮想マシンのSLAの管理についてご説明しました。今回は、Virtual SANの読み書き、及び障害時の動作についてご説明します。

書き込み処理

 許容障害数=1 で作成された仮想マシンを例にとってご説明します。このポリシーを適応され作成された仮想マシン(仮想ディスク)は、VMDKファイルが2つのホスト内のHDDに分かれて配置されます。

1. 上記ケースでは、ホストH1とH2にVMDKファイルが配置されています。その際、このオブジェクトに対するオーナーが決まります(上記例ではH1)
2. 仮想マシンはオブジェクトオーナであるH1に対し、書き込みの要求を発行します
3. オブジェクトオーナーであるH1は書き込み要求を二つ作成し、H1 とH2 に対して発行します
4. 各ホストのSSD上で「準備」が完了すると、それぞれ「ACK」を返します(ライトバック動作となります)
5. オーナーはH1、H2からの「ACK」を受け取るとIO完了を仮想マシンへ通知、仮想マシンでの書き込み処理が完了します
6. SSD内のキャッシュは数秒間蓄積された後、HDDへディステージされ、SSD領域から削除されます

読み込み処理

上記と同じ仮想マシンでの読み込み処理について説明します。

1. 仮想マシンはオブジェクトのオーナーであるH1に対し、読み込みの要求を発行します
2. オブジェクト(VMDK)はある容量毎に読み込みを実行するホストがあらかじめ決められています(上記例ではH2)*
3. H2のキャッシュにヒットした場合はSSDから読み込みます
4. キャッシュミスした場合はHDDから読み込まれ、SSDにキャッシュされます
5. 読み込んだ内容がH1に返ります
6. 仮想マシンの読み込み処理が完了します

※このアルゴリズムにより、同一領域が複数のSSDにキャッシュされることが無くなり、SSDの利用効率が最大化します。

障害及びホストメンテナンスに関して

 ディスク障害時やホスト障害時の仮想マシンの可用性、さらにはホストのメンテナンス時の考慮事項と具体的なオペレーションについてご説明します。

ディスク障害
 Virtual SANを構成するHDD 1 台が障害を起こした場合、適応されたストレージポリシーに従って仮想マシンの可用性が担保されます。この場合デフォルトである、許容する障害数=1 以上で作成された仮想マシンに関しては連続稼働が担保されます。

 障害を起こしたHDDがエラー状態でオペレーション継続不能な状態に陥った場合、ホストは即座に復旧処理を開始します。上記の場合は薄青の仮想ディスクに対し復旧処理を開始し、以下のような状態となります。


”障害を起こしたHDDがエラー状態でオペレーション継続不能な状態” というのが実はミソです。上記したとおりHDDの障害が永久障害と判断される場合は即時復旧となりますが、例えばHDDの状態が分からない様な場合(疑似障害発生のためHDDを抜いた場合など)、ホストはコンポーネントの一時障害か永久障害か区別が付かないため下記ホスト障害同様、一定時間デバイスが復帰するのを待つ動作に入ります。HDDの復旧処理は重い処理であるため、一時障害で戻ってくるのであればそれを待つアルゴリズムになっているということです。

ホスト障害時
 ホスト障害時の仮想マシンの可用性は、vSphere HA(ホストの可用性)とVirtual SAN(ストレージの可用性)で担保されます。例えば、vSphere HAとVirtual SANを利用した以下のようなクラスタで、一番右のホストが障害でストップしてしまった場合を考えます。

上記で影響を受けるのは、以下のオブジェクトです。
 障害を起こしたホスト上で稼働する仮想マシン
 障害を起こしたホスト内に存在する仮想ディスク
  薄青・・・3面ミラー構成
  薄緑・・・2面ミラー構成

この場合、以下のようになります。

1. 障害を起こしたホスト上稼働していた2つの仮想マシンは、レプリカディスクを利用して他のホストで起動する(vSphere HA)
2. 一定時間経過してもホストが復帰しない場合*、ストレージポリシーに従い仮想ディスクの再配置を行う(Virtual SAN)

 ※2の一定時間に関しては、ホストの詳細設定VSAN.ClomRepairDelayパラメータで定義されており、デフォルト値は60分となっています。

ホストメンテナンス・削除時
 通常のクラスタ環境同様、ホストをメンテナンスモードに変更します。このオペレーション時、以下のような確認画面が表示されます。オプションは以下の3つがあります。このオプションを利用することにより、管理者の意図した形でかつ安全に、ホストをVirtual SANから取り外すことが出来ます。なお、この作業は、必ずvSphere Web Clientで行ってください。vSphere Clientではサポートされません。

・アクセシビリティの確保(デフォルト)
 該当ホストをVirtual SANデータストアから外しても仮想マシンの動作に問題ない場合、仮想ディスクの待避は行いません。ホストへのパッチ適応や一時的なシャットダウンなど、ホストをメンテナンスしたい時に利用するオプションです。このオプションを選択すると、ストレージポリシーに違反する仮想マシンが出てくる可能性があります。このため、恒久的にホストを削除する場合には適さないオプションです。

・全データの移行
 該当ホスト内の仮想ディスクを他のホストへ待避します。多量のデータ転送が発生するため、メンテナンスモードに移行するまでの時間が長くなります。恒久的にホストをVirtual SANから削除する際に適するオプションです。

・データの移行なし
 仮想マシンの稼働にかかわらず、仮想ディスクのデータ待避を行いませんので仮想マシンが仮想ディスクへアクセスが出来なくなる可能性があります。

まとめ

 3回に渡りVirtual SANについてご紹介を行いました。Virtual SANは安価なホストローカルのストレージを利用する、拡張性に富んだストレージの新機能です。現在PublicBetaという位置づけですが、将来のFullサポートを視野に入れ、是非この段階での評価をご検討下さい。

Virtual SAN Public Beta登録サイト
http://www.vmware.com/vsan-beta-register.html