当《五十度灰》在软件定义存储的世界里上演
引言
正如同《五十度灰》里人性背后隐藏着复杂深沉的阴暗面,软件定义存储世界也有着它的“五十度灰”。
时下,尽管软件定义存储(Software-Defined Storage,SDS)还没有严格的技术定义,但俨然已成为业内“模因”一样的存在。尤其在“传教士”们盛情的渲染下,我们似乎也迷醉了双眼,看到SDS完美得闪耀圣光,而轰下神坛的“传统存储”(如SAN和NAS)看起来一无是处。
模因(meme):文化基因,与基因(gene)发音相近,指人类思想通过模仿、散播,像基因一样代代相承。
然而,“阳光越强烈,阴影就越浓郁。”正如同《五十度灰》里的男主,表面光鲜亮丽的背后,实则隐藏着五十道不为人知的阴暗面;软件定义存储在“闪耀”的背 后,其实也隐藏着它的“五十度灰”,需要我们去深入了解,仔细辨别。而对于拥有明智商业头脑的IT决策者来说,选择哪种存储架构,与其看它是否时下最热 门,不如回归传统考量标准——成本、可靠性和便捷性来得更有效。
“传教士”们究竟说了多少谎?
存储市场上,“传教士“们为SDS堆砌的华丽辞藻不绝于耳——“SDS将颠覆传统存储,开启存储进化新时代”…冷静想想,如果“存储进化”真的发生,它一定是从存储“孤岛”向存储“共享”的大方向演进。
想起了上世纪六七十年代,还是“内部存储”和“直连存储”的天下。所谓“内部存储”,即存储内置于服务器;“直连存储”则是磁盘阵列通过外部扩展的服务器主板总线连接到服务器机箱外侧。此后存储技术开始朝着两个方向发展:一是支持存储通过网络共享文件级数据,二是通过数据库和面向事务处理的系统共享块级数据。后来块级存储从“孤岛”架构演进为“共享”阵列,这意味着从前“内部存储和直连存储必须直连服务器,数据存取、共享、扩展十分困难”的日子结束了,共享阵列有很多端口,可以连接很多服务器主机。
然而当系统需要进一步扩展时,依然十分麻烦。这时工程师们想到引入一个交换机制,将存储阵列全部连接到交换机上,并使用光纤通道或iSCSI传输协议,这就是SAN架构。当初SAN架构的终极梦想是:底层存储可为上层全体应用所共享。
然而,一个开放异构的终极SAN终究没能在市场上问世。厂商为了确保存储设备的销量盈利,更愿将精力放在盘阵里专用控制器的功能扩展上,而对不同厂商品牌的 异构组件如何实施一致性管理并不上心。于是,专有控制器加上专有增值软件,通用管理策略的缺失,以及高精尖运维团队的需求,导致购买、部署、运营一套 SAN架构极为昂贵。
到了本世纪初,服务器虚拟化全面来临,上述SAN的困扰依然继续。对于提供服务器hypervisor技术的厂商来说,当更多应用负载整合到更少服务器上时,上层应用负载出现性能不足,厂商就把责任全归咎到底层存储的SAN架构上。
事实上,无论SAN或NAS本身有多少短板,服务器虚拟化负载只会让它们情况更糟。毕竟,当应用负载整合到更少服务器上之后,单个服务器发出的I/O数量将 急剧变化——每服务器平均增加7~16路I/O连接。Hypervisor执行计算任务时也会对网络、fabric互联及交换机系统的通信状态产生改变。
既然服务器虚拟化和传统存储杠上了,hypervisor厂商当然得想方设法灌输给用户“虚拟化技术的各种好”了:一来,虚拟机可在主机之间复制,形成高可用集群;再者,虚拟机还能在服务器之间迁移,实现高效负载分配和高可用性…
只是,以下事实怎么也回避不了:当单个服务器主机整合了大量虚拟机,且负载要在各物理服务器间实现自由迁移,必然给上层应用和底层存储之间的持续连接造成压 力。此外,当某个应用搬迁到新的服务器,通常需要管理员介入,为其设置新通道连接所分配的存储。而且,众多虚拟机共同向管理程序发送I/O数据流,在繁重 的工作负载下,I/O数据流可能连续产生,也可能比较随机,这会加重内存和磁盘的读写压力,增加延迟,最终导致上层应用负载性能下降…这种现象也就是业内 常说的“I/O竞争”(I/O blender effect)。
当 越来越多hypervisor用户开始抱怨“应用性能不足”,hypervisor厂商狡黠地将炮火齐刷刷对准了传统存储,还积极编排其“N宗罪”—— 成本高、扩展差、运维难…“是时候颠覆传统存储了!”于是,他们摇身变为SDS的“传教士”,热情奔向“软件定义存储”这颗存储界超级新星的怀抱。
“传教士”们诉说传统存储“N宗罪”之再审判
1. “传统SAN或NAS导致应用负载性能低下”
不好意思,他们说谎了。因为只要很简单看下存储I/O的队列深度,就能知道存储I/O路径是否导致应用延迟。很多时候,队列深度不是很重要(并没有数据在排 队等待写入磁盘)。当队列深度读操作与处理器周期相结合,CPU与内存间的通信路径很可能出现拥塞,这时,应用性能下降是由相关的应用代码或 hypervisor代码引起,而与存储一点关系也没有。
2. “专用存储导致高成本(包括OPEX 和CAPEX)”
传统存储意味着高成本,毫无疑问,过去是,现在也是。也许硬件厂商会争辩道,盘阵控制器上的增值软件及功能扩展增强了个性化竞争优势,然而现实就是赤果果,这些“增值扩展”增加的…反而是系统配置复杂度、管理难度以及高精尖运维团队的人力成本!
3. “传统存储架构缺乏灵活性”
专用存储在灵活分配和释放资源这方面的确比较苦手,但是,这对“应用性能”不会造成一丁点儿影响。
4. “DAS存储比SAN强”
这显然是假的,而且毫无意义,因为NAS和SAN本身也是广义的DAS。NAS是一种直连到精简型服务器的存储,且基于网络传输数据。而SAN是在DAS中加入物理或fabric层交换机,将服务器层和存储层既隔开又实现高速互联,给人一种网络附着的错觉。
“五十度灰”下,“你”(软件定义存储)的真实面目到底是什么?
话说回来,既然人性的阴暗面复杂深沉,定不能简单粗暴地盖棺定论,因此,“传教士”们给传统存储扣上这些“N宗罪”的帽子,究竟真相如何,我们也不必急着妄下断言。倒是他们宣扬的 “软件定义存储将掀起下一代存储革命”的观点很让人共鸣。
BTW,软件定义存储也属于DAS结构呢!存储直接从物理上连接虚拟服务器主机。它与从前的DAS唯一的区别是:存储增值功能(软件)不是安装在本地外接盘阵的控制器上,而是在服务器的软件层里;Hypervisor厂商则干脆将其封装到自家的软件堆栈中。
虽然软件定义存储还没有公认的确切定义,但它确实也算是一颗“万灵丹”——在软件定于数据中心(Software-Defined Data Center,SDDC)的世界里,因“传统存储”引起的疑难杂症,用上SDS,通常就能药到病除。虽然该“万灵丹”当前贴有各种厂牌,但本质区别就一条:“软件”定义在了哪一层?(或:存储智能化在哪一层实现?)是在本地盘阵控制器里?还是在服务器hypervisor软件堆栈里?
于是,当所有 SDS解决方案都可用以下两个标准来划分时,一切变得清晰明了起来。即:1. Hypervisor绑定与Hypervisor不感知;2. 硬件绑定与硬件不感知。
1. Hypervisor绑定与Hypervisor不感知
有 一类SDS解决方案是与hypervisor深度结合的。最典型的代表当属VMware的Virtual SAN(也称VMware vSAN),其与该公司专属hypervisor——VMware vSphere引擎紧密集成,深度融入VMware体系架构中。紧密程度稍微小一点的是微软的Clustered Storage Spaces,他们强调可与VMware共享存储。(只需将VMware工作负载转化为微软的VHD格式,再将其导入Hyper-V就行了)
与上述完全相反的另一类SDS解决方案是:很多第三方SDS软件不感知hypervisor。基于这类SDS软件搭建的基础架构通常支持异构hypervisor,有时还支持非虚拟化工作负载。
2. 硬件绑定与硬件不感知
不得不说,时下某些“软件定义”产品,尽管宣称是“软件定义”—— USE ANY HARDWARE U WANT(随心所欲使用硬件吧),但实际上对硬件组件及系统拓扑结构有着相当严格的要求。比如VMware的超融合架构EVO:RAIL,其绑定的 VMware vSAN就要求使用精致高端的硬件以及遵循严格标准的系统拓扑。
而与之相对的就是另一类对硬件不感知的SDS解决方案。既然说到超融合,就以天玑数据的超融合架构PriData私有云平台为例吧,其采用标准x86的商用硬件,通过软件来定义节点角色和管理任务,不仅对硬件无感知,而且支持异构hypervisor。
结束语
软件定义存储从诞生至今,争议伴随着发展前行。对于企业用户来说,需保持冷静睿智的商业头脑,从实际业务需求、架构部署及数据管理的策略目标、成本预算、员工技能及其它实际限制条件等出发,综合考虑,慎重挑选最适合自身的存储方案。
当《五十度灰》在软件定义存储的世界里上演相关推荐
- SPDK,软件定义存储的催化剂
去年第四季度开始,XSKY团队[3]开始研究英特尔向社区开源的SPDK.福叔在学习之中发现,就像软件定义网络(SDN)和网络功能虚拟化(NFV)中的性能利器DPDK,SPDK也极有机会给SDS领域带来 ...
- 从传统运维到云运维演进历程之软件定义存储(一)
运维是企业业务系统从规划.设计.实施.交付到运维的最后一个步骤,也是重要的步骤.运维从横向.纵向分可以分为多个维度和层次,本文试图抛开这纷繁复杂的概念,讲述一个传统的企业级运维人员转型到云运维人员,尤 ...
- 惠普发布软件定义存储 助力提升虚拟化能力
10月15日,惠普宣布向包括戴尔.IBM.联想以及全新的惠普ProLiant Gen9服务器在内的,所有采用英特尔®至强®处理器E5 v3的服务器免费提供1TB的惠普StoreVirtual虚拟存储设 ...
- 图解软件定义存储-百炼钢成绕指柔
新浪微博:@frankfan7 邮件:frank@GetToCloud.com 实现软件定义的数据中心,软件定义的运算.网络还有存储,一个都不能少.继图解网络虚拟化之后本文揭开软件定义存储这位神秘女郎 ...
- Windows Server 2016软件定义存储:Storage Spaces Direct介绍
微软在Windows Server 2016 Technical Preview 2中引入了Storage Spaces Direct.这个特性将本地存储扩展为高可用(HA)存储系统. 举个例子,St ...
- 用Windows Server实现软件定义存储之存储空间直连
曾几何时软件定义的概念一时无两,超融合架构.无共享存储(Share Nothing Storage)的概念也是层出不穷:梦想总是要照进现实才有实际参考意义,这里拨开纷繁的软件定义存储选项,为大家揭示在 ...
- 软件定义存储的定制化怎么走?
当前,软件定义存储成为业内超高速增长的典型.有研究人员称,从2014年到2019年,软件定义存储市场将从14亿美元增长到62亿美元以上,年复合增长率将达35%.软件定义存储所带来的优势显而易见,但是对 ...
- 软件定义存储的系统架构图和关键技术
软件定义存储系统架构图 在存储业界,不同存储厂商问的存储设备和解决方案长期存在技术壁垒.多数现有的存储系统是单一的,集成的系统,只支持特定的硬件和软件组合,使独立的存储系统缺乏灵活性,无法充分利用不断 ...
- 软件定义存储相比传统存储系统的优势
软件定义存储的优势 软件定义存储可将用户存储服务集成到服务器软件层中,使存储功能从传统存储控制装置中的脱离,进一步拓宽存储功能应用范围. 软件定义存储可将软件功能与阵列控制装置分离,增设管理数据中心存 ...
最新文章
- pthread中如何追踪stack over flow
- oracle的cv函数,cv_wait 和 cv_timedwait 函数
- Centos7下使用yum安装lnmp zabbix3.2
- 5g通用模组是什么_中国联通发布《5G通用模组白皮书V2.0》
- 【多线程】LockSupport 使用 原理 源码 分析
- [BZOJ] 1614: [Usaco2007 Jan]Telephone Lines架设电话线
- 一行代码如何隐藏 Linux 进程?
- MongoDB的正确使用姿势
- 分布式存储系统学习笔记(二)—分布式文件系统(4)—内容分发网络(CDN)
- Atitit 乱码的检测与纠正总结 目录 1. Atitit.request 乱码的检测与解决 attilax总结	1 1.1. 乱码的检测,,可以检测,列徐俩个问好??	1 1.2. 使用常用汉字
- Queue与生产者消费者模型
- 汤国安《地理信息系统教程》(第二版)笔记(1)——概论
- 自适应滤波器 | 时域ALE算法
- xmapp环境搭建注意事项
- 晚上几点睡才叫“熬夜”?给你“答案”,很多人都想错了
- Texstudio + sumatraPDF 正反向搜索关联设置
- sdn网络搭建以及负载均衡
- 首师大附中OJ系统 0019 求圆台的体积
- spring boot前端
- 艾默生流量计测量密度时要注意什么
热门文章
- 【7046】赛马、生态组织与个人英雄
- Day15(Js入门、jquery入门、ajax入门、前后端分离开发跨域问题、linux环境准备、jdk_tomcat环境搭建、docker介绍及应用(docker安装、基本命令、安装tomcat))
- 手动编写SpringIOC框架
- 让你的iriver更动听
- 基于时间序列的异常检测算法小结
- 阿里软件测试工程师手把手教学—如何快速定位bug 编写测试用例?
- HTML5实现学生档案
- 爱思助手短信备份到安卓_爱思助手备份/恢复功能介绍
- word2007的问题,页码怎么从任意页开始到任意页结束、断码问题
- 用JS脚本实现批量插入MongoDB数据