虚拟SAN我的问题’人们经常问到有关Virtual SAN中见证组件的行为和逻辑。显然,这有点混浊。因此,我想借此机会回答这个问题,并为那些在正式白皮书之前寻求有关该主题的更多细节的人们解答。因此,请注意这一点。

行为与逻辑我’这里要说明的m对最终用户是100%透明的,并且与见证组件的布局无关。此行为由系统管理和控制。这旨在提供您可能会看到的见证组件的数量及其原因的理解。

虚拟SAN对象由在配置了Virtual SAN的vSphere群集中的主机之间分布的组件组成。这些组件存储在Virtual SAN分布式数据存储中的磁盘组的不同组合中。通过基于闪存的设备及其数据为组件透明分配缓存和缓冲能力“at rest”在磁盘上。

见证组件是每个存储对象的一部分。 虚拟SAN Witness组件包含对象元数据,它们的目的是在必须在Virtual SAN群集中做出可用性决定时避免出现裂脑行为并满足法定要求的情况,成为决胜局。

虚拟SAN Witness组件以三种不同的方式定义和部署:

  • 主要证人
  • 次要证人
  • 抢劫者见证

主要证人: 群集中至少需要(2 * FTT)+ 1个节点才能容忍节点/磁盘故障的FTT数量。如果在放置所有数据组件之后,我们在配置中没有所需数量的节点,则主要见证方位于互斥节点上,直到配置中有(2 * FTT)+1个节点。

次要证人: 创建辅助见证人以确保每个节点对仲裁具有相等的投票权。这很重要,因为每个节点故障都应平等地影响仲裁。添加辅助见证人,以便每个节点获得相等数量的组件,这包括仅包含主要见证人的节点。因此,在此步骤中,均衡每个节点上的数据组件+见证的总数。

抢劫者证人: 如果在添加主见证服务器和辅助见证服务器后,最终在配置中获得的组件总数为偶数(数据+见证服务器),那么我们将添加一个决胜局见证服务器以使总组件计数为奇数。

让我将上述定义和逻辑结合到两个现实世界场景中,并解释为什么证人组件按其放置方式放置:

  • 方案1:带有511 GB VMDK的VM容忍失败1

注意: Virtual SAN对象名称空间限制为每个对象255GB。大于255GB的对象在主机之间平均分配。这说明了在以下两个示例中使用带有多个串联RAID 0集的RAID 1集配置说明的行为。

例子1

在此特定方案中仅部署了一个见证人,为什么?

在这种特定情况下,所有RAID 0条带都放置在不同的节点上。仔细看看主机名。

现在为什么以这种方式发生这种情况,这与上述证人类型有何关系?

在这种情况下执行见证计算时,见证组件逻辑将发挥作用,如下所示:

  • 主要证人: 数据分量分布在4个节点上(大于2 * FTT + 1)。因此,我们不需要主要证人。
  • 次要证人: 由于参与配置的每个节点仅具有一个组成部分,因此我们不需要任何辅助见证即可平均投票。
  • 抢劫者证人: 由于配置中的组件总数为4,因此我们只需要一名决胜局见证人。
  • 方案2:具有515 GB VMDK的VM容忍失败1

方案2

在这种情况下,部署了3个见证人,为什么?

在这种特定情况下,某些RAID 0条带放置在同一节点上。仔细看看主机名。组件的配置在以下配置中分层:

  • 节点vsan-host-1.pml.local上的2个组件
  • 节点vsan-host-4.pml.local上的2个组件
  • 节点vsan-host-3.pml.local上的1个组件
  • 节点vsan-host-2.pml.local上的1个组件
在这种情况下执行见证计算时,见证组件逻辑将发挥作用,如下所示:
  • 主要证人: 数据分量分布在4个节点上(大于2 * FTT + 1)。因此,我们不需要主要证人。
  • 次要证人: 由于两个节点各有2票,而2个节点各只有1票,因此我们需要在以下节点上添加一票(见证):
    • vsan-host-3.pml.local
    • vsan-host-2.pml.local
  • 抢劫者证人: 在将以上两个见证人相加后,配置中的总组件数为8(6个数据+ 2个见证人),我们需要一个决胜局见证人,这是第三个见证人。
在大多数情况下,人们希望见证者数量取决于对策略的容忍度(0到3)。见证人的数量完全取决于组件和数据的放置方式,并不是真正由给定的策略确定。
再次,正如我在本文开头所说的那样,此行为对最终用户而言是100%透明的,并且无需担心,因为该行为是由系统管理和控制的。
– Enjoy
有关将来的更新,请确保在Twitter上关注我: @PunchingClouds
X