生活

写给儿子<11>

Posted on by aspirer

距离上次写东西给你已经不知道有多久，感觉大概有半年多了吧。。。。

我不习惯在很多人面前写文字，习惯一个人安静的敲键盘，就像不想被人盯着敲代码一样

这段时间你的变化挺大的，已经可以流畅的表达自己的想法，还可以说出一些出其不意的观点，很高兴你有自己的思维了，可以反驳大人的观点

还有一个好消息，或许是吧，要告诉你，过几个月你将会有一个弟弟了，也是你妈妈一直给你强调的肚子里的那个“妹妹”。。。

没错，爸爸妈妈确实非常希望给你生个妹妹，只是世上没有完美的人生，总不能万事皆顺意

每个人的人生都会有缺憾，你长大之后也要学着接受这种不完美的人生，否则人生就处处充满悲痛了。。。

不过也不是100%一定是弟弟，毕竟B超看到的也不一定没有错误的可能，目前最重要的是给未来的弟弟（或者妹妹）取个名字，再过4个多月就要出生了

前几天你的牙齿终于全部补完了，一共补了9颗，耗时有半年左右吧，花了几千块，不过现在都好了，你吃东西再也不会用门牙嚼了。。。

还有你最近晚上总是会把裤头尿湿一点点，然后自己脱掉扔出来，据你自己说的理由是，太冷了，不想起床尿尿，还有就是叫了爸爸妈妈但是没人理，还有就是没憋住，。。。

其实每天晚上我都会抱你两次去尿尿，可惜不是每次你都配合

好吧，反正都会好起来的。。。

话说，两个儿子的压力可是非常非常非常非常大的

唯一的好处是给你买的双层床可以真的用起来了。。。。

爸爸妈妈只能尽力尽力再尽力给你们创造更好的基础，能做到什么程度，我也没谱。。。

技术

完善的IaaS云服务的个人理解

Posted on by aspirer

前情提要

这篇文章在7月份就列好了大纲，但是一直拖拖拉拉到11月初，才憋出了几百字。

本文仅讨论云主机（虚拟机）、云硬盘（块存储）、云网络（普通虚拟网络或SDN）相关的IaaS服务，相关论调仅代表个人意见，如有谬误，敬请批评指正。

网易云IaaS平台自2012年上半年立项，到如今已有接近5年的发展历程，生产环境云主机数量也从个位数扩展到当前的5位数，机房数量也从1个扩展到杭州3个，北京2个，并且还在迅速扩张。有一点我特别深有体会，那就是生产环境流行“屯云主机”，线上资源长期处于秒杀状态，每个季度采购的计算节点，一个月左右基本就抢光，剩下两个月就处于等待新节点上线，无法创建新云主机的尴尬境地，所以很多有经验的开发人员，会在季度采购节点上线后，迅速准确的提出扩容需求（当然可能是两三个月之后的需求），创建一批云主机备用，当然他们也是逼不得已，因为晚了就抢不到了。说了这么多，不知道大家看明白了没有，我只是想强调一点，我们的IaaS服务非常受欢迎。

接下来就谈一谈我心目中的完善的IaaS服务是长什么样的，本文属于抽空写两条，想到哪儿写到哪儿这种情况，权当闲聊吧。

何为完善

  • 功能完善
  • 运维便利
  • 安全可靠
  • 性能优异
  • 体验友好
  • 服务优质
  • 成本低廉

功能完善

作为一个IaaS服务提供商，尤其是做公有云（私有云需求相对简单一些），必须要提供完善的IaaS功能，这点是最基本、最基础的要求，如果功能都不完善，缺少一些重要功能，甚至API都不对用户开放，怎么能算是完善的IaaS服务？个人认为具备如下几个方面的功能，才能算是功能完善：

普通用户功能

  • 基本的主机、网络、存储资源的生命周期管理功能（增删改查、修改规格、快照备份、VNC等）
  • 资源汇总查看
  • 操作日志查看（包含web和api操作）
  • 账户及子账户管理
  • 监控报警
  • 计费充值（消费清单、充值记录、发票申请、退款处理等）
  • 镜像丰富，规格齐全
  • 客户支持（一般为工单系统）
  • API、SDK、CLI支持
  • 移动端管理

后台管理员功能

  • 在线、离线迁移及常规生命周期管理
  • 平台容量规划预警
  • 欠费通知及处理
  • 集群状态监控
  • 异常状态报警
  • 租户配额管理
  • 用户权限控制
  • 管理员分级
  • 管理员操作审计
  • 各种资源的详细信息展示

功能完善的直观体现是用户不会因为功能不全而选用竞品。

运维便利

IaaS云平台运维主要包含如下几个方面：

  • 平台初始化部署
  • 平台扩缩容及容量估算
  • 平台升级更新
  • 平台故障恢复
  • 常见错误排查

便利的意思主要是指如下几个方面：

  • 故障自恢复，不需要人为介入
  • 人员交互少，跨部门跨项目组交互少，最好一个人能搞定
  • 耗时短，自动化程度高，极低的人工参与度
  • 操作简单，容易上手，不需要高深的知识技能和经验积累（坑少且浅）
  • 常见简单错误可以自助识别原因（无资源、无网络端口、无配额等）

运维便利的直观体现是新招员工一周内可接手全部平台运维工作。

安全可靠

  • 计算服务多层高可用保障（多数据中心，多级可用域）
  • 网络服务冗余链路保障
  • 存储多副本保障、租户数据隔离
  • 管理服务无单点
  • SLA保证
  • QoS保证
  • 租户网络隔离
  • 平台、租户防攻击（平台入口如web或API、网络、虚拟化内核等方面）
  • 机房基础设施安全（多路供电、多网络出口、防人为失误、防火防盗防高温防鼠防虫等）
  • 管理员权限管控（防止误操作和恶意操作）
  • 用户及管理员操作记录和审计
  • 物理基础设施资源冗余保障（机房、机柜、电力、服务器、交换机、硬盘、内存、网卡、网络带宽等）
  • 计算节点宕机恢复速度快（支持云主机宕机自动迁移恢复）
  • 其他节点宕机用户无感知

安全可靠的直观体现为全年用户可感知故障时间和次数（总故障时间120分钟以内或更少，总故障次数不超过3次）。

性能优异

  • 计算（cpu、内存）性能达到或接近扣除虚拟化损耗的理论值
  • 网络（带宽、时延）性能达到或接近扣除虚拟化损耗的理论值
  • 存储（带宽、时延）性能达到或接近扣除虚拟化损耗的理论值
  • 性能波动较少，与租户数量、测试时间段等关系较小或无关
  • 不同租户性能相互影响较小或无相互影响
  • 相同租户不同云主机的性能相互影响较小或无相互影响

性能优异直观体现为与竞品厂商相比，对比测试结果排名靠前（前三或更好），并与测试时间段无关

体验友好

  • 完善的使用指导文档（目录清晰、内容详细、解释清楚、更新及时、FAQ全面）
  • 优秀的web交互、UI设计（人性化、提示明确、傻瓜式，很多用户是不看文档直接上手操作的）
  • 详细生动的API文档（文档更新及时、目录清晰、示例丰富、参数尽量少、内聚程度高、版本兼性好）

体验友好的直观体现为用户使用过程中问题较少（用户极少因为使用问题找售后支持）

服务优质

  • 用户响应及时（按问题类型、用户类型分类制定响应时限，类似服务等级策略）
  • 渠道丰富（工单、QQ、微信群、公众号、电话等）
  • 售前交流深入充分（将平台的相关局限性与用户充分沟通，可防止给用户过高期望而导致满意度降低）

服务优质的直观体现为用户满意度很高（如果满分5分，则需要达到90%以上4分甚至更高）

成本低廉

成本低廉的直观体现是相同规格服务与竞品价格对比优势明显，并且可保证我们平台的盈利能力。

技术

网易蜂巢新版服务管理初体验

Posted on by aspirer

网易云战略发布会已经在9月20号完美谢幕，新版本服务管理也启动了灰度测试，苦于一直没有时间体验，今天终于抽出时间一睹新版芳容，简单体验了一下服务管理、负载均衡这两大功能，感受到了容器云的便捷和弹性。

先说下注意事项，某些docker hub官方镜像由于dockerfile编写不太规范，启动命令不符合docker要求，会导致服务创建失败，所以建议选择蜂巢官方镜像进行创建，这个并不是蜂巢的bug。

ps. docker hub镜像启动问题导致创建失败，蜂巢产品经理已经着手改进了，会做到尽量符合用户习惯，避免用户产生困扰和疑惑。

接下来是非常简单的体验过程！

首先进入“服务管理”，点击“创建服务”，然后选择一个镜像，我这里选择的是蜂巢官方提供的centos6.5镜像，然后填写容器名称“test”，我这里选择的是“无状态”服务，因为我打算在容器里面的只是一个简单的web服务，并没有具体的需要持久化保存的数据。

然后下一步，填写服务名称，选择容器规格，填写端口配置，我这里随意填写了一个容器端口（10086）和服务端口（10010），创建完毕后蜂巢服务管理系统会自动把容器端口映射到服务端口，以便对外提供服务。

最后是填写副本数量，这也是新版本服务管理针对无状态服务的特有功能，可以自动保持容器副本数量，在容器崩溃等异常情况下可以自动恢复，也可以后续进行副本扩容。

cloudcomb1 cloudcomb2

最后点一下“立即创建”，稍等片刻即可完成整个服务集群的创建。

服务创建完毕后，是没有外网的，也就是说集群不能对外提供服务，因此我们要配合负载均衡服务来对外发布，顺便实现服务的负载均衡。

创建负载均衡也比较简单，填写名称，选择按带宽或者流量计费模式，选择需要绑定的服务空间即可创建。

cloudcomb3

创建完毕后，等待片刻，即可通过“创建监听”进行端口管理，我们选择监听协议HTTP，端口80，默认转发规则，后端服务选择刚创建的“service”，端口填写服务端口“10010”，立即创建即可。

cloudcomb4

到这一步，如果你上面创建的服务集群的镜像是你自己打好的，容器中已经有服务监听了10086端口，那么你就可以直接通过负载均衡的外网IP访问你的web服务了。一切就是这么简单！

但是我刚创建的服务只是一个裸的centos6.5操作系统，因此要在里面跑一个简单的HTTP Server，我这里以Python自带的SimpleHTTPServer服务为例进行说明，我们在服务管理中，点击服务名称“service”，进入服务详情，通过console登录到各个容器副本中，然后执行：

cloudcomb8

cloudcomb9

最后我们在浏览器中访问负载均衡的外网IP，即可看到容器的文件目录：

连续刷新几次页面，可以分别看到container1、container2、container3，证明我们的负载均衡服务生效了。

然后我们还可以扩缩容服务（增加或者减少容器副本数量），或者更新我们的服务版本（更新镜像版本），这两个功能可以帮我们高效便捷的完成常用的服务运维（扩缩容和服务更新），这一切都只需要点击鼠标即可完成，非常的方便。

除了服务管理和负载均衡两个常用功能外，网易蜂巢还提供了数据库、缓存、对象存储、云硬盘等功能，绝大部分的web等服务搭配数据库和缓存服务，以及负载均衡，即可实现无状态，从而通过服务管理进行维护，非常的简单便捷。而云硬盘则主要是为有状态容器提供高可靠的持久化块存储服务，并且可以帮助用户完成格式化和挂载操作，也是非常便捷和人性化。

新版初体验到此结束，欢迎大家前去试用！

技术

云计算节点故障自动化运维服务设计

Posted on by aspirer

现状

  • 计算节点发生磁盘损坏等数据无法恢复的异常时，节点上的云主机系统盘无法恢复，导致云主机只能被清理重建
  • 计算节点宕机但磁盘数据可用时，重启即可恢复所有云主机的运行
  • 计算节点多次宕机（或一段时间内频繁宕机），则需要迁移所有云主机或者直接清理重建，云硬盘需要迁移到其他cinder-volume存储服务节点

一般来说重建过程比较耗时，并且云主机数据盘数据会全部丢失；另外采用本地file镜像启动的云主机离线或者在线迁移比较耗时并大类占用物理机硬盘和网络IO，会进一步加重计算节点负载，增大宕机可能性，实际情况下迁移操作的可执行性大打折扣。

另外有一些对我们自动化恢复流程有利的功能或者设备已经逐步上线到新建机房，因此可以考虑在这些机房实施相关的自动化恢复方案。比如义桥机房服务器已经全部配备远程管理卡，并且基于ceph存储作为系统盘+云硬盘的云主机也已经上线到该机房，这是我们实施该方案的基础。基于ceph存储后端的云主机在异常恢复过程中，没有数据的拷贝，不会占用硬盘和网络IO，因此恢复速度较快，可以做到几秒内在正常节点恢复运行（不包含云主机操作系统启动时间），相比现在的直接下线无法恢复或者数小时的更换硬件耗时，是对云主机SLA相当大的提升。

需求

  • 保证异常节点上所有被标记为需要恢复的云主机、云硬盘资源被正确恢复（处理过程中本进程退出其他进程可以继续）
  • 把所有被处理的资源记录在案（资源id、所在节点、处理时间、调用nova/cinder服务的request-id、处理状态等）
  • 保证异常处理服务本身的高可用

场景

用户创建云主机

用户创建云主机时指定宕机恢复策略，目前有三种：

  • null：不做处理，节点下线之后残留在数据库
  • 恢复：在其他正常节点恢复重建
  • 删除：直接删除

节点首次异常

首次异常之后要尝试重启节点（上面的云主机、云硬盘不做特殊处理），但节点已自动重启的除外，并要分析异常原因，找到原因并可以修复的软硬件异常，则不需要记录到节点异常次数中，否则需要记录在案，用做下次异常时的处理依据，记录前未找到原因，但事后找到的，需要从异常记录中删除该次记录。

节点多次异常

多次异常节点需要做下线处理（多次异常包含首次异常后重启失败的情况），节点上的云主机需要根据创建时指定的宕机处理策略来执行相应的操作，云硬盘则一律迁移到其他正常服务的cinder-volume节点（并不会实际的迁移数据，对用户使用没有任何影响），处理过的云主机、云硬盘要记录在案，便于事后查验。

方案

本方案只是初步想法，还需要在开发过程中继续完善，尤其是服务高可用部分，以及与哨兵系统的交互部分，会对本服务的设计造成较大影响。

云计算节点异常自动化处理流程

依赖

  • 被恢复的云主机需使用ceph启动盘+ceph云硬盘
  • nova、cinder支持把服务强制设置为down状态（cinder可选，nova必须支持，否则需要等待超时变成down才可以执行云主机的宕机恢复操作）
  • 哨兵系统异常主动通知机制（建议），或者哨兵系统提供api供我们轮询节点状态
  • 哨兵系统提供接口可强制重启和下电节点

后续

  • L3节点宕机自动化处理流程
  • 动态资源调度功能：可根据节点负载动态均衡云主机分布
  • 节电省成本：可将空闲节点云主机迁移之后下电节点
技术

对私有云一些问题的思考

Posted on by aspirer

 

问题

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

答案

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

 

生活

云涛名苑业委会组建意向初步调研结果

Posted on by aspirer

概述

截至6月23号晚8点，共有78位邻居填写了调查问卷：https://www.wenjuan.com/s/eMvmUzS/

详细调查结果请参考这里：http://www.wenjuan.com/report/basic_chart/57674c15a320fc8c889c1706

问题2分析

大部分邻居对卫生和物业人员还算满意，最不满意的就是电梯和车位，车位应该主要是指地面免费车位，主要问题应该是保安查看剩余车位不及时，经常有车位不让进。。。

电梯维护感觉跟物业关系不是特别大，物业应该主要是应该在出现故障时，能及时报修给电梯保养公司，目前看来物业这点做的还不够好，也可能是物业不能及时发现电梯偶尔出现的故障，比如电梯无法关门，偶尔out of service等，如果这种情况邻居有反馈给物业，但是物业没有联系电梯保养公司检查，那就属于物业的责任了。

总体来说，大部分邻居对中粮物业都不是很满意，满意度应该在50%（平均3.X分）左右。

chart (1)

问题3分析

这个问题主要是想了解下邻居们对相关规定的了解情况，目前看来大家都是第一次买房，不熟悉相关规定，这应该也是大家没能及时筹备业委会的一个重要原因，后续大家可以多分享一些相关知识，可以帮助大家了解业委会的要求、职责、作用、限制，以及可能出现的问题等。

另外还是有几位邻居有相关经验的，希望这些邻居可以在我们真正要筹备业委会的时候，可以挺身而出，给大家一些指导性的意见。

chart (2)

问题4分析

这个问题的结果与上面的问题有点冲突，看起来大部分邻居都是不了解规定，但是直觉上感觉应该是满足规定要求的。但是我感觉如果投票人数只有不到80户（总户数如果没记错的话，应该是400多），肯定是不满足要求的。

chart (3)

问题5分析

跟上面的问题结论比较匹配，大家都觉得应该成立，众望所归、群众基础较好，但问题还是一样的，基数太少。。。

chart (4)

问题6分析

既然大家都感觉应该成立业委会，就得知道大家实际组建过程中会不会参与、积极性如何，通过这个问题我们可以看到，大部分邻居都是想简单的投个票了事，不太想深入参与，可能大家都比较忙吧。还好有几个邻居乐意参选，是我们可以依赖的领袖！

另外我还想说一句，调查结论肯定比实际参与的情况要好一些，也就是说实际操作起来不一定有这么高的积极性，毕竟动动手指比实际行动要难很多。。。chart (5)  问题7分析

首先说下为啥要设置这个敏感问题？

我一直认为人性总有恶的一面，都有经不住诱惑的时候，除非诱惑不够大。。。

实际结果也是类似，一半的邻居都觉得或多或少会存在业委会勾结物业问题。。。

这也会对我们组建业委会造成一定的不利。。。

1分 2分 3分 4分 5分 6分 7分 平均分数
可能性分数 28.57%
22人		 16.88%
13人		 20.78%
16人		 19.48%
15人		 14.29%
11人		 0.00%
0人		 0.00%
0人		 2.74
受访人数77
技术

云主机镜像发布系统构想

Posted on by aspirer

现状

制作

  1. sa+开发准备模板，提交到gerrit，并交叉review
  2. merge模板，sa使用镜像制作工具（oz）制作镜像（windows镜像除外）
  3. 对于初次制作的镜像，可能需要sa手工处理各种特殊问题（如网卡配置、服务配置等）

测试

  1. sa制作完毕，上传镜像到联调环境，一般设置为私有并共享给qa
  2. qa进行各种验证（部分已自动化）
  3. qa测试发现问题，则通知开发和sa进行分析解决
  4. sa和开发再次修改模板，并制作新镜像
  5. qa测试通过则通知sa上传到对应的公共测试、线上环境
  6. sa上传到线上环境admin账号下，并共享给qa
  7. qa在线上进行最后的验证，不通过则重新制作镜像
  8. qa测试完毕通知sa将镜像设置为public正式对外提供

发布

  1. sa负责上传到联调、演练、公共测试、线上环境
  2. sa负责镜像版本在各个环境的更新同步
  3. 目前线下环境镜像版本比较混乱，环境和镜像比较多，靠sa人肉维护不太现实

目标

制作

  1. 尽量自动化
  2. 做完的镜像要有初步检查脚本（比如各种软件是否安装成功，配置是否修改正确，二进制是否替换等），建议和镜像模板一起提交检查脚本
  3. sa根据初步检查结果决定是否要重新制作镜像
  4. 较小的配置改动，建议通过mount镜像的方式修改，而不是再次制作新镜像（有qa二次验证，不用担心这种修改导致镜像有问题）

测试

  1. 尽量自动化，最好全部自动化
  2. 可以实现两个检查脚本，一个用来检查镜像内部配置（可以参考sa的初步检查脚本并进行用例扩充），二是外部的云主机各种操作脚本（创建删除、挂卸卷、挂卸载网卡、迁移修改规格等）

发布

  1. 开发一个镜像发布管理系统（具有预发布功能），并使用glance上传镜像时可以从指定http地址下载镜像功能实现镜像自动发布
  2. 系统可以执行发布、查看、修改、共享、删除、弃用等镜像管理操作
  3. 系统可以查看镜像版本，与sa制作的最新镜像的版本差异等
  4. 系统可以更新指定镜像
  5. 其他附加功能
  6. 具体功能参考“发布场景”描述

发布场景

账户管理

分为多个权限级别，如sa、qa、dev、ro等，其中sa拥有最高权限，可以增加删除账号，sa的账号需要手工在数据库中初始化，其他账号由sa创建管理。

用户登录

用户输入用户名密码即可登录，可以限制仅在办公区访问。

sa预发布镜像到发布服务器

sa制作完成后，将镜像拷贝到发布NOS等存储服务（对外需提供无需认证的http下载链接，用来glance-api下载镜像），该服务器要可以与所有环境的glance服务的网络连通，如果无法保证网络连通性，则需要部署多个发布服务器。

sa发布镜像到nos之后，登录发布系统，填写或者选择已有的镜像发行版类型（如Debian）、版本（如7.0）、位数（如64bit）、校验和（如镜像md5值）、镜像描述信息、镜像存放地址（如nos下载链接），完成预发布。

qa测试新制作镜像

sa预发布新镜像后，qa在web上切换到测试的环境（对应于发布系统与各环境网络全部连通场景），或者登录测试环境的发布服务web页面（对应各个环境独立部署发布服务场景），选择要测试的镜像（可以首先通过“操作”的“镜像详情”查看镜像制作时间、版本、md5等信息），点击“操作”中的预发布，预发布的镜像为“私有”属性，隶属于配置的管理员用户，qa通过“操作”中的“共享管理”功能，将预发布的镜像共享到自己的测试账号下，进行镜像测试，测试通过后，点击“操作”中的“测试通过”，表示该镜像已通过测试，可以发布到各个环境，只有“测试通过”的镜像才可以进行发布操作。

sa发布镜像到线上环境

首先是选择“预发布”操作，之后“共享管理”给qa测试，“测试通过”后，sa选择“发布”即可完成。

sa/qa/开发查看各环境镜像版本

打开相关web页面即可查看

sa/qa同步更新线下环境镜像版本

根据相关环境的镜像信息即可进行相关的发布操作，如果已经确认测试完毕的镜像，预发布后直接点测试通过最后发布即可。

sa/qa/开发查看各环境某个镜像的历史版本信息

点击版本信息即可查看

sa维护管理线上环境镜像

弃用/启用镜像

点击版本信息，并启用或者弃用某个版本的镜像即可

删除镜像

主要是为了sa清理镜像中间版本，防止镜像制作测试过程中产生的不可用镜像，被错误的发布到线上，以及删除某些确实无法使用的镜像，一般来说弃用镜像即可，不需要删除。

共享镜像

通过“操作”的“共享管理”即可

设置私有/公共镜像

预发布镜像都为私有，已发布的镜像都是公共，某些企业用户或者内部服务的专有镜像，不需要设置为公共镜像，通过“共享管理”共享给指定用户即可。 如果某个镜像需要从公共镜像改为私有镜像，建议通过“弃用”镜像实现，或者删除重新发布。

修改镜像描述

仅sa可修改镜像描述，描述信息会在发布到相关环境时设置到glance的description字段中。

其他人员查看各环境镜像信息

只读静态页面即可，无敏感信息，不需要认证，可设置为仅办公区访问减少安全风险。

设计

架构图

发布服务器与所有机房网络连通场景

只需要一个发布服务器和域名即可：

Alt pic

发布服务器分别部署到所有机房场景

可能需要多个发布服务器和域名：

Alt pic

web前端

主要界面类似下图：

Alt pic

web后端

无状态服务，部署在一个或者多个服务器上（视服务器与各环境的网络连通性决定），配置好相关环境的glance admin账号密码，和keystone、glance api地址，用来生成web页面，以及调用glance-api服务执行各种管理操作。

最好能搭建一个服务器，可以访问所有环境的glance-api服务，架构将会十分简化。

用镜像的校验和来作为镜像的唯一索引依据。

数据库

部署在一个服务器上，可使用公网IP对外服务（无敏感数据，仅用来记录镜像版本、更新记录以及镜像描述等信息）。 使用mongodb或者MySQL均可，表结构比较简单，主要以镜像md5为索引，来保存镜像已发布的环境、发布状态、描述、测试状态、发行版、版本、位数等web前端需要展示的信息。

流程

  • sa/开发负责镜像制作
  • qa负责镜像测试
  • sa负责线上环境镜像的更新维护
  • qa负责线下环境镜像的更新维护
  • sa/qa/开发均可查看线上线下环境的镜像版本及其他信息，以便提醒相关人员同步或更新镜像
技术

制作Ubuntu-16.04-amd64 OpenStack镜像cloud-init注意事项

Posted on by aspirer
  1. 安装cloud-init
  2. 配置合适的数据源，配置文件位于/etc/cloud/cloud.cfg.d/90_dpkg.cfg，一般配置为[ConfigDrive, Ec2]，也就是通过ConfigDrive盘或者Ec2（nova metadata api或者说169.254.169.254接口）数据源来获取云主机配置信息
  3. 根据需要修改cloud-init的配置文件，位于/etc/cloud/cloud.cfg，一般是为了打开root用户的用户名密码登录功能，比如如下配置：
  5. 修改cloud-init服务启动依赖，这一步是为了防止/etc/network/interfaces里面有多张网卡的dhcp配置，而启动networking服务的时候如果只有一张网卡，就会报服务启动Failed，导致依赖networking服务的cloud-init服务无法启动，修改方式为：注释掉/lib/systemd/system/cloud-init.service文件中的Requires=networking.service这行，也即改为：#Requires=networking.service
  6. /etc/default/grub中GRUB_CMDLINE_LINUX_DEFAULT加上console=tty0 console=ttyS0,115200，用来生成console.log（nova console-log可以获取到）
  7. 网卡名称ensX重置为老版本ethX方法是在上面的配置中继续增加net.ifnames=0 biosdevname=0

 

技术

网易蜂巢IaaS平台工作阶段总结（计算存储部分）

Posted on by aspirer

以下为蜂巢正式上线以来，IaaS平台云主机服务相关工作的一些总结

注：根据Jira和个人记忆整理，可能存在遗漏

工作内容列表

  • 转移云主机功能支持及优化
  • ceilometer计费支持
  • 解耦nova-metadata接口
  • ceph存储后端支持
  • ceilometer+qemu-ga的云主机监控支持
  • config drive功能支持
  • 租户网络初始化过程优化
  • 对应用运维开放部分API
  • 无物理资源错误信息详情展示
  • 云主机静态IP支持
  • nova创建云主机耗时优化
  • 云主机操作系统启动耗时优化
  • Docker运行环境调研
  • 物理机宕机重启云主机自动恢复支持
  • 支持超售比例针对单台计算节点设置
  • 单台计算节点云主机密度提升
  • 错误状态云主机云硬盘数量报警
  • keystone token创建及验证耗时优化
  • nova/glance/keystone/cinder/umbrella相关服务日志接入ELK
  • RabbitMQ服务故障重连问题修复（nova/cinder）
  • nova/glance/keystone/cinder/umbrella相关进程支持打印栈信息
  • 支持创建不带网卡的云主机
  • API性能优化（nova/glance）
  • 3.18内核virtio bug修复（修复中）
  • glance返回空body问题修复（修复中）
  • keystone升级M版本调研
  • 支持带网卡转移云主机
  • 云主机在线垂直伸缩
  • 云主机网络状态检查

工作内容详情

转移云主机功能支持及优化

主要目的是为了加速蜂巢docker运行环境的创建和初始化，提升蜂巢产品形象改进用户体验。改进方法是上层维护云主机资源池（按可用域、规格），当有用户需要创建容器时，直接从资源池中分配云主机并转移给用户，作为docker运行环境（通常耗时0.5~2s），避免了创建云主机流程（通常耗时10~30s）。

针对从资源池转移云主机耗时超过秒级情况，我们又进一步做了优化，取消了转移前后两个租户/用户资源使用量的更新以及发送notification这两步比较耗时的操作（有参数可选是否更新资源使用量），从而进一步加快转移速度（毫秒级）。

ceilometer计费支持

公有云计费功能不可或缺，针对蜂巢提出的对外网网络流量计费需求，我们基于ceilometer从MQ获取了每个租户每个网络端口的流量信息（neutron负责推送流量信息到MQ），并输出相关信息给计费服务。

针对当前计费服务存在的一些问题，如可靠性、可扩展性、易用性、性能等方面的问题，新的计费方案也在设计当中，预计第三季度可以开发完成并上线。

解耦nova-metadata接口

解耦云主机内部对169.254.169.254相关metadata接口的依赖，目的是减轻neutron-sever的压力，减少nova-metadata服务的部署和维护工作，提升平台安全性和可靠性并在一定程度上降低成本，解决因为metadata接口或不可用超时导致的各种问题（如云主机初始化不正确、infos接口获取云主机信息失败等）。

该接口的替代方案是使用config drive，因为从169.254.169.254获取的相关信息基本都是静态的，与云主机各种生命周期操作无关，config drive是一种更安全高效稳定可靠的云主机信息提供方案。

ceph存储后端支持

基于ceph分布式存储系统的流行，以及其与OpenStack深度整合所带来的各种益处，我们也在逐步切换到ceph存储后端，其中涉及到的相关问题有：

  1. ceph后端接入cinder
  2. 原nbs后端相关特性的支持（如QoS设置更新、ssd/sas卷类型支持等）
  3. 部署方案设计（独立部署、与nbs混合部署、镜像存储后端、快存储后端等）
  4. 快照功能相关优化（在线快照支持、链式快照深度问题优化等）
  5. OpenStack整合功能验证及改进（如nos+ceph或nbs+ceph混合部署场景的支持、用户使用场景分析及限制等）
  6. 蜂巢相关需求开发
  7. 基于ceph存储后端的功能支持（如计算节点宕机自动恢复、在线迁移）

ceilometer+qemu-ga的云主机监控支持

原有监控方式（包含操作系统状态）是在云主机内部增加监控脚本配合定时任务，通过云主机网络来推送监控信息到云监控，存在如下几个方面的问题：

  1. 安全性（监控脚本+定时任务方案是针对私有云场景设计的，基本没有考虑安全性问题）
  2. 可靠性（定时任务受用户进程影响较大、依赖云主机网络）
  3. 可维护性（更新维护不便、出现问题分析困难）
  4. 未考虑windows操作系统云主机

为此我们基于ceilometer服务，再其框架基础上，增加了qemu-guest-agent获取云主机内部监控数据的功能，相比ceilometer原生。基于libvirt获取监控数据方案，极大提升了监控数据的准确性。并且很好的解决了原有方案存在的问题。

config drive功能支持

config drive主要是为了给云主机提供稳定的信息源，相比依赖网络的nova metadata api，其开销只是一个64M的文件镜像（qcow2格式其实只有1M以内），基本可以忽略，并且具有只读属性，有效防止用户篡改导致的云主机初始化异常。更重要的是其可靠性有极大提升，主要改进了云主机网络异常、nova metadata服务异常、neutron metadata-agent/namespace-proxy异常等场景下导致的云主机初始化异常问题，如云主机主机名错误、静态IP场景下IP地址配置失败、文件注入失败等。

另外该功能也是云主机静态IP功能的基础，如果云主机继续依赖metadata api获取信息，则会出现循环依赖问题（云主机需要网络通过metadata api获取IP等配置信息，但是IP等网络配置信息又依赖metadata api获取）。

租户网络初始化过程优化

私有云环境每个用户都是有效用户，默认为所有用户初始化私有网、L3 router、VPN服务是一种节约运维成本的有效有段。但公有云却并非如此，很多用户注册完成之后，并不一定会真正的创建资源，或者使用到所有网络服务（如VPN服务很多用户都从来没有使用，而是改用web console或者通过公网IP ssh到容器内部），所以修改公有云用户的网络资源初始化流程就特别有必要。我们主要是拆分了租户网络初始化的各个流程，可以做到单独初始化、按需初始化，极大的减少了资源浪费，降低了单个用户的成本开销。

对应用运维开放部分API

主要是开放了容量计算以及平台资源信息等接口，方便应用运维可以将容量监控实现自动化监控报警。

无物理资源错误信息详情展示

该功能主要用来帮助用户（如nlb、rds、nce，或者yun.163.com的IaaS用户等）自己定位云主机创建错误的原因，我们会在没有可用计算资源、网络资源、网络初始化错误等场景下，返回准确的错误信息，用户根据错误信息即可初步确定错误原因。

当然这只是一种事后的补救措施，更加正确或者完美的做法肯定是不让用户遇到创建错误问题，这就要求我们在资源规划、服务可靠性方面多下功夫。目前公有云已经做的相对完善，但私有云仍然有很多问题，所以该功能在私有云环境的作用比公有云要大很多。

云主机静态IP支持

该功能与转移云主机类似，也是为了加快docker运行环境初始化而设计开发的。我们通过分析云主机从创建到网络连通也即可用的耗时，发现相当多的时间都耗费在等待dhcp分配ip上（正常情况下10~60s，异常情况则会超过2分钟甚至始终无法分配ip导致云主机网络不通），为此我们设计并开发了云主机的静态IP方案，在云主机创建或者后续动态挂卸载网卡的时候，可以为网卡配置正确的IP地址、网关、路由、DNS等信息，从而将网络初始化耗时降低到1s以内。

该功能依赖config drive和qemu-guest-agent，config drive用来支持创建过程的静态IP配置，而动态挂载网卡则需要依赖qemu-guest-agent。另外由于官方的cloud-init依赖网络，会导致云主机的网络无法使用其进行配置，所以我们又另外新增了一个服务，用来模拟cloud-init来实现网络配置，在网络服务之前加载，保证网络服务启动时相关配置已经准备完毕，之后cloud-init就可以正确完成其自身工作。

nova创建云主机耗时优化

有了云主机资源池之后，大部分情况下用户创建容器的场景都不需要执行创建云主机操作，而是从资源池转移一台云主机即可。但是也有一定的情况下，资源池云主机耗尽，需要通过新建云主机来完成docker运行环境的初始化，这种情况下就要求云主机创建耗时尽可能少。

我们分析了nova创建云主机流程，发现了一些概率性耗时较长的操作（比如nova-compute定时任务对创建云主机RPC请求处理的影响、以及不合理的加锁逻辑、不必要的资源更新等），并一一进行优化，从优化前的最长1分钟以上到当前平均10s左右（单台创建到可用99值在15s左右）。

云主机操作系统启动耗时优化

创建云主机直到可用包含两大部分，上面提到的nova创建云主机算是第一步，云主机自身操作系统启动是第二部分，我们对这方面的优化除了上面提到的静态IP方案改动，还尝试了各种方案，有些由于效果不佳、性价比较低而最终没有采用（比如qboot代替smbios、重新编译内核去掉initrd等），当前主要采用的优化手段包括优化cloud-init耗时，异步生成ssh host key等。优化后云主机操作系统启动耗时大概在5s左右，正常情况下最长不超过10s，99值应该在6~7s。

Docker运行环境调研

这部分工作也是为了加快docker运行环境的初始化，主要调研了hyper.sh和clear container，以及上面提到的qboot替代smbios方案。但通过分析，发现无法满足我们对安全隔离的要求、或者这些方案无法与OpenStack很好的结合。

物理机宕机重启云主机自动恢复支持

之前私有云环境的计算节点宕机后，需要做较多的手工运维工作，才能将节点上的云主机恢复可用状态（尤其是网络连通性），私有云主要支撑公司内部产品，这些产品通常具有很好的集群容错性，单节点甚至部分节点宕机对集群影响基本可以忽略不计，所以恢复时间稍长对产品可用率影响不大，但换到公有云环境，则面临更加严格的SLA要求，否则对产品形象和盈利都有很大不利，所以我们分析了影响宕机自动恢复的各个问题点，并针对性的做了改进和多次的线下宕机恢复测试，目前已经可以做到节点宕机重启后无需人工介入节点上所有云主机即可全部恢复可用（通常耗时15分钟左右），主要改进有等待云硬盘挂载完毕、等待ovs规则刷新完毕、并主动刷新虚拟网卡状态，以保证云主机尽快可用。

支持超售比例针对单台计算节点设置&单台计算节点云主机密度提升

这两个工作其实是一个目的，都是为了降低成本。第一个功能使用nova原生的AggregateCoreFilter即可支持，第二个则需要配合更多的测试验证工作，以保证用户体验。

错误状态云主机云硬盘数量报警

这个功能是为了监控线上错误情况，正常情况下应该没有错误，或者仅有个别上层服务用户（如rds、ncr等）参数使用错误导致创建云主机或者云硬盘失败或者物理资源不足导致普通用户创建失败（完全不应该发生），之前出现过一种情况是线上某个服务出现故障，导致物理资源被错误状态云主机占用很多，没有及时清理，影响了剩余物理资源的统计结果，所以我们加上了这个报警，就可以每天（可配置）监控错误情况。该功能由umbrella服务基于ELK报警实现。

keystone token创建及验证耗时优化

测试环境曾经出现过某个用户修改密码导致token、用户创建超时等问题，原因主要是修改密码要清理用户已有的token，如果用户当前使用的token数量太多，而token表又没有加索引，就会锁表很长时间，影响其他用户的操作。加了索引之后，很大程度上缓解了此类问题，但是仍然有概率性的耗时过长问题（创建token偶尔8~10s），我们又去掉了token表中catalog字段的无用内容，并会在后续将keystone数据库使用的硬盘从sas改为ssd，应该会有进一步的性能提升。同时我们也会测试M版本keystone的性能，看下有没有改善。

nova/glance/keystone/cinder/umbrella相关服务日志接入ELK

接入ELK可以方便的进行日志统计分析、问题定位、错误报警等，对服务运行状态监控、性能优化、bug修复等方面有极大的帮助。

RabbitMQ服务故障重连问题修复

当前我们使用的Havana版本OpenStack组件存在该问题，nova、cinder、neutron等服务在使用集群模式的MQ场景下，第一个MQ节点异常之后，不会尝试重连第二个节点，新版本已经修复，但backport回H版本比较困难，我们对其进行了修改，使用了python amqp库来加快移植速度。

nova/glance/keystone/cinder/umbrella相关进程支持打印栈信息

参考neutron之前的实现，执行kill -USR1 $pid可以打印进程的调用栈信息，方便获取调试信息。

支持创建不带网卡的云主机&支持带网卡转移云主机

第一个功能目的是为了减少创建资源池云主机后，从资源池中转移给用户时无法携带网卡，需要先卸载掉所有网卡而优化的，这个功能可以使NCE在创建资源池云主机时不带虚拟网卡，从而省去转移前的卸载网卡操作流程。

第二个功能是为了进一步加快转移速度，我们计划与网络组合作开发携带虚拟网卡转移云主机功能（私有网除外），从而减少资源池云主机转移完毕后，还需要挂载多个虚拟网卡到云主机这一耗时较长的步骤（3张网卡通常需要10s甚至更长时间），私有网卡可以延迟挂载，对用户创建容器过程中的docker运行环境初始化流程影响不大。该功能上线后，预计可以将docker运行环境初始化过程减少到3s以内（上面已经提到云主机转移在1s以内，其他耗时视neutron转移端口接口耗时而定），也即减少了大概10s左右。

云主机在线垂直伸缩

计划通过balloon技术来实现内存的在线动态调整，方便容器的扩容和支持单个云主机运行多个docker实例（属于同一租户）。主要难点是计算节点资源管理和更新问题，以及无法满足内存扩容情况的处理，还有就是内存balloon失败之后的异常处理问题。

云主机网络状态检查

网络组之前已经在云主机内部加入了自动分析网络状态的定时任务，可以每5分钟分析一次网络配置和连通性，保存检查结果到特定路径，我们打算利用ceilometer+qga+ELK实现云主机网络状态的监控和报警，ceilometer+qga当前已经支持云主机操作系统状态的检查，再加上网络状态检查可以更好的确认云主机运行状态，获取云主机内部网络状态信息后会打印到日志，由ELK收集并处理，方便后续添加相关报警。

Keystone升级M版本

计划先从改动最小的keystone组件入手，调研升级步骤和新版本性能、功能改进情况，其他组件视情况决定是否继续升级。

其他工作

  • yun.163.com控制台前端优化（用户+管理员）
  • 信息安全相关需求开发
  • 节点扩容
  • 常规更新
  • LXC网络性能问题分析
  • 管理员权限安全问题改进方案
  • 镜像制作及更新

 

后续工作

  • 大规模集群支持
  • 性能优化
  • 可靠性增强
  • 可用率提升
  • 自运维改进
  • 降成本
  • 用户体验
  • 流程优化

 

 

技术

使用ceilometer+snmp监控物理机

Posted on by aspirer

可以通过ceilometer+snmp方式监控物理机的基本状态信息（cpu、memory、disk、network），centos7+openstack-kilo配置过程如下（100为被监控的物理机，也是snmpd服务端；101为ceilometer-agent-central服务节点）：

配置snmp服务

首先配置被监控物理机的snmpd服务，centos已经自带该服务，但默认是关闭的，需要修改配置文件后启动服务。snmpd配置文件修改如下：

配置防火墙

打开被监控的物理机防火墙udp协议的161端口，命令如下：

建议写入iptables配置文件以便持久化（重启服务器仍然有效）：

或者直接关闭iptables防火墙服务（不建议这么做）。

测试snmp服务

启动snmpd服务，建议加入开机自启动，防止服务器重启后服务关闭：

测试snmp服务是否正常，先在snmpd服务端执行测试：

之后再到ceilometer-agent-central服务所在节点也就是客户端执行同样的测试命令，正常即可继续下一步。

配置ceilometer

修改ceilometer的pipeline配置：

重启所有ceilometer服务，主要是central和collector两个。
查看ceilometer-agent-central服务日志，重启后600s左右输出如下内容表示监控物理机配置正常：

支持的监控项有从上面的日志可以看出（hardware.*那些项目）。

监控数据获取方法

首先查看所有hardware监控项的meter-name：

第二步是可以通过sample-list命令查看采样点数据列表：

或者通过statistics接口获取统计数据：