vSphere環境の証明書周りをまとめてみた

この投稿はvExperts Advent Calendar 2019における18日目の投稿ですm(     )m。

adventar.org

証明書の管理、してますか？ 

皆さん、証明書はきちんと管理されていらっしゃるでしょうか。

「証明書？あぁ、だいたい10年有効期限があるし、HW保守なんてだいたい7~8年で切れるから気にする頃には環境がリプレイスされてて関係ないでしょ(鼻ﾎｼﾞ」

 ちょっと待ってください。
2017年のCA/Browser Forumで、SSL証明書の最大有効期間は825日（2年3か月）に短くすることが可決されました。
VMCA(VMware 認証局)で発行される証明書も、実はこの採択に追従しています。

  VMware vCenter Server 6.5 Update 2 リリース ノート

  VMware vCenter Server 6.0 Update 3g リリース ノート

VMware 認証局 (CA) 証明書のデフォルト有効期間が 2 年に短縮される
すべての VMware 認証局証明書のデフォルトの有効期間が 10 年から 2 年に短縮されました。
CA/Browser Forum の勧告のとおり、VMware 認証局証明書は 825 日以内に期限切れになります

つまり、、、早ければ2020年はポツポツ証明書が切れ始めてきます。

この記事を読んで、今のうちに対策を進めましょう。

 証明書の有効期限を確認する - VMCA(VMware 認証局)で管理される証明書

では早速証明書の有効期限の確認をしましょう。

vCSA、PSC(vSphere 6.7)

html5 Client [メニュー] > [管理] > [証明書の管理] へアクセスし、

vCSA/PSC それぞれのFQDN で各アプライアンスで管理している証明書が確認出来ます。

User/passは SSOユーザーです。

vCSA：

PSC:

vCSA、PSC(vSphere 6.0/6.5)

  h ttps://<PSCのFQDN>/psc へアクセスし、 [Certificate Management]よりvCSA/PSC それぞれのFQDN で各アプライアンスで管理している証明書が確認出来ます。

本環境は6.5.0-7515524 (U1e)環境なので2年じゃありませんね。

vCSA:

PSC:

ESXi(vSphere 6.0/6.5/6.7で共通)：

各ホストの[設定] > [証明書]

vSAN環境の場合(vSphere 6.0/6.5/6.7で共通)：

vCenter > [設定] > [ストレージプロバイダ]

 証明書の有効期限を確認する - STS(Security Token Service)証明書

vSphere 6.0/6.5/6.7で共通

web Clinet > [管理] > [Single-Sign On] > [設定] > [証明書] > STS署名

※操作した限りだとhtml5 Clientからは確認する場所が無かったです(移動した？)

次回の記事ではそれぞれの更新をためしてみます。


 

参考文献：

 vSphere で証明書を使用する場合

 Security Token Service (STS)

続・vSAN Cluster全停止/起動時における注意

vSAN Cluter全停止/起動時に関して、

vSphere6.7U3 がReleaseされたことでupdateが出ましたね。
  - Using a built-in tool to perform simultaneous reboot of all hosts in the vSAN cluster (70650

    https://kb.vmware.com/s/article/70650

**6.7U3未満で必要な作業は過去の↓記事をご参照ください。

kcana.hatenablog.jp

今まではcrontabで一斉にvsan Network TAGを外す/付け直す という手順が必要でしたが、

reboot_helper.py prepare/recover を実施することでユーザー側の操作が楽になっています。

”Note: This solution is only applicable to the vSAN cluster with all hosts on 6.7 Update 3 or later.”

 とあるため、6.5での対応は期待薄です。

検証環境をこれからUpgradeして試してみよっと。

vSAN Cluster全停止/起動時における注意

**12/20 追記

6か月ぶりのご無沙汰です。

vExperts Advent Calendar 2018 12/14分の寄稿になります。

今週、vSAN Clusterの全停止/起動に際して注意が必要なVMware KBが出ました。

 - A simultaneous reboot of all hosts in the vSAN cluster may result in data unavailability after a single failure (60424)
  https://kb.vmware.com/s/article/60424 

この記事を見つけたとき日本語版が無かったのでせかせか手順を
まとめていましたが,昼過ぎに日本語版がreleaseされていました...結果オーライ？
 - vSAN クラスタで全てのホストを同時に再起動する際に単一障害により利用不可のデータが発生する (60424)
 https://kb.vmware.com/kb/60424?lang=ja

KBに添付されているシェルスクリプトを停止/起動時にcronで実行することで
ホスト上の vsan network tag をremove/addし、vSANトラフィックを明示的に制御しています。
本記事では、簡単に行間の補足をしておきたいと思います。

そもそもvSAN Cluster全体を停止するときのオプションは"データの移行なし"で正しいの？

→ はい。逆にそれ以外のオプションはNGです。  

     VMware社で紹介している"正しいvSANクラスタ停止手順"を実行した際に、

    いくつかの問題を確認したことで今回のVMwareKBが公開されているようです。    

    vSAN クラスタのシャットダウン

なぜNTP同期が必要なの？

→  確実に同じタイミングで全Nodeの vsan network tag removeが出来るようにするための処置です。

「 Node State が “Master”であることを確認します」とは何を意味しているの？

→ 各ESXi Nodeが Single vSAN Roleの状態になったかをチェックしています。

     vSAN Clusterは Master / Backup/ Agent という役割をそれぞれ担います。

     vsan network tag removeが正しく処理されたかをチェックしています。

停止時にcrontabへ登録した追加コマンドを 再起動後に明示的に消すような記載が無いけど大丈夫なの？

→ はい。ESXiでは /var/spool/cron/crontabs/root にcrontabにあたる定期実行のスクリプトコマンドが記述されていますが、こちらは/var配下のためホストを再起動するとクリアされます。今回は不要ですが、再起動後もcronの設定を保持したい場合は

以下VMware KBに準じて /etc/rc.local.d/local.sh に記述します。ただし、VMware社でも特別な状況でない限り勝手に編集することは推奨していません。

 - ESX/ESXi で rc.local または sh.local ファイルを変更して、起動中にコマンドを実行する (2043564)

   https://kb.vmware.com/s/article/2080563

In CMMDS: true を確認する意図は何？

→CMMDS(Clustering Monitoring, Membership, and Directory Services)できちんとvSAN Diskとして管理下に置かれているかをチェックするためです。正しく管理されている場合、以下のような出力となります。

# esxcli vsan storage list |grep -e "Device: naa." -e "In CMMDS:" -e "Used by this host:" -e "Is SSD:" -e "Is Capacity Tier:" | xargs -n 17 | sort -k 6 -t ":"  

Device: naa.58ce38ee20qw3f39 Is SSD: true Used by this host: true In CMMDS:true Is Capacity Tier: false

Device: naa.5000cca02d9c4128 Is SSD: false Used by this host: true In CMMDS:true Is Capacity Tier: true

Device: naa.5000cca02d3280 Is SSD: false Used by this host: true In CMMDS:true Is Capacity Tier: true

Device: naa.5000cca32cc390 Is SSD: false Used by this host: true In CMMDS:true Is Capacity Tier: true

Device: naa.5000cca23950 Is SSD: false Used by this host: true In CMMDS:true Is Capacity Tier: true

 「$ cmmds-tool find -f python | grep -C5 CONFIG_STATUS | grep content | grep -v "state....7\|state....15"」は何をチェックしているの？

→ vSAN データオブジェクトが正常なステータスであるかどうかをチェックしています。stateが7 か15 であれば、オブジェクトのstateがhealthまたはavailableであることが証明されます。それ以外のステータスとなっている場合はデータに影響がある可能性があります。まずは各仮想マシンの起動可否含め確認することが推奨されます。データオブジェクトに影響がないスクリプトを今回紹介している..けれども 念のため確認してください、ということですね。

いかがでしたでしょうか。 

vSANは起動処理に時間がかかる(経験としては1時間程度かかった場合も)ことがArchitecture Design上起こり得るとしてVMware KBで紹介されています。

 - Initializing vSAN during boot takes a longer time (2149115)
   https://kb.vmware.com/s/article/2149115 

不意にこういった事象に見舞われた場合にも備え,
vSAN Cluster全停止の際は本VMwareKBの処置を実施していきたいですね。

今後計画停電などがある際は注意したいですね。

明日のvExperts Advent Calendar 2018は Yuki Kawamitsu   さんの投稿です。

お楽しみに！

ワンライナーでvSANステータスチェック!! ディスク編

最近ワンライナーという宗教(?)にハマりつつあります。

決め打ちのコマンドをポン！ と叩けば、整理された目的の情報が手に入る というのは気持ちがいいものです。

本記事はvSAN環境でディスクステータスを手っ取り早くチェックするためのワンライナーをご紹介します。

これらのコマンドを叩いて得られた情報をみれば、その環境のディスクステータスが正常かどうか？が

サックリ分かります。なるべくversion依存の無いよう、標準コマンドでまとめてみました。

動作検証はvSAN6.2~6.6で行っています。

ディスク正常性チェック その1

# esxcli vsan storage list |grep -e "Device: naa." -e "In CMMDS:" -e "Used by this host:" -e "Is SSD:" -e "Is Capacity Tier:" | xargs -n 17 | sort -k 6 -t ":"  

 
ディスク正常性チェック その2

# vdq -qH | grep -e "Name: " -e "State:" -e "IsPDL?:" -e "Reason:" | sed 'N;N;N;s/\n / /g' | sort -k 2 -t ":"

ディスク正常性チェック その3 

＃ esxcli storage core device list | grep -e "Is Local: true" -e "Vendor:" -e "Model:" -e "Revision:" -e "Is SSD:"  | sed 'N;N;N;N;s/\n / /g' | sort -k 3 -t ":"

コンポーネント正常性チェック

# cmmds-tool find -f python | grep CONFIG_STATUS -B 4 -A 6 | grep 'uuid\|content\|health' | grep 'state\\\":\|health' | sort | uniq -c

デバイスロケーションチェック

# esxcli storage core path list |grep -e "Runtime Name: vmhba" -e "Device: " | xargs -n 5 | sort -n

 

各コマンドでチェックするポイントについては、後日別途記事でまとめたいと思います。

DCLI コマンドからmoref IDをスマートに参照する

vSphere6.5から、DCLI コマンドを使ってmoref IDをスマートに参照する事が可能です。

moref IDとは 

MoRef IDとは、Managed Object Reference IDの略で「管理対象オブジェクト参照 ID」です。
vCenter Serverは、管理対象のオブジェクト --- hostやdatastore、リソースプールや仮想マシン すべてにMoRef IDを付与し管理しています。
管理対象の属性に寄らない一意の値はvSphere SDKにて3rd party製のSWやプラグインとの連携に利用されます。 

vSphere6.0まではPowerCLIを利用するか、mob(Managed Object Blowser)のいずれかで参照する必要がありました。

https://vCenter_Server_IP/mob/ 

 しかしながら、Power CLIはWindows環境が前提として必要。MOBはmoref IDを探すのにクセがあり、使いにくい。と、それぞれで難点がありました。

DCLI コマンドの使い方

 DCLI コマンドは、vCenter Serverさえあれば利用できます。

vCSAへSSHにてrootでログインします。

root@vc [ ~ ]# dcli +interactive
Welcome to VMware Datacenter CLI (DCLI) usage: <namespaces> <command>

To auto-complete and browse DCLI namespaces: <TAB>
If you need more help for a command: vcenter vm get --help
If you need more help for a namespace: vcenter vm --help
For detailed information on DCLI usage visit: http://vmware.com/go/dcli

dcli>

## 仮想マシン ##

 dcli> com vmware vcenter vm list

## ホスト ##
dcli> com vmware vcenter host list

## データストア ##
dcli> com vmware vcenter datastore list

## クラスタ ##
dcli> com vmware vcenter cluster list

## リソースプール ##
dcli> com vmware vcenter resourcepool list

 以上です。

vSAN ネットワーク クラスタパーティション エラーを復旧してみた。

vSAN障害ネタ第2弾。

本記事では、vSAN 6.6.1環境で クラスタパーティション エラー がたまたま発生したので

復旧までの手順をまとめました。

ネタ第1弾もお暇でしたら読んでみてください☟ 

きっかけ_vSAN ネットワーク クラスタパーティションが"失敗"

web clientにて、Node#1に「vSANサービスが有効になっていません」というエラーが表示されていました。

確かに、vSAN DiskGroupとしては存在しているが..

vSAN健全性チェックを見ると、[ネットワーク] > [vSANクラスタパーティション]が失敗。

詳細を見ると、パーティション化していました。

パーティション化しているにも関わらず、他のネットワークチェックはすべてパス。

[vSANクラスタパーティション] のテストがどういった事を実行しているか？

をVMware KBから確認してみました。

  - vSAN 健全性サービス - ネットワークの健全性 - vSAN クラスタ パーティション (2148543)
 https://kb.vmware.com/s/article/2148543 

 * - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -
Q：エラー状態とは、どのような状況を意味しますか。

パーティションが 1 つだけ見つかると、この健全性チェックでは OK ということになります。

複数のパーティションが見つかるとただちに、クラスタは不健全とみなされます。

Q：どのようにエラー状態をトラブルシューティングして修正しますか。

ネットワーク構成の問題を特定して、解決する必要があります。ネットワークに対するその他の健全性サービス チェックは、

ネットワーク パーティションを引き起こした可能性のある根本原因の発見を支援するように設計されています。

構成の誤り以外に、ネットワークの負荷が高く、相当量のパケットのドロップにつながる場合にも、パーティションが発生する可能性があります。
 * - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -* - * -* -* - 

 今回、その他ネットワークの健全性サービスチェックはすべて正常。

加えて本環境はテスト環境としての利用なので、ほとんど負荷はかけていません。

そのため、改めて基本に立ち返って調査することにしました。

調査_vSAN Architectureから現状を理解する

以下はVMware社提供する whitepaper、 "VMware Virtual SAN Layer 2 and Layer 3 Network Topologies" から抜粋した図になります。

vSANでは、各ノードにRole(役割)が存在します。

Masterは Agent/Backup ノードから得た情報を収集・集約した情報を再配布することで、全ノードで一貫したvSANメタデータが共有されます。

これらの通信はvSAN Networkでやりとりされます。なお、vSAN6.6からはユニキャストで通信されます。

つまり、vSANがvSAN Clusterとして正常に動作するためには、以下をクリアする必要がある。

 ✅vSAN Networkが適切に構成されているか ★既にvSAN健全性チェックでpass済★

 ✅Master Group Multicast + Agent Group Multicast でやり取りが出来ているか

 ✅各vSAN Role が適切に役割分担出来ているか

## Master Group Multicast + Agent Group Multicast でやり取りが出来ているか

 connectionとしてはlistできる状態。

実際に今やり取りが出来ているか？はtcpdumpを追加でとれば分かります。

node#1
[root@sds-01:~] esxcli network ip connection list | egrep 224
udp 0 0 224.1.2.3:12345 0.0.0.0:0 65897
udp 0 0 224.2.3.4:23451 0.0.0.0:0 65897

node#2
[root@sds-02:~] esxcli network ip connection list | egrep 224
udp 0 0 224.1.2.3:12345 0.0.0.0:0 65897
udp 0 0 224.2.3.4:23451 0.0.0.0:0 65897

node#3
[root@sds-03:~] esxcli network ip connection list | egrep 224
udp 0 0 224.1.2.3:12345 0.0.0.0:0 65897
udp 0 0 224.2.3.4:23451 0.0.0.0:0 65897

node#4
[root@sds-04:~] esxcli network ip connection list | egrep 224
udp 0 0 224.1.2.3:12345 0.0.0.0:0 518116 VSAN_0x43170ace2318_CMMDSProces
udp 0 0 224.2.3.4:23451 0.0.0.0:0 518116 VSAN_0x43170ace2318_CMMDSProces

## 各vSAN Role が適切に役割分担出来ているか

なんと、Node#1がMasterのRoleとして割り当てられていました。

[root@sds-01:~] esxcli vsan cluster get
Cluster Information
Enabled: true
Current Local Time: 2018-04-28T14:40:11Z
Local Node UUID: 5add76f4-f498-ca86-5b72-246e96ac1870
Local Node Type: NORMAL
Local Node State: MASTER
Local Node Health State: HEALTHY
Sub-Cluster Master UUID: 5add76f4-f498-ca86-5b72-246e96ac1870
Sub-Cluster Backup UUID:
Sub-Cluster UUID: 529b340b-60bc-671c-37b3-5fd2ec850ad8
Sub-Cluster Membership Entry Revision: 0
Sub-Cluster Member Count: 1 ★vSAN Clusterに参加しているnode数★
Sub-Cluster Member UUIDs: 5add76f4-f498-ca86-5b72-246e96ac1870
Sub-Cluster Membership UUID: 9484dd5a-6448-a2f3-8d25-246e96ac1870
Unicast Mode Enabled: true
Maintenance Mode State: OFF
Config Generation: 6e397dda-6b3a-45ce-bf2d-ad1b84adccd5 15 2018-04-28T13:28:07.604

[root@sds-03:~] esxcli vsan cluster get
Cluster Information
Enabled: true
Current Local Time: 2018-04-28T14:41:08Z
Local Node UUID: 5a81f6c9-eda3-e3de-3f01-246e96abf790
Local Node Type: NORMAL
Local Node State: MASTER
Local Node Health State: HEALTHY
Sub-Cluster Master UUID: 5a81f6c9-eda3-e3de-3f01-246e96abf790
Sub-Cluster Backup UUID: 5a81f6c3-66b0-c318-f932-246e96ac0db0
Sub-Cluster UUID: 525f3eba-a578-0034-a0a7-051f6af61134
Sub-Cluster Membership Entry Revision: 12
Sub-Cluster Member Count: 3 ★vSAN Clusterに参加しているnode数★
Sub-Cluster Member UUIDs: 5a81f6c9-eda3-e3de-3f01-246e96abf790, 5a81f6c3-66b0-c318-f932-246e96ac0db0, 5adc877e-70c3-bb20-79ba-246e96ac1b10
Sub-Cluster Membership UUID: d272dd5a-d447-9eca-7091-246e96abf790
Unicast Mode Enabled: true
Maintenance Mode State: OFF
Config Generation: 6e397dda-6b3a-45ce-bf2d-ad1b84adccd5 15 2018-04-28T13:28:07.581

 結果_vSAN Clusterからの離脱/再参加 で改善！

いくつかVMwareの文献を漁りましたが、vSAN Roleの役割を変更するコマンドなどは確認出来ませんでした。

そのため、vSAN Clusterからの離脱/再参加 を実施したところ改善しました。

Node#1をメンテナンスモードへ移行(componentはnode#1に未配置だったため、[データを退避しない]のオプションを選択)し、以下の通り データセンタを移行先に指定します。

移行後、すぐにvSAN健全性エラーは正常化しました。

 再参加させるため、vSAN Clusterへ移行します。

メンテナンスモードを解除したところ、役割がAgentとして認識したことを確認しました。

[root@sds-01:] esxcli vsan cluster get

Cluster Information

   Enabled: true

   Current Local Time: 2018-04-28T15:10:43Z

   Local Node UUID: 5add76f4-f498-ca86-5b72-246e96ac1870

   Local Node Type: NORMAL

   Local Node State: AGENT

   Local Node Health State: HEALTHY

   Sub-Cluster Master UUID: 5a81f6c9-eda3-e3de-3f01-246e96abf790

   Sub-Cluster Backup UUID: 5a81f6c3-66b0-c318-f932-246e96ac0db0

   Sub-Cluster UUID: 525f3eba-a578-0034-a0a7-051f6af61134

   Sub-Cluster Membership Entry Revision: 15

   Sub-Cluster Member Count: 4

   Sub-Cluster Member UUIDs: 5a81f6c9-eda3-e3de-3f01-246e96abf790, 5a81f6c3-66b0-c318-f932-246e96ac0db0, 5adc877e-70c3-bb20-79ba-246e96ac1b10, 5add76f4-f498-ca86-5b72-246e96ac1870

   Sub-Cluster Membership UUID: d272dd5a-d447-9eca-7091-246e96abf790

   Unicast Mode Enabled: true

   Maintenance Mode State: OFF

   Config Generation: 6e397dda-6b3a-45ce-bf2d-ad1b84adccd5 19 2018-04-28T15:07:59.600

以上です。

長文お読みいただきありがとうございました。

皆さまのvSANライフに活かして頂けると幸いです。

predictive DRSの使いどころを考える。

本記事では、vSphere 6.5から実装されたpredictive DRSの使いどころについて考えます。

 現状 日本語で情報があまり出ていないので、使用するかどうか 検討の一助となれば。

Predictive DRSの基本

Predictive DRSは、vSphere DRS(Distributed Resource Scheduler)とvROps(vRealize Operations)を

連携させることで、仮想マシンの配置とリソースのバランスをPredictive(予測)して最適化するための機能です。

そもそもDRSは①仮想マシンの作成/起動 ②5分毎にCPU,memoryリソースをチェックすることで

設定されている移行の閾値に応じてリソースの最適化を行います。

複数のリソースプールがあれば、リソースプール毎に最適化されます。

**vSphere 6.5からはNetwork Aware という機能により物理NICリソースも考慮されます

移行の閾値 は "3" が Defaultの値です。

"1" だとメンテナンスモード実施時のみDRSが動作します。

実際の設定箇所だと以下。

Predictive DRSは、利用状況やペースを把握/分析することに用いられるvROpsと連携する事で、

より「リソース管理の効率化」を果たすことを目的とした機能です。

 本機能を使用するためには、vROpsとvCenter Server 両方で有効化します。

なお、vRealize Operations Manager と vCenter Server それぞれでクロックを同期させる必要があります。

## vROps

 ## vCenter Server

Predictive DRSで抑えるべきポイント

 抑えるポイントは以下2つです。

 1.Predictive DRSは有効化されてから14日後に初めて恩恵を受ける

有効化して13日目までは、通常のDRSに基づいて動作します。

これは14日間を利用してリソース配分の予測値を算出するためです。

時間が経過するにつれ、予測の精度は上昇します。

 2.リソースの移行を判断するメトリックはMAX(A,B)ルールに基づく 

MAX(A,B) = MAX(現在の使用率,予測使用率) 

 ⅰ.予測使用率よりも現在の使用率が高い場合...
      現在の使用率を基にリソースの移行を検討します。

 ⅱ.予測使用率よりも現在の使用率が低い場合...
     予測使用率を"現在の使用率"として扱い,

      先んじて"今後想定されるリソース配分率"になるようDRSが動作します。

      つまり、Predictive DRSは"今後想定されるリソース使用率の上昇"に基づき動作します

Predictive DRSの使いどころ

 Predictive DRSは、「ある程度予測可能な周期的リソース変動」に対して効果を発揮しそうですね。

  ✅ 24h/365d TurnOverで利用されるVDI環境での ログイン/ログオフストーム

  ✅ ECサービス環境での定期セールによるアクセス上昇

  ✅ 動画定期配信サービス環境での接続数上昇

翻って、突発的なリソース消費には対応が難しそうです。

例えば、ノード障害やメンテナンスでDRSが頻繁に動作した際、

Predictive DRSを有効化して日が浅いと想定していないリソース配分が実行される可能性がありますね。

 長く利用していくことで徐々に精度があがり、効果を発揮していきそうです。

参考資料：
- New vSphere 6.5 DRS White Paper released
https://blogs.vmware.com/vsphere/2018/04/new-vsphere-6-5-drs-white-paper-released.html 

- VMware World 2017 : Extreme Performance Series: Predictive DRS - Performance and Best Practices
https://static.rainfocus.com/vmware/vmworldeu17/sess/1496368002323001drsB/finalpresentationPDF/SER2849BE_EMEA_1507847103171001IH7z.pdf 

- INF7827 DRS Best Practices
https://www.slideshare.net/BrianJGraf/inf7827-drs-best-practices 

- vSphere Predictive DRS の構成
  https://docs.vmware.com/jp/vRealize-Operations-Manager/6.4/com.vmware.vcom.core.doc/GUID-D830E36D-08A3-4D1A-87EC-0EC6217D1761.html