sddc-storage-logo随着vSphere 6.5的发布,我注意到人们对采用虚拟卷有了新的兴趣。与客户讨论的主要话题之一是VASA Provider,以及存储供应商将其作为Virtual Volumes实现的一部分提供的方式。好吧,我认为’现在是时候让我对这个话题以及最近与客户和合作伙伴讨论的话题进行一些探讨。

万一阅读本文的任何人都不是Virtual Volumes的新手,让我简要介绍一下VASA Provider是什么,以及它对于使用Virtual Volumes的重要性,只是为了设置讨论的上下文。

VASA Provider是Virtual Volumes体系结构框架的关键软件组件。在VMware开发虚拟卷框架时,VASA Provider由存储供应商设计和实施,以支持其存储解决方案。 VASA Provider负责其中一些最关键的功能。 vp-2框架,包括vSphere与存储阵列之间的一些通信方面。下面,我列出了VASA Provider负责的一些基本功能:

  • 提供存储意识服务
  • ESXi和vCenter Server的集中式连接
  • 负责创建虚拟卷(VVol)
  • 提供对用于ESXi的VASA API的支持
  • 负责定义绑定操作
  • 将与VM相关的操作直接卸载到阵列

如您所见,这些也是虚拟卷最关键的功能。实际上,’可以说VASA Provider是框架的大脑,没有它,虚拟卷将无法按预期工作。这很重要。繁荣!

 绑定 这使我指出了VASA Provider适当设计,可用性和实施​​的重要性。重要的是要注意,VASA Provider的开发以及所有供应商’特定的特性完全取决于存储供应商。他们将基于VMware提供和开发的标准来实现这一目标。

当客户考虑采用虚拟卷时,他们有兴趣在做出采用虚拟卷的实际决定以及要选择的特定供应商之前,了解VASA Provider实施的详细信息及其特性。

知道以两种方式之一支持VASA Provider的实现:

  • 设计并内置到存储阵列管理服务或控制器固件中
  • 以带外虚拟设备的形式设计和构建

对于虚拟卷(VVol 1.0)的初始版本,大多数存储设计合作伙伴都选择了虚拟设备模型来实施VASA Provider。注意事项
采用虚拟设备实施方法的原因可能是工程资源以及修改其当前存储体系结构和概念,实施虚拟卷框架引入的新存储体系结构,概念和技术所需的时间和精力。这是采用最初的VASA Provider实施方法的原因之一,但还有其他一些我不能随意讨论。

Regardless of what those facts were, this was 一些早期的设计合作伙伴和完善的存储供应商所采取的方向 in the industry that represented the largest storage footprint in the data center. ( 日立 , NetApp , 戴尔电脑 , 电磁兼容 (现在是DellEMC)。

On the other hand, the new and up and coming storage vendors, 拥有更现代,更适应的架构, such as  SolidFire , 灵活的存储 , NexGen存储 等等不一定与其他大型存储厂商一样面临挑战和约束。这使他们能够采用和实施Virtual Volumes框架引入其产品的新存储体系结构,概念和技术。一些供应商能够将其VASA Provider实施为管理服务的一部分,并嵌入到存储控制器中。

随着时间的流逝,我一直密切关注这些类型的讨论,并且我注意到客户和供应商都将控制器嵌入式实现作为首选方法。这些假设的结果是,控制器集成的实现已成为VASA Provider的首选方法。

我可以理解,当重点放在运营效率上时,客户和供应商可能是如何最初得出这个结论的。但是,出于相同的原因,我可以提出相同的论点,并将其放置在虚拟设备实现中。

我经常看到存储供应商之间进行了这些类型的比较。实际上,事实并非如此,这是我提出的一些理由。

警告:请记住,我要强调的观点和观点并不以任何方式,形式或形式被视为竞争性比较。

我的观察旨在引入不同的观点,以便在评估两种类型的VASA Provider实施的优缺点时,您可能会获得更多的见解。

我的讨论重点是运营效率,基础架构可管理性和降低风险的考虑因素。它们不基于任何特定供应商的存储功能,功能和其他与数据服务相关的技术。

VASA Provider:控制器嵌入式与虚拟设备

以下是我的观察所基于的一些企业基础结构特征。

  • 可管理性
  • 可用性
  • 失败的
  • 风险性
  • 成本

除非您打算购买新硬件,否则将VASA Provider嵌入到存储控制器中的要求不应成为决定因素。据我所知,存储供应商没有为客户提供购买较新的存储控制器的选项,其中可能包括VASA虚拟卷提供者,并允许他们换出较旧的存储控制器。

从可管理性的角度来看,我可以看到将VASA Provider嵌入在由众多存储解决方案组成的大型企业基础架构中的存储控制器中的价值。在这些类型的环境中,由于增强的可管理性,可用性和易于操作的基础架构,这立即变得有吸引力。

不必担心虚拟设备的管理,不必处理其潜在的故障和可用性问题,可以减少潜在的重大存储域(虚拟卷)故障的风险。

考虑以下:

如果您首选的存储供应商没有’是否为其虚拟卷解决方案提供了控制器嵌入式VASA Provider?

您是否会完全注销该供应商的解决方案为您的基础架构和业务带来的所有收益(成本,功能,运营等)?都是因为您可能导致您相信VASA Provider的替代实施不是最佳选择?

您是否愿意并能够从较新的存储供应商那里购买全新的存储解决方案来克服限制问题?但是,该解决方案是否满足围绕成本,技术和功能要求的其余基础架构和业务要求?可能会或可能不会。

例如,新供应商可以采用独特的方法来克服任何潜在的限制和对嵌入式VASA Provider的担忧。这些供应商之一是 SolidFire 。他们引入了独特的分布式架构 sf-vp-imp 作为其VASA Provider设计和实施的一部分,作为其存储平台服务的一部分。但是,他们的解决方案是否可以满足您基础架构所需的其他基础架构成本,技术和功能要求?可能会或可能不会。

现在,从操作效率和风险评估的角度来看,当存储解决方案具有控制器嵌入式VASA Provider时,请考虑以下事项:

通常,企业基础结构由大量存储阵列组成,其中包括模型,供应商等,当需要或需要固件升级时会发生什么?

需要升级多少个存储框架?升级的潜在风险是什么?可访问性和可用性在这里受到质疑。从运营效率的角度来看,这对基础架构的可管理性有什么影响?

所有这些都是因为由于各种原因,虚拟设备VASA Provider模型被认为不是最佳选择,其中之一是无法提供与存储控制器提供的级别相当的可用性。

在观察这些情况时,我倾向于采取务实的方法,以便我可以全面了解正在发生的事情和即将发生的事情。它’可以很肯定地说,如果您要购买可能提供或不提供该选项的新存储阵列,则只能选择将VASA Provider嵌入到存储控制器中。顺便说一句,可能要考虑一下。

就像控制器嵌入式VASA Provider一样,虚拟设备VASA Provider也有其优点和缺点,需要以与我上面为控制器嵌入式VASA Provider呈现的方式相似的方式来考虑和评估其优点和缺点。

从降低风险和操作的角度来看,Virtual Appliance VASA Provider提供了一些非常重要的宝贵功能。这里有些例子:

在由大量存储解决方案和阵列组成的企业基础架构中,执行升级对于任何存储基础架构而言都是冒险和艰巨的任务。
这是第一名,因为执行基于阵列的固件和控制器升级非常敏感。

第二,必须考虑所需升级的频率。对于控制器嵌入式VASA Provider,从该角度考虑这些事实。在使用虚拟设备VASA Provider的地方,可以以更高效的方式(升级一台或几台设备)来实现这一目标,而降低关闭存储系统的风险则要低得多。

嵌入式控制器

从可用性的角度来看,问题可能归结为您的基础架构的可用性,但是除此之外,为什么有人会认为Virtual Appliance VASA Provider不如Controller Embedded VASA Provider?它们是相同的,并且基于相同的框架。如果您假设虚拟设备VASA Provider是存储域的单点故障,或者如果虚拟设备发生故障,它可能使您面临有限的功能中断,那么这里有一些事实。

VASA Provider框架旨在提供其高可用性服务,它基于主动/被动或主动/主动两种功能行为。您可以部署多个虚拟设备以实现高可用性。它们是需要最少管理的低维护设备。

 副总裁

你不’不必依靠vSphere为虚拟设备提供可用性,但这是运行虚拟设备VASA Provider的附加价值。
给您的存储供应商带来的一个问题应该是他们的VASA Provider实现是否使用VASA Provider框架内的高可用性功能。–因为由他们决定是否使用它。

这是另一个要问的问题–从虚拟设备故障到存储控制器故障,您可以恢复多少速度?

希望人们现在可以清楚地量化和评估虚拟设备VASA Provider的优缺点以及可能的误导,这可能会由于VASA Provider的实施细节而阻止任何人选择特定供应商的Virtual Volumes解决方案。

了解我’我没有选择一种实现而不是另一种实现,而只是提出了一些其他要考虑的事实。该框架提供了企业在需要时对采用虚拟卷充满信心的工具和功能。 VASA Provider的实施细节不应阻止任何人为您的企业采用虚拟卷。

现在,我觉得我们可以摆脱VASA Provider提供商的关注,而专注于重要的事情。向您可能正在考虑为虚拟卷提供解决方案的供应商咨询以下内容:

  • 可扩展性–每个阵列或框架支持的虚拟卷总数
  • 储存容器–支持多少
  • 协议端点–支持多少个,每个存储容器支持多少个。
  • 太空回收–他们是否利用了空间回收API
  • 基于存储策略的管理–解决方案是否与SPBM集成在一起
  • 基于阵列的复制–支持吗?这是vSphere 6.5和Virtual Volumes 2.0的新功能部分

上面列出的任何项目的错误答案都应该并且可能会阻碍基于基础结构和业务需求采用虚拟卷。这些限制是特定于供应商的,而不是与VMware软件有关的限制。

我希望这会有所帮助。如果听起来太复杂,我强烈建议您查看我一直以来最喜欢的Virtual SAN(vSAN)。

最后那行是给你的 基思·诺比 。我认识你’我会感激的。在野外好友Boom上见!!!来点儿!!!
-请享用

有关Virtual SAN(VSAN),vSphere虚拟卷(VVol)和其他存储和可用性技术以及vSphere Integrated OpenStack的 (VIO)和云原生应用程序(CNA)的将来更新,请确保在Twitter上关注我:@冲云。

X