vSAN架构细节(2)

上一期是： 《vSAN架构细节-分布式RAID》

---Begin---

vSAN数据存储是一种对象存储系统，其上的虚拟机是由大量不同的存储对象组成的，而不像过去的虚拟机是保存在LUN或卷上的一组文件的集合。这对于vSphere管理员来说是一个新的概念，理解这一点很重要。

　　到目前为止我们还未曾提过对象和组件。所以，在深入不同对象的各种细节之前，让我们先从vSAN中对象和组件的定义及概念讲起。

对象指的是一个位于vSAN数据存储中的独立的存储块设备，与SCSI语义兼容。它可以根据需要来创建，并且大小没有限制，不过在vSAN最初发行的版本5.5中VMDK的大小上限是2TB减512字节。从vSAN 6.0发布起，VMDK现在最大可达62TB，和VMFS和NFS数据存储一致。

对象现在取代了LUN成为了vSAN的主要存储单元。在vSAN中最典型的存储块设备就是独立的VMDK、虚拟机主页名字空间和虚拟机交换文件。当然，如果虚拟机拍过快照，则还会创建一个增量盘对象。如果快照包含有虚拟机的内存，这也会被实例化成一个对象。因此取决于快照的类型，一个快照可能包含有1个或2个对象。

vSAN中的每个“对象”都有其自己的RAID树，将策略要求映射成为物理设备上实际的布局。 如果你在部署虚拟机的时候选择了某一个虚拟机存储策略，那么策略中关于可用性和性能的这些要求就会被应用到虚拟机对象上。

组件是对象的RAID树上的叶子——这意味着，一“片”组件是存放在一个特定的“缓存设备+容量设备”的组合（一个物理磁盘组）上的。组件通过缓存设备（闪存）获得了透明[1]的缓冲/缓存能力，其数据则静静地躺在容量设备(在全闪存vSAN配置中是闪存而在混合vSAN配置中是磁盘)上。

　　在vSAN数据存储上，虚拟机可以具有5种不同类型的对象。注意，每台虚拟机都可以由这些对象中的部分组合而成，这些对象如下：

1. 虚拟机主页（VM Home）或“名字空间目录” （namespacedirectory）

2. 交换文件对象（如果虚拟机处于开启状态）

3. 虚拟磁盘/VMDK

4. 为快照创建的增量盘（每个对象）

5. 为快照创建的快照内存（每个对象）

　　

  在这5种对象中，虚拟机名字空间需要进一步解释一下。所有的虚拟机文件，包括VMDK、增量（快照）、内存快照和交换文件都存放在vSAN上一块叫做虚拟机名字空间的地方。在虚拟机主页名字空间中最典型的文件有.vmx虚拟机描述文件、.log日志文件、.vmdk磁盘描述文件、快照增量盘描述文件以及所有其他可能在虚拟机主页目录中找到的文件。

vSAN上的每个存储对象都可以被看成一棵RAID树，每片树叶就是一个组件。例如，如果一个VMDK的条带宽带是2，且无需容忍任何故障（不要管为什么），那么这个VMDK上就会配置一个RAID-0条带并横跨2块磁盘。这个VMDK是一个对象，组成它的每一片条带就是这个对象的一个组件。

　　类似的，如果定义了这块VMDK在群集中应该至少容忍一个故障（主机、磁盘或网络），且保持其他所有策略设置为默认值，就要对这个VMDK对象创建一个RAID-1镜像——在群集内的一台主机上有一个副本组件，同时在另一台主机上有另一个副本组件。最后，如果策略要求同时包含条带和可用性，那么条带组件将会在主机之间被镜像，最终形成了RAID0+1配置。单个对象最终会由4个组件构成，每个副本中有2个条带组件。

　　注意，增量盘是在对虚拟机拍摄快照的时候创建出来的，它会继承其母盘的策略（条带宽度、副本数等等）。

　　交换文件对象仅在虚拟机开机的时候创建。

　　另有一个组件叫做见证（witness），它非常重要，也很特殊。尽管它不直接给虚拟机提供存储空间，但是不可否认的是，当群集中的虚拟机存储对象出现故障的时候，作为必要的仲裁对象，它是非常关键的。稍后我们还会讨论见证组件，现在让我们先关注虚拟机存储对象。

5.2.1组件的限制

　　关于vSAN中的组件有一个主要的限制。因为这是一个硬性限制并且最终会影响单台主机和群集上可以运行的虚拟机数量，理解这些限制是非常重要的。vSAN 5.5的限制如下：

• 每台主机的最大组件数：3000

在vSAN 6.0中因为一种新的磁盘格式(on-diskformat)的引入，这个每台主机的最大组件数的上限增加了。

• 每台主机的最大组件数：9000

　　每台主机的组件包括了处于关闭状态虚拟机、未注册的虚拟机和模板的组件。vSAN将这些组件分派到群集中的各台主机上，并试图保持一种均衡的分布。然而，某些主机拥有的组件仍然有可能比其他一些主机更多。所以这就是为什么VMware推荐的最佳实践是使得一个vSAN群集的所有主机尽可能地保持类似（甚至是完全一致）的配置。在设计和部署一个vSAN群集的时候，组件的数量限制是设计和部署vSAN群集时重要的决策因素，这将会在第9章中进一步深入探讨。

　　管理员使用vSphere Web客户端可以查看虚拟机主页名字空间和虚拟机的VMDK等对象及其组件的布局，图5-3提供了一个此类布局的示例。这台虚拟机有一块硬盘，这块硬盘在2台不同的主机上拥有镜像，你可以在Host这一列看见这些组件的位置。

[x1] 

图5-3　物理磁盘布局

5.2.2 虚拟机存储对象

　　如前所述，5种存储对象是：虚拟机主页名字空间、虚拟机交换文件、VMDK、增量盘和快照内存（如图5-4所示）。我们将先暂时忽略快照内存而更多地讨论一下其他组件。

图5-4　虚拟机存储对象

　　现在我们将讨论虚拟机存储策略中定义的特性将如何影响这些存储对象。注意，并非所有的虚拟机存储对象都会实施这些策略。

5.2.3 名字空间

　　虚拟机使用名字空间(namespace)对象来作为它的虚拟机主页(VM Home)，并用它来存储没有专属对象其他所有虚拟机文件，如以下这些内容（但不限于此）：

1.  .vmx、.vmdk（描述文件部分）、VMX使用的.log日志文件

2. 用于VMware HorizonView的CBRC[2]的摘要文件。这个功能是View的存储加速器，虚拟桌面基础机构(VDI)是vSAN的一个重要用例。

3. vSphere Replication和Site RecoveryManager的文件

4. 客户机自定义文件

5. 由其他软件解决方案产生的文件

　　

  这些对象是独特的，每台虚拟机各有一个。vSAN使用VMFS作为文件系统来存放虚拟机的所有文件，包括名字空间中的这些文件。名字空间VMFS是一个功能完整的常规的VMFS，也就是说它具备所有群集功能及所有VMFS支持的功能（例如vMotion、vSphere HA等）。若查看ESXi主机的文件系统，它表现为一个自动挂载的子目录。不过，尽管作为常规的VMFS来使用，它却没有其他环境中的那些VMFS所具有的限制，因为连接到虚拟机主页名字空间VMFS卷的主机最多是2台（例如，在vMotion发生时），而在传统环境下同样的VMFS卷往往是同时被几十台主机共享的。换而言之，vSAN对常规VMFS卷的用法是完全不同的，使其得以具有更高的扩展性和更佳的性能。

　　用于虚拟机主页的虚拟机存储策略是特殊的。大多数情况下，虚拟机主页存储对象都不会继承与VMDK一样的策略要求。设想一下，像虚拟机主页名字空间这样的对象需要闪存来当读缓冲或者需要条带功能吗？不需要！这就是为什么即便与虚拟机关联的策略中声明这些能力也不起作用的原因。不过有一个功能的确是继承的——允许的故障数。这个功能使虚拟机得以在群集中多个硬件发生故障的时候仍然可用。随着vSAN 6.2的发布，它还继承容错方法的策略设置，这意味着虚拟机主页名字空间可以以RAID-5或RAID-6的方式部署，而不仅限于以前版本中RAID-1。

　　由于对于虚拟机主页存储对象来说，高性能不是主要诉求，继承下来的VMDK的设置会被覆盖掉，条带宽度（Stripe Width）总是设成1，读取缓存预留（Read Cache Reservation）总是设成0%，而且对象空间预留（Object Space Reservation）被设成0%所以它总是精简置备的。这使得虚拟机主页名字空间不会无谓消耗资源，而把可用资源留给那些需要的对象，例如VMDK。

　　另外一个要点是，如果策略中设置了强制置备（Force Provisioning），虚拟机主页名字空间对象会继承这个属性，这意味着，即使资源总量不足，虚拟机也会被部署。

　　在vSAN 6.2中引入了一个新的性能服务，它汇集了群集中所有ESXi主机的性能信息，并将性能指标存储在vSAN数据存储的一个状态表中。这个存储着“状态数据库”的对象也是一个名字空间对象。因此，名字空间对象的使用不仅限于虚拟机（尽管这是最常见的用法）。

5.2.4 虚拟机交换文件

　　虚拟机交换文件也具有自己的特殊策略设置。虚拟机交换文件的策略中允许的故障数总是为1，主要原因是虚拟机重启时是不会沿用原交换文件的。当HA在群集中的另外一台主机上重启虚拟机的时候，新的交换文件会被创建出来。因此，没有必要在可以容忍一个故障的水平之上再增加额外的保护。

　　默认情况下，无需将策略中的对象空间预留设为100%，交换文件也会事先被100%的置备出来。这意味着从接入控制的角度说，如果没有足够的空间来容纳整个虚拟机交换文件，虚拟机就不能在vSAN上置备出来。在vSAN 6.2中，有一个新的高级主机选项SwapThickProvisionDisabled，它可以允许虚拟机交换文件以精简对象的方式被置备出来。如果这个高级设置被设成True，则虚拟机交换文件对象将是精简置备的。

5.2.5 VMDK和增量盘

　　现在你知道了，当虚拟机部署的时候，虚拟机主页名字空间和虚拟机交换文件（.vswp）有其自己的默认策略，并不与策略中设置的功能一致。因此，只有VMDK和这些磁盘文件的快照（增量盘）才遵循设置在虚拟机存储策略中的那些属性。

　　因为vSAN对象有可能是由多个组件构成的，部署的时候每个VMDK和增量盘都会有其自己的RAID树配置。

5.2.6 见证和副本

　　作为RAID-1树的一部分，每个对象通常都有多个副本，我们已经知道，这些副本是由一个或多个组件组成的。在此我们想说，一个或多个见证组件可能会随着虚拟机存储对象被创建出来。在RAID-1树中，见证是每个对象的一部分。它是组成RAID-1树的叶子，但只包括元数据（metadata）。见证是当vSAN群集中发生了故障后进行仲裁决断的时候用来打破平局的裁判。

　　让我们用一个最简单的例子来解释下这么设计的目的：假设要部署的虚拟机的配置是条带宽度为1且允许的故障数为1。在这个例子中，我们不想使用RAID-5或RAID-6。这种情况下，需要为每台虚拟机创建2个副本。因此，RAID-1设置就足够了。然而在2个副本的情况下，如果主机之间失联，将无法分辨这到底是主机故障还是网络分区的情况。因此，需要在配置中引入一个第三方，这就是见证。vSAN中的一个对象要被认定为可用，必须满足以下两个条件：

1. RAID树必须允许数据访问（RAID-1必须至少有一个完好的副本，RAID-0必须所有的条带都完好）。对于RAID-5和RAID-6配置来说，RAID-5要求4个组件中必须有3个可用，而RAID-6则是6个组件中必须有4个可用。

2. 在vSAN的早期版本中，规则是必须有超过50%的组件可用。从vSAN 6.0开始，引入了和组件相关联的投票(vote) ，规则被更改为投票至少要超过50%。

　　

   在前面的例子中，只有当能同时访问到一个副本和一个见证，或者同时访问到两个副本（无见证）的时候，才能够访问这个对象。这样，在出现网络分区的情况下，至少有部分群集可以访问这个对象。

　　一个常见的问题是，见证是否消耗vSAN数据存储的空间？在最初的vSAN 5.5版中，使用VMFS作为磁盘格式，一个见证在vSAN数据存储上消耗大约2MB空间来存放元数据(metadata)。自从vSAN 6.0版发布起，使用vSANFS作为磁盘格式，一个见证在vSAN数据存储上大约要消耗4MB空间来存放元数据。尽管相对而言见证占据的空间很小，但是如果需要在vSAN上大量部署很多虚拟机和很多VMDK，在进行设计、容量规划和扩展性考量的时候，这也是值得考虑的因素。

5.2.7 对象布局

　　另一个常常被提起的问题是，vSAN环境中对象到底是怎么分布的？如前所述，虚拟机主页空间是用来存储虚拟机配置文件的，它是VMFS格式的。所有其他虚拟机磁盘对象（不论是VMDK还是快照）都以其各自的方式被实例化成一种分布式存储对象。

vSAN会负责对象的放置来满足允许的故障数以及容错方法的要求，管理员无须担心这些(对象的)放置决策。我们能够理解你的心情，对于这样一种新型的解决方案，你可能希望会对组件和对象存放的物理位置有一个更好的了解。VMware觉得管理员可能会有这样的期望，因此，vSphere用户界面中有地方可以让管理员来查看虚拟机对象的布局，并可看见组成一个存储对象的每个组件（条带、副本及见证）存放的位置，如图5-5所示。

 

图5-5  RAID-1, RAID-0和见证

 

　　处于可用性的考虑，vSAN绝不会让不同的副本（镜像）组件共用同一台主机。

　　

   注意，在vSAN 6.2之前的版本中，我们看不见虚拟机交换文件对象。这是因为交换文件UUID目前无法通过VIM应用程序可编程接口来获得，因此无论是Ruby vSphere Console（RVC，将在第10章介绍）还是vSphere Web客户端都无法显示其信息。不过，早先的版本中有一个办法来获取交换文件的信息，稍后会演示。在vSAN 6.2之前的版本中，快照/增量盘对象在vSphere用户界面中也不可见，不过这些对象默认是继承其VMDK母盘的策略配置的（也就是说其对象分布和其VMDK母盘是一致的）。

　　在vSAN 6.2中，虚拟机交换文件和快照增量都可以通过vSphere Web客户端查看。可以这么做：导航到vSAN Cluster (vSAN群集) à Monitor(监控)，然后选择Virtual Disk(虚拟磁盘)，对象就都列出在那里了。我们已经说过不少关于虚拟机存储策略的概念了，现在让我们再深入一步。

 

默认虚拟机存储策略

VMware鼓励管理员们不要依赖默认策略的设置而是去创建自己的vSAN策略。不过，如果你决定在vSAN数据存储上部署虚拟机时不选择任何策略，那么默认策略就会被应用。默认策略（名字叫做Virtual SANdefaultstorage policy）有一些非常特殊的特性，当管理员在（不管是什么原因）没有选择策略的情况时，它可以防止虚拟机及其相关数据置于风险之中。在vSAN的早期版本中这种情况相当常见，我们就见过很多次管理员在匆忙中创建了虚拟机但是忘记了选择策略的情况。不过，的确需要强调的是，VMware强烈建议管理员们创建自己的虚拟机存储策略，即使需求和默认策略完全一致。这仅仅只是因为一点：自建策略使得管理员可以获取有意义的合规性检查报告。

　　默认策略可以通过vSphere Web客户端来观察，如图 5-6所示。

图 5-6 vSAN默认存储策略

　

　由此我们可以推断出部署出来的存储对象总是带有允许的故障数为1的属性。图5-6没有显示出来的是容错方法策略设置，它的默认值是RAID-1(Mirroring)–  Performance。这意味着没有使用RAID-5配置（不会是RAID-6）。换而言之，存储对象将部署为RAID-1镜像方式。如果容错方法设置成RAID-5/6(ErasureCoding) – Capacity，那么根据FTT的数值的不同，就会实施RAID-5或RAID-6，其中的关系我们在第4章已经详细探讨过了。图5-7显示了在一个策略中可以选择的各种容错方法的选项。

图5-7 容错方法

　　关于默认策略需要提起的另外一点是校验和将被启用，换而言之就是disable checksum(禁用校验和)功能将被设置成false。

　　最后一点和强制置备有关。默认情况下，强制置备为No，仅VM交换文件对象是个例外（对其默认为启用）。如果你想在一个单主机的vSAN群集上引导一台vCenterServer，在当前配置下是无法实现的。这是因为默认策略中的允许的故障数为1，如果只有一台主机可用，vSAN将无法满足这个条件，所以虚拟机将无法创建。要想使之可行，必须更改默认策略，将默认策略中的强制置备更改成Yes。

　　接下去让我们简短地看一下，除了默认策略之外，管理员还能在一个策略中定义些什么东西。

 

---

[1]对于存储组件来说是闪存所提供的缓冲/缓存功能是透明的，也就是说，组件不关心也不知道自己的数据是通过闪存中的缓存/缓冲提供的还是直接访问磁盘的。——译者注

[2] CBRC是Content-Based ReadCache缩写，意思是基于内容的读缓冲。

 

 ---End

 

微信公众号-乐生活与爱IT 将连载vSAN架构细节的系列文章，本篇是

vSAN架构细节系列之二。上一期是： 《vSAN架构细节-分布式RAID》

2017年10月26-27日，VMware中国在北京-中国大饭店举办vForum 2017年度用户大会。欢迎扫描如下二维码报名参加。

另外大会还提供了至少100多本《vSAN权威指南》第二版的书籍。