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

作成者別アーカイブ: Yuji Ujita

VMware Virtual SAN 入門 〜 VSAN オンラインハンズオンラボをやってみよう 〜

みなさん、こんにちは!
VMware Virtual SAN 入門シリーズ第 3 弾となる本エントリでは、VMware のハンズオンラボを利用して Virtual SAN ( VSAN ) の構築に挑戦してみましょう。
~ ハンズオンラボとは ~

ハンズオンラボとは、Web ブラウザから VMware 製品の実機を操作できるサービスです ( 図 1 )。誰でも簡単かつ無償で VMware 製品を評価することができます。詳細については、過去のブログ 「日本語環境が増えました!VMware製品の無償評価環境 ハンズオンラボ」 をご覧ください。
今回対象となるラボは、 「HOL-SDC-1608 – Virtual SAN 6の新機能」 です。
HandsOnLabConsole

図 1 . ハンズオンラボ ( 右側の操作手順に従うことで、VMware 製品の操作を体感できる )

ハンズオンラボは実機を操作するうえで非常に便利ですが、操作マニュアルに従っているだけでは全体のイメージがわかないことも多いと思います。そこで、本エントリでは VSAN の構築から利用までの流れをイメージできるよう図を多用しつつ、各手順の位置づけを解説していきます。本ブログ記事には、該当するラボの手順を ( 手順 〇 ~ 〇 ) のように示していますので、ぜひ皆さんもこのブログを読みながら一緒に操作してみてください。
それでは、始めましょう !
~ VSAN ハンズオンラボ ~

VSAN のハンズオンラボ 「HOL-SDC-1608 – Virtual SAN 6の新機能」 では、 VSAN の設定から利用までを 3 ステップで簡単に体感できます ( 図 2 )。
構築ステップ

図 2 . VSAN 構築・利用の 3 ステップ
  – STEP 1 . VSAN 設定 ( 手順 20 ~ 41 )
VSAN を構成し、データストアとして利用できるようにします ( 図 3 ) 。

– STEP 2 . ストレージポリシー作成 ( 手順 51 ~ 78 )
VSAN 独自のストレージポリシー ( ストライピング数やミラー数の指定 ) を作成します。

– STEP 3 . ストレージポリシー適用 ( 手順 79 ~ 116 )
STEP 2 で作成したストレージポリシーを仮想マシンへ適用します。
vsanDatastore_DiskGroup_01

図 3 . VSAN データストアの完成イメージ

では、実際にラボを操作して具体的な手順について見ていきましょう。
§ STEP 1 . VSAN 設定 ( 手順 20 ~ 41 )

まずは、VSAN を構成するところからです。
VSAN の構成は非常に簡単であり、下記の 2 ステップで OK です。

① VSAN ネットワークをセットアップする ( 手順 23 ~ 34 )
② クラスタ上で VSAN を有効にする ( 手順 35 ~ 41 )
① VSAN ネットワークをセットアップする ( 手順 23 ~ 34 )

今回のハンズオンラボ環境では既に VSAN ネットワークを設定済みですが、 esx01-a ホストだけ VSAN ネットワークに未接続の状態になっています。そのため、手順 23 ~ 34 で esx01-a ホストを VSAN ネットワークに参加させます ( 図 4 の「VMKernel アダプタの追加」参照 )。
NW構成図_01

図 4 . VSAN ネットワーク ( VMKernel アダプタ ) の設定

VSAN ネットワークへのホスト追加には VMKernel アダプタを使用しますが、この際「仮想 SAN トラフィックの有効化」のチェックボックスを ON にします ( 手順 23 ~ 34 ) ( 図 5 )。
VSANの有効化

図 5 . 仮想 SAN トラフィックの有効化

これで VSAN ネットワークのセットアップが完了しました。
各ホストに仮想スイッチの設定を施すのは大変だと思われた方もいらっしゃると思いますが、じつは VSAN を購入すると分散仮想スイッチ ( vDS ) の使用権が自動で付与 されます。このため、 vSphere のエディションに関わりなく、 vDS を利用して簡単にネットワーク設定ができます。
② クラスタ上で VSAN を有効にする ( 手順 35 ~ 41 )

VSAN ネットワークが構成できたら、あとは ESXi クラスタの設定から VSAN を有効化するだけです ( 図 6 ) 。VSAN を有効化する際には、ディスクグループの作成を「手動」と「自動」のどちらで行うかを指定します。「手動」を選択した場合は、ディスクグループとなる SSD ( キャッシュ領域 ) と HDD ( キャパシティ領域 ) の組み合わせを任意に変更できるようになります。
VSANクラスタON

図 6 . クラスタ上で VSAN を有効にする

今回の VSAN のハンズオンラボ環境では、ホスト esx-01a ~ esx-03a に、それぞれ SSD が 2 つ、HDD が 4 つ内蔵されているため、各ホストに Disk Group が 2 つずつ構成されます ( 図 7 )。
vsanDatastore_DiskGroup_01

図 7 . Disk Group と VSAN データストア

VSAN の設定は以上です。非常に簡単ですね。
§ STEP 2 . ストレージポリシーの作成 ( 手順 51 ~ 78 )

VSAN の設定が完了したので、次はストレージポリシーを作成していきます。
ストレージポリシーを定義する方法には 2 種類あります。「タグに基づくルール」「データサービスに基づくルール」 です ( 図 8 )。
ストレージポリシー_ルール_02

図 8 . ストレージポリシーのルールセット
「データサービスに基づくルール」 と 「タグに基づくルール」

・ タグに基づくルール ( ポリシー作成手順 51 ~ 68 )
タグに基づくルールでは、データストアに紐付けた vSphere タグ ( ② ) をストレージポリシーで指定します ( ④ )。仮想マシンにこのストレージポリシーを適用すると、仮想マシンはタグが割り当てられているストレージに自動的に展開されます ( ⑤ )。

・ データサービスに基づくルール ( ポリシー作成手順 69 ~ 78 ) ( VSAN、VVol など )
データサービスに基づくルールでは、VASA Provider がストレージ機能を vCenter Server に通知するため ( ① ) 、ストレージポリシーの作成にあたり、 vSphere タグを利用する必要はありません ( ② )。仮想マシンにこのストレージポリシーを適用すると、仮想マシンはポリシー内で定義されたサービスに基づいて展開されます ( ③ )。定義できるストレージサービスは、ストレージの種類によって異なります。VSAN 6.0 の場合、下記のサービス定義が可能になっています ( 図 9 )。

VSAN 6.0 で定義可能なストレージサービス ( ストレージポリシー )
– 許容する障害の数
– オブジェクトあたりのディスクストライプの数
– フラッシュ読み取りキャッシュの予約 ( % )
– 強制プロビジョニング
– オブジェクトスペースの予約 ( % )
NewVSANPolicy

図 9 . VSAN ストレージポリシーの作成

「タグに基づくルール」では、事前にストレージ側 ( LUN ) でサービスレベルを設定しておく必要がありますが、「データサービスに基づくルール」では、データストアを構成した後からストレージポリシーでサービスレベルの設定が可能です。後者の方が、柔軟かつ多彩なストレージポリシーを定義できることがお分かりいただけると思います。
§ STEP 3 . ストレージポリシーを仮想マシンへ適用 ( 手順 79 ~ 116 )

VSAN ストレージポリシーが作成できたら、後はこれを仮想マシンに適用するだけです。ストレージポリシーを仮想マシンに適用するタイミングには、仮想マシンのデータストア移行時 ( 手順 81 ~ 88 ) と仮想マシンの新規作成時 ( 手順 109 ~ 116 ) の 2 つがあります。
また、ストレージポリシーを変更する際は、そのポリシーで展開済みの仮想マシンに直ちに変更を適用するかどうかを設定可能になっています ( 手順 134 ~ 145 )。

ストレージポリシーの適用ができたら、実際に仮想マシンのディスクが VSAN の各 Disk Group にどのように配置されているかを確認してみましょう。確認は仮想マシンの監視画面から可能です ( 手順 116 、141 ) ( 図 10 )。

例えば、今回のハンズオンラボの 手順 141 時点で適用されている VSAN のストレージポリシーは、下記のとおりです。
– 許容する障害の数 : 1
– オブジェクトあたりのディスク ストライプの数 : 3
したがって、図 10 に示したように「許容する障害の数 : 1 」によって仮想マシン ( Windows2008 ) のディスクのオブジェクトが 2 つにミラーリング ( RAID 1 ) され、「オブジェクトあたりのディスク ストライプの数 : 3 」によってそれぞれが 3 つのコンポーネントにストライピング ( RAID 0 ) されていることが確認できます。
VSANPolicy適用確認

図 10 . VSAN ストレージポリシーの適用確認

本ブログの VSAN ハンズオンラボ解説はここまでとさせていただきますが、同ラボでは VSAN クラスタの拡張や障害時対応など、他にも様々な操作を試すことができます。
これ以降のラボ手順についても、ぜひお時間があるときに実施してみてください。本ブログでお伝えした基本をご理解いただければ、楽しみながら進めていただけると思います。
~ おわりに ~

今回のブログエントリは、ハンズオンラボの解説という初の試みでしたが、お楽しみいただけたでしょうか?
本ブログで一番にお伝えしたかったことは、やはり 「VSAN は非常に簡単 & 便利」 ということになりますが、今回利用したハンズオンラボにも興味を持っていただければ幸いです。
VMware VSAN 入門:
1/4 〜 従来のストレージと VSAN の違い 〜
2/4 〜 信頼性と性能編 〜
3/4 〜 VSAN オンラインハンズオンラボをやってみよう 〜(本記事)
4/4 〜 VSAN Ready Nodeとは〜

VMware SE 氏田裕次

新卒 SE 社員が贈る vSphere のキソ!第8回 ( 追加編 ) 〜 まだまだあった!ストレージ関連機能 〜

みなさん、こんにちは! VMware SE の氏田 ( Ujita ) と申します。
本エントリでは、前回ご好評頂いた新卒ブログの追加編として、VMware vSphere のストレージ関連機能である vFRC 、Multipathing 、VAAI をご紹介します!

 

~ はじめに ~

私は以前、新卒ブログシリーズにて vSphere のキソ!第5回 を担当させていただきましたが、その中でストレージに関する機能として、 SIOC と Storage DRS を挙げさせていただきました。これらはいずれも vSphere 単体による工夫でしたが、ストレージのパフォーマンスを向上させる機能の中には、ESXi サーバ内の SSD や外部のストレージの機能と連携できるものがあります。それが、今回ご紹介する vFRC ( vSphere Flash Read Cache ) 、Multipathing 、VAAI ( vStorage API for Array Integration ) といった機能になります。

 

§ 1 . vFRC ( vSphere Flash Read Cache )

まずは、vFRC からご紹介していきます。vFRC とは、ESXi サーバ内の SSD を仮想マシンの読み取りキャッシュとして利用する機能です。SSD を内蔵している ESXi サーバ上に読み取りパフォーマンスを向上させたい仮想マシンがある場合、仮想マシン単位 ( 正確には、vmdk 単位 ) でキャッシュ領域を割り当て可能です ( 図 1 ) 。

 

vFRC
図 1 . vFRC

 

ESXi サーバには、図 2 のように、SSD を仮想フラッシュリソースとして追加できます。

 

仮想フラッシュリソース管理
図 2 . ESXi サーバにフラッシュリソースを追加
( ※ フラッシュリソースの用途としては、今回ご紹介する読み取りキャッシュの他に、ESXi ホストのメモリスワップ領域として利用する方法もあります )

 

仮想マシンのキャッシュ領域は、このフラッシュリソースから切り出されて提供されます。仮想マシンへのキャッシュ領域の割り当ては、サーバにフラッシュリソースを追加後、インベントリから仮想マシン名を右クリック -> [設定の編集] から簡単に行うことが出来ます( 図 3 )。仮想マシンに特別な変更を加える必要はありません。

 

仮想マシンへ読み取りキャッシュ領域を追加
図 3 . 仮想マシンへのキャッシュ領域の割り当て

 

前回ご紹介した SIOC は、特定のストレージへ I/O が集中した場合、優先的に I/O を通す仮想マシンを設定できる機能でした。これに対し、vFRC では、仮想マシンのストレージパフォーマンス自体を向上させる事が可能です。特に、読み取りが多く、遅延に敏感なアプリケーションを実行している仮想マシンに有効です。キャッシュ内にデータがある場合、ストレージへアクセスする必要は無いので、ストレージの負荷を減らすことができるというのも大きな利点となります。

 

§ 2 . Multipathing

次に、Multipathing についてご紹介します。図 4 に示したように、ESXi サーバ – ストレージ間のパスは複数存在します ( 実際には、ESXi サーバが複数あるためもっと複雑 ) 。Multipathing は、このパスを効率よく利用するための機能であり、仮想マシンが共有ストレージにアクセスする際、どこを通ればパスの負荷を分散できるかを常に考えてくれます。

 

Multipathing
図 4 . サーバ – ストレージ間のパス

 

ご存じの通り、仮想環境では一台のサーバ上でたくさんの仮想マシンが稼働するため、物理環境と比べサーバ – ストレージ間のパスが大変混み合います。従って、サーバ – ストレージ間のパスの負荷を分散させることは非常に重要です。ESXi サーバがどのようにパスを選択するかの基準を、パス選択ポリシー ( PSP : Path Selection Policy ) といいますが、vSphere のデフォルトの機能だと、パス選択ポリシーには、最近の使用ラウンドロビン固定の3つしかありません ( 図 5 ) 。

 

vSphere_PSP
図 5 . パス選択ポリシー

 

vSphere では、ストレージの種類を見て、最適なパス選択ポリシーを自動で設定してくれますが、これら 3 つのポリシーはどれも機械的なものであり、パスの負荷が適切に分散されるわけではありません。特定のパスに負荷が偏ると、レイテンシが発生し、アプリケーションの安定稼働に影響を与える可能性があります。

これに対し、Multipathing は、ストレージベンダが提供する専用のマルチパスの仕組みを利用します。これにより、インテリジェントかつ動的なパスの選択が可能になるため、パスの負荷が平滑化されます。以前、私が書いたブログで NIC の負荷分散機能である LBT ( Load Based Teaming ) をご紹介しましたが、適切なパスを選択して負荷を分散するという考え方は同じです。

Multipathing を利用することで、パスの帯域を最大限有効に使うことができるので、I/O 要求が混み合っている場合でも安定したストレージパフォーマンスを期待できます。

 

§ 3 . VAAI ( vStorage API for Array Integration )

最後に、VAAI についてご紹介します ( ※ VAAI を利用するには、vSphere の Enterprise 以上のエディション、ストレージのファームウェア対応が必要となります )。VAAI を有効にすることで、ストレージが持つ機能と vSphere が連携し、仮想環境におけるストレージパフォーマンスを向上させることができます。

例えば、仮想環境のストレージには、以下の課題があります。

    ( 1 ) 大量の仮想マシンからのアクセス
    ( 2 ) 仮想マシンファイル ( 大容量 ) のコピー、移動が頻発
    ( 3 ) ストレージへの 0 書きが頻発

VAAI は、これら仮想環境特有のストレージ処理を効率よくこなすための仕組みを提供します。以下、それぞれの課題を VAAI がどのように解決するかについてご説明します。

 

( 1 ) 大量の仮想マシンからのアクセス

今までは、たくさんの仮想マシンが同一のストレージを利用することによって I/O が混雑するというお話をしていましたが、実はもう一つ大きな課題があります。それが、ストレージの排他制御です。排他制御はデータの整合性を保つために必要ですが、これはファイルシステムのメタデータを更新する場合にのみ実行されます。しかし、仮想環境では多くの仮想マシンからアクセスが発生するため、排他制御により生じる待ち時間は馬鹿になりません。そのうえ、vSphere の標準機能の場合、排他制御は LUN 全体をロックすることにより行われるため、同じ LUN を利用している仮想マシン全てが待たされる状態でした ( 詳しくは、過去のブログ 押さえておきたいvSphereの基本~ストレージ編 第2回~ をご覧ください ) 。

これに対し、VAAI が有効なストレージでは、LUN 全体ではなく、より細かい単位でストレージをロックします。従って、排他制御の影響を受ける仮想マシンを大幅に減らすことが可能になります。これを実現している VAAI の機能を ATS ( Atomic Test & Set ) と呼びます。

 

( 2 ) 仮想マシンファイル ( 大容量 ) のコピー、移動が頻発

仮想環境には、仮想マシンがファイルであることを生かした便利な機能がたくさんありました。前回のブログでご紹介した Storage vMotion もその一つです。こういった便利な機能を利用するには、大容量の仮想マシンファイルをコピーしたり、移動したりする必要があります。VAAI が有効でない場合、この処理は ESXi サーバの CPU が行います。つまり、 ESXi サーバが対象となるデータをストレージから読み込み ( read ) 、再びストレージへ送って書き込む ( write ) という処理を行う必要がありました。このため、本来仮想マシンによって利用されるべき ESXi サーバの CPU リソースが奪われるうえ、サーバ – ストレージ間の帯域も一時的に逼迫してしまいます。

これに対し、VAAI が有効なストレージでは、ファイルコピーや移動の処理をストレージ単体で行うことが可能になります。ESXi サーバは、ただ一度命令を出すだけで済むので、CPU リソースが奪われることがありません。また、実際のデータは、ストレージ内でのみ流れることになるため、サーバ – ストレージ間の帯域も消費されません。これを実現している VAAI の機能を Full Copy と呼びます。

 

( 3 ) ストレージへの 0 書きが頻発

これまでお伝えしてきたように、仮想環境では、一つのストレージを複数の仮想マシンが利用します。従って、ある仮想マシンが書き込んだ領域を別の仮想マシンが使うということが頻繁に起こります。しかし、ある仮想マシンが過去に書き込んだ情報に別の仮想マシンからアクセスできるというのはセキュリティ上良くありません。そのため、仮想マシンがストレージ上のとある領域に初めてアクセスする場合、まずは 0 書きされるという仕組みになっています。仮想マシンを新たに作成する際にも大量の 0 書きが行われます。VAAI が有効でない場合、この 0 を書く処理は、ESXi サーバの CPU が行います。当然、( 2 ) と同じように、ESXi サーバの CPU リソースやサーバ – ストレージ間の帯域に影響を与えてしまいます。

もうおわかりかと思いますが、VAAI が有効なストレージでは、この処理をストレージ側にオフロードすることが出来ます。従って、ESXi サーバの CPU リソースに影響を与えませんし、サーバ – ストレージ間の帯域にも影響しません。これを実現している VAAI の機能を Block Zeroing と呼びます。

 

図 6 に、VAAI 機能のイメージ図を示します。

 

VAAI
図 6 . VAAI

 

~ おわりに ~

今回は、新卒ブログシリーズのおまけとして、vFRC 、Multipathing 、VAAI をご紹介させていただきました。前回ご紹介した SIOC や Storage DRS も考えると、vSphere にはストレージ関連機能がたくさんあると言うことがおわかりいただけたと思います。機能が多すぎて複雑に見えてしまうかも知れませんが、裏を返せば、それだけストレージが重要視されているということでもあります。皆様には、本シリーズでご紹介したストレージ関連の機能を生かし、仮想化の恩恵を最大限受けられる環境を構築していただけたらと思います。ありがとうございました。

VMware SE 氏田裕次

 

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

新卒 SE 社員が贈る vSphere のキソ!第5回~様々な仮想マシンが混在&混雑しても大丈夫!?ネットワーク と ストレージの帯域を維持する仕組み~

みなさん、こんにちは! VMware 新卒 SE の氏田 ( Ujita ) と申します。
第 5 回となる今回の新卒ブログでは、 ” 様々な仮想マシンが混在し、かつネットワークやストレージ I/O が混雑している時であっても、各仮想マシンのサービスレベルを維持できる” ということについてお話しします!
仮想環境におけるネットワークとストレージについてよく知らないという方は、椨木君による第 2 回のブログをご覧ください。

 

~ はじめに ~

仮想環境を最大限に生かすには、サーバリソースをプール化し、システムごとに切り分けるというアプローチが大切です ( 図 1 ) 。サーバリソースをプール化することによって、特定の ESXi サーバの負荷を他のサーバで補うことが可能になるため、サーバ統合率を向上させることができます。また、管理者の方にとっては、どのサーバ上でどの VM が動いているかを気にする必要がなくなります ( 詳しくは、前回のブログ ( DRS ) をご覧ください ) 。

fig_01_new

図 1 . システムごとにリソースを切り分ける

 

しかし、このような環境では一つの ESXi サーバ上に様々なシステムの VM が混在することになるため、各 VM のサービスレベルを維持できるのかという不安を持たれる管理者の方も少なくないと思います。この不安はもっともなことであるといえます。実際に、 DRS を適用した場合、 CPU やメモリなどのサーバリソースは最適化できますが、ネットワークやストレージの利用帯域については考慮されていません。 管理者の方からすれば、VM がどこに移動しても安心なように、 CPU 、メモリの他に、ネットワークやストレージの利用帯域を含めたサービスレベルを担保したいのではないでしょうか。

そこで、今回のブログでは、このような問題を一気に解決できる ネットワーク IO コントロール ストレージ IO コントロール という機能についてご紹介します!これらの機能を有効にすることで、同一の ESXi サーバ上に様々な VM が混在している場合であっても、各 VM のサービスレベルを簡単に維持することができます!
また今回は、 ネットワークやストレージの帯域を効率よく利用するための機能である LBT ( Load Based Teaming )Storage DRS といった機能についても併せてご紹介します!

 

§ 1 . ネットワーク編 ~混在&混雑時でも仮想マシンのトラフィックを維持する仕組み~

まずは、ネットワークリソースを各 VM に適切に分配する仕組みである ネットワーク I/O コントロール から見ていきましょう。

 

§ 1 . 1 ネットワーク IO コントロール ( NIOC ) とは?

ネットワーク IO コントロール ( 以下 NIOC ) とは、物理 NIC のトラフィックが輻輳している時に、優先的に送出するトラフィックの種類を設定できる機能です。

最初に、 VMware vSphere におけるトラフィックの種類についてご説明します。
vSphere 環境では、ネットワーク帯域もリソースのひとつとして捉え、各種トラフィックリソースが ESXi サーバの帯域をみんなで仲良く使います。ネットワークのトラフィックリソースは、 FT トラフィックや vMotion トラフィックなど、事前に定義されたものがいくつかありますが、ユーザ側で特定のポートやポートグループをひとつのネットワークリソースとして定義することも可能です ( 図 2 ) 。

NIOC_01_new

図 2 . ネットワークリソースの定義

 

NIOC では、定義されたネットワークリソースにサービスレベルの設定をすることで、優先して帯域を利用できるトラフィックや仮想マシンを指定することができます。

具体的には、各ネットワークリソースにシェア値というものを設定し、ネットワークに輻輳が起きた場合、このシェア値の割合に基づいて、 ESXi サーバの帯域を割り当てるという仕組みです ( 図 3 ) 。

NIOC_02

図 3 . ネットワークリソースのシェア値を設定

 

では実際に、輻輳が起きた場合、開発用 VM トラフィックにどの程度の帯域幅が割り当てられるか計算してみます。
図 3 をベースとした場合、開発用 VM のシェア値の割合は、全体値 ( 20 + 5 + 10 + 10 ) 分の 20 、すなわち、 20 ÷  ( 20 + 5 + 10 + 10 ) = 0.444 となります。 NIC 一枚あたり、 10 Gbps となりますので、 10 Gbps × 0.444 = 4.44 Gbps の帯域が割り当てられることになります。この例では、 ESXi サーバには NIC が 2 枚搭載されているので、開発用 VM のネットワーク用に担保されている帯域は、合計で 8.88 Gbps ということになります。

このように、 NIOC を利用することで、ネットワークのサービスレベルが異なる仮想マシンが混在していても、それぞれの仮想マシンのサービスレベルを制御することができます。言い換えれば、大事な仮想マシンのトラフィック ( シェア値 : 大 ) が重要でない仮想マシンのトラフィック ( シェア値 : 小 ) に影響されないように設定できると言うことです。

( ※ シェア値はネットワークに輻輳が起きたときのみ発動されるものなので、輻輳が起きていない状態であれば、どのような仮想マシンであっても上限なく、自由にネットワーク帯域を利用することが可能です! )

 

§ 1 . 2 LBT ( Load Based Teaming : 物理 NIC に基づいた負荷分散 ) とは?

次に、 ESXi サーバ上の物理 NIC を最大限活用する機能である LBT ( Load Based Teaming ) についてご説明します。

同一 ESXi サーバ上で稼働する仮想マシンは、限られた物理 NIC をみんなで仲良く使わなければならないので、全ての物理 NIC を可能な限り有効に活用することが重要になってきます。

vSphere には、どの仮想マシンがどの物理 NIC を利用するかを紐付ける方式がいくつかありますが、デフォルトの設定では、仮想マシンがつながっているポートと物理 NIC が 1 対 1 で結びつきます ( ポート ID ベース ) 。しかし、これでは、ある仮想マシンが多くのネットワーク帯域を利用しようとした場合、同じ物理 NIC に紐付いている仮想マシンが影響を受けてしまう可能性があります。

また、仮想マシンが利用する物理 NIC が通信相手の IP によって変わる方式 ( ターゲット IP ハッシュベース ) もありますが、この方式でも、ある仮想マシンが同一の宛先に大量のデータを送信する場合、同じ物理 NIC を利用している仮想マシンへの影響を無視できません。

前置きが長くなりましたが、 vDS という仮想スイッチ ( 後述 ) を利用している場合に限り、仮想マシンと物理 NIC に特別な紐付けを行うことができます。これこそ、今回ご紹介する LBT です! LBT では、物理 NIC の負荷に基づいて、各仮想マシンがどの物理 NIC を利用するか決定します。具体的には、30 秒ごとに物理 NIC の使用率をチェックし、とある物理 NIC の使用率が 75 % 以上であった場合、負荷が均等になるように仮想マシンと物理 NIC の紐付けを更新します ( 図 4 ) 。

LBT_01_new

図 4 . LBT ( 物理 NIC に基づいた負荷分散 )

 

LBT を利用していれば、特定の仮想マシンのトラフィックが幅を利かせていても、他の仮想マシンのトラフィックが逃げ場を失うことはありません。

 

§ 1 . 3 分散仮想スイッチ ( vDS : vSphere Distributed Switch )

最後に、NIOC や LBT を利用するために必須となる分散仮想スイッチ ( vDS ) について簡単にご説明します。

標準仮想スイッチ ( vSS ) だけだと設定は大変!?
前回までのブログでは、仮想マシンを ESXi サーバ間で移行することにより様々なメリット ( DRS 、 HA など ) が得られることをご紹介してきましたが、実は、仮想マシンを他のサーバ上に移動させる際には、あらかじめ両サーバに同一の仮想スイッチを設定しておく必要があります。 ESXi サーバが 2 台や 3 台ならまだマシですが、それ以上になってくると、全てのサーバに全く同じ仮想スイッチを設定するのは大変面倒です。これでは、設定ミスのリスクも増大してしまいます。

しかし、分散仮想スイッチを利用すると、複数の ESXi サーバに同じ仮想スイッチを一気に展開することが可能になります ( 図 5 ) ( もちろん設定の変更も一発でOK! ) 。 この分散仮想スイッチは、論理的には、 ”複数の ESXi サーバにまたがった 1 つの仮想スイッチ” と捉えることができます ( 図 6 ) 。

vDS_01

図 5 . 分散仮想スイッチ ( 複数の ESXi サーバに同じ仮想スイッチを一気に展開 )

 

vDS_02

図 6 . 分散仮想スイッチ ( 論理的には一つの仮想スイッチとなる )

 

分散仮想スイッチを利用することで、複数の ESXi サーバへのネットワーク設定が楽になるほか、様々な機能が利用できるようになります( 今回ご紹介した、NIOC や LBT はほんの一部です )。

分散仮想スイッチについて詳しく知りたいという方は、「押さえておきたいvSphere の基本~ネットワーク編 第2回~」をご覧ください。

 

§ 2 . ストレージ編 ~混在&混雑時でも仮想マシンのストレージ I/O を維持する仕組み~

それでは次に、仮想マシンがストレージを快適に利用するための仕組みについてご説明します。

 

§ 2 . 1 ストレージ I/O コントロール ( SIOC ) とは?

ストレージ IO コントロール ( 以下 SIOC ) とは、特定のストレージへの I/O が集中し、レイテンシが大きくなった場合、優先的に I/O を行う仮想マシンを設定できる機能です。先ほど出てきた NIOC のストレージ版と言っても過言ではありません。ストレージ I/O を ” シェア値に基づいて各仮想マシンに割り当てる ” という考え方も同じです。

ただ、ネットワークと異なり、ストレージには複数の ESXi サーバからアクセスがあるため、SIOC ではストレージを利用しているサーバ間でシェア値を共有する必要があります。図 7 をご覧ください。

SIOC_01_new_

図 7 . SIOC ( ストレージ IO コントロール )

 

実は、 図 7 ( a ) のように、SIOC を使わなくても、単体の ESXi サーバの中だけであれば I/O を優先する仮想マシンを指定することは可能です。しかし、この仕組みは他の ESXi サーバにからのストレージ I/O を意識していないので、他の ESXi サーバに存在する優先度の低い仮想マシンにストレージ帯域を奪われてしまう可能性があります。ストレージ側から見れば、管理者が意図しない I/O 割合になるのは明らかです。

そこで、 SIOC では、特定のストレージを利用している仮想マシンのシェア値を ESXi サーバ間で共有してから各 VM のシェア値割合を計算します ( 図 7 ( b ) )。こうすることで、重要な仮想マシンの I/O が、重要でない仮想マシンに影響されないようにサービスレベルを担保することができます。

ただし、 SIOC を利用して仮想マシンのストレージサービスレベルが維持できていたとしても、特定のストレージの高負荷状況が長く続くのも良くありません。
実は、この場合には、次に説明するStorage DRS が有効に働きます!

 

§ 2 . 2 Storage DRS とは?

仮想マシンの実体は、共有ストレージ上のファイルであるというお話が第 2 回のブログでありました。仮想マシンの台数が増えてくると、当然ストレージへの I/O 要求が増加するため、ストレージ間での I/O 負荷の分散が重要になります。そのため、インフラ管理者の方は、仮想マシンを展開する際、各データストアの空き容量や、予想される I/O 量などを確認し、適切な配置先を選択する必要がありました。

しかし、 Storage DRS を利用すると、この煩わしい仮想マシンの初期配置を自動で行ってくれます。更に、特定のデータストアへの I/O 負荷が慢性的に高くなっている場合には、そのデータストア上に配置されている仮想マシンを他のストレージへ自動的に移すことで I/O 負荷を分散してくれます ( 図 8 ) 。仮想マシンのデータストアを移行する際には、 Storage vMotion が使われるので、仮想マシンが停止する心配はありません。

仮想マシンのデータストア初期配置やストレージ I/O 負荷分散は、管理者が データストアクラスタ として定義したプール化されているストレージに対して行われます ( 実際には、データストアクラスタに対して Storage DRS を有効にするという形になります ) 。

StorageDRS_01_new

図 8 . Storage DRS によるストレージ I/O 負荷分散

 

ESXi サーバをクラスタ化した場合、 DRS という便利な機能が利用できましたが、データストアも同様にクラスタ化することで、 Storage DRS という便利な機能が利用できるようになるのですね。
 

~ おわりに ~

仮想環境では、複数の ESXi サーバやストレージをクラスタ化して、一つの大きなリソースとして扱うことが多いです。そのため、一つのサーバやストレージに様々なシステムの仮想マシンが混在するという状態は避けられません。今回は、このような環境で重要となる、各物理リソースを効率よく利用する仕組み ( LBT 、Storage DRS ) や仮想マシンへの適切なリソース割り当て ( NIOC 、SIOC ) についてご説明させていただきました。
みなさんには、今回のブログを通して、様々なシステムが混在する環境でも各仮想マシンのサービスレベルを担保できるということをご理解いただき、これまでよりも大胆にリソースをプール化していただけたらと思います。次回もお楽しみに!

VMware SE 氏田裕次

 

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