登錄vCenter的Web管理界面也就是vSphere Client的時候頁面還沒完全加載出來先彈了一行紅字500 獲取身份提供程序時出錯。再打開瀏覽器開發(fā)者工具翻一下或者直接上vCenter看nginx日志大概率還能看到一個熟悉的老朋友——no healthy upstream。這個報錯組合在vSphere 7.0 Update 3之后的版本里相當(dāng)?shù)湫蛌Sphere 8.0全系也經(jīng)常遇到。很多運維同行第一次碰見第一反應(yīng)就是把vmware-sso重啟一遍結(jié)果等了半天報錯原封不動躺在那里。這里不打算給一個“萬能重啟命令”就完事。我會把這條報錯鏈路拆開講清楚再按真實排障順序走一遍最后落到磁盤空間打滿、Java進程僵死、身份提供程序配置損壞這三類高頻根因的具體處理方式。無論你是剛接手vCenter還是已經(jīng)被這個500折磨了幾個小時跟著這條線走大部分環(huán)境都能在半小時到一小時內(nèi)定位到問題。1. 500與no healthy upstream登錄請求卡在哪一環(huán)1.1 先分清報錯的是“登錄動作”還是“登錄頁加載”這個錯誤有兩種出現(xiàn)方式處理思路完全不同第一步得先分清。第一種打開 https://vcsa_fqdn/ui 之后登錄頁本身就沒加載完整頁面上方直接提示“500 獲取身份提供程序時出錯”這時候你還沒輸入賬號密碼。第二種登錄頁正常顯示你輸入 administratorvsphere.local 并點擊登錄之后才報錯。本文討論的主要是第一種也就是登錄頁加載階段的報錯這種情況最能迷惑人因為看起來像認(rèn)證失敗實際上問題出在更前面的環(huán)節(jié)。為什么登錄頁在加載階段就要去“獲取身份提供程序”因為vSphere Client的登錄頁面默認(rèn)要把可用的身份提供程序列出來至少得知道當(dāng)前這臺vCenter注冊了哪些身份源才能決定認(rèn)證請求發(fā)到哪個服務(wù)去處理。這個動作由頁面里的JavaScript在后臺悄悄發(fā)起對應(yīng)一個后端接口。接口掛了頁面就只能把錯誤拋給你。1.2 這個500到底是誰吐出來的很多人看到500下意識以為是某個Java應(yīng)用拋了業(yè)務(wù)異常。但在vSphere Client登錄頁這個場景里500通常是nginx反向代理層直接吐出來的不是Java應(yīng)用“有意”返回的。瀏覽器的請求先到達(dá)vCenter的443端口那里站著一個nginx。nginx負(fù)責(zé)HTTPS加解密、URL路由、把請求轉(zhuǎn)發(fā)到合適的后端服務(wù)。vCenter的登錄頁請求會被轉(zhuǎn)發(fā)到身份服務(wù)那一支nginx給這些后端服務(wù)配置了一個upstream池子里面是一個或幾個后端節(jié)點。每次轉(zhuǎn)發(fā)前nginx會判斷池子里有沒有能用的節(jié)點判斷依據(jù)就是健康檢查。如果池子里一個健康節(jié)點都沒有nginx沒法轉(zhuǎn)發(fā)就只能自己返回一個錯誤響應(yīng)。在nginx的error.log里這個情況通常寫作“no live upstreams while connecting to upstream”或者“no healthy upstream”。在vSphere Client界面上你看到的就是HTTP 500 “獲取身份提供程序時出錯”。劃重點接到這個報錯不要第一時間懷疑SSO安全策略、賬號鎖定、證書綁定之類的東西。先搞清楚后端服務(wù)到底健不健康。方向?qū)α藛栴}就解決了一半。2. vSphere身份登錄的調(diào)用鏈前端、反向代理與身份服務(wù)2.1 一條登錄鏈路里都有誰vCenter不是一個單體程序vSphere Client的登錄功能由好幾個組件協(xié)作完成。熟悉這條鏈路排查才能有的放矢瀏覽器 [HTTPS 443] vCenter nginx反向代理 /ui -- vsphere-ui (Java/Tomcat Web應(yīng)用) /websso -- vmware-sso / vmafdd /identity -- identity service (vSphere 8.0)這幾個組件分工大致如下vsphere-uivSphere Client這個Web應(yīng)用本身跑在Tomcat里。前端JS、大部分API都在這里。nginx反向代理vCenter所有對外Web請求的入口負(fù)責(zé)TLS證書、路由以及把請求轉(zhuǎn)發(fā)給后面的Java服務(wù)。vmafddVMware認(rèn)證框架守護進程管理SSO域內(nèi)本地令牌、身份源探測。vmware-ssoSTS安全令牌服務(wù)登錄成功后簽發(fā)SAML或OIDC令牌。identity service / identity sourcesvSphere 8.0里新引入的VMware Identity Services專門管理身份提供程序和身份源。登錄頁加載“身份提供程序”列表時請求走的不是vsphere-ui而是身份服務(wù)這一支。所以當(dāng)nginx說“no healthy upstream”的時候故障點往往在認(rèn)證/身份服務(wù)相關(guān)進程而不是前端靜態(tài)資源服務(wù)。2.2 nginx的upstream和健康檢查規(guī)則搞懂nginx的upstream機制是這個排障里特別關(guān)鍵的一環(huán)。upstream就是一組后端服務(wù)器地址。nginx維護著每個節(jié)點的健康狀態(tài)。vCenter內(nèi)置nginx通常使用被動健康檢查也就是通過實際轉(zhuǎn)發(fā)請求的結(jié)果來判斷節(jié)點是否健康。如果轉(zhuǎn)發(fā)時發(fā)生TCP連接失敗、超時、或者上游返回502/504這類狀態(tài)碼nginx會把這個節(jié)點標(biāo)記為失敗失敗次數(shù)超過max_fails之后在fail_timeout時間內(nèi)不再向這個節(jié)點轉(zhuǎn)發(fā)。“no healthy upstream”的意思是整個upstream池子里每一個節(jié)點都被標(biāo)記成了不可用或者根本沒有節(jié)點能建立連接導(dǎo)致nginx徹底無法轉(zhuǎn)發(fā)。翻譯成人話就是nginx想找一個人干活但名單上所有人要么不接電話、要么聯(lián)系不上于是它兩手一攤告訴你——找不到人。2.3 為什么后端不健康登錄頁立刻就有感覺身份服務(wù)屬于高頻依賴。vSphere Client登錄頁只要打開就要獲取身份提供程序列表。也就是說這個故障不是在你點擊登錄的那一刻才出現(xiàn)而是頁面加載階段就已經(jīng)發(fā)生了只是界面到很晚才把錯誤拋出來。身份服務(wù)不健康的常見誘因按真實排障中出現(xiàn)的頻率排序磁盤空間打滿尤其 /storage/log 和 /storage/archive 最容易爆。Java進程OOM或者線程池被耗盡進程“假死”。服務(wù)間證書過期、NTP時鐘偏移導(dǎo)致內(nèi)部HTTPS調(diào)用TLS握手失敗。身份提供程序配置損壞后端組裝列表數(shù)據(jù)時拋異常。這也就是為什么后面所有操作都圍繞“服務(wù)健康”展開而不是糾結(jié)“認(rèn)證為什么失敗”。3. 完整排障鏈路從服務(wù)狀態(tài)到日志證據(jù)鏈3.1 給vCenter服務(wù)做整體體檢一開始別急著翻日志先確認(rèn)vCenter整體服務(wù)狀態(tài)。SSH登錄到VCSA執(zhí)行service-control --status --all重點觀察這幾個服務(wù)vsphere-ui、vmafdd、vmware-sso、identity service8.0、vmon。如果有一大片服務(wù)狀態(tài)異常優(yōu)先懷疑是不是系統(tǒng)級問題如果只有個別服務(wù)DOWN聚焦到那一個組件上。再看更細(xì)一層的健康狀態(tài)/usr/lib/vmware-vmon/vmon-cli --healthvmon-cli的輸出比service-control更貼近故障表象能明確告訴你服務(wù)是否通過健康檢查。注意服務(wù)狀態(tài)顯示RUNNING不代表健康檢查通過。更常見的是進程還在、端口還開著但服務(wù)已經(jīng)“假死”對外表現(xiàn)就是“no healthy upstream”。3.2 磁盤與資源檢查最容易翻車的隱形坑很多排障卡在日志分析半天最后發(fā)現(xiàn)是磁盤滿了。所以我會把磁盤檢查放在日志之前。df -h free -m topVCSA有幾個分區(qū)要特別留意/storage/log、/storage/archive、/storage/db還有根分區(qū)。其中/storage/log和/storage/archive是故障高發(fā)區(qū)日志和歸檔日志一旦累積過多使用率直接就沖到100%。磁盤滿為什么會導(dǎo)致健康檢查失敗這里有明確的因果關(guān)系Java服務(wù)運行時要寫日志、創(chuàng)建臨時文件磁盤滿時寫入失敗輕則日志丟失重則進程直接退出。就算進程沒退出健康檢查線程也要依賴線程池正常調(diào)度系統(tǒng)資源耗盡時線程池排隊健康URL的響應(yīng)就超時了。nginx去探測后端發(fā)現(xiàn)后端根本不響應(yīng)或者響應(yīng)超時自然就把節(jié)點標(biāo)記為unhealthy。如果你看到df輸出已經(jīng)100%先不要往下排查優(yōu)先騰空間否則重啟多少次服務(wù)都是白搭。3.3 服務(wù)日志證據(jù)收集磁盤確認(rèn)沒問題之后開始翻日志。我習(xí)慣把日志路徑和關(guān)注點列成一張表方便對照服務(wù)日志路徑重點關(guān)注關(guān)鍵詞vsphere-ui/var/log/vmware/vsphere-ui/logs/OutOfMemoryError, Connection refused, No space leftvmafdd/var/log/vmware/vmafdd/vmafdd.logtoken, cert, timeout, errorvmware-sso/var/log/vmware/sso/SAML, STS, health, 500identity service (8.0)/var/log/vmware/identity/ 或 /var/log/vmware/vmidentity/identity provider, metadata, crash先做一次粗粒度檢索grep -i OutOfMemoryError\|Connection refused\|No space left /var/log/vmware/vsphere-ui/logs/*.log | tail -n 50如果日志里有java.lang.OutOfMemoryError: Java heap space那基本可以判斷是vsphere-ui的堆內(nèi)存出了問題。如果看到No space left on device那磁盤問題實錘了。如果出現(xiàn)大量Connection refused說明某個后端服務(wù)確實沒在監(jiān)聽端口。這一步的目的不是直接用日志定案而是把嫌疑范圍縮小到一個或兩個組件上。3.4 nginx日志還原“500現(xiàn)場”找到nginx日志是還原故障現(xiàn)場的關(guān)鍵一步。vCenter內(nèi)置nginx日志的位置我記得常見的有兩個路徑一個是 /var/log/nginx/另一個是在vsphere-ui自己的logs目錄下。兩個都看一眼根據(jù)實際版本確定。grep -i no healthy upstream\|no live upstreams /var/log/nginx/error.log | tail -n 50再看access.log里對應(yīng)的500請求grep 500 /var/log/nginx/access.log | tail -n 20重點看error.log里upstream失敗的具體原因這個細(xì)節(jié)能區(qū)分故障類型connect() failed (111: Connection refused)后端端口根本沒監(jiān)聽進程掛了。connect() failed (110: Connection timed out)后端進程可能還在但已經(jīng)假死無法正常響應(yīng)。connect() failed (104: Connection reset by peer)后端主動斷開連接多半是應(yīng)用層異常。結(jié)合這條信息和前面service-control的輸出基本就能判斷到底是哪個后端服務(wù)不健康了。3.5 時鐘同步與證書容易忽略的隱性因素如果上面幾步查下來一切正常服務(wù)都在、日志也沒明顯異常這時候就要考慮兩個隱性因素時鐘和證書。身份認(rèn)證對時間極度敏感。vCenter內(nèi)部服務(wù)之間走的是HTTPS和令牌機制時鐘偏移超過一定范圍令牌時間戳校驗就會失敗。NTP有問題的vCenter最典型的癥狀之一就是身份服務(wù)間歇性不健康。timedatectl chronyc tracking檢查NTP同步狀態(tài)如果時間偏差太大先把時間源修好。修完時鐘之后很多詭異的認(rèn)證報錯會自己消失。證書檢查稍微重一點但也要會看/usr/lib/vmware-vmca/bin/certool --list查看機器SSL證書、solution user證書和vmdir證書的有效期。如果哪個證書過期了服務(wù)間TLS握手就已經(jīng)開始失敗nginx把上游判不健康只是遲早的事。日志里的SSL handshake failure、certificate expired都是線索。3.6 證據(jù)鏈怎么串到這里排障信息基本齊了。把證據(jù)串起來就能得出根因。舉個例子nginx error.log顯示upstream指向127.0.0.1:9443失敗說明故障在vsphere-ui這個后端。vsphere-ui日志里出現(xiàn)OutOfMemoryError。再看df -h/storage/log已經(jīng)100%。這條證據(jù)鏈非常清晰磁盤滿導(dǎo)致Java服務(wù)OOM或者寫日志失敗vsphere-ui無法正常響應(yīng)nginx健康檢查判定失敗最終登錄頁報“獲取身份提供程序時出錯”。這套“串證據(jù)鏈”的思維方式比單看任何一個日志都管用。4. 高頻根因與修復(fù)實操先給一張總覽表三類高頻場景一眼看清場景典型現(xiàn)象優(yōu)先處理動作磁盤空間打滿df顯示/storage/log或/storage/archive 100%服務(wù)反復(fù)重啟清理日志與歸檔滾動重啟受影響服務(wù)Java OOM/僵死日志出現(xiàn)OutOfMemoryErrorvsphere-ui響應(yīng)超時重啟服務(wù)評估JVM堆與物理內(nèi)存身份提供程序配置損壞登錄頁單獨報“獲取身份提供程序時出錯”服務(wù)本身健康修復(fù)或刪除異常身份源重新加載配置4.1 場景A磁盤空間打滿引發(fā)的服務(wù)雪崩磁盤滿導(dǎo)致服務(wù)大面積異常的場景我遇到得最多處理順序也最講究。先不要急著刪文件先定位到底哪些目錄占了空間du -xh --max-depth1 /storage 2/dev/null | sort -rh | head -20通常大頭就兩個/storage/archive和/storage/log。/storage/archive下面全是被壓縮歸檔的舊日志保留價值其實有限。確認(rèn)保留周期之后直接清理rm -rf /storage/archive/*.tgz清理日志文件時有個細(xì)節(jié)很多人不知道不要用rm用重定向清空。 /var/log/vmware/vsphere-ui/logs/vsphere-ui-runtime.log /var/log/vmware/vsphere-ui/logs/catalina.out為什么因為Java進程可能還持有這個文件的文件句柄你用rm刪掉磁盤空間不會立刻釋放反而要等進程重啟才回收。用清空空間立刻就回來了?？臻g釋放之后重啟受影響的組件service-control --restart vsphere-ui驗證方式df -h確認(rèn)使用率降下來了service-control --status --all確認(rèn)服務(wù)狀態(tài)正常再回到瀏覽器刷新登錄頁身份提供程序應(yīng)該能正常加載出來了。4.2 場景Bvsphere-ui Java進程OOM或僵死vsphere-ui是個Java應(yīng)用OOM是這類“no healthy upstream”報錯的高發(fā)根源。日志里的OutOfMemoryError是最直接的證據(jù)。如果沒抓到OOM但vsphere-ui日志里頻繁出現(xiàn)Full GC耗時過長或者健康檢查URL響應(yīng)超過幾十秒也基本可以按僵死處理。先用最直接的方式恢復(fù)service-control --restart vsphere-ui服務(wù)重啟后馬上觀察vmon健康狀態(tài)和日志輸出。如果重啟后很快又OOM說明不是偶發(fā)問題需要調(diào)整JVM堆內(nèi)存。vsphere-ui的JVM參數(shù)可以在 /etc/vmware/vsphere-ui/vsphere-ui-config.properties 里找到重點是-Xmx參數(shù)。根據(jù)vCenter物理內(nèi)存的實際情況適當(dāng)調(diào)大再重啟服務(wù)。有一點必須提醒JVM堆不是越大越好。vCenter每個服務(wù)都有內(nèi)存規(guī)劃盲目把-Xmx調(diào)到超過物理內(nèi)存的一半只會讓系統(tǒng)更早觸發(fā)OOM。建議先看top里的實際內(nèi)存占用再結(jié)合官方配置規(guī)范來調(diào)留足余量。如果是進程死鎖導(dǎo)致的僵死而不是單純的內(nèi)存不足線程dump需要完整的Java工具鏈現(xiàn)場不一定有。這種情況下重啟是最高效的恢復(fù)手段。重啟后持續(xù)觀察vsphere-ui響應(yīng)速度確認(rèn)不再復(fù)發(fā)。4.3 場景C身份提供程序配置損壞這類故障有個非常明顯的特征vCenter服務(wù)狀態(tài)全部正常nginx日志里也沒有connect失敗但登錄頁就是單獨報“獲取身份提供程序時出錯”。看身份服務(wù)日志可能會有failed to load identity provider configuration之類的關(guān)鍵字。這種情況通常和身份提供程序配置有關(guān)。管理員在“身份提供程序”頁面里添加了自定義OIDC身份源比如Azure AD、Okta之類結(jié)果Issuer URL或Client Secret填錯了。身份服務(wù)在拉取或組裝身份提供程序列表時遇到異常前端接口就返回500。處理思路是這樣的優(yōu)先通過vCenter UI里的身份提供程序頁面刪除或修正異常身份源。但這里有個“蛋生雞”的困境登錄頁都報錯了怎么進UI你可以在登錄頁直接輸入 administratorvsphere.local 這個本地SSO賬戶繞過身份提供程序下拉框很多時候是能登錄進去的。進去之后立刻去配置頁面把壞掉的身份源刪掉或者修正。如果本地賬戶也登錄不了還有VAMI兜底也就是5480端口那個管理頁面進去看服務(wù)狀態(tài)確認(rèn)是配置問題還是服務(wù)問題。命令行層面能做的事有限vmafdd可以查看SSO域狀態(tài)/usr/lib/vmware-vmafd/bin/vmafd-cli get-domain --server-name localhost但身份提供程序的完整配置不建議通過命令行直接改更不要手工改vmdir數(shù)據(jù)庫風(fēng)險太大。最好的路徑還是通過UI調(diào)整UI進不去就先修服務(wù)再修配置。配置修正后讓身份服務(wù)重新加載配置service-control --restart vmafdd service-control --restart vmware-sso回到登錄頁刷新身份提供程序列表應(yīng)該就能正常拉取了。4.4 通用兜底全量服務(wù)重啟與證書方向如果上面三類場景排查完都沒定位到根因還有一個兜底方案但一定要在維護窗口做。全量重啟vCenter服務(wù)service-control --stop --all service-control --start --all重啟過程比較長VCSA服務(wù)多等它全部起來可能要十幾分鐘。起來之后馬上檢查服務(wù)狀態(tài)不要等服務(wù)報錯再處理。如果全量重啟之后依然報no healthy upstream那就要回到證書方向深挖。重點查machine SSL證書和solution user證書是否過期以及證書鏈?zhǔn)欠裢暾?。證書的問題不是重啟能解決的需要走正式的證書續(xù)期流程。5. 這類“500no healthy upstream”怎么防巡檢與變更紀(jì)律5.1 磁盤水位是頭號敵人回看那些讓我熬夜的vCenter故障磁盤空間打滿占了一半以上。所以監(jiān)控必須前置。我建議給/storage/log和/storage/archive這兩個分區(qū)單獨設(shè)告警85%觸發(fā)警告90%立刻處理。不能等到100%才去看那時候服務(wù)已經(jīng)處在一個非常危險的狀態(tài)了。清理策略也要做成常態(tài)。vCenter日志歸檔堆積非?？煊绕湓趘Sphere 8.0里日志輪轉(zhuǎn)和歸檔頻率比7.0明顯更高。定期清理/storage/archive下的舊tgz歸檔確認(rèn)logrotate對vsphere-ui等大日志生效別讓大文件無限增長。5.2 服務(wù)健康巡檢腳本化與其等用戶報障不如把服務(wù)健康巡檢寫成一個簡單的腳本交給定時任務(wù)去跑。思路如下#!/bin/bash # vCenter服務(wù)健康與磁盤水位巡檢 echo Disk Usage df -h | grep -E /storage/(log|archive)$ echo Key Services service-control --status --all | grep -E vsphere-ui|vmafdd|vmware-sso|identity echo vmon Health /usr/lib/vmware-vmon/vmon-cli --health這個腳本不用太復(fù)雜能定時輸出服務(wù)狀態(tài)和磁盤水位就夠了。關(guān)鍵是把“健康檢查”納入監(jiān)控范圍不能只看進程在不在。VAMI的5480頁面里也能直接看服務(wù)健康狀態(tài)故障期那是為數(shù)不多還能進去的入口。5.3 變更紀(jì)律身份提供程序這類認(rèn)證相關(guān)的變更一定要在低峰期操作。修改之前把現(xiàn)有配置完整截圖保存或者用導(dǎo)出功能備份。vCenter升級之后第一件事就是打開登錄頁確認(rèn)身份提供程序能正常加載確認(rèn)沒問題再讓業(yè)務(wù)用戶使用別把驗證放到生產(chǎn)出故障之后。NTP配置和證書變更對身份服務(wù)的影響也要評估。vCenter內(nèi)部服務(wù)之間大量依賴HTTPS和令牌機制一旦證書或時間基線變了身份服務(wù)很容易進入不健康狀態(tài)。5.4 故障現(xiàn)場的取證習(xí)慣排障過程中養(yǎng)成兩個習(xí)慣能幫你省下后續(xù)很多麻煩。第一清理日志之前先備份或者至少copy一份現(xiàn)場日志不要為騰空間把能看的東西全刪了不然修好了也不知道問題到底出在哪。第二nginx error.log和vsphere-ui日志建議至少保留7天很多服務(wù)故障是間歇性的第一次報錯可能只是前兆后續(xù)復(fù)盤還得靠這些日志。說實話這類500故障我在維護環(huán)境里前后遇到不下三次其中兩次都是磁盤分區(qū)打滿最后一次才是身份源配置損壞。復(fù)盤下來最有價值的經(jīng)驗不是某個救火命令而是把“登錄頁500”和“后端服務(wù)不健康”這條鏈路焊死在腦子里。排查時永遠(yuǎn)先問一句nginx在幫誰轉(zhuǎn)發(fā)后端服務(wù)健康嗎只要抓住這條線絕大多數(shù)類似問題都能在半小時內(nèi)定位。