之前基于 OpenStack 部署了一个云，运营下来一段时间下来还算正常，出现了各种问题也是意料之内，基本都很快搞定。
搞云计算的人嘛，就得懂得多一些、深一些不是：）
但有一天有个客户找上来反映了一个小问题，虽然最终解决掉，却引发了我的深思。
问题
客户的应用很简单，也是在我们的平台上申请了虚机，然后自己用 keepalived 为后面的某 db 业务提供 HA 保障。一切运行的都很正常，突然有一天，死活访问不通 db 了。
通过查看日志，发现故障发生前 keepalived 发生了切换，灾备节点被切换了。一开始怀疑是 keepalived 配置问题，检查后发现都正常，而且灾备节点确实也拿到地址了。我们搞运维的同学怀疑是网络问题，但底下排查了半天，也没找到原因，而且别的业务都跑的好好的。
分析和解决
出现问题肯定不会是莫名其妙的，我仔细回想了 VRRP 的原理和 Neutron 的实现。keepalived 基于 VRRP 来切换主从节点，被激活的节点会抢到配置的虚地址。然而，neutron 里面为了防止虚机作恶，会记录每个虚机启动时候分配的 IP 和 Mac，并用这个地址来过滤，避免出现篡改源地址的恶意流量。好了，那问题来了，neutron 并不知道某个虚地址其实是在两个 port 上都可能出现的，就会阻碍切换后的灾备节点流量通信。
问题定位到，就好解决了，直接改 iptables 规则，或者开启 Allowed-Address-Pairs (https://review.openstack.org/#/c/38230/) 即可。
进一步思考
从应用的角度看，VRRP 这种切换地址机制毫无问题；从 OpenStack 角度看，你申请一个虚机配置好了地址后，我只允许已知地址的流量出来，也是正常的。但偏偏两个结合到一起就有了问题。这根子上还是在于上层应用和底层平台之间的整合出现了偏差。其实系统就是这样，俩都正常的组件，放一起不出问题的概率很小，这也是为啥接口设计很关键。
我们一直说，要懂业务，要理解业务，其实也是避免设计出的产品跟真实的需求出现偏差。
首先，客户往往并不懂技术（甚至自己都不懂业务），这意味着他们很难用准确的语言描述清楚自己的真正需求（甚至自己都不知道真正需求是啥）。这就需要提供服务的团队要做到比客户更懂自己的业务，这是赢得客户信任的一个极大的优势。懂得从客户需求到业务流程到底下各种技术栈的灵活运用，这才是优秀的技术人员。
另外，就是产品的形态很重要，为什么现在云有 IaaS、PaaS、SaaS 等多种分类，其实这不同的产品形态都是针对不同的客户群体，满足不同的业务需求。呈现细节越少，意味着灵活性越差，但客户使用难度会降低。但无论是那种形态，都应该有严格的范围限制和操作保障，要让完全不懂技术的人能成功操作，甚至各种误操作也能纠正过来。在这点上，OpenStack 是做得很差的，这也是为什么基于 OpenStack 做云服务，首要任务是替换掉 Horizon。极简设计和极繁设计，无所谓高低，合适最好。
最后就是要选择合适的工具。现在开源特别发达，甚至同一个应用场景会出现数个优秀的开源产品，光看特性都是很吸引人。这个时候，选择就很重要了，最看重啥特性？二次开发的难度有多大？针对需求选这个是否合适？选择对了，事半功倍，反之往往陷入各种坑难以自拔。
No comments:
Post a Comment