私有存储云如何构建?

构建内部的云存储必须考虑到弹性、选择正确的平台、支持工作流，以及批量部署和跟公有云的集成。

随着时间的推移，存储即服务的交付进展惊人。如今，公有云，如Amazon Web Services和Microsoft Azure，都提供了内部以及外部连接的按需分配的对象存储，以及块和文件存储，用于内部分配给计算实例。这种运维的灵活性在数据中心里很引人注意，比起传统的存储部署方式，它提供了更大的便捷性和敏捷性。

如何构建自己的私有存储云呢?我们首先退后一步，思考一下云计算到底意味着什么。云标准定义包括如下特性：弹性，所消耗资源能够自如扩展和收缩;作为服务交付，以抽象的形式(而不是在物理硬件上)定义的服务方案的标准集合;多租户，支持多个客户;请求资源的按需访问，很少或者无需任何手动干预;以及报告和计费，基于使用量收费，并提供详细的报告。

私有存储云必须具备这些特性。业务用户，这里也就是客户，必须具备请求存储能力，而不用关心这样的能力到底是如何交付的。因此服务目录，这项技术已经使用很多年了，之前关注于物理技术(比如HDD速度或者HDD/闪存)，需要更新，从而更加关注于服务矩阵。这意味着使用这些术语：I/O密度(每兆字节存储的IOPS)、延迟、吞吐量、数据可用性和弹性。

多租户指的是安全和性能的隔离。安全确保数据在私有存储云的用户之间不可见，而性能特性，如服务质量(QoS)确保无论系统整体负载如何，每个用户都能享受始终如一的服务级别。安全访问保证客户对资源的请求尽量不需要IT——特别是存储管理员，的干预。报告特性需要提供存储使用率的更细粒度的度量，包括能够生成某个团队或者业务领域的报告。

创建弹性

私有存储云需要做的事情列表里的第一条就是弹性，这里有两个场景：首先，客户能够按需扩展以及收缩使用量，其次，系统管理员能够按需部署更多的基础架构。但是如果终端用户能够轻易地归还存储的话，部署的一些硬件可能就不会被使用到，不过这种情况很少发生。

这里的挑战是通过在数据中心里部署新硬件来持续满足需求，并且同时在不影响应用程序可用性的情况下管理技术的更新周期。对于大多数IT部门来说，达到新硬件正好及时的部署，这不仅是门艺术也是门科学——Amaon和Microsoft可能不一样——大部分公司现金流和人力都有限。他们必须妥协，因为无法提供无限的资源，只能预测什么时候需要添加新硬件。

这也正是体现艺术的地方。预测的需求要求业务线的参与，来计划可能的未来项目及其存储需求。如果IT能够洞察未来可能的存储资源需求，那么这些需求就能够很容易地计划出来——特别是如果是非核心产品的话，如对象或者高性能存储。

科学性在于查清存储增长的足够信息。很多IT环境使用瘦预配，这意味着物理存储能力会随时间而增长，因为数据被写入到分配的空间里。并且因为计划消耗的存储的预留空间很少会被快速地全部使用掉(如，1TB的请求可能在第一天仅仅使用了50GB，之后可供三年使用)，文件系统和对象存储的使用率就会随着应用写入更多数据而自然增长。这也使得必须有精确并且详尽的工具来度量随时间的存储消耗，最好是每天，同时能够使用这样的数据生成有意义的增长预测。

另外，决定什么时候部署新硬件要求理解并且管理供应商、硬件部署和配置事件。在企业里，IT仍然需要负责这些事情，当然如果你购买了公有云存储的话，这些都在云服务供应商(CSP)的服务范围内。

选择平台

有正确的存储平台是高效部署新硬件的关键。横向扩展作为纵向扩展技术的一个选择，可以让新的部署相对简单，因为你只需要简单地往已有配置上添加硬件来增加能力即可。

大多数现代的对象和块扩展产品都能够执行一定级别的重新平衡、重新分发数据，从而使用新增加的资源并且从硬件上获得最佳的性能。单体增强的架构很难管理，因为可扩展性的限制，而旧的遗留存储系统可能本身并没有负载均衡，从而无法使用新硬件。这意味着必须要更加小心地对遗留架构进行负载均衡规划，将逻辑资源分发到物理硬件之上。很多这些平台都提供了工具，可以在存储平台内移动LUN，减轻一些负载均衡问题。

为私有存储云选择存储平台时，多租户和QoS也是要考虑的核心特性。调研CSP提供的服务矩阵，可以看到性能用IOPS和吞吐量衡量，也有一些提到了I/O延迟。无论CSP是不是满负载，这些都是必须提供给客户的服务级别，这对于传统的遗留存储就无法保障了。因此QoS就变得特别重要，要么提供工具确保终端用户得到所需的性能，要么限制仅仅在新系统上才提供所购买的服务级别。

必需的API

最近几年里，存储应用领域发生了一些管理上的改革。以前通过GUI和命令行接口(CLI)的交互来管理存储，使用“提交”阶段来实施变更。CLI让存储管理员能够进行脚本化预配以及关闭流程，允许一定程度的自动化。但是，创建脚本是一项费时的工作。这些年里，供应商改为使用API实现存储的可编程化——通过授权API调用设置配置。配置数据现在也能够轻松地提取出来，一些存储平台可以生成很详细的度量。

API

应用程序编程接口已经改变了企业存储的管理方式。将来，API将会驱动自动化，并且移除大多数存储预配的手动干预，从而让私有云存储更为实用，推广到更多企业中。

API还能够带来自动化，让“人”不需要参与预配存储流程。现在，可以通过一次或两次API调用就可以将存储映射到主机上。一些平台原生实现了API，而另一些围绕已有的API工具构建了API封装器。这里的重要需求是确保API，CLI和GUI的操作更加和谐，而不用切换来切换去。

工作流问题

难题的最后一部分是，交付私有云存储就是执行一些工作流流程。用户请求必须被验证然后执行。公有云通过用户提供信用卡或者其他支付方式来实现验证流程。这之后，可以通过web门户或者API配置服务。在企业里，请求存储的传统流程需要有内部的流程，通过手工管理请求，基于服务ticket将存储预配到主机上。ticket的负责人负责确保是否允许业务线“购买”存储，并且随后负责所有实现。

即用即付

可以使用信用卡购买公有云资源，滞后付款。工作流的改动意味着很多企业需要在部署内部云存储时实现支付和退款。

在私有云里，目标是让流程尽可能地自动化。EMC的ViPR是这样的工具，让用户围绕存储自动化来构建工作流流程。Hitachi Data Systems提供了Hitachi Automation Director围绕存储以及其他资源的预配构建工作流。

很多企业将需要考虑私有存储云所需的支付上的变化。如果没有实现支付和退款，那么什么也干不了，因为IT部门还需要继续负责服务交付的费用——很可能继续根据项目来收费。但是，如果必须购买新资源，那么财务实践上就需要一些变更——可能包括IT直接支付硬件、可能需要允许基于服务的账单，让业务单元负责这里的开销。

Stack部署

跳出存储团队的视角，看向更为广泛的领域，你可以在私有云框架，比如Openstack上构建存储自动化，来节约预配的工作量。最初的Openstack部署没有持久化存储的能力，因此建立了一些项目来管理和外部存储队列的集成。最终Cinder项目处理块存储并且自动将LUN映射到OpenStack实例上，而Manila提供了和文件系统数据的集成，Swift提供对象存储的API。

更广泛的Stack

云存储，可以是内部的或者公开的，是更广泛的基础架构stack的一部分。这意味着和OpenStack或者vCloud Director这样的平台集成。

同时，存储供应商能够编写插件，让OpenStack框架能够按需预配并且映射存储LUN。很多硬件和软件公司已经支持了所有OpenStack的存储API。Cinder支持OpenStack平台的每个版本所支持的供应商特性。

公有云集成

向前看，这个世界并不是只有公开和私有，还有两者的混合。因此，存在在公有和私有基础架构之间移动数据和应用程序的需求，后者提供额外的数据保护(备份)并且提升可用性。你还可以为使用公有云存储负责突发的工作负载和归档。

在本地以及公有云地址之间移动应用和数据的产品已经出现在市场上了。对象存储供应商，比如Cloudian(HyperStore)以及Hitachi Data Systems (Hitachi Content Platform)提供了将本地数据归档到云上的能力，并且能够搜索所有内容，就像存储在同一个地方一样。

数据保护方面，Druva和Zerto都提供了产品，让用户可以在公有云上备份以及恢复本地的虚拟机(VM)。作为备份和迁移流程的一部分，软件负责处理VM镜像的转换，以及额外驱动的注入。

虚拟化

在运行服务器虚拟化的平台上，存储通常会映射到物理主机上。大部分创建虚拟机实例存储的工作都由hypervisor管理软件来处理。VMware通过vRealize Automation 和 vCloud Director提供自动化，而Microsoft提供了System Center 2016。

Velostrata更进一步，允许在公有云上启动VM来处理云爆发。这可以用来在高资源配置的VM上运行应用，随后在本地可用，或者将工作负载移动到公有云上来应对突增的需求。一旦峰值过去，VM就可以归还回去。

同时，虚拟化供应商也开始和云供应商合作，完成应用到公有云的迁移。比如，VMware最近发布了Amazon Web Services上的VMware Cloud，以及和IBM的合作伙伴关系。它还提出了跨云架构，作为管理多云部署的方式。Microsoft Azure Stack(撰写此文时出了技术预览版)在Azure云上提供了相同的功能，可以运行在私有数据中心上，链接到公有Azure上。

很明显，如今本地和公有云的实现是不同的，主要差异在自动化程度，是否完全利用私有云存储。工作流，是其中最为重要的部分，——可能——仍然尚未成熟，需要今后私有云上的更多工作。

这里难题的一部分是改变内部业务团队的行为。这是公有云帮忙推进的领域，并且也应该采纳为内部资源的交付模型。