ESXiのラウンドロビンのIOPS制限の変更とキューの深さ変更
DellEMCのUnityのbest practiceによるとラウンドロビンの IOPS limit を1にするのが推奨らしい。(ただしアクティブ、アクティブの場合は不要な気がする。自信なし)
方法はKBを参照、やってみるとわかると思うが結構面倒だし
ミスが起きる可能性もあるので本当に必要なのかメーカーに確認して進むことを推奨
https://kb.vmware.com/articleview?docid=2069356&lang=ja
ストレージのパフォーマンスチューニングとしてqueue_depthの変更が必要な場合がある。ここでは手順だけ紹介する
例はfnicのqueue_depthを変更する手順
1)現在ロードされているHBAモジュールの確認
esxcli storage core adapter list
esxcli system module list | grep fnic
2)現在のパラメータの確認
esxcli system module parameters list -m fnic
3)キューの深さ変更
esxcli system module parameters set -p fnic_max_qdepth=32 -m fnic
4)変更後の確認
esxcli system module parameters list -m fnic
ESXi設定確認用コマンドまとめ
esxcli system version get
esxcli software vib list
esxcli software profile list
ls -l /vmfs/volumes/(データストアのパス)
esxcli system get settings keyboard layout get
esxcli storage filesystem list
esxcli hardware clock get
esxcli /etc/ntp.conf
esxcli system hostname get
esxcli network ip dns server list
esxcli system syslog config get
esxcli system setings advanced list
esxcli system snmp get
esxcli system coredump network get
esxcli system account list
esxcli system permission list
esxcli network ip interface list
esxcli network ip route ipv4 list
esxcli network ip interface ipv4 get
esxcli network ip interface ipv6 get
esxcli network vswitch standard list
esxcli network vswitch standard portgroup list
esxcli network vswitch dvs vmware list
df -h
esxcli hardware platform get
esxcli hardware cpu global get
esxcli hardware trustedboot get
esxcli hardware memory get
esxcli iscsi adapter list
esxcli network nic list
esxcli storage core adapter list
esxcli storage core device list
esxcli system uuid get
esxcli storage boot device get
ESXi6.5パスワードポリシーの無効化
詳細設定のSecurity.PasswordQualityControlを変更
デフォルト値:retry=3 min=disabled,disabled,disabled,7,7
パスワード制限なし:retry=3 enforce=none min=disabled,disabled,disabled,7,7
参照:
ESXiのパッチ、ドライバ更新コマンド
現在の情報を確認
esxcli system version get
esxcli software vib list
esxcli software profile get
更新にしようするファイルを確認
ls -l /vmfs/volumes/(ファイルのパス)
パッチの場合
esxcli sofware sources profile list -d (パッチファイルのパス)
esxcli sofware profile update --dry-run -d (パッチファイルのパス) -p (当てるプロファイルを選択、通常standard)
esxcli sofware profile update -d (パッチファイルのパス) -p (当てるプロファイルを選択、通常standard)
ドライバの場合
esxcli software vib udate -v (ドライバのパス)
更新が終わったらvib listなどを比較して確認すること
ESXi6.5のパスワードポリシーを一時的に無効化する方法
Security.PasswordQualityControl の詳細オプションに enforce=noneを入れる事で可能
修正することで可能
retry=3 min=disabled,disabled,disabled,7,7
を
retry=3 min=disabled,enforce=none, disabled,disabled,7,7
に修正すると暗号のポリシーに無効になる。ほしい暗号を入力したら元のデフォルト設定に戻せば完了
参照
http://www.openwall.com/passwdqc/README.shtml
vSphere 6.5U2の重要な変更点と注意点
1)'PSCが組み込まれた2台以上のvCenter Server'構成のサポート(VCSAのみ)
KB2148113によるとPSCが組み込まれた2台以上のvCenter Server構成は廃止されたトポロジになっていますがリリースノートによると6.5U2も6.7と同じくはPSCが組み込まれた2台以上のvCenter Server構成がサポートされます。
ただし、VMwareのブログによると’新規構築する場合のみ’がサポート対象になります。
Enhanced Linked Mode using an Embedded Platform Service Controller is only supported for Greenfield deployments.
6月22日追記
6.5U2へのアップデートの話が出たのでまだブログを見たら文言が新規構築以外でもできるように変わったので追記します。
It supports Greenfield deployments or an existing environment which has an existing embedded deployment. An additional embedded deployment can be added for Enhanced Linked Mode after the upgrade to either vSphere 6.5 U2 or vSphere 6.7.
2)現時点では6.5U2から6.7へのアップグレードはサポートしないです。
(おそらく6.5U2のビルド番号が6.7のビルド番号より新しいのが原因で新しいビルド番号から古いビルド番号にアップグレードができないのではないかと思います。)
6.5U2にするか6.7にするかまたは6.5U1にするか迷うことになると思いますが
①6.5と6.7のライフサイクルが一緒であること
②6.7をサポートしないハードウェアもあるし、NSXも現時点でサポートしないこと
などを検討して決めるべきです。6.5U2は新しすぎてサポートが不安だと思う場合は6.5U1にすることも一つの案です。
HPE iSCSI rescan softwareについて
VSAを利用する環境でESXiを停止・起動するたびデータストアを手動でスキャンする必要なく自動でスキャンしてくれるソフトウェアらしいです。しかもHPEの推奨。
インストール方法はP20参照
普通のvibインストールと変わりはないです。
https://support.hpe.com/hpsc/doc/public/display?docId=a00016289en_us
ダウンロード:
http://vibsdepot.hpe.com/hpe/HPE-StoreVirtual/hpe-iscsi-rescan/
でも、本当にインストールする方がいいのかは少し疑問ですね。
ESXi5.5または6.0から6.5にアップデートすると以前インストールされたiSCSI rescan softwareが不具合を起こすという記事があります。
https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-a00027692en_us
おそらくESXi6.5にアップグレードする前に古いバージョンのiSCSI rescan softwareを削除しなかったから起きる問題だと思います。
iSCSI rescan softwareはHPのESXiカスタムイメージに含まれてないし同時にリリースされる物でもないです。
つまりESXiのアップグレードする時は①古いバージョンのiSCSI rescan softwareを削除、②ESXiのアップグレード,、③アップグレードしたESXiのバージョン用のiSCSI rescan softwareがリリースされたらインストールという流れになります。
問題は②と③の間は手動でデータストアをスキャンしないといけない時期が発生することです。運用からみると二つのパターンがでるのはあまりよろしくない気がします。
最初から「iSCSI rescan softwareはインストールしない、ESXiの停止・起動後は手動でデータストアをスキャンするべき」にする方がむしろ事故が起きる可能性が低いかも…と思いました。
