Home > Blogs > Japan Cloud Infrastructure Blog > 作成者別アーカイブ: 塚田 大輔

作成者別アーカイブ: 塚田 大輔

これだけは押さえておきたい!マルチクラウド運用管理

みなさん、こんにちは。

VMware vRealize Operations Manager (vR Ops)の主な得意分野は、仮想基盤のキャパシティ管理や健全性管理ですが、他社の運用管理製品と連携することによって、vR Ops単体では不十分な機能を相互に補完し合う事が可能です。

今回は株式日立製作所の運用管理製品「JP1」、およびストレージ管理製品と連携してクラウド基盤全体、およびその上で動くサービスや業務を安定的に運用する方法について、株式会社日立製作所の坂川博昭様と同 長江亮介様にご紹介していただきます。それでは坂川様、長江様よろしくお願い致します。

 

hitachi_apr2015_sakagawa_banner

こんにちは。株式会社日立製作所 ITプラットフォーム事業本部 JP1ビジネス推進センタの坂川(さかがわ)(以下、坂川)です。私は、JP1のモニタリング製品を中心に拡販活動をしています。今回は、最近よく話題になっているクラウド環境についてお話をさせて頂きます。特に、さまざまなクラウド環境でも、一つにまとめて管理できる統合運用管理製品JP1のご紹介をしたいと思います。

hitachi_apr2015_nagae_banner

皆さん、こんにちは。同じく日立製作所 プロダクトビジネス推進部の長江(ながえ)です(以下、長江)。僕は、プラットフォーム製品、サーバ・ストレージ含めた装置周りの運用管理ソフトウェアの拡販に従事しています。これまでは特にストレージ運用管理を担当していましたので、その観点で最近のマルチクラウド環境のストレージ運用まわりの課題への新しい解決案をご説明したいと思います。

専用ツールがネックになる?マルチクラウド運用管理の落とし穴

hitachi_apr2015_sakagawa_icon (坂川)最近クラウドって言葉がはやっていますけど、さまざまな会社がクラウドサービスを提供しています。それぞれのクラウドを管理する時には、それぞれ専用ツールを使って管理をするのが一般的です。それだと、それぞれのツールの使い方を覚えないといけないですし、UIも異なるので、管理者には負担が大きいという問題があります。

日立の統合運用管理製品JP1を使いますと、複数のクラウド管理が、一つの製品でまとめて管理できるというメリットがあります。運用コストも低減できますし、管理者も運用が楽になるというメリットがあります。

hitachi_apr2015_nagae_icon

(長江)確かにそういう負担はありますよね。それぞれのクラウド環境で用意されたツールを使わないといけないですし、使いやすさの面で、ネックになることが多いですよね。ですから、そこを統合的に管理できるツールがあれば、ぐっと楽になりますよね。

 

hitachi_apr2015_sakagawa_icon(坂川)そうですね。JP1を使いますと、マルチクラウド環境の一元管理ができます。構成情報に関しては、JP1/Integrated Management(以下JP1/IM)でさまざまなクラウド環境の構成情報を取得することができます。

hitachi_apr2015_jp1-vrops_rev2

稼働監視については、JP1/Performance Management(JP1/PFM)を使うと、さまざまなクラウド基盤が混在していても情報を一つの画面で確認することができます。今どうなっているのか、リソースの使用状況はどうなのかを俯瞰することができます。

クラウド上で稼働している業務については、ジョブ管理製品であるJP1/Automatic Job Management System 3(JP1/AJS3)を使うことによって、クラウド上での業務を自動化できます。

クラウド種別を問わずに、監視や業務で発生するイベントをJP1コンソール画面で一元管理をすることができます。この画面では、マルチクラウド環境で発生するイベント、それから監視で発生するイベント、業務で発生するイベントを「統合監視」できます。

hitachi_apr2015_nagae_icon

(長江)最近はお客さまがクラウド管理をされることが多いですし、例えば、従来ではストレージは管理していなかったのに、今はサーバ・ストレージを含めた全体的な管理の必要にせまられているお客さまが増えてきています。クラウドの実績が豊富なVMwareとストレージ間での課題もありますよね。

 

hitachi_apr2015_sakagawa_icon

(坂川)そうですね。他にも、クラウドを利用していて動作が重くなった時に、どこに問題があるのかを分析するのも結構大変になってくるのかなと。そういう時に、ツールを使って仮想のリソースが足りないのか、それともサーバなどのハードウェアのリソースが足りないのか、もしくはストレージに何かボトルネックがあるのかとか、そういう分析をする作業もすごく大変ですよね。

VMware社の管理ソフトであるvRealize Operations Manager(以下vR Ops)を使うと、どこに問題があるのかをヒートマップで表示してくれて、「ストレージのどこどこの箇所でI/Oネックが発生している」といった事象がわかる仕掛けになっています。このvR OpsとJP1を連携させると、管理者にとってさらにやさしい運用ができるようになります。例えば「リソースが足りなくなっているよ」というイベントをJP1で検知して、じゃあその問題はどこにあるのかをvROpsで分析するといった感じですね。

ストレージの観点でも、いろいろと課題はありますよね?

hitachi_apr2015_nagae_icon

(長江)そうですね。VMware製品を使われている方は、管理対象をVM単位とすることが多いと思いますが、やはり従来のストレージだと、LUN(Logical Unit Number、ストレージの論理ユニットを識別するための番号)単位、ボリューム単位の管理になってしまうので、ストレージとサーバで管理したい粒度が異なったりと、課題はありますね。

例えば、従来の環境だと「VMがなんだか遅いなあ」という時に、まずはVMを構成しているデータストアを調べて、そのデータストアがどこのストレージにつながっているかを調べて、そのデータストア上に乗っているVMのどれが影響を与えているかを調べなきゃいけなかったので、非常に大変でした。

それに、LUNの上に載っているVMが複数あれば、どのVMに原因があるかの特定も難しいですし。やはり、ストレージはLUN単位、サーバはVM単位で管理しているところに、管理対象のギャップがあり実運用上で課題となりますね。

hitachi_apr2015_sakagawa_icon

(坂川)仮想基盤のVMware製品の部分は、vR Opsと連携することによって、検知したイベントも一元管理ができるようになります。これにより、vR Opsでとらえたストレージまわりの異常や、仮想環境で発生するイベントも合わせて見られるようになります。

vR OpsとJP1/Base間の連携に関してはクラウド連携設計支援のための商品をご用意していますので、それを組み込むことによって、シームレスにイベントが通知されるようになります。

hitachi_apr2015_nagae_icon

(長江)さきほどもお話しましたが、ストレージで管理したい単位と、サーバで管理したい単位とでギャップがあるので、そこが運用管理のネックとなっています。

具体的にいうと、一つのLUNに、複数のVMがくくりついています。これがどういう問題を生むかと言うと、例えばLUNでバックアップを取って、一つのVMだけを戻したいとします。でも、LUNの単位でのバックアップなので、すべてのVMが昔の状態に戻ってしまいます。そこで、これまではサーバ側から、スナップショットやクローンを作って対処していました。

それを変えてしまうのが、2015年3月にリリースされたVMware vSphere 6 のVirtual Volumes(以下VVOL)です。VVOLを使うことで、これまでサーバ側でやっていたスナップショットやクローン処理を、ストレージにオフロードできますので、性能が早くなるとか、管理の単位が楽になるという大きなメリットがあります。

そして、VMが遅くなった時でも、どこで遅くなっているのかが特定できますので、分析の精度が向上し、管理者の負担も減るというメリットがあります。将来的にはVVOLの情報もvROpsに表示されるようになり、ユーザの使い勝手がよくなればよいな、と思っています。

また、これまでは、こういう管理をしたい場合はVMとLUNを1対1で構築するケースもありました。その場合だと数が増えてしまって管理が大変だったり、1つのサーバに割り当てられるLUNの数にも制限がありました。

こういった問題にも、VVOLを使いますと、プロトコルエンドポイント(サーバとストレージ間のアクセスポイント、以下PE)と呼ばれるLUNをサーバに割り当てて、それ以外のLUNはすべてPE経由でアクセスすることで数の制限もなくなりました。

今までは、ストレージの管理者がLUNの割り当てまでを担当していたのですが、サーバの管理者がLUNを割り当てたり、スナップショットを操作したりすることができるようになりますので、ストレージ管理者とサーバ管理者のやりとりも減りますし、VMが必要になった時に、すぐに構築できるので機敏性が増しますね。

こういったVVOLに対して、日立ではHitachi Command Suite(以下、HCS)を使って、VVOLを使うために必要なストレージの設定や、ストレージコンテナの作成、ケーパビリティ(Capability、ストレージを管理するためのパラメータやルールのセット)を作ったり、VM単位の性能分析を実行したりと、運用管理を楽にする工夫をしています。

実際にはこのような画面で管理します。

hitachi_apr2015_storagecontainer

※開発中の画面のため予告なく変更となる場合があります。

詳しくは、2015年5月14日にセミナーを開催予定ですので、そちらでご紹介します。(セミナーの詳細はページ下部をご覧ください。)

日立が目指す運用管理

hitachi_apr2015_nagae_icon (長江)長々とお話してしまいましたが、最後に一つだけ。

VVOLにおけるストレージ側の実装については、ストレージベンダの依存になるところが大きいので、そこでいろいろな独自性を出していけるのかなと思っています。ですから、日立ではより使いやすくなるようにエンハンスを行っていく予定です。マルチクラウド運用に対して、ユーザは使い勝手を意識しなくても、楽に使えるようなものを順次提供していけたらなと。

hitachi_apr2015_sakagawa_icon

(坂川)そうですね。JP1もそうです。JP1はおかげさまで20周年を迎えることができました。今後も皆様のご要望を受けつつ、より使いやすく、皆様の役に立てるような運用管理製品を目指して、エンハンスをしていく所存です。

 

hitachi_apr2015_nagae_icon

(長江)それでは、今回ご紹介した内容を2015年5月14日に予定しているセミナーでご紹介します。 ぜひお越しください~!

 

 

hitachi_apr2015_sakagawa_icon

(坂川)浜松町で僕と握手!

無料セミナー開催のご案内

いかがでしたか?マルチクラウド運用管理、おわかりいただけたでしょうか? もっと詳しく知りたい!という方に、坂川と長江が今回ご紹介しきれなかった運用管理のコツを詳しくご説明いたします。

マルチクラウド運用にお困りの方へ ~最新の運用管理のご提案~

  • 日時:2015年 5月 14日(木) 14:00 – 17:00 (受付開始 13:30)
  • 会場:ヴイエムウェア株式会社 本社(東京都港区浜松町1-30-5浜松町スクエア13F)
  • 参加費:無料(事前登録制)
  • お申込み:http://info.vmware.com/content/APAC_JP_ev_joint_ht

皆様のご参加を心よりお待ち申し上げております。

関連リンク

VMworld 2014 からの注目セッション 第2回 – Software-Defined Data Center と Hyper-Converged Infrastructure他

皆様こんにちは、VMwareの塚田と申します。

今回は、8月末に米国サンフランシスコで開催されたVMworld 2014にて発表された数あるトピックより、比較的大きな注目を集めたVMware EVO:RAILに関連するセッションを取り上げ、より詳細な情報をご紹介致します。

VMworldでは、VMware EVO:RAILに関連するセッションが複数提供されました。本ブログ記事ではその中から下記セッションのの内容に沿ってVMware EVO:RAILについて紹介致します。

  • SDDC3245 (Software-Defined Data Center through Hyper-Converged Infrastructure)
  • SDDC2095 (Overview of EVO:RAIL: The Radically New Hyper-Converged Appliance 100% Powered by VMware)

Hypver-Converged Infrastructure – SDDC導入に最適化されたアプローチ

今年のVMworldにおける弊社からの発表、または発信内容のテーマの一つがSoftware-Defined Data Center(以下SDDC )の推進です。

SDDCにおいては、サーバ、ストレージ、ネットワーク等のデータセンター内のハードウェア資源は全てソフトウェアによって仮想化および抽象化され、リソースプールとして利用可能になります。また、それら仮想化されたリソースの運用管理はソフトウェアやAPIによって自動化され、ビジネス部門やITサービスの利用者からの要求に迅速に応えられようになります。

お客様が自社のITインフラをSDDCへ移行させたい、あるいは新規に導入したい、と考えられた時、お客様が取りうる導入方法(アプローチ)は下記の3通りのいずれかであるとVMwareは考えます。

evorail_fig01

  1. Build Your Own(アラカルト)
      • サーバやストレージ、ネットワーク機器などのハードウェア、仮想化ソフトウェア、管理ソフトウェアなどを個別に選択して調達し、お客様に合わせて統合する
      • 利点:お客様の要件に沿ったカスタマイズが可能であり、構成上の自由度が最も高い
  2. Converged Infrastructure(統合インフラストラクチャ)
    • サーバ、ストレージ、およびネットワーク機器が単体シャーシ、またはラック内に工場出荷時に構成済み。ソフトウェアはオプションとして選択可能。
    • 利点
      • パッケージ済みなので購入が容易
      • お客様に合わせてカスタマイズが可能
      • 一本化されたサポート窓口
  3. Hyper-Converged Infrastructure(高度な統合インフラストラクチャ)
    • 仮想化ソフトウェアとハードウェア(サーバ、ストレージ、ネットワーク)がSDDCを前提として統合済み
    • それらのために最適化された管理ソフトウェアも同梱
    • 利点
      • 購入が容易
      • ハードウェアとソフトウェアがSDDC向けに設計済み
      • より短時間で導入可能
      • 一本化されたサポート窓口

SDDC実現への3番目のアプローチであるHyper-Converged Infrastructure の特徴は、その用途をSDDC実現のために絞り込み、導入にかかる事前検討や調整の対象を徹底的に削減していることです。その代わり、カスタマイズの自由度が下がったり、拡張性に制限がかかったりするなどのトレードオフが伴いますが、SDDC実現を最優先にしたアーキテクチャであると言えます。

SDDC向け専用アプライアンス – VMware EVO:RAIL

VMware EVO:RAILは、このSDDC向けのHyper-Converged Infrastructureのアーキテクチャに沿ったハードウェア アプライアンスです。

evorail_fig02 evorail_fig03

VMware EVO:RAILは、2RUのシャーシ内に4台のサーバノードが搭載され、各ノードは次のようなスペックを備えています。

  • Intel Xeon E5-2620 v2プロセッサ(6コア)x 2
  • 192GBメモリ
  • ストレージ
    • 146GB SAS HDD、または32GB SATADOM(ESXiの起動ディスク)
    • 400GB SSD x 1
    • 1.2TB SAS HDD x 3
  • ネットワーク
    • 10Gb Ethernet x 2
    • 100Mbps/1Gbps管理用NIC x 1

また、下記のソフトウェアが予め組み込まれています。

  • vSphere 5.5(Enterprise Plusエディション)
  • VMware Virtual SAN
  • VMware vCenter Log Insight
  • EVO:RAIL Engine

VMware EVO:RAILはサーバノード間の共有ストレージを持っていません。その代わり、各サーバノードが内蔵しているSSDとHDDをVMware Virutal SANによって共有データストアとして使用します。

SDDCの導入と管理の複雑性を排除した管理ソフトウェア「EVO:RAIL Engine」

evorail_fig04

また、EVO:RAIL Engineは、VMware EVO:RAILのための管理用ソフトェアです。お客様は、VMware EVO:RAILの最初のセットアップから仮想マシンの作成など毎日の運用までを、このEVO:RAIL Engineで行うことが可能です。

VMware EVO:RAILをセットアップをする際は、PCからHTML5対応ブラウザを使って接続すれば開始可能です。セットアップにあたってESXiやvCenter Server、VSAN等に関する知識やスキルは必ずしも必要ではなく、インフラのことを意識せず、仮想マシンの作成や運用に専念することが可能です。

セッションでは、EVO:RAIL Engineを使うことにより、VMware EVO:RAILの初期化から最初の仮想マシンを作成するまで約15分で完了するデモを紹介していました。

evorail_fig05

また、EVO:RAIL Engineは最大4台までのVMware EVO:RAILを管理することが可能であり、増設もとても簡単です。2台目以降のVMware EVO:RAILをネットワークへ接続すると、クラスタへ自動的に追加され、コンピュート(CPU, メモリ)とストレージそれぞれの容量が自動的に拡張されます。一般的なサーバ用途の仮想マシンであればVMware EVO:RAIl 1台あたり100台、仮想デスクトップ(VDI)用であれば仮想マシンを同250台まで作成可能です。アアプライアンスを追加することにより、サーバならば最大400台、仮想デスクトップであれば最大1,000台まで拡張することが可能です。

VMware EVO:RAILはOEMパートナーから提供されます

evorail_fig08 evorail_fig09

ここまでVMware EVO:RAILの説明をして参りましたが、VMwareが「EVO:RAIL」というハードウェア製品を開発し販売するわけではございません。この点はくれぐれもご注意ください。

VMwareはVMware EVO:RAILを構成するためのソフトウェア(vSphereやEVO:RAIL Engine等)を開発し、これのOEM契約を結んだパートナー(以下EVO:RAILパートナー)各社へ提供しています。EVO:RAILパートナーが、このEVO:RAILソフトウェアと各社が開発、または調達したハードウェアを組み合わせ、各社それぞれのVMware EVO:RAILアプライアンスを開発し提供します。

本ブログ執筆時点でのVMware EVO:RAILのOEMパートナーは、Dell, EMC, Fujitsu, Inspur, Super Micro、およびネットワンシステムズの6社です。特にネットワンシステムズは、VMware EVO:RAILに基づくアプライアンス製品「NetOne Integrated System Appliance for VMware EVO:RAIL」を10月1日より販売開始することを発表されました(ネットワンシステムズによる発表資料へのリンク)。他のOEMパートナーからも日本国内でのVMware EVO:RAILアプライアンスの発表が続くと予想されますので是非お待ち下さい。

VMware EVO:RAILはOEMパートナーから提供されます

まとめ – VMware EVO:RAILの利点

ここまで述べてきました通り、 VMware EVO:RAILは、VMwareが推進するアーキテクチャ “Software-Defined Data Center” (SDDC)を実現するために特化したインフラストラクチャ アプライアンスです。これを用いる利点を再度まとめてみます。

SDDCのための基盤を最速で導入、構築することが可能。

VMware EVO:RAILは、SDDCのためのインフラとして求められる性能や信頼性、拡張性を備えながら、複雑性を徹底的に排除しています。セットアップ時に必要な設定項目もIPアドレスや管理者のパスワードなど必要最小限にとどめられています。また、ハードウェア、およびソフトウェアが相互に密に連携しています。それらのため、導入後最短15分で最初の仮想マシンを起動することが可能なくらい、SDDCを最速で構築することが可能です。

基盤構築や運用のために仮想化技術やハードウェアの専門知識は必須でありません

VMware EVO:RAILの運用管理は専用の管理用ソフトウェア”EVO:RAIL Engine”を用います。その操作にあたっては、VMware ESXiやvCenter Server等の仮想化ソフトウェア、そしてサーバやストレージ等ハードウェアに関する知識も必須ではありません。また、それらの技術に精通した専門家を雇用しづらい組織や、専門家が配置されていない拠点においてもSDDCのための基盤を導入することが可能です。

拡張が非常に容易、そのため常に最適な構成で利用可能

VMware EVO:RAILは最大4台(サーバノードは最大16台)まで拡張することが可能です。また、増設も非常に容易です。EVO:Engineが増設されたシャーシを認識すると、追加されたCPU, メモリ、HDDやSDD等のリソースが利用できるよう自動的に再構成します。その間も、仮想マシンを稼働させ続けられます。

このように拡張が非常に容易なので、必要になった時にリソースを追加することが可能です。そのため、お客様は常にジャストサイズの構成のVMware EVO:RAILを利用することが可能であり、過剰なリリースを抱える必要はありません。

以上

最適な”ポリシー”の設定~VMware vCenter Operations Manager活用法(最終回)~

こんにちは、VMwareの塚田です。

早いもので、連載「VMware vCenter Operations Manager活用法」も今回(第5回)が最終回です。今回のテーマは、「ポリシーの設定」です。

vC Opsが仮想基盤を正確に分析できるかどうかは”ポリシー”の設定次第

これまでの連載において、VMware vCenter Operations Mangaer(以下、vC Ops)は「仮想基盤にあと何台の仮想マシンを追加可能か?」や「リソースを無駄遣いしている仮想マシンはないか?」などの疑問に答えられる情報を提供する事、そして「リソースの需要予測」を支援する事が可能である事を紹介して参りました。

これらを行うため、vC Opsは仮想基盤を構成するサーバやストレージのリソースの利用状況、仮想マシンの構成等の情報を収集し分析し続けています。その分析を通して、仮想マシンの平均的な構成やリソースの需要や、仮想基盤のリソース使用量の推移を算出しています。

ここで、vC Opsが仮想基盤の情報を収集、分析することについて、次のような疑問が湧いて来ませんか?四半期末毎、または半年に1回のみ起動するバッチ処理専用の仮想マシンがあるのだが、それのCPU使用率やメモリ使用量も織り込んで計算してくれるのだろうか?

  • 四半期末毎、または半年に1回のみ起動するバッチ処理専用の仮想マシンがあるのだが、それのCPU使用率やメモリ使用量も織り込んで計算してくれるのだろうか?
  • CPUとメモリに一時的に高い負荷がかかるバッチ処理を受け持つ仮想マシンの場合、そのような「負荷のピーク」を正しく読み取り、ノイズを排除するような仕組みを持っているのだろうか?
  • 開発環境用仮想マシンはメモリのオーバーコミットを積極的に行い、統合率を上げたい。一方、本番環境用の仮想マシンはオーバーコミットをしたくない。このように相反する方針を両立した仮想基盤のキャパシティ管理ができるのだろうか?

実は、上記のような時々起動される仮想マシンの統計情報を正しく読み取ったり、仮想マシン毎に異なるワークロードを正確に解析したりする事はvC Opsにとって非常に重要です。そうしないと、仮想マシンの平均構成を誤って過少に算出したり、仮想基盤リソースへの需要を過少に見積もってしまったりすることが起きかねません。

また、3番目の疑問も重要です。仮想基盤上で処理されるワークロードは一様でないため、「オーバーコミットをしてもよい仮想マシン」と「オーバーコミットをさせたくない仮想マシン」が同時に存在することも当然あり得ます。

そこでvC Opsでは、仮想マシン毎に異なるワークロードの特性を把握し、それぞれのワークロードの特性に合ったリソースの使用量や容量の見積もりができるようにするための設定、「ポリシー」を定義します。また、CPUやメモリ等のキャパシティ管理を行う際、リソースのオーバーコミットを許容するか否か、許容する場合にはオーバーコミットさせる目標も「ポリシー」で定義可能です。

そして、定義されたポリシーを仮想マシンに関連付けすることにより、それぞれに合った分析を行います。

vC Opsのポシリーの設定する

仮想マシンのためのvC Opsのポリシーを構成する大まかな手順は以下の通りです。

  1. 仮想マシンやESXiホストの分類分けする
  2. 上記の分類ごとに適したvC Opsのポリシーを作成する
  3. 作成したポリシーを仮想マシンやESXiホストへ関連づける
  4. vC Opsによるデータ収集および分析結果を確認する

以下では、vC Opsのポリシー作成の詳細について説明いたします。

仮想マシンやESXiホストを分類分けする

まず、仮想マシンやESXiホストをそれが処理するワークロードや期待される SLAに応じて分類分けします。

下の表に分類分けの例を挙げてみましたのでご参照ください。

本番(バッチ型)

本番(インタラクティブ型)

開発環境

ワークロードの特性

特定の時間帯のみ高い

定常的に高い

業務時間のみ
(平均的には低い)

サービス例 バックアップ、週次・月次レポートなど ウェブサーバー 開発環境
リソース配分 CPUオーバーコミット:低
メモリオーバーコミット:なし
CPUオーバーコミット:中
メモリオーバーコミット:なし
CPUオーバーコミット:高メモリオーバーコミット:あり

ポリシーを作成する

上記で分類した仮想マシンやESXiホストごとに適切なポリシーを作成します。作成するためには、vC OpsのvSphere UIから[設定]→[+]をクリックし、ポリシーの編集ダイアログを表示させます。

vcops_6_fig1

ここでESXiホストや仮想マシンのワークロードに応じたポリシーの作成例を3点ご紹介致します。

ポシリーの作成例1: 本番環境用ESXiホスト向けポリシー

vcops_6_fig2

ポリシーの作成例2:  開発・テスト環境用ESXiホスト向けポリシー

vcops_6_fig3

設定内容の詳細については下の表を参照して下さい。

設定項目

本番環境用ホスト向けポリシー 開発・テスト環境用ホスト向けポリシー
3a. 残り容量と時間 残り容量の算出方法(需要ベース、または割り当てベース) 需要ベース、および割り当てベース双方の方法で残り容量と残り時間を算出するよう全ての項目にチェックを入れる 需要ベースのみをチェックする
[急増とピークを考慮するために負荷を使用します] ピーク時の高負荷を分析に織り込むためチェックを入れる ピーク負荷は考慮しないため、チェックを入れない
3b. 使用可能な容量 [高可用性(HA)構成の使用と容量の縮小] ホストがHAクラスタのメンバーの時にチェックを入れる 同左
バッファとして予約する容量の割合(%) 使用率が100%にならないよう、10〜20%程度をバッファとして確保するよう指定する。負荷変動が大きいホストはバッファを多めに確保する(例:40%) 統合率を上げるため考慮しない(バッファを確保しない)
3c. 使用量の計算 CPUオーバーコミット比 1から2程度に(最大でも4程度) 割り当てベースの残り容量分析を選択した場合のみ設定する。4 以上も設定可能。
メモリのオーバーコミットの割合 オーバーコミットしない場合は0%に 20%程度
ディスク容量のオーバーコミットの割合 同上 同上
4c. 低負荷および高負荷 CPU需要、およびメモリ需要のピークの考慮 ピークとして認識するしきい値を70%程度に設定
ピーク負荷が継続する時間を指定(例:4時間) [全範囲]を選択

ポシリーの作成例3: 仮想マシン向けポリシー

適切なポリシーを設定し、仮想マシンへ関連づけることにより、節約可能なリソースをより正確に算出できるようになります。

vcops_6_fig4

設定大項目

設定項目

設定値、および説明

3b. 使用可能な容量 [高可用性(HA)構成の使用と容量の縮小] チェックしない(仮想マシンには無関係)
バッファとして予約する容量の割合(%) 仮想マシンの需要がCPUやメモリの割り当て値を超えるまでの時間(残り時間)をケインさするために利用。負荷変動が大きい仮想マシンは高め(30% – 50% )に設定
4b. VMが過剰サイズとなる状況 CPU, およびメモリ需要がしきい値 ワークロードが低負荷状態と見なす値を設定(15%程度)
4c. VMが不足サイズとなる状況 CPU, およびメモリの需要のしきい値 需要平均を上回ると見なす値を設定(例:50%以上)
需要平均を超過する負荷が持続する時間 ピーク負荷が持続する時間(1〜8時間程度)を設定

ポシリー設定例4: 統計処理の対象期間の設定

vC Opsは、仮想マシンやESXiホストのリソースの利用状況は需要のデータを分析して仮想マシンの平均的なプロファイルを算出したり、キャパシティ残量を計算したりしますが、その計算対象となるデータの期間をポリシーによって指定することが可能です。これを適切に設定することにより、例えば1ヶ月に1回、または四半期に1回だけ起動されるような仮想マシンの需要や構成も正確に分析することが可能になります。

vcops_6_fig5

非傾向ビューの間隔、および間隔数を調整することにより、過剰サイズVMや過小サイズVMなどの長期的統計を取る期間を設定することが可能です。

デフォルト値は[日単位]および30[間隔]です。すなわち、直近30日間のデータが統計処理の対象です。これは週単位、および52間隔まで設定可能です。すなわち直近1年間のデータを統計処理の対象にすることが可能です。

ポリシーと仮想マシンやESXiホストを関連付ける

最後に、作成したポリシーを管理対象の仮想マシンやESXiホストへ関連付けます。

vcops_6_fig6

 ポリシーによる分析結果を確認する

ポリシーを仮想マシンやホストへ関連付けると、vC Opsはデータを収集し分析を行います。その分析結果が妥当なものかどうか確認してみましょう。

ポリシーが適切であれば、vC Opsが算出する仮想マシンの平均プロファイルや残り容量の計算結果はより正確になります。下の図は、ピーク負荷を考慮しないポリシーを使って分析した結果とピーク負荷を正しく考慮したポリシーを使って計算した結果の差異の例を示しています。

vcops_6_fig7

このように、ポリシーの内容を精査し、それを適切な仮想マシンやESXiホストへ関連づけることはとても重要です。

連載終了にあたり

本連載では、5回に渡りVMware vCenter Operations Managerの活用方法を紹介、提案して参りました。

vC Opsは、仮想基盤を導入したもののそれの有効活用に困ってらっしゃる基盤ご担当者、あるいは限られた人数でより多くの仮想マシンを管理したい運用ご担当者の課題の解決を支援致します。本連載では4つの課題の解決法とポリシーの設定方法をご紹介しました。それらが少しでも皆様の課題解決のお役に立てれば幸いでございます。

連載におつき合いいただきありがとうございました。

~VMware vCenter Operations Manager活用法~
第1回 あとどのくらい仮想マシンを載せられるか?(リソース残量を知る)
第2回 どこにリソースの無駄が発生しているのか!(リソースの無駄の把握と削減)
第3回 より多くの仮想マシンを安全に載せていく(統合率を上げていく)
第4回 将来、物理リソースがどのくらい必要か?(需要予測)
第5回 使用環境における”ポリシー”の設定
vC Ops簡単操作ガイド

仮想基盤のリソース状況を知る! ~vCenter Operations Manager活用法(第3回) ~

こんにちは、VMwareの塚田です。

「vCenter Operations Manager活用法」の連載第3 回のテーマは「統合率を向上させる」です。

サーバ統合率を向上させるための重要な課題

仮想基盤の利用効率を測る基準の一つとして「統合率」があります。これは、仮想基盤上で稼働している仮想マシンの台数を、基盤を構成するESXiホストの台数で割って得られます。すなわち、ESXiホスト1台あたりで動作する仮想マシンの平均台数です。これが高い程、より少ないESXiホストでより多くの仮想マシンを稼働している事を示しており、限られた物理リソースをいかに効率的に活用しているかを測り比較する事が可能です。

当然ながら、統合率は高いに超した事はありません。サーバの台数を最小限に抑えながら可能な限り多くの仮想マシンを作成、稼働させる事ができれば、サーバ統合の見かけ上の効果は大きくなります。しかし、ただ仮想マシンを詰め込めば統合率が上がる訳ではありません。そんな事をすれば、仮想マシンを詰め込み過ぎた結果、仮想マシン間でリソースの競合が発生し、仮想基盤全体の性能が低下する事態、すなわち性能劣化を引き起こしかねません。 また、仮想マシンが稼働するESXiホストにかかる負荷を均衡にすることも重要です。そうしないと、 一部のホストにだけに過剰な負荷がかかり、もうそれ以上の仮想マシンを稼働させられないが、その隣のホストはまだ余裕がある、などという事態が起こり得ます。また、仮想マシンを新たに追加しようにもどのESXiホストで稼働させるのが決めるのに時間がかかってしまう事もよくある事です。結果として、統合率を向上させる事の阻害要因になります。 したがって、統合率を高めるためには下記の2つの要件を満足することが重優です。

  1. 仮想マシン間でのリソース競合が発生しておらず、仮想基盤に性能劣化が生じていないことを常に確認する
  2. ESXiホスト間の負荷の均衡を維持し、稼働マシンを追加させやすい状況を維持する

VMware vCenter Operations Manager(以下ではvC Ops)は、前述のサーバ統合率を高めるための2つの重要な要件を満足する機能を提供し、お客様の仮想基盤の性能劣化を避けながらサーバ統合率を高める事を支援します。

vC Opsを使ったサーバ統合率向上のアプローチ

図1は、vC Ops、およびVMware vSphereの機能を利用してサーバの統合率を向上させるためのアプローチを示しています。すなわち、下記の順にプロセスを進め、そしてそれらを繰り返す事によってサーバ統合率の向上を実現する事が可能です。

vCOps_Blog3_fig1

図1. vC Opsを活用したサーバ統合率向上のアプローチ

  1. vC Opsの「密度」バッジのスコアに基づき、仮想マシンを少し追加する
  2. VMware vSphereの機能であるDRS(分散リソーススケジューラ)により仮想マシンの配置場所を自動的に調整し、仮想基盤の負荷を平準化させる
  3. vC Opsの「ワークロード」バッジをスコアを確認し、仮想基盤全体が過負荷の状態になっていないことを確認する
  4. サーバ統合率が目標とする値に達するまで1.から3.までを繰り返す

以下では、上記の各プロセスをもう少し詳細に説明します。

「密度」バッジから現在のサーバ統合率を把握し仮想マシンを追加する

vC Opsの「効率」バッジの下にある「密度」バッジは、仮想環境の統合率を測定し表示します。その中の「仮想マシン:ホストの比」が、ESXiホストあたりの仮想マシンの台数をあらわします。これの値が目標をとする値を下回っている場合、仮想マシンを少数ずつ追加します。

「密度」バッジを表示するためには、[ダッシュボード]タブ→[効率]→詳細に順にクリックしていきます。

vCOps_Blog3_fig2

図2. 現在のサーバ統合率を確認できる「密度」バッジ

vSphere DRSを使って仮想基盤の負荷を分散させる

仮想基盤を仮想マシンを追加する際、および追加した後、その仮想マシンをどのESXiホストで稼働させるのが最適かを判断する事は決して簡単ではありません。特に、仮想マシンの台数が増えてくるとそれが難しくなってきます。

vSphere DRSは、仮想基盤を構成するESXiホストへ対する仮想マシンからのCPUとメモリの要求状況を監視し、一部のホストに過剰な負荷がかかっている事を検知した場合、仮想マシンを自動的に移行させ(vMotionの実行)、仮想基盤全体で負荷が分散されるよう調整します。

vSphere DRSの詳細については当社ブログの記事をご参照下さい。

「ワークロード」バッジから仮想基盤が過負荷の状態にないことを確認する

上記で述べた通り、統合率を向上させる際にもっとも注意しなければならない事は、仮想基盤全体の性能を劣化させないことです。vC Opsは仮想基盤の健全性を監視し、それが過負荷な状態になっていないかどうか管理者がわかり易く表示します。

vCOps_Blog3_fig3

図3. 仮想基盤に性能劣化が発生していないか確認する事ができる「ワークロード」バッジ

vC Opsの「健全性」バッジの下にある「ワークロード」バッジは、仮想基盤にかかっている負荷の高さを表します。この値が100を超える事は、仮想基盤が提供可能な容量以上の負荷がかかっていて、性能劣化の状態にあることを示しています。つまり、サーバの統合率が高過ぎるのです。

仮想マシンを追加した後、「ワークロード」バッジのスコアが100に達していなければ、仮想基盤にはまだ余力があり、更に多くの仮想マシンを稼働させることが可能です。そこで、上記アプローチの最初に戻って、さらに仮想マシンを追加し、サーバ統合率をもう少し高めてみます。追加された仮想マシンは再度vSphere DRSによって動的に配置されます。仮想マシンの追加後、「ワークロード」バッジのスコアを確認し、それが100に達していなければ更にプロセスを繰り返します。

結果として、仮想基盤の負荷状態(「ワークロード」バッジ)を注意しながら仮想マシンを増やしていくと、目標とするサーバ統合率に達している事でしょう。

このように、vC Opsは仮想基盤の性能を維持しながら、サーバ統合率を少しずつ高めていく事を支援します。その際、難しい負荷状態の計算や仮想マシンの配置場所の決定は全てvSphere,およびvC Opsが自動的に行いますので、管理者は余計な工数を割かれる事もありません。

以上

~VMware vCenter Operations Manager活用法~
第1回 あとどのくらい仮想マシンを載せられるか?(リソース残量を知る)
第2回 どこにリソースの無駄が発生しているのか!(リソースの無駄の把握と削減)
第3回 より多くの仮想マシンを安全に載せていく(統合率を上げていく)
第4回 将来、物理リソースがどのくらい必要か?(需要予測)
第5回 使用環境における”ポリシー”の設定
vC Ops簡単操作ガイド

あとどのくらい仮想マシンを載せられるか(リソースの残量を知る)〜 VMware vCenter Operations Manager活用法(第1回)

こんにちは、VMwareの塚田です。

今週から始まる連載「VMware vCenter Operations Manager活用法」では、VMware® vCenter Operations Manager (vC Ops)の活用ノウハウを具体的に紹介致します。第1回目のテーマは「現在運用中の仮想基盤へ何台くらい仮想マシンを載せられるのか?」です。

リソースの残り容量を把握する事は意外に難しい

仮想基盤を運用されていると、仮想マシンを後何台くらい基盤へ追加できるか?という事を知りたいと思う事が度々あると思います。そのような時、皆さんはどのような方法で調べますか?

真っ先に思い浮かぶのはvCenter Serverのパフォーマンス チャートだと思います。パフォーマンス チャートは、CPU使用率やメモリの使用量、データストアの使用済み容量と空き容量等、仮想基盤のリソースの最新の利用状況を詳細に把握する事を支援してくれます。また、リソースの統計情報を一定期間アーカイブしてくれるので、過去にさかのぼってリソースの利用状況を調べる事も可能です。

しかし、その便利なパフォーマンス チャートも、仮想基盤に追加可能な仮想マシンの台数については何も教えてくれません。それを知るためには、下に挙げるような手順を経て計算するしか方法がありません。

  1. vCenter Serverのパフォーマンス チャートのデータをエクスポートする
  2. エクスポートしたデータを表計算ソフト等へ取り込んで、以下の情報を算出する
    • 仮想基盤上の仮想マシンの平均的な構成(vCPU数、仮想メモリの容量、仮想ディスクの容量、仮想NIC等)
    • 仮想基盤の仮想マシンの平均的なリソース使用量(CPU、メモリ、仮想ディスク、仮想NIC等)
  3. 算出された仮想マシンの平均的な構成とリソース使用量から、残りリソースで平均的な構成の仮想マシンを何台作成可能か算出

いかがですか?結構な工数がかかりそうですね。また、このような複雑な計算を頻繁に行う事も大変そうですね。

このように、「仮想マシンをあと何台作成できるか?」という一見簡単そうな疑問に答えるのも、実際は結構な工数がかかったり、ある程度の知識が必要だったりする事がご理解いただけると思います。

vC Opsは残り容量を常に分かり易く表示

しかし、「基盤全体のパフォーマンスに影響なく仮想マシンを後何台作成できるのか?」、または「仮想基盤の空き容量はどれくらいか?」とは仮想基盤の運用者であれば常に把握しておきたい基本的な情報の一つだと思います。vC Opsを用いれば、このような基本的な情報も手間をかけずに常に把握することが可能です。

vC Opsは、クラスタ全体のリソースの残り容量を次の2つの観点で仮想基盤の運用管理者へ分かり易く伝えます。

vcops_blog_2_fig1

図1. 仮想基盤の残りリソースを「残り時間」(日数)と「残り容量」(台数)で表示

  • 残り時間(日数)
    • CPU、メモリ、ストレージの容量とI/O数、およびネットワークの各種リソースの内、最も早く枯渇するリソースを特定し、それが枯渇するまでの残り時間を「日数」で表示します。
  • 残り容量(作成可能な仮想マシンの台数)
    • 基盤上の仮想マシンの平均的な構成を算出し、残ったリソースから同じ構成の仮想マシンを何台作成する事が可能か「台数」

リソース毎の枯渇時期も予測し、リソース増強計画の作成を支援

また、vC Opsは先ほど挙げた各種リソース(CPU、メモリ、ストレージの容量とI/O数、ネットワーク)それぞれについて詳細な利用状況のレポートも作成、表示します。その内容は以下の通りです。

  • 枯渇するまでの残り時間(日数)
  • 過去のリソース利用状況(過去2週間)
  • 最新のリソース利用状況(今週)
  • 未来のリソース利用状況の予測(来週から 半年先まで)
vcops_blog_2_fig2

図2. リソース枯渇までの残り時間を把握することが可能

これを参照することにより、運用管理者は最も早期に枯渇しそうなリソースを特定することが可能であり、この情報を元に以下のような対策を取る事が可能になります。

  • リソースの追加計画を作成する
  • 日程上、または予算上の都合によりリソース追加が難しい場合は、仮想マシンの構成を見直してリソースを節約する事を計画する

そして、vC Opsはリソースの追加計画の作成を支援する機能、仮想マシンの構成を見直してリソースの節約を支援する機能も備えています。これらについては、今後の連載において紹介致します。

まとめ

vC Opsは、仮想基盤を運用管理する上で把握しておくべき基本的な情報の1つである、リソースの残り容量を常に計算しています。そして、その結果をいつどのリソースが最も早期に枯渇するか、仮想マシンを何台まで作成可能か、というとても分かり易い形式で管理者へ伝えます。

管理者はvC Opsのダッシュボードを見るだけで、いつまでにリソースを増強すべきか計画を練ったり、仮想マシンの構成を見直してリソースの消費量を抑制する事を検討したりする事が可能になります。

次回以降の連載の内容(予定)は以下の通りです。是非お楽しみにして下さい。

仮想基盤のリソース(キャパシティ?)状況を知る!
~VMware vCenter Operations Manager活用法~

第1回 あとどのくらい仮想マシンを載せられるか?(リソース残量を知る)

vC Ops簡単操作ガイド
執筆者:VMware SE 塚田 大輔