データストアへのアクセスが遅い on ESXi6.0
少し前にESXi5.1からESXi6.0u1へアップデートしました。
(インストールの方法としては、新規インストールというかたちで）
アップデート後に気になった点として、データストアへのアクセスが遅く感じました。
特に書き込みの面で顕著な気がします。
ESXi6.0がリリースされてから、しばらく時間がたっていますので
事例がないかなと調べてみたらありました。
結論としては、HPのドライバに問題がありそうとのこと。
自宅ではHP製のサーバを利用しているということもあり、
ESXiインストール時には、HPのカスタムイメージを利用しています。
※ちなみに下記からダウンロードしています。
HP製サーバに必要なドライバが組み込まれているので楽です。
HP and VMware’s infrastructure as a service solution | Hewlett Packard Enterprise
どうも、最近のバージョンのカスタムイメージに含まれている
アレイコントローラドライバが良くないようです。
自分が利用した「vSphere 6.0 U1 Nov 2015」というカスタムイメージには
HP製の下記ドライバが組み込まれています。
[XXXX@XXXX:~] esxcli software vib list | grep He char-hpcru 6.0.6.14-1OEM.600.0.0.2159203 Hewlett-Packard PartnerSupported 2016-01-02 char-hpilo 600.9.0.2.8-1OEM.600.0.0.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hp-ams 600.10.3.0-15.2494585 Hewlett-Packard PartnerSupported 2016-01-02 hp-build 600.9.4.34-2494585 Hewlett-Packard PartnerSupported 2016-01-02 hp-conrep 6.0.0.1-0.0.13.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hp-esxi-fc-enablement 600.2.4.6-2494585 Hewlett-Packard PartnerSupported 2016-01-02 hp-smx-provider 600.03.09.00.15-2768847 Hewlett-Packard VMwareAccepted 2016-01-02 hpbootcfg 6.0.0.02-01.00.11.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hpnmi 600.2.3.14-2159203 Hewlett-Packard PartnerSupported 2016-01-02 hponcfg 6.0.0.04-00.13.17.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hpssacli 2.30.6.0-6.0.0.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hptestevent 6.0.0.01-00.00.8.2159203 Hewlett-Packard PartnerSupported 2016-01-02 scsi-hpdsa 5.5.0.46-1OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2016-01-02 scsi-hpsa 6.0.0.114-1OEM.600.0.0.2494585 Hewlett-Packard VMwareCertified 2016-01-02 scsi-hpvsa 5.5.0.100-1OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2016-01-02 <<ここ!
上記のドライバ中、scsi-hpvsaの「5.5.0.100-1OEM.550.0.0.1331820」というバージョンが良くないようです。
そこで、ドライバをダウングレードして実績のあるものに差し替えました。
Very slow acces to datastores on HP MIcroserver... | VMware Communities
既に海外の有志の方々が検証してくれており、上記のサイトを参考にドライバを入れ替えています。
Before:scsi-hpvsa 5.5.0.100-1OEM.550.0.0.1331820
After: scsi-hpvsa 5.5.0-88OEM.550.0.0.1331820
#適用するパッチを格納 cp scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib /var/log/vmware/ #ESXiをメンテナンスモードへ esxcli system maintenanceMode set --enable true #既存のドライバを削除 esxcli software vib remove -n scsi-hpvsa -f #対象のドライバをインストール esxcli software vib install -v file:scsi-hpvsa-5.5.0-88OEM.550.0.0.1331820.x86_64.vib --force --no-sig-check --maintenance-mode #再起動して反映 reboot #再起動後、変更されているのを確認 [XXXX@XXXX:~] esxcli software vib list | grep He char-hpcru 6.0.6.14-1OEM.600.0.0.2159203 Hewlett-Packard PartnerSupported 2016-01-02 char-hpilo 600.9.0.2.8-1OEM.600.0.0.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hp-ams 600.10.3.0-15.2494585 Hewlett-Packard PartnerSupported 2016-01-02 hp-build 600.9.4.34-2494585 Hewlett-Packard PartnerSupported 2016-01-02 hp-conrep 6.0.0.1-0.0.13.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hp-esxi-fc-enablement 600.2.4.6-2494585 Hewlett-Packard PartnerSupported 2016-01-02 hp-smx-provider 600.03.09.00.15-2768847 Hewlett-Packard VMwareAccepted 2016-01-02 hpbootcfg 6.0.0.02-01.00.11.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hpnmi 600.2.3.14-2159203 Hewlett-Packard PartnerSupported 2016-01-02 hponcfg 6.0.0.04-00.13.17.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hpssacli 2.30.6.0-6.0.0.2159203 Hewlett-Packard PartnerSupported 2016-01-02 hptestevent 6.0.0.01-00.00.8.2159203 Hewlett-Packard PartnerSupported 2016-01-02 scsi-hpdsa 5.5.0.46-1OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2016-01-02 scsi-hpsa 6.0.0.114-1OEM.600.0.0.2494585 Hewlett-Packard VMwareCertified 2016-01-02 scsi-hpvsa 5.5.0-88OEM.550.0.0.1331820 Hewlett-Packard PartnerSupported 2016-01-02 <<ここ!
これで改善されました。
ESXiをUSBブートで利用時の、パススルー設定に注意。
ESXiをはじめ、最近の仮想化製品はデバイスを仮想マシンにアタッチできるので便利ですよね。
仮想マシンだからという制約がかなり低減されていると思います。
ESXiだとパススルーと呼ばれてまして、
その名のとおりESXiホストに接続されているデバイスを仮想マシンに直接接続させることが可能。
で少し前に、ふとUSBを仮想マシンに接続させようとした際にトラブリました。
何気なくUSBを仮想マシンに接続させるために
パススルーの設定をして、設定適用のために再起動しました。
普通にESXiが起動して、USBデバイスも
仮想マシンから見てるようになりめでたしめでたしと思ったのですが、
その後幾つか気になることが発生しました。
設定を変更した内容が、再起動したら消える。
→これは定期的にESXiはバックアップ処理を入れているから
そのタイミングに合わなかったのかな？と思って
自分を納得させました。（気付けよ。。というはなしなんですが）
ESXiのvib(パッチ)を適用したら、下記エラーがでて怒られる。
(このタイミングでブートデバイスである、USBデバイスになにか問題がある？と思った）
「The transaction is not supported : ・・・略・・・ cannot be removed live.」
で、ESXiのコンソールに接続してデバイス一覧を確認したら、
Bootデバイスが一覧にありませんでした。。(trueが一つもない)
[XXXX@XXXX:~] esxcli storage core device list | grep Boot Is Boot USB Device: false Is Boot Device: false Is Boot USB Device: false Is Boot Device: false Is Boot USB Device: false Is Boot Device: false Is Boot USB Device: false Is Boot Device: false
こうなるとESXiがUSBメモリを認識できていないのは確実。
最近の設定変更を思い出してみると、タイトルになるのですがUSBのパススルー設定をしたなと。
ここで、USBのコントローラ毎パススルー設定をしているのが発覚。
ESXiが起動するまでは、BIOSからブートメディアとして見えているが、
ESXiがメモリにロードされて完全に起動するとパススルー設定が有効化させて、
ブート用USBメモリがESXiから見えなくなるという。。
なので、設定もメモリ上では保持しているが、
再起動等する際には保存されないので先祖返りするということに。
じゃあ、どうやって設定を戻すの？ということになるわけです。
設定変更しても、ブート用USBメモリに設定が反映されないのでしょと。
はい、こうなると再インストールした後に設定を戻すしかありません。
それは、、うん、そうだよね。ということになるのですが。
ちなみにVMWareのKnowledge Baseにご丁寧に説明もあります。
ESXiがUSBからブートしているのを検知できるんだから、設定時に警告だしてくれないかなぁ。
ちょっと求めすぎかなぁ。
PowerShell DSC Configuration設計に関して
PowerShell DSCに関して、まだまだ情報は少ないのが現状。
サンプルとかに関してはちらほらネット上にあるのだが、
より実用的な、大規模な設定を投入することになると、サンプルのようにはいかなくなる。
以下、より実用的なConfigurationを作成するにあたり参考にしたサイトが以下。
■巨大なDSC Configurationの考え方
ParameterとRoleの活用に関しての記載がある
Designing Node Configurations in PowerShell DSC - Nicholas Dille
■DSCにおける、設定とConfigurationの分離
複数のConfigurationに分割しての実装方法に関して
■Nested Configuration の問題点
ネスト構造のConfigurationに関しての問題点に関して記載している。
自分は、ネスト構造を採用しているけど。
Reusing #PSDSC Node Configuration with Nested Configurations - the Horror! - Nicholas Dille
ちなみに、DSCはまとまった情報得るのが難しいのが現状かと思うが、
書籍としては下記が非常に良かった。
下手に情報をパラパラとネットで集めるよりは、この本をベースに始めるのがいいかと思う。
こっちの本も、まだ購入していないけど気になる。
VMWare ESXiのインストールおよびアップグレードのベスト プラクティス
システムを設計するうえで、利用する製品の機能・仕様を理解するのは非常に大事です。
特に、製品ベンダーの公式の資料というのが何よりも大切な指針となります。
（当然、ソースレベルで使用を確認できる唯一の組織になりますからね）
VMWareのESXi製品は、毎回バージョン毎に「インストールおよびアップグレードのベストプラクティス」が
KB Blogに公開されています。
それぞれ、ESXi 5.1, 5.5, 6.0のページが公開されています。
各ページともに下記内容で構成されています。
■システム要件
ESXiが既定しているHW要件に関しての記載があります。
特にESXiで肝になるのは、CPU、NIC、メモリサイズとかでしょうか。
CPUは、HW仮想化のサポートの有無(Intel VT)、
NICはサポートしているNICでないとドライバが対応していない等があります。
おすすめはIntel製のNICですね。迷ったらIntel、それでなくてもIntelが基本です。
メモリに関しても、最低要件が定められており、ESXi5.5ですと4GBです。
加えて、サポート対象としているSATAコントローラも記載があるのですね。
■起動要件
ここはUEFIの話とかです。
■ストレージ要件
ESXiのインストールに必要な容量としては1GBが必要です。
加えて、5.2GB以上のディスクがないとスクラッチ領域がRAM上に置かれるようです。
つまり、再起動するとデータが消えるということです。
当然、推奨はされていません。
※スクラッチ領域とは、ESXiのログ、システムスワップ含むデータを保持する領域です。
インストール後に、スクラッチ領域を別途指定可能です。
USB,SDカードにインストールする場合も、8GB未満ですとスクラッチ領域を作成しないようです。
8GBのUSBにESXiをインストールしている方は要注意です。
■ESXi ホストのアップグレードまたは移行のベストプラクティス
文字通りですが、エンタープライズ向けですとアップグレードまたは移行を考えることもあるかと思います。
その際のベストプラクティスがまとめられています。
ところで、エンタープライズでESXiのアップグレードってそんなに需要あるんですかね。
移行はともかく。
HP Lights-Out スタンド アロン リモート コンソール for Windows
サーバ機器にはリモートからコンソール接続できる機能が搭載されていることが多いです。
これは、トラブルのたびにデータセンターへダッシュして、コンソールを開いて作業することにならないためにも非常に大事です。
HP製のサーバにはiLoというリモートコンソールの機能が搭載されていますが、
多くの方がブラウザ経由でアクセスして、利用しているかと思います。
自分がよくであう状況としては、ブラウザのバージョンが低くてうまく画面を取得できない、
Javaがインストールされていない（Java版のリモートコンソールの場合）などなど、
意外とうまく動いてくれないことがありました。
トラブルの時くらいしか利用しないため普段はまったく意識しません。
が、いざトラブル時に利用できないと焦るのです。。
そこで、タイトルの件になるのですが、
ブラウザを利用しなくてもよい、スタンドアロンのソフトウエアがあるようです。
初めて知りましたが、これならメンテナンス用の端末にインストールしておけば確実ですね。
※メンテナンス用の端末のブラウザを保全しておけよという意見もまぁあるのですが。
Drivers & Software - HP Support Center.
また、HPさんはiOS,Android版のコンソールアプリもリリースしているみたいです。
HP iLO Mobile - Google Play の Android アプリ
以下、参考サイト。
あまり知られていない HP iLO リモートコンソールの 5 つの Tips - 仮想化でプリセールスしてるSEの一日
Windows Server 2012 OS標準NICチーミングに挙動に関して
サーバ構築する際には、NIC障害に備えて、複数NICを搭載してチーミングをしているかと思います。
従来、Windowsでサーバ構築をする際のNICチーミングには、NICベンダのドライバを利用してチーミングを構成していたかと思います。
ですが、Windows Server 2012以降は、OS標準機能としてNICチーミングの機能を提供しています。
OSレイヤーでチーミングが可能ですので、別ベンダーのNICでも事実上チーム構成が可能です。
※あえて、そのような構成を選択する人はいないかと思いますが。
当時、OS標準のNICチーミングでアクティブ・スタンバイ構成を利用した際に、随分とフェイルバックが遅いなと感じていました。
以下のような流れで挙動を検証をしたのですが、
NIC1:アクティブ
NIC2:スタンバイ
2.内、NIC1のイーサネットケーブルを抜栓する。
ここは瞬時にスタンバイに切り替わる。
NIC1:エラー "メディアが切断されています"
NIC2:アクティブ
3.抜栓したイーサネットケーブルを結線する。
NIC1:エラー "接続の保留中"
NIC2:アクティブ
4.一定時間経過後、NIC1がアクティブに復帰
NIC1:アクティブ
NIC2:スタンバイ
3から4への遷移に結構な時間がかかっていました。
"接続の保留中"という文言から何か待っているのかなと思っていましたが、
MSのNetworkチームBlogにその件の記載がありました。
結論から言うと、30秒待ってから、アクティブに復帰するそうです。
これは、リンクの安定性を確かめるために30秒まつようにしているようです。
尚、下記Blogによると、この30秒を変更する方法はなく、OSの仕様として決まっているようです。
Microsoft User Experience Virtualization(UE-V)概要
【概要】
Microsoft User Experience Virtualization(UE-V)に関して概要を。
このような製品があることを最近知ったので、ひとまず、簡単な調査をした程度。
今後、もう少し検証していきたい。
2012年ころに、MSがリリースした製品。
UE-Vは、Windows上でのユーザ設定を一元管理する機能を提供する。
つまり何よというと、ユーザがWindows端末にログオンして行った設定情報を
管理サーバに保存しておき、別端末にログインしてもその情報が提供されるというもの。
TecNetからの文言を拾うと、以下の設定が同期されるとある。
・ユーザアプリケーション
・Windows設定
・App-Vでシーケンス処理されたアプリケーション
・RemoteAppアプリケーション
参考：
User Experience Virtualization 1.0 の概要
となると、頭に浮かんでくるのは「移動プロファイル」である。
おおよそ機能としてはかぶっているように見える。
※ここに関しては調査中。
【アーキテクチャ概要】
自身のコンピュータに、UE-V Agentというモジュールが稼働する。
UE-V設定場所のテンプレートに従って、アプリケーションとOSを監視する。
（設定場所のテンプレートとは、UE-Vで管理対象としているアプリなどの記載がある設定ファイル)
該当のアプリケーション等が起動すると、設定が設定PKGからダウンロードされて適用される。
終了時は、更新分がアップロードされる。
設定の保存場所はActiveDirectoryのホームディレクトリ
共有フォルダへ保存できるとのこと。
また、移動プロファイルと違い、「上書き問題」は発生しないように制御されるとのこと。
（どのように制御されるかまでは、調べられてないので検証した際にでも）
