vSphere HA アドミッションコントロール ”クラスタ リソースの割合”の計算方法
社内で、”アドミッションコントロールによるリソース予約”について質問をされることが結構多いです。
既存の書籍やドキュメントでも、説明文が長くわかりにくいものが多いので、本記事ではvSphere Web Client上の画像を用いつつリソースの予約状況について解説を入れていきたいと思います。
まず”そもそもアドミッションコントロールって何?”という方は、是非こちらを御覧ください。
次に、今回のテーマはアドミッションコントロールでも3タイプの手法がある中の、
"クラスタ リソースの割合(%)"についての説明です。
まずお題となる環境の構成をご覧頂きましょう。
- 2ノードホストが参加するクラスターです
- クラスターのCPU搭載量は11.08GHzです。
- クラスターのメモリ搭載量は10GBです。
- vSphere HAは有効化済み
- アドミッションコントロールも有効化済み、かつリソース予約方法も"クラスタ リソースの割合"にて50%(既定値)となっています。
パターン1. クラスターリソースの50%がアドミッションコントロールにて予約されている場合
ご覧頂くと、全体のリソースの50%として、次のリソースが確保されています。
- メモリは5GBがフェールオーバー用に予約(10GB*50%=5GB)
- CPUは5.60GHzがフェールオーバー用に予約(11.20GHz*50%=5.60GHz)
つまり、クラスターリソースの残り半分は仮想マシンやvmkernel上のプロセスによって利用可能だと言えます。(今回は予約が50%なので、利用出来るリソースも全体で5GBとCPU 5.60GHzまで利用可能)
パターン2. クラスターリソースの70%がアドミッションコントロールにて予約されている場合
続いて、パターン2ですが、既定値よりも20%多めにアドミッションコントロールによる制御範囲を増やしました。
なぜわざわざこれを行ったか、と言えばよく聞かれる質問に”本設定でセットするパーセントは、”フェイルオーバーのためのリソース予約値”なのか”仮想マシン運用のために確保するリソース容量値なのか”、どっちなのか?”とよく聞かれるからです。
正直、デフォルト値が50%の予約、であれば、フェイルオーバーリソースも仮想マシン動作用リソースも双方ともに50%になるので、この値の情報だけでは、この値の意味合いを把握するには、確かにこの値だけでは不十分です。
そこで、あえて50%以外の値をセットし、リソースの取られ方を見てみることにしました。
結論としては次の通りで、やはりアドミッションコントロールで設定する割合というのは、”フェールオーバーのためのリソースサイズ”であることがこれで明白になりました。
※ちなみに本検証もVMware Hands On LABで行っているのですが、ラボのレンタル時間を超過したため、再度レンタルし直したら、ホストのCPUサイズが前回と異なるリソースがアサインされました(前回は1ホスト辺り5.60Ghz、今回は4.20GHzとなっています)
パターン3. クラスターリソースの33%がアドミッションコントロールにて予約されている場合
最後に、少し細かい値設定したケースを考えてみました。
この33%という値は現場でよく見かける数字です、理由としては3ノードクラスターの場合に、1台のホスト障害が発生した場合に、フェイルオーバーリソースを十分に用意する際に33%と設定しているお客様が多く居られます。
ですが、実情としてこの数字を入力することで、”リソース不足”に関連するメッセージに直面しているお客様が多いと私は感じています。
3台で1クラスターという環境で、もしパーセンテージ指定でリソース予約を行いたい場合は、”34%”と入力した方が1ノードホスト分以上のリソースが確保できます。
ちなみに、同設定値に対し小数点を持った設定を試みましたが、全て切り捨てされました。(つまり33.3%と指定した場合は、33.0%として取り扱われます)
以上です。今回の総括は次の通りです。
iSCSI ポートバインドを行う理由
<著者からのお願い>
本記事の改訂版として以下のリンク内に更新記事を掲載しております。最新の情報をご確認頂くため、こちらのリンクをご覧ください。
なお、はてなブログ上の本記事については今後更新は行いませんので、ブックマークなどをされている読者様は、恐れ入りますが新ブログを改めてブックマーク頂くようお願い致します。
今回も、トレーニングで質問を受けた内容から1点紹介です。
自分自身もたまに見返すことがある"iSCSIポートバインド"について、備忘録としての意味合いも込めて投稿しておきたいと思います。
まず、vSphere ESXiにおいて、iSCSIストレージを利用する場合、"iSCSI ポートバインド"を利用するケースがありますが、これは全てのiSCSIストレージが対象ではありません。
キーポイントは2種類のアレイのiSCSI ターゲットポートのあり方の違いにあります。
ESX/ESXi でソフトウェア iSCSI ポート バインディングを使用する際の考慮事項 (2080447)
これは、iSCSIターゲット側のストレージにて、IPアドレスの利用形態が”シングルサブネット”か”マルチサブネット”によって変わります。
以下のKBには、次のような記載があります。
同じサブネット上に複数の VMkernel ポートがある場合にネットワークのデフォルトの VMkernel ゲートウェイ インターフェイスを変更する (2093988)
つまり、単一のESXiホスト上に複数のvmkernelポートを同一サブネット上に設ける場合、基本的にはそのうちの1つしか使われないという原則があるわけです。
これを踏まえ、幾つかのiSCSIイニシエーター側のポート構成を考えてみたいと思います。
例:2つの物理NICポート(vmnic)に対し、1つのvmkernelポートを用意した場合
※上述にあるよう、同一サブネット上に複数のvmkernelポートを置くと、1つしか利用されない、というルールがあるので、この事例をはじめに持ってきてみました。
この場合、チーミングが組まれた構成となっています。
ここで、vSphereのネットワークにおいて、チーミングポリシーを思い出してみると、標準スイッチでは3種類のパターンがありました。
1. 送信元の仮想ポートID
2. 送信元のMACハッシュ
3. 送信元及び送信先のIPハッシュ
これらを考えた場合、2つの物理NICポートの使われ方は次のようになると言えます。
1. 送信元の仮想ポートIDの場合
単一のvmkernelポートに対し、仮想ポートは常に一定です。つまりプライマリなアクティブポートとして選択されるvmnic(物理NICポート)に障害が発生するまでは、単一のポートだけが使用されます。(つまり、冗長性のためにセカンダリポートがあり、負荷分散は提供しない)
2. 送信元のMACハッシュの場合
vmkernelポートは、仮想マシンと違い、MACアドレスは提供しないのでこれは論外ですね。
仮想マシンであればvNICがあり、00:50:56からはじまるMACアドレス付帯がありますから、これらを基準に物理NICが選択されます
3. 送信元及び送信先のIPハッシュの場合
これであれば、複数のiSCSIターゲットIPを持つストレージであれば、複数のvmnicを利用してくれる形にはなりますが、Link Aggregationの構成が必須となってしまい、構成が難しくなってしまいます。
結論、単一のvmkernelポートに対し、複数の物理NICポートをアサインするチーミングでは、冗長性と負荷分散の両立が難しい状況です。
続いて、複数のvmkernel ポートを、単一ホストに準備した場合です。(iSCSIポートバインドを使う場合、使わない場合の2つです)
例:2つのvmkernel portを準備した場合(iSCSI バインド無効、同一サブネットIP付帯)
例:2つのvmkernel portを準備した場合(iSCSI バインド有効、同一サブネットIP付帯)
以上の点から、iSCSI ポートバインドを利用することで、vmkernel ポート1つ辺り、1つのvmnicだけをアサインし、ホストレベルでの冗長性と負荷分散を実現するように設定が出来ます。
繰り返しますが、これはあくまでもiSCSIターゲット側(ストレージ側)が、シングルサブネットのIPアドレスだけで構成されるケースに限定され、複数のサブネットマスクが存在するストレージのケースに於いては、バインドは不要となります。
(理由は、別サブネットに対するvmkernel ポートが複数存在する場合は、ESXiはそれらを同時に利用することが出来るからです)
以上です、勿論ストレージ導入の際に、ハードベンダー側での導入ベストプラクティス等がある場合はそれも是非参考に頂けると幸いです。
VMware tools インストール、アップグレード時に再起動は必要か?
esxtopネタから少し横道にそれますが、トレーニングで出たネタです
VMware toolsは、仮想マシンに対してインストールする事で、仮想基板のインフラの最適化や管理性を高めてくれる効果があります。
これらをインストール、またはアップグレードする場合、やはりユーザーの視点としては"仮想マシンの再起動は必要か?"という点が気になりますね
この点については様々な方の意見を聞くと、"前にやった時には再起動はいらなかった!"であったり、"最近試したら再起動を要求された"と意見が分かれます
そこで資料を確認したところ次の情報に行き着きました。
Linux 仮想マシンでの VMware Tools の手動インストールまたは手動アップグレード
結論から言えば、ケースバイケースです。
これは、VMware toolsはその中にいくつかのドライバーを含んで入ることに起因しており、アップグレードに伴い、内包するドライバーが更新される場合は再起動が必要という判定です
esxtopの使い方&見方 - ネットワークの通信状況は?(ネットワーク編)
少々更新が遅れましたが、今週初めの記事です。しばらくesxtopネタを続けようかと思っております。
今回はネットワークの通信状況について、esxtopにて確認をしてみようかと思います。
まずはじめに、主にネットワークのモニタリングをする目的は次の2つです。
- 負荷分散状況の把握
- パケットドロップの有無
これらを踏まえ、esxtopを見てみましょう。
esxtop起動後、ネットワークの"n"を押下すると次の画面が表示されます。
表示情報のデータは一切変更は加えておらず、上記のような配置となっています。
ネットワークの受信情報がオレンジ(左から、毎秒のパケット受信数/毎秒のパケット受信Mb数/パケットサイズ平均)
ネットワークの送信情報がグリーン(左から、毎秒のパケット転送数/毎秒のパケット転送Mb数/パケットサイズ平均)
ネットワークのパケットドロップカウントがレッド
非常にシンプルですね。
特にレッドのパケットドロップのカウントが0以上である場合は、通信問題が、パケットの破棄によって起きていると言えます。この図は正常ですね。
また、上記の情報からでもある程度の仮想スイッチのイメージ図がつかめます。
ちなみにチーミング構成により、各vmkernelポートも仮想マシンポートグループも、vmnic0とvmnic1をアップリンクとして持っていました。
上図では、負荷分散の配慮の元vmnic0とvmnic1が均等に使われていますが、試しにvmnicをコマンドで落としてみました。
想定通りですが、vmnic1をダウンさせたことで、全ての通信がvmnic1によりましたね。
また、vmnic1をサイドアップしてみます。
vmnic1ダウン前に、vmnic1を使っていた各vmkernelポートは、フェイルバックルールにより元のポートに戻りましたね。
以上です。ネットワークに関して言えば、CPUやメモリ程見る箇所が多くあるという印象は無いですね。負荷分散状況とパケットドロップをモニター出来ればまずは良いかなという感想です。
esxtopの使い方&見方 - 物理リソースは足りてるか?(メモリ編)
先日に引き続き、esxtopを使った、ホスト単位のメモリ利用状態の概要把握について語りたいと思います。
先日の記事はこちらにありますので、是非よろしければご覧ください。
まず、メモリ利用状況を分析したいホストにSSHでアクセスし、"esxtop"と入力後、"m"を押下した図がこちらです。
先日と同様、上から3行分に対し解説を入れてみました。このesxtopの出力から、次のようなことが分かります。
- PMEMのTotalが8191MBであるため、このホストは約8GBのメモリを搭載している
- PMEMのfreeが4176MBであるため、空き容量は4GBである
- 上記2つの事から、現在約4GBのメモリが利用されている
- PMEMのotherが2666MBである事から、仮想マシンにより、2.6GB程のメモリが利用されている
(この点はより正確に言えば、仮想マシン+vmkernel上で動作するworldの合算値が2.6Gです)
実際に上記の様になっているか、vSphere Web Clientで確認してみたいと思います。
解説通りの様子ですね。ホスト単位の大まかな概要をつかむためには、上の3つの行だけでもなんとなく状況がつかめることが分かりました。
また、上部の他の項目についても少し触れたいため、2つの状況を用意し値を比較しました。
比較からわかる点として、オーバーコミット状態ではSWAP, ZIP, MEMCTLがカウントアップしています。
これらは、オーバーコミット状態がトリガーとなり発生するvmkernelがメモリをやりくりするための機能の略称です。
これらの機能については別記事で紹介したいと思います。
esxtopの使い方&見方 - 物理リソースは足りてるか?(CPU編)
昨日に引き続き、esxtopネタです。
なぜリソースの状況をモニタリングするのか、と言われれば”リソースが足りているのか否か”を判断するためですね。
そこで今回は、”物理CPUリソースは足りているか”という観点で、esxtopの簡単な見方を紹介します。
はじめに申し上げますが、ここで紹介するモニタリング手法や数値などに対する考察は、全ての環境に対し同様のコメントが当てはまるとは言えませんので、ご注意ください。
今回は、esxtopの初回起動時の画面で表示される2~3行に注目をしてみました。
※オレンジのPCPU USEDとPSCPU UTILの違いはこちらのURLよりご確認ください。
What is the difference between PCPU Used and PCPU Utilized? - VMware vSphere Blog
この数行を見ただけでも色々なことが分かります。詳細は画像側のコメントをご覧ください。
今回のテーマにある、”物理CPUリソースは足りてるか?”についてですが、特に赤色の箇所をご覧頂くと、直近3パターンの時間におけるCPUの利用率が分かります。
例えばシステムのピークタイムにesxtopを起動し、この値が1.00であれば、それはCPUの利用率が100%を意味します。(つまりリソースをフルに利用していると言えます)
この場合は、CPUの増設や、クラスターに対し追加ノードを用意し、vMotionで仮想マシンを他のホストに動かす事で、リソースの利用率を下げてやることが期待出来ます。
一方で、システムのピークタイムにesxtopを起動し、この値が0.50であれば、それはCPUの利用率が50%を意味します。(つまり、CPUにはまだ余力があり、増設そのものの効果が薄いと言えます。)
但しこれについては”CPUに余力があるのであれば、コア数を増やして良いか?”と言われれば必ずしもその次第ではありません。
この点については仮想マシン上で動作させるアプリケーションがマルチスレッド対応の場合は複数コアがあることで、パフォーマンスの向上を期待出来ます。
以上です。話したい事は多くありますが、1つ1つの記事で解説をして行きたいと思いますので、今後のシリーズもご期待ください。
esxtopの使い方&見方 - esxtopとは何か?(起動/ログイン/基本操作編)
<著者からのお願い>
本記事の改訂版として以下のリンク内に更新記事を掲載しております。最新の情報をご確認頂くため、こちらのリンクをご覧ください。
なお、はてなブログ上の本記事については今後更新は行いませんので、ブックマークなどをされている読者様は、恐れ入りますが新ブログを改めてブックマーク頂くようお願い致します。
esxtop、VMware vSphere ESX/ESXiの運用を少し触ったことがある人で、”パフォーマンス”について問題を抱えたことがある人は、一度は聞いたことがあるかもしれない名称です。
esxtopとは、”ホスト単位で実行する、CLIベースのパフォーマンス監視ツール”です
監視できる対象物としては、CPU、メモリ、仮想マシン、ホストバスアダプター、ディスクデバイス、電力管理、vSANなどが挙げられます。
- Windowsで言う、”タスクマネージャー”のようにリアルタイムのシステム監視に向いています。
- Linuxの”Top”コマンドの利用経験がある方は、それとほぼ近い操作感でご利用頂けます。
- 起動方法はTelnetやSSHでESXiに接続し、"esxtop"とだけ入力すれば起動出来ます。
起動手順
起動直後は、次のような状態です。
- 5秒間隔で画面が更新されます
- 初期画面では、"CPU"の活動状況に関する情報の画面が表示されています。
基本操作
esxtop起動中に"h(helpのh)"を押下すると次の画面が表示されます。
必要な情報はここに掲載されています。
特によく使うものとしては、”画面更新タイミングの変更”、”各画面スイッチ切り替え”、”ソート”です。
これらの操作は大文字、小文字を分けますので 操作時はご注意ください。