![在 Ubuntu MAAS Juju 服务器上观察到奇怪的行为](https://linux22.com/image/978728/%E5%9C%A8%20Ubuntu%20MAAS%20Juju%20%E6%9C%8D%E5%8A%A1%E5%99%A8%E4%B8%8A%E8%A7%82%E5%AF%9F%E5%88%B0%E5%A5%87%E6%80%AA%E7%9A%84%E8%A1%8C%E4%B8%BA.png)
抱歉,我写了这么多。过去几周,我发现 Juju 和我们的 Ubuntu MAAS OpenStack 出现了一些非常奇怪的行为,似乎完全出乎意料(我离开办公室一周了):
- keystone 报告 errno 111(超出 HTTPConnectionPool 最大重试次数)
- keystone reporting 授权失败:无法建立连接到http://10.10.5.5:5000/v2.0/tokens)
- nova 报告 errno 111 (错误:HTTPConnectionPool(host='10.10.5.5', port=5000): url: /v2.0/tokens 的最大重试次数超出 (原因:[Errno 111] 连接被拒绝) )
- Horizon 抛出 ConnectionError 111
- 几乎所有其他服务也都如此
我应该补充一下,当前运行的实例仍然运行,仍然支持 SSH/VNC/RDP,并且仍然联网。
在阅读了尽可能多的错误信息后,我发现问题出在 Keystone 及其连接的 MySQL 数据库上。我立即尝试直接手动连接数据库,并成功连接,至少乍一看,那里没有数据损坏。
这甚至变得更加有趣(和令人烦恼)。降级 juju charms 或启用日志记录会导致部分和随机修复这种情况。
例如。:
- 启用 keystone 日志记录会导致 keystone 正常工作,但没有其他效果。
- 启用 Glance 日志记录会使 nova 在一定程度上正常工作。
- Horizon 仍然完全无法工作,但是升级 Glance 可以让某些功能在一段时间内正常工作。
切换登录/关闭、保存和提交更改似乎会导致 OpenStack 网络总体上出现不可预测的行为,与升级和降级 juju charms 一样。
坦率地说,实际上我在任何 juju charms 中所做的、保存和提交的任何更改,无论多小(例如将调试设置为已启用),都会导致不同的功能正常工作和不同的功能不正常工作,似乎是随机的。
OpenStack 日志文件没有太大帮助,因为它们显示与前面提到的相同的错误 + 大量关于所讨论的 Python 脚本的哪一部分失败的信息。
以前有其他人见过/经历过这种极其奇怪的行为吗?关于如何开始调查此事,有什么建议吗?