vSphere環境の管理に便利なツール
vExperts Advent Calendar 2018 - Adventar の 12/5 の投稿となります。
新参vExpertながらアドベントカレンダー初参加させていただきます。
普段使用している/したことがある便利なツールについて紹介します。
すべてフリーのツールですので気軽に利用可能です。
どれもそれほど新しいものでもないので知っている人にとっては常識かもしれませんが、誰かの役に立つことを願ってまとめてみます。
1. RVTools
vCenter経由でvSphere環境の様々な情報を取得して一覧表示してくれるWindows向けのアプリケーションです。
Excelファイルとしてエクスポートすることもできるので、定期的にエクスポートして保存しておくと棚卸しなどで大活躍します。
vSphere環境の管理者はユーザーから「○○○の条件のVMってどれだっけ」とかの調査依頼をよく求められると思いますが、Excelファイル化すればPowerCLI等の知識がなくても簡単に棚卸しができます。
2. vCheck
vCenter経由でvSphere環境の様々な情報を取得し、潜在的な問題が無いかをレポートしてくれるツールです。
実行結果はHTMLファイルとして表示されます。
結果をメール送付させることもできます。
私はこのツールをスケジュールタスクに設定し、定期的にメール送付させるようにしています。
はじめて実行した場合、あまりに多くの問題が出てきて驚くと思います。
3. SexiLog
vSphere環境用にカスタマイズされたELKスタック(Elasticsearch, Logstash, Kibana)です。
ova形式なので、環境にデプロイするだけで即利用可能です。
デプロイ後、ESXiのsyslogの宛先をデプロイしたSexiLogに設定すれば、あらかじめ作られているダッシュボードを使って簡単にESXiのログ解析が可能です。
フリーのvRealize Log Insightのようなイメージです。
基本的にオープンソースのソフトウェアの詰め合わせなので、自分でカスタマイズもできますし、ツールを追加して利用することもできます。
以前担当していた環境では、デプロイしたSexiLogにElastalertを追加インストールして、特定のログが出力されたらアラートを投げるという仕組みを作っていました。
github.com
弱点としてはバージョンが古くメンテナンスされていないことです。
ESXi6.0台では動作することを確認しましたが、今後ESXiのログフォーマットが大きく変わると動かなくなる可能性があります。
4. SexiGraf
SexiLogと同じ作者によるセクシーシリーズ第2弾です。
vCenter経由でvSphere環境のパフォーマンス情報を取得して簡単に見やすいグラフとして表示してくれるツールです。
SexiLogと同じくova形式なので、環境にデプロイするだけで即利用可能です。
デプロイ後、vCenterの認証情報を登録すれば、あらかじめ作られているダッシュボードを使って色々な情報が簡単にグラフとして見られます。
以前vSANの環境を管理していたときによく使っていました。
vCenterのデフォルト機能のvSAN Observerを動作させればより詳細な情報が取得できますが、vSAN ObserverはvCenterへの負荷が高く激重だったので、日常的なパフォーマンス確認はほとんどこちらのツールで見ていました。
普段はSexiGrafやWeb Clientのパフォーマンスモニタ、トラブル時にはvSAN Observer、のように使い分けすると良さそうです。
以上です。
誰かのお役に立てば幸いです。
vExperts Advent Calendar、明日(12/6)は yueisu913 さんの予定です。
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
事象
不定期に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認証のチェックボックスが選択できないことがあります。
この問題のトラブルシュート方法をまとめました。
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のデバッグコンソールのセキュリティタブで証明書エラーが起きている様子。
これが発生している場合、該当の証明書を許容するために一度 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と定義される。
共有メモリ型であるので各プロセッサが全ノードのメモリを利用可能である必要があるが、あるプロセッサから見て同一ノードのメモリをローカルメモリ、他ノードのメモリをリモートメモリと呼ぶ。
ローカルメモリへのアクセスは低レイテンシ、高パフォーマンスであり、リモートメモリへのアクセスは高レイテンシ、低パフォーマンスとなる。
ほとんどのアプリケーションでメモリアクセスはある特定の領域に集中するので、オペレーティングシステムが適切にメモリを割り当てることによって、プロセッサが頻繁に参照する必要のあるデータをアクセスコストの低いメモリに配置し、アクセスコストの高いメモリには頻繁に参照しないデータを配置することができる。
この点に着目したのがNUMAアーキテクチャである。
UMAとは
UMA (Uniform Memory Access) は、NUMA以前から存在する共有メモリ型マルチプロセッサコンピュータシステムのアーキテクチャである。
各プロセッサがバスを共有しており、すべてのCPUが任意のメモリに対して同じ時間でアクセスできるのが特徴である。
UMAは SMP (Symmetric Multi-Processor) とも呼ばれる。
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は無効になる。
ノードインタリーブとは、RAID0のようにストライピングでメモリに書き込みアクセスを高速化するものである。
これにより、システムはメモリをUMAのように扱うことができる。
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ノード数はソケット数の倍になる。
AMD Magny-Coursは、12コアのCPUを1つ開発する代わりに、実際には6コアのCPU2つを1つのパッケージにまとめたもの。
実体として内部に2つのプロセッサを持っているため、NUMAノード数はソケット数の倍になる。
キャッシュスヌーピング
マルチプロセッサシステムでは、各コアがキャッシュを保持しており、共有メモリから読み出したデータをキャッシュで保持、更新してメモリに書き戻すことで、遅いメモリへのアクセスの回数を少なくして高速化を実現している。
このため、同じ場所のデータを複数のコアがキャッシュに持っており、一方が更新して書き戻すと矛盾が生じることになる。
これをキャッシュコヒーレンシ問題という。
この問題を解決するために各コアで持っているキャッシュの内容を同期させる必要があり、その方法はキャッシュスヌーピングと呼ばれる。
キャッシュコヒーレンシに影響を与える可能性があるキャッシュ操作が発生すると、キャッシュはこれを他のすべてのキャッシュに対して同期させるようブロードキャストする。
各キャッシュはこのメッセージを確認してそれに対して操作を行う。
キャッシュスヌーピングの方法の1つが前述のCoDである。
キャッシングアーキテクチャ
キャッシュスヌーピングを理解するためにキャッシングアーキテクチャを理解する必要がある。
Sandy Bridge以降のプロセッサ内部はリングバスを使った構造になっている。
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の構造は下記のようになっている。
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の構成である。
この場合、仮想マシンは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構成に合わせるために適切な値に変更するべき。
ベストプラクティスまとめ
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を検知して登録解除ができなかった。
仕方ないので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)
$ sudo yum -y install epel-release
- zncのインストール
$ 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
- ファイアウォールの設定でzncの接続ポートを開ける
# 事前確認 $ 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:
- ブラウザで管理画面にアクセス
- zncの初期設定で設定したURL(http://znc_server_ip:1031/)
- 管理画面でネットワーク(IRCサーバ)を追加
- [webadmin]-[Networks]で[Add]をクリック
- [Network Info]を入力
- [BindHost]は"0.0.0.0"
- 日本語を使う場合、[Server encoding]は"Parse and send as ___ only"を選択してテキストボックスに"JIS8"と入力する
- [Save and continue]をクリック
- [Channels]で[Add]をクリック
- チャンネルを追加する
- 管理画面でログモジュールを追加
- [Global Settings]-[Global Modules]で[log]のチェックボックスをオンにする
- [save]をクリック
- IRCクライアントからzncサーバに接続
- znc_server_ip:1031
- その他
- configの場所
- /var/lib/znc/.znc/configs/znc.conf
- ログの場所
- /var/lib/znc/.znc/moddata/log/ユーザー名/ネットワーク名/チャンネル名/
- configの場所
toeic 2017/03の結果
2017/03のtoeicの結果が発表になりました。
770点でした。(L:355、R:415)
リーディングが良くてリスニングが足を引っ張っているアジア人らしい点数でした。
