vSAN ディスク交換問題
こんにちは。
今回は、
vSAN環境のDiskで障害が起きた際に同時に発生した障害についてご紹介します。
特定条件下（All Flash かつ重複排除が有効になっている環境）では、
予め計画して交換対応をしないと面倒なことになります。
ということで、
ただのCapacity Diskの障害だったはずなのですが、
対応に手間がかかったという話を聞いたので
そんなときの対処法です。
さて、
VMwareも言っている通りの話なのですが、、、
『vSAN環境（All Flash かつ重複排除が有効になっている環境）で、
ディスクグループ内のディスクに障害が発生した場合、
ディスクグループ全体の障害として検知されます。』
上記の様な話（前提）があるので、
本来、、、
『該当のディスクグループを一度予め削除しておいてから交換する』のが
一番だとは思いますが、
（様々な事情で）『ディスクが既に交換されてしまっている』場合、、、
という話の対処方法は一般情報を調べても、、イレギュラー情報？のため、
見つからないと思います。
ということで。
ディスクグループを予め削除せずに、
All Flash構成のvSAN環境で、障害が発生したDiskを交換するとどうなるか、、
（一例だとは思いますがご参考まで）
『交換してないDiskにゴミ情報が残存する。（ことがある？）※』
上記のDiskが使えないことで作り直すべき新しいディスクグループを
構成できなくなるんですよね。
今回のエンドユーザ様のケースでは、
※の対処のためにパーティション情報を全てクリアするという
対処方法で対応した様ですが、
他の原因が問題だった場合にはvSANでDisk情報を管理しているDBに
情報を再認識させるために、ホストの再起動が必要だったりすることも、、、
必要な様です。
ちなみに、余談ですが、vSAN環境のDisk交換作業の際に
ホストをメンテナンスモードにして対応しようとすると、
おそらくVSAN.ClomRepairDelayがデフォルト設定のまま1時間では
時間的に厳しいと思いますので、
VSAN.ClomRepairDelayの値は変更を事前に検討することをお勧めします。
VSAN.ClomRepairDelayのKBはこちらです。
本日はここまで。
ご参考になれば、幸いです。
vSAN環境のクラスタのホストでメンテナンスモードにできないことがある件
こんにちは。
今回は、
vSAN環境のクラスタのホストでメンテナンスモードにできないことがある件
についてご紹介します。
皆さんもご存じの通り、vSANクラスタでホストをメンテナンスモードに
入れるためには、ケースバイケースで実施する手順が異なります。
①特定のホストを単独で一時的にシャットダウン（再起動）するケース
②特定のホストを単独で永続的にシャットダウンするケース
③クラスタ全体をシャットダウンするケース
上記の様に3パターンのケースがありますが、
今回は、①のケースでメンテナンスモードに1時間近く経っても変更できず、
予定していた作業を再スケジュールせざるを得なかったという話があったので、
そのお話です。
①のケースなために、ホストをメンテナンスモードに入れる際の使用する
オプションは「アクセシビリティを確保する」な訳ですが、
今回の様に（おそらく、あまり容量的に使用してない環境だったりすると）
移行容量『0Byte』で入れると表示される場合があると思います。
ですが、、、今回の件、
データ移行が0Byteのはずなのに、、、
1時間近く経ってもメンテナンスモードにホストがならない。
原因は、、、
『vSANクラスタ内のホストとしてのメンテナンスモード』と、
『vSphere ESXi？としてのメンテナンスモード』
この2つが別々に管理？されている「仕組み」に起因していました。
状態としては、、、
vSAN としてのメンテナンスモードは「ON」になっていて、
vSphere側のメンテナンスモードが有効になるのをずっと待っていた
状態だったようです。
こういう事象が発生する原因としては
hostdのプロセスでメモリ確保に問題があったりすると、、、
起こりうるそうです。
と、いうことで、対処方法です。
hostd、vpxdのサービスをESXiで再起動をしてみて、
もう一度やってみる、という方法です。
（何度か、、サポートの方にお話していますが、
vSANデータストアの容量問題でなければ、、、
この結論に至ります。）
ちなみに、vSANとしてのメンテナンスモードがONになってるか、、の確認は、
localcli vsan cluster get
このコマンドをホストで実行します。
メンテナンスモードにならない、ということで確認してvSANだけONになっている様なら、、、
その時点でvSANメンテナンスモードはCancelしてしまって良いと思います。
Cancelのコマンドは、
localcli vsan maintenancemode cancel
こちらです。
再度、
localcli vsan cluster get
を実行すると、OFFに変わっているはずです。
本日はここまで。
ご参考になれば、幸いです。
Horizon 環境を監視するためのツールとなった「ControlUp」
こんにちは。
今回は、
Horizon 環境を監視するためのツールとなった「ControlUp」について、
ご紹介します。
vRealize Operations Manager for Horizon (V4H)はサポート対象外となり、
リソース状況の傾向の情報収集を行い、対策するためには
OEM提供されるControlUp を使用することになりました。
VMware Horizon 8 に関するお知らせ、および価格設定とパッケージの更新 (80146)
また、こちらの以下のkbの様にVMwareからも
サポートのドキュメントが提供されるようになっています。
ControlUp Support Documentation (79615)
私が直接応対しているエンドユーザではないのですが、
グループ内のメンバーが、メーカー（ControlUp社）から直接導入していて
面白い（苦労？トラブル？）話を聞けたので、
私の方からも皆さんにご紹介させて頂こうと思います。
コトの発端は、
ControlUpのConsoleから見た監視対象（Agentが入った仮想デスクトップ）が
Disconnect状態になるという事象が発生したことでした。
（この環境は以前はV4Hで情報を収集していましたが、
その様な問題はなかった（、、、ようです）。）
調べてみていくと分かったのが、
Disconnect状態になった複数の仮想デスクトップには共通点があり、
実際のIPアドレスとDNS上のAレコードと異なっている、、、。
この環境では動的にレコードを更新させない運用となっているため
上記のレコード差異が日常的に発生するために、
ControlUp ConsoleおよびMonitorから名前解決が出来ず、
ControlUpからAgentを検出できなくなったことが原因で、
メーカからも『名前解決できないと駄目だ』という回答もありました。
DNSサーバの設定を変更して動的更新を出来れば問題が解決したのですが、
他のシステムにも影響が出てしまうために
今回の環境では、『既存環境には影響与えず』に
ControlUp用のHostsファイルを数分おきに作成し、
ControlUpのConsoleおよびMonitorのhostsファイル
（\Windows\system32\drivers\etc\hosts）
を上書きしていくという方法で対応している様です。
なんという力技、、、とも思いますが、
ControlUp社からも
「hostsファイルを更新し続けられるなら、良い方法だ」
と、お墨付きをもらっている様です。
本日はここまで。
ご参考になれば、幸いです。
NSX-Vのサポート期間
こんにちは。
今回は、
NSX-Vのサポート期間についてご紹介します。
NSX-Tが出てきてから、結構時間も経っておりますが、、、
NSX-Vの最新（最終）バージョンである
NSX for vSphere 6.4が2022年1月16日でGeneral Supportが終了となります。
2022年1月17日以降は、
Technical Guidanceというフェーズに移行され、
障害や問題があった場合に過去のKBからの情報提供は受けられますが、
過去の情報にない場合は情報が得られない形です。
正直、NSX-Tに関してはNSX-Vの延長上にあるものではないと思いますので、
（ネットワーク仮想化のためのインフラとしてはあるべき形と考えられますが、、）
移行されずに様子を見ている環境もあるのではないかと思います。
そんなわけで、
今後の対応方法についてです。
１．のNSX-Tへの移行に関しては、ライセンス的には追加費用無しで
無償バージョンアップが可能ですが、ライセンスの切り替え実施にあたり
エンドユーザ（管理者）からの手続き（申請書および署名提出）と
VMware社の承認が必要となります。
２．のTechnical Guidanceの期間は2023年の1月16日までのため、
1年延命、、、できますが、1の対応をするしかないですかね。
３．これは、、、スペシャルプランです。
これまでと同じサポートを受けられますが、、、
費用もスペシャル、、、です。
なんと、1契約ｘｘｘｘ万円という話を口頭で聞きました。
どうしてもバージョンアップ作業を行えず、
Technical Guidanceでは済ませられない、、となると使うのでしょうか、、、？
本日はここまで。
ご参考になれば、幸いです。
VMware Carbon Black Cloud 機能のご紹介(Live Response編)
こんにちは。
今回は、VMware Carbon Black Cloud の「Live Response」機能をご紹介します。
「Live Response」とは、VMware Docsによると、
「Live Response を使用して、リモート調査を実行し、進行中の攻撃を阻止し、コマンド ライン インターフェースを使用して脅威を修復します」とあります。
これは、特定のエンドポイントに対して、リモートから対話型で制御ができ、
任意のOS標準コマンドで操作が可能となります。
「Live Response」ツールの主な利用例は以下の通りです。
・調査のための追加情報取得
・マルウェアリムーバ/クリーナーの実行
・プロセスやメモリ情報の取得
・レジストリの参照や変更
・ファイルのアップロード・ダウンロード・削除
・任意のプログラムの実行
etc
具体的なコマンド例は
任意のOS標準コマンドでいろいろできそうです。
使う場面がないことが一番なんですけど、いざという時をシュミレーションして、運用フローや手順書を予め整備したいなと、、、
本日はここまで。
ご参考になれば、幸いです。
VMware Carbon Black Cloud 機能のご紹介(Live Query編)
こんにちは。
今回は、VMware Carbon Black Cloud の「Live Query」機能をご紹介します。
「Live Query」とは、VMware Docsによると、「Live Query を使用すると、エンドポイントの質問をして、セキュリティと IT ハイジーンを改善するためのエリアをすばやく特定できます」とあります。
はて・・もう少しかみ砕いて言うと、
まず、ITハイジーン（IT Hygiene）ですが、ハイジーンとは英和辞典では衛生状態と訳します。つまり、ITハイジーン（IT Hygiene）とは、エンドポイントの「衛生状態」を管理するものです。
Carbon Blackでは、「Live Query」機能を用いて、常にエンドポイントの健全性を維持するため、内部及び外部からの脅威から保護では、定期的且つ継続的な取り組みが必要です。
ではでは、「Live Query」の利点を以下にまとめてみました。
・端末状況の可視化
・定期的な検索による運用自動化
・設定確認作業の迅速化
具体的に「Live Query」でできることは、
・脅威に関連する1,500 種類以上の情報を検索可能(オンデマンドも可)
・豊富な検索クエリのテンプレートの提供
・検索クエリのテンプレートは随時更新
・定期的に確認が必要な検索項目はスケジューリングが可能
などが挙げられます。
本日はここまで。
ご参考になれば、幸いです。
vSphere7.0環境（ESXi）でvSSの設定変更ができない問題
こんにちは。
今回は、
vSphere7.0環境（ESXi）でvSSの設定変更ができない問題があった件
についてご紹介します。
前回（vSphere 6.0環境からvSphere 7.0環境での仮想マシン移行時に発生した障害）
の環境の話なのですが、
vCenterから統合管理するvDS（virtual Distrbuted Switch）ならまだしも、、、
ESXi単独でも設定できて、障害が起こりづらいと思われている
vSS（virtual Standard Switch）の設定変更（新規ポートグループの追加）に
失敗するという事象が発生していました。
（ツクヅク、ここの担当をしている〇高氏は『引き』が強いなーと思いますが、、、笑）
事象としては、
今回もタイトルの通りで、
vSSでポートグループを新たに作成しようとすると、エラーが発生して完了できない
という事象でした。
切り分けのためにやった作業としては、定番だとは思いますが、、、
- vCenterから変更できなくても、ESXiのHost Client からなら設定変更が
出来るのではないか、、、と、該当のホストに個別にログインして
変更を試みましたが状況としては変わらず。
- ホストをメンテナンスモードにして再起動しても状況は変わらず。
と、やり方の問題や一時的な問題ではないと思われたため、
hostdのログを確認したところ、ネットワーク設定にエラーが出ており、
vSwitch0のチーミングに変なところがあった様で、
実際、vSwitch0のコンフィグをCLIで確認すると
vSwitch0に紐づいてはいないインタフェース（vmnic xx）が、、、
何故かManagement Networkのポートグループに紐づいていた、、、。
というのが問題だったようです。
対応方法としては、、、
問題になっていたvSwitch 0 に対して
vmnic xxを一度明示的に追加してvmnic xxを明示的に削除する。
こうしたことで、hostd.logのエラーも出力されなくなり、
無事（？）設定変更が行えた、、、とのことでした。
本日はここまで。
ご参考になれば、幸いです。
