Home > Blogs > Japan Cloud Infrastructure Blog


新卒 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回 ( 追加編 ) まだまだあった!ストレージ関連機能

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

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

  2. ピンバック: 新卒 SE 社員が贈る vSphere のキソ!第4回~仮想マシンの配置管理はDRSにお任せ! ~ | Japan Cloud Infrastructure Blog - VMware Blogs

  3. ピンバック: 新卒 SE 社員が贈る vSphere のキソ!第3回~vMotionとvSphere HA/vSphere FTの違いとは?~ | Japan Cloud Infrastructure Blog - VMware Blogs

  4. ピンバック: 新卒 SE 社員が贈る vSphere のキソ!第2回 ~仮想環境におけるネットワークとストレージ~ | Japan Cloud Infrastructure Blog - VMware Blogs

  5. ピンバック: 新卒 SE 社員が贈る vSphere のキソ!第1回〜 vSphere を俯瞰する〜 | Japan Cloud Infrastructure Blog - VMware Blogs

  6. ピンバック: 新卒 SE 社員が贈る vSphere のキソ!第6回 ~vSphere でココまでできる!データ保護~ | Japan Cloud Infrastructure Blog - VMware Blogs

  7. ピンバック: 新卒 SE 社員が贈る vSphere のキソ! 第7回 ~ 仮想環境となが〜くお付き合いしていくために ~ | Japan Cloud Infrastructure Blog - VMware Blogs

コメントは停止中です。