Home > Blogs > Japan Cloud Infrastructure Blog > 月別アーカイブ: 2016年7月

月別アーカイブ: 2016年7月

VIB アクセプタンスレベルに関して

VMware 内野です。

VMware では仮想基盤をより安定して運用して頂くために VIB に関してアクセプタンスプログラムという認証プログラムを持っております。今回は VIB に関するご説明とアクセプタンスプログラムに関してご紹介させていただきます。

 

非常に地味ですが、システム選定の際に非常に大切なことですので、ご一読頂ければ幸いです。

 

VIB (VMware Infrastructure Bundle) とは…..

ESXiの構成上するために以下の様なパーツをまとめたファイルを VIB (VMware Infrastructure Bundle) と呼んでおります。

よくある VIB ファイルの構成例:

・ESXiベースイメージ(ESXi Kernel)
・デバイスドライバ
・CIMプロバイダ

特定のハードウェアを認識させる場合、該当のハードウェア専用の VIB ファイルをインストールさせてから動作させる必要が多いため、デバイスドライバの様なイメージで捉えて頂いている方も多いのではないでしょうか。

その為、特定のハードウェアを利用する為に、該当のハードウェアメーカー様が提供されている VIB ファイルを ESXi にインストールするという形なります。Windows のデバイスドライバと同じ考え方だと思って頂ければわかりやすいかと思います。

アクセプタンスレベルの分類

VIB にはデバイスドライバ等、システムを安定的に稼動させるために必要な多くのプログラムが含まれております。デバイスドライバ等、システムにロードされるプログラムの品質が悪いと仮想基盤自体を不安定になってしまう要因となることがございます。

そのような仮想基盤が不安定になってしまう要因を取り除くために品質テスト・動作テストというのが非常に大切になってまいりますが、VMware では下記の 4 つのレベルに分類して品質テスト・動作テストを実施しております。

  1. VMwareCertified
  2. VMwareAccepted
  3. PartnerSupported
  4. CommunitySupported

以下、4 つの項目に関して 1 つずつ説明させていただきます。

“VMware Certified” に関して

VMware Certified レベルは最も厳しい要件です。VMwareCertified レベルの VIB はVMware 社内品質保証テストと完全に同等な詳細なテストが行われます。

この VIB に関する障害調査は VMware 内部で全ての調査等が行われます。

 

“VMware Accepted” に関して

VMware Accepted レベルは、すべての機能を完全に VMware 内部でテストをしている訳ではありません。検証テストは各パートナー様内で実行されており、VMware は各パートナー様内で行われたテスト結果を確認した上で認証しております。

この VIB に関する障害調査は VMware は、各種パートナー企業様のサポート組織と連携して調査を行います。

 

“PartnerSupported” に関して

Partner Supported レベルは、VMware パートナー プログラムに参加している信頼のおける各パートナー様内ですべてのテストが実行されており、VMware はテスト結果を確認しておりません。

この VIB に関する障害調査は VMware は、各種パートナー企業様のサポート組織と連携して調査を行います。

 

“CommunitySupported” に関して

Community Supported レベルは、VMware パートナー プログラムに参加していない個人または企業が作成した VIB になります。

このレベルは VMware が承認したテスト プログラムは行われておりません。

VMware のテクニカル サポートや VMware パートナーによるサポートは受け付けることができません。

 

まとめ

アクセプタンスプログラムは皆様の仮想化基盤の安定稼動を目的としたプログラムです。仮想基盤の新規構築・更新の際には、アクセプタンスレベルも含めてご確認頂きますようお願いいたします。

特に Community Supported レベルの VIB をインストールする必要がある場合は、テクニカルサポートに関しては、ユーザー企業様・販売会社様の自己責任となる可能性があることをご認識の上、ご検討頂ければと思います。

VMware としては、より上位のアクセプタンスレベルの製品 (VIB) を選定して頂きますよう推奨させて頂いております。

[参考ドキュメント]

VIB およびホストの許容レベルについて

内野

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ベースに記載しております。予めご了承ください。

VMware vRealize Operations (vROps) をパワーアップしよう!

2回目:SDDC Management Packs (VSAN/NSX)

– Back Number –
#1…カスタムダッシュボードって難しいの?
#2…SDDC Management Packs (VSAN/NSX)
#3…3rd Party Management Packs (Deep Security)
#4…3rd Party Management Packs (F5/NetApp/UCS)

こんにちは、ソフトバンク コマース&サービスの中川明美です。
2回目は、管理パック「SDDC Management Packs (VSAN/NSX)」についてご紹介します。「Virtual SAN (VSAN)」と「VMware NSX」が盛り上がっていますね!!私も気合いを入れて書きたいと思います。このBlogではVSANの管理パックをインストールしたvROpsを中心に進めます。「vROps+VSAN」運用の参考にしていただければと思います!

◆管理パックの入手方法◆

Solution Exchangeのサイトから、「vRealize Operations」を選択し、管理パックをダウンロードします。下図は、VSANの管理パックをダウンロードする画面です。
ファイル名は、「vmware-MPforStorageDevices-(Build #).pak」です。2016年7月現在の最新バージョンは、「6.0.4-3668305」です。
https://solutionexchange.vmware.com/store

Management-Pack

◆5つのダッシュボード◆

先の管理パックをインストールすると、下図のダッシュボードが追加されます。
VSANを管理するには、メニューの「ダッシュボードリスト」→「MPSD」→「VirtualSAN」を使用します。VSANには5つのダッシュボードがあります。

VSAN

◆”VirtualSAN Troubleshooting”ダッシュボード◆

ダッシュボード名の通り、VSAN全体の問題を確認することができます。
ここからは、当社LabのVSAN環境を例に、画面左の「VirtualSANトポロジ」のオレンジや赤のオブジェクトの原因追究を開始します!!

VirtualSANクラスタを選択
最初にクラスタ全体で問題がないかを確認するために、図1は「VirtualSANクラスタ(赤の点線枠)」を選択しています。この環境は、ESXiホスト6台でクラスタを構成しています。6台のうち4台が、VSAN用のディスクリソースを提供しています。残り2台はコンピュータリソースのみを提供しています。そのため、「アラートリスト」に「VirtualSANホストに誤った設定のストレージがあります(青の枠)」とクラスタに関するアラートが表示されています。

【図1】
Troubleshooting_1

磁気ディスクを選択
図2は、オレンジ表示の「磁気ディスク(赤の点線枠)」を選択しています。画面右で、磁気ディスクの詳細な情報を確認することができます。「使用済みディスクキャパシティ(青の枠)」では、時系列で使用量を追うことができます。80%以上の使用量が続いていますね。

【図2】
Troubleshooting-disk_1

図3は、図2の磁気ディスクを選択した際の「優先度の高い問題(赤の点線枠)」を表示しています。「VirtualSAN磁気ディスクのキャパシティが使用量の限界に近づいています」と問題が表示され、その下には、「ディスクグループに磁気ディスクを追加します」と解決方法が明示されています。青のリンク文字列をクリックすると、磁気ディスクの問題が詳細表示されます。使用量の限界は、80%を超えた時なのですね。

【図3】
Troubleshooting-disk2

磁気ディスクの「オレンジ」や「緑」のオブジェクトを見ながら、「VSANって、リバランスしないのかなぁ?」と疑問がわいてきました。調べてみると、「VirtualSANデータストア」の使用量が80%を超えなければリバランスが起きないそうです。この環境ではデータストアの使用量は80%を超えていないためリバランスが起きません。
参考までに、「Virtual SAN Cluster Insight」ダッシュボードで「コンポーネント数」を確認してみました。図4から、各ESXiホストのコンポーネント数(赤の点線枠)に大きな偏りはないことがわかります。

【図4】
Insights

<結果>
「VirtualSAN Troubleshooting」ダッシュボードで表示された磁気ディスクの問題を解決する方法は、図3の画面で提示されていた「ディスクグループに磁気ディスクを追加する」ですね!

(参考KB)
Virtual SAN Health Service – Physical Disk Health – Disk Capacity
https://kb.vmware.com/kb/2108907

VSAN 6.0以降は、「vsan.proactive_rebalance」コマンドを使用して、手動でリバランスをすることができます。
https://pubs.vmware.com/vsphere-60/index.jsp?topic=%2Fcom.vmware.vsphere.virtualsan.doc%2FGUID-6DC1DCEF-C596-4A11-9DB7-45B119450794.html

◆”VirtualSAN Heatmap”ダッシュボード◆
「データストア」「ストレージコントローラ」「ディスクグループ」「NIC」のスループット等をヒートマップ形式(サイズと色)で表示します。図5では、「VirtualSAN データストア」が大きな赤の四角で表示されています。「サイズのスループット」はデータストアが1つのため大きな四角になっています。「色の遅延」は赤色表示です。ここからは、データストアの問題原因を追究していきます。

【図5】
Heatmap

VSANデータストアのパフォーマンスを向上させる方法の一つは、SSDの追加です。「SSDと最低1本のHDDを追加したディスクグループ」を追加作成します。
SSDの追加がこの環境の問題解決となるのか、収集したデータから分析してみましょう!!

<SSD読み取りキャッシュヒット率>
「VirtualSAN Device Insight」ダッシュボードで、「SSD読み取りキャッシュヒット率(図6:赤の点線枠)」を確認します。高いヒット率です。ここに原因はなさそうです。

ヒット率が著しく低い場合は、「VirtualSAN Entity Usage」ダッシュボードで、「磁気ディスク読み取りスループット(図7:赤の点線枠)」の値や、VSAN上で稼働する仮想マシンのIOを確認します。磁気ディスクへの読み取り値が非常に高く、その高い読み取りが原因で仮想マシンのパフォーマンスに影響を及ぼしているのであれば、SSDの追加は有効です。

<SSDスループット書き込み>
「VirtualSAN Entity Usage」ダッシュボードで、「SSDスループット書き込み(図7:緑の枠)」の値が高く、キャッシュディステージ(HDDへの書き込み)の発生による「磁気ディスク書き込みスループット(図7:紫の枠)」の値が高い場合も、SDDの追加は有効です。今回はいずれの値も高くないため、SSDの追加では解決できなさそうです。

【図6】
Figure6

【図7】
Figure7_1

<結果>
この環境のVSANデータストアのパフォーマンス劣化の原因は、「CPU」です。
VSANはSoftware Defined Storageですから、ESXiホストのCPUを使用して処理します。今回はCPUのパフォーマンスがデータストアの大きな遅延を招いているようです。他に物理NICやストレージコントローラのパフォーマンスにも影響を及ぼしているようです。
問題を解決するには、ESXiホストの追加が必要ですね。
IO-Latency
※Lab環境のESXiホストは、ネストされたESXiホスト(ESXi on ESXi)です。

◆まとめ◆
VSANを監視する際は、「VirtualSAN Troubleshooting」と「VirtualSAN Heatmap」のダッシュボードをおもに活用してみてください。その他の3つのダッシュボードは、根拠となる詳細な数値を確認する場合に適しています。
ストレージは監視する項目や視点が多く、混乱しますね!

vROpsを使用すると、このBlogのように、緑色以外のオブジェクトから始めることができます。VSAN連携では優先度の高い問題と解決方法までを提示してくれます。一つ一つ原因を探していくことと比べると管理工数を抑えることができますね。

このBlogでは、VSANの監視について書きました。機会があればNSXも書いてみようと思います。次回以降の3rdベンダー提供の管理パックについてもお楽しみに!!

nakagawa

ソフトバンク C&Sのサイトで仮想化健康診断の事例を紹介しています。運用のヒントになるかもしれません。

詳細についは、以下↓↓アイコン↓↓をクリックして下さい!
Logo2

VMware vRealize Operations (vROps) をパワーアップしよう!

仮想インフラを効率的に管理する vRealize Operations。vSOM (vSphere with Operations Management)のパッケージをお使いのお客様も増えてきていますが、vRealize Operations の標準ダッシュボードを使って運用されているケースが大半なのではないでしょうか。
しかし、vRealize Operations の上位ライセンスである Advanced を使うことで、より多様なシステム管理を行うことが可能になります。今回は、ソフトバンクコマース&サービスの中川様に、全4回シリーズにてAdvanced の有効な使い方について執筆頂きましたので、掲載を致します。

1回目:カスタムダッシュボードって難しいの?

こんにちは、ソフトバンク コマース&サービスの中川明美です。vRealize Operations (vROps)の「Advanced」エディションで提供される、「ダッシュボードのカスタマイズ」と「管理パック」についてご紹介します。
このBlogでは特に、管理パックで構成されるダッシュボードのデザインに注目してみてください。カスタムダッシュボードを設計する際のヒントになります!
一度に各製品のカスタムダッシュボードを見る機会は多くないと思います。「ダッシュボードを並べてみる」、そんな視点で各メーカーの製品を評価するのもおもしろいですよ。

このBlogは次の4回構成です。

#1…カスタムダッシュボードって難しいの?
#2…SDDC Management Packs (VSAN/NSX)
#3…3rd Party Management Packs (Deep Security)
#4…3rd Party Management Packs (F5/NetApp/UCS)

1回目の「カスタムダッシュボードって難しいの?」を開始します!

◆標準ダッシュボード◆
お客様先で、vRealize Operations (vROps) のワークショップを行う際、「診断リスト」を使用します。たとえば、下図のように仮想マシンのCPU ワークロードが高いアラートが表示されている場合(赤色の点線枠)、「詳細」タブの「ビュー」から、「仮想マシンのCPU 診断リスト」「ホストのCPU 診断リスト」の値を確認しています。リストは「分析」タブからも画面遷移できます。

dashboard

下図は、「仮想マシンのCPU 診断リスト」です。
パフォーマンスに影響を及ぼしている原因を、診断リストから推察します。ここでは「競合」の値がかなり高いですね。「遅延」が発生していると判断できます。リストを右にスクロールすると、遅延がどの「処理待ち」で発生しているかを確認することができます。

CPU_List

◆カスタムダッシュボード◆

CPU の「パフォーマンス」に関わる情報が、一画面で確認できれば便利!!と思いませんか。
下図のカスタムダッシュボードは、「ワークロード(サイズ)」と「IO 待ち時間(色)」で仮想マシンをグループ化した「ヒートマップ」、ヒートマップで選択した仮想マシンの「関連するオブジェクト」と「CPU 関連のメトリック値(準備完了/相互停止)」を表示できるように構成しました。このダッシュボードは、現在のCPU パフォーマンスを監視するために使用します。

heatmap

このダッシュボードから、高いワークロードで IO 待ちが発生している仮想マシンがわかります。「オブジェクトの関係」ではその仮想マシンが配置されているESXiホストを、さらにどのメトリック値が遅延に関わっているかを1つの画面で確認します。
選択された仮想マシン「soldc-dc」は、□(四角)のサイズが大きく、色が緑です。□(四角)の大きさはワークロード(今回はCPU使用率)の高さを表し、 緑はIO待ちが低い状態を表します。またCPU負荷が上がりVM間でCPU競合が起きた際に発生する「準備完了(CPU Ready)」や「相互停止(Co-Stop)」の値も高くないため、高いワークロードの要因は、遅延ではなく、 vCPUの割り当てが少ないのでは?と推測できます。

◆カスタムダッシュボードの作成方法◆

先のダッシュボードを例に、作成方法を説明します。

custom_dashboard_1

作成したカスタムダッシュボードのウィジェットを編集します。

custom_dashboard_2custom_dashboard_3
custom_dashboard_4

ここでは、「オブジェクトの関係」は編集しません。

ウィジェットリストの「表示」で、使用する「ビュー」を合わせて作成します。

custom_dashboard_5
custom_dashboard_6
custom_dashboard_7

各ダイアログボックスで保存します。

再度、ダッシュボードの編集画面で、「ウィジェットの相互作用」の設定をします。この設定で、ヒートマップで選択した仮想マシンのデータが、2つのウィジェットに反映されます。

custom_dashboard_8

設定を保存します。

メニューの「ダッシュボードリスト」から、作成したカスタムダッシュボードを表示します。

custom_dashboard_9

カスタムダッシュボードの作成は難しいですか?思いの外簡単ですよね!
大事なのは、どのデータでダッシュボードを構成したら、得たい情報を素早く入手できるかです。私個人は、標準のダッシュボードに慣れてから、カスタムダッシュボードを作成することをお勧めします。この Blog で例にした通り、標準ダッシュボードで使い勝手を知ってからの方が、役に立つダッシュボードが作成できると思います。
この Blog をきっかけにカスタムダッシュボードの活用にぜひチャレンジしてみてください。次回は、「SDDC Management Packs」をご紹介します。

nakagawa
ソフトバンクC&Sのサイトで仮想化健康診断の事例を紹介しています。運用のヒントになるかもしれません。ぜひ参考にしてください!
◆仮想化健康診断の超活用法◆
https://www.it-ex.com/focus/kasoukashindan/

VSAN Cormac Blog ~ パフォーマンスの監視(VSAN Performance service) ~

VSAN管理者は、これまでVSAN Observer を使用してVSANのパフォーマンスを確認していました。
VSAN Observerは非常に強力なツールですがいくつかの欠点もありました。
たとえば、リアルタイムなパフォーマンスデータは確認できましたが、過去のパフォーマンス統計データを確認することはできませんでした。また、VSAN Observerは個別のツールとして提供されていたため、vSphereweb clientと統合されておらずシングルコンソールでの管理がおこなえませんでした。VSAN Observerは多くのメトリックを提供しますが、大半がエンジニアリングレベルのメトリックとなり、管理者向けのメトリックではありませんでした。また、vCenter Server 上のRVC(Ruby vSphere Console)で実行されるため、vCenter Serverへの影響もありました。

これらの状況をふまえ、VSAN6.2では管理者が容易にVSANのパフォーマンスを確認するための機能として、新たに VSAN Performance service が実装されましたので、ご紹介させていただきます。

VSAN Performance Service は下記の機能を提供します。

 

  • vSphere Web Client への統合

最初のポイントとして、VSAN Performance Service は vSphere Web Client から使用できます。VSAN Observer のように、RVCにログインして手動でサービスを起動する必要はありません。また、管理者が VSAN Performance Service を一度有効に設定するだけで、常にサービスが稼動している状態となります。

vSphere Web Client から、vCenter server のインベントリでクラスタや各ホスト、仮想マシンを選択し、 [ 監視 ] タブの [ パフォーマンス ]  からパフォーマンス統計情報をパフォーマンスチャートで表示できます。

VSAN_PerformanceService_01_cluster-view

 

  • シンプルなメトリック

VSAN Performance Serviceで表示できるメトリックは VSAN Observer と比べて削減されていますが、各メトリックは管理者が活用しやすい項目となっています。

管理者は、ホスト上で実行されている仮想マシンのパフォーマンス情報と、ホストのバックエンド操作のパフォーマンス情報を選択して表示する事ができます。例えば、RAID1(FTT=1)構成の仮想マシンでは、仮想マシンで 500 IOPS の書込み処理が表示される場合、バックエンド操作としては1000 IOPS の書込み処理が表示されます。バックエンド操作ではVMDKがミラーされますので、各レプリカに500 IOPS ずつの書込み処理が行われ、合計1000 IOPS となります。IOPS以外のメトリックとしては、スループット、遅延、輻輳、未処理の I/O があります。

ホストのパフォーマンスビューでは、ディスクグループや個々のディスクに関する、いくつかの追加のメトリックが提供されています。
ディスクグループに関しては、読み取りキャッシュ ヒット率(ハイブリット構成時のみ)や、削除、書き込みバッファの未使用割合などの多くの有益な項目を表示する事ができます。

仮想マシンのパフォーマンスビューでは、各VMDKへの仮想 SCSI IOPS、スループット、遅延などの項目が表示できます。

また、特定のメトリックに関しての内容が不明な場合は、メトリックの横にある WS000030 ボタンをクリックする事でメトリックに関する情報が表示されます。詳細情報の確認の為に AskVMware のリンクも用意されています。

VSAN_PerformanceService_02_perf-serv-vm

VSAN Performance Serviceで表示できるメトリックは、VSANの管理者に頻繁に利用されるものになっています。

 

  • 分散型アーキテクチャ

VSAN Performance Service を設計する上で、vCenter Server へパフォーマンスの影響を与えない事が一つの目標でした。
このため、VSAN Performance Service はVSANの分散型アーキテクチャを採用しています。

パフォーマンスデータは、統計DBに格納されますが、VSAN Performance Serviceが有効化されると、VSANデータストア上に統計DBが1つのオブジェクトとして作成されます。クラスタの中から一台のホストが統計DBを更新するマスターとして選ばれ、クラスタ内の他のホストはマスターへパフォーマンス統計情報を送信します。統計情報は5分間の平均値となります。パフォーマンスグラフを描写する際はvSphere web client が統計DBを参照します。

もうひとつの設計目標は vCenter server に依存しないことでした。vCenter server に何かしらの問題が起こった場合や、新しく vCenter server が展開された場合でも、パフォーマンス統計情報は継続して取得され続けます。

 

  • シングルポイント障害の回避

統計DB はVSANデータストア上に作成されると述べましたが、統計DBに対してもVSANストレージポリシーを適用して高可用性を実現する事が可能です。VSAN Performance Serviceを有効化すると、統計DBオブジェクトに対して、どのVSANストレージポリシーを適用するか聞かれます。

デフォルトのポリシーでは、許容する障害の数は1(FTT=1)として設定されますので、1台のホストに障害が発生した場合でも、パフォーマンス統計情報は継続して取得され続けます。

VSAN_PerformanceService_03_-turn-on-perf-service

また、VSAN Performance Serviceおよび統計DB の状態はヘルスチェックシステムで確認されるため、管理者はサービスに問題が発生した場合にアラートを確認する事が可能です。

下記はクラスタにスプリットブレインが発生したような場合の表示例です。

VSAN_PerformanceService_04_perf-service-health-error

 

  • 履歴情報の利用

最後のポイントとして、VSAN Performance Service では VSAN Observer では利用できなかった、過去のパフォーマンスの履歴情報を確認する事が可能となりました。デフォルトでは、直近1時間のデータが表示されますが、もちろん表示対象とする時間範囲は変更が可能です。

VSAN_PerformanceService_05_perf-service-last

 

特定の期間の情報を確認したい場合は、下記のように時間範囲を指定することができます。

VSAN_PerformanceService_06_perf-service-custom

 


VSAN6.2で実装された VSAN Performance Serviceにより、VSANのパフォーマンスの概要を容易に確認する事が可能となりました。

VSAN Observerは継続して利用可能ですが、我々はこの新たに提供された VSAN Performance Service で、より多くの VSAN上のパフォーマンスデータが確認できるべきであると感じています。皆さんがVSAN Observerで定期的に使用しているフィールドやメトリック等で、VSAN Performance serviceに追加するべきと感じる項目があれば、プロダクトマネージャおよびエンジニアへフィードバックしますのでご連絡ください。

原文: VSAN 6.2 Part 6 – Performance Service

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