“云”上存储初显规模 如何架构是关键
那么我们又当如何去构建私有化的存储云呢?首先让我们后退一步，回顾云计算的本质所在。云计算的标准定义中囊括了以下特点：弹性增长且减少资源消耗;作为一项服务进行交付，并且服务应当由抽象的术语，而非实际的物理硬件来定义;多租户性质，支持多客户端并发;对资源请求按需分配，无须人工干预;提供报告和计费功能，可以统计一段时间内资源使用的详细报告。
私有云同样能够具备相同的功能。企业内的业务单位，换句话说私有云中的客户，亦应当能够直接请求使用资源而不用去想这些资源的交付形式。传统里存在许多年的服务目录需要有所改变，从专注于物理技术(例如磁盘速度或磁盘/闪存类型)转向注重服务参数，也就是说使用像I/O密度(单位TB存储的IOPS)、延迟、吞吐量、数据可用性与弹性这些术语。
多租户更偏向于安全性与性能之间的隔离。安全性需要能确保私有存储云中各用户的数据彼此间不可见，而诸如服务质量(QoS)等性能特性则使得不管当前系统的负载如何，每位用户都能得到预期的服务水平等级。按需访问让用户的资源请求不需要IT人员，尤其是存储管理员过多的干预。报告功能应当可以更精细地处理、衡量存储利用率，包括统计各团队与业务部门分别使用多少容量。
实现弹性
弹性是我们在私有云中要实现的首个目标，它有两层含义：其一是用户需求的扩展和按需计算的能力;其二是让系统管理员有能力随着需求扩展，部署更多的基础架构资源。虽然有些人认为只要最终用户随时释放出空余的存储空间，新部署的硬件不怎么会被用到，但这种情况事实上很少发生。
这其中的难点在于如何将新的硬件资源部署到数据中心内，并在技术更新交替的周期内加以适合的管理，以避免其影响应用程序的可用性。对大多数IT部门而言，实现硬件的即时部署颇具科学性，甚至说是艺术性——他们很难像Amazon和Microsoft那样拥有大量的资金与人力。必须精准预测在何时需要进行硬件采购，才能实现无限的资源扩展。
需求预测需要与业务部门相吻合，从而规划出未来可能出现的项目，预估存储需求——这便是其中艺术性之所在。如果IT部门能够深入了解未来可能的存储资源需求，在规划时便能更加游刃有余，尤其是对于对象存储或高性能存储这类非核心产品。
其科学性源自在存储的增长过程中需要收集、整理到足够的信息。自动精简配置已经应用在许多IT环境中，这意味着随着数据的不断写入，物理存储容量会相对的得到增长，并且因为规划的存储消耗很少会被立刻消耗殆尽(例如1TB的数据请求可能在最开始只占用50GB，并在未来三年内稳定增长)，文件系统与对象存储的存储利用率会随着应用程序不断的数据写入而得到提升。这便需要有精准而细致的工具来衡量并优化每天的存储消耗，同时使用这些信息，做出更有意义的存储增长预测。
此外，确定何时应当部署新的硬件需要能清楚认识并管理好供应商的交货期、硬件部署和配置的时间。如果在企业内部，那么IT部门自然需要考虑这些问题，而假如你选择购买公有云存储时，就可以将这些难题丢给云服务供应商(CSP)了。
平台的选择
拥有适合的存储平台是高效部署新硬件的关键所在。横向扩展相对于纵向扩展技术使得新的资源相对简易部署，你只需要向现有的配置添加硬件资源以扩充容量。
当前大多数横向扩展的对象和数据块会在一定程度上自动执行性能与数据块的重新平衡，从而利用新的容量，并最大化发挥性能。考虑到纵向扩展体系架构中可扩展性的限制，烟囱式架构往往难以管理，因此在陈旧的传统存储系统上也不太可能通过负载均衡来利用新的物理容量。换句话说，传统架构必须要有更仔细的设计，以便在物理硬件层面实现逻辑资源的均衡分布。通常这些平台都会配备用于各存储平台内迁移LUN的工具，从而在一定程度上减缓均衡性方面的问题。
多租户与QoS正在成为选择私有存储云的存储平台时的关键考量功能。如果仔细查看云服务供应商提供的服务指标，我们会注意到性能指标是依据IOPS和吞吐量衡量的，有些还会提及到I/O延迟。不论云服务供应商是否处于满负荷运作，其提供的服务级别都应遵照这些指标，这与传统存储不同。因此QoS可以说是一项非常重要的指标，无论视其为一种保障最终用户得到其期待性能的工具，或是作为一种限制。
应用程序接口(API)方面的要求
近年来，存储设备管理领域有所细微的演变。传统方式中，你会使用GUI和一些命令行界面(CLI)来手动管理存储，点击“提交”来进行变更。CLI使得存储管理员能够对配置和启停过程进行脚本化，从而在一定程度上实现了自动化。不过创建脚本确实是一项耗时的过程。多年以来，供应商一直致力于实现存储可编程API，通过授权的API调用来设定配置。配置数据也更容易提取，一些存储平台还能生成十分详尽的参数。
API同时还实现了更高程度的自动化，使得管理员从存储配置流程中脱离开。现在存储可以直接通过1个或2个API调用映射到主机。一些平台在内部实现了API，另一些则根据现有的API工具构建相应的封装。这其中的关键在于确保API、CLI与GUI协同运作，而不能互为干扰。
至关重要的工作流
私有云存储交付中的最后一项难题在于工作流程的具体执行。用户请求必须经过验证、部署，并最终完成服务。公有云可以通过用户的信用卡或其它计费手段完成验证环节。然后通过Web门户或API配置服务。在企业内部，传统请求存储资源往往依靠手动管理的内部流程，根据服务申请中的详细信息为主机配置存储。申请的审批者有责任确保该业务部门被允许“订购”相应的存储资源，并需要负责履行服务。
私有云的目的是使得这个流程尽可能自动化。譬如EMC的VIPR等工具可以帮助你构建存储自动化的工作流程。Hitachi数据系统公司提供的HitachiAutomationDirector亦能够搭建存储与其它资源配置的工作流程。
许多组织正在考虑在私有存储云内引入计费机制。如果不考虑结算或退款，那么问题会简单很多，因为IT部门将继续承担提供服务的相应成本——并可以根据项目分摊费用。但假如要对新的资源申请进行收费，那么便不可避免要在财务方面有所改变，例如IT部门直接支付硬件费用，然后通过向服务部门收取服务费来弥补。
堆栈式部署
比单纯的存储更进一步，你可以在私有云的框架中实现存储自动化，例如OpenStack，从而大幅减少配置工作。最初的OpenStack部署没有永久性的存储功能，因此出现了一些实例化项目用以管理集成外部存储阵列。最终的Cinder项目能够处理数据块存储，并自动将LUN映射到OpenStack实例，而Manila则提供了文件系统数据的集成，并由Swift为对象存储提供API。
同时，存储供应商可以编写插件，使得OpenStack框架根据按需配置并映射存储LUN。许多软硬件公司都已经支持所有的OpenStack存储API。Cinder支持列表上详细列出了OpenStack平台每个版本中支持的供应商功能。
集成公有云
展望未来，世界并不只是由公有或私有化技术组成，还有许多两者的混合体。因此势必会有在私有和公有基础架构之间迁移数据和应用的需要，并由后者提供额外的数据保护(备份)并增加可用性。你还可以通过公有云存储来进行突发的负载峰值以及归档操作。
你已经可以在市场上找到用于在内部和公有云之间迁移应用和数据的产品。诸如Cloudian(HyperStore)和HitachiDataSystem(HitachiContentPlatform)等对象存储供应商提供了将内部数据归档到云端的能力，同时最大程度支持跨平台的检索，就如同在单一视图中操作一样。
在数据保护方面，Druva和Zerto都有产品让你从公有云中备份和恢复本地虚拟机(VM)。VM镜像的转化与驱动程序都可交由软件处理，作为迁移备份过程中的一部分。
Velostrata则进一步允许在公有云中启动虚拟机。这项功能可以让虚拟机应用拥有比本地更大的资源，或在应用负载增长时将其迁移到公有云端。一旦负载峰值过去，便可将虚拟机迁移回本地。
同时，虚拟化技术供应商也开始与云服务供应商合作，以便将应用程序迁移到公有云。例如VMware最近在AmazonWebServices上宣布了VMwareCloud，并与IBM建立了合作伙伴关系。VMware还引入了跨云平台的体系架构，可以管理多个云端部署的环境。MicrosoftAzureStack(在本篇的写作过程中)令Azure的功能可以运行在私有化的数据中心内，并与公共的Azure端链接。
今天，在私有云与公有云端的部署截然不同，这主要反映在自动化程度方面，以充分利用私有云存储。作为最关键的一部分，工作流程或许还不成熟，需要在私有云端进一步加以完善。
另有一部分的挑战在于改变内部业务团队的工作模式。借助公有云的带动，内部资源的交付模式亦应当做出改变。
APIs
应用程序的编程接口改变了企业存储的管理方式。将来APPI将推动自动化并在存储配置中减少绝大多数的人工干预，使得私有云存储对更广泛的企业更加实用。
更广泛的堆栈
云存储，无论是内部还是公共的，构成了更广泛的基础架构的组成部分。这意味着与OpenStack或vCloudDirector之类的平台整合。
按量支付
你会使用信用卡或后付费方式来购买公有云资源。在工作流中这种变化意味着许多企业组织将在部署内部云存储时考虑实施计费结算机制。
