Loading

【VMware VCF】VCF 5.2：配置管理域 vSAN 延伸集群。

VMware vSAN 解决方案中，根据集群的配置类型分为 vSAN 标准集群、vSAN 延伸集群以及双主机集群（延伸集群特例）。我们最常见的使用方式应该是 vSAN 标准集群，也就是 vSAN HCI 超融合集群，至少由 3 台 ESXi 主机所组成，这些 ESXi 主机安装位属于同一个数据中内，将本地磁盘聚合后提供给工作负载使用。为什么需要 vSAN 延伸集群？vSAN 标准集群能够为虚拟机提供同一数据中心站点内的冗余保护，比如因主机或者机柜故障，而不影响工作负载的正常运行。但是这还不够，因为还有可能发生数据中心级别的故障，vSAN 延伸集群方案就是为了解决这一问题，能够实现跨数据中心级别的虚拟机保护。双主机集群是延伸集群架构的一种特例，适用于 ROBO 这种小型场景，由于集群内的主机数仅仅需要两台，因此被称为双主机/节点集群。

在 vSAN 中，对于虚拟机的保护是依赖基于存储存储的管理（SPBM）来实现的，SPBM 根据 vSAN 集群中的故障域数来配置虚拟机的存储策略，故障域数越多，虚拟机可配置的保护级别就越高。首先需要先理解一个概念，那就是故障域（FD），故障域是针对某一类主机的逻辑划分，这类主机可能位于同一个机柜或者同一个数据中心，这个区域我们认为可能会发生故障，所以可以将这个区域内的主机划分为一个故障域。在标准 vSAN 集群中，如果没有针对集群内的主机进行特定的区分，那每一个主机都属于一个独立的故障域，如果进行了区分，可以创建故障域并将主机划入到这个故障域中，当然最终的故障域数不能少于 vSAN 集群最低要求 （3 个，包含故障域和独立主机数）。在 vSAN 延伸集群中，一个数据中心属于一个故障域，主备数据中心站点分别属于不同的故障域，这样就有两个故障域，为了解决双活数据中心存在的“脑裂”问题，单独设置了仲裁服务器，这个仲裁节点位属于第三站点并且属于一个独立的故障域，最终形成了一个由三个故障域所组成的 vSAN 延伸集群。

在 SPBM 中，对于虚拟机的保护级别是通过允许的故障数 Failures To Tolerate（FTT）来定义的，而 FTT 有两种，一种是 PFTT，另一种是 SFTT。PFTT 叫允许的故障数“主要”级别，对应 SPBM 配置中的“站点容灾”，可供设置的选项有标准集群、延伸集群以及双节点集群等；SFTT 叫允许的故障数“辅助”级别，对应 SPBM 配置中的“允许的故障数”，可供设置的选项有无数据冗余（RAID 0）、RAID 1、RAID 5 以及 RAID 6等。通常，我们所说的 FTT 都是指 SFTT，因为 SFTT 保护级别可以反映 vSAN 集群要求的主机数量（故障域数）。如果是标准 vSAN 集群，那 PFTT 默认设置为“标准集群”，然后根据集群内的主机数设置 SFTT 保护级别；如果是 vSAN 延伸集群，那 PFTT 可以设置的选项就多了，默认设置为“延伸集群”，然后根据主（首选）站点或备（辅助）站点上的主机数量设置 SFTT 保护级别。

当然，不管是 vSAN 标准/延伸集群，集群内的主机数量越多，越能为虚拟机带来更高的保护级别，代价就是需要消耗更多的存储空间。

VMware Cloud Foundation 解决方案中，默认构建的管理工作负载域所使用的 vSAN 集群为标准 vSAN HCI 集群。登录管理域 vCenter Server（vSphere Client），导航到集群（vcf-mgmt01-cluster01）->配置->vSAN->故障域，可以看到当前 vSAN 集群配置类型为单站点集群。集群内共有 4 台 ESXi 主机，在标准 vSAN 集群下每台主机都属于独立的故障域，根据 FTT = 2N + 1，当前可允许的故障域故障数（FTT）为 1，也就是说当失去一个故障域（主机）的情况下，也还有一个故障域（主机）可以满足 FTT = 2N+1 的要求，从而恢复虚拟机存储策略保护级别的弹性（RAID 1）。当然如果想实现 FTT=2 的保护级别，vSAN 集群内的主机至少要求 5 台主机，建议使用 6 台主机以确保当某台主机故障后能够恢复其规定的弹性级别；如果想实现 FTT=3 的保护级别，vSAN 集群内的主机至少要求 7 台主机，建议使用 8 台主机以确保当某台主机故障后能够恢复其规定的弹性级别。

实际环境中，可能需要将标准的 vSAN 集群拓展为 vSAN 延伸集群，从而为工作负载实现更高级别的保护。VMware Cloud Foundation 中可以对工作负载域中的 vSAN 集群进行延伸，但是具有许多要求和注意事项，比如在对 VI 工作负载域中 vSAN 集群进行延伸之前，需要先延伸管理工作负载域默认集群，不能使用常规的方法去延伸 VCF 实例中的 vSAN 集群，需要使用 SDDC Manager 中的 API 资源管理器执行延伸过程，VMware Cloud Foundation 5.2 开始支持管理域 vSAN ESA 延伸集群。下面来看看具体的配置过程。

 

一、添加见证主机

vSAN 延伸集群由首选和辅助两个数据站点以及见证主机组成，见证主机通常位于第三站点，由于 vSAN 见证主机上只存放虚拟机对象的见证组件，并且只是 Metadata 元数据，不参与 vSAN 数据存储操作，所以可以使用低带宽/高延迟链路连接到两个数据站点。vSAN 见证主机是一个专用的虚拟 ESXi 主机，可以通过 VCF BOM 物料清单确定对应的发行版本。注意，vSAN OSA 和 vSAN ESA 架构具有单独的见证设备，需要根据实际情况部署与集群匹配的 vSAN 见证主机。

见证主机的部署过程这里就忽略了，由于当前 VCF 是嵌套环境，可以将 vSAN 见证设备部署到嵌套环境的物理主机上即可，下面主要陈述一下添加过程。登录管理域 vCenter Server（vSphere Client），导航到数据中心（vcf-mgmt01-datacenter01），右击“添加主机”，输入见证主机的 FQDN 后，点击下一页。

输入见证主机的用户名和密码。

验证见证主机的证书指纹。

查看见证主机的摘要信息。

设置见证主机的生命周期管理方式，可以暂时不设置，从 vSphere 8 U2 开始支持通过 vLCM 使用映像直接管理见证主机的生命周期。

分配见证主机的许可证，默认即可。

设置见证主机的锁定模式。

选择见证主机虚拟机的位置。

检查所有信息，点击完成。

已完成见证主机的添加。

注意，用于见证主机 vSAN 服务的 VMkernel 网卡地址需要与管理域 vSAN 集群中主机的 vSAN 网络互相通信，如果使用不同网段并且跨 L3 路由，请在见证主机以及 vSAN 主机上配置相应的路由使其互通，由于这里是测试环境，见证主机使用了与管理域主机相同网段 vSAN 服务的 VMkernel 地址，所以只需要将见证主机 vSAN 服务的 VMkernel 端口组设置为相同 VLAN 即可。

 

二、添加服役主机

vSAN 延伸集群具有首选和辅助两个数据站点，VCF 管理域初始构建的时候要求至少由 4 台 ESXi 主机组成 vSAN 集群，所以当延伸 vSAN 集群后，这 4 台主机将被划分为首选站点主机，我们需要增加用于辅助站点的 ESXi 主机，并且需要先将这些主机添加到 SDDC Manager 服役主机清单当中。注意，新添加的主机请尽量与当前管理域中的主机保持一致，如配置和数量等。

导航到 SDDC Manager->清单->主机，点击服役主机后，选择导入并使用 JSON 模板文件来批量添加 ESXi 主机，如下所示：

{
    "hostsSpec": [
        {
            "hostfqdn": "vcf-mgmt01-esxi05.mulab.local",
            "username": "root",
            "storageType": "VSAN_ESA",
            "password": "Vcf5@password",
            "networkPoolName": "vcf-mgmt01-np01",
            "vvolStorageProtocolType": ""
        },
		{
            "hostfqdn": "vcf-mgmt01-esxi06.mulab.local",
            "username": "root",
            "storageType": "VSAN_ESA",
            "password": "Vcf5@password",
            "networkPoolName": "vcf-mgmt01-np01",
            "vvolStorageProtocolType": ""
        },
		{
		    "hostfqdn": "vcf-mgmt01-esxi07.mulab.local",
            "username": "root",
            "storageType": "VSAN_ESA",
            "password": "Vcf5@password",
            "networkPoolName": "vcf-mgmt01-np01",
            "vvolStorageProtocolType": ""
        },
        {
            "hostfqdn": "vcf-mgmt01-esxi08.mulab.local",
            "username": "root",
            "storageType": "VSAN_ESA",
            "password": "Vcf5@password",
            "networkPoolName": "vcf-mgmt01-np01",
            "vvolStorageProtocolType": ""
        }
    ]
}

完成服役主机添加工作流后，所有主机会显示在未分配的主机列表当中，如下图所示。

 

三、配置延伸集群

VMware Cloud Foundation 解决方案中延伸 vSAN 集群与我们常规的 vSAN 集群的延伸过程不同，不能直接在工作负载域 vCenter Server（vSphere Client）中添加主机并配置 vSAN 延伸集群。由于 VCF 是一个融合了 vSphere、vSAN 以及 NSX（可能还部署了 NSX Edge 集群） 等产品的 SDDC 解决方案，VMware 有一个专门针对 VCF 实例并且延伸 vSAN 集群的编排方案，这个方案需要使用 SDDC Manager 中的 API 资源管理器（API Explorer）来完成配置。

导航到 SDDC Manager->开发人员中心（Developer Center），通过这里的 API 资源管理器（API Explorer）完成 vSAN 延伸集群的配置。关于 API 资源管理器的参考指南可以访问 VMware Cloud Foundation API Reference Guide 进行查看。

使用 API 资源管理器来延伸 vSAN 集群需要做一些前期准备，比如前面我们准备了 vSAN 见证主机并将见证主机添加到了 VCF 管理域当中，还将用于辅助站点的 ESXi 主机添加到了 SDDC Manager 服役主机清单，这些是延伸 vSAN 集群的必备条件。你还可以为辅助站点的 ESXi 主机单独创建网络池并用于分配 vSAN 和 vMotion 服务的 IP 地址，不过由于是测试环境，我直接使用了当前管理域的网络池。除了这些，使用 API 资源管理器来延伸 vSAN 集群还需要准备 JSON 配置文件，在这个 JSON 配置文件中预定义了延伸 vSAN 集群的配置信息，比如辅助站点的 ESXi 主机（主机名、ID 以及 License 等）、NSX（TEP IP 地址池、上行链路配置文件以及传输节点配置文件等）以及见证主机等。准备好 JSON 配置文件以后可以对该配置文件进行配置前验证，如果没问题，通过 API 资源管理器使用 JSON 配置文件即可执行 vSAN 集群的延伸。

1）JSON 模板配置文件。

用于延伸 vSAN 集群的 JSON 模板配置文件如下所示，不过以下模板只能用于 VCF 工作负载域中具有单个 VDS 分布式交换机的场景，比如在构建 VCF 管理域的时候使用 Profile-1 配置文件，这个配置文件要求 ESXi 主机具有两张网卡用于 VDS 分布式交换机，这个交换机上同时承载了管理网络、vMotion 网络、vSAN 网络以及 NSX Overlay 网络的所有流量。实际环境中，通常 ESXi 主机具有多张网卡并且配置了多个分布式交换机，比如当前测试环境中，有 4 张网卡，创建了 2 个 VDS 交换机，这种情况下就不能完全使用下面的 JSON 配置文件模板了，需要对该配置文件进行一些调整。不过，JSON 配置文件中有些信息是需要提前获取的，比如 ESXi 主机 ID，下面看看如何获取这些信息并完成 JSON 配置文件的准备。

{
 "clusterStretchSpec": {
  "hostSpecs": [
   {
    "hostname": "sfo02-w01-esx01.sfo.rainpole.io",
    "hostNetworkSpec": {
     "networkProfileName": "sfo-w01-az2-nsx-np01",
     "vmNics": [
      {
       "id": "vmnic0",
       "uplink": "uplink1",
       "vdsName": "sfo-w01-cl01-vds01"
      },
      {
       "id": "vmnic1",
       "uplink": "uplink2",
       "vdsName": "sfo-w01-cl01-vds01"
      }
     ]
    },
    "id": "<ESXi host 1 ID>",
    "licenseKey": "<license key>"
   },
   {
    "hostname": "sfo02-w01-esx02.sfo.rainpole.io",
    "hostNetworkSpec": {
     "networkProfileName": "sfo-w01-az2-nsx-np01",
     "vmNics": [
      {
       "id": "vmnic0",
       "uplink": "uplink1",
       "vdsName": "sfo-w01-cl01-vds01"
      },
      {
       "id": "vmnic1",
       "uplink": "uplink2",
       "vdsName": "sfo-w01-cl01-vds01"
      }
     ]
    },
    "id": "<ESXi host 2 ID>",
    "licenseKey": "<license key>"
   },
   {
    "hostname": "sfo02-w01-esx03.sfo.rainpole.io",
    "hostNetworkSpec": {
     "networkProfileName": "sfo-w01-az2-nsx-np01",
     "vmNics": [
      {
       "id": "vmnic0",
       "uplink": "uplink1",
       "vdsName": "sfo-w01-cl01-vds01"
      },
      {
       "id": "vmnic1",
       "uplink": "uplink2",
       "vdsName": "sfo-w01-cl01-vds01"
      }
     ]
    },
    "id": "<ESXi host 3 ID>",
    "licenseKey": "<license key>"
   },
   {
    "hostname": "sfo02-w01-esx04.sfo.rainpole.io",
    "hostNetworkSpec": {
     "networkProfileName": "sfo-w01-az2-nsx-np01",
     "vmNics": [
      {
       "id": "vmnic0",
       "uplink": "uplink1",
       "vdsName": "sfo-w01-cl01-vds01"
      },
      {
       "id": "vmnic1",
       "uplink": "uplink2",
       "vdsName": "sfo-w01-cl01-vds01"
      }
     ]
    },
    "id": "<ESXi host 4 ID>",
    "licenseKey": "<license key>"
   }
  ],
  "isEdgeClusterConfiguredForMultiAZ": <true, if the cluster hosts an NSX Edge cluster; false, if the cluster does not host an NSX Edge cluster>,
  "networkSpec": {
   "networkProfiles": [
    {
     "isDefault": false,
     "name": "sfo-w01-az2-nsx-np01",
     "nsxtHostSwitchConfigs": [
      {
       "ipAddressPoolName": "sfo-w01-az2-host-ip-pool01",
       "uplinkProfileName": "sfo-w01-az2-host-uplink-profile01",
       "vdsName": "sfo-w01-cl01-vds01",
       "vdsUplinkToNsxUplink": [
        {
         "nsxUplinkName": "uplink-1",
         "vdsUplinkName": "uplink1"
        },
        {
         "nsxUplinkName": "uplink-2",
         "vdsUplinkName": "uplink2"
        }
       ]
      }
     ]
    }
   ],
   "nsxClusterSpec": {
    "ipAddressPoolsSpec": [
     {
      "description": "WLD01 AZ2 Host TEP Pool",
      "name": "sfo-w01-az2-host-ip-pool01",
      "subnets": [
       {
        "cidr": "172.16.44.0/24",
        "gateway": "172.16.44.253",
        "ipAddressPoolRanges": [
         {
          "end": "172.16.44.200",
          "start": "172.16.44.10"
         }
        ]
       }
      ]
     }
    ],
    "uplinkProfiles": [
     {
      "name": "sfo-w01-az2-host-uplink-profile01",
      "teamings": [
       {
        "activeUplinks": [
         "uplink-1",
         "uplink-2"
        ],
        "name": "DEFAULT",
        "policy": "LOADBALANCE_SRCID",
        "standByUplinks": []
       }
      ],
      "transportVlan": 1644
     }
    ]
   }
  },
  "witnessSpec": {
   "fqdn": "sfo-w01-cl01-vsw01.sfo.rainpole.io",
   "vsanCidr": "172.17.11.0/24",
   "vsanIp": "172.17.11.219"
  },
  "witnessTrafficSharedWithVsanTraffic": false
 }
}

2）获取 ESXI 主机 ID。

JSON 配置文件中需要填入用于辅助站点 ESXi 主机的 ID，这就是为什么需要提前将主机添加到服役主机清单中的原因，因为这样你才能获取到这些主机的 ID。导航到 SDDC Manager->开发人员中心（Developer Center）->API 资源管理器，在序号③处输入“Hosts”搜索 API 类别，找到序号④“Hosts”。

展开“Hosts”，找到序号①“GET /v1/hosts”并展开，在序号②“status”处填入“UNASSIGNED_USEABLE”，然后点击序号③“执行”。

执行后，在下面可以看到 Response。

展开序号①“PageOfHost”，再展开某一台主机序号②“Host......”，在序号③处确定主机的 FQDN，在序号④处获取主机的 ID。

使用上述相同的方式展开所有 Host，获取所有 ESXi 主机的 ID，最终得到的信息如下表所示：

主机 ID
vcf-mgmt01-esxi05.mulab.local 9147f1ce-7b65-40e4-a8e7-f4fe5ce98295
vcf-mgmt01-esxi06.mulab.local 373f5d1d-d074-4da6-b5ef-765880fa90a5
vcf-mgmt01-esxi07.mulab.local e1c85352-d168-493e-a2a3-be4772e51a93
vcf-mgmt01-esxi08.mulab.local c282a60d-bc00-404c-a65a-8244886b7b9d

其实还有一个最简单直接的方法可以获取 ESXi 主机的 ID，在下图的地方点击进入某一个 ESXi 主机后，你可以在浏览器地址栏中获取该主机的 ID 信息。

https://vcf-mgmt01-sddc01.mulab.local/ui/sddc-manager/inventory/hosts/host/9147f1ce-7b65-40e4-a8e7-f4fe5ce98295/summary(monitoring-panel:monitoring/tasks)

3）准备 JSON 配置文件。

获取了所有 ESXi 主机的 ID 信息之后，现在可以准备 JSON 配置文件了，如下所示，这是用于具有 2 个分布式交换机的 vSAN 延伸集群环境的 JSON 配置文件。每个 ESXi 主机的 LicenseKey 已经过处理，请注意，这些 License 需要在 SDDC Manager 许可证清单中。每个 ESXi 主机的网卡需要与现有 vSAN 集群环境中 ESXi 主机分配给 VDS 分布式交换机的网卡对应，交换机名称也需要对应。由于当前 vSAN 集群未配置 NSX Edge 集群，所以 isEdgeClusterConfiguredForMultiAZ 配置为 false。需要为辅助站点的 ESXi 主机配置新的 TEP IP 地址池、新的上行链路配置文件以及新的传输节点配置文件，这个新的传输节点配置文件叫子传输节点配置文件（子 TNP），最终辅助站点被配置为子集群。az2 表示 availability zone 2（可用区域 2），首选站点为 az1（可用区域 1）。最后，将 vSAN 见证主机的信息填入配置文件中，vsanIp 是见证主机用于 vSAN 流量的 VMkernel 网卡地址。witnessTrafficSharedWithVsanTraffic 配置选项为 true 表示 ESXi 主机的见证流量和 vSAN 流量共享一个网卡，如果值为 false，则将 vSAN 见证流量和 ESXi 主机的 vSAN 流量分开并单独配置其他网卡（默认是管理网卡）与 vSAN 见证主机的 vSAN 网络通信。

{
 "clusterStretchSpec": {
  "hostSpecs": [
   {
    "hostname": "vcf-mgmt01-esxi05.mulab.local",
    "hostNetworkSpec": {
     "networkProfileName": "vcf-mgmt01-az2-network-profile",
     "vmNics": [
      {
       "id": "vmnic0",
       "uplink": "uplink1",
       "vdsName": "vcf-mgmt01-vds01"
      },
      {
       "id": "vmnic1",
       "uplink": "uplink2",
       "vdsName": "vcf-mgmt01-vds01"
      },
	  {
       "id": "vmnic2",
       "uplink": "uplink1",
       "vdsName": "vcf-mgmt01-vds02"
      },
      {
       "id": "vmnic3",
       "uplink": "uplink2",
       "vdsName": "vcf-mgmt01-vds02"
      }
     ]
    },
    "id": "9147f1ce-7b65-40e4-a8e7-f4fe5ce98295",
    "licenseKey": "00000-00000-00000-00000-00000"
   },
   {
    "hostname": "vcf-mgmt01-esxi06.mulab.local",
    "hostNetworkSpec": {
     "networkProfileName": "vcf-mgmt01-az2-network-profile",
     "vmNics": [
      {
       "id": "vmnic0",
       "uplink": "uplink1",
       "vdsName": "vcf-mgmt01-vds01"
      },
      {
       "id": "vmnic1",
       "uplink": "uplink2",
       "vdsName": "vcf-mgmt01-vds01"
      },
	  {
       "id": "vmnic2",
       "uplink": "uplink1",
       "vdsName": "vcf-mgmt01-vds02"
      },
      {
       "id": "vmnic3",
       "uplink": "uplink2",
       "vdsName": "vcf-mgmt01-vds02"
      }
     ]
    },
    "id": "373f5d1d-d074-4da6-b5ef-765880fa90a5",
    "licenseKey": "00000-00000-00000-00000-00000"
   },
   {
    "hostname": "vcf-mgmt01-esxi07.mulab.local",
    "hostNetworkSpec": {
     "networkProfileName": "vcf-mgmt01-az2-network-profile",
     "vmNics": [
      {
       "id": "vmnic0",
       "uplink": "uplink1",
       "vdsName": "vcf-mgmt01-vds01"
      },
      {
       "id": "vmnic1",
       "uplink": "uplink2",
       "vdsName": "vcf-mgmt01-vds01"
      },
	  {
       "id": "vmnic2",
       "uplink": "uplink1",
       "vdsName": "vcf-mgmt01-vds02"
      },
      {
       "id": "vmnic3",
       "uplink": "uplink2",
       "vdsName": "vcf-mgmt01-vds02"
      }
     ]
    },
    "id": "e1c85352-d168-493e-a2a3-be4772e51a93",
    "licenseKey": "00000-00000-00000-00000-00000"
   },
   {
    "hostname": "vcf-mgmt01-esxi08.mulab.local",
    "hostNetworkSpec": {
     "networkProfileName": "vcf-mgmt01-az2-network-profile",
     "vmNics": [
      {
       "id": "vmnic0",
       "uplink": "uplink1",
       "vdsName": "vcf-mgmt01-vds01"
      },
      {
       "id": "vmnic1",
       "uplink": "uplink2",
       "vdsName": "vcf-mgmt01-vds01"
      },
	  {
       "id": "vmnic2",
       "uplink": "uplink1",
       "vdsName": "vcf-mgmt01-vds02"
      },
      {
       "id": "vmnic3",
       "uplink": "uplink2",
       "vdsName": "vcf-mgmt01-vds02"
      }
     ]
    },
    "id": "c282a60d-bc00-404c-a65a-8244886b7b9d",
    "licenseKey": "00000-00000-00000-00000-00000"
   }
  ],
  "isEdgeClusterConfiguredForMultiAZ": false,
  "networkSpec": {
   "networkProfiles": [
    {
     "isDefault": false,
     "name": "vcf-mgmt01-az2-network-profile",
     "nsxtHostSwitchConfigs": [
      {
       "uplinkProfileName": "vcf-mgmt01-vds01-az2-uplink-profile",
       "vdsName": "vcf-mgmt01-vds01",
       "vdsUplinkToNsxUplink": [
        {
         "nsxUplinkName": "uplink-1",
         "vdsUplinkName": "uplink1"
        },
        {
         "nsxUplinkName": "uplink-2",
         "vdsUplinkName": "uplink2"
        }
       ]
      },
	  {
       "ipAddressPoolName": "vcf01-mgmt01-tep02-az2",
       "uplinkProfileName": "vcf-mgmt01-vds02-az2-uplink-profile",
       "vdsName": "vcf-mgmt01-vds02",
       "vdsUplinkToNsxUplink": [
        {
         "nsxUplinkName": "uplink-1",
         "vdsUplinkName": "uplink1"
        },
        {
         "nsxUplinkName": "uplink-2",
         "vdsUplinkName": "uplink2"
        }
       ]
      }
     ]
    }
   ],
   "nsxClusterSpec": {
    "ipAddressPoolsSpec": [
     {
      "description": "AZ2 Host TEP Pool",
      "name": "vcf01-mgmt01-tep02-az2",
      "subnets": [
       {
        "cidr": "192.168.43.0/24",
        "gateway": "192.168.43.254",
        "ipAddressPoolRanges": [
         {
          "end": "192.168.43.50",
          "start": "192.168.43.1"
         }
        ]
       }
      ]
     }
    ],
    "uplinkProfiles": [
     {
      "name": "vcf-mgmt01-vds01-az2-uplink-profile",
      "teamings": [
       {
        "activeUplinks": [
         "uplink-1",
         "uplink-2"
        ],
        "name": "DEFAULT",
        "policy": "LOADBALANCE_SRCID",
        "standByUplinks": []
       }
      ],
      "transportVlan": 0
     },
	 {
      "name": "vcf-mgmt01-vds02-az2-uplink-profile",
      "teamings": [
       {
        "activeUplinks": [
         "uplink-1",
         "uplink-2"
        ],
        "name": "DEFAULT",
        "policy": "LOADBALANCE_SRCID",
        "standByUplinks": []
       }
      ],
      "transportVlan": 43
     }
    ]
   }
  },
  "witnessSpec": {
   "fqdn": "vcf-mgmt01-witness01.mulab.local",
   "vsanCidr": "192.168.41.0/24",
   "vsanIp": "192.168.41.200"
  },
  "witnessTrafficSharedWithVsanTraffic": true
 }
}

4）获取管理域集群 ID。

准备好 JSON 配置文件之后，我们可以对该配置文件进行验证，但是在进行验证之前，需要先获取 VCF 管理域集群的 ID。导航到 SDDC Manager->开发人员中心（Developer Center）->API 资源管理器，在序号③处输入“Clusters”搜索 API 类别，找到序号④“Clusters”。

展开序号①“Clusters”，找到序号②“GET /v1/clusters”并展开，然后点击序号③“执行”。

展开序号①“PageOfCluster”，再展开序号②“Cluster(vcf-mgmt01-cluster01)”，在序号③处可以获取到集群的 ID。

使用上述方式获取的集群 ID，如下表所示：

集群 ID
vcf-mgmt01-cluster01 1c10ff5f-d65f-4cc4-a062-79be46b3d9d7

其实还有一个最简单直接的方法可以获取集群的 ID，在下图的地方点击进入集群后，你可以在浏览器地址栏中获取该集群的 ID 信息。

https://vcf-mgmt01-sddc01.mulab.local/ui/sddc-manager/inventory/domains/mgmt-vi-domains/a0ef2be8-0d8c-4ac1-89aa-a6a575f3f9e0/clusters/1c10ff5f-d65f-4cc4-a062-79be46b3d9d7/summary(monitoring-panel:monitoring/tasks)

5）验证 JSON 配置文件。

准备好 JSON 配置文件以及获取了集群的 ID 后，下面验证一下 JSON 配置文件是否满足延伸 vSAN 集群要求。在序号①处输入“Clusters”搜索 API 类别后，展开序号②“Clusters”，找到序号③“POST /v1/clusters/{id}/validations”。

展开序号①“POST /v1/clusters/{id}/validations”后，在序号②处填入集群的 ID，在序号③处填入准备好的 JSON 配置文件，在序号④点击“执行”。如果验证成功，在序号⑤处可以看到执行状态为“COMPLETED”完成，在序号⑥处可以看到执行结果为“SUCCEEDED”成功。

6）配置 vSAN 延伸集群。

如果一切准备就绪，下面正式开始配置 vSAN 延伸集群。在序号①处输入“Clusters”搜索 API 类别后，展开序号②“Clusters”，找到序号③“PATCH /v1/clusters/{id}”。

展开序号①“PATCH /v1/clusters/{id}”后，在序号②处填入集群的 ID，在序号③处填入准备好的 JSON 配置文件，在序号④处点击“执行”，在序号⑤处可以看到执行状态为“IN_PROGRESS”处理中。

点击任务窗口，查看任务状态。

进入该任务，查看子任务状态。

延伸 vSAN 集群任务执行成功。

 

四、验证集群配置

导航到 SDDC Manager->清单->工作负载域->集群，可以看到 vSAN 配置状态为“已延伸”，延伸状态为“已启用”，说明配置成功。

登录管理域 vCenter Server（vSphere Client），导航到集群（vcf-mgmt01-cluster01）->配置->vSAN->故障域，可以看到配置类型为“延伸集群”。

导航到集群（vcf-mgmt01-cluster01）->配置->配置->虚拟机/主机组和虚拟机/主机规则，可以看到集群内首选站点主机组、辅助站点主机组以及虚拟机组，并且创建了虚拟机组与主机组的关联性规则。

导航到存储选项卡->存储（vcf-mgmt01-vsan-esa-datastore01）->配置->常规，可以查看该存储的默认存储策略为“stretched RAID5”。

导航到网络选项卡->网络文件夹（Management Networks）->网络->分布式端口组，可以查看辅助站点主机配置的分布式端口组信息。

登录管理域 NSX Manager（VIP），可以查看辅助站点主机被配置为传输节点主机，并且配置了子集群和相应的网络配置文件。

点击传输节点配置文件配置，可以看到集群的传输节点配置文件里，每个分布式交换机下面配置了子传输节点配置文件（子 TNP）。

点击配置文件查看上行链路配置文件，可以看到辅助站点创建的上行链路配置文件。

注意，配置 vSAN 延伸集群后，集群“添加主机”功能被禁用，如果后续想要扩展，则只能使用 API 资源管理器（API Explorer）来完成。

posted @ 2024-09-03 10:00  JUNIOR_MU  阅读(280)  评论(0)  编辑  收藏  举报