> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/learn-the-platform/zh/mo-kuai-1-jia-gou-ji-chu/04-core-fabric.md).
# 核心 Fabric 与网络
## 什么是核心织构？
该 **core fabric** 它是一个私有的高速网状网络，连接 VergeOS 系统中的所有节点。它是每个 VergeOS 部署的骨干——所有内部集群通信都通过该织构传输。核心织构绝不会暴露给外部流量。
核心织构承载的流量类型包括：
* **vSAN 复制** — 存储参与节点之间的主数据块写入和冗余数据块写入
* **集群协调** — 节点健康检查、领导者选举和系统状态同步
* **虚拟机热迁移** — 在节点之间移动运行中的虚拟机时传输内存和 CPU 状态
* **控制平面** — VergeOS 服务之间的 API 调用、配置更新和管理通信
核心织构旨在实现 **低延迟和高吞吐量**。由于 vSAN 性能直接取决于节点间通信的速度和可靠性，核心织构是 VergeOS 系统中性能最关键的网络。
{% hint style="info" %}
**VMware 桥接**
在 VMware 中，vMotion、vSAN 复制、管理以及其他节点间流量会在 vDS 上分别拥有各自的 VMkernel 端口组，并针对不同流量类型配置 VLAN 和上行链路故障切换策略。VergeOS 核心织构通过一张带冗余的私有网状网络承载所有节点间流量——无需为不同类型规划端口组。
{% endhint %}
{% hint style="info" %}
**Nutanix 桥接**
Nutanix 的 CVM 到 CVM 底层网络需要为底层网络、CVM 和超管管理显式配置 VLAN/IP。VergeOS 核心织构是一个私有的二层网状网络，没有 IP 也没有 VLAN——节点会自动发现彼此。
{% endhint %}
## 双交换机冗余
为实现故障容错，核心织构跨越 **两张独立的物理网络** —— 称为 **核心织构 1** 以及 **核心织构 2** （或 Core 1 / Core 2）。每张织构网络都是各自独立的二层广播域。
每个节点都连接到 **计算和存储** 织构网络。如果一台交换机或一条线缆路径故障，另一张织构网络会继续保持完整的节点间连通性，vSAN 复制、热迁移或集群协调都不会中断。
{% hint style="info" %}
**Layer 2 交换机，Layer 3 由 VergeOS 处理**
你将物理核心织构交换机配置为 **仅限 Layer 2** —— 只包含广播域，不进行路由。VergeOS 会在这些 Layer 2 网络之上处理所有 Layer 3 地址分配和路由（下文所述的核心网络覆盖层）。交换机本身无需进行 Layer 3 配置。
{% endhint %}
```mermaid
graph TB
子图 "物理交换机基础设施"
SW1["交换机 A
核心织构 1
VLAN 900"]
SW2["交换机 B
核心织构 2
VLAN 901"]
end
子图 "节点 1（控制器）"
N1_CF1["网卡 1 → 核心织构 1"]
N1_CF2["网卡 2 → 核心织构 2"]
end
子图 "节点 2（控制器）"
N2_CF1["网卡 1 → 核心织构 1"]
N2_CF2["网卡 2 → 核心织构 2"]
end
子图 "节点 3（横向扩展）"
N3_CF1["网卡 1 → 核心织构 1"]
N3_CF2["网卡 2 → 核心织构 2"]
end
N1_CF1 --- SW1
N2_CF1 --- SW1
N3_CF1 --- SW1
N1_CF2 --- SW2
N2_CF2 --- SW2
N3_CF2 --- SW2
style SW1 fill:#e3f2fd,stroke:#1565c0
style SW2 fill:#e8f5e9,stroke:#2e7d32
```
### 关键设计规则
| 要求 | 详细说明 |
| --------- | ---------------------------------------------------------------------- |
| **隔离性** | 核心织构 1 和核心织构 2 必须位于各自专用的二层网络上，彼此之间以及与外部流量完全隔离 |
| **巨帧** | 所有核心织构交换机端口的 MTU 必须为 9216 或更高（9216 可容纳 9000 字节负载以及 VLAN 标签、报头和租户开销） |
| **零交换跳数** | 所有节点必须位于同一交换织构中，核心织构路径中不允许跨交换机跳转——额外跳数会引入延迟并降低 vSAN 性能 |
| **端口模式** | 接入口（不打标签，每个核心织构网络一个单独 VLAN） |
| **生成树** | 在核心织构端口上禁用（BPDU guard 禁用、portfast 禁用）——核心织构链路不应使用 STP。最好这类流量根本不要离开交换机。 |
| **速率** | 建议 10 Gbps 或更高 |
> **Playground 说明：** Terraform playground 为其虚拟核心织构网络使用 MTU 9142。生产部署应根据 VergeOS 官方文档使用 MTU 9216 或更高。
## 核心网络覆盖层
在这两张物理织构网络之上，VergeOS 会创建一个 **虚拟核心网络** —— 一个逻辑覆盖层，地址范围为 `100.96.0.0/24`。这个核心网络为每个节点提供一个稳定的内部 IP 地址，供 VergeOS 服务使用。
二者关系如下：
* **核心织构 1 和核心织构 2** 是物理层传输（Layer 2 网络）
* **核心网络（`100.96.0.0/24`)** 是覆盖在两个织构交换机之上的逻辑覆盖层
核心网络抽象了底层的双路径冗余，因此 VergeOS 服务无论当前激活的是哪条物理织构，都只需使用每个节点一个地址进行通信。
### IP 地址分配
| 网络 | 节点 1 | 节点 2 | 节点 3+ |
| ---------- | ---------- | ---------- | -------------- |
| **核心网络** | 100.96.0.2 | 100.96.0.3 | 100.96.0.(N+1) |
| **核心织构 1** | 172.16.1.1 | 172.16.1.2 | 172.16.1.N |
| **核心织构 2** | 172.16.2.1 | 172.16.2.2 | 172.16.2.N |
| **外部** | 静态（已配置） | 静态（已配置） | DHCP 或静态 |
> 安装期间的外部网络。如果先分配外部网络，VergeOS 会为核心织构分配不同的子网。 **核心网络**, `100.96.0.1` 被保留为集群网关；各节点地址从 `.2` 节点 1 开始，之后依次递增。
> 该 `172.16.1.0/24` 以及 `172.16.2.0/24` 核心织构子网是在配置核心网络时默认分配的 **之前** 外部网络在安装时分配。
```mermaid
graph TB
子图 "逻辑覆盖层"
CORE["核心网络
100.96.0.0/24
MTU 9000"]
end
子图 "物理传输层"
CF1["核心织构 1
172.16.1.0/24
MTU 9216"]
CF2["核心织构 2
172.16.2.0/24
MTU 9216"]
end
CORE -->|"承载于"| CF1
CORE -->|"承载于"| CF2
style CORE fill:#fff3e0,stroke:#e65100
style CF1 fill:#e3f2fd,stroke:#1565c0
style CF2 fill:#e8f5e9,stroke:#2e7d32
```
## 节点网络连接
典型的 VergeOS 节点有 **四个网络接口** —— 两个用于核心织构，两个用于外部：
| 网卡 | 连接 | 用途 |
| -------- | ------ | ----------------------- |
| 网卡 1 | 核心织构 1 | 所有节点间流量的主路径 |
| 网卡 2 | 核心织构 2 | 所有节点间流量的冗余路径 |
| 网卡 3 + 4 | 外部网络 | 管理 UI/API 访问、用户流量、互联网连接 |
实际的 NIC 设备名称会因硬件而异（例如， `eno1`, `enp3s0f0`, `eth0`）。安装期间，你可以选择每个角色对应的物理 NIC。
外部 NIC 通常会 **进行绑定** （LACP 或主备模式）以实现冗余。VergeOS 同时支持基于交换机的绑定（LACP）和其自身的 **基于软件的绑定** —— 无需交换机配置。两张核心织构 NIC **绝不能** 进行绑定——物理 LAG 或端口绑定会干扰织构内置的冗余机制；该机制在应用层能够检测到比 LAG 更广泛的问题（丢包、MTU 不匹配、NIC 卡死、固件缺陷）。每张核心织构 NIC 都连接到各自独立的交换机。
```mermaid
graph LR
子图 "节点"
NIC1["网卡 1
核心织构 1"]
NIC2["网卡 2
核心织构 2"]
NIC3["网卡 3
外部"]
NIC4["网卡 4
外部"]
end
NIC1 --- CF1["核心织构 1
MTU 9216+"]
NIC2 --- CF2["核心织构 2
MTU 9216+"]
NIC3 --- BOND["绑定（LACP / 主备）"]
NIC4 --- BOND
BOND --- EXT["外部网络
MTU 1500"]
CF1 -.- CORE["核心网络覆盖层"]
CF2 -.- CORE
style EXT fill:#fce4ec,stroke:#c62828
style BOND fill:#fce4ec,stroke:#c62828
style CF1 fill:#e3f2fd,stroke:#1565c0
style CF2 fill:#e8f5e9,stroke:#2e7d32
style CORE fill:#fff3e0,stroke:#e65100
```
## 外部网络与核心织构的分离
VergeOS 严格区分面向外部的流量和内部集群流量。这是两个本质上不同的网络域：
### 外部网络
* 连接到现有 LAN/WAN 基础设施
* 承载面向用户的流量：管理界面访问、虚拟机工作负载连接、互联网访问
* 除非工作负载需要巨帧，否则使用标准 MTU（1500）
* 配置为 VLAN Trunk（802.1Q 标记），以支持多个 VLAN 进行租户和工作负载隔离
* 通常进行绑定（LACP 或主备）以实现冗余
* 每个系统可以有多个外部网络（例如管理 VLAN、生产 VLAN、DMZ VLAN）
### 核心织构网络
* 完全私有——绝不会暴露给外部流量或用户
* 承载所有节点间系统流量（vSAN、迁移、协调）
* 为提高存储效率需要巨帧（MTU 9216+）
* 配置为接入口（不打标签，每个织构一个单独 VLAN）
* 始终使用两个独立织构以实现冗余
* 节点之间必须零交换机跳数，以保持低延迟
### DMZ 网络
VergeOS 会自动创建一个 **DMZ 网络** 在安装期间。DMZ 是系统中所有虚拟网络的中央连接点。每个 VergeOS 云（无论是宿主系统还是租户）都恰好有一个 DMZ 网络。
DMZ 提供 **Layer 3 路由** 在网络之间进行。每种网络类型（外部、内部、核心）都有自己的虚拟路由器：在其自身网络上一个接口，在 DMZ 上一个接口。当内部网络需要访问外部网络时，流量会经过 DMZ，并在路由边界应用网络规则和防火墙策略。
DMZ 使用 `100.64.0.0/16` 地址范围。每个虚拟网络的路由器——外部网络、内部网络、核心网络以及任何嵌套的租户云——都会在 DMZ 接口上从该子网分配一个地址：
```mermaid
graph TB
ISP / 上游路由器
外部网络路由器
Eth0: 外部 IP
Eth1/DMZ: 100.64.0.3
DMZ 网络
100.64.0.0/16
(Layer 3 路由中心)
核心网络路由器
Eth0: 100.96.0.1/24
Eth1/DMZ: 100.64.0.2
内部网络路由器
Eth0: 192.168.0.1/24
Eth1/DMZ: 100.64.0.4
租户网络
(从宿主视角)
Eth0: 100.96.0.1/24
Eth1/DMZ: 100.64.0.5
虚拟机
子图 tenant_inside["租户内部（其自身的 VDC）"]
T_EXT["租户外部路由器
Eth0: 100.96.0.2/24
Eth1/DMZ: 100.64.0.3"]
T_DMZ["租户 DMZ
100.64.0.0/16"]
T_INT["租户内部路由器
Eth0: 192.168.0.1/24
Eth1/DMZ: 100.64.0.4"]
T_VM["租户虚拟机"]
T_EXT <--> T_DMZ
T_INT <--> T_DMZ
T_INT <--> T_VM
end
ISP <--> EXT
EXT <--> DMZ
CORE <--> DMZ
INT1 <--> DMZ
TENANT <--> DMZ
INT1 <--> VM1
TENANT <--> T_EXT
style ISP fill:#fce4ec,stroke:#c62828
style EXT fill:#fce4ec,stroke:#c62828
style DMZ fill:#fff3e0,stroke:#e65100
style CORE fill:#e3f2fd,stroke:#1565c0
style INT1 fill:#e8f5e9,stroke:#2e7d32
style VM1 fill:#e8f5e9,stroke:#2e7d32
style TENANT fill:#e8eaf6,stroke:#283593
style tenant_inside fill:#e8eaf6,stroke:#283593
style T_EXT fill:#fce4ec,stroke:#c62828
style T_DMZ fill:#fff3e0,stroke:#e65100
style T_INT fill:#e8f5e9,stroke:#2e7d32
style T_VM fill:#e8f5e9,stroke:#2e7d32
```
从宿主的角度看，租户就像是连接到 DMZ 的另一张网络。租户内部拥有自己完整的网络栈——自己的 DMZ、外部路由器、内部网络和虚拟机——一个完全嵌套的虚拟数据中心。
{% hint style="info" %}
**VMware 桥接**
VergeFabric 将 VMware 分散在 vDS 端口组、NSX-T 分段和物理防火墙中的功能整合起来：核心织构取代了用于 vSAN/vMotion/管理的 VMkernel 组，外部网络取代了用于虚拟机流量的 vDS 上行链路，DMZ 网络取代了 NSX Edge 路由器/防火墙功能，内部网络则用内置的 DHCP/DNS/路由/防火墙取代了 NSX-T 分段。
{% endhint %}
{% hint style="info" %}
**Nutanix 桥接**
Nutanix 依赖标准 VLAN、用于微分段的 Flow 附加组件，以及外部设备来实现路由/防火墙。VergeOS 原生提供等效能力：核心织构取代了 CVM 底层网络（无需 VLAN 配置），外部网络取代了基于 VLAN 的上行链路，DMZ 网络负责路由/防火墙，内部网络则集成了 DHCP/DNS/路由/防火墙。
{% endhint %}
## 生产网络设计模型
在生产环境中，VergeOS 会根据每个节点的 NIC 数量和外部网络需求支持多种网络设计模型。所有模型都保持双核心织构以实现冗余。
### 4 网卡模型（推荐）
标准生产配置为每个节点使用 4 块 NIC：
| NIC | 分配 | 配置 |
| ----- | -------------- | ---------------------- |
| 网卡 1 | 核心织构 1 | 接入口，专用 VLAN，MTU 9216 |
| 网卡 2 | 核心织构 2 | 接入口，专用 VLAN，MTU 9216 |
| NIC 3 | 外部 1（bond 主接口） | Trunk 端口，LACP，MTU 1500 |
| NIC 4 | 外部 2（bond 从接口） | Trunk 端口，LACP，MTU 1500 |
这在核心织构（两条独立路径）和外部网络（绑定对）上都提供了完整冗余。
### 2 网卡模型
2 网卡模型通过 VLAN 标签将核心织构和外部流量合并到同一物理端口上：
| NIC | 分配 | 配置 |
| ---- | ---------------- | ----------------------- |
| 网卡 1 | 核心织构 1 + 外部 VLAN | 核心使用原生 VLAN，外部使用标记 VLAN |
| 网卡 2 | 核心织构 2 + 外部 VLAN | 核心使用原生 VLAN，外部使用标记 VLAN |
该模型非常适合 **100 GbE 网络端口** 在这种情况下，两条高带宽接口为核心织构和外部流量提供的吞吐量绰绰有余。它也适用于边缘站点和概念验证部署。该模型还可以使用 VergeOS 软件绑定在两个 NIC 上提供外部网络冗余，同时保持双核心织构冗余。
## Terraform Playground 如何模拟这一点
在 Terraform playground 中，核心织构被建模为宿主 VergeOS 系统上的两个 `vergeio_network` 资源：
* `core_fabric_1` — Layer 2 网络，MTU 9142，无 DHCP
* `core_fabric_2` — Layer 2 网络，MTU 9142，无 DHCP
每个节点 VM 会获得三个 NIC：
1. **网卡 1** → 外部网络（管理和用户访问）
2. **网卡 2** → 核心织构 1
3. **NIC 3** → 核心织构 2
Playground 使用 MTU 9142（而不是生产环境建议的 9216），因为宿主系统的虚拟网络基础设施会带来额外开销。核心网络覆盖层（`100.96.0.0/24`）会在两张织构网络之上承载，就像在生产环境中一样。
## 要点总结
| 概念 | 摘要 |
| ---------------- | -------------------------------------------------- |
| **核心织构** | 私有节点间网状网络——承载 vSAN、迁移、协调和控制平面流量 |
| **双重冗余** | 两张独立的织构网络（Core 1 + Core 2），位于各自独立的二层域上 |
| **MTU 要求** | 生产环境中为 9216+（playground 中为 9142）——必须使用巨帧 |
| **核心网络覆盖层** | 逻辑 `100.96.0.0/24` 运行在两台织构交换机之上的网络，提供稳定的内部 IP |
| **每个节点 3 块 NIC** | 最低要求：1 个外部 + 2 个核心织构。生产环境通常使用 4 块以上 NIC，并对外部网络进行绑定 |
| **零交换跳数** | 核心织构端口必须位于同一交换织构中——不允许跨交换机跳转 |
| **流量隔离** | 核心织构绝不会暴露给外部流量；外部网络完全独立 |
| **DMZ 网络** | 自动创建的 Layer 3 路由中心，连接系统中的所有虚拟网络 |
## 下一步
现在你已经了解 VergeOS 节点是如何互连的，下一主题将介绍这些节点如何组织成集群： [**集群与节点类型 →**](/learn-the-platform/zh/mo-kuai-1-jia-gou-ji-chu/05-clusters-nodes.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.verge.io/learn-the-platform/zh/mo-kuai-1-jia-gou-ji-chu/04-core-fabric.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.