VMware / Microsoft 製品はこう使う。

好きなことを好きに描く.

ESXi5.x以降で運用中にデータストアをアンマウントするときはきちんとした手順でお願いします。

ESXiを運用していると、Storage 側で仮想ボリュームを切り出したり、
コピーしたり、スナップショットを取得したり、
いろいろなことをしながら運用すると思います。

あるあるかなと思います。

その中でたまにオペレーションミスか勘違いなのかはわかりませんが、
データストアをきちんとアンマウントせずに、Storage側でボリュームを削除したり、
アンマウントする前にStorage側からESXi ホストにボリュームを
見せないように設定変更してしまったりして、人為的ミスによって障害が起こることが少なくありません。

 

そのため、今回はきちんとアンマウントする方法をご紹介します。

 

「40GB-Store」をアンマウントしたいと思います。

f:id:japan-vmware:20161207010249p:plain

 

データストアを右クリックし、「アンマウント」をクリックします。

f:id:japan-vmware:20161207010404p:plain

 

チェックが入ります。「OK」をクリックします。

f:id:japan-vmware:20161207010456p:plain

 

タスクが完了するとグレーアウトします。
ここまででオワリと思いがちですが、まだ作業は残っています。

f:id:japan-vmware:20161207011043p:plain


「デバイス」をクリックします。

f:id:japan-vmware:20161207011232p:plain


上記でアンマウントしたデータストアと対応する デバイスを右クリックし、
「分離」をクリックします。

f:id:japan-vmware:20161207011324p:plain

 

チェックが入ります。

f:id:japan-vmware:20161207011720p:plain

 

グレーアウトしました。

f:id:japan-vmware:20161207012415p:plain

 

ここまでがきちんとしたESXiアンマウント作業になります。

このあと、Stoarge側からESXiに対してボリュームを見せないように設定変更しすることになります。

 

■きちんとした作業をしないといけない理由

きちんとESXiからボリュームをアンマウントせずにStorage側から、
ボリュームを見せないようにしたり、ボリュームを削除してしまったりすると、
ESXiホストは、存在しないLUN(ボリューム)を探し続けている状況になります。

ESXiホストは、存在しないLUNを探し続けている状況が続くと、
APD(All Path Down)やPDL(Permanent Device Loss)が起き、
いずれはすべてのデータストアが見れない状況となったりします。


この状況は、VMware KB 2081089 の内容が該当します。

 

vSphere 5.x での永続的なデバイスの損失 (PDL) と全パス ダウン (APD) (2081089)
http://kb.vmware.com/kb/2081089

私が書いた過去のエントリだと ↓ になります。

ESXi の APD(All-path-Down)はご存知でしょうか。 - 自由人なエンジニアの備忘録

 
APDになるとvmkernel.log にこんなログが出たりします。
2015-XX-XXT1X:01:38.488Z cpu2:329XX)ScsiDevice: 4195: Device naa.6000eb3XXXXXXXXXXXXXXXXXX is Out of APD; token num:1
2015-XX-XXT1X:01:38.489Z cpu2:329XX)StorageApdHandler: 912: APD Exit for ident [naa.6000eb3XXXXXXXXXXXXXXX]!

また、ESXiホストが存在しないLUNを探し続けると連携している
その他のプロセスにも影響が出てきたりもします。

そのため、ESXi上にはvCenter とやり取りを行う vpxa というプロセスが存在しますが、きちんと動作しなくなり、vCenterから見ると [応答なし] になったり、
SSHログインができなくなったり、いろいろなところで不可解な挙動が発生します。

 

このような自体にならないよう注意を払って作業をしてほしいところです。

 

もし、間違えて何もESXi側で操作をしないままStorage 側でボリュームを削除してしまったら、
早い段階でESXiの再起動を実施することをお勧めします。
存在しないLUNを探し続けている状況は、ESXiホストを再起動することで解消するためです。再起動時に存在しないパス(正常に接続されないパス)はクリアされます。

 

障害がなくなることを祈ります!

 

vSphere 6.0のvSphere FTはイマイチなので使わない方がいいかも。

vSphere 6.0 になって vSphere FT の機能が拡張されたのは、
ご存知の方が多いと思います。

よく耳にするのは、ESXi5.5 以前の vSphere FT はLegacy FT と言い、
6.0 の vSphere FT をNew FT とか言っているのを耳にします(汗

 

たしかに Performance Best Practices for VMware vSphere® 6.0 にも
"Legacy FT"  ,  "new version of FT"  と記載があるのであながち間違いではないのかなと思います。

 

このvSphere 6.0の New version のFTですが、Legacy FTのときと異なる仕組みで
動作しているらしく、仮想マシンのパフォーマンスがすごく良くないようです。

参考としてはこのあたりの記事になります。

 

Fault Tolerance Performance in vSphere 6 - VMware VROOM! Blog - VMware BlogsPerformance Best Practices for VMware vSphere® 6.0

vSphere 6.0 Documentation Center

 

 

もし、Legacy FT (vCPU 1) のときに動作の遅くなくて、
マルチvCPU だと明らかに遅いと感じた場合は、仕組みの違いによるものである可能性が高いです。

ドキュメントとか見てても、ある程度のネットワーク遅延は避けられない、という意味合いにも読み取れます。


Legacy FT  も New FT  も異なるESXi間にある仮想マシンを同期する必要があるので、primary 側のVMと secondary 側のVMで常に同期をとる必要があるため、
Network のトラフィックが多く発生するのは同じです。

 

ドキュメント類をいろいろ見ていると、新FT の仕組みとしては、

Legacy FT では record/replay という方式で動作しているようで、
新 FT では、Fast checkpointing という方式になっていると書かれています。
record/replay 方式ではprimary 上で発生した処理の情報(input)をSecondaryのVMに流して、
流された内容を secondaryのVMでも処理を行うことで、同期させていたようですが、
新FT で新しく実装された Fast checkpointing という方法では、Primary のVMのメモリ,ストレージなどの情報を
seconcary 側に送信し、送信された情報を適用することで、同期を取るということが書かれています。
公開されてる情報では、Storage vMotion の技術を使って、データ転送しているみたいです。

 

Blog側にこんな記載が。
>This technology is similar to Storage vMotion, which copies the virtual machine state (storage, memory, and networking) to the secondary ESXi host.
>Fast Checkpointing keeps the primary and secondary virtual machines in sync.

処理情報だけではなくて、ディスクの変更点やメモリの情報を流すので要件として10 Giga Network が必要と記載されていそうです。
たしかに常にStorage vMotionみたいなことをすると帯域はかなり使いそうです。そして遅そう…。


ここまで書いてからなんとなく思ったのですが、
2015年のvForumでは、vSphere 6.0 の目玉機能としてvSphere FTがすごく
フォーカスされて紹介されていたのに、
最近ではあまりvSphere FTのことを聞きません。
やはり、VMwareとしてもあまり使ってほしい機能ではないのかもしれません。。

 

実際に使った人の話を聞いてもディスクI/Oがかかったときに極端に遅いということを聞いたことがあります。

vSphere FT でパフォーマンスが出ないときは、
要件を考え直して、vSphere HA を使うほうがいいかもしれないです。

 

 

 

ESXi5.1~5.5がインストールされたマシンでNICの交換は大丈夫なの?

今回はあるあるネタを綴ります。

 

ESXi5.1~5.5を運用していると、当然ながらハードウェア障害に遭遇することがあります。
CPU,マザーボード,NIC,HDD,SSD 挙げだすと、山ほどあるわけですが、
今回はNIC を交換したときの影響について書きたいと思います。

ESXiでは、物理NICのことを 「vmnic」と言います。

 

まず始めに、結論から申し上げるとESXiはハードウェア的にNICを交換しても、
基本は影響を受けません。一部例外もありますが、順に記載してきます。

NICの交換でハードウェア的に変更されるものは、ESXi観点からは
MAC Address、SerialNo , デバイス ID あたりかと思います。
(同じNICと交換することを想定しています)

Windows であったりLinuxでは、NICを交換すると別の新しいNICという扱いになるため、再設定が必要です。

特にMAC Addressが変更されると、ロードバランサーを使っている環境や、
ファイアーウォールを使っている環境では、MAC Addressで識別して動作させていることも少なくありません。そこでまずはMAC Address観点で影響を受けない理由から記載していこうと思います。


【影響を受けない理由1】
ESXi 上で稼働する仮想マシンに装着されているvNIC はそれぞれ固有に
MAC Addressを保持しています。そのため、物理NIC(vmnic)のMAC Addressを利用していないため、仮想マシンは、物理NIC交換の影響を受けません。

vSphere Web Client から仮想マシンの編集画面を見ると確認できます。
もちろん vSphere Client からでも確認ができます。
(私の環境がvCenter6.5なので見れませんが)

f:id:japan-vmware:20161204141319p:plain

 

◆vmkernel ポートすらMAC Addressを持っている
仮想マシンが固有のMAC Addressを保持しているのは上記の画像でお分かりいただけると思います。

そして、ESXi とって重要なvmkernel ポート もそれぞれMAC Addressを保持しています。
(vmkernelポートは HA,iSCSI接続,vMotion等で使われる仮想ポートです) 

f:id:japan-vmware:20161204203554p:plain

 

◆つまり
ESXiは、物理NIC(vmnic)のMAC Address を使用して外部と通信していないため、
物理NIC 交換後に物理NICMAC Addressが変更されてしまっても、影響を受けず、
外部と通信することが可能です。
イメージとしては、vmnicは通信をパススルーさせてるだけという感じです。

 

【影響を受けない理由2】
ESXi 5.1、5.5 のvmnic番号の割り振り動作について理解してみるといいと思います。
ESXi はOS起動毎にvmnic番号を割り振っていて、
サーバーが認識したPCI IDから順にESXi は自動的にvmnic 番号を割り振ります。
そして、割り振られたvmnic番号は/etc/vmware/esx.conf ファイルに書かれます。
ポート数が同じNICとの交換、そして同じ PCIスロット上にあると認識されれば(同じスロットに挿せば)、基本的には同じvmnic番号で認識されます。
vmnic番号が変更されなければ、従来通りのvSwitchに接続されます。
そのため、影響を受けないということになります。
(参考)
+ESXi/ESX host loses network connectivity after adding new NICs or an upgrade
https://kb.vmware.com/kb/2019871

esx.confにはこんな感じで記録されています。
--------------------------------------------
/device/00000:002:00.1/vmkname = "vmnic1"
/device/00000:002:00.0/vmkname = "vmnic0"
--------------------------------------------

※4ポートのNICを2ポートのNICに交換した場合は、
 vmnic番号が歯抜けになります。番号を振り直したい場合は、
 KBの通り、BIOS からvmnic0以外のNICを全て無効化し、
 サーバーを再起動したあと、認識したい順にBIOSから有効化していきます。
 vmnicの数だけ再起動していきます。

 

NICのベンダーが変わっても同じ動作になります。

 

ESXi6.0以降は実際に試したことがないので、なんとも言えませんが、
おそらく同じ動作になるのではないかと思っています。(推測)

 

参考になると幸いです。

 

 

 

 

VMware KB 2147739 (ESXi 5.5 and 6.x hosts hang after running for 85 days.)

Hi, everyone.

 

VMware vSphere has also new released vmware kb 2147739 .

This is very Critical Issue.However , This is not a VMware issue.

+ ESXi host or virtual machine hangs after approximately 85 days
https://kb.vmware.com/kb/2147739

 

This issue is caused by a QLogic HBA Adapter Firmware problem introduced in Firmware v8.01.00 causing Read Diagnostic Parameters (RDP) between FC Switch and HBA adapter to fail.
By default, the RDP routine is initiated by the FC Switch and occurs once every hour. After 2048 (~85 days)

consecutive RDP failures the HBA Adapter will become stalled which causes the virtual machine and\or ESXi host to fail.

 

My Customer was all ESXi hosts is down and a few VMs is no responsed.
Be careful.


Thanks,


【ESXiホストの動作が不安定になったとき - ATS Heartbeat の無効化を検討してみる - VMware KB 2118921 】

こんにちは。

 

ESXi5.5 Update 2 以降でESXi の動作が不安定であったり、
仮想マシンの動作が不安定になったときには、
いろいろな観点で切り分けを行おうとすると思います。


今回ご紹介するのはVMware KB 2118921 です。

(日本語)ESXi ホストが VMFS3 および VMFS5 データストアから切断される (2118921)
https://kb.vmware.com/kb/2118921

(英語)ESXi host loses connectivity to a VMFS3 and VMFS5 datastore

https://kb.vmware.com/kb/2113956

このKB だけみてもワカラナイこともあると思いますので、少し解説します。


まず、次の内容が単体で稼働するESXi5.5 Update 2 以降のマシン、もしくはクラスタで
発生した場合は、このKB を見てみるといいことがあるかもしれません。

・vCenter Server 配下のクラスタ全体で動作が不安定
・ESXiホストが vSphere vCenter から切断される
・仮想マシンのディスク I/O 操作が不安定、もしくはハングする



これらの事象が発生したとき、正直なところ運用担当者としては ”勘弁してほしい" と
思うでしょう。私だって思います(汗


では、内容に入ろうと思いますが、この事象(VMware KB)が影響を及ぼしている機能は、
ESXi 5.5 Update 2 以降で実装された ATS(Atomic Test and Set) です。

 

ATS(Atomic Test and Set)とは?
まず参考になる資料はこちらです。

https://pubs.vmware.com/vsphere-50/topic/com.vmware.vsphere.storage.doc_50/GUID-DE30AAE3-72ED-43BF-95B3-A2B885A713DB.html


ESXi5.5 Update 2 以降からAtomic Test and Set という機能が実装されました。
これは、従来行っているSCSI Reservation を利用してストレージを利用するのではなく、
Atomic Test and Set(ATS)と呼ばれるアルゴリズムを用いて小さいファイル単位でファイルをロックするため、これによりSCSI  Reservation よってディスクI/O待ちと
なった問題が最小限に抑えられ、処理が向上するようになっています。

ご存知のとおり、VMFSは複数のホストから共有できる優れたファイルシステムですが、ストレージを共有している以上は、整合性を保つ必要があり、
データの一貫性を保つためにVMFSのメタデータ領域に対して排他制御が行われます。


例を挙げると従来行っているSCSI Reservation を利用した場合、
LUN単位でロックし排他制御が行われるため
同じLUNを利用している仮想マシン全てが待たされます。

一方でATSでは、LUN単位ではなくロック対象のセクタのみ排他制御を行いますので、
排他制御の影響を受ける仮想マシンを大幅に減らすことが可能です。
これによりSCSI Reservation の衝突が発生し性能(パフォーマンス)が劣化するという
問題を解消し、効率の良い排他ロック機能を提供するため、
SCSI Resetが発生しづらい状況にもなります。


この機能は、ハードウェア アクセラレーションをサポートするストレージ デバイスを
利用している場合に利用可能です。(ハードウェアオフロードとかいう言い方も)


しかし、この機能により、ESXi カーネルがストレージ システムに発行する ATS コマンドの量が大幅に増え、
ストレージ システムへの負荷が増え、場合によっては、ATS を使用する VMFS へのハートビートが
うまく動作せず失敗し、ESXi カーネルが VMFS データストアへのアクセスを再検証を繰り返す結果になることがあります。
これにより、データストアへの接続が切断されたり、切断されてすぐに接続されるなどの不安定な状況になることがあります。

こういったときは一度ATS heartbeat を無効化してみるといいかと思います。

この部分はVMware KB に記載されている以下のコマンドをESXiにSSH接続して
実行することで無効化が可能です。日本語版も英語版もコマンドに間違いはありませんでした。

esxcli system settings advanced set -i 0 -o /VMFS3/UseATSForHBOnVMFS5

 

実行例を記載します。
まずは、現在の状況を確認し、ATS有効化になっていることを確認。
■画像

f:id:japan-vmware:20161128000621p:plain■テキスト
esxcli system settings advanced list -o /VMFS3/UseATSForHBonVMFS5

Path: /VMFS3/UseATSForHBOnVMFS5
Type: integer
Int Value: 1
Default Int Value: 1
Min Value: 0
Max Value: 1
String Value:
Default String Value:
Valid Characters:
Description: Use ATS for HB on ATS supported VMFS5 volumes

==========

 

ではATS heartbeat を無効化します。

■画像

f:id:japan-vmware:20161128001354p:plain

■テキスト

esxcli system settings advanced set -i 0 -o /VMFS3/UseATSForHBOnVMFS5
esxcli system settings advanced list -o /VMFS3/UseATSForHBonVMFS5
Path: /VMFS3/UseATSForHBOnVMFS5
Type: integer
Int Value: 0
Default Int Value: 1
Min Value: 0
Max Value: 1
String Value:
Default String Value:
Valid Characters:
Description: Use ATS for HB on ATS supported VMFS5 volumes

==========


また、判断材料の1つとしてvmkernel.log を見ることも有効です。
vmkernel.log にこのような記録が多く確認できることがあります。
====================
2016-xx-xxTxx:xx:xxx.xxxZ cpuxx:xxxxx)ScsiDeviceIO: xxxx: Cmd(0x4136c3d842c0) 0x89, CmdSN 0x1088c from world 32797 to dev "naa.xxxxxxxxxxxxxxxxx082xxx" failed H:0x5 D:0x0 P:0x0 Possible sense data: 0xe 0x1d 0x0.
====================

この Sense data : 0xe 0x1d 0x0  がVMware KBに記載されている以下の内容と一致します。
====================
/var/log/vmkernel.log ファイルに、ATS の不一致を示す次のようなエラー メッセージが記録される。
2015-11-20T22:12:47.194Z cpu13:33467)ScsiDeviceIO: 2645: Cmd(0x439dd0d7c400) 0x89, CmdSN 0x2f3dd6 from world 3937473 to dev "naa.50002ac0049412fa" failed H:0x0 D:0x2 P:0x0 Valid sense data: 0xe 0x1d 0x0. 
====================


Hewlett-Packard Enterprise からはStorage観点でもドキュメントが公開されていました。
+ Array Host Disconnects While Running VMware vSphere 5.5 Update 2 and Later
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c05228694

 

もし、障害に困っている方がいらっしゃれば、
お試し頂けると幸いです。

 

私の備忘録として記事を書きましたがどなたかに見てもらえると嬉しいです。

 

オワリ

 

VCSA6.5 - vCenter Server Appliance 6.5 をデプロイして使えるようにする。

こんにちは。

 

vCenter Server Appliance 6.5 がリリースされているので、
使えるようにするまでの流れです。

 

新しくインストールウィザードが刷新されていますし、
OSも異なるLinuxに変わっています。(Photon Linuxというらしい…)

f:id:japan-vmware:20161124205239p:plain

Photon OS™ by VMware®

 

それでは新規インストールの画面です。
VMwareのサイトからISOイメージをダウンロードし、
ISOイメージをESXiと通信可能なPC上でマウントして、インストーラーを実行します。

マウントしたインストーラーがFドライブである場合の例はこちら。
例)"F:\vcsa-ui-installer\win32\installer.exe"

また、インストール方法のreadme.txt がここにあります。
例)"F:\readme-ja.txt"

 

では、「"F:\vcsa-ui-installer\win32\installer.exe"」を実行します。
新規インストールの場合は、「Install」ボタンをクリックします。

f:id:japan-vmware:20161124022841p:plain

 

 「Next」をクリックします。

f:id:japan-vmware:20161124022909p:plain

 「vCenter Server with an Embedded Platform Service Controller」を選択して
「Next」をクリックします。
私が知る限り、あまりPlatform Service Controllerを外部(External)にしている方は少ないように思います。(vSphere6.0のとき)

f:id:japan-vmware:20161124022930p:plain

 

vCSA6.5 をデプロイする先の指定です。今回vCenter Server が既に存在する環境へ
vCSA6.5をデプロイするので、vCenter Server の情報を入力しています。

f:id:japan-vmware:20161124023303p:plain

 

証明証の警告がでますが、気にしません。

f:id:japan-vmware:20161124023319p:plain

 

 デプロイ先を指定します。

f:id:japan-vmware:20161124023356p:plain

 

デプロイ先のESXiを指定します。

f:id:japan-vmware:20161124023458p:plain

 

VCSA6.5 の仮想マシン名と root パスワード入力します。

f:id:japan-vmware:20161124023527p:plain

 

「Tiny」でデプロイしても、2 vCPUs , メモリ10GB使います。
正直かなりキツイです。

f:id:japan-vmware:20161124023554p:plain

 

vCSA6.5の仮想マシンのネットワーク設定です。

f:id:japan-vmware:20161124024129p:plain

 

デプロイ開始です。

f:id:japan-vmware:20161124024204p:plain

 

だらだらと待ちます。

f:id:japan-vmware:20161124030206p:plain

 

Platform Service Controllerのデプロイが完了しました。

f:id:japan-vmware:20161124030446p:plain

 

続いて、VCSA6.5のセットアップの続きです。

f:id:japan-vmware:20161124030608p:plain

 

デフォルトでは、SSH は無効になっています。(画面上では設定変更してます)
また、NTPServer を設定するようにデフォルトではなっていますが、
ESXiホストと同期するように設定変更することができます。
f:id:japan-vmware:20161124030633p:plain

 

SSOの設定です。
vCenter Server 6.0のときと変わらないパラメータです。

f:id:japan-vmware:20161124030743p:plain

 

次へ進みます。

f:id:japan-vmware:20161124030756p:plain

 

ネットワーク設定を完了させるため、「Finish」をクリック。

f:id:japan-vmware:20161124030903p:plain

 

もう戻れませんよ と脅されます。
「OK」をクリック。

f:id:japan-vmware:20161124031008p:plain

 

デプロイ開始します。

だらだらと待ちます。

f:id:japan-vmware:20161124031035p:plain

 

完了しました。

f:id:japan-vmware:20161124091113p:plain

 

[Close]ボタンを押すと、既定のブラウザからアクセスされます。(親切)

f:id:japan-vmware:20161124092100p:plain

 

vSphere Web Client (Flash)をクリックし、
SSOで設定したアカウント 「Administrator@vSphere.local」でログインしました。

f:id:japan-vmware:20161124092426p:plain

 

 

以上になります。

ここからは以前までのvCenter Server の操作と同じです。

ライセンス適用するなり、ESXiホスト追加するなり、順次操作していくことになります。

 

【補足】

作業時間としては1時間弱というところでした。

あまりコケるポイントも無く、すんなりデプロイから設定まで終えることができました。

 

おわり