云社区 | 超融合产品选型中如何测试节点故障后的恢复效率？基于容器云平台灰度发布功能如何设计实现？

本期专家：

尹学峰  Rancher企业级Kubernetes管理平台 售前技术支持

纪    晨 LinuxONE 首席架构师

张家驹 红帽企业级开源解决方案中心 首席架构师

肖    林 博云企业级PaaS及云管理解决方案中心 业务咨询顾问

吴比伦 XSKY 资深存储解决方案架构师

荣重实 XSKY 资深存储解决方案架构师

钟锦锌 SmartX超融合 产品经理

刘    康 日志易 系统分析师

---

01 如果K8s或Docker有bug，底层的代码我们还是搞不定，风险如何控制？

@尹学峰  Rancher企业级Kubernetes管理平台 售前技术支持： 

首先为了避免供应商锁定，建议您找一家开源厂商的产品先使用起来。在使用过程中，慢慢提高自己的对Kubernetes以及容器相关知识的理解以及运维能力。毕竟与其坐而论道，不如知行合一。

02 有了Docker和K8s，我们还需要Openstack吗？

@纪晨 LinuxONE 首席架构师：

主要还是看应用，应用的现状（单体化）和容器化改造难度以及成本都会一定意义上维持乃至扩大虚拟机的生态，所以个人觉得长期并存是一个可以预见的状况。

而且k8s仍然需要在IaaS 层面提供支持，从k8s的设计理念来说它是不关心iaaS层面的，例如每一个cloud 提供商都需要提供一套自己的cloud 接口来部署虚拟机/裸机或者load balancer 等，这些都是需要云提供商提供的，openstack作为一种云提供商在这些领域的生态建设也做的很好。

所以，总体来说，openstack 在现有应用的继续支持和与k8s生态集成以及边缘计算等领域发挥持续的作用。

@尹学峰 Rancher企业级Kubernetes管理平台 售前技术支持：

OpenStack与Kubernetes是处于二个不同层面的事情。二者所解决的问题虽然在宏观上有一点相似性，但又有很大的不同。二者虽然存在一定的交集，但更多的是补充的关系。

所以可以明确的回答即使有了docker/Kubernetes(容器技术)，OpenStack(虚拟化技术)也是需要的。

03 虚拟机与容器并行承载同一套应用系统是否可行？？

@张家驹 红帽企业级开源解决方案中心 首席架构师：

可以，没有问题，好多金融客户都是把前端和逻辑处理放在PAAS上，数据库放在虚拟机或者物理机上。

04 基于容器云平台灰度发布功能是如何设计实现的？

@肖林 博云企业级PaaS及云管理解决方案中心 业务咨询顾问：

灰度发布的方案其实有很多，关键在于使用的容器云平台的架构是怎样的， 比如：

• 基于F5做灰度

• 基于K8S Ingress controller 做灰度

• 基于SpringCloud架构的ribbon组件做灰度

• 基于Istio架构方案做灰度（采用sidecar对应用流量进行了转发，通过Pilot下发路由规则）

• 自研基于Nginx方案做灰度

• 基于Kubernetes SLB引流：更新客户端或DNS解析，将Kubernetes 集群SLB地址追加到客户端或DNS中，实现流量引入。（不推荐，引流成本高，回滚风险高）

05 分布式存储的应用场景是什么，与异构云产品契合度如何？

@吴比伦 XSKY 资深存储解决方案架构师：

分布式存储的应用场景涵盖广泛，基本上90%的应用场景均可以适合，主要包括5大场景：1、虚拟化、云、容器场景：比如VMware、OpenStack、K8s等均有成熟解决方案；2、海量非结构化数据场景：大规模文件、对象场景广泛支持，比如文档管理系统、银行双录系统、数据湖等；3、传统应用场景，比如对接数据库，当做SAN存储使用；4、备份场景；大量的数据备份，使用大量大容量HDD盘替换原有的磁带库或光盘库等；5、大数据、AI的场景。

与异构云能够很好地契合，可以同时支持vmware等虚拟化、多种版本的OpenStack平台、cloudstack平台，还可以通过S3对接公有云等，这也是与各种HCI架构的不同点之一。

06 在分布式存储当中，是否需要使用低延迟的网络设备？

【问题描述】在分布式存储当中，除了ssd这个问题，由于采用了多副本的技术，需要跨交换机和跨主机存放，在性能这个重要的因素当中，是否需要使用低延迟的网络设备，如低延迟交换机和低延迟网卡，实际的投资回报会是怎样的一个效果？

@荣重实 XSKY 资深存储解决方案架构师：

主要还是看前端应用的需求，分布式存储固有的延迟很难做到集中式存储那样超低，所以双模IT架构是一定存在的。10多年前做分布式cluster网络使用infiniband，比如isilon有自己的横向内存池机制，必须要超低延迟才能实现；近些年网络产品进一步提高，使得万兆网络已经可以作为节点间通讯的介质，一般非结构化数据场景都差不多可以支撑，特殊情况下可以选择25或40Gb网络，如果能配合RDMA如RoCE会有更好的效果。

07 在超融合产品选型中如何测试节点故障后的恢复效率问题？

【问题描述】超融合选型测试时，其中一个关键点就是节点或硬盘故障后的恢复效果，也就是数据同步的效果，这点各位是如何测试的？

@钟锦锌 SmartX超融合 产品经理：

关于节点故障或者硬盘故障触发的数据恢复效率的测试主要分三种场景：

• 插拔 HDD

• 插拔 SSD

• 节点断电

测试考量的关键指标有：

1、数据恢复过程中对整个集群的性能影响（这个非常重要，数据恢复如果过分影响正在运行的业务是无法接受的。）

2、数据恢复量（由于技术差异原因，同样的场景，数据恢复量可能不一致）

3、数据恢复速度（涉及数据恢复效率）

4、数据恢复触发条件

不同测试场景的实际意义：

插拔 HDD （机械硬盘）测试：

主要目的是模拟硬盘故障的状况下，系统执行数据恢复的效率。

• 测试中需要留意副本策略（或者是 RAID 级别，纠删码级别等），例如 2 副本和 3 副本所允许故障的硬盘数量不一致，恢复速度也不尽相同。

• 测试中需要留意插拔硬盘的容量大小以及已写入数据量大小，观察拔出硬盘触发数据恢复量是全盘容量还是已写入数据量的恢复，这会直接影响到恢复效率。

• 测试中需要记录恢复时间，恢复数据量，计算出恢复速度；以及需要验证节点数量对数据恢复速度的影响（有些系统节点可以支持并发恢复，节点数多恢复效率更高；而有些系统可能不受节点数量影响）

• 触发数据恢复是否要专门的热备硬盘（使用空间的效率）

• 记录恢复过程中系统性能下降比例

插拔 SSD （固态硬盘）测试：

主要目的是模拟 SSD 故障的状况下，系统执行数据恢复的效率。由于 SSD 在不同的系统中有不同的用途，例如是作为缓存空间、容量空间，甚至是操作系统空间或者元数据存放空间等等，相比 HDD 来说更复杂，故障的影响可能更大，因此单独列出进行测试。

• 测试中需要验证 SSD 故障是否是单点故障

• 验证数据恢复量与 SSD 硬盘容量之间的关系（某些系统有磁盘组概念，单块 SSD 故障会引起整个磁盘组数据恢复）

• 恢复速度

• 记录恢复过程中系统性能下降比例

节点断电测试：

主要目的是模拟单个服务器节点故障的状况下，系统执行数据恢复的效率

• 节点失效到触发数据恢复需要的时间（考虑系统是否足够敏感）

• 节点长时间失效，数据恢复量（模拟需要长时间修复机器宕机问题）

• 节点短时间重新上线，数据恢复量（模拟重启解决机器宕机问题）

• 恢复速度（节点数量是否影响恢复速度）

08 应用日志管理采用准实时数据仓库技术，除了全文搜索外，还可业务指标抽取监控。有什么成熟的经验或建议吗？？

@刘康 日志易 系统分析师：

应用日志使用全文搜索引擎在分析问题的时候还是比较重要的，因为：

1. 可以加速查询，无需登录每台主机

2. 可以将各个应用模块进行串联分析

3.  将应用的整体趋势与各个相关联的并非此应用的内容进行结合查看，可以分析出性能问题

如果要做全文搜索引擎，建议要考虑一下我们的目标。假如是我们上面是主要目标，则：

1. 需要接入应用的全部日志

2. 需要有串联id

3. 日志输出一定要规范化。最常见的  时间、级别、串联ID、事件类型、事件描述、必须要全部按照一定格式输出。

4. 在接入的时候使用事件合并（如果有这个功能，可以大大减少日志规范化工作量）

在日常使用中，经常出现的问题是 日志打印不规范，输出内容多而无用。如果出现这个问题，且很难更改，那么问题重点不再是选用何种搜索引擎，而是如何将日志规范化，因为无论何种引擎，如果需要精益分析，数据准确、可靠、可追溯是必须的要求。