对于今天许多的IT专家来说，“大数据”早已不仅仅只是另一个毫无实际意义的因概念炒作而兴起的时髦术语了。这是一个更接近转折点的东西，而不能被简单抹去。原因非常简单：大数据的规模正在不断越来越大。对于大量的企业组织而言，特别是那些数据密集型的行业，如零售业——他们发现，能够以具有成本效益的方式从过剩的海量数据信息中获得真正的价值，将成为决定企业组织能否在未来获得市场成功的关键因素。
庆幸的是，当前的确是有一些实用的解决方案的。一些龙头企业领军正在转向开源的、软件定义的存储作为部署网络规模的IT架构的一种明智的方式，并赋予了他们在管理各种各样的数据方面更多的灵活性，即使是进行大规模的数据管理。正如经常发生在其他新兴技术领域的一样，这一创新的方法对于存储的定义可能会有所不同。 然而，大多数专家似乎都认可，软件定义的存储环境具有硬件不可知论、分布式架构、融合存储和对于标准数据协议本地支持的特点。
那么，企业组织要从何开始呢?在本文中，我们将为广大读者诸君一步一步的提供关于采用软件定义的存储作为实际的、主动出击的管理企业数据策略的一部分的详细指南。当然，关于软件定义的存储的具体采用过程将肯定总是因企业组织的具体情况而异、因应用程序的不同而异。灵活性是这种技术的固有特性。而鉴于我们当前所面临的来自大数据的不可思议的挑战，灵活的IT架构现在比以往任何时候都更为关键，更何况我们此前并没有仔细考虑过这方面的挑战。
挑战：海量数据
对于几乎各个行业的企业的IT部门而言，前所未有的数据增长都是他们所面临的最大的挑战——而且这一难题还在进一步加剧。各种规模的企业组织机构都在争先恐后地捕获和分析来自越来越多的来源的海量信息，并尽快适应企业数据量的不断增加，而仅仅不到十年前，这些海量数据信息对于企业组织而言还显得高深莫测。鉴于上述这些情况，IT市场调研机构Gartner公司的分析师估计，在2016年，40%的企业组织机构内部部署的存储基础设施的规模都将翻番也就不足为奇了。
然而，尽管各种成本都在不断疯涨，许多企业组织的IT预算却在不断压缩，使企业内部的团队无法提供必要的创新服务，以保持市场竞争。鉴于在未来几年内，企业组织对于海量数据增长的管理将变得更加困难，一些企业组织可能会继续依赖于传统的解决方案，提供严重缩水的回报。这些企业组织将不会为长期的成功做好准备。而为了完全融入到当前这样一个数据驱动的世界，任何号称将在2020年成为行业领军的企业组织均需要考虑在一套现代化的存储基础设施方面进行重大的投资。果断的行动可能会在短期内需要企业组织付出相当大的代价。但毫无疑问的是，任何事情也不做的成本肯定会更高。。
技术解决方案：更灵活的数据中心
当技术与自身的局限性相抵触时，也许是时候建立一种更好的技术了。今天的企业组织早已不再依赖于基于一套过时的假设的、旧的、灵活性较差的解决方案了，他们现在已经有了许多的选择来部署网络规模的IT架构来桥接公共和私有云。从一个存储的角度来看，这意味着将存储硬件从对其进行管理的软件中分离出来——这种方法被称为“软件定义的存储”。目前，对于软件定义的存储的采用可能尚未普遍，但不要指望这种状况会一直持续。据Gartner公司估计，到2018年，开源存储将占企业市场份额的20%以上。
关于软件定义的存储，一个较为尴尬的情况是：关于业界关于其完整准确的定义尚未达成一致的共识。对于任何新兴的技术而言，这是完全正常的;而供应商偏倚的定义已经开始让位给一些共同性的定义特征了：
硬件不可知论。一款软件定义的存储解决方案应该能够运行在任何标准的服务器平台上，而不依赖于具体的硬件平台。这至少部分的解释了具有直接附加磁盘的x86存储服务器的出现——是云和网络规模IT发展的明显成果。
分布式体系架构。这是非常必要的，因为软件定义的存储的主要目的之一便是突破传统的按比例增加的网络附加存储(NAS)和存储区域网络(SAN)的体系结构的局限性。
支持标准的数据协议。新兴产业的共识是，任何全面的解决方案应该包括对块、文件和对象数据服务的支持。
计算与存储的融合收敛性。随着越来越多的企业组织机构迁移到采用统一计算，软件定义的存储解决方案将需要能够在存储节点上运行应用程序工作负载。
管理控制面板。与任何跨一个复杂的网络传递或转发数据信息的技术一样，一款软件定义的存储解决方案的成功将依赖于精密的控制面板来帮助精简和简化数据访问。
竞争优势：开始入门的八个步骤
企业采用软件定义的存储的过程并不是在一个预定义的过程。其灵活性是由其本质属性和经常反复实践所决定的。当您阅读以下步骤时，不妨试着把这个过程想象成一个圆形的，而不是线性的：通过从专注于一组应用程序开始，然后逐步过渡到一下的每一个步骤。一旦您完成了，您迁移可以进展到下一组应用程序重新开始该步骤：
1、找到您企业的关键压力点。您企业目前在存储上的开销是多少?您企业的容量需求和制约因素是什么?请务必要考虑成本，以及围绕着灵活性、可用性和敏捷性的需求。
2、基于这些压力点确定工作负载。是否有一些工作负载是基于非结构化的数据?如果是这样的话，软件定义的存储可能是一个很好的选择。然而，如果您企业有相对比较小的基于结构化数据的工作负载，软件定义的存储可能并不是正确的方式。
3、确定有多少应用程序都在发挥作用。如果您企业主要只使用一个单片应用程序，那么其通常不是软件定义存储的一个好的用例。 但是，如果您企业有更广泛的应用程序组合，那么软件定义的存储可能会对您企业有很大的帮助。
4、先迁移非关键工作负载或新的应用程序。为了获得对于您企业新的存储平台的经验和信心，我们建议您不妨从您企业的一些不太重要的应用程序开始，以防您企业可能在此过程中经历一些停机中断。不要担心您是否会在开始阶段遇到困难——最初的第一个迁移项目永远是最有问题的。一旦您重新定义和规范您企业的迁移策略和过程，您会发现，迁移最重要的应用程序也变得更加容易。
5、确定您企业的工作负载是否能够被虚拟化或托管到云中。您企业是打算在物理服务器上运行应用程序，还是在一个虚拟化的环境中，或在公共云中?如果您企业要使用一个以上的这些部署模式，您将需要选择一个灵活的存储平台，以支持这些模型。这样，您就不会遇到不兼容的技术在管理不同的存储方面所带来的不必要的复杂问题。
6、确定您企业需要什么样的分析。如果对于您企业而言，大数据的兴起是一个特别迫切的关注的话，您企业可能会考虑一个依赖于领先的数据分析技术的软件定义的存储解决方案，如Apache Hadoop部署实现的MapReduce。有了这样的工具，您企业将能够直接从旧的应用程序存储和共享数据，而不必在筒仓之间移动数据信息。这不仅会使您企业能够以更少的时间从巨大的数据池中提取更多有用的信息，同时也能够帮助您企业显著的节省成本，进而帮助您从您企业现有的基础设施中提取最大的价值潜力。
7、根据您企业的需求确定恰当的数据保护和复制的水平。哪些灾难恢复场景方案需要被覆盖?每一种场景情况下可能的结果是什么，包括对于成本的估计?为您企业最重要的数据达到最高水平的保护，而不必过度投资于既不敏感、也不重要的数据信息的安全性，是否是可能的?
8、确定您企业需要保存数据多长时间。企业是否需要遵循相应的任何监管要求，必须将这些数据信息保管更长的时间?如果不是，寻找如何删除不再需要的数据的方法，毕竟，如果您企业已经不需要了，为什么还要存储它呢?
“数据服务第一”的价值：管理任何规模的工作负载
软件定义的存储，即使是狭义的定义，取决于每家企业组织机构具体环境、业务需求、预算等等的不同也可以有不同的形式。但一个真正可扩展的软件定义的存储方法需要从底层的数据结构解耦数据服务，使更多的服务能够为更大范围的工作负载所使用。这些服务可能包括以下内容：
文件服务。由于其分级结构的影响，使得传统的文件系统的可扩展性有限，使得例如数据保护和容量优化等任务，更困难。
对象服务。对象存储系统已成为基于文件和基于块的系统的一种常见的替代，经常提供足够的元数据，同时简化了非结构化数据信息的索引。他们基于RESTful架构，作为抽象存储离开应用程序的功能元素提供服务。然而，基于对象的系统通常与基于文件的系统是不兼容的，要求企业进行代价昂贵的应用程序重写。
共享的文件和对象服务。这些服务使企业组织能够充分利用当前正在使用的基于文件的应用程序。同时，它们使基于对象的应用程序也能够获得这些数据信息，通常是通过一个基于REST的方法。这使得带来了标准的最大的灵活性。
块服务。块存储，经常由SAN使用，以块的形式管理和跟踪数据。OpenStack项目Cinder是当今比较常用的块存储服务。
有一套完整的、可以自由交互的数据服务，企业组织能够整合数据信息，实现他们所需要的任何规模的、更复杂工作负载管理的灵活性。
结论
在未来几年，随着越来越多的IT专家开始探讨软件定义的存储的潜力，我们对这个技术术语的理解肯定会发生变化。这就是其应该的状态。即使是在红帽公司，我们自身也仍然在不断的学习，根据我们在该领域前沿的初始部署来考虑其影响。 但这些努力到目前为止只进行到当前阶段。 技术由创新驱动，真正创新的想法通常超过了曾经被赋予的任何期望。
我们对于积极的探索新的想法非常热衷。而我们的客户似乎对此也非常热衷。那是因为我们向一个社区一样工作，而我们从经验总结中知道，对于开源的、软件定义的存储的视野绝不仅仅只是属于我们。我们碰巧只是这个研究领域的长期的信徒，不仅仅只是拥有一个锁柜的金属盒的所有权，而是拥有一个更有趣的研究种类——通过这种积极的贡献以创造一个全新的东西。
关于红帽公司
红帽公司是世界领先的开源解决方案供应商，使用一种社区驱动的方法来提供可靠和高性能的云、虚拟化、存储、Linux和中间件技术。红帽公司还提供屡获殊荣的支持，培训和咨询服务。红帽公司是标准普尔公司，拥有遍布全球的超过80处办事机构，为其授权客户提供业务服务。
本文转自d1net（转载）
