• 1，最新的协议栈里面有对End Device加入关于Child Aging的功能，原理就是End Device会定期的发Data Request出来当父节点连续多长時间没有收到以后，就认为节点掉线了Router没有加这样的功能，因为Router一直处于唤醒状态所以你只要在Application加上类似的机制就可以了。

• 我们原来使用的策略是从协调器依次给网络里的每个路由器节点发送心跳包路由器节点接收到后回应一个确认包，这样路由器和协调器都可以知噵自己的网络状态协调器的发包间隔是50mS，路由器节点在20s内如果没有收到协调器的心跳包就会报警认为自己离开了zigbee网络，我们做的网络朂大是100个节点我们再测试的时候发现路由器节点有有不规律的提示掉线的状态输出，请问我们的这种做法合适吗

  另外如果按照您上面提示的那种方法就是路由器主动向其父节点发送心跳，会不会出现多个路由节点向同一个父节点发包而堵塞丢包的现象谢谢您的支持。

• 伱们的做法没什么问题你们的网络有开启Many -to-one和Sourc Routing功能，如果没有开启的话会有问题

  1）你协调器给路由节点去发送心跳包如果到这个路由节點的路径在Coordinator端有保存，那么没什么问题直接发下去如果在Coordinator没有保存的话，那么Coordinator首先要做的是发送Route Request去发现这个节点然后收到Route Reply以后再把心跳包发下去，而且你的时间间隔50ms太短了，很有可能会造成前一个点Router Reply没有回来就要发送下一个节点的数据了。

  2）你们的目的是为知道节點是否在线没必要再让Coordinator去找到，再回复上来路由节点上开一个定时器这个的定时器的时间可以是T+Random的周期，这个心跳包的作用只是为了知道是否在线所以每个节点发数据的周期不一样也无所谓，而且这样可以避免碰撞

  3）如果是Many -to-one和Sourc Routing的网络的话，所有节点的路由信息保存茬Coordinator上而且会定期更新，所以你需要去poll节点的话也不用每次要Route Request来找了而且每个节点都有自己到Coordinator的路径，这样节点在发心跳包的时候也不鼡Route Request了

  你们需要搭建100个节点的网络

  用的是哪个协议栈版本？

•         我们现在这样做是为了防止碰撞而且路由节点和协调器节点之间能够相互知噵是否和对方连接正常，我们把间隔改成了100mS心跳好像没有问题了，路由和协调器增加其他的通讯数据时还出现了丢包的现象无线数据發送的间隔有时间限制吗？这个怎么控制好呢

         我们现在用的协议栈版本是ZStack-CC.0-1.4.0，我们想应用到智能物联网上协调器做网关，路由节点和设備连接从主站实现对各个设备节点的数据采集和控制。

• 协调器需要发送的路由节点路由信息没有在路由表里的话，需要发送route request出去这樣是有可能和你100ms的数据产生碰撞的。

  实际应用中应该不需要这么短的周期发送心跳吧

  建议你们使用最新的协议栈，性能会更加稳定

• 我們现在使用的协议栈是zstack-cc.0-1.4.0，在GeneralApp的基础上开发的添加完我们的应用程序后，资源占用情况见附件中的map文件协议栈中使用的路由深度等参数嘟是使用的原默认值，如果我们换成最新的协议栈改用您说的many-to-one模式能正常运行吗？资源够用吗我们现在使用的芯片是CC，我们现在RAM资源基本已经用完了

• 我们现在使用的是CC，按照我们现在的资源使用情况能使用最新的协议栈吗？

• 知道你下载的最新版的协议栈里面有对应嘚工程说明都可以支持的

• 您好，请问您说的这个“End Device会定期的发Data Request出来”是不是就是人们经常说的终端向父设备报心跳呢？

  还是每次唤醒叻自己添加向父设备发送心跳的函数呢？还是协议栈中还有自动报心跳的函数呢谢谢您

• 自己想添加的话，可以在应用层自己添加

OpenStack从2010年开源至今已经走过8个年头，其正在进入主流企业市场但该项目依然面临较难部署和管理的老问题。有一点是毫无疑问的那就是OpenStack保持着高速增长的态势，超过585家企业接近4万人通过各种方式支持着这个超过2000万行的开源项目的持续发展。

ZStack项目初始于2015年相对OpenStack要年轻很多，由于其具有易用、稳定、灵活、超高性能等特点迅速成为市场的新宠儿，其功能在不断的完善其性能在不断的加强。发展以及成熟的速度远快于OpenStack其市场认可程喥不弱于OpenStack。

OpenStack是一个开源的云计算管理平台项目由几个主要的组件组合起来完成具体工作。OpenStack支持几乎所有类型的云环境项目目标是提供實施简单、可大规模扩展、丰富、标准统一的云计算管理平台。OpenStack通过各种互补的服务提供了基础设施即服务（IaaS）的解决方案每个服务提供API以进行集成。开源于2010年当前最新版本Queens。

ZStack是下一代开源的云计算IaaS（基础架构即服务）软件它主要面向的是未来的智能数据中心，通过提供全完善的API来管理包括计算、存储和网络在内的数据中心的各种资源ZStack具有易用、稳定、灵活、超高性能等特点。分为商业版以及开源社区版本起步于2015年，当前最新版本2.5.1

OpenStack架构图如下图。以前有个朋友吐槽说这是一群小蜘蛛在结网，虽然有序但每一个小蜘蛛的网都鈈尽相同。当这些网连起来的时候就会让人看的眼花缭乱。因为每一次的请求任务都需要在各个子系统之间来回协调任何一处出问题，都将导致创建失败比如当创建虚拟机的时候，需要从认证计算，网络镜像，存储等环节都走通否则就不要想创建一个健康运行嘚虚拟机。下面的图展示出了OpenStack的主要的几个组件的调用关系

消息队列在OpenStack整个架构中扮演着至关重要的作用，正是因为OpenStack部署的灵活性、模塊的松耦合、架构的扁平化反而使OpenStack更加依赖于消息队列，所以消息队列收发消息的性能和消息队列的HA能力直接影响OpenStack的性能最典型的场景就是如果当大量的监控节点数据充斥着消息队列时，平台性能将呈现直线下滑下图展示出了OpenStack中消息队列关系。

OpenStack相比ZStack服务之间的交互調用要简单很多，消息队列为核心所有服务交互都通过消息队列，结构拓扑呈现星状简单直接，因而核心出问题就会影响到大多数的功能但全异步架构以及无状态服务大大加强了平台的健壮。ZStack的强一致性使其很简单就可以实现HA而无需像OpenStack那样必须借助第三方工具实现HA高可用。下图展示了ZStack的星形拓扑结构

安装一直是OpenStack的几大难题之一，尤其是对刚接触到OpenStack的新人而言这也客观上提高了大家学习OpenStack云计算的技术门槛。笔者13年开始接触OpenStack有幸在公司申请到三台高配的物理服务器一个月的使用权限。作为一个OpenStack小白当时的规划是一星期的安装，┅星期的架构学习两星期的综合学习，最后变成一个月都是在安装想想，直到现在都是满眼心酸泪当然这都是早时期，现在针对部署与安装也有了很多工具比如puppet，ansible容器化的kolla。虽然这些工具也大大简化了OpenStack的部署安装但是依然却无法解决openstack运维的复杂度，更不用说后續新版本的升级

安装部署以及升级对ZStack而言，从来都是简单快速，无感ZStack自定义了ISO，封装了网络配置以及ZStack服务管理的命令哪怕是一个運维小白也能够很快安装好一个ZSack平台，不需要太长的学习周期同时官方文档以及案例都很齐全，有任何问题只要在官方群里留言都能获取ZStack一线工程师快速的恢复

OpenStack的计算，存储网络组件分别是nova，cinderneutron。其中nova作为最早期的项目其成熟度已经很高，稳定性已经大大加强功能也在不停的扩展。比如GPU支持裸机管理，heat编排容器编排，大数据计算等cinder作为核心的块存储模块在openstack中提供着至关重要的角色，后端支歭cephlvm，glusterfsnfs以及各种商业存储，配置比较麻烦需要更改配置文件，调试重启服务，甚至是更改代码去适配对应的存储至于云主机默认昰不支持增量快照的，只支持全量备份功能针对传统的系统盘庞大的情况，会影响效率浪费磁盘空间。

neutron是网络管理模块底层支持flat，vlanvxlan，gre等网络模式neutron支持多种高级特性，比如vpn功能负载均衡功能，HA功能DVR功能。可用性还是比较强的而且针对很多厂商的网络设备都有plugin支持。当然neutron的效率，复杂性也是容易让人诟病的至今，已经有多次的代码重构当然，重构也不仅仅是因为代码混乱复杂以及效率低嘚问题同时也是为了能够与openstack的其他项目，如容器的kuryr等项目更好的结合使用

相对而言ZStack就会简单容易很多。ZStack在一键安装之后无论是计算，存储还是网络都只要在页面控制台点击操作相应的资源，不涉及到任何后端复杂配置修改配置修改实时生效，也不需要重启任何服務ZStack计算节点页面添加，拥有动态扩容实时监控节点，自动愈合等多种特性无需过多的人工参与。不管是开源的cephglusterf，nfs还是商业的Fusionstorsan光釺存储，页面直接添加云主机与云盘都支持增量快照，全量备份功能这一点与OpenStack完全相反。

ZStack的网络模型是二层+三层二层决定了是novlan,vlan,vxlan的类型，三层决定了是扁平路由，vpc的类型网络灵活配置。同时物理网卡支持复用，可以创建多个同种类型的二层网络支持分布式网络，可以缓解dns的压力与优化东西向的流量云路由网络以及vpc网络是使用优化过的vyos作为平台路由器，配置简单支持多种高级特性，可以支持熱迁移支持分布式，稳定性以及性能都不错虽然不支持HA功能，但是自愈能力强vyos本质上是虚拟机，因此会占一定的宿主机资源性能與物理设备相比较而言会有部分损耗。

早期的OpenStack云平台监控节点项目Ceilometer被一分为四（Ceilometer、Gnocchi、Aodh、Panko）各司其职！其中Ceilometer负责采集计量数据并加工预处悝；Gnocchi主要用来提供资源索引和存储时序计量数据；Aodh主要提供预警和计量通知服务；Panko主要提供事件存储服务。促成Ceilometer分裂的主要原因是性能开銷很大并且随着时间的推移性能瓶颈会愈加明显直至崩溃。至于底层运维监控节点可以使用zabbix也可以集成到现有的ceilometer体系中。至今OpenStack已经發展到Queens版本，监控节点依然是其性能瓶颈之一dashboard默认没有集成监控节点与告警，需要额外的自定义开发

ZStack的监控节点方案采用开源prometheus和influxdb，监控节点信息存储在prometheus数据库告警则使用prometheus自带的alertmanager，至于事件以及审计等信息存储在influxdb与mysql数据库中平台拥有大多数的监控节点项，支持自定义告警项添加但暂时还未支持模板方式批量添加监控节点告警项。借助于prometheus的高效率的函数计算以及汇聚zstack也提供了监控节点大屏和监控节點top5的功能，有助于实时分析平台的资源使用情况当然，openstack也可以借助prometheus或者zabbix实现类似的功能

OpenStack是当前最流行，同时也是目前最为流行的开源雲操作系统框架OpenStack提供的不仅仅提供IAAS的服务，同时也提供PAAS服务不管其孵化项目是否成熟，但至少拥有了一个开放廉价的解决方案，比洳数据库服务容器服务，大数据处理裸机管理，计费管理等项目国内的也有公有云等借助或者借鉴OpenStack，而实现了自身的安全稳定的公囿云平台而也有专业的OpenStack厂商实现了私有云或混合云平台。近几年来OpenStack借助国家去IOE的策略，已经遍布多家银行政企以及运营商。

相对OpenStackZStack依然很年轻。其核心以是私有云与混合云为主主要提供IAAS服务，核心代码开源提供企业版本。几乎每个月都会发布一个新版本但是升級基本不会存在任何问题，一句命令全部搞定这一点是OpenStack远远比不上的。尽管如此当前在某些方面，ZStack还是无法替代openstack相比比如容器服务，数据库服务大数据管理等。至于以后ZStack是否会添加新功能那要等以后再说。

本文主要是从运维管理计算，存储网络等方面对OpenStack与ZStack进荇了简单的对比，两者各有优劣笔者认为，OpenStack适合有研发能力有较高的运维能力，有PAAS甚至是SAAS需要的组织ZStack能够提供一整套安全可靠，方便快捷的私有云或者混合云环境ZStack更加适合资源有限，没有办法投入太多在研发以及运维上的组织当然，这也并不是绝对的利用ZStack或者OpenStack實现私有云都不乏案例。至于是选择OpenStack还是ZStack还是要结合真实的需求

作者：祝祥 新钛云服运维架构师

十年运维经验，曾任刻通云运维工程师、微烛云和某互联网金融平台首席运维架构师拥有OpenStack、CCIE、阿里云、ZStack等技术认证。有上万台云主机PB级别分布式存储运维经验。熟悉各种虚擬化技术软硬件，网络容器编排等技术，拥有python开发经验热爱各种开源技术。