某五百强信创数据库运维幽默记录

某五百强信创数据库，为了搭配他们的 arm 硬件，把物理安装的配置需求设计得十分严格，核数内存比 1:8 ，至少 8C 起步，否则安装检查不通过。

（但是容器化模式下允许 4C16G 安装）

一个集群 3 节点，也就是每个 cluster 至少要吃掉 24C192GB 内存，我们这边 base 的机器资源不够，调动用外地的机器，两地之间网络全隔离，需要开单申请端口放行

开始之前，我问某五百强技术支持，我们网络隔离，完成任务 1 需要开通什么端口

技术支持丢给我一个《端口矩阵》，林林总总列出了所有组件的端口接近 100 个，但是没告诉我是干什么用的，说可以参考这个文档

然后选了几个看起来要用的端口，提交了审批，等了 2 天，端口批下来了开始干任务 1

卡住了，几百个组件查 log 查了俩小时，发现它在任务过程中冷不丁地要请求一个端口 A 才能完成，具体来说，它下发 agent 包用的不是 scp ，而是要求 node 反过来请求 controller 的自建非标端口 sftp

OK ，反馈，继续开审批，然后追问五百强技术支持，你们任务 1 还涉及什么端口能说说吗？任务流程全是黑盒子，使用手册没有、矩阵文档也没有

技术支持说，你看看端口矩阵，自己整理下

OK ，等了 2 天，端口 A 批完了，继续任务 1 ，结果卡在另一个地方，再查俩小时 log ，发现这个子任务靠 ping 判断 node 的网络连接，但我们没开 ICMP

OK ，继续开审批，把 ICMP 开了，我再追问技术支持，你们还有什么端口要访问的，能不能说清楚

他回答我，那个端口矩阵你可以看下

等了 2 天，ICMP 批下来了，继续任务 1 ，结果卡在最后一个子任务，这个任务在矩阵文档里写的是要用端口 B ，之前已经批过这个端口，测试也顺利放行。

继续查 log 和测试，俩小时之后发现这个子任务实际上在用端口 C ，而非 B ，端口 C 没开通

OK ，继续开审批，等了 2 天，把端口 C 开了，最后终于跑完了

半个月时间消失了

接下来做任务 2 ，毫无意外地卡住了

查 log 两小时，发现这个子任务试图让 node 终端请求 controller 的 Kafka 来获取一些任务参数，这个端口当然是没开通的，哥们，你是个数据库啊

反馈技术支持，追问，你们任务 2 要什么端口

技术支持进入了已读不回状态