金融时报昨天,我的老板以及VMware存储和可用性业务部门的CTO 克里斯托斯·卡拉马诺利斯(Christos Karamanolis)》发表了一篇文章,其中概述了Virtual SAN作为存储平台的未来。这篇文章是出色的写作,也是出色的阅读。这篇文章很棒,是我想回应的文章,以便更多的人有机会阅读。

请在下面查看并阅读Christos的文章。如果你’重新参加了VMworld Christos,我正在就该主题进行会议,我不得不说,现在这是您不参加的会议’t want to miss.

STO6050 – 虚拟SAN:未来的软件定义平台

未来的软件定义存储平台

下周,在2015年美国VMworld上,我们将发布Virtual SAN 6.1,这是VMware用于VM的第三代Hypervisor聚合存储。在此版本中,我们引入了几个主要的增强功能和新功能,包括对最新一代存储设备的支持,新的可用性和灾难恢复功能以及高级管理和可维护性工具。

这些功能建立在经过验证的同类最佳性能,可伸缩性和可靠性功能的基础之上,可为所有虚拟化工作负载(包括Tier-1生产,关键任务应用程序和要求高可用性的用例)提供企业级存储。

虚拟SAN整体

有关最新Virtual SAN功能的更多信息,请关注下周在VMworld上发布的公告。

在本文中,我想退后一步,回顾一下我们今天对产品的立场以及对未来的展望。注意:本文中的前瞻性陈述并不反映已承诺的VMware产品或功能。

正如我们过去多次讨论过的那样,Virtual SAN产品的主要目标(今天已交付)是为典型的虚拟化环境提供经济高效的企业级存储解决方案。 (到目前为止,该产品取得了巨大成功,有2000多个客户进行了生产部署,证明了该产品的优势。)那些``典型''环境的外观如何?它们是围绕传统的“整体”应用程序设计的。

这些是单二进制应用程序,旨在执行某些任务,并且在利用库和OS功能进行数据访问和联网方面是独立的。它们通常设计为在独立服务器平台上运行,并且除Microsoft和Oracle等一些集群应用程序外,它们并非设计为分布式容错软件服务。

借助vSphere功能,VMware在很大程度上取得了极大的成功。 vMotion, DRS, , 金融时报 和各种 数据保护 解决方案,用于满足具有传统应用程序的IT组织的业务连续性需求,而这些应用程序本来就不具有此类功能。

所有这些vSphere功能都是围绕以下概念设计的: 手动地 托管的计算资源池 vSphere群集。共享存储后端是启用这些功能和管理工作流程的先决条件。这正是VSAN使用超融合架构所做的工作-它聚合了群集中所有主机的本地存储设备,并使它们显示为共享数据存储,可供群集中的所有主机访问。

虚拟SAN:存储基础架构管理(今天)

鉴于当今VSAN的主要用例,我们为当前产品制定了一些包装决定。首先,我们决定使VSAN群集与vSphere群集相同。这不是固有的技术属性,但是使管理和与vSphere的集成更加容易。

  • 用户不必配置和管理存储集群与计算集群,然后处理主机访问哪种VSAN数据存储的所有复杂性。毕竟,这正是我们要使用VSAN解决的SAN管理的复杂性,例如分区和防护!
  • 它促进了与关键管理工作流程(如升级,维护模式,HA,紧急情况的超额配置等)的无缝集成。即使是自动声明磁盘等基本任务,其语义也更加简单。
  • 所有现有的vSphere API和管理工作流程都可以正常运行!我们只是扩展现有的API或添加一些新的API以用于存储。
  • 计算和存储群集成员身份的一致性简化了对基础架构的监视和故障排除。它有助于重用现有机制,例如vCenter警报和任务。

虚拟SAN:存储消耗模型(今天)

当前,虚拟机使用存储的主要方式是虚拟SCSI(VSCSI)磁盘。这是确保任何旧版应用程序可以在任何存储后端上运行而没有兼容性问题的技巧。

实际上,VMware和所有其他虚拟化供应商都拥有IP,可以在其虚拟机管理程序中有效地模拟SCSI控制器和设备。同样,VSAN产品已打包为支持VM和VSCSI磁盘。但是有一个非常重要的新变化: 基于策略的细粒度存储供应和管理(SPBM).

SPBM

在VSAN中,每个VM甚至每个单独的VMDK(VSCSI磁盘)都配备有自己的个性化QoS属性。用户以策略的形式指定所需的内容,然后VSAN自动决定如何在群集中分配每个VMDK以及分配哪些资源以满足用户的需求:容量,用于缓存和性能的闪存空间,副本数可用性,条纹数等

这种方法有很多好处,我们过去已经广泛讨论过。我要在这里重点说明的是VSAN如何实施这种细粒度的配置方法。与VMFS和业界其他类似产品不同,VSAN是 集群文件系统。它是基于对象的存储系统。

VM由许多对象组成。可以将对象视为数据+元数据的独立单元,例如,其中可能包含文件系统的一部分或全部,VSCSI磁盘的内容等。从这个意义上讲,VSAN大致类似于 RADOS,Ceph对象后端.

好,为什么这很重要?因为VSAN是通用的基于对象的存储平台。它并非专门为VSCSI磁盘和当今的虚拟化用例而构建。相反,用于VSCSI磁盘和VM元数据(VMFS文件系统)的ESXi软件模块位于通用VSAN界面的顶部。值得注意的是,这个对象接口和控制平面是我们打开并变成VASA的东西 虚拟卷 规范。

虚拟SAN应用程式

所有这些都是设计使然。该计划是使用VSAN来为将来的更多用例提供服务。这是事情变得非常有趣的地方。

虚拟SAN:未来之路

IT世界正处于由软件驱动的过渡之中。我们正在见证应用程序的开发,部署和管理方式的巨大变化。

CNA

 

首先,我们正在从拥有大量小型应用程序的模型转向具有跨越100或1000个节点甚至有时甚至是地理位置的云规模应用程序的用例。新一代应用程式(也称为Cloud-Native 应用领域或3rd-Platform 应用领域)是由许多细微服务实例构成的。

它们不是整体的。分发,扩展和资源控制以微服务的粒度完成。容错性和可用性通常由应用程序本身实现。

围绕vSphere群集构建的资源池和DRS / 哈服务的类型不适用于这些应用程序。实际上,vSphere群集不再与管理抽象相关。我们正在谈论一种完全不同的管理模型,其中物理基础结构可以由应用程序本身查看和管理,这种方法非常适合与新一代软件一起提供的DevOps模型。

未来

这些新的用例从根本上需要新的数据抽象和存储管理模型。

当我考虑这些挑战时,它可以帮助我从两个维度组织问题空间:存储基础架构管理和数据消耗模型。

让我们依次看一下这些领域的需求。

  • 大规模存储基础架构管理

处理由数以万计的服务器和成千上万的存储设备组成的存储基础架构已不再是科幻小说。我们如何以可扩展但有效的方式管理如此庞大的基础架构?

以下是大规模管理的关键原则:

  • 可以鸟瞰基础架构的配置和运行状况的工具。允许快速有效地“放大”任何问题区域和问题。
  • 使用大数据分析(是的,与那些基础结构上运行的某些应用程序使用的工具相同)向用户提供答案,而不仅仅是大量数据。
  • 支持双接口:
    • 玻璃UI和可视化工具的单窗格。协助IT人员进行物理基础结构故障排除和修复。
    • 用于与自动化代码和应用程​​序逻辑(devOps模型)集成的编程接口(API)。

现有基础架构管理服务的体系结构,无论是VMware vCenter Server还是Microsoft System Center Virtual Machine Manager,都需要进行彻底的重新思考。为了让您了解我的意思,请考虑以下简单算法:

我认为我们中的任何一个都愿意献出10个 每个主机上的一个核心用于运行数据分析以进行基础结构运行状况监视,自动故障排除,趋势分析等。支付自动化服务的收益是非常合理的“税”。

现在考虑另一种选择,即在某个中央数据库上收集所有数据(就像上面提到的管理服务一样),然后在该数据库之外的某个服务器上运行分析。对于拥有2,000台主机的“适度”基础架构,将需要200个CPU内核!对于集中式管理服务这是一个荒谬的要求。

分布式,可扩展的管理体系结构是未来的方式。 Cloud-Native应用程序的基本原理在这里起作用。

在VMware,我们正忙于设计遵循这些原则的新一代存储管理服务和工具。您将在下周在VMworld上宣布的新VSAN管理工具中首次看到其中一些想法。

  • 新的存储消耗模型

多年来,当我们在VM中运行旧版应用程序时,虚拟SCSI仿真一直为我们服务良好。但是,对于容器,无论它们是在VM中运行还是在本机中运行,都可以利用OS映像,该映像专门针对其应用程序需求而设计。

像Docker,VMware或CoreOS这样的供应商可以在OS映像中使用他们想要的任何驱动程序-轻量级块驱动程序或文件系统驱动程序/客户端。开发人员使用对他们的应用程序更有意义的抽象,并将它们与应用程序打包在一起在容器中。无需向后兼容和旧版支持。

正是在这种情况下,VSAN的通用性非常方便。 虚拟SAN已扩展为通过VSCSI磁盘以外的抽象服务器数据的平台。它可以为传统VM或在vSphere上运行的Containerized应用程序提供支持(在VMworld上可以找到有关此主题的更多激动人心的声明)。

虚拟SAN可以通过REST API为轻量级块驱动程序(可能使用NVMe协议),本机文件甚至对象提供服务。具有单一管理经验和一套工具的单一平台都支持不同的抽象和协议。 融合存储平台.

vsan融合

文件对于容器映像管理特别重要。主要要求是可伸缩,快速创建和部署几乎相同的映像。缺乏具有强大克隆功能的开源文件系统,导致社区使用具有性能和可管理性限制的解决方案,例如“联合”和“重叠”文件系统。

文件系统共享被限制在单个主机内。容器的部署涉及将单个映像副本运送到每个主机,这是一个效率低下且耗时的过程。

那么,设计成可扩展到数千个主机的基础架构的分布式文件系统呢?一个文件系统,可以提供在O(1)时创建的几乎无限数量的克隆(按文件或卷的粒度),并且每个主机上的任何容器和任何VM均可对其进行访问。

如果您认为实在太好了,那么您应该参加分组讨论会 STO6050 – 虚拟SAN:未来的软件定义平台 在VMworld。或访问 CTO Lounge的VMware Office 了解有关如何利用VSAN的对象体系结构及其基础结构管理服务来设计这种文件系统的更多信息。

期待与您在VMworld见!

- 请享用

有关将来创建的最大软件定义存储平台上的更新,该软件定义了Virtual SAN(VSAN),vSphere虚拟卷(VVol)和其他软件定义的存储技术以及vSphere + OpenStack的,请确保在Twitter上关注我:@PunchingClouds

X