Home > Blogs > Japan Cloud Infrastructure Blog > 作成者別アーカイブ: Tomoyuki Nakamura

作成者別アーカイブ: Tomoyuki Nakamura

VSANにおける SSDの役割

本blogは VMware Storage Business UnitのCormac Hogan Blog の翻訳になります。VSANをより深く知っていただき活用していただく為、本記事の翻訳がお役に立てば幸いです。
最新のVSAN 6.2では「ハイブリッド」と「オールフラッシュ」2つの方式のがありますが、本記事はハイブリッド方式の記事となります。

★SSDにおける役割

VSAN 内における SSD は、リードキャッシュとライトバッファとして作用します。これは VSAN データストア上で実行される仮想マシンのパフォーマンスが向上させます。

VSAN はストレージ市場における SSD と HDD を備えた”ハイブリッド”ストレージと比較されますが、パフォーマンス向上だけでなく、キャパシティのスケールアウトも特徴として兼ね備えています。それでは VSANにおけるリードキャッシュとライトバッファについて話を進めていきましょう。

★リードキャッシュ★

リードキャッシュは、頻繁にアクセスするディスクブロックのリストを保持します。これは、キャッシュヒット時に、I/Oリード遅延を削減することができます。

VSAN において興味深いのは、アプリケーションが読み取られている実際のブロックが、仮想マシンが実行されているESXiホストにないかもしれない、ということです。

言いかえると、仮想マシン自体はあるESXiホスト上で動いておりますが、その仮想マシンのストレージオブジェクトは、それとは異なるESXiホスト上にあってもよい、ということです。

ストレージオブジェクトが異なる ESXi 上に分散している際、該当するブロックが VSAN クラスタ内の別 ESXi ホストのリードキャッシュにあるかどうか探します。キャッシュミスがある場合、データは HDD から直接取り出されます。

VSAN はリードキャッシュがヒットしやすいように常に同じレプリカを読み取るようにします。つまり、クラスタ内どこか1つのノードでキャッシュされます。キャッシュスペースは比較的高価ですので、このメカニズムがキャッシュ利用効率を最適化してます。

★ライトバッファリング★

ライトキャッシュは、不揮発性ライトバッファとして動作します。アプリケーションからの書き込みは、SSDに書き込まれた際 ACKを返します。 もちろんこの動きは書き込み時の遅延予防となります。

SSDに書き込むので、 ハード障害時に備えて VSAN クラスタ内のどこかにデータコピーがある必要があります。

ポリシーによって、VSANに展開される仮想マシンはコピーを持たせることができます。これは、ライトキャッシュコンテンツも含みます。

アプリケーションによって書き込みが開始されると、”オーナー”であるホストのライトキャッシュに書き込むのと同時に、レプリカのあるリモートホストのライト キャッシュにも書き込まれます。

書き込まれたキャッシュデータは、他のホストでもコピーを保持しているので、ホスト障害が起きた際も安心です。その後、SSDに書き込まれたキャッシュデータは、一定の間隔で、HDDにデステージされます。

他のフラッシュソリューションと同様、VSANは可能な限り最高のパフォーマンスを提供します。

原文:The role of the SSD
VMware Storage and Availability Business Unitの シニアスタッフエンジニアCormac Horganの個人ブログを翻訳したものになります。VSANの詳細に関しては弊社マニュアル 、KBをご確認ください。また本記事は VSAN 5.5ベースに記載しております。予めご了承ください

VSAN Cormac Blog 〜手動・自動モードについて〜

本blogは VMware Storage Business UnitのCormac Hogan Blog の翻訳になります。VSANをより深く知っていただき活用していただく為、本記事の翻訳がお役に立てば幸いです。

VSAN クラスタの作成は、DRS / vSphere HA クラスタを作成する方法とほぼ同様にできてしまいます。まず、vSphere  HA/DRS クラスタを予め作成、VSAN クラスタを有効にしてからESXiホストを追加することもできますし、最初にESXiホストをクラスタに登録し、その後 VSAN を有効にすることもできます。

VSAN クラスタ :  vsanDatastore を構成するESXi群を指します。

VSAN 機能を有効にすると、手動または自動(デフォルト)の選択画面が表示されます。VSAN がESXiホストの空ディスクを検出し、自動的にVSANにクラスタに追加、もしくは手動でディスクを選択しVSANクラスタに追加することも可能です。

手動モード

VSANクラスタ作成時に手動モードを選択すると、VSAN クラスタ自体は作成されますが、HDDが選択されてないので、vsanDatastoreの容量は0です。 手動モードでは、管理者がESXiホストごとに「ディスクグループ」を作成します。ディスクグループには最大7つのHDD(キャパシティ用途)と1つのSSDディスク(キャッシュ用途)を追加する必要があります。

図1

 

ディスクグループの概念として、ストレージコンテナー(器)として考えることができます。 vsanDatastore のサイズはキャパシティ用途のHDD容量によって決まります。 SSDは、リードキャッシュ機能およびライトバッファとして使われるため、VSAN データストアの容量に含まれません。

VSAN クラスタの拡張時、手動モードで設定されたVSAN クラスタに ESXiを追加する場合、そのESXi ホストからローカルストレージが自動的に VSAN データストアに追加されません。 管理者は手動でディスクグループを作成し、ディスクグループにディスクを追加する必要があります。

 

自動モード

自動モードが選択されている場合、各 ESXi ホスト上の空HDDとSSDを自動的に検出し、各 ESXi ホスト上にディスクグループを構築します。

各ディスクグループにつき1つのSSDが必要になるので、もし各 ESXi ホストに複数SSDがある場合、各 ESXi ホストには複数のディスクグループが作成されます。VSANデータストアが作成されると、VSANクラスタを構成しているメタデータ部分を少し差し引いたHDDの容量がvsanDatastoreのサイズとして反映されます。

VSANクラスタに新しいESXiホストが追加される場合、 ESXi ホストにある使われていないストレージは自動的に VSAN に検出され ディスクグループが作成されます。

最後にディスクグループの最大構成情報 (VSAN 6.2)になります。

-最大 5 ディスクグループ / ESXiホスト
-最大 7 HDD (キャパシティ用途) / ディスクグループ
-最大 1 SSD (キャッシュ用途) / ディスクグループ

VSAN 最大構成詳細に関しては、こちらを参照ください。

原文:Manual or Automatic Mode
VSAN Cormac Blog 日本語版 Index

VSAN Cormac Blog 〜VASAの役割〜

本blogは VMware Storage Business UnitのCormac Hogan Blog の翻訳になります。VSANをより深く知っていただき活用していただく為、本記事の翻訳がお役に立てば幸いです。

VASA と VSAN

VASA (よく “ヴァーサ”と発音してます) とは、vSphere 5.0 で紹介されている vSphere Storage API の拡張版で、 “vSphere Storage API for Storage Awareness ” の頭文字をとっています。 VASA はストレージの管理性を高める機能として vCenter の Plug-in もしくはストレージベンダーが提供するプロバイダー経由で vCenter に統合されています。

補足1 〜 VASA の由来〜

vMotionで仮想マシンがホスト間を移動できるように、 VMDK もStorage vMotion で ストレージを柔軟に行き来できるようになっています。ところが配置しているストレージを変更することによって、パフォーマンスや保護レベル等、いわゆるストレージのサービスレベルが異なることも考えられます。あらかじめこの VASA 経由で LUN や Volume の情報( 例:RAIDレベルだったり、スピンドルの情報など)を vCenter でも把握し、仮想マシンのサービスレベルに応じた配置を適切にできるようにします。

この VASA の仕組みを使ってストレージの情報を吸い上げますが、vCenterとストレージが会話する際、ストレージプロバイダ (VASA プロバイダとも呼ばれます) が必要になります。

このストレージプロバイダはストレージコントローラ上かホスト側 ( アプライアンスとして提供する場合もあります)に存在しています。 VSAN の場合も VASAの仕組みを利用しており、ストレージプロバイダはESXiホスト上に配置されています。

VASA が出た vSphere 5.0時代は、 1 LUN または Datastore に対して1つのストレージ情報 ( =  capability )を扱うことができましたが。vsanDatastoreの場合、複数のストレージ情報(capability)を定義することができます。(図1)

 

図1

VSAN がリリースされた当初、可用性周り、プロビジョニングとパフォーマンンスについて vCenter上でみることができましたが VSAN 6.2 ではさらにこのストレージ情報(capability)の種類が増えています。

ストレージプロバイダの確認

VSAN のストレージプロバイダを確認するには、vSphere Web Clientで確認できます。 vCenter Serverに[Manage]タブを選択し、[Storage Providers]を選択します。( 図2 )

ESXi ホストと VSAN クラスタを示しています。すべての ESXi ホストはストレージプロバイダを持っています、1 ESXi ホストがアクティブ状態になり、残りの ESXi ホストはスタンバイ状態です。

Storage Provider
(図2)

補足2  〜仮想マシン単位でサービスレベルを設定〜
VSAN の特徴として、仮想マシン単位でポリシーを定義できます。
一般的なストレージの場合、事前にRAIDを作成、LUNを切っていき、その上にそのRAIDにあった仮想マシンを乗せていく流れですが、VSANの場合、VASAの仕組みを使って、vsanDatastoreをその仮想マシン単位にあった形態で使用することができるのです。

原文:The role of VASA
VSAN Cormac Blog 日本語版 Index

VSAN Cormac Blog 〜 VSAN におけるオブジェクトとコンポーネントの考え方〜

本blogは VMware Storage Business UnitのCormac Hogan Blog の翻訳になります。VSANをより深く知っていただき活用していただく為、本記事の翻訳がお役に立てば幸いです。

VSANにおけるオブジェクトとコンポーネントの概念

VSANを理解する大事なポイントとして、”オブジェクト”と”コンポーネント”の理解が大切になってきます。
VSANに展開された仮想マシンは、4種類のオブジェクト(コンポーネントの集合体)が展開されます。

  • 仮想マシン ホーム or ”ネームスペース ディレクトリ”
  • スワップオブジェクト( 仮想マシンがPower on状態 )
  • 仮想ディスク / VMDK
  • スナップショット時のDelta-Disks(差分ディスク) それぞれの差分ディスクはオブジェクト

仮想マシンホームについて補足します。全ての仮想マシンファイル ( 仮想マシンディスク、差分、スワップファイル以外 ) については、VSANの仮想マシンホームに格納されています。.vmxファイル、 .logファイル、 .vmdk & snapshot差分ディスクリプタ等、仮想マシンホーム(VM Home)にあります。

コンポーネントは何でしょうか?
仮想マシンを展開するとオブジェクトがVSAN上に展開されます。コンポーネントはそのオブジェクトの枝のようなイメージです。

図1

例えばある仮想ディスクをVSAN上にRAID-0  / 2ストライプで展開すると、2の物理的なディスクに仮想マシンが展開されます。仮想ディスク = VMDK はオブジェクトです。そのオブジェクトに紐付いているストライプがコンポーネントとなります。

クラスタ内で1台のホスト障害に耐久性を持たせようとする設定は、 VMDK ( = オブジェクト) に対してRAID1、コンポーネントを2つのホストに配置することを意味します。ポリシー設定については、こちらを参照ください。

スナップショット作成時には差分ディスクが作成されます。この差分ディスクのポリシーは親Diskのポリシーを引き継ぎます。スワップオブジェクトは仮想マシンがPower onの時のみ作成されます。

VSANにおけるコンポーネント数の制限です。

    • コンポーネント数、ホストあたり 9000 ( VSAN 6.xの上限 )

詳細はVMware Virtual SAN™ 6.2 Design and Sizing Guideもご覧ください。

ホストあたりのコンポーネント数は電源オフの仮想マシンも含まれます。 VSAN はクラスタ内で均等にコンポーネントを分散するようにしていますが、多少のばらつきもあり得ます。VSANクラスタを展開する際、同じスペック / 設定のホストを準備しましょう。VSANクラスタをデザイン展開する際、コンポーネント数は十分考慮しましょう。

vSphere Web Clientでこの仮想マシンのVMホームネームスペースやVMDKのオブジェクト、コンポーネントをみることができます。こちらはそのサンプルです。この仮想マシンは一つのハードディスクを持っておりミラーされております。(異なるホストに配置されてますね!)

11.-Physical-Disk-Placement

原文:Understanding Objects and Components

VSAN Cormac Blog 日本語版 Index

VMware Virtual SAN ( VSAN )関連 Blog 目次

VSAN入門

VSAN Cormac Blog 日本語版 (随時翻訳中!)

そのほか VSAN 関連blog

VMware Virtual SAN 入門 〜 信頼性・性能編 〜

こんにちは! VMwareの中村朝之です。
前回からすこし時間があいてしまいましたが、引き続き VMware Virtual SAN (以下VSAN) についてご紹介していきます。本題に入る前に少し前回の復習から…

VSANとは?…
-シンプルな構成、シンプルな運用
ストレージ機能もハイパーバイザーに同梱。ソフトウエアでストレージ管理もシンプル!
-汎用的なハードウエアで実現可能
ストレージ専用ハードウエアは不要。サーバ/HDD等、汎用的なハードウエアを選択!
-新しいアーキテクチャによるワクワク感
vSphere専用ストレージならびに新しいアーキテクチャということで、お客様に安心していただきながらご利用いただいております

それでは第2回の VSAN における信頼性、性能についてみていきましょう。
※VSANでは、ハイブリッドタイプとオールフラッシュタイプがありますが、本記事はハイプリッドタイプを対象としております。

信頼性はどのように実現?

まずVSANにおいて一番気になるのが、データ保護はどうやっているのか?です。VSAN におけるデータ保護は、仮想マシンが持っている VMDK が図1のように異なるホストに複製が配置されます。図1では異なるサーバに2重書きして冗長性を確保しています。

図1

図1:VSANにおけるデータ冗長性

この冗長性は「仮想マシンのストレージポリシー」の failures to tolerate = FTTというパラメータで設定できます。何台の物理ホスト障害に耐えられるようにするか、という設定で決めます。例えば2重化の場合、ホスト2台のうち1台に障害が発生しても、片方の VMDK にアクセスできますので仮想マシンは稼働し続けます。この冗長性を実現するポイントは、仮想マシン単位(もっと細かくいうと、VMDK単位)で定義するということです。VSANは大きな1つのデータストアを準備し、仮想マシン毎に冗長レベルをきめられます。事前に可用性やパフォーマンスを考慮したRAID設計はいりません。ちなみに3重、4重まで指定できます。

このストレージポリシーに関しては、次回VSANハンズオンラボのご紹介の際、どのような項目があるのか触れさせてもらいます。

ハードウェア障害時の挙動を知る!

データ保護はこの冗長性により実現できていますが、実際に障害が発生した場合はどのような動きになるのか表1で見ていきましょう。

表1にあるとおり、FTT= 1 以上であれば大部分のハードウエア障害時、仮想マシン上のサービス継続が可能となります。ホスト障害の場合、落ちてしまった仮想マシン上で動いている仮想マシンは一旦サービス停止が発生しますが、vSphere HAで保護されていれば、vSphere HAと同様の動きをします。

表1 :障害ポイントとサービスへの影響、復旧方法
(VSANノード 4台以上、ストレージポリシー FTT=1を想定)

障害箇所 仮想マシン影響 ユーザへの影響 復旧作業 VSAN内部のリカバリ処理(リカバリ開始のタイミング)
HDD 障害 継続稼動 影響なし ・HDD交換
・VSANへ追加
障害が発生したディスク上のデータのミラーコピー(即時)
SSD 障害 継続稼動 影響なし ・SSD交換
・VSANへ追加
同一ディスクグループ内の全ディスク上のデータコピー(即時)
ストレージ
コントローラー障害
継続稼動 影響なし ・コントローラ交換
・再設定
・VSANへ追加
コントローラ管理下の
全ディスクのデータコピー(即時)
ホスト障害 障害ホスト上の仮想マシン再起動 障害ホスト上で稼働している仮想マシンに数分ダウンタイム
(HAでの自動再起動)
・ホスト交換、
・ホスト初期設定
・VSANへ追加
ホスト内の全ディスク上の
データコピー(60分後*)
*開始までの時間は変更可能

 

VSAN はハイパーバイザに含まれている、いわば”vSphereストレージ”なので、vCenter Serverで管理が一元化されています。もちろん復旧操作もvCenter Serverでできてしまいます。また VSAN におけるデータ配置は基本的に個別のハードディスクに対して配置されます。

(設定や容量によって分散させることも可能)HDD障害時のリビルド時は、必要なDiskのみ負荷がかかります。(図2参照)復旧時の負荷は、必要最低限な負荷で短時間に復旧できます。

 

図2

図2: リビルド時も最低限の負荷で早急に復旧

ハードウエア障害時の動きについては、こちらの vExpertの大塚さま(ソフトバンク C&S)のBlogにて詳細に紹介されておりますので、こちらも参照してみてください。

VSANの性能について〜分散して処理を実行〜

最近のストレージのパフォーマンス向上として、キャッシュ機能としてフラッシュデバイスを有効活用する手法がトレンドです。VSANでもフラッシュデバイスをキャッシュとして性能向上をはかっています。まずは VSAN がどのようにRead/Writeをしているか見ていきましょう。

VSANにおけるキャッシュの考え方は図3がイメージしやすいです。図3の場合、VSANノード(ESXiサーバ)は4台で構成されてます。それぞれのノードに400GBのSSDを搭載しているとすると、1.6TBのキャッシュを持ったストレージとなります。

2-3-1

図3:SSDの総量がVSANのストレージキャッシュとして利用

キャッシュを追加したい場合、ESXi ( VSAN を構成するホスト)を追加したり、ノードにディスクグループを追加することによってキャッシュを増やすことが可能です。

ディスクグループ:
VSANのおけるSSD(キャッシュレイヤ)とHDD(キャパシティレイヤ)を1つのグループとした管理単位

もしキャッシュ量が足りなかったり、またはパフォーマンスを向上させたい場合、キャッシュ容量を柔軟に増やすことができます。追加もとてもシンプルで、vCenter Server実施します。先日 VSAN をお使いのユーザ様も実際ご自身で実施されていました。

VSANにおけるキャッシュ容量の指針としてはサイジングガイドをご参照ください。実データの10%がキャッシュ容量の目安です。

データの読み書きについて

さて実際のデータ読み書きの動きについてもみていきましょう。

書き(Write)
Writeについては 通常のストレージとあまり変わりはないので、イメージしやすいかと思います。FTT = 1であれば、異なる2つのノードから Ackが戻ってきたら書き込み終了です。(Ackを返すのはフラッシュデバイス) フラッシュデバイスから磁気HDDヘの書き込みは順次実施しています。

読み(Read)
Readについては、VSANの特徴がでます。図4を例にみていきましょう。ある仮想マシン( FTT =1)がデータを読み出す場合、1つのノードからReadではなく、分散してデータを読み出します。

2-4

図4: VSANは分散処理が特徴

分散して読み込み処理を行っているので、どこかのホストで読み込み集中したりしません。また仮想基盤の場合、想像してみてください….仮想マシンが頻繁に移動することが考えられますので、もし配置が変わったとしても読み込み処理が分散されているので安心です。

通常のストレージはコントローラが2個( =2重化 )あるのが一般的ですが、VSANの場合で考えると、コントローラがノード数だけあり処理を分散させ処理能力を向上させている、というイメージです。

まとめ

VSANの信頼性と性能についてご紹介しました。VSANの動きがイメージできると安心して使用することができますね!ちなみに 最新バージョン VSAN 6.2についてはこちらの記事を参照ください。それでは次回、オンラインラボで実際にVSANを触ってみましょう!

VMware VSAN 入門:
1/4 〜 従来のストレージと VSAN の違い 〜
2/4 〜 信頼性と性能編 〜(本記事)
3/4 〜 VSAN オンラインハンズオンラボをやってみよう 〜
4/4 〜 VSAN Ready Nodeとは〜

<著者紹介>
VMware シニアシステムズエンジニア(リーダー) 中村 朝之
2010年 VMware入社以後パートナーSEとしてプリセールスに従事。前職ではストレージ関連のサポート業務をしていたため、その経験を活かしながら現在はVSANやハイパーコンバージドインフラ(HCI)に注力しております。プライベートはトライアスロンでIronmanレースを目指して奮闘中。

VMwareテクニカルトレーナーよりワンポイントレッスン〜リソースプール活用術〜

みなさん、こんにちは!VMwareテクニカルトレーナーのSatokoです。

前回、ハイパーバイザが物理のCPUやメモリをどのように仮想マシンに割当しているのか、またオーバコミットとは?という話をさせていただき、大きな反響をいただきました。仮想基盤におけるCPUやメモリのリソース関連の話はとても奥が深いのですが、イメージするだけで理解が深まります。

CPUやメモリを効率よく使うのは、今までとは違った考え方で運用していく必要があります。ですが、すこしの知識を身につけることによって、限られた資源を有効活用することができます。本記事がその参考になればと思います。

vSphere におけるリソース管理の概念について段階を追ってみてみましょう。
前回までは仮想マシン単体での話がメインでしたが、今回からは仮想マシンをある単位で束ねて運用していく話をすすめていきます。そこで重要になるのが考え方がクラスタです。
クラスタについては、新入社員ブログも参照ください

クラスタ= ESXi を束ねて論理的に大きなサーバにみせることですね。

1-1

クラスタの機能を段階的に活用する例をみていきましょう。

ステップ1:クラスタの有効化
ステップ2:クラスタにおける仮想マシンの配置
ステップ3:クラスタ内で論理的にグルーピングする

ステップ1:クラスタの有効化

まず、ここで押さえておきたい用語はクラスタです。クラスタとは ESXi を束ねて大きな物理サーバとして使用していただく方法です。個々の物理サーバの管理から複数のESXiを束ねて仮想基盤を使用する手法です。

クラスタ化すると、仮想マシンはどの ESXi にのっているかインベントリー情報だとわからなくなってしまいます。これはクラスタという論理的なコンピュータ上で仮想マシンが動いていることを表しているので、どこのESXi で動いているかは、あまり気にしないで!という意味でもあります。

クラスタ化していない場合は、仮想マシンとESXi(物理的なサーバ)の紐付きがわかるように表示されています。

1-2_disableCluster

クラスタ化すると、この仮想マシンはこのクラスタ上で動いている!という考えにかえる必要がありますね。

1-3_enableCluster

このクラスタ化をすることによって使用できる代表的な機能としては、vSphere HA ( 以下HA )ですね。HA はクラスタリソースをみながら、仮想マシンを起動していきます。たとえば、クラスタの25%のCPUを余剰リソースとして確保しておく等、クラスタ全体を論理的なサーバとして、物理サーバの障害時にどうリソースを確保できるか考えます。

ステップ2:クラスタ内における仮想マシンの配置

HAの使用だけでは、クラスタ化して、ESXiを束ねてみたものの….個々の仮想マシンは物理サーバを意識して配置することになります。そこで次に出てくる課題としては、クラスタ内で、仮想マシンをどこに配置すればいいのか?ということです。

「仮想マシンは特に移行することを考慮していないので、決められた ESXi サーバに展開している」

という方、意外と多くいらっしゃるのではないでしょうか。

ただ、この手法ですと、せっかくクラスタ化したにもかかわらず、個々の ESXi に何台仮想マシンがのるか? を意識する必要があるので、物理環境とリソース管理という観点でもあまりかわりがなく、少しもったいない気がします。

HAだけだと….仮想マシンとESXiサーバの紐付きから解放されない

1-4DRS_off

仮想マシンはどこにでも動いて、クラスタ内のリソースを有効に活用する 、というのが仮想基盤の大きな特徴なので、個々の物理サーバとの紐付きからの束縛から解放されたいものです。

そのため、クラスタ内のCPUやメモリの負荷をみながら、仮想マシンを最適な物理サーバに自動的に配置してくれる機能があります。(DRS:vSphere Distributed Resource Scheduler)

クラスタ=大きなコンピュータとして扱われているので、その中でどこの物理的なCPU/メモリ資源を使うかどうかは、DRS任せになります。仮想マシンが最適に配置されるということは、CPUメモリ資源の使用の偏りをなくしクラスタ全体をまんべんなく使用できる環境に整えてくれます。

DRSを使っていると、ESXi は1コンピュータリソースとして存在するだけで、仮想マシンは最適な場所で動くのです。

1-5DRS_On

ちなみに弊社のお客様調査によると、このDRSを使っているお客様とそうでないお客様の統合率の差は約2倍ほどとなっているそうです。限られたサーバ資源を有効的に活用できる、といえそうですね。DRSの詳細はこちらも参照ください。

ステップ3 :クラスタ内で論理的にグルーピングする

クラスタ資源が足りなくなったら、物理サーバの追加となります。とはいいつつも….なかなかすぐに物理サーバを追加できない…という場面も考えられますね。ここで紹介したいのが「リソースプール」という機能です。

このリソースプール、クラスタ内で仮想マシン群をグルーピングすることができます。

1-6RP

例えば、本番系グループと開発系グループという2つのグループを作ったとします。ここでは、ESXi サーバ3台でクラスタを構築するとします。この3台で構成されたクラスタで、本番系グループと開発系グループの資源の調整がとれます。

季節的に本番系のリソースが枯渇した場合は、本番系にリソースが多く割り当てられるような設定をしたり、開発系リソースが必要な際は、優先的に開発にリソースが割り当てられる設定をすることができます。

1-7RP2

このリソースプールを使えるようになると、クラスタリソース自体を余計にふやすことなく、クラスタ内で資源の調節することも可能になります。このリソースプールはDRS機能が必須になりますので、方法2についてももちろん自動的に実施されています。

いかがでしたでしょうか。今回はクラスタの概念からはじまり、限りあるリソースを有効的に活用できる機能であるDRSやリソースプールをみてきました。イメージがつかめたところで、次回からは設定方法やリソースプール作成の際に知っておきたい話をしていきますね。お楽しみに!!

vSphereのリソースプール活用術
第1回:クラスタのおさらい (本記事)
第2回:リソースプールを活用しよう -設定編-
第3回:リソースプールを活用しよう -管理編-

VMwareテクニカルトレーナーよりワンポイントアドバイス 過去の記事
第1回:VMware vSphereにおけるCPU・メモリの考え方編
第2回:シェアと予約を押さえよう!

執筆協力
VMware Partner SE 中村朝之

VMware Workstation 12 PROを使って仮想マシンをvCloud Airに移行してみよう〜後編〜

ソフトバンクC&Sの幸田章です。前回はVMware Workstationを使ってvSphereと連携したり、vSphereの仮想マシンをWorkstationに移行する方法を紹介しました。今回はその仮想マシンをVMware vCloud Airへ移行してみます!!

vCloud Air VPC OnDemand環境との連携

 仮想マシンの移行の前にWorkstation 12 ProにvCloud Air VPC OnDemand環境を登録が必要です。連携の登録をすることで仮想マシンのコンソール操作や電源操作をWorkstation 12 Proの画面から実行することができます。

2-1

今回連携させるvCloud Air VPC OnDemandの環境は下記のようにオーストラリアリージョン(仮想マシン3台)と西日本リージョン(仮想マシン1台)を利用している環境です。

2-2

 それではWorkstation 12 ProにvCloud Air VPC OnDemand環境を登録します。「ホーム」画面から「VMware vCloud Airに接続」をクリックします。クリックすると「ユーザ名」「パスワード」を入力する画面がポップアップ表示されますのでvCloud Air VPC OnDemandにログインするユーザID・パスワードを入力し「接続」をクリックします。

2-3

正常に接続できればWorkstation 12 ProのライブラリにvCloud Air VPC OnDemand環境上の仮想マシンが表示されます。

2-4

これでvCloud Air VPC OnDemand環境の登録は完了です。Workstation 12 Proの画面からvCloud Air VPC OnDemand環境上の仮想マシンへ、コンソール接続や電源操作を実施することができます。但し、割当リソースの変更など、設定変更操作はWorkstation 12 Proの画面からはできませんので、vCloud Airのポータル画面から行う必要があります。

下記の画面キャプチャはvCloud Air VPC OnDemand上のWindows仮想マシンにコンソール接続し、その後に仮想マシンのパワーオフを行っているところです。

2-5

仮想マシンのハードウェアバージョン変更

 登録が完了したので、すぐにvCloud Air VPC OnDemandへ仮想マシンを移行したいところですが、その前にひとつ作業が必要です。vCloud Air上では仮想マシンのハードウェアバージョンが「vSphere5.5でサポートされているバージョン(4,7,8,9,10)」である必要があります。今回、前編でvSphere6から移行してきた仮想マシンのハードウェアバージョン11で作成した仮想マシンなので、このままだと移行ができません。(2015年10月現在の状況です)

2-6

Workstation 12 Proでは、仮想マシンのハードウェアバージョンの変更ができます。vSphereではハードウェアバージョンのアップグレードはできますが、ダウングレードはできません(ダウングレードする際はハードウェアの一部機能が削除・変更される場合があるので注意が必要です)。
次の手順で、仮想マシンのハードウェアバージョンを変更(ダウングレード)します。ライブラリの仮想マシン名を右クリックし「管理」-「ハードウェア互換性の変更」を順にクリックします。

2-7

 ハードウェアの互換性変更ウィザードが表示されますので、変更後のハードウェアバージョンを選択します。今回は「10.0」を選択し、「次へ」をクリックします。

2-8

 次に、変換前に仮想マシンのクローンを作成するかを選択します。今回は「この仮想マシンを変更」を選択し、選択した仮想マシン自体に変更を加えます。選択後「次へ」をクリックします。
※もし元の仮想マシンに変更を加えたくない場合は、「この仮想マシンの新しいクローンを作成」を選択することでハードウェアバージョンをダウングレードしたクローンの仮想マシンを作成することができます。

2-9

確認画面が表示されるので「完了」をクリックすると変換が開始されます。変換終了後「閉じる」をクリックします。

2-10

 終了後、仮想マシンの詳細を確認するとハードウェアバージョンがダウングレードされている事が分かります。これでダウングレード作業は完了です。

2-11

vCloud Airへ移行(V2C)

 それでは、いよいよ変換したWindows Server 2008R2の仮想マシンをvCloud Air VPC OnDemandへ移行(コピー)します。まず対象の仮想マシンをパワーオフします。次に対象の仮想マシンを右クリックし「管理」-「アップロード」の順にクリックします。

2-12

 仮想マシンアップロードウィザードが表示されるので「VMware vCloud Air」を選択し「次へ」をクリックします。

2-13

 次に、アップロード先での仮想マシン名を入力し、デプロイするリージョンとVDCを選択します。今回は「西日本リージョン(jp-jpanwest-1-10.vchs.vmware.com)」の「VDC1」を選択します。最後に「完了」をクリックするとアップロードが開始されます。

2-14

 アップロードの進行具合は、下記左側のキャプチャ画面のようにゲージで表示されます。また、右側のキャプチャ画面のようにvCloud Airポータル画面でも移行作業が行われている事が確認できます。

2-15

以上の手順でアップロード作業は完了です。移行完了後、vCloud Airポータルで移行した仮想マシンが確認できます。電源オンし、通常の仮想マシンとして利用することができます。

2-16

 下記キャプチャ画面は移行した仮想マシンに対しコンソール接続している画面です。vCloud AirポータルとWorkstation 12 Proのどちらの画面からも仮想マシンを操作することができます。

2-17

なお、アップロードした仮想マシンはどのネットワークにも接続されていないので、vCloud Airポータルから追加設定が必要ですのでご注意下さい。

2-18

※参考
Workstation 12 Proドキュメントセンター
Workstation 12 Proリリースノート

以上、前編・後編にわたりWorkstation 12 Pro を使ってvCloud Airへの移行をご紹介しました。Workstation 12 ProはvSphere、vCloud Air VPC OnDemandともに簡単に連携でき、仮想マシンの移行もクリック操作で簡単にできることがご確認頂けたかと思います。なおWorkstation 12 Proでは物理環境からのP2V2Cも簡単に実施することも可能です。
※Workstationを使ったP2V2Cの動画はこちらからダウンロードして閲覧可能です。
仮想化基盤をオンプレミス・PC・クラウドに拡張し益々ご活用頂ければと思います!

VMware Workstation 12 PROを使って仮想マシンをvCloud Airに移行してみよう
(前編) VMware Workstationを使ってみよう
(後編) vCloud Airへ仮想マシンを移行してみよう 本編

ソフトバンク C&S 幸田 章/市島 拓弥

VMware Workstation 12 PROを使って仮想マシンをvCloud Airに移行してみよう〜前編〜

ソフトバンク C&Sの幸田章さんより新しくでたVMware Workstationを使って、VMware vCloud Airへの移行について寄稿していただきました。それでは幸田さん、よろしくお願いいたします!

皆さんこんにちは!ソフトバンク C&Sの幸田です。
仮想マシンを簡単に移行できるのがVMware vCloud Airの大きな特徴ですが、このPC向け仮想化ソフトウエアVMware Workstation (以下Workstation)もvCloud Airと非常に相性のいいツールとなってきました。今回前編と後編にわけて、前編はまずWorkstationで少し遊んでみます。後編は実際にWorkstation上の仮想マシンをvCloud Airに移行する手順を紹介していきます。

VMware Workstation 12 PROを使って仮想マシンをvCloud Airに移行してみよう
(前編) VMware Workstationを使ってみよう 本編
(後編) vCloud Airへ仮想マシンを移行してみよう

PCにWorkstation 12 Pro のインストールしてみよう

ではまず、PCにWorkstation 12 Proをインストールします。Workstation 12 ProはVMwareからは評価版(30日間)が無料で公開されており、VMwareのサイトからダウンロードすることができます。後で正規ライセンスを購入した際もライセンス キーを更新するだけで正規版に変換でき、Workstation 12 Proを再インストールする必要がありませんので、試しにインストールして使ってみるのに評価版を利用するのも良いかと思います。
URL:https://www.vmware.com/jp/products/workstation/workstation-evaluation.html

今回はWindows用の評価版をダウンロードしてインストールします。

1-1

インストーラがダウンロードできたら、実行してインストールを行います。インストール先の選択などがありますが、特別設定変更する項目がなければ、ウィザードに従ってただクリックしていけば簡単にインストールできます。最後にライセンスキーの入力画面が表示されますが、後でも入力できますので「完了」でOKです。

1-2

※インストールウィザードの途中で選択する追加機能の「拡張仮想キーボード ドライバ」は、各国語対応のキーボードや特殊なキーを持つキーボードを適切に処理する為のドライバです。

1-3

1-4

これでWorkstation 12 Proのインストールは完了です。最初にWorkstation 12 Proを起動するとラインセンスキーの入力か評価版利用かを聞かれます。ライセンスキーをお持ちであれば入力し、評価版利用であればメールアドレスを入力することでWorkstation 12 Proの利用を開始することができます。

vSphere環境とも連携できてしまいます

次は、 Workstation 12 ProにオンプレミスのvSphere環境を登録します。ESXiやvCenter Serverを登録することができ、vSphere環境上の仮想マシンのコンソール操作や設定変更をWorkstation 12 Proの画面から実行することができます。
今回はvSphere 6 のvCenter Serverを登録し連携させます。

1-5

まず、Workstation 12 Proの起動した画面から「ファイル」-「サーバに接続」の順にクリックします。設定画面が表示されますので「サーバ名(vCenter ServerのFQDNもしくはIPアドレス)」「ユーザ名(管理者権限のあるユーザ)」「パスワード」をそれぞれ入力し「接続」をクリックします。正常に接続できればWorkstation 12 ProのライブラリにvSphere環境上の仮想マシンが表示されます。

1-6

※セキュリティ証明書の警告が表示された場合は「接続する」を選択します。

これでvSphere環境の登録は完了です。これでvSphere Web Clientで仮想マシンの操作をするように、Workstation 12 Proの画面からvSphere環境上の仮想マシンへのコンソール接続や電源操作、設定変更を実施することができます。下記の画面キャプチャは一例です。
(左側)電源操作:仮想マシンを右クリックし「パワー」を選択
(右側)仮想マシンの設定変更:仮想マシンをシャットダウンし、「仮想マシンの設定を編集する」を選択

1-7

vSphere環境の仮想マシンをWorkstationへもってこれます (V2V)

それではいよいよvSphere上の仮想マシンをWorkstation 12 Proへ移行(コピー)します。まず対象の仮想マシンをパワーオフします。今回はWindows Server 2008R2の仮想マシンを移行します。対象の仮想マシンを右クリックし「管理」-「ダウンロード」の順にクリックします。

1-8

ポップアップ画面で移行後の仮想マシン名を入力し、新しい仮想マシンを保存する場所を選択します。今回の仮想マシンの保存場所はデフォルトで選択されているパスのまま進みます。入力後「ダウンロード」をクリックすると仮想マシンの移行が開始されます。

1-9

暫く待つと仮想マシンの移行が完了し、ライブラリのマイコンピュータに移行した仮想マシンが表示されます。これで仮想マシンの移行(V2V)は完了です。電源ボタンをクリックしパワーオンすれば、Workstation 12 Pro上で移行した仮想マシン実行することができます。下部キャプチャ画面の右側が移行した仮想マシンをパワーオンしコンソール接続している画面です。

1-10

Workstation 12 Pro上で仮想マシンのネットワーク設定をしてみよう

これまでの手順で仮想マシンの移行を行いましたが、ネットワークについての設定は何も行っていません。Workstation 12 Pro上の仮想マシンを既存の物理ネットワークに参加させたり、インターネットにアクセスさせたりする為には設定変更が必要な場合がほとんどです。ネットワーク接続のタイプには一般的な構成として「NAT」「ブリッジ」「ホストオンリー(PC内部で完結するネットワーク)」の3種類があります。

1-11

今回は移行した仮想マシンを「NAT」で接続設定し、インターネットに接続します。
まず、「編集」-「仮想ネットワークエディタ」をクリックし、ポップアップされた仮想ネットワークエディタ画面から「設定の変更」をクリックします。ユーザアカウント制御が表示された場合は「続行」を選択します。

1-12

次に、NATの設定を行います。今回は前述したNAT構成イメージ図のネットワークアドレス構成で設定します。仮想ネットワークエディタ画面上部のタイプNATのインターフェースを選択します。VMnet情報が「NAT」に選択されている事を確認し、下部の「サブネット」と「サブネットマスク」を設定したい値で入力します。今回は「172.16.100.0 」「255.255.255.0」で設定します。次に「NAT設定」をクリックします。表示された画面でゲートウェイのアドレスを設定します。これはWorkstation 12 Pro上で動作している仮想マシンのデフォルトゲートアドレスになり、Workstation 12 Proが動作しているPCの仮想インターフェースに割り当てるIPアドレスです。今回は172.16.100.1で「OK」をクリックします。

1-13

今回仮想マシンはDHCPでIPアドレスを割り当てますので、「ローカルDHCPサービスを試用してIPアドレスをVMに配布する」にチェックを入れ「DHCP設定」をクリックします。DHCPで配布するアドレス範囲を「開始IPアドレス」と「終了IPアドレス」に入力し(今回は172.16.100.100~200)「OK」をクリックします。これで仮想ネットワーク設定(NAT構成)は完了ですので「OK」をクリックします。

1-14

次に仮想マシンの仮想NICをNAT構成の仮想ネットワークに接続します。対象の仮想マシン名を右クリックし、「設定」をクリックします。仮想マシンの設定画面が表示されますので「ネットワークアダプタ」を選択しネットワーク接続を「NAT」に変更します。変更後「OK」をクリックし完了です。

1-15

これでNAT接続構成の設定は完了です。仮想マシンにコンソール接続してインターネットにアクセスできるか確認してください。接続できない場合は仮想マシンが認識しているネットワーク設定やWorkstation 12 Proが動作している物理PCの仮想インターフェースを確認してみて下さい。仮想ネットワークエディタで設定したIPアドレスと、仮想マシンや物理PCが認識しているIPアドレスが異なっている場合は設定変更する必要があります。

1-16

これでvSphere上の仮想マシンをWorkstation 12ProへV2V し、インターネットにアクセスさせることができました。GUI操作で簡単に仮想マシンを移行できることをご確認頂けたかと思います。また、逆にWorkstation 12Pro上の仮想マシンをvSphere上で移行することも同じような手順で実行でき、仮想マシンを行ったり来たりさせることがWorkstation 12Proなら簡単にできます。
前編は以上です。次回はvCloud Air VPC OnDemand上へ移行する『V2C(Virtual to Cloud)』の手順をご紹介させて頂きます。

VMware Workstation 12 PROを使って仮想マシンをvCloud Airに移行してみよう
(前編) VMware Workstationを使ってみよう 本編
(後編) vCloud Airへ仮想マシンを移行してみよう

ソフトバンク C&S 幸田 章/市島 拓弥

vCloud Airを使った災害対策~活用編・後半~

ソフトバンクC&Sの幸田さまより、機能強化された VMware vCloud Air のDisaster Recoveryサービスについて寄稿していただきます。それでは幸田さま、よろしくお願いします!!


みなさまこんにちは、ソフトバンクC&Sの幸田です。いよいよこの連載も最終回です!
引き続き、機能強化されたVMware vCloud AirのDRサービス、通称「DR 2.0」の活用方法、今回はフェイルオーバーとフェイルバックの手順をみていきます。

(前半)フェイルオーバー試験/フェイルオーバー試験のクリーンアップ/フェイルオーバーの実行
(後半)フェイルバックの実行 本記事

フェイルバック

vCloud Air DR2.0上で起動していた仮想マシンを、オンプレミス環境へ再び移行します。DR2.0ではネイティブフェイルバックに対応し、オンプレミスのvSphere Web Clientからの操作で、簡単に仮想マシンをオンプレミス環境へ戻せるようになりました。

フェイルバックの流れとしては、3つの流れで実施します。
-オンプレミス環境の再構築
-vCloud Air–>オンプレミス環境へのレプリケーション確立
-切り戻し(フェイルバック)

オンプレミス環境の再構築

新たに構築したオンプレミス環境で、本連載第2回の後半でご紹介した「vCloud Air を退避先として登録」までの作業(vSphere Replicationのデプロイ、vCloud Air DR2.0環境との接続設定)を実施し、vCloud AirのDR環境を「ターゲットサイト」として登録します。

vCloud Air–>オンプレミス環境へのレプリケーション確立

vSphere Web Clientにログインし、「vSphere Replication」アイコンをクリックして「ホーム」タブから「監視」を選択します。

3-2-1

3-2-2

「受信レプリケーション」を選択し、「クラウドプロバイダからのレプリケーションを構成」と表示される下記アイコンをクリックします。

3-2-3

現在レプリケーション元となるvCloud Airの仮想データセンタを選択し、「次へ」をクリックします。

3-2-4

オンプレミスに戻したい仮想マシンを選択し、「次へ」をクリックします。

3-2-5

※新たに構築し直したオンプレミス環境へのフェイルバックの場合、下記の様なエラーが表示されます。これは、旧オンプレミス環境とDR2.0間でレプリケーションの設定が残っているためです。

3-2-6

このような場合は、いったんフェイルバックの操作を中断して、不要なレプリケーションを停止してください。

レプリケーション処理を行うvSphere Replicationサーバを選択し「次へ」をクリックします。今回はデフォルトのまま進みます。

3-2-8

レプリケーション処理で仮想マシンのデータが保存されるオンプレミス上のデータストアを選択します。「編集」をクリックします。

3-2-9

ポップアップ画面からデータストアの場所を選択して「OK」をクリックします。

3-2-10

「次へ」をクリックします。

3-2-11

レプリケーション時のオプションを選択する画面が表示されますが、受信レプリケーション時は選択できませんので、このまま「次へ」をクリックします。

3-2-12

確認画面が表示されますので内容に問題なければ「終了」をクリックします。

3-2-13

設定に問題がなければ、vCloud Airからオンプレミスへのレプリケーションが開始されます。進捗は下部のウインドウで確認できます。また、vCloud Airポータル画面でも逆転したレプリケーションが実行されていることを確認できます。

Web Client画面
3-2-14

vCloud Air画面
3-2-15

ステータスがOKになれば完了です。

切り戻し(フェイルバック)

vCloud Airからオンプレミスへのレプリケーション確立後、いよいよ切り戻しです。
vSphere Web Clientにログインし、「vSphere Replication」アイコンをクリックして「ホーム」タブから「監視」を選択します。

3-2-

3-2-18

リカバリしたい仮想マシンを選択し、リカバリ開始のボタンをクリックします。

3-2-19

ウィザードに従いリカバリを実行します。まず、リカバリポイントを選択します。今回は過去のインスタンスは保持していないので「最新の変更の同期」を選択し「次へ」をクリックします。

3-2-20

次にvCloud Air環境にログインする際の「ユーザ名」と「パスワード」を入力します。入力後、「次へ」をクリックします。

3-2-21

vCloud Air上の移行元仮想マシンのシャットダウンが必要となる為、シャットダウンの方法を選択します。今回の仮想マシンはVMware Toolsがインストールされているので「ゲストシャットダウン」を選択し、タイムアウトを「5分」のまま「次へ」をクリックします。

3-2-22

オンプレミス側で仮想マシンをデプロイするフォルダを指定し、「次へ」をクリックします。

3-2-23

仮想マシンで試用するリソース(クラスタ、またはホスト)を選択します。下部に「検証が成功しました」と表示されれば、「次へ」をクリックします。
※以前の構成ファイルがオンプレミス上に存在し、警告が表示される場合は「はい」上書きを選択します。

3-2-24

確認画面が表示されるので設定に問題なければ、「終了」をクリックします。オンプレミス環境でのフェイルバックが始まります。

3-2-26

リカバリが開始されると、vCloud Air DR2.0上の仮想マシンが自動的にシャットダウンされます。オンプレミス環境でのリカバリが完了するとステータスがリカバリ済みの表示になります。

3-2-27

完了後、vSphere Web Clientのインベントリリストからリカバリした仮想マシンが正常に起動している事を確認します。
(vNICの再接続等、ネットワークの再設定が必要になる場合があります)

以上がvCloud Airからの切り戻し手順になります。
災害対策は敷居が高い…と思われがちですが、意外と簡単に構築できてしまいます。
お得なキャンペーン情報もありますので、これらを活用しつつ♪是非、vCloud Airをお試しください!!

1回:vCloud Air DR 2.0 概要編
第2回:vCloud Air DR 2.0 構築編
・(前半) vSphere Replication のデプロイ
・(後半) vCloud Air を退避先として登録/・仮想マシンの保護設定
第3回:vCloud Air DR 2.0 活用編
・(前半) フェイルオーバー試験テスト/フェイルオーバー 
・(後半)フェイルバック 本記事