Home > Blogs > Japan Cloud Infrastructure Blog

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

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
VOA

 

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のサイトで仮想化健康診断の事例を紹介しています。運用のヒントになるかもしれません。ぜひ参考にしてください!
◆仮想化健康診断の超活用法◆
http://www.it-ex.com/focus/techinfo/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ベースに記載しております。予めご了承ください

 

VSAN 6.2 監視ホスト(Witness)の再配置

VSAN 6.2 監視ホスト(Witness)の再配置

この操作は、VSANストレッチクラスタ環境/2ノードVSAN環境で監視ホストを変更する際に行います。具体的には、VSANストレッチクラスタ環境/2ノードVSAN環境を、VSAN 6.1からVSAN 6.2 にアップグレードする際に必要な手順となります。1点気を付けなければいけないのは、クラスタ内のディスクグループとして、オンディスクフォーマットと同一バージョンの監視ホストを使用しなければいけないことです。タスクを要約すると以下のようになります。

1.新しい監視ホストの展開
2.VSANストレッチクラスタ/2ノードVSAN環境を管理しているvCenterに登録されているESXiホストに監視ホストを追加
3.現在のVSANストレッチクラスタ、2ノードVSANを無効化
4.同じ2台のホスト(優先フォールトドメイン、セカンダリフォールトドメイン)、および新しい監視ホストを選択しストレッチクラスタ/2ノードVSAN環境の再構成
5.健全性画面からデータを選択し、オブジェクトをただちに修復するをクリック(そうしないと、新しい監視ホストによるリビルド処理が実行されるまで、60分(デフォルト値)待たなければいけなくなる。)

以下はより詳細なステップです。

・新しい監視ホストの展開

VSANストレッチクラスタ環境では、L3を超えて監視ホストとVSANを構成する物理ホストが通信する必要があり、そのために監視ホストと物理ホスト間の通信のために静的ルートを追加する必要があります。この手順はVSANストレッチクラスタガイドで記載されています。

・VSANを管理しているvCenterに監視ホストを新たに追加

インベントリ内に2台の監視ホストを確認できます。(オリジナルと新しいもの)
.19の監視ホストが新しく展開されたもので、.26が置き換えられる現在のものです。

・既存構成を無効化

監視ホストを削除するために、Cluster>Manage>Virtual SAN>Fault Domain and Stretched Cluster(日本語UIでは、クラスタ>管理>Virtual SAN>フォールトドメインおよび拡張クラスタ)を選択します。
現在の監視ホストである.26を選択します。右側のウインドにあるDisableボタンをクリックします。その後、
Yesをクリックすることで監視ホストを削除することができます。

disable-stretched-cluster

ここでのポイントは、一旦監視ホストを削除すると、全ての監視ホストコンポーネントがAbsent状態となり、何らかのオブジェクトに対するクエリ、もしくは健全性チェックが実行されると、それらの操作は失敗します。

witness-health-issues

・新しい監視ホストの再構成

新しい監視ホストを選択して、ストレッチクラスタ/2ノードVSAN構成の再構成を行います。最初のステップはフォールトドメインの再構成です。元のフォールトドメイン構成が確認可能であるため、単にセカンダリという名前で作成されているフォールトドメインを、セカンダリフォールトドメインに移動すれば良いだけの簡単な手順です。

3.-reconfigure-DFs

次に、新しい監視ホストを選択します。ここでは.26ではなく、新たに展開した.19の監視ホストを選択します。残りのステップでは、ディスクグループを作成するなど、最初に監視ホストの設定を行うのと同じ作業を行います。

4.-new-witness

・オブジェクトをただちに修復

構成が完了した後は、健全性のテストを行います。デフォルトでは60分後にオブジェクトは自動的に修復されますが、その間はリスクが高い状態である(他の問題が発生すると、VMにアクセスできなくなる可能性がある)ため、オブジェクトをただちに修復を行うことをお勧めします。これによりAbsent状態の監視ホストの修復を迅速に行うことができます。再度テストを実行すると、可用性が低くなっているオブジェクトの数は減少し、健全なオブジェクトは増加します。

5.-repair-objects-immediately

全てのオブジェクトが健全な状態となったら、監視ホストの置き換えプロセスは完了です。

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

VSANにおける SSDの役割

本blogは VMware Storage Business UnitのCormac Hogan Blog の翻訳になります。VSANをより深く知っていただき活用していただく為、本記事の翻訳がお役に立てば幸いです。
最新のVSAN 6.2では「ハイブリッド」と「オールフラッシュ」2つの方式のがありますが、本記事はハイブリッド方式の記事となります。

★SSDにおける役割

VSAN 内における SSD は、リードキャッシュとライトバッファとして作用します。これは VSAN データストア上で実行される仮想マシンのパフォーマンスが向上させます。

VSAN はストレージ市場における SSD と HDD を備えた”ハイブリッド”ストレージと比較されますが、パフォーマンス向上だけでなく、キャパシティのスケールアウトも特徴として兼ね備えています。それでは VSANにおけるリードキャッシュとライトバッファについて話を進めていきましょう。

★リードキャッシュ★

リードキャッシュは、頻繁にアクセスするディスクブロックのリストを保持します。これは、キャッシュヒット時に、I/Oリード遅延を削減することができます。

VSAN において興味深いのは、アプリケーションが読み取られている実際のブロックが、仮想マシンが実行されているESXiホストにないかもしれない、ということです。

言いかえると、仮想マシン自体はあるESXiホスト上で動いておりますが、その仮想マシンのストレージオブジェクトは、それとは異なるESXiホスト上にあってもよい、ということです。

ストレージオブジェクトが異なる ESXi 上に分散している際、該当するブロックが VSAN クラスタ内の別 ESXi ホストのリードキャッシュにあるかどうか探します。キャッシュミスがある場合、データは HDD から直接取り出されます。

VSAN はリードキャッシュがヒットしやすいように常に同じレプリカを読み取るようにします。つまり、クラスタ内どこか1つのノードでキャッシュされます。キャッシュスペースは比較的高価ですので、このメカニズムがキャッシュ利用効率を最適化してます。

★ライトバッファリング★

ライトキャッシュは、不揮発性ライトバッファとして動作します。アプリケーションからの書き込みは、SSDに書き込まれた際 ACKを返します。 もちろんこの動きは書き込み時の遅延予防となります。

SSDに書き込むので、 ハード障害時に備えて VSAN クラスタ内のどこかにデータコピーがある必要があります。

ポリシーによって、VSANに展開される仮想マシンはコピーを持たせることができます。これは、ライトキャッシュコンテンツも含みます。

アプリケーションによって書き込みが開始されると、”オーナー”であるホストのライトキャッシュに書き込むのと同時に、レプリカのあるリモートホストのライト キャッシュにも書き込まれます。

書き込まれたキャッシュデータは、他のホストでもコピーを保持しているので、ホスト障害が起きた際も安心です。その後、SSDに書き込まれたキャッシュデータは、一定の間隔で、HDDにデステージされます。

他のフラッシュソリューションと同様、VSANは可能な限り最高のパフォーマンスを提供します。

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

VSAN Cormac Blog 〜 障害が発生したディスクのコンポーネントのメタデータ健全性 〜

〜 障害が発生したディスクのコンポーネントのメタデータ健全性 〜

最近、VSANの健全性チェックでコンポーネントのメタデータ健全性障害が発生するケースがあります。
以下のようなメッセージが表示される現象です。

component-metadata-health

最初に確認すべきことは、KB2108690に記載されている以下の内容です。

ノート:この健全性チェックテストは、デステージングのプロセスが遅い(多くの場合はVSANがストレージデバイス上に物理ブロック割り当てを行う必要があるような高負荷状態)場合に、この事象が断続的に発生することがあります。この事象に対するワークアラウンドは、ディスク負荷が高くなるようなアクティビティ(複数の仮想マシンを展開する等)が完了した後に、再度健全性チェックを実行することです。

もし健全性チェックで再度障害が表示されるようであれば、表示される情報は正しく物理ディスクに何らかの問題があるのかもしれません。もし健全性チェックが成功するようであれば、上記アクティビティが原因で発生していた事象でありメッセージは無視しても問題ないでしょう。

それを念頭おいて、どの物理ディスクが潜在的な問題を抱えているのかを確認していきましょう。
上記の障害では、コンポーネントのUUIDを表示していますが、顧客がUUIDと物理ディスクを引き合わせるのは非常に困難です。
現時点で、この確認をするにはRVC(Ruby vSphere Console)を利用する必要があります。では、障害として表示されたコンポーネントのUUIDが、どの物理ディスクに対応しているのかを確認する方法を見ていきましょう。

最初に、健全性チェックで障害と表示されたコンポーネントのUUIDを引数に指定してvsan.cmmds_findコマンドを実行します。いくつかの先行して表示されるカラムは見やすくするために削除して表示しています。コマンドは、クラスタオブジェクト(0を指定)に対して実行しています。

vsan.cmmds_find-1

ここでディスクUUIDを確認できたので、それを次に実行するコマンドの引数として使用します。
ここでもいくつかのカラムを見やすくするために削除して表示しています。

vsan.cmmds_find-2

上記出力結果のdevNameフィールドで、該当物理ディスクのNAA ID(SCSI ID)を確認できました。
健全性チェックテストで問題が発生した際に、上記手順を参考にして物理ディスクの特定を行って下さい。

※現在、この情報をKBとして掲載するためのリクエストを行っています。

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

VSAN Cormac Blog 〜 管理クラスタを含んだVSANデータストアの復旧シナリオ〜

〜管理クラスタを含んだVSANデータストアの復旧シナリオ〜

こちらのポストでは、管理クラスタが含まれているVSANデータストアに障害が発生した際の復旧方法についてご紹介させて頂きます。

我々のLabにあるサーバの一台で興味深い事象が発生しました。4ノードのクラスタの1台のホストで、そのホスト上のストレージがVSANデータストアとして利用出来なくなるというトラブルです。VSANには自動復旧させる機能が実装されているので、障害が発生した際には可能な限り多くのVMを再保護しようとします。しかしVSANデータストアの容量が限界になった時に発報されるWarningを無視したことによって、VSANデータストアを失う羽目になりました。このVSAN環境は私たちの管理クラスタとしての機能も含まれていて、vCenter Server、DNS/AD及び、VDPやView等の他のアプリケーションも配置されています。

こちらがその際に出力されたWarningです。
注:ホスト障害を対処する為に十分な容量がないことを示しています – 全てのVMを再保護する為には、120%の利用可能なストレージ容量が必要。(今後、この警告を無視してはいけない)

limits-failure

掻い摘んでお話しますと、容量を増やして当初のVSANの問題は解消され、次に仮想マシンを起動させる必要がありました。vCenterサーバやDNS/ADサーバなどの仮想マシンのvmware.logを調査することによって、仮想ディスクが容量不足になっていることを確認できました。もちろん、その仮想マシンがディスクを使い果たした時にはサスペンドされますが、これはデータストア上の仮想マシンの通常の動きであり、VSANに限ったお話ではありません。

2016-04-17T09:50:05.280Z| vmx| I120: Msg_Question:
2016-04-17T09:50:05.280Z| vmx| I120: [msg.hbacommon.outofspace] There is no \
more space for virtual disk mgmt-vc01.rainpole.com_6.vmd
2016-04-17T09:50:05.280Z| vmx| I120: ----------------------------------------
2016-04-17T09:50:25.278Z| vcpu-0| I120: Tools: Tools heartbeat timeout.
2016-04-17T09:54:05.650Z| vmx| I120: Timing out dialog 1510834
2016-04-17T09:54:05.651Z| vmx| I120: Vigor_MessageRevoke: message \
'msg.hbacommon.outofspace' (seq 1510834) is revoked
2016-04-17T09:54:05.651Z| vmx| I120: MsgQuestion: msg.hbacommon.outofspace reply=0
2016-04-17T09:54:05.687Z| vmx| I120: Msg_Question:
2016-04-17T09:54:05.687Z| vmx| I120: [msg.hbacommon.outofspace] There is no \
more space for virtual disk mgmt-vc01.rainpole.com_6.vmd
2016-04-17T09:54:05.687Z| vmx| I120: ----------------------------------------
2016-04-17T09:58:06.664Z| vmx| I120: Timing out dialog 1510835

その時点でvCenterにアクセスすることが出来ませんでしたので、このメッセージに対してどのように対応すればいいのかを検討し、CLIコマンドである、”vim-cmd”コマンドを実行してみることにしました。AD/DNSサーバ(dc01.rainpole.com)から始めてみます。最初にVM idが必要になりますので、ESXi上に配置されているVM idを以下のコマンドで確認します。

[root@esxi-hp-01:~] vim-cmd /vmsvc/getallvms
Vmid            Name                                                 
15     vVNX                     [vsanDatastore] ...
16     vdp-01.rainpole.com      [vsanDatastore] ...
20     dc01.rainpole.com        [vsanDatastore] ...
22     appvolmgr.rainpole.com   [vsanDatastore] ...
24     HCIBench                 [vsanDatastore] ...

次に、以下のコマンドでVMにメッセージが表示されていないか確認します。

[root@esxi-hp-01:~] vim-cmd /vmsvc/message 20 
Virtual machine message 6034178:
There is no more space for virtual disk \
dc01-rainpole.com.vmdk. You might be able to continue this \
session by freeing disk space on the relevant volume, \
and clicking Retry. Click Cancel to terminate this session. 
   0. button.retry (Retry) [default]
   1. button.abort (Cancel)

次のコマンドで、出力されているメッセージを対処します。注:メッセージ id 6034178に対して、”0″(0. button.retry (Retry) [default])を実行。問題なく処理できたことが確認出来ます。

[root@esxi-hp-01:~] vim-cmd /vmsvc/message 20 6034178 0
[root@esxi-hp-01:~]

引続き、メッセージが残されているか確認してみます。もしメッセージが表示された場合は新しいメッセージidを使い、もう一度同じコマンドを実行する必要があります。注:必要に応じて何回か繰り返します

[root@esxi-hp-01:~] vim-cmd /vmsvc/message 20
Virtual machine message 6034179:
There is no more space for virtual disk \
dc01-rainpole.com.vmdk. You might be able to continue this \
session by freeing disk space on the relevant volume, and \
clicking Retry. Click Cancel to terminate this session. 
   0. button.retry (Retry) [default]
   1. button.abort (Cancel)
[root@esxi-hp-01:~] vim-cmd /vmsvc/message 20 6034179 0
[root@esxi-hp-01:~] vim-cmd /vmsvc/message 20 
Virtual machine message 6034180:
There is no more space for virtual disk \
dc01-rainpole.com.vmdk. You might be able to continue this \
session by freeing disk space on the relevant volume, and \
clicking Retry. Click Cancel to terminate this session. 
   0. button.retry (Retry) [default]
   1. button.abort (Cancel)
[root@esxi-hp-01:~] vim-cmd /vmsvc/message 20 6034180 0
[root@esxi-hp-01:~] vim-cmd /vmsvc/message 20 
No message.
[root@esxi-hp-01:~]

全てのメッセージに対処し、最終的にはメッセージが出力されなくなります(”No message.”)。次は同様の方法でvCenterサーバを起動させます。vCenterサーバが起動したら各種クライアントから接続し、未解決の問題に対応します。

 

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

VSAN Cormac Blog 〜手動・自動モードについて〜

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

VSAN クラスタの作成は、DRS / vSphere HA クラスタを作成する方法とほぼ同様にできてしまいます。まず、vSphere  HA/DRS クラスタを予め作成、VSAN クラスタを有効にしてからESXiホストを追加することもできますし、最初にESXiホストをクラスタに登録し、その後 VSAN を有効にすることもできます。

VSAN クラスタ :  vsanDatastore を構成するESXi群を指します。

VSAN 機能を有効にすると、手動または自動(デフォルト)の選択画面が表示されます。VSAN がESXiホストの空ディスクを検出し、自動的にVSANにクラスタに追加、もしくは手動でディスクを選択しVSANクラスタに追加することも可能です。

手動モード

VSANクラスタ作成時に手動モードを選択すると、VSAN クラスタ自体は作成されますが、HDDが選択されてないので、vsanDatastoreの容量は0です。 手動モードでは、管理者がESXiホストごとに「ディスクグループ」を作成します。ディスクグループには最大7つのHDD(キャパシティ用途)と1つのSSDディスク(キャッシュ用途)を追加する必要があります。

図1

 

ディスクグループの概念として、ストレージコンテナー(器)として考えることができます。 vsanDatastore のサイズはキャパシティ用途のHDD容量によって決まります。 SSDは、リードキャッシュ機能およびライトバッファとして使われるため、VSAN データストアの容量に含まれません。

VSAN クラスタの拡張時、手動モードで設定されたVSAN クラスタに ESXiを追加する場合、そのESXi ホストからローカルストレージが自動的に VSAN データストアに追加されません。 管理者は手動でディスクグループを作成し、ディスクグループにディスクを追加する必要があります。

 

自動モード

自動モードが選択されている場合、各 ESXi ホスト上の空HDDとSSDを自動的に検出し、各 ESXi ホスト上にディスクグループを構築します。

各ディスクグループにつき1つのSSDが必要になるので、もし各 ESXi ホストに複数SSDがある場合、各 ESXi ホストには複数のディスクグループが作成されます。VSANデータストアが作成されると、VSANクラスタを構成しているメタデータ部分を少し差し引いたHDDの容量がvsanDatastoreのサイズとして反映されます。

VSANクラスタに新しいESXiホストが追加される場合、 ESXi ホストにある使われていないストレージは自動的に VSAN に検出され ディスクグループが作成されます。

最後にディスクグループの最大構成情報 (VSAN 6.2)になります。

-最大 5 ディスクグループ / ESXiホスト
-最大 7 HDD (キャパシティ用途) / ディスクグループ
-最大 1 SSD (キャッシュ用途) / ディスクグループ

VSAN 最大構成詳細に関しては、こちらを参照ください。

原文:Manual or Automatic Mode
VSAN Cormac Blog 日本語版 Index