> 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/fr/administration-systeme/core-fabric-status.md). # Guide d’état du tissu central ## Prérequis * Accès à l’interface VergeOS avec des privilèges de gestion des nœuds * Compréhension de base de [l’architecture du réseau central VergeOS](/plan-and-deploy/fr/guide-de-mise-en-oeuvre/concepts.md#core-fabric-network) * Accès à la console physique ou à IPMI des nœuds (pour le dépannage) * Connaissance de vos affectations VLAN principales (Core 1 et Core 2) et de la vitesse de liaison NIC attendue ## Qu’est-ce que la fabric principale ? La fabric constitue l’épine dorsale de votre système VergeOS, en utilisant le réseau principal pour gérer toutes les communications de nœud à nœud, y compris le trafic vSAN, la découverte des pairs, les opérations de gestion, le trafic réseau inter-nœuds, les migrations de VM et de réseau, ainsi que d’autres fonctions. Un déploiement VergeOS typique utilise **deux réseaux principaux physiques indépendants** (« Core 1 Switch », « Core 2 Switch ») pour la redondance. Chaque nœud doit disposer de deux chemins physiques indépendants vers chaque autre nœud du cluster. {% hint style="warning" %} **Aucun saut de commutateur requis** Tous les nœuds doivent être connectés à la même fabric de commutation avec **zéro saut de commutateur** entre eux. La latence cible entre les nœuds sur les réseaux de la fabric principale est inférieure à 0,05 ms. L’ajout de sauts de commutateur introduit une latence qui dégrade les scores de la fabric et les performances du cluster. {% endhint %} Cette redondance de la fabric principale est essentielle pour maintenir la résilience du système et son fonctionnement ininterrompu, même en cas de panne d’un nœud ou d’un disque, et permet d’effectuer des opérations de maintenance sans interruption. **Exigences MTU de la fabric principale :** | Composant | MTU | | ---------------------------- | --------------------------------------- | | Port de commutateur physique | >= 9216 | | NIC physique | 9192 (typique) | | superposition VXLAN | MTU de la NIC moins 50 octets d’en-tête | {% hint style="info" %} **Comment fonctionne la redondance de la fabric principale** La fabric principale gère la redondance à bas niveau, en créant un maillage où chaque nœud maintient des chemins redondants vers chaque autre nœud du système. En raison de cette redondance intégrée, le LAG physique ou l’agrégation de ports ne devrait **pas** pas être utilisé sur les réseaux de la fabric principale — cela interférerait avec les mécanismes propres à la fabric. La fabric principale VergeOS offre une détection et une résilience plus complètes que l’agrégation de liens traditionnelle. Le LAG ne détecte et ne protège que contre les défaillances au niveau du lien, tandis que la fabric VergeOS fonctionne au niveau applicatif et détecte un éventail beaucoup plus large de problèmes, notamment les paquets perdus, les incohérences de MTU, les blocages de NIC et les micrologiciels défectueux — en plus des simples liens déconnectés. {% endhint %} ## Accès à l’état de la fabric (interface utilisateur) L’état de la fabric est disponible dans l’interface utilisateur VergeOS à plusieurs niveaux de détail. | Méthode | Niveau de détail | Cas d’usage | | --------------------------- | -------------------------- | ------------------------------------------------------------------------------------------- | | **Alarmes** | Résumé | Surveillance quotidienne — alertes lorsque des chemins sont dégradés ou perdus | | **Liste des NIC des nœuds** | Par NIC | Vérification rapide de l’état de toutes les NIC des nœuds | | **Tableau de bord du nœud** | Par NIC (nœud sélectionné) | Vérification rapide de l’état des NIC individuelles et de leurs connexions aux autres nœuds | | **Diagnostics des nœuds** | Rapport JSON complet | Dépannage avancé — détails complets des chemins, des scores et des pairs | ### Alarmes Au quotidien, la surveillance de l’état de la fabric peut être gérée via le même système d’alarmes que celui utilisé pour le reste de votre environnement VergeOS. Une **alerte** d’avertissement est déclenchée lorsque la communication bidirectionnelle n’est pas disponible sur un chemin du réseau principal. {% hint style="success" %} En cliquant sur une alarme dans la liste, vous accédez directement au tableau de bord du nœud affecté, où des détails supplémentaires sont disponibles. {% endhint %} Pour plus d’informations sur la consultation et la gestion des alarmes, consultez le [Guide des alarmes](/run-the-platform/fr/operations/alarms.md). {% hint style="warning" %} **Traitez immédiatement les alarmes du réseau principal** Les alarmes du réseau principal indiquent que votre système ne dispose peut-être pas de la redondance complète de la fabric. Résolvez-les rapidement afin de garantir que votre cluster puisse tolérer une panne sans interruption. Les déclencheurs d’événements peuvent être configurés pour envoyer des notifications par e-mail, par SMS via des systèmes d’alerte, via des canaux Slack surveillés, et plus encore, afin que les administrateurs soient avertis immédiatement. Consultez le [Guide produit du moteur de tâches](/automate-protect-and-extend/fr/automatisation/task-engine.md) pour plus d’informations sur la création de tâches automatisées ; cet [Exemple d’automatisation](/knowledge-base/fr/automation-api/automated-task-example-webhook.md) article de la base de connaissances fournit un exemple de configuration de notifications déclenchées par événement. {% endhint %} ### Liste des NIC des nœuds C’est un moyen rapide de consulter l’état de la fabric sur toutes les NIC du réseau principal depuis une seule page. 1. Accédez à **Infrastructure** > **Nœuds**. 2. Cliquez sur **NICs** dans le menu de gauche. 3. Une liste de toutes les NIC de tous les nœuds est affichée. Le **État du fabric** colonne affiche l’état des NIC du réseau principal (par ex. « Confirmed », « No Path », « Degraded »). Un *État du fabric* de « None » est affiché pour les NIC qui ne participent pas à la fabric principale (par ex. réseaux externes). ### Tableaux de bord des nœuds Les informations d’état sont disponibles par NIC dans chaque tableau de bord de nœud. 1. Accédez à **Infrastructure** > **Nœuds**. 2. Double-cliquez sur le **nœud** dans la liste. 3. Faites défiler jusqu’à la section **NICs** section du tableau de bord du nœud. Chaque NIC de la fabric principale affiche soit un **Confirmé** indicateur d’état, soit un message d’état de problème (par ex. No Path, Degraded). 4. Pour plus de détails, cliquez sur l’icône du globe à droite. Une fenêtre contextuelle s’affiche avec les détails de la NIC : * Fabricant, modèle, interface et pilote * **Confirmé** / **Aucun chemin** / **Dégradé** état pour chaque connexion vers chaque autre nœud du système * **Score** par connexion vers chaque autre nœud (voir [Valeurs du score](#score-values) ci-dessous) 5. Chaque chemin doit afficher **Confirmé** l’état. Tout chemin affichant **Aucun chemin** ou **Dégradé** indique un problème de connectivité qui doit être étudié et résolu. ### Diagnostics des nœuds Des détails plus complets sur l’état de la fabric (utiles pour le dépannage avancé) sont disponibles via les diagnostics du nœud. Cela renvoie un rapport JSON complet de l’état de la fabric tel qu’il est vu par le nœud sélectionné, y compris tous les pairs découverts, leurs chemins, scores et état de confirmation. 1. Accédez à **Infrastructure** > **Nœuds**. 2. Sélectionnez le **nœud** dans la liste. 3. Cliquez sur **Diagnostics** dans le menu de gauche. 4. Sélectionnez **Configuration de la fabric** dans la **Requête** menu déroulant. 5. Cliquez sur **Envoyer** pour l’exécuter. 6. Examinez la sortie. Champs clés à vérifier en premier : `paths[].confirmed` et `paths[].score` pour chaque nœud pair. #### Référence des champs Les champs suivants apparaissent dans la sortie JSON de l’état de la fabric. | Champ | Description | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `$sysid` | Hachage SHA-1 identifiant ce système VergeOS (provenant de `/.system_id`) | | `$last_update` | Horodatage de la dernière actualisation de l’état de la fabric | | `syncing_time` | Champ de niveau supérieur indiquant si le nœud synchronise actuellement son horloge avec le cluster. Cela doit être `faux` avant que le nœud ne rejoigne complètement le cluster. Lors de la jonction initiale d’un nœud, il est normal que la valeur soit `true`. | | `paths` | Tableau des chemins réseau vers ce nœud pair | | `paths[].ip` | Adresse IP du nœud distant sur le réseau principal | | `paths[].iface` | Interface réseau locale utilisée pour atteindre ce chemin | | `paths[].score` | Score numérique de qualité de connectivité (plus le score est élevé, mieux c’est). Le maximum dépend de la vitesse de liaison de la NIC — voir [Valeurs du score](#score-values) ci-dessous. | | `paths[].confirmed` | Si ce chemin a été vérifié comme actif et joignable (`true` / `faux`) | | `vxlans` | Points de terminaison de tunnel VXLAN programmés pour ce pair. Ce sont les tunnels de superposition utilisés pour le trafic des réseaux virtuels inter-nœuds. | #### État de confirmation | Valeur | Signification | | ------ | ---------------------------------------------------------------------------------------- | | `true` | Le chemin a été vérifié — la communication bidirectionnelle fonctionne | | `faux` | Le chemin n’a pas pu être vérifié — la connectivité est perdue ou n’a jamais été établie | ### Valeurs du score Le `score` le champ représente la qualité de la connexion à un nœud pair via un chemin spécifique. Le score maximal correspond à la vitesse de liaison de la NIC principale — un score plus élevé indique une connexion plus rapide et plus saine. | Vitesse de liaison NIC | Score maximum | | ---------------------- | ------------- | | 100 Gbit/s | 200 | | 50 Gbit/s | 100 | | 25 Gbit/s | 50 | | 10 Gbit/s | 20 | {% hint style="info" %} **Interprétation des scores** Un score « parfait » signifie que la valeur correspond au maximum attendu pour la vitesse de votre NIC. Par exemple, un score de **50** sur une NIC 25 Gbit/s est sain, tandis qu’un score de **50** sur une NIC 100 Gbit/s indique une dégradation. Comparez toujours le score au maximum de votre vitesse de liaison. {% endhint %} Un score nettement **inférieur à** le maximum attendu indique une dégradation — les causes possibles incluent la latence réseau, la perte de paquets ou un routage sous-optimal. Un score de **0** indique une perte complète de la communication bidirectionnelle. {% hint style="success" %} **Confirmé vs score** *confirmé* indique si le chemin est joignable, tandis que *score* reflète la qualité de ce chemin. {% endhint %} ## Exemples de fabric saine et non saine ### Fabric saine (système à 2 nœuds) Tous les nœuds sont visibles, deux chemins chacun, scores au maximum pour la vitesse de la NIC, tous confirmés : ```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" %} **Ce qu’il faut rechercher** * Chaque nœud du cluster apparaît dans la sortie (dans un cluster à 4 nœuds, vous devez voir les 4 entrées de nœud) * Chaque nœud a **deux chemins** (un par réseau principal) * Tous les chemins affichent `"confirmed": true` * `"syncing_time": false` au niveau supérieur * Les scores correspondent au maximum attendu pour la vitesse de votre NIC (par ex. 200 pour 100 Gbit/s, 50 pour 25 Gbit/s) {% endhint %} ### Fabric dégradée — redondance perdue Un chemin manquant pour un nœud (panne d’un seul réseau principal) : ```json { "node2": { "paths": [ { "ip": "172.16.1.2", "score": 200, "confirmed": true } ] } } ``` {% hint style="warning" %} **Impact** Le nœud n’est joignable que par un seul réseau principal. Si le chemin restant tombe en panne, le nœud perdra totalement la connectivité au cluster. À investiguer immédiatement. {% endhint %} ### Fabric dégradée — score faible Les deux chemins sont présents mais l’un affiche une qualité réduite : ```json { "node2": { "paths": [ { "ip": "172.16.1.2", "score": 200, "confirmed": true }, { "ip": "172.16.2.2", "score": 120, "confirmed": true } ] } } ``` {% hint style="warning" %} **Impact** Un score inférieur au maximum attendu pour la vitesse de votre NIC indique une dégradation du réseau sur ce chemin. Les performances vSAN peuvent être affectées. Vérifiez la latence, la perte de paquets ou les problèmes de commutateur sur le réseau principal concerné. {% endhint %} ### Fabric critique — chemin non confirmé Un chemin existe mais ne peut pas être vérifié : ```json { "node2": { "paths": [ { "ip": "172.16.1.2", "score": 200, "confirmed": true }, { "ip": "172.16.2.2", "score": 0, "confirmed": false } ] } } ``` {% hint style="danger" %} **Impact** Le nœud a perdu la communication sur un réseau principal. Si les deux chemins affichent `"confirmed": false`, le nœud est isolé du cluster, ce qui provoquera une perturbation de vSAN et des charges de travail. {% endhint %} ### Fabric critique — nœud manquant Un nœud qui devrait se trouver dans le cluster n’apparaît pas du tout dans la sortie de la fabric. {% hint style="danger" %} **Impact** Le nœud manquant est totalement injoignable. Il peut être hors tension, avoir ses deux NIC principales hors service, ou se trouver sur un VLAN différent. Vérifiez immédiatement la connectivité physique et l’état d’alimentation du nœud. {% endhint %} ## Vérification de la fabric avant maintenance Les opérations de maintenance VergeOS — y compris [les mises à jour du système](/run-the-platform/fr/operations/sop-update.md), [les montées en charge vSAN](/run-the-platform/fr/operations/vsan-scale-up-sop.md), et [les extensions horizontales](/run-the-platform/fr/operations/sop-scale-out.md) — nécessitent une fabric saine comme prérequis. **N’engagez pas de maintenance si la fabric n’est pas saine.** Résolvez d’abord tout problème à l’aide de la [Dépannage](#troubleshooting-fabric-issues) section ci-dessous. Une fabric saine signifie : * Tous les nœuds pairs sont visibles dans la sortie * Chaque pair a **deux chemins** (un par réseau principal) * Tous les chemins affichent `"confirmed": true` * Les scores correspondent au maximum attendu pour la vitesse de liaison de votre NIC * `"syncing_time": false` au niveau supérieur {% hint style="success" %} **Vérification rapide** Depuis n’importe quel nœud, exécutez **Diagnostics des nœuds** > **Configuration de la fabric** et confirmez que chaque pair répond aux critères ci-dessus avant de poursuivre la maintenance. {% endhint %} ## Dépannage des problèmes de fabric ### Chemin non confirmé **Symptômes :** Un ou plusieurs chemins affichent `"confirmed": false` **Causes et actions courantes :** 1. **Câblage physique** — Vérifiez que le câble est correctement enfiché à la fois sur la NIC du nœud et sur le port du commutateur. Essayez un câble reconnu comme fonctionnel. 2. **Configuration VLAN du commutateur** — Vérifiez que le port du commutateur est attribué au bon VLAN principal. Les ports principaux doivent être configurés en tant que **ports d’accès** sur un VLAN dédié. 3. **Incompatibilité de MTU** — La fabric principale nécessite des jumbo frames (MTU minimum 9216 sur le commutateur physique). Vérifiez la cohérence de l’MTU de bout en bout : * MTU du port du commutateur >= 9216 * MTU de la NIC physique (par ex. 9192) * MTU VXLAN = MTU de la NIC moins 50 octets d’en-tête 4. **NIC hors service** — Vérifiez l’état de la NIC sur le tableau de bord du nœud. Si la NIC affiche « Down », cela peut indiquer une panne matérielle ou un problème de pilote. ### Dégradation du score **Symptômes :** Les chemins sont confirmés mais le score est inférieur au maximum attendu pour la vitesse de votre NIC **Causes et actions courantes :** 1. **Latence réseau** — Tous les nœuds doivent être sur la même fabric de commutation avec **zéro saut de commutateur** entre eux (latence cible <0,05 ms). L’ajout de sauts de commutateur dans le chemin de la fabric principale introduit une latence qui peut dégrader considérablement les performances du cluster et les scores. 2. **Congestion du commutateur** — Examinez les compteurs des interfaces du commutateur pour détecter des erreurs, des pertes ou des échecs CRC. 3. **Incompatibilité duplex/vitesse** — Utilisez **Diagnostics des nœuds** > **l’outil Ethernet** pour vérifier que la NIC négocie à la vitesse attendue (10 Gbit/s et plus). ### Nœuds manquants **Symptômes :** Un nœud qui devrait être dans le cluster n’apparaît pas dans la sortie de la fabric **Causes et actions courantes :** 1. **Nœud hors ligne** — Vérifiez que le nœud est sous tension et en cours d’exécution. Vérifiez IPMI si le nœud ne répond pas. 2. **Les deux NIC principales sont hors service** — Si les deux interfaces du réseau principal sont hors service, le nœud ne peut pas participer à la découverte de la fabric. 3. **Isolement VLAN** — Vérifiez que les ports du commutateur du nœud manquant se trouvent sur les mêmes VLAN que les autres nœuds. 4. **ybfabric non exécuté** — Le `ybfabric` démon doit être en cours d’exécution pour qu’un nœud participe à la découverte de la fabric. Si le processus n’est pas en cours d’exécution, le `vsan-watchdog` devrait le redémarrer automatiquement. Si le nœud reste manquant après plusieurs minutes, contactez le support VergeOS. ### Un seul chemin **Symptômes :** Les nœuds n’affichent qu’un seul chemin au lieu de deux **Causes et actions courantes :** 1. **Panne de câble** — Un câble du réseau principal peut être déconnecté ou endommagé. Essayez un câble reconnu comme fonctionnel. 2. **Panne du port du commutateur** — Le port du commutateur d’un réseau principal peut être hors service. Vérifiez l’état et les journaux de l’interface du commutateur. 3. **Panne de NIC** — L’une des deux NIC principales a peut-être été défaillante. Vérifiez l’état de la NIC sur le tableau de bord du nœud. Utilisez **Diagnostics des nœuds** > **l’outil Ethernet** pour vérifier l’état de la liaison. ### Problèmes de synchronisation horaire **Symptômes :** `"syncing_time": true` persiste plus de 60 secondes après le démarrage du nœud **Causes et actions courantes :** 1. Le nœud ne peut pas joindre ses pairs pour synchroniser son horloge. Vérifiez d’abord la connectivité de la fabric. 2. Si les chemins de la fabric sont sains, le `ybfabric` démon devra peut-être être redémarré via le script de démarrage. ## Bonnes pratiques * **Traitez immédiatement les alarmes du réseau principal** — Résolvez rapidement les problèmes pour maintenir la redondance complète de la fabric * **Vérifiez la fabric avant chaque opération de maintenance** — Prenez l’habitude de vérifier l’état de la fabric avant les mises à jour, les montées en charge, les extensions horizontales et la maintenance des nœuds * **Maintenez deux réseaux principaux** — Conservez toujours des chemins Core1 et Core2 sains pour assurer la redondance * **Testez après des modifications physiques** — Après toute modification de câblage, de commutateur ou de NIC, revalidez l’état de la fabric * **Utilisez l’action Refresh Fabric** — Après avoir résolu un problème de connectivité, utilisez le **Refresh Fabric** bouton du tableau de bord du nœud (ou l’action par lot depuis la liste des nœuds) pour forcer une mise à jour de l’état * **Incluez l’état de la fabric dans les diagnostics** — Lorsque vous travaillez avec le support VergeOS, le `ybfabric.txt` fichier dans les diagnostics système contient l’état de la fabric au moment où le diagnostic a été généré ## Ressources associées * [Concepts de base — réseau de la fabric principale](/plan-and-deploy/fr/guide-de-mise-en-oeuvre/concepts.md#core-fabric-network) * [Vue d’ensemble des nœuds](/run-the-platform/fr/administration-systeme/nodes-overview.md) * [Guide de diagnostic des nœuds](/run-the-platform/fr/administration-systeme/node-diagnostics.md) * [SOP de mise à jour du système](/run-the-platform/fr/operations/sop-update.md) * [SOP de montée en charge vSAN](/run-the-platform/fr/operations/vsan-scale-up-sop.md) * [SOP d’extension horizontale](/run-the-platform/fr/operations/sop-scale-out.md) * [Guide de configuration du commutateur](/plan-and-deploy/fr/guide-de-mise-en-oeuvre/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/fr/administration-systeme/core-fabric-status.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.