Article 2/3 — Série déploiement SONiC sur Dell PowerSwitch S5212F-ON

Le MC-LAG est en place, les deux switches se voient. Avant d'entrer dans la configuration réseau, cet article fait un arrêt sur la baie Dell PowerStore — ce qu'elle est, ce qu'elle fait, et pourquoi elle s'intègre naturellement dans une architecture SONiC. Puis on passe au concret : câblage du cluster network PowerStore et création des VLANs iSCSI sur les switches.

La configuration des ports iSCSI data et l'intégration côté serveurs font l'objet de l'article 3.

La Dell PowerStore : présentation

Un peu d'histoire

La PowerStore est lancée par Dell Technologies en 2020, en remplacement des gammes Unity XT et SC Series. L'objectif affiché : une plateforme unifiée, NVMe native de bout en bout, capable d'adresser aussi bien les PME que les grandes entreprises sur une architecture commune. C'est un changement de paradigme par rapport aux anciennes baies — plus de disques SAS ou SATA comme tier principal, NVMe d'emblée sur l'ensemble de la gamme.

En quelques années, la PowerStore s'est imposée comme la plateforme de stockage principale de Dell Technologies pour le segment mid-range.

Architecture dual-node

La PowerStore est une appliance dual-node : les deux nodes accèdent simultanément au même pool de stockage NVMe partagé, et servent les I/O simultanément. En cas de panne d'un node, l'autre prend en charge l'intégralité du trafic de façon transparente — sans intervention manuelle, sans reconfiguration.

Les deux nodes communiquent en permanence via un lien cluster interne pour synchroniser les métadonnées, les caches et les états. C'est ce lien que nous allons câbler et configurer dans cet article.

Concrètement, les deux controllers ne se contentent pas d'être redondants l'un pour l'autre : ils exposent un pool de stockage virtualisé unique, où n'importe quel drive est accessible depuis n'importe quel controller. Deux mécanismes logiciels rendent cette architecture "autonome" :

• Dynamic Node Affinity — le chemin d'accès d'un host vers un volume est réassigné dynamiquement entre les deux controllers, en fonction de l'IOPS et de la latence en temps réel. Pas de configuration manuelle de path préféré.
• Dynamic Resiliency Engine — pas de RAID group à créer : le rebuild en cas de panne disque s'appuie sur du sparing distribué sur l'ensemble du pool, ce qui accélère la reconstruction et permet d'ajouter des drives un par un, en mixant tailles et capacités.

C'est cette architecture qui explique pourquoi le cluster network que nous câblons ci-dessous n'est pas une simple liaison de heartbeat : c'est le lien qui permet aux deux controllers de continuer à se comporter comme un seul système de stockage cohérent, quel que soit le path emprunté par un host.

Gammes et modèles

La PowerStore se décline en deux familles :

La lettre T désigne les modèles tout-flash TLC (le meilleur compromis performance/latence), la lettre Q les modèles équipés de drives QLC pour privilégier la densité et le coût au To. Pour un déploiement orienté performance et latence, la gamme T reste la cible naturelle.

Note : l'ancienne famille PowerStore X (hyperviseur ESXi embarqué) a été absorbée par la fonctionnalité AppsON, désormais disponible nativement sur les modèles T — plus besoin d'une gamme dédiée pour exécuter des VMs directement sur la baie.

Pour situer où se place la baie utilisée dans cette série par rapport au reste de la gamme :

Clustering jusqu'à quatre appliances (mix and match de modèles), et connectivité front-end couvrant FC (32/16/8 Gb), NVMe/FC, Ethernet 100/25/10 GbE en NVMe/TCP, iSCSI et File — cohérent avec le choix iSCSI 25G fait dans cette série.

Protocoles supportés

La PowerStore est une baie multiprotocole — elle peut servir simultanément différents types d'hôtes :

• Block : iSCSI, Fibre Channel (FC), NVMe/TCP, NVMe/FC
• File : NFS v3/v4, SMB v2/v3 (moteur NAS intégré)
• vVols : intégration native VMware avec VASA Provider

Dans notre série, nous utilisons iSCSI 25G — le protocole le plus accessible en termes d'infrastructure réseau, qui s'appuie sur des switches Ethernet standard comme nos S5212F-ON. Ce choix permet d'obtenir des performances très élevées tout en conservant une infrastructure Ethernet standard, sans nécessiter de fabric Fibre Channel dédiée.

Fonctionnalités clés

• Efficacité des données always-on — déduplication et compression inline activées par défaut sur tous les modèles, sans impact mesurable sur les performances grâce au NVMe.
• Snapshots et clones — snapshots natifs avec cohérence applicative (VSS pour Windows), clones block et NFS pour les environnements de test.
• Réplication — réplication asynchrone native entre baies PowerStore, et réplication Metro (synchrone, RPO zéro, actif/actif) pour les architectures bi-site.
• AppsON — possibilité d'exécuter des VMs directement sur la PowerStore (VMware ESXi embarqué). Utile pour héberger des appliances de gestion sans serveur dédié.
• PowerStore Manager — interface web unifiée pour la gestion complète de la baie : provisioning, monitoring, alertes, mises à jour firmware.

Architecture de l'environnement

Une salle, une baie PowerStore, deux switches S5212F-ON en MC-LAG. La PowerStore est une appliance dual-node — Node A et Node B — chacun équipé d'une carte 4 ports 25G SFP28.

Dans cet article, nous nous concentrons sur deux éléments :

1. Le cluster network PowerStore — lien LACP entre Node A et Node B via les deux switches en MC-LAG
2. Les VLANs iSCSI — création et propagation des deux VLANs qui porteront le trafic de stockage dans l'article 3

Le cluster network PowerStore : comprendre avant de câbler

Le cluster network est le lien vital entre Node A et Node B de la PowerStore. Il transporte en permanence :

• La synchronisation des métadonnées et des états entre les deux controllers
• Le heartbeat inter-node (détection de panne)
• Le trafic de cache coherency

Ce lien doit être opérationnel avant toute mise sous tension de la baie. Ne pas le câbler ou le câbler incorrectement provoque des alertes critiques dans PowerStore Manager et peut empêcher l'initialisation de l'appliance.

Le câblage cross-switch

La PowerStore préconfigure ses ports cluster en LACP. Le câblage imposé par Dell est cross-switch : le port cluster de Node A va sur Leaf 1 (SW-01), le port cluster de Node B va sur Leaf 2 (SW-02).

Source : Julien HOKINI — 2026

Les codes couleur du schéma :

• Bleu plein — 25G LACP PowerStore cluster link vers Leaf 1 (SW-01)
• Bleu pointillé — 25G LACP PowerStore cluster link vers Leaf 2 (SW-02)
• Rouge — 100G MC-LAG peer-link entre Leaf 1 et Leaf 2

La logique est simple : si SW-01 tombe, Node A perd son lien cluster direct — mais le trafic cluster transite via le peer-link MC-LAG vers SW-02 pour rejoindre Node B. La continuité est assurée.

[ SW-01 (Leaf 1) ] ──── MC-LAG peer-link 100G ──── [ SW-02 (Leaf 2) ]
        │                                                    │
  (cluster plein)                               (cluster pointillé)
        │                                                    │
  PowerStore Node A ──────────────────────── PowerStore Node B
        └──────────── 4-port card gauche      4-port card droite ───┘

Pourquoi un câblage cross-switch ?

Ce choix évite qu'une panne complète d'un switch n'isole un contrôleur de son homologue. Grâce au MC-LAG, le cluster network conserve un chemin actif via le peer-link, ce qui assure la continuité des échanges internes.

Plan de VLANs

Trois VLANs sont nécessaires dans cet article :

Les VLANs 100 et 200 sont créés maintenant et propagés sur les deux switches — ils seront utilisés dans l'article 3 pour les ports iSCSI data. Le VLAN 300 est le VLAN cluster, en access (untaggé) sur les ports cluster de la PowerStore.

Configuration des switches

Étape 1 — Créer les VLANs et les SVIs

On crée les trois VLANs sur les deux switches avec leurs SVIs (adresses IP utiles pour la supervision et les futurs tests de connectivité).

Sur SW-01 :

sonic-cli
configure terminal

interface Vlan 100
  description iSCSI-Fabric-A
  ip address 192.168.10.251/24
  no shutdown

interface Vlan 200
  description iSCSI-Fabric-B
  ip address 192.168.20.251/24
  no shutdown

interface Vlan 300
  description PS-Cluster
  ip address 192.168.30.251/24
  no shutdown

end
write memory

Sur SW-02 :

sonic-cli
configure terminal

interface Vlan 100
  description iSCSI-Fabric-A
  ip address 192.168.10.252/24
  no shutdown

interface Vlan 200
  description iSCSI-Fabric-B
  ip address 192.168.20.252/24
  no shutdown

interface Vlan 300
  description PS-Cluster
  ip address 192.168.30.252/24
  no shutdown

end
write memory

Étape 2 — Propager les VLANs sur le peer-link MC-LAG

Les trois VLANs doivent transiter sur le peer-link pour être disponibles sur les deux switches. Sans cette étape, un VLAN présent sur SW-01 sera inaccessible depuis SW-02 en cas de basculement.

Sur SW-01 et SW-02 (même commande) :

sonic-cli
configure terminal

interface PortChannel 100
  switchport trunk allowed vlan add 100,200,300

end
write memory

Vérification :

show vlan

Les trois VLANs doivent apparaître sur les deux switches avec leurs ports membres respectifs.

Étape 3 — PortChannel MC-LAG pour le cluster network PowerStore

Les ports cluster de la PowerStore arrivent en cross-switch — Node A vers SW-01, Node B vers SW-02. Il faut un PortChannel MC-LAG pour que la PowerStore voie un seul LAG logique côté switch.

Sur SW-01 :

sonic-cli
configure terminal

interface PortChannel 10
  description PS-Cluster-MCLAG
  switchport access vlan 300
  no shutdown
  mclag 1

interface Eth 1/1
  description PS-NodeA-Cluster
  channel-group 10
  no shutdown

end
write memory

Sur SW-02 :

sonic-cli
configure terminal

interface PortChannel 10
  description PS-Cluster-MCLAG
  switchport access vlan 300
  no shutdown
  mclag 1

interface Eth 1/1
  description PS-NodeB-Cluster
  channel-group 10
  no shutdown

end
write memory

Le mot-clé mclag 1 rattache ce PortChannel au domaine MC-LAG de l'article 1. Les deux membres physiques — un port cluster sur chaque switch — forment un seul PortChannel logique vu par la PowerStore.

Vérifications

PortChannel cluster

show interfaces PortChannel 10
show mclag

Le PortChannel 10 doit être Up avec son membre actif. Dans show mclag, il doit apparaître avec le statut Active.

VLANs sur les deux switches

show vlan

Les VLANs 100, 200 et 300 doivent apparaître sur les deux switches. Les VLANs 100 et 200 n'ont pas encore de ports membres — c'est normal, ils seront rattachés dans l'article 3.

Connectivité cluster depuis le switch

Une fois la PowerStore initialisée, vérifiez la connectivité depuis le SVI cluster :

ping 192.168.30.10 -I Vlan300

État du cluster dans PowerStore Manager

Dans Hardware → Nodes, vérifiez que les deux nodes affichent un statut Connected sur le cluster network. C'est la validation finale que le PortChannel MC-LAG est correctement négocié des deux côtés.

À ce stade, l'infrastructure réseau est prête à accueillir le trafic de stockage. Les VLANs sont propagés, le cluster network est opérationnel et la PowerStore dispose d'une connectivité redondante entre ses deux contrôleurs. Il ne reste plus qu'à configurer les interfaces iSCSI, présenter les premiers volumes et connecter les serveurs Hyper-V, ce qui sera l'objet du troisième et dernier article de cette série.

Récapitulatif des points critiques

Ce que couvre l'article 3

L'article 3 entre dans la configuration iSCSI complète : ports data de la PowerStore, adresses IP iSCSI, Jumbo Frames, configuration PowerStore Manager, et connexion des serveurs Hyper-V WSFC au fabric de stockage.

Testé en production — Enterprise SONiC 4.5.2 sur Dell PowerSwitch S5212F-ON, PowerStoreOS 4.4.