ZStack 3.6.0，支持云主机从任意KVM云平台在线迁移至ZStack

 

常常在新闻里听到“企业号航母”并非新船，它是1962-2012年服役的，其核心功能已经稳定运行了50年。铁打的营盘流水的兵，船上的人常常变，电控系统和操做流程，既在尊重传统，也在持续演进之中。

体验完ZStack 3.6.0版本的更新，我看到了一个新兴商业软件的成熟过程。

若是用一个航母战斗群来比拟一个私有云计算平台，ZStack从软件功能上已经完成了“造一艘航母”的过程，这几回更新主要是“完善管理和人为操做的软装”，说通俗点就是让练兵更容易。

核心功能稳定

ZStack好久没有发布核心功能更新和关键BUG漏洞的补丁了，这并非ZStack黔驴技穷，而是私有云主机产品已经很完善了；我接触过十几个ZStack的客户，你们也都没反馈有什么BUG。

这里既有虚拟化软件二十年的经验积累，也是ZStack研发测试团队的军功，仍是“私有云/专有云”比公有云更稳定可靠的明证。

每当有朋友想了解云主机该有哪些功能，我并不会让他们盲目上手作实验，而是推荐他们看ZStack的产品说明书，只要是围绕云主机开展的功能，1000多页说明书里应有尽有。

 

严谨灵活的权限和流程

企业软件的买单决策人是项目负责人、CIO和CEO，在标准软件功能雷同之后，企业更看重商业软件和自身的管理流程是否匹配。企业的权限设计是以活动目录AD为事实标准的，ZStack是我见到最用心去兼容企业权限设计的私有云软件。

以ZStack 3.6.0的更新为例，本次更新将帐号和角色、权限和资源池（部门/项目）作了完全的解耦。这个设计在外行看来是细枝末节，但对于企业付费者是核心诉求。

互联网产品设计中，一个帐户表明的天然人是权限和资源设计的核心，你们以帐户的角度去管理资源，角色只是个“附加属性”，资源池统计管理的功能也被弱化了。

可是企业产品设计中，并不存在一个资源只被一个帐户管理的状况，帐户只是个身份登陆凭证。角色实际是一个权限集合，企业产品的受权操做是给帐户赋予某种角色，据此清晰表述一堆用户对一个资源池的受权粒度。

ZStack的另外一重要功能是承载审批和业务操做的工单。传统工单更可能是邮件的变体，参与者的角色只有客户和技术支持，最终工单落实要靠工程师跨到另外一个系统去操做；这种工单拿到企业环境价值不大，还不如邮件审批来的轻快。

带审批逻辑的工单，须要将“客户VS技术支持”的简单沟通，变成全部相关角色参与审批的企业管理过程；ZStack的工单系统还和业务系统紧密结合，流程审批结束时，既能够自动授予权限，也能够主动完成工做。这种工单系统本质上是企业客户要的流程自控系统。

我并不信任互联网思惟的云产品设计，只要客户仍是要“勾选用户注册协议”，这就不是一个平等的甲乙方关系，而是一个牧羊人和羊群的关系，牧羊人不会尊重羊群的管理诉求。

 

尊重工程师的操做优化

ZStack3.6.0版本但愿实现从造船到练兵，要想顺畅完成练兵，就要理解和尊重客户侧的工程师，顺应他们的传统工做习惯，并且减小繁琐易错操做，让客户专一核心业务判断。

顺应传统工做习惯并非贬义词，好比在网络设计中，传统不等于过期，多是经典场景中的经典设计。

ZStack在本次更新中，一个重要网络功能就是VPC防火墙。不少人会将防火墙和安全组混淆，将架构师和软件研发提出的防火墙设置建议，直接扭曲成安全组配置。但ZStack的说明文档很清楚的解释了，防火墙不等于安全组。

安全组诞生于大二层网络时代，作很差二层隔离那就先作好三层隔离，其部署位置在云主机的网卡上，其重点防范的是其余云主机的非受权访问。在二层隔离VxLan普及之后，安全组的东西向流量隔离功能已经略有鸡肋，其南北向访问的配置规则则过于简陋。安全组不必识别目标IP和端口，由于做用点就是本网卡；咱们曾经熟悉的“放行全部ESTABLISHED状态报文”，在安全组模式下也没法设置。

防火墙是部署在VPC路由器上的，并不关注内网传输，但对外部访问的控制粒度很细，不只能够识别源IP目标IP，对协议中的报文状态也有清晰的识别能力。对于老网络工程师来讲，防火墙规则中的“拒绝”和“丢弃”的区别，能够当作经典面试题，而防火墙规则中复杂的优先级设计，是网络工程师炫耀逻辑和工程能力的最好战场。此外VPC路由器支持了NetFlow，在VPC内排查故障，跟在物理环境上已经类似了。

ZStack每次更新都有大量操做简化优化，3.6.0版也不例外，目标是让使用者从边思考边操做一堆繁琐命令，变为只思考一次核心问题，只发出一条简单指令。

前文谈过权限设计以后，管理员就要作一个工做——在私有云平台上建立用户。ZStack提供了AD对接、表格导入的方式批量建立用户；云平台管理员不用把时间花在如何点鼠标新增用户上，而是集中精力判断该添加哪一个list的用户。相似的操做优化还有诸如主机硬盘同时快照、云主机优先在旧宿主启动，当主机和硬盘迁移时对目标物理机按负载高低排序。

若是说批量建立用户功能是个很是规的单薄操做，那咱们就看V2V的自动迁移，ZStack很早就支持vCenter云主机批量迁移，本次更新后支持了KVM云主机批量自动迁移。

V2V迁移原本是个重度依赖迁移工程师人力的工做，要求迁移工程师对业务了解、对通用虚拟化标准了解、对新旧V2V资源池的配置了解，而后瞪大了眼睛一台一台迁移。如今ZStack作了足够多的适配，将V2V迁移自动化，那迁移工程师的工做量会极大下降，他们的重点精力放在选择迁移对象和时机上。

高危操做并不能经过“操做优化”来避免，平台能作的只是精细化权限和明确审批过程，但绝对不是无端拖长审批过程甚至干扰高危操做，执剑人终归要承担执剑人的责任。

 

 利器在手活学活用

我常常强调一个概念，成熟的商业软件绝对不会让甲方工程师边缘化和失业；而是给甲方工程师留下“肥而不腻”的工做量。甲方工程师始终是一个有决策能力的专家，而非给供应商打工的苦力。

肥而不腻的肥”，指的是高含金量的工做是有业务价值、没法被简单汇总的工做；好比ZStack的权限设计只是个趁手的好工具，甲方工程师仍然要结合实际业务作精细调试；好比防火墙的策略设置比安全组复杂多了。

“肥而不腻的腻”，指的是别让甲方工程师太过劳累繁琐，好比我不确认V2V自动迁移能切掉几个友商KVM的项目，但我相信迁移工程师不会由于选择了ZStack而面临过大的工做量。

如今ZStack给甲方工程师打造的这套私有云软件，是有意识也有能力让客户侧工程师开心放心的练兵，最终用这套软件证实自身团队的价值。

再先进的武器也是为人设计的，即便无人机也要听司令官下命令。科幻小说里常常YY出脱离人类控制的灭世AI军队，但能毁掉使用者的程序，就是有严重BUG的程序，或者空谈式YY。