Diff for "désert/VMware/VSAN"

故障域构造

您必须至少定义三个故障域，每个故障域可能包含一个或多个主机。故障域定义必须确认可能代表潜在故障域的物理硬件构造，如单个计算机柜。

如果可能，请使用至少四个故障域。使用三个故障域时，不允许使用特定撤出模式，Virtual SAN 也无法在故障发生后重新保护数据。在这种情况下，您需要一个使用三域配置时无法提供的备用容量故障域用于重新构建。

如果启用故障域，Virtual SAN 将根据故障域而不是单个主机应用活动虚拟机存储策略。

根据计划分配给虚拟机的存储策略中规定的“允许的故障数”属性，计算群集中的故障域数目。

number of fault domains = 2 * number of failures to tolerate + 1

如果主机不是故障域成员，Virtual SAN 会将其解析为单独的域。 

删除磁盘原有分区

使用partedUtil工具 首先确认哪些磁盘被确认出来。

esxcli storage core device list
# 获取 ID
partedUtil get /vmfs/xxx/xxx
1 2048 3xxx 0 0

# 删除分区
partedUtil delete /vmfs/xxx/xxx 1

MTU setting

Dell switches a MTU 9000 is actually (9 * 1024) = 9216. Ugh, so now I have set

• 9000 MTU on the VSAN VMkernel on the vSphere host.

• 9000 MTU on the VSAN VLAN on the Dell PowerConnect

• 9216 MTU on the VSAN Physical Interface the Dell PowerConnect

BAM! The VSAN datastore is rocking and I can now write to it. However, this scenario posed some reflection on how MTU actually impacts VSAN. I did some further testing and came up with the follow conclusions:

• If any host in a VSAN cluster has a mismatched MTU size, NOTHING can write to the VSAN datastore. Even if one host with the wrong MTU is set then it will prevent VSAN from working.

  • Even with mismatched MTU’s when one verifies the Network Status (vCenter > Virtual SAN > General) it will show Normal. However, this doesn’t verify MTU, just IP connectivity. To test if the MTU is correct then use the MTU of the VSAN VMkernel’s MTU size and issue a vmkping -s <VSANvmkernel_mtu_setting> <Other-VSANvmkernel-interfaces-in-cluster>

  VSAN performances about the same with or without Jumbo Frames configured.

In conclusion, would I advise configuring Jumbo Frames with VSAN? No. Unless you’re the type who prefers all risk and no reward… http://flcloudlabs.com/vsan-and-mtu/