vCenter Server Appliance6.7から7.0u1へのアップグレード手順 -Stage 1
vCenter Server Appliance 6.7から7.0u1へアップグレードする手順について、ラボ環境のembedded版のvCenterを7.0u1へアップグレードします。
アップグレード手順は以下のステップになります。
Stage 1 - 新しいvCenter Server ApplianceのOVFをデプロイ
Stage 2 - 新しくデプロイされたvCenter Server Applianceへのデータ移行
アップグレードを開始する前に、vCenter 7.0へのアップグレードの要件を満たしている事を確認します。
新しい vCenter Server アプライアンスのシステム要件
次に、MyVMwareからvCenter Server Appliance 7.0u1のインストールISOファイルを入手します。
インストールISOファイルをマウントして、インストーラを起動します。
(D:\vcsa-ui-installer\win32\installer.exe)
ステージ1のウィザードが表示されるので、内容を確認し、NEXTをクリック
End user license agreementを確認し、"I accept the terms of the license agreement"のチェックボックスにチェックを入れ、NEXTをクリック
アップグレードするソース6.7vCSAを入力します。
vCenter FQDNとアプライアンスのHTTPSポートを入力します。
"CONNECT TO SOURCE"をクリックします。
ソースのアプライアンスのSSOユーザー名とパスワードを入力します。
また、ソースアプライアンスを管理するESXiホストまたは、vCenter Serverの詳細情報を入力します。
SSLサムプリントの警告が表示されたら”YES”をクリックします。
新しいvCenter Server Applianceのデプロイ先のESXiもしくはvCenterの情報を入力します。入力後、NEXTをクリックします。
再度、SSLサムプリントの警告が表示されたら”YES”をクリックします。
7.0 vCenter Server ApplianceのVM名とルートの資格情報を入力してNEXTをクリックします。
デプロイするサイズを選択します。
インストール先のデータストアを選択します。
必要に応じて"Thin Disk Mode"を有効にします。
(検証環境のため、Thin Diskにしますが、本番環境ではあまりお勧めではありません)
NEXTをクリックします。
ネットワーク設定を入力して、NEXTをクリック
入力した内容を確認します。問題なければ、FINISHをクリックします。
デプロイが開始されます。
正常に完了するとステージ1のアップグレードが完了します。
"CONTINUE"をクリックして、Stage 2のアップグレードを開始します。
NSX-TのSSHとWeb GUIのタイムアウト無効化について
NSX-T ManagerのSSHとWeb GUIセッションのタイムアウト無効化について記載します。
デフォルトのNSX-T Managerのタイムアウト値は以下です。
2.adminユーザーでログインします。
3.set cli-timeout 0 で無効化します。
nsxtmgr> set cli-timeout 0
4.タイムアウトの無効化を確認します。
nsxtmgr> get cli-timeout
Timeout disabled
2.adminユーザーでログインします。
3.set service http session-timeout 0 で無効化します。
nsxtmgr> set service http session-timeout 0
4.HTTPサービスを再起動します。
nsxtmgr> restart service ui-service
5.HTTPのタイムアウト値を確認します。
nsxtmgr> get service http
Service name: http
Service state: running
Session timeout: 0 seconds <<<★
Connection timeout: 30 seconds
Client API rate limit: 100 requests/sec
Client API concurrency limit: 40 connections
Global API concurrency limit: 199 connections
Redirect host: (not configured)
以上です。
NSX-Tのパスワード有効期限について
NSX-Tのユーザーはadmin/audit/rootの３つがありますが、全てのユーザーのパスワードは90日後に変更する必要があり、期限切れが迫ると警告がでます。
NSX-Tのパスワード有効期限はデフォルト90日になっています。
今回は、パスワードの有効期限を無効にする方法について記載します。
パスワードの有効期限が切れると、一部の機能(APIやWebインターフェース)が使用できなくなるため、パスワードは定期的に変更するか有効期限を無効にしてください。
NSX-T Managerのパスワードだけでなく、Edge TransportNode(Edge VM)のパスワードも同様に有効期限切れになりますので、そちらも同時に変更する事を推奨します。
次のコマンドを使用して、パスワードの有効期限ポリシーを無効にできます。
NSX-T Managerが3台で構成されている場合は、どれか1つのノードでのみ実行します。
2.adminユーザーでログインします。
3.パスワードの有効期限を削除します
clear user admin password-expiration
clear user audit password-expiration
clear user root password-expiration
4.パスワードの有効期限を確認します。
get user admin password-expiration
Password expiration not configured for this user
Edge TransportNode(Edge VM)も同様の手順で実施します。
vSAN6.7u3 - vSAN iSCSI ボリュームのオンライン拡張について
本BlogはvExpert Advent Calendar 2019に参加しています。
vSAN6.7u3でvSAN iSCSIのボリュームをオンラインで容量拡張する事ができるようになりました。
VMware vSAN 6.7 Update 3 リリース ノート
vSAN iSCSI サービスの機能強化
vSAN iSCSI サービスが強化されて、iSCSI LUN を中断しなくても、動的にサイズ変更できるようになりました。
Labで検証してみました。
vSAN iSCSIターゲットの設定を行い、以下2つのボリュームを作成済み
・vol-01 3G
・vol-02 10GB
"編集"からvol-02を10GB→15GBに変更してみます。
15GBに容量が増えました。
上記でボリュームの容量拡張後、OS側では、ディスクの管理 > 操作 > ディスクの再スキャンを行います。
5GB分の未割り当て領域が作成されました。
拡張したいディスクを選択して、ボリュームの拡張を行います。
ディスクの拡張が完了しました。(10GB→15GB)
次は、CLIでvol-01を3GB→5GBに変更してみます。
ターゲットエイリアスを確認
[root@esxi01:~] esxcli vsan iscsi target list
Alias iSCSI Qualified Name (IQN) Interface Port Authentication type LUNs Is Compliant UUID I/O Owner UUID
---------- -------------------------------------------------------- --------- ---- ------------------- ---- ------------ ------------------------------------ ------------------------------------
wsfc-iscsi iqn.1998-01.com.vmware.52d9af5ef69bb645-1245c1689aee844f vmk0 3260 No-Authentication 2 true 57056a5d-26e7-6f65-ec86-005056818076 5d6603b4-b94c-e120-5140-005056818076
容量を拡張するLUNのIDを確認
[root@esxi01:~] esxcli vsan iscsi target lun list -t wsfc-iscsi
ID Alias Size UUID Is Compliant Status
-- ------ --------- ------------------------------------ ------------ ------
0 vol-01 3072 MiB 7a056a5d-e028-4745-e673-005056818076 true online
1 vol-02 15360 MiB 9f056a5d-06d2-cfca-780e-005056812e61 true online
5GBに拡張します。
<オプション>
-s サイズ
-i LUNのID
-t ターゲットのエイリアス
[root@esxi01:~] esxcli vsan iscsi target lun set -s 5120MB -i 0 -t wsfc-iscsi
拡張後のサイズを確認
[root@esxi01:~] esxcli vsan iscsi target lun list -t wsfc-iscsi
ID Alias Size UUID Is Compliant Status
-- ------ --------- ------------------------------------ ------------ ------
0 vol-01 4885 MiB 7a056a5d-e028-4745-e673-005056818076 true online
1 vol-02 15360 MiB 9f056a5d-06d2-cfca-780e-005056812e61 true online
拡張はされているが、5GB(1024*5=5120MB)で指定したはずが、若干意図した容量と異なる。。
OS上での認識
GUI上で再度変更してみました。(4.77GB→5GB)
期待する値になってました。
[root@esxi01:~] esxcli vsan iscsi target lun list -t wsfc-iscsi
ID Alias Size UUID Is Compliant Status
-- ------ --------- ------------------------------------ ------------ ------
0 vol-01 5120 MiB 7a056a5d-e028-4745-e673-005056818076 true online
1 vol-02 15360 MiB 9f056a5d-06d2-cfca-780e-005056812e61 true online
-s オプションのサイズをMiBで指定(5GB→6GBに拡張)
[root@esxi01:~] esxcli vsan iscsi target lun set -s 6144MiB -i 0 -t wsfc-iscsi
[root@esxi01:~] esxcli vsan iscsi target lun list -t wsfc-iscsi
ID Alias Size UUID Is Compliant Status
-- ------ --------- ------------------------------------ ------------ ------
0 vol-01 6144 MiB 7a056a5d-e028-4745-e673-005056818076 true online
1 vol-02 15360 MiB 9f056a5d-06d2-cfca-780e-005056812e61 true online
サイズをMiBで指定すると意図した値になりました。
CLIでの容量拡張はMiBで指定した方が混乱が無く実施できそうです。
以上、vSAN6.7u3で追加されたvSAN iSCSIの機能拡張により、上記の作業(GUI/CLI)は全てオンラインで実施可能でした。
関連KB
https://blogs.vmware.com/virtualblocks/2019/08/13/vsan67u3-whats-new/
vSAN6.7u3 - SCSI-3 PRを使用したWSFCについて
vSAN6.7 Update3よりSCSI-3 Perssitent Reservationがネイティブにサポートされ、共有VMDKを使用したWSFCの構成が可能です。
https://docs.vmware.com/jp/VMware-vSphere/6.7/rn/vmware-vsan-67u3-release-notes.html
ネイティブ vSAN VMDK 上の Windows Server Failover Clusters (WSFC)
vSAN 6.7 Update 3 では SCSI-3 PR がネイティブにサポートされており、Windows Server Failover Clusters を最初のクラスのワークロードとして VMDK に直接デプロイできます。この機能を使用すると、物理 RDM のレガシー環境または外部ストレージ プロトコルを vSAN に移行できます。
サポートされる機能
・クラスタ間のvMotion(WSFCノード(VM)は異なるESXiに配置する事が推奨)
・vSANストレッチクラスタ
サポートされない機能
・スナップショット
・オンラインstorage vMotion
・共有ディスクのHot-extension
・メモリ/CPUのHot add
・vSphere Fault Tolerance(FT)
・異なるESXiバージョンが混在されている環境
以下も参照
SCSIコントローラは"VMware準仮想化"(VMware Paravirtual)が推奨のようです。
SCSIバスの共有を"物理"に変更します。
Node#2側でNode#1側のvmdkをマウント
SCSIコントローラはVMware準仮想化で作成、SCSIバスの共有を"物理"に設定
関連KB
https://kb.vmware.com/s/article/74786
https://kb.vmware.com/s/article/2147661
https://blogs.vmware.com/virtualblocks/2019/08/13/vsan67u3-whats-new/
https://blogs.vmware.com/virtualblocks/2019/08/23/vsan67-u3-wsfc-shared-disksupport/
https://blogs.vmware.com/apps/2019/05/wsfc-on-vsphere.html
vSAN6.7でのWindows Server Failover Clusters(WSFC)について
今までの記事でVIT(vSAN iSCSI Target)について記載してきました。
vSphere6.7の問い合わせも多く入ってくるようになり、それに伴いvSAN 6.7でのWSFC構成に興味を持たれていらっしゃる方も増えてきました。
そこで、勉強のため環境を構築して、テストしてみようと思います。
まず、VITでのWSFC構成はvSAN6.7でサポートされました。
https://docs.vmware.com/jp/VMware-vSphere/6.7/rn/vmware-vsan-67-release-notes.html
Windows Server フェイルオーバー クラスタのサポート。vSAN 6.7 では、vSAN iSCSI ターゲットの上に Windows Failover Clustering (WSFC) ターゲットを構築することにより、WSFC をサポートしています。vSAN iSCSI ターゲット サービスは、共有ディスクの SCSI-3 の永続的な予約と、WSFC の透過的フェイルオーバーをサポートします。WSFC は、物理サーバまたは仮想マシンのいずれかで実行できます。
images: https://storagehub.vmware.com
検証環境
- Windows Server 2016 (2ノード WSFC構成)
- ESXi6.7u2 / vSAN 6.7EP9
- MPIO/フェールオーバークラスタリングの機能を追加
- VITの設定でLUNを2つ(Quorum:3GB/Share Storage:10GB)を作成
- WSFCクラスタノードのIQNをイニシエータグループに登録済
フェールオーバークラスタにファイルサーバーの役割を追加
クライアント側に共有ドライブをマウントします
MPIO周りの設定確認
アクティブセッションはセッション03となり、ターゲットポータルはesxi01である事がわかる
上記のMPIO設定から、アクティブセッションを張っているesxi01がダウンし、iSCSIセッションが途切れてしまった場合でも、別のノードでiSCSIセッションを再接続し、ファイルサービスへのアクセスが継続して提供される事が期待する結果です。
次回は本環境を使用して、動作検証を行いたいと思います。
関連KB
vSAN健全性チェックで"統計情報に影響するすべてのホスト"が記録される
vSAN健全性チェックでvSANパフォーマンスサービスの"統計情報に影響するすべてのホスト"のエラーが記録されていたので、その対処方法についてです。
このチェックの目的はVMware KB2144400に記載されています。
Q：[パフォーマンス サービス - 統計情報に影響するすべてのホスト] チェックでは何を行いますか。
A：このチェックでは、現在同じネットワーク パーティションの一部であるすべてのホストがコレクションの統計に影響していることを確認します。同じネットワーク パーティションにないホストは、確認しません。一般的なネットワーク健全性チェックを使用して、全体的なクラスタの健全性のこの側面を評価します。このチェックは、vSAN パフォーマンス サービスがホストと通信し、統計を取得できることを確認するために使用されます。
Q：エラー状態とは、どのような状況を意味しますか。A：このチェックが黄色の場合は、一部のホストがパフォーマンス統計に影響していないことを意味します。
この問題は様々な要因で発生するため、本問題を解決するための一連のトラブルシューティングを行います。
1.全vSAN Hostのvsanmgmtdのサービスを再起動
[root@esxi01:~] /etc/init.d/vsanmgmtd restart
watchdog-vsanperfsvc: Terminating watchdog process with PID 2101508
vsanperfsvc started
※この作業は稼働中のVMには影響ありません。
2.vCenter Server Applianceのvmware-vsan-healthサービスを再起動
root@vc [ ~ ]# service-control --stop vmware-vsan-health
Operation not cancellable. Please wait for it to finish...
Performing stop operation on service vsan-health...
Successfully stopped service vsan-health
root@vc [ ~ ]# service-control --start vmware-vsan-health
Operation not cancellable. Please wait for it to finish...
Performing start operation on service vsan-health...
Successfully started service vsan-health
3.vSphere Web ClientからvSANパフォーマンスサービスをOff/Onを実施
(※過去のvSANパフォーマンス統計データが削除されます)
vSANクラスタ > 設定 > 健全性とパフォーマンス > オフにする
4.全vSAN HostのvSAN Storage Providerの証明書の確認
vCenter Server > 設定 > ストレージプロバイダ > vSAN Provider "ESXi Hostname" > 証明書情報
上記で確認した所、"問題のないホスト"は証明書がPSCから発行されている事に対し、"問題のあるホスト"はvCenterから発行されている事に気が付きました。
※本環境は外部PSCなので、vCenterとPSCが独立して存在しており、本来はPSCから証明書が発行される事が正しい挙動になります。
問題のあるホスト
問題のないホスト
解決策としては、問題のあるホストの証明書を再発行します。
"問題のあるESXiホスト" > 設定 > 証明書 > 更新
※証明書の再発行をすると、ESXiホストのHAエージェントが再起動しますので、クラスタでHAを有効化している場合は、予期せずVMがフェールオーバーする可能性があります。
証明書の再発行後、vSAN健全性テストを実施して、パスする事を確認します。
同様の事象が発生した場合は、参考にして頂けると幸いです。
関連KB
https://kb.vmware.com/s/article/2150570
https://kb.vmware.com/s/article/52567
以上です。
