虚拟SAN对驱动器槽的利用使其看起来是个可行的存储选项,但它带来了额外的流量负担,可能产生消极影响。
在产品常常吹嘘过头的存储市场中,虚拟SAN最该挨鞭子。基于超融合系统的理念,虚拟SAN被吹捧成一种解决所有SAN与存储设备痛点的方式。当然,我们还是得檫亮眼睛,探究其所宣称的是否属实,虚拟SAN价值主张能否在数据中心占有一席之地。
围绕着虚拟SAN的最初讨论基于对虚拟集群中的每台服务器上的驱动器槽的使用。为每台服务器添加10TB逻辑驱动,你就能获得PT级的驱动容量,无需购买存储设备。
表面上,这样做很理智,但细节经不起推敲。数据必须与集群中所有其他服务器共享。这意味着每台服务器必须支持的额外LAN存储流量是原始I/O负载的两倍。额外的负载是个问题,尤其是在网络本来就很紧张的虚拟环境中。
让我们调查一下以前使用驱动器槽的基本前提。为实现成本最小化,我们看到云供应商喜欢使用极简硬件,而且目前市面上售卖的大多数服务器只包括了最小数量的驱动器槽。某种意义上,这表示即使虚拟SAN避免了购买存储单元的成本,那再去购买驱动槽设备的成本也不低啊。
将虚拟SAN软件与传统存储方式进行对比也有问题,由于我们迁移到小型模块化存储设备,而不是大型阵列。这些阵列为存储量身定制,一般包含12个驱动、一个存储界面交换机与一个头处理器。使用虚拟SAN的额外服务器成本可能超过等同效果设备的成本,尤其是买的是廉价或初创厂商的设备是更是如此,相当划不来。
用户在快速进化的存储市场更应该谨慎。随着25GbE的袭来,LAN速度增加了2.5倍,同时远程直接内存访问的延迟降低70%,显著减少服务器存储操作的开销。但这就够了么?
虚拟SAN可以列出一些技术参数。首先,到服务器的存储I/O是不对称的。读写速率通常是8:1,这意味着在一个完全双网的以太网环境中,出站流量使用带宽,否则就浪费了。
另一个争论是实例需要一个本地永久存储设备来运营。因此,本地实例存储通过云厂商提供。为什么不将这种存储作为虚拟SAN使用呢?这又让我们回到了带宽争论这个话题。如果虚拟环境的目标是在出现故障时使用自动化的恢复路径,从而提供编排的话,在对本地磁盘上复制数据需要在另一台服务器上进行,以便消除单点故障。
这种复制抵消了在虚拟SAN争论中本地实例存储的价值。
统一管理是针对虚拟SAN的又一争论。事实是多数存储管理关乎设置LUN,并发现坏掉的驱动,在处理虚拟SAN时也是如此。有个通用平台是能让存储与服务器管理团队融合在一起,但在由诸如iSCSI与对象存储等以太网协议掌控的世界中,两个团队的独立更具有政治与行政意义。
当然,底线是别将虚拟SAN看作是与传统存储一样好的选项,必须搞清楚它的价值主张,符合平台与方法论的发展。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
翻译
相关推荐
-
《IT新架构》:紧跟时代
本期主要关注超大规模提供商用来实现服务器利用率提升的云技术和实践最终将流向企业IT商店,这有助于弥补企业数据中心在服务器利用率方面的差距。
-
架构师和研发经理那个对公司更重要一些?
公司最近赶上裁员,技术团队里就研发经理和架构师工资高,老板的意思是肯定要裁一个,那应该留那个?
-
做CTO最重要的技能是什么?是写代码吗?
不写代码能做好CTO吗?
-
System Center 2016来袭 是时候和你挚爱的功能说再见了
我们见证了微软从系统中心虚拟机管理器(SCVMM)2012 R2起舍弃了P2V功能,但在即将推出的System Center 2016中丢掉App Controller并没有明显的征兆,但微软正在这么做。