Azure计算节点无法连上本地主节点，原来是MTU惹的祸

 

IBM Spectrum Symphony 是基于SOA架构的分布式计算框架，它能在自由伸缩的共享集群中，为计算密集型和数据密集型的应用提供强大的企业级管理。而且，Symphony能加快多个并行应用以更快地得出结果以及更好地使用所有可用资源。利用Symphony，企业可以提高IT性能，减少基础设施成本，以更快地满足商业需求。受益于Symphony底层优秀的资源调度框架EGO、由C++实现的中间件SOAM，Symphony的性能和可扩展性都极为优秀，在金融衍生品的定价以及风险模拟等金融领域得到广泛的应用。

在Cloud大势所趋的今天，越来越多的公司选择将应用迁移到Cloud上，目的无非都是为了降低IT成本，说白了就是为了省钱。从全球的角度来看，前几大Cloud大厂无非是Amazon的AWS，Microsoft的Azure，Google Cloud，IBM Cloud，阿里云，腾讯云，金山云，等等。Symphony的客户也在尝试将Symphony的应用跑到Cloud上，目前为止支持AWS，Azure和IBM Cloud。现如今已经有不少Symphony的客户将整个cluster都跑到AWS或Azure上。

 

近日，欧洲某大型商业银行在测试Symphony上Azure的时候，就遇到一个网络连接问题。他们的架构是Symphony master节点依然保留原本跑在本地的master，但是打算从Azure上租用数以千计的计算节点。在部署测试的时候，他们遇到的现象是，计算节点在cluster中显示为Unavailable的状态，而且计算节点上，启动Symphony之后只有LIM这个进程，连PEM都没有起来。参看下图了解Symphony的daemon关系图，PEM在计算节点上是负责关停其他进程的。

从计算节点上LIM的DEBUG日志来看，内容也很简单，把request发给master LIM之后就没有下文了。

May 18 17:27:43 2020 1732:3912 5 3.7.0 logMTU(): The MTU (Maximum Transmission Unit) size of the network interface <Microsoft Hyper-V Network Adapter> is 1500 bytes.
May 18 17:28:43 2020 1732:3912 7 3.7.0 LSF uses normal communication
May 18 17:28:43 2020 1732:3912 7 3.7.0 announceMasterToHost: Sending request to LIM on 192.168.31.13:7869

而master LIM的DEBUG log也没相关信息，

May 18 15:52:39 2020 9456:1552 5 3.7.0 logMTU(): The MTU (Maximum Transmission Unit) size of the network interface <Microsoft Network Adapter Multiplexor Driver> is 1500 bytes.
May 18 15:52:45 2020 9456:1552 4 3.7.0 initNewMaster: This is now the master host.<