> 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/run-the-platform/zh/xi-tong-guan-li/core-fabric-status.md).

# 核心 Fabric 状态指南

## 前提条件

* 拥有节点管理权限的 VergeOS 界面访问权限
* 对……的基本了解 [VergeOS 核心网络架构](/plan-and-deploy/zh/shi-shi-zhi-nan/concepts.md#core-fabric-network)
* 用于故障排查的物理控制台或 IPMI 访问节点
* 了解你的核心 VLAN 分配（Core 1 和 Core 2）以及预期的 NIC 链路速度

## 什么是核心织构？

织构是 VergeOS 系统的骨干，使用核心网络管理所有节点间通信，包括 vSAN 流量、对等节点发现、管理操作、跨节点网络流量、虚拟机和网络迁移以及其他功能。

典型的 VergeOS 部署使用 **两个独立的物理核心网络** （“Core 1 Switch”、“Core 2 Switch”）以实现冗余。每个节点都应与集群中的每个其他节点拥有两条独立的物理路径。

{% hint style="warning" %}
**无需交换机跳数**

所有节点必须连接到同一个交换织构，并且 **不经过交换机跳转** 彼此之间的核心织构网络目标延迟小于 0.05 毫秒。增加交换机跳数会引入延迟，从而降低织构评分和集群性能。
{% endhint %}

这种核心织构冗余对于保持系统弹性和不间断运行至关重要，即使在节点或磁盘故障期间也是如此，并且允许在不停机的情况下执行维护操作。

**核心织构 MTU 要求：**

| 组件        | MTU                |
| --------- | ------------------ |
| 物理交换机端口   | >= 9216            |
| 物理 NIC    | 9192（典型）           |
| VXLAN 覆盖层 | NIC MTU 减去 50 字节开销 |

{% hint style="info" %}
**核心织构冗余如何工作**

核心织构在底层处理冗余，创建一个网状拓扑，使每个节点都与系统中的每个其他节点保持冗余路径。由于这种内置冗余，物理 LAG 或端口绑定不应 **并不** 用于核心织构网络——这样做会干扰织构自身的机制。

VergeOS 核心织构提供比传统链路聚合更全面的检测和弹性。LAG 只能检测并防护链路级故障，而 VergeOS 织构在应用层运行，能够检测更广泛的问题，包括丢包、MTU 不匹配、NIC 卡死和固件异常——除了简单的链路断开之外。
{% endhint %}

## 访问织构状态（UI）

在 VergeOS UI 中，可以在多个详细级别查看织构状态。

| 方法            | 详细级别         | 用例                        |
| ------------- | ------------ | ------------------------- |
| **告警**        | 摘要           | 日常监控——当路径退化或丢失时发出告警       |
| **节点 NIC 列表** | 每个 NIC       | 所有节点 NIC 的快速状态检查          |
| **节点仪表板**     | 每个 NIC（所选节点） | 单个 NIC 及其与其他节点连接的快速状态检查   |
| **节点诊断**      | 完整 JSON 报告   | 高级故障排查——完整的路径、评分和对等节点详细信息 |

### 告警

在日常使用中，织构状态监控可以通过用于 VergeOS 环境其余部分的同一套告警系统来处理。 **警告** 当核心网络路径上的双向通信不可用时，会触发告警。

{% hint style="success" %}
单击列表中的告警将直接跳转到受影响的节点仪表板，可在那里查看更详细的信息。
{% endhint %}

有关查看和管理告警的更多信息，请参阅 [告警指南](/run-the-platform/zh/yun-wei/alarms.md).

{% hint style="warning" %}
**立即处理核心网络告警**

核心网络告警表明你的系统可能没有完整的织构冗余。请尽快解决这些问题，以确保你的集群在发生故障时不会中断。可以配置事件触发器，通过电子邮件、短信告警系统、受监控的 Slack 频道等发送通知，确保管理员立即收到通知。另请参阅 [任务引擎产品指南](/automate-protect-and-extend/zh/zi-dong-hua/task-engine.md) ，了解有关创建自动化任务的更多信息；这 [自动化示例](/knowledge-base/zh/automation-api/automated-task-example-webhook.md) 知识库文章提供了设置事件驱动通知的示例。
{% endhint %}

### 节点 NIC 列表

这是在单个页面上快速查看所有核心网络 NIC 织构状态的方式。

1. 导航到 **基础架构** > **节点**.
2. 单击 **NIC** 左侧菜单中的。
3. 将显示来自所有节点的所有 NIC 列表。 **Fabric 状态** 列显示核心网络 NIC 的状态（例如“已确认”、“无路径”、“降级”）。对于不参与核心织构的 NIC（例如外部网络），显示“无”。 *Fabric 状态* 显示“无”

### 节点仪表板

可在每个节点仪表板上按 NIC 查看状态信息。

1. 导航到 **基础架构** > **节点**.
2. 双击所需的 **节点** ，从列表中。
3. 向下滚动到屏幕的 **NIC** 节点仪表板上的该部分。每个核心织构 NIC 都显示一个 **已确认** 状态指示器或问题状态消息（例如无路径、降级）。
4. 要查看更详细的信息，请单击右侧的地球图标。这将弹出一个窗口，显示 NIC 详细信息：
   * 供应商、型号、接口和驱动程序
   * **已确认** / **无路径** / **降级** 系统中与每个其他节点的每个连接的状态
   * **评分** 针对每个连接到其他节点的连接（参见 [评分值](#score-values) 下面）
5. 每条路径都应显示 **已确认** 状态。任何显示 **无路径** 或 **降级** 都表示存在需要调查和解决的连接问题。

### 节点诊断

更详细的织构状态信息（适用于高级故障排查）可通过节点诊断获取。这将返回所选节点所见的完整织构状态 JSON 报告，包括所有已发现的对等节点、它们的路径、评分和确认状态。

1. 导航到 **基础架构** > **节点**.
2. 选择所需的 **节点** ，从列表中。
3. 单击 **诊断** 在左侧菜单中。
4. 选择 **Fabric 配置** 从 **查询** 下拉菜单。
5. 单击 **发送** 执行。
6. 查看输出。首先要检查的关键字段： `paths[].confirmed` 和 `paths[].score` 对于每个对等节点。

#### 字段参考

以下字段会出现在织构状态 JSON 输出中。

| 字段                  | 描述                                                                      |
| ------------------- | ----------------------------------------------------------------------- |
| `$sysid`            | 标识此 VergeOS 系统的 SHA-1 哈希值（来源于 `/.system_id`)                            |
| `$last_update`      | 最近一次织构状态刷新的时间戳                                                          |
| `syncing_time`      | 顶层字段，指示节点当前是否正在与集群同步时钟。此项在节点完全加入前必须为 `否` 在节点完全加入之前。初始节点加入期间，该值为 `true`. |
| `paths`             | 到该对等节点的网络路径数组                                                           |
| `paths[].ip`        | 核心网络上远程节点的 IP 地址                                                        |
| `paths[].iface`     | 用于到达该路径的本地网络接口                                                          |
| `paths[].score`     | 数值型连接质量评分（越高越好）。最大值取决于 NIC 链路速度——参见 [评分值](#score-values) 下面。            |
| `paths[].confirmed` | 此路径是否已被验证为活动且可达（`true` / `否`)                                           |
| `vxlans`            | 为该对等节点配置的 VXLAN 隧道端点。这些是用于跨节点虚拟网络流量的覆盖隧道。                               |

#### 确认状态

| 值      | 含义                  |
| ------ | ------------------- |
| `true` | 该路径已验证——双向通信正常      |
| `否`    | 该路径无法验证——连接已丢失或从未建立 |

### 评分值

该 `评分` 此字段表示通过特定路径连接到对等节点的连接质量。最大评分对应核心 NIC 的链路速度——评分越高，表示连接越快、状态越好。

| NIC 链路速度 | 最大评分 |
| -------- | ---- |
| 100 Gbps | 200  |
| 50 Gbps  | 100  |
| 25 Gbps  | 50   |
| 10 Gbps  | 20   |

{% hint style="info" %}
**分数解读**

“完美”评分表示该值与你的 NIC 速度对应的预期最大值一致。例如，在 25Gbps NIC 上得分为 **50** 在 25Gbps NIC 上是健康的，而在 100Gbps NIC 上得分为 **50** 表示已退化。务必将评分与链路速度的最大值进行比较。
{% endhint %}

明显 **低于** 预期最大值表示已退化——可能原因包括网络延迟、丢包或路由不理想。得分为 **0** 表示双向通信完全丧失。

{% hint style="success" %}
**确认状态与评分**

*已确认* 表示路径是否可达，而 *评分* 反映该路径的质量。
{% endhint %}

## 健康与不健康织构示例

### 健康织构（2 节点系统）

所有节点可见，每个节点都有两条路径，评分均达到 NIC 速度的最大值，全部已确认：

```json
{
    "$sysid": "68e1925057aa7c6afaf9a255dcfc623794a6398e",
    "$last_update": "03/24/2026 13:31:46",
    "syncing_time": false,
    "node2": {
        "paths": [
            { "ip": "172.16.1.2", "iface": "enp148s0f0np0", "score": 200, "confirmed": true },
            { "ip": "172.16.2.2", "iface": "enp148s0f1np1", "score": 200, "confirmed": true }
        ],
        "vxlans": ["vx2 via 172.16.1.2", "vx1 via 172.16.2.2"]
    },
    "node1": {
        "paths": [
            { "ip": "172.16.1.1", "iface": "enp148s0f0np0", "score": 200, "confirmed": true },
            { "ip": "172.16.2.1", "iface": "enp148s0f1np1", "score": 200, "confirmed": true }
        ],
        "vxlans": ["vx2 via 172.16.1.1", "vx1 via 172.16.2.1"]
    }
}
```

{% hint style="success" %}
**需要关注的内容**

* 集群中的每个节点都出现在输出中（在 4 节点集群中，你应看到全部 4 个节点条目）
* 每个节点都有 **两条路径** （每个核心网络一条）
* 所有路径都显示 `"confirmed": true`
* `"syncing_time": false` 在顶层
* 评分与 NIC 速度对应的预期最大值一致（例如，100Gbps 时为 200，25Gbps 时为 50）
  {% endhint %}

### 退化的织构——冗余丢失

一个节点缺少一条路径（单个核心网络故障）：

```json
{
    "node2": {
        "paths": [
            { "ip": "172.16.1.2", "score": 200, "confirmed": true }
        ]
    }
}
```

{% hint style="warning" %}
**影响**

该节点只能通过一个核心网络访问。如果剩余路径也失败，该节点将完全失去集群连接。请立即排查。
{% endhint %}

### 退化的织构——低评分

两条路径都存在，但其中一条显示质量降低：

```json
{
    "node2": {
        "paths": [
            { "ip": "172.16.1.2", "score": 200, "confirmed": true },
            { "ip": "172.16.2.2", "score": 120, "confirmed": true }
        ]
    }
}
```

{% hint style="warning" %}
**影响**

对于你的 NIC 速度而言，低于预期最大值的评分表明该路径上的网络已退化。vSAN 性能可能受影响。检查受影响核心网络上的延迟、丢包或交换机问题。
{% endhint %}

### 严重织构——路径未确认

路径存在，但无法验证：

```json
{
    "node2": {
        "paths": [
            { "ip": "172.16.1.2", "score": 200, "confirmed": true },
            { "ip": "172.16.2.2", "score": 0, "confirmed": false }
        ]
    }
}
```

{% hint style="danger" %}
**影响**

该节点在一个核心网络上的通信已丢失。如果两条路径都显示 `"confirmed": false`，则该节点已与集群隔离，这将导致 vSAN 和工作负载中断。
{% endhint %}

### 严重织构——缺失节点

本应在集群中的节点完全未出现在织构输出中。

{% hint style="danger" %}
**影响**

缺失的节点完全无法访问。它可能已关机、两块核心 NIC 都已停用，或者位于不同的 VLAN。请立即检查物理连接和节点电源状态。
{% endhint %}

## 维护前织构验证

VergeOS 维护操作——包括 [系统更新](/run-the-platform/zh/yun-wei/sop-update.md), [vSAN 扩容](/run-the-platform/zh/yun-wei/vsan-scale-up-sop.md)，并且 [横向扩展](/run-the-platform/zh/yun-wei/sop-scale-out.md) ——都要求健康的织构作为前提。 **如果织构不健康，请不要继续维护。** 先使用下面的 [故障排除](#troubleshooting-fabric-issues) 部分解决任何问题。

健康的织构意味着：

* 输出中显示所有对等节点
* 每个对等节点都有 **两条路径** （每个核心网络一条）
* 所有路径都显示 `"confirmed": true`
* 评分与 NIC 链路速度的预期最大值一致
* `"syncing_time": false` 在顶层

{% hint style="success" %}
**快速验证**

从任意节点运行 **节点诊断** > **Fabric 配置** 并在继续维护前确认每个对等节点都满足上述条件。
{% endhint %}

## 排查织构问题

### 路径未确认

**症状：** 一条或多条路径显示 `"confirmed": false`

**常见原因和处理：**

1. **物理布线** ——确认网线在节点 NIC 和交换机端口两端都已正确插好。尝试一根已知良好的网线。
2. **交换机 VLAN 配置** ——确认交换机端口已分配到正确的核心 VLAN。核心端口应配置为 **访问端口** 并使用专用 VLAN。
3. **MTU 不匹配** ——核心织构需要巨帧（物理交换机上的最小 MTU 为 9216）。请验证端到端 MTU 一致性：
   * 交换机端口 MTU >= 9216
   * 物理 NIC MTU（例如 9192）
   * VXLAN MTU = NIC MTU 减去 50 字节开销
4. **NIC 停用** ——检查节点仪表板上的 NIC 状态。如果 NIC 显示“Down”，可能表示硬件故障或驱动问题。

### 评分下降

**症状：** 路径已确认，但评分低于 NIC 速度的预期最大值

**常见原因和处理：**

1. **网络延迟** ——所有节点必须位于同一个交换织构中，并且 **不经过交换机跳转** 彼此之间（目标延迟 <0.05 毫秒）。在核心织构路径中增加交换机跳数会引入延迟，从而显著降低集群性能和评分。
2. **交换机拥塞** ——查看交换机接口计数器中的错误、丢包或 CRC 失败。
3. **双工/速度不匹配** ——使用 **节点诊断** > **以太网工具** 验证 NIC 是否协商到了预期速度（10Gbps 以上）。

### 缺失节点

**症状：** 本应在集群中的节点未出现在织构输出中

**常见原因和处理：**

1. **节点离线** ——确认节点已通电并正在运行。如果节点无响应，请检查 IPMI。
2. **两块核心 NIC 都已停用** ——如果两个核心网络接口都停用，节点就无法参与织构发现。
3. **VLAN 隔离** ——确认缺失节点的交换机端口与其他节点位于相同的 VLAN。
4. **ybfabric 未运行** —— `ybfabric` 守护进程必须运行，节点才能参与织构发现。如果进程未运行， `vsan-watchdog` 应会自动重启它。如果节点在几分钟后仍然缺失，请联系 VergeOS 支持。

### 仅有单一路径

**症状：** 节点只显示一条路径，而不是两条

**常见原因和处理：**

1. **线缆故障** ——一条核心网络线缆可能已断开或损坏。尝试更换一根已知良好的线缆。
2. **交换机端口故障** ——某个核心网络的交换机端口可能已停用。检查交换机接口状态和日志。
3. **NIC 故障** ——两块核心 NIC 中的一块可能已故障。检查节点仪表板上的 NIC 状态。使用 **节点诊断** > **以太网工具** 以验证链路状态。

### 时间同步问题

**症状：** `"syncing_time": true` 在节点启动后持续超过 60 秒

**常见原因和处理：**

1. 节点无法连接到对等节点以同步时钟。请先排查织构连接。
2. 如果织构路径正常， `ybfabric` 守护进程可能需要通过启动脚本重启。

## 最佳实践

* **立即处理核心网络告警** ——快速解决问题以保持完整的织构冗余
* **在每次维护操作前验证织构** ——养成在更新、扩容、横向扩展和节点维护前检查织构状态的习惯
* **维护两个核心网络** ——始终保持 Core1 和 Core2 两条路径健康以实现冗余
* **物理更改后进行测试** ——在任何布线、交换机或 NIC 更改后，重新验证织构状态
* **使用“刷新织构”操作** ——在解决连接问题后，使用 **刷新织构** 按钮（或在节点列表中使用批量操作）强制更新状态
* **在诊断中包含织构状态** ——在与 VergeOS 支持合作时， `ybfabric.txt` 系统诊断中的文件包含生成诊断时的织构状态

## 相关资源

* [核心概念——核心织构网络](/plan-and-deploy/zh/shi-shi-zhi-nan/concepts.md#core-fabric-network)
* [节点概览](/run-the-platform/zh/xi-tong-guan-li/nodes-overview.md)
* [节点诊断指南](/run-the-platform/zh/xi-tong-guan-li/node-diagnostics.md)
* [系统更新 SOP](/run-the-platform/zh/yun-wei/sop-update.md)
* [vSAN 扩容 SOP](/run-the-platform/zh/yun-wei/vsan-scale-up-sop.md)
* [横向扩展 SOP](/run-the-platform/zh/yun-wei/sop-scale-out.md)
* [交换机配置指南](/plan-and-deploy/zh/shi-shi-zhi-nan/switch-configuration.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/run-the-platform/zh/xi-tong-guan-li/core-fabric-status.md?ask=<question>&goal=<endgoal>
```

`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.