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

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

VSAN Cormac Blog ~ オブジェクトの IOPS 制限 ~

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

vsanpart4_1

VSAN 6.2 では、 ” オブジェクトのIOPS制限 ” という新しい QoS の仕組みが採用されています。ポリシーの設定を通して、管理者はオブジェクト ( 一般的には VMDK ) の IOPS 制限を設定でき、オブジェクトは設定した IOPS の制限を超えることはできません。もし、分配されたリソース以上消費している可能性がある仮想マシンがある場合、この機能は非常に便利です。このポリシーの設定は、その他の仮想マシンまたは VSAN データストアの全体的なパフォーマンスに影響を及ぼすことのないよう、仮想マシン上に ” ガードレール ” が存在していることを保証します。

下のスクリーンショットでは、新しい ” オブジェクトの IOPS 制限 ” のルール設定が仮想マシンのストレージポリシ-の設定画面でどのように見えるかを示しています。ポリシーで ” オブジェクトの IOPS 制限 ” を選択し、その時に IOPS 制限の整数値を選択します。このポリシーが割り与えられたオブジェクト ( VMDK ) は何でも、設定した IOPS の数値よりも高い IOPS を出すことはできません。

vsan62part4

基準は32KB

IOPS 制限の IO のサイズは 32 KB が基準となっています。つまり、 IOPS の制限を 10,000 に設定して、仮想マシンの典型的な IO のサイズが64KBだった場合、 5,000 IOPS だけを使用することができます。もし、ブロックサイズが 4 KB / 8 KB / 16 KB または 32 KB である場合は、 10,000 IOPS の制限を行うことができるでしょう。私の理解では、今回のリリースでは基準となっている I / O のサイズを変更する方法はありません。これは IOPS 数の Hard Limit であるので、システム上に利用可能なリソースが十分にある場合でも、VM / VMDK の IOPS を制限することになる点に注意してください。

考慮点

考慮すべきことは、 read および write の I / O はIOPS制限に含まれるだけではなく、 VM / VMDK に対して発生した幾つかのスナップショットの I / O も IOPS 制限に含まれていることです。

もし特定の VM / VMDK に対する I / O が、 IOPS 制限のしきい値よりも上昇する場合、すなわちそれは、 しきい値が10,000 IOPS に設定されて 10,001 I / O 以上を受け取ることになるので、この場合は I / O が絞られて遅延が発生することになります。

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

新卒 SE 社員が贈る vSphere のキソ!第4回~仮想マシンの配置管理はDRSにお任せ! ~

みなさん、こんにちは! VMware 新卒 SE の野田です。
少しずつ vSphere について、理解が深まってきているのではないでしょうか?
第4回目は管理者にうれしい、仮想マシンの配置に絶大な効果を発揮する機能 vSphere Distributed Resource Scheduler (以下 DRS )をご紹介します。

〜はじめに〜

DRS というのは” Distributed Resource Scheduler “という単語の頭文字を繋げた略称です。訳すと“分散リソーススケジューラ”となります。 ESXi サーバの物理リソース CPU /メモリを効率的に使いましょう!そんな感じ感じの解釈をされた方もいるのではないでしょうか。果たして DRS とはどんな機能なのか?見ていきましょう。

その前に、まずは前回登場したクラスタのおさらいです。
クラスタの構成
 vCenter Server の配下にある複数の ESXi サーバを論理的にグループ化し、 ESXi  サーバ群を作ります。このサーバ群を協調動作させる仕組みを”クラスタ”と呼びます。

図3。クラスタ構成図

図1. クラスタ構成図

クラスタとして一つにまとめられたサーバ群は、あたかも一つの大きなリソースであるかのように扱うことができました。前回の例では図1のようにクラスタは一つの大きなコンピュータのように扱える、とご説明しました。このクラスタの構成が、今回ご紹介する DRS には必須となってきます。

では、本題に入ります。ここから少しの間、社会の IT 管理者になったつもりで考えてみてください。

【状況】
あなたは IT 管理者として自社の仮想基盤の整理を任されています。今、自社の仮想基盤では10台の ESXi サーバ上で100台の仮想マシンが動いています。(図2参照)

図2。 自社のvSphereの環境光製図

図2. 自社のvSphereの環境構成図

あなたの会社がある新規サービスを立ち上げるため、仮想マシンを展開することになりました。しかし自社の ESXi サーバはリソースが飽和状態のものや時間帯によって大きく変化したりと様々です。(仮想環境は生き物です)

課題1. どこの ESXi サーバ上で新規の仮想マシンをパワーオンすべき?
おそらく ESXi サーバ1台1台のリソースの消費具合を確認し、展開先の ESXi サーバを探そうと考えたのではないでしょうか。 ESXi サーバの台数が多くなればなるほど、各 ESXi サーバのリソースを調べるのにも大変な労力と時間を消費します。見つかったとしてもすぐ負荷負荷状況が変わる可能性もあります。困りました…。

課題2. ESXi サーバ間に負荷の偏りが出てきた場合(図3参照)

図0.3のESXiホスト間の負荷の偏り

図3. ESXiホスト間の負荷の偏り

手動で仮想マシンを他の ESXi サーバに移行して ESXi サーバ間の負荷の均衡をとります。移行先の ESXi サーバのリソースに余裕があればよいですが、どの ESXi サーバにどの仮想マシンを移行すればよいのか?判断が難しい。困りました…。

課題3. 物理サーバのメンテナンスやハードウェア交換、パッチの更新やメンテナンスの時期

各 ESXi サーバのリソースを調べながら、手動で仮想マシンをリソースに余裕のある ESXi ホストへ移行していくのも根気のいる作業。こちらも課題2と同様、どの ESXi サーバにどの仮想マシンを退避したらいいのか?もちろん移行先にある仮想マシンに影響がでないようにしなくては…。

せっかく仮想基盤にしたにもかかわらず悩ましい課題がでてきてしまいました。こういった状況で存在感を示すのが「 DRS 」という機能です。先ほどクラスタは複数の ESXi サーバを、一つの大きなコンピュータ(リソース)として扱える、と説明しました。管理者はクラスタ上に仮想マシンが存在する!と意識しておりますが、実際どこの ESXi サーバ上に仮想マシンが配置されるかはこの DRS にお任せできてしまいます。

課題1. どこの ESXi サーバで新規の仮想マシンをパワーオンすべき?

DRS によって、仮想マシンはクラスタ内で最適な ESXi サーバ上に自動(もしくは管理者が承認後)で展開されます。

課題2. ESXi サーバ間に負荷の偏りが出てきた場合

負荷の偏りが発生した時点で、自動(もしくは管理者が承認後)で適切な ESXi サーバ上に移行されます。(図4参照)

図4。 DRS発動後の​​負荷のロードバランス

図4. DRS 発動後の​​負荷のロードバランス

課題3。物理サーバのメンテナンスやハードウェア交換、パッチの更新やメンテナンスの時期

物理サーバメンテナンス時も、 ESXi サーバをメンテナンスモードにすることによって、仮想マシンの再配置を自動的に行ってくれます。

このように、 DRS は仮想マシンをどの ESXi サーバ上へ展開するか?といったことを考える必要はなく、単にクラスタに仮想マシンを展開するといった感覚で仮想マシンの展開を可能にしています。課題1~3について考慮する必要は無くなりますね。
どうですか?クラスタ単位で考えると、今まで以上に仮想基盤を有効に使う事ができるかもしれません。

〜 DRS の設定〜

では DRS の設定を行ってみましょう。 DRS として仮想マシンの再配置が行われるタイミングは以下の2つです。
A )仮想マシンのパワーオン時
B )クラスタ内のリソースに偏りが生じたとき
この2つに意識しながら、 DRS の設定を行います。

図5.DRSによって再配置が行われるタイミング

図5. DRS によって再配置が行われるタイミング

 DRS の設定で特徴的なのが「自動化レベル」「移行のしきい値」です。 DRS を有効にしても仮想マシンを移行するタイミングは自分で確認したい!という方には自動化レベルの設定が役に立ちます。

図6。 DRS設定画面

図6. DRS設定画面

自動化レベル
 DRS には以下3種類の自動化レベルが提供されています。

●完全自動化
仮想マシンをパワーオンすると、仮想マシンが最適な ESXi サーバに自動で移行されます。また、 DRS がクラスタ内の負荷の偏りを検出し、自動で仮想マシンの移行を行ないます。 IT 管理者は仮想マシンがどの ESXi サーバで動いているかあまり意識しません。自動化レベルの設定ではこの完全自動化がデフォルト値となっています。

●一部自動化
仮想マシンをパワーオンした段階は、完全自動化と同じくDRS により仮想マシンが最適なホストに配置されます。しかし、クラスタ内のリソースに偏りが出てくると、仮想マシンの移行推奨が表示され、IT管理者が承認後、仮想マシンの再配置が行われます。

●手動
この場合、自動的な仮想マシンの移行は行われません。つまり、仮想マシンをパワーオンすると、推奨の ESXi サーバのリスト表示、またクラスタのリソースに偏りが出た場合、仮想マシンの移行を推奨する表示がされ、いずれもIT管理者の承認後仮想マシンの配置、再配置が行われます。

では DRS が発動するタイミング B )のクラスタのリソースに偏りが出た場合ですが、少しの偏りでも再配置をするのか、大きく偏りが出た場合に再配置をするのか?を定義するのが「移行しきい値」です。

図7。 移行しきい値設定画面

図7. 移行しきい値設定画面

移行しきい値
クラスタ内の ESXi サーバ間のリソースの偏り具合によって移行するかしないかを決定します。この決定する値のことを移行しきい値と呼びます。図7に示す通り、しきい値は1(保守的)〜5(積極的)までの5段階あり、デフォルトは3に設定されています。しきい値1はメンテナンスモードと呼ばれ、仮想マシンの再配置はメンテナンスモードが実行された際のみ行なわれます。移行しきい値は、値が大きくなるにつれ、少しの偏りでも仮想マシンの再配置(積極的な再配置)が行なわれるようになります。

再配置先を限定する〜ホストアフィニティ〜

 DRS を使用すると、仮想マシンの再配置先はクラスタ上の全ての ESXi サーバとなります。ここでゲストOSで使用しているソフトウェアライセンスの関係上等で、再配置先の ESXi サーバを限定したい!というご要望があるかと思います。このような状況で役に立つのが、 DRS のホストアフィニティという機能です。前もって仮想マシンをグルーピングしておき、その仮想マシンが動く ESXi サーバを限定することでソフトウェアライセンスの節約や、仮想マシンの所在をはっきりさせておくことも可能となります。また、このグルーピングは DRS のみならず、HAの時にも有効に働きます。

まとめ

 DRS についてご紹介しましたが、いかがでしたでしょうか? DRS でできることを一度ご理解いいただくと、この機能にきっと魅力を感じると思います。そして一度でも DRS を使ったことがある方は「 DRS がない環境はちょっと大変…と思われているかもしれません。ちなみに、VMwareでは事例を紹介しております。こちらのお客様 、4台の物理サーバ上に130 VM (統合率32.5)を稼働させ、リソースを有効に使用させてさせております。是非こちらのお客様のお声もご参照ください。
 DRS を使用されているお客様にうかがうと、「この機能はやはり便利♪」とおっしゃっておりました。今後もこの DRS の魅力を理解しながら、仮想基盤のリソースを更に有効に、またもっと楽に管理して頂ける様、私自身も vSphere の魅力をご紹介していきたいと思います。

次回もお楽しみに!

– VMware SE 野田裕二

 

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

新卒 SE 社員が贈る vSphere のキソ!第1回〜 vSphere を俯瞰する〜

はじめまして!
今回から数回に分けて新卒 SE 社員が贈る vSphere のキソ!と題して、 vSphere の用語や機能を新卒 SE 野田( Noda )、椨木( Tabuki )、川崎( Kawasaki )、氏田( Ujita )の4名でご紹介します。宜しくお願いします。初回を担当する野田裕二です。私が入社して約4ヶ月が経ち、vSphere について説明ができるようになりましたが、入社当時の状況を振り返ると、 vSphere の理解に少し手間取った部分もありました。そんな経験を踏まえて、 vSphere のキソ!では”わかりやすく”をモットーに解説していきます。

VMware vSphere ~仮想化基盤の中心的存在~
VMware vSphere (以下 vSphere )とは VMware vSphere ESXi (以下 ESXi ) と VMware vCenter Server (以下 vCenter )を含む仮想化ソフトウェアのスイートの総称です。この vSphere により、仮想化プラットフォームを実現することができます。
以下に vSphere の基本構成コンポーネントを示します。

20140813_vSphere1
– vSphere の基本コンポーネント

この図は、vSphere の全体像を表しています。各物理ホストの上にハイパーバイザーである ESXi が敷かれており、その上でゲストOS、アプリケーションが動いています。そして ESXi の管理を束ねているのが vCenter です。 vSphere 環境の管理者は vSphere Client 、または vSphere Web Client (以下 Web Client )を用いて vSphere という仮想環境の管理を行うことができます。それでは登場する各用語を押さえていきましょう!

vSphere の構成要素 ~登場人物の確認~
ここで vSphere の基本コンポーネントについて整理を行いたいと思います。
・ ESXi
・ vCenter Server
・ vSphere Client / Web Client
・ 仮想マシン
・ 共有ストレージ

VMware ESXi ~ vSphere の根幹をなす仮想化ソフトウェア~
ESXi

ESXi は、 vSphere の中核となるハイパーバイザー型仮想化ソフトウェアです。ハイパーバイザーとは仮想化ソフトウェアのことで、ホスト OS の代わりにハードウェア上で直接動作する仮想化のための OS ようなものです。ハイパーバイザー上では、複数の仮想マシンを実行することができます。具体的には、各物理サーバーの上に Windows や Linux といった OS を直接インストールするのではなく、 ESXi をそれぞれの物理サーバーにインストールしておくことで、1つの物理サーバー上で複数の OS を動かすことが可能となります。 ESXi のインストールも簡単で、慣れていれば10分程で終えることができます。

ESXi_boot
– ESXi インストーラーブート画面

VMware vCenter Server  ~仮想基盤の司令塔~
vCenter

vCenter Server とは、仮想基盤を管理する必須のコアサービスです。 vSphere 環境の管理一元化を行います。1台の物理サーバーに vCenter Server をインストールして vCenter Server として使うこともできますし、仮想マシンに vCenter server をインストールして使うこともできます。また vCenter がインストールされたアプライアンスとしても用意されておりますで、簡単に vCenter を展開することも可能です。

vCenter Server の役割として大きく2つあります。
・ 統合管理(複数の ESXi を束ねて管理)
・ vSphereにある様々な機能を有効化( vMotion や HA 、 DRS …等々、 vCenter がないと使用できません)
vSphere にある”様々な機能”に関しては次回以降にご説明しますね。

vSphere Client / vSphere Web Client ~仮想基盤の入り口~
WebClient

vSphere Client とは仮想環境にアクセスする、言わば vSphere への入り口となるインタフェースを提供します。 vSphere Client は Windows マシンにインストールして使用してましたが、 Web ベースの vSphere Web Client (以下 Web Client )を用いることによって、ブラウザベースの vSphere 環境の管理ツールを提供し、 vSphere 基盤の運用・監視を行うことができます。従来の vSphere 管理機能は vSphere Client のみだったのですが、 Web Client が登場し、今後は Web Client に統一されます。

vSphere 5.5 以降の追加機能は Web Client で対応しますので、 Web Client の操作に慣れておくことをお勧めします。先輩達は vSphere Client に慣れているようですが、私達は Web Client からスタートなのであまり違和感はありません(笑)ちなみに、 Update Manager や SRM といった一部アドオン製品のプラグインに関しては、 vSphere Client でしか使えない機能もあります。

20140813_vSphereWebCloent
– vSphere Web Client のインタフェース

仮想マシン ~仮想マシンの実体はファイル~
VM

冒頭で各物理ホストの上に ESXi が敷かれており、その上に OS 、アプリケーションが動いているとお話しました。ここで出てくる物理ホストとは、物理サーバのことを指し、この物理サーバ上に直接 ESXi がインストールされています。この ESXi がインストールされたサーバのことを通称「 ESXi サーバ」と呼んでいます。そしてこの ESXi が、 Windows や Linux 等の OS = ゲスト OS やアプリケーションを入れる器を作り出します。この器が「仮想マシン」です。

この仮想マシンには、物理環境でいう CPU やメモリ、 HDD といった装置も ESXi によって仮想化されソフトウェアとして定義され、仮想 CPU 、仮想メモリ、仮想 HDD として存在しています。 vSphere 5.5 では、仮想マシンに対して最大 64 vCPU (仮想 CPU )、1 TB のメモリを割り当てることができます。また、仮想マシンの実体は”ファイル”です。全ての仮想マシンの情報はファイル( .vmdk や .vmx 等)としてストレージに保存されています。ファイルなので、仮想マシンの複製が簡単に行え、ネットワークを通じて遠隔地に同じ構成の仮想マシンを作成することも簡単にバックアップをとることも可能になります。災害対策としても仮想環境は威力を発揮し、物理環境では構築等やハードに大幅な時間コストがかかってしまい敷居が高くなってしまいますが、 vSphere 環境では、そういった敷居を下げてくれます。

下図は仮想マシンのイメージになります。この例では、 ESXi サーバ上に3台の仮想マシンが載っています。
それぞれ仮想マシンには CPU、メモリ、 NIC 、 Disk がありますが、ハイパーバイザーが各仮想マシンに物理リソースを割り当ています。
仮想マシンに入るゲスト OS は仮想環境で動いている、ということを意識せずに割り当てられたリソースを使って動いています。

20140813_vSphere2
-仮想マシンの実体

共有ストレージ ~仮想マシンの家~
Storage

vSphere 環境では共有ストレージがほぼ必要となってきます。共有ストレージへの接続方法としては、 FC 、 iSCSI 、 NFS 等、選択可能です。この共有ストレージに仮想ディスクファイルが保存され、共有ストレージに保存された仮想ディスクファイルを読み込むことで、仮想マシンを動かしていいます。ストレージについては次回ご説明します。

今回は主に用語の説明を中心に vSphere の全体像を俯瞰してみました。 vSphere の全体像はご理解いただけたでしょうか?
次回は「 vSphere 環境におけるネットワークとストレージ」についてをお贈りします!

kawasaki_noda_tabuki_ujita
– VMware SE 野田裕二

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