对私有云一些问题的思考

问题

之前做了很多功能，为什么做这些功能？
为什么做功能改进性能提升？原版有什么问题？什么场景下会用？
实际业务对底层云有什么现实需求？
HA和LB都怎么做？安全方面怎么做的？
实际运维中遇到什么有代表性的问题，怎么解决的？

答案

其实针对私有云环境，我们并没有做过太多定制化开发，云主机方面主要还是把OpenStack原有的功能用起来；云硬盘主要是适配自研的块存储系统，不过后来也改成了ceph了，目前ceph主要是使用起来原生的功能，外加做了一些比较小的改进，比如链式快照深度超过一定值的自动flattern；云网络那边做的东西比较多，主要也是为了私有云环境SDN使用简化，另外支持了3种网络类型私有网、机房网、外网，以及实现了L3 router的高可用；OpenStack本身的功能就比较多，对于一般的私有云用户来说，真正会用到比较常用的功能很少，比如我们这边的私有云用户，基本就是创建完之后就当物理机在用了，基本重启操作都不会执行。这些问题从web上N年不变的页面就可以看出来，上线后外部可见的部分基本没有改动过。公有云这边倒是做了一些东西，但也是为了支持docker，加快创建速度等，并不一定适合私有云。也就是说我们主要还是把OpenStack已有的功能开放出来给用户用起来，并保证没有问题。大部分需求还都是运维相关的，方便运维以及尽量能自动化运维，还是以修bug为主。有些需求比如qos等社区实现的功能不太好用，比如不够智能，不能任意调整等，其实目前来说都已经证明这些功能根本用不到，都已经慢慢的去掉了或者废弃没人管了。因此我建议不要乱做功能，至少得有多数用户反馈紧缺的功能，并且我们自己也没有办法用其他方式解决掉的，才需要考虑定制开发。另外还有很多功能，我们的版本太低没办法用，也升级不了，只能从上游分支抄回来，这种事情浪费时间，没啥好处，如果能跟着社区走，就没这么多麻烦事了。很多需求都是YY出来的，伪需求。
第2个问题跟第一个类似，上面已经解释了，总得来说还是以解决用户痛点为主，用户的痛点是啥，对我们这边的私有云来说，就是要能跑程序的服务器，网络能通，磁盘可靠，性能要好一点，至少不能太差，资源交付要快，资源要充足，服务要稳定，不能三天两头的不能用（主机挂掉、网络不通、磁盘数据丢失等）。原版的问题主要还是功能用起来要经过很多的测试，不能直接拿来用，因为有很多配置部署方面的坑等着你，不把这些搞明白了，肯定掉坑里，测试的过程就是发现问题，填坑的过程，主要还是修改配置参数，调整部署方式，bug也是有的，但越新的版本越少，而且新版本你发现了bug，提给社区，可以重现的一般都会很快被修复的。什么场景会用到这些二次定制功能，还是上面说的，很多都是伪需求，YY出来的，需求这种东西，有客户了自然会来，没客户尽量不要YY，专注解决基本的通用的场景问题，抓住关键痛点，不要做大而全，尽量小而美，OpenStack目前一个很大的问题就是功能上大而全，能用的不多，能可靠稳定使用的更少，也就最早那几个核心项目比较靠谱（keystone、glance、cinder、nova），之后的neutron、ceilometer都不能算成熟稳定。paas层需求不在这里讨论的范围内。
实际业务的需求，上面也简单提到了，我个人感觉按重要程度排序应该主要是稳定性>性能>高可用>功能（价格因素没有放进来，但是性价比也是非常重要的，但这里不讨论），之所以把功能排到最后，是因为对IaaS来说，只要能保证核心功能不确实即可，哪怕你只有创建删除两个功能，对用户也基本够用了，最简单的创建删除已经交付了IaaS云服务的核心资源（弹性的计算、存储、网络），我相信任何一家有重要业务的公司都不会用一个三天两头出问题的云平台，性能只要不差到影响用户业务的正常运行，并且不能用水平扩展来解决这种程度，一般来说都还不至于影响用户的使用。当然如果你能做到大而全并且还很美，那是再好不过的，但付出的成本能接受吗？华为投入那么多人力去做也没做出来大全美的服务（不是我黑老东家华为，全球范围业界前三肯定还排不上）。所以我建议还是做小而美的产品，麻雀虽小五脏俱全，美到让用户无法拒绝，当然美不单指界面，包含全方位的用户体验在里面，用户体验做的好不好，自己用心去用就能做到不差的程度，但要做到完美那还是要有一定的技术实力和审美水平的。
这个问题才是关键，稳定性就涉及到这两个问题，高可用和安全，相对来说，对私有云场景，高可用是第一位的，安全倒还是没有特别突出，至少跟使用物理机来说区别不是特别大。先简单说下安全问题吧，这个我也不专业，但我理解应该主要包含网络安全和主机安全，对私有云来说，网络安全是第一位的，要做到绝对安全，切断跟外部网络的联系是最安全的，一般企业肯定做不到，所以在私有云和外部网络之间架设防火墙（类似物理机场景）是最方便的选择。高可用怎么做的问题，我们这边都是采用的业界成熟的方案，web层面都是haproxy+keepalived+vip，RabbitMQ使用集群模式，不过貌似低版本MQ和OpenStack服务都有坑，要注意选择版本并加强异常测试，其他组件比如nova-scheduler等通过MQ接入的服务，多部署几个节点即可，数据库的高可用就是主从+vip，出异常手工切换vip即可，毕竟OpenStack管理服务出现问题的影响也只是不能创建删除资源，对私有云来说影响并不是特别严重（除非急需创建新机器扩容），而云主机层面的高可用，对于集群中的主机则一般是通过把不同可用域的物理机分别接入不同的交换机，保证网络冗余，如果是单点部署的云主机，则没办法支持高可用（只能做好备份然后出问题新建），存储方面高可用，如果用ceph默认就支持，不需要特别设置，网络方面的高可用，不太懂不敢乱写。
遇到的问题很多，也是各种各样的都有，你要做的就是做好应对各种奇怪问题的准备，修炼好内功，不光要把用到的OpenStack组件吃透（配置项、代码、部署架构、功能等方面），还要把使用到的其他组件吃透（MQ、DB、haproxy、keepalived、底层网络部署架构、ovs、libvirt、qemu、Linux使用和性能分析等工具、内核特性如namespace等），但总的来说，遇到的更多的还是部署问题、宕机问题、网络问题，OpenStack本身的问题也有一些，比如代码bug、配置错误等，还有很多是用户体验问题，比如api慢，缺少分页支持等。最后我要说的是，代码bug只占遇到的问题中极少的一部分，要把所有的周边组件吃透，是个大问题。经验和技术一样重要，都需要积累，要想快速吸取经验，比较困难，建议还是要自己多测，多用，多处理问题来积累。大公司有完善的分工，遇到相关组件的问题可以找相关方面的专业人士处理，如果是小公司，就要靠google和自己动手了。所以说小公司比较锻炼人，容易出“全才”。