前两天被一个VCF环境里的“管理冲突”折腾到半夜。现象很简单SDDC Manager里新增的工作负载域一直提示vCenter Server状态异常SSO登录时好时坏点开告警面板出现的是“vCenter Server SSO association conflict”这一类的描述。我当时的第一个反应是改SSO管理员密码改成最新轮换过的密码之后问题不但没有消失状态反而从“可恢复”变成了“需手动介入”。顺着vCenter的日志继续往下查才发现真正的原因不是密码而是这台vCenter在预部署阶段已经向SSO注册过一遍正式部署时又注册了一次SSO里留下了两套身份vCenter自己都分不清该用哪一套。解决这个问题的正确动作不是改密码而是要把vCenter Server和VCF共享的这套SSO关联重置掉让vCenter以当前的主机名、证书和UUID去重新认领身份。这篇就把我这次的判断过程和操作路径整理出来给还在跟VCF里vCenter、SSO较劲的运维一个可参考的排障思路。1. VCF的SSO关联到底是什么为什么一断就是“管理冲突”1.1 三个角色之间的信任关系VCF环境和传统vSphere最大区别就是它多了一层“编排者”的角色。SDDC Manager不仅是界面入口更是所有工作负载域的“控制器”。每个工作负载域都会部署自己的vCenter Server用来管域内的ESXi主机和虚拟机负载SDDC Manager则负责把多个这样的域编排成一个整体。要让这两个层面互相认证、调用APIVCF选择的方式就是共享同一个SSO域。默认情况下这个域是vsphere.local所有接入VCF的vCenter Server会把自己注册到这个SSO域里。SSO里面记录的并不只是管理员账号和密码还有每个vCenter Server的服务主体、solution user、证书指纹、主机名和UUID。当SDDC Manager需要去调某台vCenter的API时它会先从SSO申请一个token然后用这个token访问目标vCenter。vCenter反过来也会校验token里的身份信息是否和自己在SSO里的注册信息一致。任何一处对不上比如证书指纹变了、UUID变了、solution user被删了都会导致认证链条断开。VCF为了让你能一眼发现问题会把这种断链表现为“管理冲突”。你可以把SSO想象成公司大楼的门禁系统SDDC Manager和vCenter Server各自都有一张员工卡卡里记录了工号、指纹和照片。重置关联就等于把vCenter Server这张卡回收掉重新录一次指纹、重新拍一张照片再发一张新卡。你并没有换岗位也没有换部门只是重新录了一次身份信息。1.2 冲突在界面上会是什么样不同版本、不同模块里冲突的表现会有差异。我自己遇到过的几种状态整理在这里症状可能原因通常影响SDDC Manager工作负载域显示vCenter状态CONFLICTEDSSO中旧注册条目与当前vCenter身份不一致SDDC Manager无法对vCenter做编排操作vCenter SSO登录页报“身份验证服务不可用”vmafd或sso服务异常、信任关系损坏管理员无法用vsphere.local账号登录SDDC Manager告警提示“vCenter already associated with another management domain”该vCenter在另一个VCF实例或SSO域注册过无法加入当前VCF管理范围vCenter日志出现solution user不存在solution user被误删或手动改动vCenter部分功能受限vpxd异常看到这些描述时不要急着断定是哪个环节坏了先按第2章的三层思路去定位。很多运维一看到“SSO”就直接去重置密码反而把现场搞乱了。1.3 最容易触发冲突的三个操作第一类是预部署残留。VCF在创建workload domain时会先用临时vCenter做预检和预注册等正式vCenter部署完成后再把管理链路切换过去。如果带出流程在中间失败或者操作员中途取消任务临时vCenter在SSO里的身份条目可能没有自动清理。下一次正式部署时新vCenter用了同样的FQDN但证书和UUID是新的SSO里却还留着旧条目冲突就来了。第二类是快照回滚。有些运维习惯在给VCSA打补丁前做快照打完补丁发现有问题就回滚。快照回滚会同时把vCenter的证书和UUID一起回滚到旧状态但SSO里记录的还是回滚前的最新状态两边对不上。这种情况在VCF里尤为危险因为SDDC Manager可能已经在回滚后尝试调用过vCenter API把冲突状态进一步固化。第三类是人肉改SSO。比如有人觉得默认的vsphere.local不好看想改域名或者手动删除过SSO里的solution user又或者用第三方工具批量同步过用户结果把vCenter自身的主体重名了。这类操作一旦出问题通常不是靠界面重置就能恢复的需要走更细致的SSO重建流程。2. 动手重置之前先把冲突位置锁到三层2.1 第一层SDDC Manager里的凭据和状态不要一开始就登录VCSA。先在SDDC Manager界面里打开对应的Workload Domain找到vCenter Server的详情页。重点看三个信息当前保存的SSO管理员账号、最近一次成功连接时间、状态字段。如果最近连接时间已经很旧甚至显示“未连接”要先怀疑SDDC Manager侧保存的凭据是否和当前vsphere.local管理员密码一致。VCF环境里SSO管理员密码轮换是很常规的操作但很多团队只改了vCenter里的密码忘了同步到SDDC Manager。发生这种情况时SDDC Manager拿着旧密码去访问vCentervCenter会返回认证失败SDDC Manager就会把vCenter标记为异常。处理方式很简单在SDDC Manager的vCenter Server条目上更新凭据保存后等待下一次探测结果。如果状态恢复正常那就说明根本不需要重置SSO关联只是密码同步问题。如果凭据确认是新的、对的但状态仍然异常再去做下面两层检查。这一步的目的是先排除最廉价的原因避免把简单问题复杂化。2.2 第二层vCenter自身的SSO服务与日志vCenter Server Appliance的SSO组件主要涉及vmafd、sso、vpxd这几个服务。登录VCSA的SSH shell先看服务状态ssh rootvcenter-fqdn service-control --status --all | grep -E vmafd|vpxd|sso正常情况下这些服务都应该是running。如果vpxd处于反复重启状态或者vmafd报错再去看对应日志。重点看两个文件tail -n 200 /var/log/vmware/vmafd/vmafd.log tail -n 200 /var/log/vmware/vpxd/vpxd.logvmafd日志里如果出现类似PRINCIPAL_LOOKUP_FAILED、Cannot find solution user的片段说明vCenter在SSO里找不到自己对应的身份条目。vpxd日志里如果反复出现token获取失败、证书不匹配说明vCenter试图向SSO申请token时被拒绝。两条日志同时出现基本可以确认问题出在vCenter自身在SSO中的注册信息而不是SDDC Manager。看日志时要注意时间戳最好和SDDC Manager告警发生时间对上。否则你看到的可能是上一次故障留下的历史日志容易被误导。2.3 第三层证书指纹与服务主体SSO信任关系很大程度依赖证书。vCenter在SSO里注册过自己的证书指纹如果当前vCenter正在使用的证书和指纹对不上即使服务状态全正常SSO也会拒绝该vCenter的身份。检查方法很简单在VCSA shell里看vCenter服务证书openssl x509 -in /etc/vmware-vpx/ssl/rui.crt -fingerprint -sha256 -noout记下输出里的SHA256指纹再打开vCenter Web Client的“证书管理”页面对比vCenter Server条目下的证书指纹。如果不一致说明证书已经更换过但SSO里还残留旧证书信息。这种情况下做SSO重置前最好先把证书统一好再执行重置。还有一个最容易忽略的点在vCenter Web Client的SSO“服务主体”或“Solution Users”列表里看有没有同FQDN的重复条目。如果有两条都指向同一台vCenter那就是非常典型的重复注册问题。这时重置关联的本质就是清理掉其中无效的那条保留当前生效的那条。3. 重置SSO关联的完整路径先靠SDDC Manager再手动兜底3.1 重置前把这些准备做掉别省动SSO关联属于高风险操作尤其在生产VCF环境里一旦操作到一半网络中断或服务起不来影响面会迅速扩大。所以无论你打算走哪条重置路径先做备份和记录。vCenter备份用VAMI即可浏览器访问https://vcenter-fqdn:5480登录后进入“Backup”配置一个基于文件的备份任务保存到远程SMB、HTTP或FTP目录。如果vCenter已经登录不进去也可以在ESXi层面对VCSA虚拟机打快照。但要注意快照只能作为短期回滚手段重置完成后必须尽快删除快照不能长期挂着。同时把下面这些信息记录下来后面验证阶段要用要记录的信息用途vCenter FQDN和IP重置后确认主机名未改变SSO域名确认重置是在原域内进行不是换域vsphere.local管理员账号重置后登录测试用当前证书SHA256指纹验证证书是否在重置前后保持一致vCenter在SDDC Manager中的ID通过API或界面定位目标任务还要选一个维护窗口。SSO重置过程中vCenter的登录和管理API可能出现短暂中断域内其他组件也可能受牵连。不要边收着其他告警边做重置容易分心出错。3.2 首选路径SDDC Manager界面或API重新注册在VCF里SDDC Manager本身是知道哪些vCenter应该挂在哪个SSO域下的。所以重置SSO关联的第一方案永远是让SDDC Manager自己去操作而不是直接跳到VCSA里改SSO。界面操作一般是这样登录SDDC Manager进入Workload Domains打开对应的域找到vCenter Server条目在更多操作里寻找“更新”“重新关联”“Resolve”这类入口。不同VCF版本叫法会有差异但逻辑都是让SDDC Manager重新使用当前的SSO管理员凭据去vCenter端同步一次注册信息。点进去之后通常会要求确认凭据填上可用的vsphere.local管理员账号提交后等待后台作业完成。如果界面上找不到现成入口就去VCF API Explorer里找对应workload domain下的vCenter Server操作接口重点看有没有repair、re-register、resync动作。VCF的API行为在不同版本里差异不小具体的接口路径以你自己环境里的API Explorer为准。这个方案的好处是SDDC Manager不仅会重置vCenter在SSO里的身份还会同步更新自己的内部状态记录避免两边各管各的。所以只要界面或API允许执行优先走这条。3.3 保底路径vCenter侧清理并重新注册身份如果SDDC Manager的操作入口被冲突状态卡住或者执行后仍然报同样的错就需要到vCenter侧做手动兜底。这里有一点必须先说清楚VCSA从部署完成那一刻起SSO域名就是定死的没有“后台改一下域名”的选项。下面说的重置是在同一个SSO域内把vCenter Server自身的注册身份清掉再让vCenter重新注册。整个过程不改变域名本身。核心思路分三步定位身份、清理身份、重启服务重新注册。定位身份通常依赖VMware官方的SSO诊断脚本。在VCSA上找到或上传官方的lsdoctor脚本运行诊断模式它会扫描SSO数据库中的vCenter服务主体和solution user把可疑条目列出来。如果你手里没有这个脚本也可以联系VMware支持通过官方工单工具包执行。这步的关键是要确认哪些条目属于当前出问题的vCenter避免误删掉管理域里其他vCenter的身份。确认无误后通过诊断脚本提供的修复模式或者在支持人员指导下把当前vCenter对应的重复或错误solution user清理掉。清理完成后重启vCenter的vpxd服务service-control --restart vmware-vpxdvpxd启动时如果发现SSO里没有自己的有效注册信息会自动按当前主机名、证书和UUID重新注册生成新的solution user。注册完成后再回到SDDC Manager重新执行一次关联操作让VCF侧的状态同步过来。这里再多提醒一句旧版本里还可以用vdcadmintool这个交互式工具去查看SSO数据库但它操作风险很高交互选项选错可能会影响整个SSO域。除非你非常熟悉它的行为或者有VMware支持在场否则不要在生产环境里凭感觉试用。3.4 操作过程中常见的中途失败怎么应对第一次做这类操作时最容易遇到三个问题。一个是后台任务卡在中间不动大概率是vCenter当时还在和SDDC Manager做其他同步操作任务队列互锁。这种情况下不要反复提交新任务等15到30分钟后刷新状态如果仍然卡住再考虑重启SDDC Manager的对应服务或联系支持。第二个问题是重置完成后vCenter侧已经能用新身份登录但SDDC Manager仍然显示异常。这是因为VCF侧的状态不是实时刷新的需要在SDDC Manager里手动触发一次vCenter连接测试或者等待后台作业的下一轮同步。不要因为这个就去重复重置反而容易把新身份又搞乱。第三个问题是清理身份时不小心多删了条目。如果误删了管理域里其他vCenter的solution user影响范围会迅速扩大所有依赖于SSO的组件都会开始报认证失败。遇到这种情况第一时间停止所有手动操作保留日志找VMware支持介入恢复。这也是为什么我一直强调手动清理前必须确认条目归属。4. 重置成功不等于完事这几步验证都要走4.1 服务状态和SSO登录验证重置完成后先把vCenter的SSO服务状态确认一遍service-control --status --all | grep -E vmafd|vpxd|sso所有相关服务都处于running状态后再用vsphere.local管理员账号登录vCenter Web Client。这一步能通过说明vCenter到SSO的token通道已经恢复管理员身份认证链路没问题。如果登录时报错先看vmafd日志确认是不是solution user注册后还没有被sso服务完全加载。4.2 检查重复身份与证书指纹登录vCenter Web Client后打开“Administration”下的SSO配置检查vCenter Server服务主体列表。正常情况下应该只有一条当前FQDN对应的记录。如果还有第二条旧记录残留在确认为无效注册后按官方流程清理否则下次vCenter重启可能又出现身份选择混乱。同时回看之前记录的证书SHA256指纹和当前vCenter“证书管理”页面的指纹做对比。重置操作不改变证书文件本身所以指纹应该保持一致。如果指纹变了说明重置过程中有证书相关任务被触发需要额外检查证书服务是否正常。4.3 回到SDDC Manager看状态vCenter侧验证通过后回到SDDC Manager刷新Workload Domain页面查看vCenter Server状态。正常情况下应该从CONFLICTED或ERROR变成REGISTERED或正常管理状态。如果状态仍然是异常可以尝试用SDDC Manager里的“更新凭据”或“重新发现”功能手动触发一次状态同步。这一步不要只盯界面还要看SDDC Manager的后台任务有没有针对该vCenter的同步作业在跑。有时候界面刷新慢作业还没执行完状态自然没有立刻变化。4.4 用一个小作业验证编排链路状态显示正常只是第一关真正可靠的验证方式是让SDDC Manager对vCenter做一次实际调用。我会推荐在SDDC Manager里选一个低风险操作比如刷新vCenter许可证或者对某个ESXi主机执行“进入维护模式再退出”只要这条作业能成功完成说明SDDC Manager和vCenter之间的SSO调用链路是通的。验证作业的意义在于它会把SDDC Manager向vCenter发起API请求、vCenter解析token、vCenter返回结果、SDDC Manager记录状态这一整条链路完整走一遍。光在界面上看状态是“正常”不一定能暴露深层的权限问题。4.5 快照和备份的善后如果重置前给VCSA打过ESXi快照现在确认环境稳定后一定要尽快删除快照。VCSA长期挂快照会带来两个问题一是磁盘占用增长很快二是之后如果再次回滚又会把刚重置好的身份状态带回旧版本等于白做。删除快照的操作要在VCSA关机或在线状态下由vCenter管理员执行但要注意会产生短时间IO开销尽量在低峰期操作。备份保留一段时间比如一周。这段时间内如果发现任何异常还能用来做恢复。一周后确认稳定再清理旧备份。5. 关于VCF中SSO重置我的一些个人习惯和坑5.1 不要在vCenter侧随意“修”我处理过一个类似的VCF环境当时运维同事用了SSO的本地工具去查看服务主体结果交互界面里看花了眼误把一个看起来很像的管理组件条目当成了问题条目执行了删除操作。好消息是那个环境是测试环境坏消息是删除后整个SSO域的组件认证全乱最后只能重建vCenter。从那之后我的原则就变成了能走SDDC Manager界面或API重置的绝不动手去vCenter侧碰SSO。如果必须动vCenter侧也要把影响范围控制在这台vCenter自身。操作前先确认当前vCenter的UUID和FQDN再核对要清理的条目是否匹配而不是看到名字相似就动。5.2 别想着把vsphere.local域名改掉有些团队对默认的vsphere.local这个名字不满意想借重置SSO关联的机会把域名一起改掉。我得直接说这个念头在VCF环境里趁早收掉。VCF部署完成后默认SSO域会和SDDC Manager、vCenter、NSX等组件的证书和标识深度绑定改域名本质上等同于重新做一次身份体系建设不是一次“重置关联”能覆盖的。如果确实对域名有要求正确做法是在VCF带出参数模板阶段就自定义SSO域名而不是等整个VCF跑起来之后再改。后期唯一适合做的是在同一域名内修复身份关系而不是换域。5.3 日常预防比排障更省时间经历过几次SSO关联冲突之后我现在的运维习惯是给vCenter做季度性配置备份并把备份文件测试恢复一次确保可用性。同时给SDDC Manager里的SSO凭据建立台账密码轮换后在一个工作日内同步到SDDC Manager避免凭据不一致成为冲突源头。另外凡是涉及VCF工作负载域的带出或删除我都会在流程结束后检查一遍SSO里是否还有残留的vCenter身份条目。这一步很难自动化但值得做因为预部署残留恰恰是我最常看到的冲突根因。5.4 处理这类问题的现场记录建议遇到SSO关联问题时我建议先花三分钟把现场信息留存完整再动手。记下SDDC Manager的告警时间、vCenter的vmafd和vpxd日志时间段、证书指纹以及当时正在执行的任务列表。这些信息在找VMware支持的时候非常有用。如果最后需要走手动重置也一定要保留操作过程中产生的日志尤其是vpxd重新注册的日志。这类日志记录了新solution user的注册时间、使用的证书指纹和主机名后面排查其他问题时还能当作基线参考。我自己现在遇到VCF里的SSO相关冲突已经不会条件反射地先改密码了。先进SDDC Manager看关联再上vCenter看日志和证书分层排查最后才决定要不要重置。这套流程帮我省了不少维护窗口希望对你们也有用。