JP1はおかげさまで20周年を迎えることができました。今後も皆様のご要望を受けつつ、より使いやすく、皆様の役に立てるような運用管理製品を目指して、エンハンスをしていく所存です。(長江)それでは、今回ご紹介した内容を2015年5月14日に予定しているセミナーでご紹介します。詳しく知りたい!という方に、坂川と長江が今回ご紹介しきれなかった運用管理のコツを詳しくご説明いたします。本社(東京都港区浜松町1-30-5浜松町スクエア13F)参加費:無料(事前登録制)お申込み:http://info.vmware.com/content/APAC_JP_ev_joint_ht皆様のご参加を心よりお待ち申し上げております。皆様こんにちは、VMwareの塚田と申します。EVO:RAILに関連するセッションを取り上げ、より詳細な情報をご紹介致します。EVO:RAILに関連するセッションが複数提供されました。EVO:RAILについて紹介致します。SDDCにおいては、サーバ、ストレージ、ネットワーク等のデータセンター内のハードウェア資源は全てソフトウェアによって仮想化および抽象化され、リソースプールとして利用可能になります。それら仮想化されたリソースの運用管理はソフトウェアやAPIによって自動化され、ビジネス部門やITサービスの利用者からの要求に迅速に応えられようになります。お客様が自社のITインフラをSDDCへ移行させたい、あるいは新規に導入したい、と考えられた時、お客様が取りうる導入方法(アプローチ)は下記の3通りのいずれかであるとVMwareは考えます。Infrastructure(統合インフラストラクチャ)サーバ、ストレージ、およびネットワーク機器が単体シャーシ、またはラック内に工場出荷時に構成済み。ソフトウェアはオプションとして選択可能。特徴は、その用途をSDDC実現のために絞り込み、導入にかかる事前検討や調整の対象を徹底的に削減していることです。その代わり、カスタマイズの自由度が下がったり、拡張性に制限がかかったりするなどのトレードオフが伴いますが、SDDC実現を最優先にしたアーキテクチャであると言えます。EVO:RAILは、2RUのシャーシ内に4台のサーバノードが搭載され、各ノードは次のようなスペックを備えています。1また、下記のソフトウェアが予め組み込まれています。EVO:RAILはサーバノード間の共有ストレージを持っていません。SANによって共有データストアとして使用します。EVO:RAILのための管理用ソフトェアです。Engineで行うことが可能です。EVO:RAILをセットアップをする際は、PCからHTML5対応ブラウザを使って接続すれば開始可能です。Server、VSAN等に関する知識やスキルは必ずしも必要ではなく、インフラのことを意識せず、仮想マシンの作成や運用に専念することが可能です。EVO:RAILの初期化から最初の仮想マシンを作成するまで約15分で完了するデモを紹介していました。EVO:RAILを管理することが可能であり、増設もとても簡単です。メモリ)とストレージそれぞれの容量が自動的に拡張されます。1台あたり100台、仮想デスクトップ(VDI)用であれば仮想マシンを同250台まで作成可能です。アアプライアンスを追加することにより、サーバならば最大400台、仮想デスクトップであれば最大1,000台まで拡張することが可能です。EVO:RAILの説明をして参りましたが、VMwareが「EVO:RAIL」というハードウェア製品を開発し販売するわけではございません。この点はくれぐれもご注意ください。Engine等)を開発し、これのOEM契約を結んだパートナー(以下EVO:RAILパートナー)各社へ提供しています。EVO:RAILアプライアンスを開発し提供します。Micro、およびネットワンシステムズの6社です。EVO:RAIL」を10月1日より販売開始することを発表されました(ネットワンシステムズによる発表資料へのリンク)。EVO:RAILアプライアンスの発表が続くと予想されますので是非お待ち下さい。これを用いる利点を再度まとめてみます。SDDCのための基盤を最速で導入、構築することが可能。EVO:RAILは、SDDCのためのインフラとして求められる性能や信頼性、拡張性を備えながら、複雑性を徹底的に排除しています。セットアップ時に必要な設定項目もIPアドレスや管理者のパスワードなど必要最小限にとどめられています。ハードウェア、およびソフトウェアが相互に密に連携しています。それらのため、導入後最短15分で最初の仮想マシンを起動することが可能なくらい、SDDCを最速で構築することが可能です。Engine”を用います。Server等の仮想化ソフトウェア、そしてサーバやストレージ等ハードウェアに関する知識も必須ではありません。それらの技術に精通した専門家を雇用しづらい組織や、専門家が配置されていない拠点においてもSDDCのための基盤を導入することが可能です。EVO:RAILは最大4台(サーバノードは最大16台)まで拡張することが可能です。増設も非常に容易です。メモリ、HDDやSDD等のリソースが利用できるよう自動的に再構成します。その間も、仮想マシンを稼働させ続けられます。このように拡張が非常に容易なので、必要になった時にリソースを追加することが可能です。EVO:RAILを利用することが可能であり、過剰なリリースを抱える必要はありません。Manager活用法(最終回)~こんにちは、VMwareの塚田です。Manager活用法」も今回(第5回)が最終回です。今回のテーマは、「ポリシーの設定」です。Ops)は「仮想基盤にあと何台の仮想マシンを追加可能か?」や「リソースを無駄遣いしている仮想マシンはないか?」などの疑問に答えられる情報を提供する事、そして「リソースの需要予測」を支援する事が可能である事を紹介して参りました。Opsは仮想基盤を構成するサーバやストレージのリソースの利用状況、仮想マシンの構成等の情報を収集し分析し続けています。その分析を通して、仮想マシンの平均的な構成やリソースの需要や、仮想基盤のリソース使用量の推移を算出しています。仮想マシンはオーバーコミットをしたくない。Opsにとって非常に重要です。しないと、仮想マシンの平均構成を誤って過少に算出したり、仮想基盤リソースへの需要を過少に見積もってしまったりすることが起きかねません。3番目の疑問も重要です。仮想基盤上で処理されるワークロードは一様でないため、「オーバーコミットをしてもよい仮想マシン」と「オーバーコミットをさせたくない仮想マシン」が同時に存在することも当然あり得ます。Opsでは、仮想マシン毎に異なるワークロードの特性を把握し、それぞれのワークロードの特性に合ったリソースの使用量や容量の見積もりができるようにするための設定、「ポリシー」を定義します。CPUやメモリ等のキャパシティ管理を行う際、リソースのオーバーコミットを許容するか否か、許容する場合にはオーバーコミットさせる目標も「ポリシー」で定義可能です。定義されたポリシーを仮想マシンに関連付けすることにより、それぞれに合った分析を行います。Opsのポリシーを構成する大まかな手順は以下の通りです。Opsのポリシー作成の詳細について説明いたします。SLAに応じて分類分けします。下の表に分類分けの例を挙げてみましたのでご参照ください。CPUオーバーコミット:高メモリオーバーコミット:ありポリシーを作成する上記で分類した仮想マシンやESXiホストごとに適切なポリシーを作成します。UIから[設定]→[+]をクリックし、ポリシーの編集ダイアログを表示させます。ここでESXiホストや仮想マシンのワークロードに応じたポリシーの作成例を3点ご紹介致します。使用率が100%にならないよう、10〜20%程度をバッファとして確保するよう指定する。割り当てベースの残り容量分析を選択した場合のみ設定する。仮想マシンの需要がCPUやメモリの割り当て値を超えるまでの時間(残り時間)をケインさするために利用。Opsは、仮想マシンやESXiホストのリソースの利用状況は需要のデータを分析して仮想マシンの平均的なプロファイルを算出したり、キャパシティ残量を計算したりしますが、その計算対象となるデータの期間をポリシーによって指定することが可能です。これを適切に設定することにより、例えば1ヶ月に1回、または四半期に1回だけ起動されるような仮想マシンの需要や構成も正確に分析することが可能になります。非傾向ビューの間隔、および間隔数を調整することにより、過剰サイズVMや過小サイズVMなどの長期的統計を取る期間を設定することが可能です。デフォルト値は[日単位]および30[間隔]です。直近30日間のデータが統計処理の対象です。これは週単位、および52間隔まで設定可能です。直近1年間のデータを統計処理の対象にすることが可能です。ポリシーと仮想マシンやESXiホストを関連付ける最後に、作成したポリシーを管理対象の仮想マシンやESXiホストへ関連付けます。Opsはデータを収集し分析を行います。その分析結果が妥当なものかどうか確認してみましょう。Opsが算出する仮想マシンの平均プロファイルや残り容量の計算結果はより正確になります。下の図は、ピーク負荷を考慮しないポリシーを使って分析した結果とピーク負荷を正しく考慮したポリシーを使って計算した結果の差異の例を示しています。このように、ポリシーの内容を精査し、それを適切な仮想マシンやESXiホストへ関連づけることはとても重要です。Managerの活用方法を紹介、提案して参りました。Opsは、仮想基盤を導入したもののそれの有効活用に困ってらっしゃる基盤ご担当者、あるいは限られた人数でより多くの仮想マシンを管理したい運用ご担当者の課題の解決を支援致します。本連載では4つの課題の解決法とポリシーの設定方法をご紹介しました。それらが少しでも皆様の課題解決のお役に立てれば幸いでございます。連載におつき合いいただきありがとうございました。~こんにちは、VMwareの塚田です。回のテーマは「統合率を向上させる」です。仮想基盤の利用効率を測る基準の一つとして「統合率」があります。これは、仮想基盤上で稼働している仮想マシンの台数を、基盤を構成するESXiホストの台数で割って得られます。ESXiホスト1台あたりで動作する仮想マシンの平均台数です。これが高い程、より少ないESXiホストでより多くの仮想マシンを稼働している事を示しており、限られた物理リソースをいかに効率的に活用しているかを測り比較する事が可能です。当然ながら、統合率は高いに超した事はありません。サーバの台数を最小限に抑えながら可能な限り多くの仮想マシンを作成、稼働させる事ができれば、サーバ統合の見かけ上の効果は大きくなります。仮想マシンを詰め込めば統合率が上がる訳ではありません。そんな事をすれば、仮想マシンを詰め込み過ぎた結果、仮想マシン間でリソースの競合が発生し、仮想基盤全体の性能が低下する事態、すなわち性能劣化を引き起こしかねません。仮想マシンが稼働するESXiホストにかかる負荷を均衡にすることも重要です。一部のホストにだけに過剰な負荷がかかり、もうそれ以上の仮想マシンを稼働させられないが、その隣のホストはまだ余裕がある、などという事態が起こり得ます。仮想マシンを新たに追加しようにもどのESXiホストで稼働させるのが決めるのに時間がかかってしまう事もよくある事です。結果として、統合率を向上させる事の阻害要因になります。したがって、統合率を高めるためには下記の2つの要件を満足することが重優です。Ops)は、前述のサーバ統合率を高めるための2つの重要な要件を満足する機能を提供し、お客様の仮想基盤の性能劣化を避けながらサーバ統合率を高める事を支援します。vSphereの機能を利用してサーバの統合率を向上させるためのアプローチを示しています。下記の順にプロセスを進め、そしてそれらを繰り返す事によってサーバ統合率の向上を実現する事が可能です。Opsの「ワークロード」バッジをスコアを確認し、仮想基盤全体が過負荷の状態になっていないことを確認するサーバ統合率が目標とする値に達するまで1.から3.までを繰り返す以下では、上記の各プロセスをもう少し詳細に説明します。Opsの「効率」バッジの下にある「密度」バッジは、仮想環境の統合率を測定し表示します。その中の「仮想マシン:ホストの比」が、ESXiホストあたりの仮想マシンの台数をあらわします。これの値が目標をとする値を下回っている場合、仮想マシンを少数ずつ追加します。「密度」バッジを表示するためには、[ダッシュボード]タブ→[効率]→詳細に順にクリックしていきます。DRSを使って仮想基盤の負荷を分散させる仮想基盤を仮想マシンを追加する際、および追加した後、その仮想マシンをどのESXiホストで稼働させるのが最適かを判断する事は決して簡単ではありません。仮想マシンの台数が増えてくるとそれが難しくなってきます。DRSは、仮想基盤を構成するESXiホストへ対する仮想マシンからのCPUとメモリの要求状況を監視し、一部のホストに過剰な負荷がかかっている事を検知した場合、仮想マシンを自動的に移行させ(vMotionの実行)、仮想基盤全体で負荷が分散されるよう調整します。DRSの詳細については当社ブログの記事をご参照下さい。「ワークロード」バッジから仮想基盤が過負荷の状態にないことを確認する上記で述べた通り、統合率を向上させる際にもっとも注意しなければならない事は、仮想基盤全体の性能を劣化させないことです。Opsは仮想基盤の健全性を監視し、それが過負荷な状態になっていないかどうか管理者がわかり易く表示します。Opsの「健全性」バッジの下にある「ワークロード」バッジは、仮想基盤にかかっている負荷の高さを表します。この値が100を超える事は、仮想基盤が提供可能な容量以上の負荷がかかっていて、性能劣化の状態にあることを示しています。サーバの統合率が高過ぎるのです。仮想マシンを追加した後、「ワークロード」バッジのスコアが100に達していなければ、仮想基盤にはまだ余力があり、更に多くの仮想マシンを稼働させることが可能です。そこで、上記アプローチの最初に戻って、さらに仮想マシンを追加し、サーバ統合率をもう少し高めてみます。DRSによって動的に配置されます。仮想マシンの追加後、「ワークロード」バッジのスコアを確認し、それが100に達していなければ更にプロセスを繰り返します。結果として、仮想基盤の負荷状態(「ワークロード」バッジ)を注意しながら仮想マシンを増やしていくと、目標とするサーバ統合率に達している事でしょう。Opsは仮想基盤の性能を維持しながら、サーバ統合率を少しずつ高めていく事を支援します。Opsが自動的に行いますので、管理者は余計な工数を割かれる事もありません。Manager活用法(第1回)こんにちは、VMwareの塚田です。Ops)の活用ノウハウを具体的に紹介致します。第1回目のテーマは「現在運用中の仮想基盤へ何台くらい仮想マシンを載せられるのか?」です。リソースの残り容量を把握する事は意外に難しい仮想基盤を運用されていると、仮想マシンを後何台くらい基盤へ追加できるか?という事を知りたいと思う事が度々あると思います。チャートだと思います。チャートは、CPU使用率やメモリの使用量、データストアの使用済み容量と空き容量等、仮想基盤のリソースの最新の利用状況を詳細に把握する事を支援してくれます。リソースの統計情報を一定期間アーカイブしてくれるので、過去にさかのぼってリソースの利用状況を調べる事も可能です。チャートも、仮想基盤に追加可能な仮想マシンの台数については何も教えてくれません。それを知るためには、下に挙げるような手順を経て計算するしか方法がありません。チャートのデータをエクスポートするエクスポートしたデータを表計算ソフト等へ取り込んで、以下の情報を算出する仮想基盤上の仮想マシンの平均的な構成(vCPU数、仮想メモリの容量、仮想ディスクの容量、仮想NIC等)仮想基盤の仮想マシンの平均的なリソース使用量(CPU、メモリ、仮想ディスク、仮想NIC等)算出された仮想マシンの平均的な構成とリソース使用量から、残りリソースで平均的な構成の仮想マシンを何台作成可能か算出いかがですか?結構な工数がかかりそうですね。このような複雑な計算を頻繁に行う事も大変そうですね。このように、「仮想マシンをあと何台作成できるか?」という一見簡単そうな疑問に答えるのも、実際は結構な工数がかかったり、ある程度の知識が必要だったりする事がご理解いただけると思います。Opsは残り容量を常に分かり易く表示しかし、「基盤全体のパフォーマンスに影響なく仮想マシンを後何台作成できるのか?」、または「仮想基盤の空き容量はどれくらいか?」とは仮想基盤の運用者であれば常に把握しておきたい基本的な情報の一つだと思います。Opsを用いれば、このような基本的な情報も手間をかけずに常に把握することが可能です。Opsは、クラスタ全体のリソースの残り容量を次の2つの観点で仮想基盤の運用管理者へ分かり易く伝えます。残り時間(日数)CPU、メモリ、ストレージの容量とI/O数、およびネットワークの各種リソースの内、最も早く枯渇するリソースを特定し、それが枯渇するまでの残り時間を「日数」で表示します。Opsは先ほど挙げた各種リソース(CPU、メモリ、ストレージの容量とI/O数、ネットワーク)それぞれについて詳細な利用状況のレポートも作成、表示します。その内容は以下の通りです。リソース枯渇までの残り時間を把握することが可能これを参照することにより、運用管理者は最も早期に枯渇しそうなリソースを特定することが可能であり、この情報を元に以下のような対策を取る事が可能になります。Opsはリソースの追加計画の作成を支援する機能、仮想マシンの構成を見直してリソースの節約を支援する機能も備えています。これらについては、今後の連載において紹介致します。Opsは、仮想基盤を運用管理する上で把握しておくべき基本的な情報の1つである、リソースの残り容量を常に計算しています。その結果をいつどのリソースが最も早期に枯渇するか、仮想マシンを何台まで作成可能か、というとても分かり易い形式で管理者へ伝えます。Opsのダッシュボードを見るだけで、いつまでにリソースを増強すべきか計画を練ったり、仮想マシンの構成を見直してリソースの消費量を抑制する事を検討したりする事が可能になります。次回以降の連載の内容(予定)は以下の通りです。お楽しみにして下さい。