2016-01-27 16:14:36
来 源
ZDNet
存储资讯
Wikibon指出NetApp 7-Mode阵列用户不应升级至CDOT,而应当认真考虑如何将工作负载转移到其它供应商的系统当中。

Wikibon咨询公司日前专门对NetApp旗下的产品战略进行了分析与汇总,并指出NetApp 7-Mode阵列用户不应升级至CDOT(即集群化DataONTAP,为NetApp公司的最新FAS阵列操作系统),而应当认真考虑如何将工作负载转移到其它供应商的系统当中。

CDOT能够将多台FAS阵列以集群方式对接在一起,从而在处理更多任务的同时作为一套向外扩展系统实现运作。不过此次由初始型号升级至7-Mode的过程非常复杂,而且截至目前,只有17%的NetApp用户选择进行这项升级。

Wikibon社区CTO David Flyer还撰写了专项文章以探讨甲骨文环境下NetApp ONTAP的迁移成本:

从ONTAP 7-Mode向集群化ONTAP的迁移工作会带来一系列隐藏成本,买家应当认真进行事前评估,而后再敲定采购决策。

下面是他的具体思路:

  • 对于大部分着眼于五十个月周期的、由ONTAP 7-Mode向集群化ONTAP的迁移项目而言,其盈亏平衡表现都相当差劲--其带来的内部收益率(简称IRR)仅为12%甚至更低。
  • • 如此可怜的回报率低于典型的技术投资回报水平,从历史角度讲这意味着其存在风险且需要拥有更高回报率才能获得CFO们的支持。
  • • 7-Mode运行状态良好的NetApp客户们应当考虑向集群化ONTAP转移的具体条件,并专注于通过转移建立真正的私有云与公有云体系,

同时:

  • 如果工作负载对于延迟水平较为敏感,那么客户应当深入了解NetApp的发展规划,掌握其如何将SolidFire纳入自家产品组合,并在确保一切符合需要后着手迁移至集群化ONTAP。
  • 对传输带宽有所要求的工作负载需要考虑使用性能更为出色的NAS设备以承载甲骨文工作负载,潜在选项包括甲骨文推出的ZFS设备。
  • 对于强调存储容量的工作负载,客户应当审查全部可用选项以降低风险并提高投资回报率。

Wikibon方面表示,真正私有云(简称TPC)是一套完整的体系,其能够以一站式方式解决采购、支持、维护以及升级任务。这套系统能够将硬件、操作系统、编排/自动化管理软件等各类元素加以整合,并将其以虚拟机系统的方式进行交付。

一部分系统还将包含数据库层、中间件层以及应用程序层。

在我们看来,这相当于包含(或者基于)所谓超融合型或者融合型系统堆栈,而EMC的VCE、Nutanix以及其它众多厂商一直秉持着这样的宣传方针。不过NetApp公司可能会坚持称,其与思科方面协力开发的FlexPod项目符合Wikibon提出的真正私有云概念。

Wikibon则认为,此类系统将随着其今年年内对真正私有云概念的调整而迎来演进。此类私有云方案将把绝大多数维护工作由IT部门手中转移到供应商或者系统集成商处。这些私有云体系可立足于内部、采取异地协同或者由云服务供应商负责交付。

详细说明

Wikibon方面坚持认为,客户应该尽快加入其TPC项目,并给出了以下分析结论:

  • 集群化ONTAP并不适合承载延迟敏感型工作负载,这是因为 FAS元数据架构并不具备(例如)40 GB RDMA InfiniBand高速节点互连机制,因此根本无法作为真正的集群化向外扩展架构使用。
  • NetApp收购SolidFire公司的举措明显是为了实现向外扩展能力,而非取代NetApp旗下的现有FlashRay项目; 不过从"向外扩展"类别角度出发,其不同节点间的连接能力仅为1 GbitE:
  • 对于甲骨文数据库这类延迟敏感型环境而言,管理员可以将甲骨文"工程技术系统"配置为真正私有云,而且有可能拥有远低于NetApp方案的使用成本。
  • 对于高度混合型延迟敏感环境,最理想的战略选项可能是采用临时性全闪存向外扩展解决方案,例如Kaminario公司的K2、戴尔/EMC的XtremIO、甲骨文公司的FS(预计将在2016年年内实现向外扩展能力)或者NetApp的SolidFire。
  • NetApp 7-Mode用户不应采取迁移至ONTAP系统的方式处理标准SAN工作负载,而应专注于将这些工作负载迁移至真正私有云当中。
  • NetApp公司的WAFL架构并不能很好地适应高写入强度与高传输带宽需求类工作负载。
  • 其它后备产品--例如甲骨文ZFS设备--能够提供出色的解决效果,同时拥有明显更低的使用成本。

Wikibon的研究结果显示,ZFS设备拥有适应自家数据库方案需求的高带宽与高强度写入操作实现能力,专门面向甲骨文数据库备份、ETL(即提取、转移与加载)以及批量处理环境。

对于7-Mode用户来说,还有更多较集群化ONTAP更为理想的方案可作为标准文件存储机制,具体包括戴尔的向外扩展解决方案、Isilon(来自EMC)以及甲骨文的ZFS,而且其作为临时性平台往往拥有更为低廉的使用成本。

WORN(即一次写入、永不读取--或者几乎永不读取)存储并不适合通过CDOT实现,相反我们应当使用由Amazon、微软Azure以及甲骨文等厂商提供的云服务,或者磁带乃至IBM通过收购Cleversafe以及惠普企业业务公司携手Scality推出的颁式对象存储方案,这些选项都能够以极低成本水平提供满足合规性要求的使用效果。

根据Wikibon方面的说法,其"分析结论也验证了为何只有很少一部分NetApp客户群体(约为17%)选择迁移至集群化ONTAP。"

五种NetApp选项

Wikibon方面同时指出,NetApp公司的传统业务正在受到服务器SAN、真正私有云以及公有云经济体系的沉重打击与破坏。

NetApp公司目前拥有以下几种选择:对日益下降的营收水平进行管理,着眼于从EMC、HDS、惠普以及其它存储供应商/厂商分支部门手中夺取市场份额,将自身业务与其中一方(通过收购或者兼并的方式)整合为单一系统厂商,利用自家软件方案转型为OEM供应商,或者像EMC那样接受整体收购。

根据Wikibon给出的分析结论,NetApp产品战略的核心正受到持续冲击,他们同时也对NetApp公司的长期未来战略适用性表示怀疑。当然,我们也将对此拭目以待。

建立于2007年的Wikibon是一个着眼于技术咨询,旨在分享免费咨询知识的专业社区。

顺带一提,我们已经与NetApp公司进行联系,希望了解其如何看待Flyer给出的观点--收到回应之后,我们将第一时间向大家汇报。

声明: 此文观点不代表本站立场;转载须要保留原文链接;版权疑问请联系我们。