超融合方案分析系列(3)深信服超融合方案分析

前言

作者是国内研究超融合相当早的专家,有非常强的理论基础和实战经验,以下是超融合分析系列前面几篇,已经阅读过的同学可以跳过。

超融合分析系列:

超融合概述

超融合产品分析系列(1):nutanix方案

超融合方案分析系列(2):VSAN的超融合方案分析

非常深入的超融合分析系列,希望大家会喜欢,另外文章最后附有作者的微信,有兴趣的同学可以加作者做更深入的交流。下面是本系列第4篇正文:

整体方案

深信服的超融合一体机以及超融合方案目前在各个地方都推的比较猛,从官网看,他们的客户也有不少了。今天我们一起来分析一下深信服超融合方案:

深信服超融合的整个方案中包含了aSV、aNET、aSAN三个核心组成部分。当然,既然是超融合方案,虚拟化是基础,而分布式存储则是超融合的核心。所以今天我们以aSAN以及超融合一体机来分析超融合方案:aSAN 是深信服在充分掌握了用户对虚拟化环境存储方面的需求基础上,推出以aSAN 分布式存储软件为核心的解决方案, aSAN 是基于分布式文件系统Glusterfs,进行深度的优化改进,开发的面对存储虚拟化的一套软件定义存储解决方案, 并作为超融合架构中的重要组成部分,为云计算环境而设计,融合了分布式缓存、SSD 读写缓存加速、多副本机制保障、故障自动重构机制等诸多存储技术,能够满足关键业务的存储需求,保证客户业务高效稳定可靠的运行。

上面这段话是我从深信服超融合技术白皮书中摘录的。从这段话,我们不难得出,aSAN是基于开源的GlusterFS优化的。最近大名鼎鼎的开源软件服务供应商Redhat也推出了自己的超融合基础架构RHHI,恰好RHHI的方案几乎完全和深信服一致:虚拟化采用KVM,分布式存储选择了Gluster,没有选择同属于Redhat旗下的分布式存储软件Ceph。这让国内一批选择了KVM+Ceph的超融合厂家情何以堪啊。这里我们不展开讨论Gluster和Ceph的两个分布式存储的优劣。还是继续回到前面的话题,深信服超融合方案的分析讨论。

深度分析

先介绍一下几个特别的地方:

1

第一个是支持2个节点起步:

这个比较好理解,GlusterFS是支持2节点HA部署的。

2

第二个是热备盘方案:

针对热备盘的技术解释,我们直接参考下面的技术白皮书原文:

如果在磁盘故障后,超过了设置的超时时间依然没有人工介入处理,aSAN 将会自动进行数据重建,以保证数据副本数完备,确保数据可靠性。同时采用了热备盘的保障机制。aSAN 在初始化阶段会自动配置至少把集群里副本数个磁盘作为热备盘。

在aSAN 自动使用热备盘替换故障磁盘后,UI 上依然会显示原来的故障磁盘损坏,可以进行更换磁盘。这时新替换的硬盘会作为新热备盘使用,不需要执行数据回迁。这一点与前文没有热备盘会做数据回迁是不一样的。

从上面可以理解:超融合方案中至少要按副本数配置热备盘,而当热备盘替换故障盘后。使用热备盘,实际上是传统存储的一个可靠性技术,缺点明显:单独的热备盘在做数据回迁时,存在数据写入的瓶颈。相比其它超融合方案,数据在一个Group内部的数据盘或者整个资源池数据盘上完全打散,在单盘故障时,不会存在单盘写入的瓶颈(从多个盘读,往一个盘上写)。如果数据盘比较大,比如现在3.5寸SATA盘主流已经是8TB,10TB已经有规模商用时,继续采用热备单盘技术,就很容易导致可靠性问题:一个大盘故障,无法在短时间内完成数据的重建,这个时候,再故障一个盘或者节点,整个集群业务就会有风险,尤其是在电子产品生命周期末期,可靠性问题将被放大。

3

第三个是网络需求:

在深信服官网http://wiki.sangfor.com.cn/index.php/超融合:最佳实践,我找到了对网络的一个要求:

我们继续分析一下上述要求:

  1. 生产环境推荐要8个网口以上,相比其它超融合方案,深信服的网络需求过多。
  2. 除了常见的业务、管理、存储网络外,还多了一个集群管理网络。这点是其它厂家方案中暂时没有发现的。网络管理显得复杂。
  3. 集群管理口采用的单网口,而且不做聚合。在方案上至少是一个明显的单点故障点。最新材料好像也支持双网口做集群管理口。
  4. 所有双端口网络,要求交换机必须堆叠,这在银行保险等对网络要求主备完全隔离的金融客户将非常有挑战。

4

第四点:扩容要求

深信服的超融合在扩容时,每次添加的主机数,要与虚拟存储副本数一致,或者是它的倍数。

如2副本环境,一次扩容扩2台、4台主机。(避免扩容单台主机时需要大量的旧数据搬迁)。这点也和其它超融合不同。其它大部分超融合在没有特殊的限制,不过本身也支持单节点扩容,只是扩容时会迁移数据,也谈不上约束,本身就是最佳实践。

5

第五点:谈谈系统盘。

从百度上找到的《深信服超融合方案产品概要》文档,可以看到深信服超融合一体机的配置中,对系统盘描述就是一个128G的系统盘。参考我前面分析nutanix的方案,单个系统盘,对可靠性是有很严重的影响。从《sangfor_asv_深信服超融合服务器硬件选型指导书》我找到了描述,该128G系统盘采用是主板板载SSD SATADOM 盘,这个方案不仅可靠性有风险,也明显降低可维护性。

6

第六点:谈谈SSD缓存盘的选型:

从《sangfor_asv_深信服超融合服务器硬件选型指导书》我找到了一个典型方案的描述:

在另外一个深信服的官网PPT中,也看到类似的宣传,采用的是S3510系列磁盘做cache。

大家注意,我这里仅仅是对SSD的选型有自己的担忧:在cache和主

存比例不到5%的情况下,采用Intel S3510系列磁盘做cache,我个人觉得等同于自杀。为什么,我们一起看看S3510系列的说明:Intel官网明确分类,S35系列属于读取密集型磁盘。

S3510 240G容量的寿命是140 TBW, 480G的寿命也只有275 TBW我们来做一个数学题,140*1024/240=597,SSD内部是按page组织,往往修改一个page的部分数据,需要整个page做一次完成一次擦写,相关的材料网上非常多,我这就赘述。通过上面的数据题的答案,我们知道如果按每天写一次全量(240GB),那么只能有597天的寿命,不到2年。如果按三倍容量写入,寿命不到100天。当然不同的业务模型,有不同的寿命。能大胆采用S35系列做cache,我暂时还没有发现第二家。大名鼎鼎的VSAN明确写明240G/480G的S3520系列只能做全闪存的容量盘,寿命比S3510系列更好。

总结展望

这次深信服的方案聊的有点多。

最后结尾谈点感想:深信服作为安全领域的国产大厂,顺应IT时代发展,切入超融合领域,超融合方案中最大的亮点是支持虚拟化防火墙、应用防火墙WAF等,而这么简单的虚拟化功能,还不需要复杂的SDN方案来支撑。而且完整的超融合方案在推出的短短2年多时间已经取得了不小的成绩,给nutanix、华为等超融合大玩家有力的冲击。因深信服本身缺少服务器硬件平台,所以超融合方案的另外一个亮点是支持其它厂家的服务器,尤其是利旧服务器,这点对客户来说有一定的吸引力。硬币有正反两面,深信服尽可能的放大了自己的集成优势、安全领域的优势,通过异构等尽量规避了硬件平台少的劣势。希望深信服能走的更远。

以上分析,完全来自官网材料,如果有错误,请大家指正,谢谢。

原文发布于微信公众号 - 大数据和云计算技术(jiezhu2007)

原文发表时间:2017-07-25

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏美团技术团队

云端的SRE发展与实践

背景 SRE(Site Reliability Engineering)是Google于2003年提出的概念,将软件研发引入运维工作。现在渐渐已经成为各大互联网...

3209
来自专栏互联网高可用架构

统一支付系统“Fastpay快付”集结号Fastpay

2453
来自专栏IT大咖说

所见即所得-基于Node.js的页面数据实践

摘要 数据抓取是企业信息化的根基和第一步,只有利用先进的技术作好了信息抓取工作,才能为信息化带来最大的价值。懂球帝高级开发工程师邓佳龙用五个字就概括了数据抓取的...

32611
来自专栏情情说

1718总结与计划

2018年已经悄然到来,回望过去一年,收获很多,感恩很多。未来一年,内心充满了期待,无论是工作还是生活,将会发生很大变化。大年初一的晚上,将自己的所思所想记录下...

3197
来自专栏北京马哥教育

如何接手一个新业务的运维工作

如何接手一个新业务的运维工作?有些东西我们还是要把话说在前面,以免前期不明确造成后期工作的混乱。

1130
来自专栏DevOps时代的专栏

流水线2.0驱动 CD / DevOps

前言 张乐:大家知道 DevOps 这两年提的特别多,非常火,我们希望从社区的角度 DevOps 不仅仅是概念的纬度,更关键是一个可以落地实施的纬度。我们觉得流...

31310
来自专栏云计算D1net

管理混合云和多云:代理或无代理?

导语 混合云在节省更多IT成本方面提供更多的潜力,并将这些成本节约转向改善业务成果,但却带来了一些独特的挑战。人工手动的流程在一个混合的世界变得难以管理,因为云...

32510
来自专栏智能计算时代

[云计算架构:Dynamics ] 多租户 或多实例 ?

Dynamics 365(在线)为您提供了隔离Dynamics 365数据和用户访问权限的选项。 对于大多数公司而言,在订阅中添加和使用多个实例可提供正确的功能...

692
来自专栏SDNLAB

GitLab推动基于Kubernetes的Auto DevOps更新

GitLab发布了其同名平台的最新版本,该版本利用Kubernetes来自动化代码处理。在微软以75亿美元收购GitHub之后,在线Git存储库管理器受到了人们...

972
来自专栏智能计算时代

LF EdgeX Foundry为IoT启用边缘计算

Linux基金会推出了EdgeX Foundry,该项目旨在为物联网计算和可互操作组件生态系统建立开放框架。 EdgeX Foundry旨在促进边缘计算的模式,...

3044

扫码关注云+社区