ESXi6.0にてFC HBAがダウンする事象について

ESXiのバージョンを5.5から6.0にアップグレードしてから、不定期にHBAのポートがダウンする事象が発生して悩んでいたのですが、最近原因と解決策が判明したのでメモ。

環境

vSphere

vCenter Server 6.5 Update 1 Build 6671409
ESXi 6.0 Update 3 Build 9239799

サーバ

HPE ProLiant BL460c G7

HBA

QLogic PCI to Fibre Channel Host Adapter for QMH2562
FC Firmware version 8.07.00 (90d5)
Driver version 2.1.73.0

事象

不定期にFC HBA のポートがダウンし、path redundancy degradedが発生。
まれに同時にダウンしてAPDが発生。
ダウン前後のvmkernel.logの内容は下記のHuaweiのkbの内容とほぼ合致。
http://support.huawei.com/enterprise/zh/knowledge/EKB1000838419
下記のようなログが出る。

2017-08-09T05:12:38.068Z cpu44:77853)WARNING: qlnativefc: vmhba2(44:0.0): Timeout: Max mbx wait reached.
2017-08-09T05:12:38.068Z cpu44:77853)WARNING: qlnativefc: vmhba2(44:0.0): Mailbox command 0x54 timeout occurred. Issuing ISP abort.
2017-08-09T05:12:38.068Z cpu44:77853)WARNING: qlnativefc: vmhba2(44:0.0): Firmware has been previously dumped (0x4307cc8f3000) -- ignoring request...
2017-08-09T05:12:38.068Z cpu44:77853)qlnativefc: vmhba2(44:0.0): Inside qlnativefcAbortIsp
2017-08-09T05:12:38.068Z cpu44:77853)qlnativefc: vmhba2(44:0.0): Performing ISP error recovery - ha= 0x4307d3a6dc20.
2017-08-09T05:13:08.070Z cpu88:140078)WARNING: qlnativefc: vmhba2(44:0.0): Timeout: Max mbx wait reached.
2017-08-09T05:13:08.080Z cpu37:77853)qlnativefc: vmhba2(44:0.0): FW: Loading via request-firmware...
2017-08-09T05:13:08.158Z cpu30:77853)WARNING: qlnativefc: vmhba2(44:0.0): Firmware dump previously allocated.
2017-08-09T05:13:08.169Z cpu30:77853)qlnativefc: vmhba2(44:0.0): Setting ELS command intercept.
2017-08-09T05:13:08.191Z cpu41:77853)qlnativefc: vmhba2(44:0.0): Enabling PUREX.
2017-08-09T05:13:08.202Z cpu28:77853)qlnativefc: vmhba2(44:0.0): DPORT feature : disabled.
2017-08-09T05:13:08.202Z cpu28:77853)qlnativefc: vmhba2(44:0.0): FAWWN feature : disabled.
2017-08-09T05:13:09.292Z cpu38:77853)qlnativefc: vmhba2(44:0.0): LIP reset occured (f700).
2017-08-09T05:13:09.327Z cpu38:77853)qlnativefc: vmhba2(44:0.0): LOOP UP detected (4 Gbps).
2017-08-09T05:13:10.745Z cpu29:77853)qlnativefc: vmhba2(44:0.0): fcport 2200886639aca5fc (targetId = 0) ONLINE
2017-08-09T05:13:10.780Z cpu29:77853)qlnativefc: vmhba2(44:0.0): fcport 2201886639aca5fc (targetId = 1) ONLINE
2017-08-09T05:13:10.813Z cpu34:77853)qlnativefc: vmhba2(44:0.0): fcport 2210886639aca5fc (targetId = 2) ONLINE
2017-08-09T05:13:10.856Z cpu51:77853)qlnativefc: vmhba2(44:0.0): fcport 2211886639aca5fc (targetId = 3) ONLINE
2017-08-09T05:13:11.346Z cpu28:77853)qlnativefc: vmhba2(44:0.0): fcport 20000425c5e7a5f5 (targetId = 4) ONLINE

トラブルシューティング

HuaweiのkbからInterrupt Remapperを有効化することで解決できそうということはわかりました。
Interrupt Remapperについては過去に推奨値が変わった経緯があり、もともとアップグレード前はInterrupt Remapperがデフォルト無効であるバージョンを利用していましたが、アップデート後にデフォルト有効に変わりました。
Interrupt Remapperは基本的にデフォルト有効で、5.5p10, 6.0p04, 6.0u3 でのみデフォルト無効になっています。
https://kb.vmware.com/s/article/2149592

本環境は6.0U3P07のため、Interrupt Remapperはデフォルトで有効になっています。

esxcli system settings kernel list -o iovDisableIR
Name          Type  Description                                                                                                                                                                                                         Configured  Runtime  Default
------------  ----  ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------  ----------  -------  -------
iovDisableIR  Bool  Disable Interrrupt Remapping in the IOMMU. Not applicable for platforms pre-configured by firmware to use x2APIC (e.g., platforms with > 256 logical processors); for these interrupt remapping is always enabled.  FALSE       FALSE    FALSE 

すでに有効なのでHuaweiのKBには該当せず別事象かと思いきや、動作確認コマンドを試してみたところ、Interrupt Remapperが動作していないことがわかりました。

vsish -e get /hardware/iov/IntrRemappingEnabled
0

正常に動作していれば 1 が返るはずです。
当然、BIOS上でもIntel VT-dは有効になっています。

HPによる数ヶ月に及ぶ長い調査期間を経て、最終的にHBAのドライバ(qlnativefc)のパラメータの変更により問題を回避できるという回答を得ました。
変更内容は下記です。

esxcfg-module qlnativefc -s ql2xenablemsix=0
esxcli system module parameters list -m qlnativefc
Name                        Type  Value  Description                                                                                                                                                                                                                                     
--------------------------  ----  -----  ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ql2xenablemsix              int   0      Set to enable MSI or MSI-X interrupt mechanism. 0 = enable traditional pin-based interrupt mechanism. 1 = enable MSI-X interrupt mechanism (Default). 2 = enable MSI interrupt mechanism.

MSI-X 割り込みではなく、レガシーなピンベースの割り込みを有効化しています。
この状態で確認コマンドを実行すると相変わらず 0 が返りますが、HPに確認したところ、この戻り値は 0 で問題ないようです。
実際この状態でしばらく運用していますが現在のところ問題は発生していません。

考察

ここからは推測ですが、本環境ではInterrupt Remapperは設定上有効ですが、実際は無効になっていると思います。

Intel 55x0 Chipset Errata - Interrupt Remapping Issue
上記はCitrixのKBですが、本環境で使用しているチップセットIntel5520はInterrupt Remapper関連のエラッタが存在し、XenではBIOS上でIOMMUを無効化することが推奨されています。
VMwareのKBではIntel55X0のエラッタに関する記事は存在しないようですが、ESXiでも同様の問題を抱えている可能性はあると思います。
設定上有効化しても動作しないことから、ESXi内部で動作が制限され無効化されているような気がします(完全に推測です)。

Interrupt Remapperが無効になっている場合、ESXiは、MSI/MSI-X割り込みを利用します。
VMwareのKBに下記のような記述があります。

VMware は最近、デバイスMSI/MSI-X 登録をプログラミングすることで ESXi が割り込み移行を実行する場合に一部 I/O デバイスが上手く反応しないという報告を受け取りました。具体的には、一部の I/O デバイスが、ESXi が使用しなくなって無効と見なされるプロセッサのベクトルに割り込み、アラート メッセージが生成され、それに続く影響が発生する場合があります。

本環境で使用しているHBAはおそらく上記の行儀の悪いI/Oデバイスに該当しており、MSI-X割り込みの際、ESXiが認識できない割り込みベクタを指定し、ESXiが処理できず問題が発生していたと思われます。
そのため、HBAドライバで、MSI-X割り込みではなくレガシーなピンベースの割り込みを有効化することで、無効な割り込みベクタが無くなり、事象が改善した、と考えられます。

Web Client 6.5 Enhanced Authentication Plugin が動かないときのトラブルシュート

Web ClientのWindows認証を有効化するために「Enhanced Authentication Plugin (旧Client Integration Plugin)」を導入しているときに、なぜかプラグインが動かずWindows認証のチェックボックスが選択できないことがあります。
f:id:hs_31:20180329124315p:plain

この問題のトラブルシュート方法をまとめました。

1. サービスが起動しているか
プラグインWindowsのサービスとして実行されている必要がありますが、まれに自動起動に失敗していることがあります。
Windowsのサービス一覧で [VMware Cip Message Proxy Service] が起動していることを確認します。
起動していない場合、起動させます。

2. vmware-plugin の名前解決ができるか
通常であればインストール時にhostsに下記のエントリが追加されており名前解決できます。

127.0.0.1 vmware-plugin
::1 vmware-plugin

ping等で名前解決と疎通ができることを確認します。
名前解決できない場合、hostsにエントリを追加します。
疎通できない場合、Windowsファイアウォール等でブロックされていないかを確認します。

3. 該当ポートに通信ができるか
telnet等でプラグインの利用ポート向けに疎通できることを確認します。

telnet vmware-plugin 8094

疎通できない場合、Windowsファイアウォール等でブロックされていないかを確認します。

4. 証明書のエラーがないか
ブラウザでWeb Clientのログイン画面にアクセスし、デバッグコンソールを開き、プラグイン向けのアクセスにてエラーが起きていないかを確認します。
画面はChromeデバッグコンソールのセキュリティタブで証明書エラーが起きている様子。
f:id:hs_31:20180329125453p:plain

これが発生している場合、該当の証明書を許容するために一度 https://vmware-plugin:8094 宛にChromeでアクセスします。
Advanced - Proceed と選択して証明書を許容するようにします。

  • 参考

vCenter 6.5 Enhanced Authentication Plugin Not Working | JonKensy.com
https://communities-gbot.vmware.com/thread/559992

NUMAについて

NUMAについてしょっちゅう調べては忘れているのでまとめておくことにした。
全般的にFrank Denneman氏のブログを大変参考にさせてもらった。

NUMAとは

NUMA (Non-Uniform Memory Access) は、共有メモリ型マルチプロセッサコンピュータシステムのアーキテクチャのひとつ。
プロセッサとメモリの対 (これをノードと呼ぶ) が複数存在し、それらをインターコネクトで接続したものがNUMAと定義される。
共有メモリ型であるので各プロセッサが全ノードのメモリを利用可能である必要があるが、あるプロセッサから見て同一ノードのメモリをローカルメモリ、他ノードのメモリをリモートメモリと呼ぶ。
ローカルメモリへのアクセスは低レイテンシ、高パフォーマンスであり、リモートメモリへのアクセスは高レイテンシ、低パフォーマンスとなる。

f:id:hs_31:20170718150941p:plain

ほとんどのアプリケーションでメモリアクセスはある特定の領域に集中するので、オペレーティングシステムが適切にメモリを割り当てることによって、プロセッサが頻繁に参照する必要のあるデータをアクセスコストの低いメモリに配置し、アクセスコストの高いメモリには頻繁に参照しないデータを配置することができる。
この点に着目したのがNUMAアーキテクチャである。

UMAとは

UMA (Uniform Memory Access) は、NUMA以前から存在する共有メモリ型マルチプロセッサコンピュータシステムのアーキテクチャである。
各プロセッサがバスを共有しており、すべてのCPUが任意のメモリに対して同じ時間でアクセスできるのが特徴である。
UMAは SMP (Symmetric Multi-Processor) とも呼ばれる。

f:id:hs_31:20170718151112p:plain

UMAの場合、CPUはシステムバス (フロントサイドバス) を介してノースブリッジに接続されている。
ノースブリッジにはメモリコントローラがあり、メモリとの間のすべての通信はノースブリッジを通過する必要がある。
すべてのデバイスへのI/Oを管理するI/Oコントローラもノースブリッジに接続されており、すべてのI/Oもノースブリッジを通過する必要がある。
ノースブリッジの内部帯域幅に依存するアーキテクチャのため、UMAのスケーラビリティは限られていた。

NUMAの登場

スケーラビリティとパフォーマンスの向上のためNUMAが登場した。
2003年にAMDは、NUMAをサポートするOpteronをリリースした。
2007年にIntelは、同じくNUMAをサポートするNehalemをリリースした。
CPU間を接続するインターコネクトは、IntelではQuickPath、AMDではHyperTransportと呼ばれる。

NUMAの有効化/無効化とノードインタリーブ

NUMAをサポートするシステムでNUMAを有効化するには、BIOSでノードインタリーブを無効にする必要がある。
逆にノードインタリーブを有効にするとNUMAは無効になる。

f:id:hs_31:20110511214323j:plain

ノードインタリーブとは、RAID0のようにストライピングでメモリに書き込みアクセスを高速化するものである。
これにより、システムはメモリをUMAのように扱うことができる。

f:id:hs_31:20170718151257p:plain

NUMAノード

NUMAを有効化したシステムではNUMAノードという単位が用いられる。
NUMAノードは、物理プロセッサとローカルメモリをひとまとまりにしたグループを表し、基本的にソケット数分のNUMAノードが作られる。
例えば、ソケットあたり4コアのプロセッサを2つ、96GBのメモリを持つシステムの場合、4コア・48GBメモリの2つのNUMAノードで構成される。
NUMAノードは基本的にハイパースレッドを考慮しないので、単純に物理コア数計算となる。
ただし、Intel Cluster-on-DieテクノロジとAMD Opteron (Magny-Cours 以降)は例外となる。
Cluster-on-Die (CoD) は、Intel Haswellアーキテクチャから提供された。
CoDが有効にされると、各プロセッサが論理的に2つのNUMAノードに分割され、NUMAノード数はソケット数の倍になる。

f:id:hs_31:20170718151539p:plain

AMD Magny-Coursは、12コアのCPUを1つ開発する代わりに、実際には6コアのCPU2つを1つのパッケージにまとめたもの。
実体として内部に2つのプロセッサを持っているため、NUMAノード数はソケット数の倍になる。

f:id:hs_31:20170718151655p:plain

キャッシュスヌーピング

マルチプロセッサシステムでは、各コアがキャッシュを保持しており、共有メモリから読み出したデータをキャッシュで保持、更新してメモリに書き戻すことで、遅いメモリへのアクセスの回数を少なくして高速化を実現している。
このため、同じ場所のデータを複数のコアがキャッシュに持っており、一方が更新して書き戻すと矛盾が生じることになる。
これをキャッシュコヒーレンシ問題という。
この問題を解決するために各コアで持っているキャッシュの内容を同期させる必要があり、その方法はキャッシュスヌーピングと呼ばれる。
キャッシュコヒーレンシに影響を与える可能性があるキャッシュ操作が発生すると、キャッシュはこれを他のすべてのキャッシュに対して同期させるようブロードキャストする。
各キャッシュはこのメッセージを確認してそれに対して操作を行う。
キャッシュスヌーピングの方法の1つが前述のCoDである。

キャッシングアーキテクチャ

キャッシュスヌーピングを理解するためにキャッシングアーキテクチャを理解する必要がある。
Sandy Bridge以降のプロセッサ内部はリングバスを使った構造になっている。

f:id:hs_31:20170719110011p:plain

L1、L2キャッシュはコア内部に存在しコアごとに専有されて利用される。
LLC (Last Level Cache)はコアごとにスライスに分割され、各コア用のLLCスライスが存在し、リングバス経由で各コアで共有される。
キャッシュスヌーピングはリングバス経由で行われるが、送信元がプロセッサごとに1つしか存在しないホームエージェントか、コアごとに1つずつ存在するキャッシュエージェントかによって特性が異なる。
Broadwell世代では以下の4つのキャッシュスヌーピングモードがサポートされている。

キャッシュスヌーピングモード

Early Snoop

Early SnoopはSandy Bridgeにて導入された。
以前はこのモードがデフォルトになっていたが、現在は後述のDir+OSBがデフォルトになっている。
各コアごとのLLCに対応したキャッシュエージェント(CBOX)がメッセージを他のキャッシュエージェントに送信したり、全てのエージェントにブロードキャストする。
このモデルは、ブロードキャストトラフィックがNUMAノード間の帯域を消費する可能性があるが、レイテンシは小さくなる。
NUMAを利用する場合、このモードは推奨されない。

Home Snoop

このモードはIvy Bridgeにて導入された。
プロセッサごとに存在するメモリコントローラに結合されたホームエージェントがメッセージを生成する。
メッセージが都度ホームエージェントに行く必要があり、レイテンシが大きくなるが、NUMAノード間の帯域の消費は少なくなる。

Home Snoop with Directory and Opportunistic Snoop Broadcast (Dir+OSB)

このモードはIvy Bridgeにて導入され、Haswellで削除されたが、Broadwellで復活した。
現在はこのモードがIntelの推奨のデフォルトスヌープモードとなっているが、サーバベンダによっては別のモードがデフォルトになっているので注意する必要がある。
このモードはホームエージェントを使用するが、各ホームエージェント内に存在するディレクトリキャッシュを使用し、キャッシュ間の転送のレイテンシを小さくし、またブロードキャストを少なくすることで帯域の消費を少なくする。

Cluster on Die

Dir+OSBは全体的に最高のパフォーマンスを示すが、高度にNUMAに最適化されたワークロードの場合はCoDを検討することが推奨される。
CoDはプロセッサとメモリの組み合わせを更に2つのNUMAノードに分割する。
CoDの構造は下記のようになっている。

f:id:hs_31:20170719111938p:plain

CoDは対応したプロセッサでのみ有効にすることができる。
図のとおりプロセッサ内に2つのグループがあり、それぞれにリングバスおよびメモリコントローラ、ホームエージェントが存在し、それぞれのグループ間はインターコネクトで接続される。
スヌーピングはそれぞれのホームエージェントからHome Snoop with Dirで送信される。
各グループごとに分割されるためレイテンシが小さくなり、また各グループごとにホームエージェントが存在しそれぞれにディレクトリキャッシュを持つためヒット率が高まりブロードキャストが少なくなるので帯域の消費も少なくなる。

NUMAノードへの仮想マシンの割り当て

NUMAシステム上でESXiが仮想マシンにリソースを割り当てる際、ESXiは仮想マシンのvCPU数がNUMAノードに収まるかどうかを確認する。
収まらない場合、仮想マシンは複数のNUMAノードに跨って均等に割り当てられる。
例えば、4コア・48GBメモリの2つのNUMAノードが存在するシステムで、6コア・64GBの仮想マシンを作成する場合、2つのNUMAノードに跨って、1NUMAノードあたり3コア・32GBのリソースが割り当てられる。

ESXiのNUMAの扱い

仮想マシンがパワーオンされると、ESXi内のNUMAスケジューラは、仮想マシンのCPU、メモリの配置を決める。
これはPPD (Physical Proximity Domain)と呼ばれる。
PPDは物理NUMA構成に従って決定される。
仮想マシンから見えるCPU、メモリの配置はVPD (Virtual Proximity Domain)と呼ばれる。
これは、仮想マシンのvCPUの数、cpuid.CorePerSocketの数、preferHT設定によって決定される。
デフォルトでは、VPDはPPDに揃えられるが、cpuid.CorePerSocketが1より大きい場合、複数のPPDに跨るVPDが作成される。
例えば下記は、10コア/4ソケットのシステムに、20コア/2ソケットの仮想マシンを搭載した場合のPPD/VPDの構成である。

f:id:hs_31:20170718151946p:plain

この場合、仮想マシンは20コアのNUMAノードx2で構成されていると考えるため、キャッシュを利用しようとするが、物理的には20コアのうち10コアずつが別のCPUになっているため、
キャッシュミスが頻繁に発生して性能が劣化する (Cache Pollution)。

vCPUのコアとソケット

上記のCache Pollutionの問題があるため、VMware仮想マシンのvCPU構成はコア数は1とし、ソケット数を変更することを推奨している。
コア数を増やす機能が存在する理由は基本的にはソケット数計算で計上されるソフトウェアライセンスに対応するためである。

vNUMA とは

vNUMAとは、NUMAアーキテクチャ仮想マシンのOSに直接意識させる技術。
VMwareは、vSphere5でvNUMAをサポートした。
NUMAシステムではリモートメモリ操作とローカルメモリ操作でパフォーマンスコストに差があるため、複数のNUMAノードに跨ってリソースを割り当てられた仮想マシンの場合、仮想マシンのOS自身がNUMA構成を理解して適切にリソースを利用することがパフォーマンス向上に繋がる。
vNUMAは、ESXiの物理NUMA全体ではなく、仮想マシンに割り当てられているNUMA構造だけを、仮想マシンOSに公開する。
デフォルトでは、vCPUが9以上の場合にvNUMAは自動的に有効になる。
物理コア数が9未満で、vCPUが9未満でも複数のNUMAノードに跨る構成になる場合、この閾値を変更することで、適切にvNUMAが構成されるようにすることができる。
numa.vcpu.min

NUMAとハイパースレッド

デフォルトではNUMAノードの計算は物理コア数で計算され、ハイパースレッドは考慮されない。
ただしアプリケーションの中にはスレッド間で大量のメモリを共有するものがあり、そういう場合、複数のNUMAノードに分散せず単一のNUMAノード内に仮想マシンのリソースを配置するほうが性能が大きく向上する。
その場合、仮想マシンのpreferHTの設定を有効にすることにより、ハイパースレッドを考慮して、物理コア数を超えたNUMAノードを作成することができる。
numa.vcpupreferHT=TRUE
ハイパースレッドがデフォルトで考慮されない理由は、より多くの物理コアを使用することでパフォーマンスを最大化するためである。
ハイパースレッドは物理コアごとに論理的に2つのコアが存在するかのように見せる技術だが、実際は物理コア内のL2キャッシュを共有するため、単純に性能が2倍になるわけではない。
一方独立した物理コアを2つ使えば性能は2倍になるため、デフォルトでは物理コアを使用する仕様となっている。

vNUMAとCPUホットアド

仮想マシンのCPUホットアドが有効になっている場合、仮想マシンのvNUMAは無効になる。
物理的に複数のNUMAノードにまたがっていたとしてもノードインターリーブでのアクセスになる。
CPUホットアドは、使う予定が無ければ有効にすべきではない。

NUMAと透過的ページ共有(TPS)

TPSはセキュリティの考慮から近年のESXiではデフォルトで無効になっている。
有効にした場合、TPSはNUMAノード内でのみ有効となり、NUMAノード間では共有されない。
TPSはソルト値の等しい仮想マシンのメモリを共有するが、デフォルトのソルト値は仮想マシンのUUIDになっているので、仮想マシン内でのみ共有される。
VDIのような環境で複数の仮想マシンでメモリを共有したい場合はソルト値を変更すればよい。
ただし、Windows Vista以降のOSではラージページが採用されており、そもそもラージページはTPS対象外となっている。
ラージページがTPS対象外となるのは、通常のページサイズ(4KB)に比べて大きなサイズ(4MB)でメモリがアサインされるため、メモリ内容が一致するケースが少なく、TPSが効きづらいためである。
そのため、TPSを有効にしてもラージページを使用する仮想マシンにTPSは普段は効かないが、ホストのメモリが枯渇した時には例外的にTPSが効いてくる。
これは、ESXiがラージページを4KBに区切ってTPSを実行してメモリを確保しようとするためである。
また、仮想マシンOSがセキュリティのためにアドレス空間のランダム化(ASLR)や、windows superfetch を使っている場合は、さらにTPSが効きづらくなるので注意する。

NUMA関連の設定まとめ

cpuid.coresPerSocket

仮想CPUソケットあたりのコア数。
デフォルトは1。
変更すると複数のPPDに跨るVPDが生成され、Cache Pollutionを引き起こす可能性があるため、1が推奨。
ライセンスによる制約がある場合は変更は検討する。

numa.autosize

仮想マシンがパワーオンされた時に毎回NUMAノードの配置を自動調整するかどうかの設定。
デフォルトはFALSE。
クラスタに物理コア数の異なるサーバが存在する場合、配置が適切にされない場合があるのでTRUEにする。
その際、numa.autosize.onceをFALSEにする。

numa.autosize.once

仮想マシンが最初にパワーオンされた時にだけNUMAノードの配置を自動調整するかどうかの設定。
デフォルトはTRUE。
クラスタに物理コア数の異なるサーバが存在する場合、配置が適切にされない場合があるのでFALSEにする。
その際、numa.autosizeをTRUEにする。

numa.vcpupreferHT

NUMAノードの計算においてハイパースレッドを考慮するかどうかの設定。
デフォルトはFALSE。
メモリのレイテンシに性能が大きく依存するような仮想マシンの場合、有効にしたほうが性能が向上する場合がある。
一般的なワークロードではFALSEが推奨。

numa.vcpu.min

vNUMAが有効になるために必要な仮想マシンのvCPUの最小数。
デフォルトは9。
物理コア数が9未満で、vCPU数が少ないのに複数の物理NUMAノードに跨ってしまう場合、vNUMA構成を物理NUMA構成に合わせるために適切な値に変更するべき。

ベストプラクティスまとめ

  • 出来るだけ物理NUMAノード1つに収まるように仮想マシンをサイジングすべき
  • キャッシュスヌーピングモードは、大抵の場合Home Snoop with Dir+OSBが最適であるが、NUMAに最適化された環境ならCoDを検討してもよい
  • vCPUホットアドは使うべきではない
  • 仮想マシンのソケット数あたりのコア数は1にすべき
  • 大抵の場合ハイパースレッドは考慮しない設定でよいが、メモリレイテンシに敏感な環境ではハイパースレッドを考慮する設定を検討してもよい

VMware Integrated OpenStack の削除方法

デプロイしたVMware Integrated OpenStackをきれいに削除する方法を調べたら下記のブログが見つかった。

Jahnin's unhandled exceptions!: Uninstall and cleanup VMware Integrated Openstack

Delete all VM's deployed by VIO
Delete all logical switches, edges and firewall rules that have been created in NSXv/Portgroups in dvSwitch
Power off and delete the VIO vApp
Unregister the VIO plugin from vCenter Server
1. Login to the following URL, https://< vcenter server ip/FQDN >/mob/?moid=ExtensionManager
2. Select UnregisterExtension
3. Unregister the following Extensions, com.vmware.openstack.ui, com.vmware.openstack.vcext.instance-xx, org.openstack.compute, org.os.vmw.plugin
4. If the Method Invocation Result is void, the extension has been successfully unregistered.
5. Logout and login back to the vSphere Web Client.

試してみたら自分の環境だとExtension Managerでエクステンションを登録解除するところでXSRFを検知して登録解除ができなかった。
f:id:hs_31:20170626180856p:plain

仕方ないのでPowerCLIでExtensionを登録解除した。
下記のブログが参考になった。
Managing vCenter Plugins with PowerCLI | Jonathan Medd's Blog

vSphere PowerCLI で 上記の function Remove-vCenterPlugin を使って該当のエクステンションを削除すればよい。

CentOS7でzncのインストール

  • バージョン確認
$ cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
  • zncはcentosの標準のyumレポジトリに入っていないのでepelのレポジトリを追加する
$ sudo yum -y install epel-release
$ sudo yum -y install znc
  • zncの初期設定
    • 公式ドキュメントに従ってzncユーザーで実行
    • Listen on port は適当な番号でよいが、6667, 6668 はブラウザで接続拒否されるため他の番号推奨
    • Set up a network は後で実施するので no とする
$ sudo -u znc znc --makeconf
[ .. ] Checking for list of available modules...
[ >> ] ok
[ !! ] WARNING: config [/var/lib/znc/.znc/configs/znc.conf] already exists.
[ ** ]
[ ** ] -- Global settings --
[ ** ]
[ ?? ] Listen on port (1025 to 65534): 1031
[ ?? ] Listen using SSL (yes/no) [no]:
[ ?? ] Listen using both IPv4 and IPv6 (yes/no) [yes]:
[ .. ] Verifying the listener...
[ >> ] ok
[ ** ] Enabled global modules [webadmin]
[ ** ]
[ ** ] -- Admin user settings --
[ ** ]
[ ?? ] Username (alphanumeric): h-sasaki
[ ?? ] Enter password:
[ ?? ] Confirm password:
[ ?? ] Nick [h-sasaki]:
[ ?? ] Alternate nick [h-sasaki_]:
[ ?? ] Ident [h-sasaki]:
[ ?? ] Real name [Got ZNC?]:
[ ?? ] Bind host (optional):
[ ** ] Enabled user modules [chansaver, controlpanel]
[ ** ]
[ ?? ] Set up a network? (yes/no) [yes]: no
[ ** ]
[ .. ] Writing config [/var/lib/znc/.znc/configs/znc.conf]...
[ !! ] This config already exists.
[ ?? ] Are you sure you want to overwrite it? (yes/no) [no]: yes
[ .. ] Overwriting config [/var/lib/znc/.znc/configs/znc.conf]...
[ >> ] ok
[ ** ]
[ ** ] To connect to this ZNC you need to connect to it as your IRC server
[ ** ] using the port that you supplied.  You have to supply your login info
[ ** ] as the IRC server password like this: user/network:pass.
[ ** ]
[ ** ] Try something like this in your IRC client...
[ ** ] /server <znc_server_ip> 1031 h-sasaki:<pass>
[ ** ]
[ ** ] To manage settings, users and networks, point your web browser to
[ ** ] http://<znc_server_ip>:1031/
[ ** ]
[ ?? ] Launch ZNC now? (yes/no) [yes]:
[ .. ] Opening config [/var/lib/znc/.znc/configs/znc.conf]...
[ >> ] ok
[ .. ] Loading global module [webadmin]...
[ >> ] [/usr/lib64/znc/webadmin.so]
[ .. ] Binding to port [1031]...
[ >> ] ok
[ ** ] Loading user [h-sasaki]
[ .. ] Loading user module [chansaver]...
[ >> ] ok
[ .. ] Loading user module [controlpanel]...
[ >> ] ok
[ .. ] Forking into the background...
[ >> ] [pid: 11089]
[ ** ] ZNC 1.6.5 - http://znc.in
# 事前確認
$ sudo firewall-cmd --list-all --zone=public
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens32
  sources:
  services: dhcpv6-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  sourceports:
  icmp-blocks:
  rich rules:

# zncの初期設定で設定したポートを追加
$ sudo firewall-cmd --add-port=1031/tcp --zone=public --permanent
success

# リロード
$ sudo firewall-cmd --reload
success

# ポートが開いたことを確認
$ sudo firewall-cmd --list-all --zone=public
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens32
  sources:
  services: dhcpv6-client ssh
  ports: 1031/tcp
  protocols:
  masquerade: no
  forward-ports:
  sourceports:
  icmp-blocks:
  rich rules:
  • ブラウザで管理画面にアクセス
  • 管理画面でネットワーク(IRCサーバ)を追加
    • [webadmin]-[Networks]で[Add]をクリック
    • [Network Info]を入力
      • [BindHost]は"0.0.0.0"
      • 日本語を使う場合、[Server encoding]は"Parse and send as ___ only"を選択してテキストボックスに"JIS8"と入力する
      • [Save and continue]をクリック
    • [Channels]で[Add]をクリック
      • チャンネルを追加する
  • 管理画面でログモジュールを追加
  • IRCクライアントからzncサーバに接続
    • znc_server_ip:1031
  • その他
    • configの場所
      • /var/lib/znc/.znc/configs/znc.conf
    • ログの場所
      • /var/lib/znc/.znc/moddata/log/ユーザー名/ネットワーク名/チャンネル名/

vSANメンテナンスモードの使い分け

vSANのメンテナンスモードの使い分けについてまとめておく。

モード 説明 用途
アクセシビリティの確保 (ensureObjectAccessibility) デフォルト。
FTT=1以上の仮想マシンのオブジェクトがホスト上に存在した場合、該当オブジェクトは不完全(Absent)になり、ClomRepairDelay(デフォルト60分)経過後に別ホストに移行される。
FTT=0の仮想マシンのオブジェクトがホスト上に存在した場合、該当オブジェクトは即時移行される。
短時間のメンテナンス時に使用
全データの移行 (evacuateAllData) ホスト上のオブジェクトが全て別ホストに即時移行される。移行先となるホストが必要(ホスト3台でクラスタを組んでいる場合は選択不可)。 長期間のメンテナンスや恒久的なホストの停止の際に使用
データの移行なし (noAction) FTT=1以上の仮想マシンのオブジェクトがホスト上に存在した場合、該当オブジェクトは不完全(Absent)になり、ClomRepairDelay(デフォルト60分)経過後に別ホストに移行される。
FTT=0の仮想マシンのオブジェクトがホスト上に存在した場合、該当オブジェクトは不完全(Absent)になり、仮想マシンは停止する。
vSANクラスタ全体を停止する時など移行を考慮せずに停止したい時に使用