关闭

OpenStack 部署分布式应用的一个坑

标签: 云计算openstack业务流程产品开源
1389人阅读 评论(3) 收藏 举报
分类:

之前基于 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。极简设计和极繁设计,无所谓高低,合适最好。

最后就是要选择合适的工具。现在开源特别发达,甚至同一个应用场景会出现数个优秀的开源产品,光看特性都是很吸引人。这个时候,选择就很重要了,最看重啥特性?二次开发的难度有多大?针对需求选这个是否合适?选择对了,事半功倍,反之往往陷入各种坑难以自拔。

转载请注明:http://blog.csdn.net/yeasy/article/details/50977581



0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:297437次
    • 积分:3958
    • 等级:
    • 排名:第8391名
    • 原创:110篇
    • 转载:0篇
    • 译文:1篇
    • 评论:51条
    最新评论