技术人生系列——vCenter重启大法不香了？

https://mp.weixin.qq.com/s/HFZKp0ligd_3PbayTBiZhw

技术人生系列中虚拟化技术一直写得比较少，有小伙伴后台留言希望我们分享一些这个方面的技术案例，近期我们的虚拟化工程师就碰到了一个比较典型的案例，话不多说，马上进入我们本期的技术人生。

 

 

 

 

 

/ / / /

 

 

近期某天下午，我正在公司整理文档，突然接到客户工程师的电话，告知VMware vSphere虚拟化平台web客户端无法访问，client端可以正常登录。听着客户的描述，我一面安抚客户不要着急，一面思考，根据客户的描述应该是vCenter web服务异常导致的，以前也碰到过这个问题，重启服务就可以轻松搞定，所以告知客户我会通过远程来进行问题处理。

 

 

/ /     这个故障不简单     / / 

 

 

16：10 ，客户发来远程，登录客户vCenter所在ESXI主机，通过控制台进入系统命令行进行服务检查，结果vCenter无法开启shell服务，无法对vCenter进行命令操作，与客户沟通得到确认后，对vCenter进行重启。但系统重启后依旧无法登录，看来不是单纯的服务状态异常了，应该还有其他原因。

 

经过多次尝试终于登陆vCenter命令行，赶紧查看服务状态，发现eam、invsvc和vpx服务没有启动，文件系统根目录使用率达到了100%。

localhost:~ # df -Th

Filesystem                           Type   Size  Used Avail Use% Mounted on

/dev/sda3                            ext3    11G  11G  0G  100% /

udev                                 tmpfs  4.0G  164K  4.0G   1% /dev

tmpfs                                tmpfs  4.0G  160K  4.0G   1% /dev/shm

/dev/sda1                            ext3   128M   38M   84M  31% /boot

/dev/mapper/core_vg-core             ext3    25G  173M   24G   1% /storage/core

/dev/mapper/log_vg-log               ext3   9.9G  353M  9.0G   4% /storage/log

/dev/mapper/db_vg-db                 ext3   9.9G  205M  9.2G   3% /storage/db

/dev/mapper/dblog_vg-dblog           ext3   5.0G  171M  4.5G   4% /storage/dblog

/dev/mapper/seat_vg-seat             ext3   9.9G  165M  9.2G   2% /storage/seat

/dev/mapper/netdump_vg-netdump       ext3  1001M   18M  932M   2% /storage/netdump

/dev/mapper/autodeploy_vg-autodeploy ext3   9.9G  151M  9.2G   2% /storage/autodeploy

/dev/mapper/invsvc_vg-invsvc         ext3   5.0G  165M  4.6G   4% /storage/invsvc

文件系统占用100%导致系统服务无法启动？

 

根据以往case经验，根目录100%一般是由于系统root用户密码过期导致audit 日志中记录大量无效认证日志，于是查看audit.log 大小，果然发现了大量日志占用根目录。

ls -lh
total 4.6G
drwx------ 2 root root 4.0K May 5 2016 audispd
-rw------- 1 root root 4.5G Apr 3 16:55 audit.log
-rw------- 1 root root 445K Apr 8 2020 audit.log-20160408.bz2
-rw------- 1 root root 447K Apr 9 2020 audit.log-20160409.bz2
-rw------- 1 root root 444K Apr 10 2020 audit.log-20160410.bz2
-rw------- 1 root root 447K Apr 11 2020 audit.log-20160411.bz2

16：40，问题基本弄清楚了，由于为根目录使用100%导致系统服务异常。解决问题的思路是，清理audit.log日志释放根目录空间，root密码更改并调整密码过期时间为永不过期，重启服务应该就可以大功告成。

localhost:~ # chage -l root

Minimum:   0

Maximum:   365

Warning:   7

Inactive:  -1

Last Change:      May 02, 2018

Password Expires: May 02, 2019

Password Inactive:   Never

Account Expires:  Never

但好像我又想的简单了。重启服务后发现eam、invsvc和vpx服务仍未启动，vpx服务依赖invsvc服务启动；先解决eam和invsvc服务启动的问题吧。

 

检查相关日志，通过查看var/log/vmware/eam/wrapper.log，发现在系统启动中存在报错信息：Could not resolve placeholder 'eam.hostd_restart_timeout'。

INFO | jvm 1| 2015/02/24 07:55:45 | WrapperSimpleApp Error: Encountered an error running main:
INFO | jvm 1| 2015/02/24 07:55:45 | WrapperSimpleApp Error: org.springframework.beans.factory.BeanDefinitionStoreException: Invalid bean definition with name 'esxAgentMgr' defined in class path resource [eam-server-beans.xml]: Could not resolve placeholder 'eam.hostd_restart_timeout'
INFO | jvm 1| 2015/02/24 07:55:45 | WrapperSimpleApp Error: at org.springframework.beans.factory.config.PropertyPlaceholderConfigurer.processProperties (PropertyPlaceholderConfigurer.java:268)
INFO | jvm 1| 2015/02/24 07:55:45 | WrapperSimpleApp Error: at org.springframework.beans.factory.config.PropertyResourceConfigurer.postProcessBeanFactory (PropertyResourceConfigurer.java:75)

检查eam配置文件 /etc/vmware-eam/eam.properties，配置文件为空，配置文件丢失了，需要恢复：

 

（1）确认系统ID ：cat /etc/vmware/install-defaults/sca.hostid。

The output should be a string like : 0a12dfe2-b3b7-4eb6-9737-1ec5a8e770ec

 

（2）确认系统名称hostname -f。

编辑 /etc/vmware-eam/eam.properties配置文件，修改如下标红位置，主要修改主机名，hostdid和 vCenter IP。

vc.proxy.host=localhost
vc.proxy.port=80
eam.host=
eam.int.http.port=15005
eam.ext.port=443
eam.ext.scheme=https
eam.ext.port.deprecated=80
eam.ext.scheme.deprecated=http
eam.support_linked_clone=true
eam.clear_db_on_startup=false
eam.debug_ref_count=false
eam.recent_event_size=20
vum.integration=true
eam.scan_for_unknown_agent_vms=1440
eam.resourcebundle.filename=eam-resourcebundle.jar
tcserver.tmp.dir=/var/tmp/vmware/eam/tomcat
eam.web.root=/usr/lib/vmware-eam/web
eam.keystore.type=VKS
eam.key.alias=vpxd-extension
eam.keystore.storename=vpxd-extension

cm.url=http://localhost:18090/cm/sdk/?hostid=0a12dfe2-b3b7-4eb6-9737-1ec5a8e770ec
cm.wait.attempts=360
cm.wait.intervalSeconds=5
sso.wait.attempts=360
sso.wait.intervalSeconds=5
vc.truststore.type=VKS
vc.truststore.storename=TRUSTED_ROOTS
vc.tunnelSdkUri.template=https://##{VC_HOST_NAME}##:8089/sdk/vimService #<====== Keep this unchanged
vc.tunnelSdkUri=https://<192.168.1.202>:8089/sdk/vimService #<====== Change this to your vCenter FQDN/IP
drs.demandCapacityRatio=100

（3）修改配置文件权限为0644：chmod 0644 eam.properties。

 

（4）重启eam服务：service-control --start vmware-eam，eam服务启动成功。

 

17：30，invsvc服务进行恢复，查看invsvc服务日志，在inv-svc.log中发现无效的凭证LDAP的报错：

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'aclLotusInitializer' defined in class path resource [server/config/authorization-config.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class
CredentialsLdapException: Invalid credentials LDAP error [code: 49] at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:287)

报错提示显示凭证无效，进一步查看/var/log/vmware/vmdird/vmdird-syslog.log日志,确定无效用户信息，[email protected]凭证不匹配：

2020-04-04T17:47:48.024511+00:00 err vmdird t@140107551946496: SASLSessionStep: sasl error (-13)(SASL(-13): authentication failure: client evidence does not match what we calculated.Probably a password error)
2020-0-04T17:47:48.024533+00:00 err vmdird t@140107551946496: VmDirSendLdapResult: Request (96), Error (49), Message ((49)(SASL step failed.)), (0) socket ([17] 10.105.217.85:389<-10.105.212.102:54753)
2020-0-04T17:47:48.024538+00:00 err vmdird t@140107551946496: Bind Request Failed ([17] 10.105.217.85:389<-10.105.212.102:54753) error 49: Protocol version: 3, Bind DN: "cn=192.168.1.202,ou=Computers,dc=vsphere,dc=local", Method: 163

接下来，我们需要对[email protected]用户进行密码重置和更新。

 

运行/usr/lib/vmware-vmdir/bin/vdcadmintool重置[email protected]密码：

localhost:~ # /usr/lib/vmware-vmdir/bin/vdcadmintool

==================

Please select:

0. exit

1. Test LDAP connectivity

2. Force start replication cycle

3. Reset account password

4. Set log level and mask

5. Set vmdir state

==================

3Please enter account UPN : [email protected]

New password is -

X+TcHrqn-q3n8TKFOIt

密码重新生成后更新密码：

/opt/likewise/bin/lwregshell

\> cd HKEY_THIS_MACHINE\services\vmdir\

HKEY_THIS_MACHINE\services\vmdir> set_value dcAccountPassword "X+TcHrqn-q3n8TKFOIt"

quit

密码重置成功后，使用service-control --start --all 重启所有服务，服务全部启动成功。

 

vCenter web客户端和client都成功登录，检查告警和集群整体状态正常。到此故障全部解决。

 

 

/ /     一点小总结     / / 

 

 

故障终于解决了，虽然重启大法不香了，但收获颇丰。我想应该赶紧总结下来，给其他小伙伴参考。

 

1、vCenter 根目录为什么100%？

 

root用户密码过期，导致audit.log中记录了大量的凭证失效记录，cron 作业未能正常进行日志轮转，导致根目录被audit.log日志占满。

 

2、eam服务为什么无法启动？

 

系统启动eam服务时会自动更新配置文件，但系统空间不足导致更新失败，eam配置文件被删除，导致服务无法启动。

 

3、invsvc服务为什么无法启动？

 

在服务启动时存在用户密码匹配失败，可能因为根目录100%后，密码文件损坏。

 

4、如何预防此类事故的发生？

 

 

追根溯源，引发这类问题的原因多是系统root密码长期过期导致，root用户密码过期导致文件系统使用率100%、配置文件丢失或损坏，最终vCenter无法对外提供服务。

 

所以，建议对vcsa的root用户密码过期策略进行修改，如果客户没有对密码定期修改的要求，建议将其更改为永不过期；如客户有对密码定期修改要求，一定要设置密码过期时间大于要求更改密码的周期。

 

还有，就是定期检查vCenter 系统磁盘空间使用率，防止文件系统100%导致系统服务异常，影响vCenter的管理和正常使用。