阿里云NAS文件存储部署方案介绍和对比
NAS业务上云的背景
作为国内最大的公有云厂商,阿里云为广大的个人用户、初创团队和企业提供了多种多样的公有云服务,包括弹性计算,数据库,存储和网络等。阿里云弹性伸缩,按需付费,无限容量,便捷使用等特性吸引了大量的客户把他们的应用以及服务部署到阿里云,其中就包括一部分部署NAS应用的客户,对于这些客户,面临的一个问题就是如何以最大的性价比来将原有的NAS应用部署到云上。本文介绍了三种可能的部署方案,并比较了他们的优缺点,包括用户最关心的价格,性能以及扩展性等。
对于企业级NAS应用,大部分企业都会在IDC中部署图1(图片来源,EMC Isilon网站)所示的架构
图1 基于本地服务器的NAS业务部署架构
图1中计算节点既可以是运行一些企业应用的服务器,也可以是简单的员工工作终端(PC,MAC等),而网络设备和存储节点则分别负责网络连通和支持NAS协议的文件存储,其中NAS存储节点,企业一般会选择专业存储厂商产品,比如EMC的Isilon,NetApp的FAS系列,华为的OceanStor系列等,这些产品提供了标准的文件访问协议NFS和CIFS/SMB,以及丰富的企业级存储服务,但价格也是不菲的,对于初次部署有比较高的门槛。
公有云提供了方便,快捷,弹性伸缩的业务部署能力,利用公有云厂商提供的产品,企业可以将图1的架构方便地迁移到云上。一般来说,业务的迁移有两种方案:1是整体搬迁,包括计算节点、存储节点和网络设备都会放到公有云上;2是计算节点不变,仅仅在云上部署并使用高可靠、高可用、弹性扩展的高性能文件存储。从中可见,不管是采用哪种方案,云上的高性能NAS存储都是业务顺利迁移的保证。对于NAS存储上云,企业一般有三种不同方案来实现:
1.公有云的NAS文件存储服务,比如阿里云的文件存储。
2.在公有云上自建文件存储服务,比如利用阿里云的ECS和云盘,利用操作系统的文件共享或者基于一些开源的NAS软件。
3.使用软网关提供的文件存储服务,比如阿里云即将推出的软网关产品。
那么这三种云上的方案从架构、部署、运维、成本等方面分别都有什么特点呢?我们结合一个最简单的应用场景(服务器数据共享和日志共享)来进行一些分析,其中大部分分析同样也适用于其他一些NAS应用场景。
对于服务器数据共享和日志共享的应用,典型的部署方式就是把上文说的图1转换成公有云版本,如图2所示:
图2 服务器数据和日志共享场景
对于Web服务器,或者移动端APP的服务器,该架构中一般会部署多台ECS服务器来处理业务请求,完成用户生成数据(比如照片,音频,视频或者一些运动类APP的特定数据)写入和读取,之所以使用多台ECS服务器是出于弹性扩容和负载均衡的考虑,这也对后端存储提出了多ECS共享数据的需求。对于后端存储的选择,该场景下客户一般都会使用文件存储,这是因为客户的软件大多是基于标准的文件访问接口(比如Posix或者Windows API)开发的,对于这些标准的文件访问接口,文件存储天然就有这样的支持;而如果采用其他的存储方式,以最常见的对象存储或者块存储为例的话,就会面临一些限制,比如使用对象存储的话需要对现有软件进行改造,来适配对象存储的SDK;而使用块存储的话本质上软件看到是一块硬盘,需要借助操作系统对其进行格式化(ext3, ext4,NTFS等),相对于文件存储和对象存储,这样的使用方式缺乏多ECS共享存储的能力。
NAS业务上云的三种方案
我们接下来就要分析的就是分别用前述的三种方案来实现图2中的“NAS共享文件存储”。
方案一:利用公有云的NAS文件存储服务
这是最直观也是最简单的方案,后端存储直接使用阿里云的文件存储服务,所有的ECS实例都可以同时挂载同一个文件系统来进行数据的共享,对于数据的访问,从最简单的文件读写锁的控制,文件和目录权限的控制,到整个服务的高可用,高可靠,弹性扩展,都可以完全由阿里云文件存储NAS托管。用户只需要完成如下三个简单步骤,就能完成图2中文件存储的部署:
1.创建文件系统,不需要显式指定文件系统容量,因为容量是随着用户的真实使用情况完全弹性扩展的。
2.为文件系统添加挂载点,支持VPC方式和经典网络方式。
3.在ECS上挂载文件系统,推荐的方式是在Linux服务器上使用NFS协议挂载文件系统,而在Windows服务器上使用CIFS/SMB协议挂载。
关于这三个步骤的图文示例可以参考这两个链接,从中可以看到,仅仅需要轻点几下鼠标,图2中的NAS文件存储部署就完成了!
方案二:在公有云上自建文件存储服务
这种方案下,用户需要自己搭建NAS文件存储服务,可以仅支持NFS或者CIFS/SMB,也可以同时支持两种协议。一个典型的方式是如图3所示:
图3: 用ECS+云盘来构建NAS存储服务
这种部署方式下,用户需要配置一台额外的ECS,以及配置一块云盘,将云盘格式化并挂载在ECS上,作为文件系统的存储,同时在ECS上用户还选择依赖于操作系统的支持,或者自己部署支持NFS、CIFS/SMB的软件(一般是开源软件,也可以自己开发),把云盘上创建的文件系统通过NFS或者CIFS/SMB输出给需要访问共享文件系统的其他ECS。
使用该方式有几个明显的缺陷:
1.容量的限制,云盘的单盘容量最大是32T,万一达到了这个限制,需要部署更多的云盘,然后使用类似LVM的方式管理多块盘,这需要用户对使用容量有一个明确的预期,而这却恰恰是很难的,用户把数据放在公有云上的一个重要原因就是看中公有云的弹性扩展功能,容量应该是按使用自动扩展,而且可以认为是无限扩展,而不应该是在业务部署之初就决定的!
2.为了适配自己的业务需求,用户往往需要自己部署运维开源NAS软件,并对软件进行一些修改和调优,这些都需要很大的技术积累!
3.单点故障问题,如果ECS上的NAS软件出了问题,比如程序出错重启,那么NAS服务在这段时间是中断的,并且,在一般情况下为处于性能的考虑,NAS软件会使用write-back的cache,那么当NAS软件意外重启时还有很大的几率出现数据丢失的情况发生;如果ECS本身出了故障,同样会有数据丢失的风险;更糟糕的是,如果ECS严重故障导致掉线,那么整个存储的访问都会瘫痪,对用户来说将是一场灾难!
4.性能无法线性扩展,表现在两个方面:
a)需要提前规划作为文件服务服务器的ECS的规格,如果一开始选择规格较低的ECS,当业务量增大时,文件服务器ECS的资源(CPU,内存等)都会成为性能瓶颈;而一开始就选择合适的ECS规格有将会面临诸多挑战:1. 初期部署价格过高;2. 无法准确预知未来的业务量和对ECS性能的需求。
b)不管是ECS还是云盘,都有带宽限制;在这种部署方式下,带宽的瓶颈往往发生在提供NFS和CIFS/SMB服务的ECS上,由于ECS虚拟网卡的内网带宽一般在几十至100MBps,这也意味着当多台ECS服务器访问共享文件系统是,总带宽会受限于这个值。
5.另外,采用这种方式,企业投入的成本会比方案1高很多(详情可见后文的对比分析)
针对第3点和第4点,可以有两种解决方案:
a) 部署多套ECS+云盘,以Active/Standby的方式提供NAS存储,此时需要把Active节点上的云盘内容实时同步到Standby节点的云盘上,否则在发生切换的时候会丢数据,另外用户还需要自己管理所有软件的HA功能。这样的改进可以解决单点故障问题,但依然没法做到性能的线性扩展!
b) 部署多套ECS+云盘,使用NAS软件的集群功能来以Active/Active的方式提供NAS存储,此时为了配合NAS软件的集群功能,需要在多个ECS间部署集群文件系统(比如LusterFS,GlusterFS等),来保证多ECS上NAS软件看到的一个单一命名空间的文件系统。这种方式下,对用户的技术积累有极高的要求,并且需要用户在业务的早期就对这方面进行仔细的考虑,并把系统设计成分布式文件系统+集群NAS的方式(否则未来会面临如何将本地文件系统平滑升级到分布式文件系统的困境),而如果这样做的话,对于前期的部署投入非常大,是非常不合算的!
方案三:使用软网关提供的文件存储服务
软网关的部署方式如图4所示,
图4: 用软网关来构建NAS存储服务
该方案和方案二非常类似,主要不同之处在于:
1.用软网关产品替换ECS+NAS软件,帮用户省掉了对NAS软件运维的投入,用户仅需要购买软网关,并将其部署在ECS上即可。
2.后端存储从云盘切换到了OSS对象存储,降低了成本,并去除了存储容量不能弹性扩容限制。
可见,方案三解决了方案二中前两个痛点,但对于后面几个痛点,包括单点故障问题,横向扩展的限制等,方案三从架构上和方案二还是一样的。另外,值得一提的是,
- 对于网络带宽,因为软网关和前端ECS服务器以及后端OSS存储都是走的同一块虚拟网卡,那么在网关Cache Miss的情况下,从前端ECS访问软网关的带宽理论上也只能达到虚拟网卡带宽的一半。
- 由于软网管对于NAS数据的缓存功能(数据先存储在软网关,定时同步到后端),当发生时ECS宕机时,会有数据丢失的概率。因此虽然OSS能提供10个9的数据可靠度,但方案三的整体数据可靠性会大打折扣。
三种方案的价格和性能对比
以上讨论了三种方案功能上的差异,以下让我们从用户最关心的性价比,来对比一下这三个方案。
方案一的成本完全在于存储:
阿里云NAS提供了性能型(全SSD存储)和容量型(SSD和SATA混合存储)两种方案,取决于用户对于访问性能的要求,用户可以选择两者之一。
两种类型NAS形态的性能和价格对比如下表所示:
性能型 | 容量型 | |
最大容量 | 1PB | 10PB |
性能-最大IOPS | 10K+ | 10K+ |
访问时延 | ms级 | ms级 |
性能-最大带宽 | 0.04MB/s * 文件系统存储空间(GB) + 60MB/s | 0.02MB/s * 文件系统存储空间(GB) + 30MB/s |
价格(每GB每月) | 1.2~2元 | 0.3~0.55元 |
表1:性能型NAS和容量型NAS对比
方案二的成本由ECS和云盘两者组成:
阿里云的云盘也分为多种,容量和性能如下表所示。
块存储类型 | SSD 云盘 | 高效云盘 | 普通云盘 |
单盘最大容量 | 32768GB | 32768GB | 2000GB |
单盘最大IOPS | 20000 | 3000 | 数百 |
单盘最大吞吐量 | 256MBps | 80MBps | 20~40MBps |
性能计算公式 | IOPS=min{30*容量,20000} 吞吐量=min{50+0.5*容量,256}MBps |
IOPS=min{1000+6*容量,3000} 吞吐量=min{50+0.1*容量,80}MBps |
不适用 |
访问时延 | 0.5 – 2ms | 1 – 3ms | 5 – 10ms |
价格(每GB每月) | 1.0元 | 0.35元 | 0.3元 |
表2:不同类型云盘对比
显然普通云盘的性能不适合我们这边讨论的场景,我们只会考虑SSD云盘和高效云盘这两种情况。
另外对于ECS的选型,阿里云提供了很多种型号供选择,因为在NAS场景下文件缓存对于性能有比较大的影响,我们选择内存型ECS中中档的ecs.e3.large(4核32GB内存)来作为文件服务器。
此外,采用这种方案,用户需要自己管理NAS的运维,在比较中我们假设对运维人员的投入是每年50000元(一个普通运维工程师的收入应该远高于这个数字)。
方案三的成本由ECS、软网关以及OSS三者组成。对比中,ECS选择了和方案二中相同的ecs.e3.large(4核32GB内存)型号;由于软网关目前还没有官方报价,我们这里假设其为50000元每年; OSS是对存储量和数据请求量同时收费的,对于数据请求,我们假设经过软网关对于NAS数据读写缓存,每TB到达OSS的请求是50次每秒(对于典型的NAS应用,由于大量小文件的存在,这个IOPS的估计还是相当保守的)。
图5和图6显示了不同方案部署方式下的成本和文件系统最大访问带宽的对比。
图5 三种NAS部署方案一年总体拥有成本(TCO)对比
图6 三种NAS部署方案最大带宽对比
从图5和图6中可以看出:
1. 价格方面,
i. 方案一整体要好于方案二(性能型对比SSD云盘,容量型对比高效云盘)。
ii.和方案三相比,在容量小于10TB容量的情况下,直接使用阿里云NAS的方案,不管是性能型还是容量型,都具有明显的优势;在容量小于100TB情况下,容量型NAS依然具有优势,直到容量接近1PB的情况下,使用方案三才会与容量型NAS有差不多的价格。
2.最大访问带宽方面,由于方案二和方案三都会受限于ECS虚拟网卡的带宽(100MBps),而直接使用阿里云NAS的方案支持完全横向扩展,具有明显的优势,尤其是在容量增大的情况下。
总结
最后,让我们以对这三个方案的多维度对比来做一个总结,如表3。
阿里云 NAS | ECS + 云盘 + 开源NAS软件 | 软网关 + OSS | ||
NAS协议支持 | NFS3、NFS4
SMB2、SMB3 |
取决于开源NAS软件 | NFS和SMB
具体协议取决于网关的能力 |
|
高可用 | 完全横向扩展,多机头Active | 不支持
|
不支持 | |
高可靠 | 10个9可靠度 | 数据可靠性低
当ECS出现故障时,会有数据丢失的风险 |
数据可靠性低
当软网关出现故障时,会有数据丢失的风险 |
|
容量上限 | 10PB(容量型)
1PB(性能型) |
32TB*云盘数 | 理论上无上限 | |
支持容量横向扩展的能力 | Y | N
|
Y | |
访问延时 | 毫秒级 | 依赖于ECS性能,可以达到毫秒级 | 网关cache miss:几十毫秒级;
网关cache hit:毫秒级(部分依赖于ECS性能) |
|
访问带宽 | 最高2GBps | 受限于ECS网卡带宽100MBps | 受限于ECS网卡带宽100MBps | |
支持性能横向扩展的能力 | Y | N | N | |
用户NAS运维开销 | 无 | 高 | 无 | |
成本 | 低 | 高 | 高
在数据量达到PB级时才和容量型NAS相当 |
表3:NAS部署方案综合对比
从中可以看到,从多方面(功能,性能和价格)综合考虑,使用阿里云NAS文件存储是企业NAS业务上云的最好选择。
参考文献:
1.阿里云文件存储 https://www.aliyun.com/product/nas
2.初探阿里云存储网关 https://yq.aliyun.com/articles/72714?spm=5176.100239.0.0.wieqpt