PowerFlex : Standardisation du balisage VLAN des données après la mise à niveau de PFxM et la conversion du système d’exploitation

Lors de la conversion du système d’exploitation de CentOS en SLES, il a été identifié que tout nœud construit à l’origine sous PowerFlex Manager (PFxM) 3.x à l’aide de la gestion de réseau v1, où les réseaux Data1 et Data2 étaient non balisés et connectés pour accéder aux ports de commutation VLAN, n’effectuait pas une transition correcte vers le modèle de gestion de réseau PFxM 4.x. Ces nœuds existants ont continué à s’appuyer sur des interfaces non marquées pour les réseaux de données, tandis que les nœuds plus récents ajoutés sous PFxM 4.x ont été déployés avec des interfaces utilisant le balisage VLAN pour les réseaux de données.

Lors de la conversion, PFxM 4.x a mis à jour les interfaces réseau de données sur ces nœuds hérités vers des interfaces SLES balisées VLAN, mais les ports de commutateur associés sont restés configurés en tant que ports d’accès. Cette condition entraînait l’isolement du nœud en cours de conversion des réseaux de données, ce qui empêchait l’achèvement du processus de conversion.

Cette procédure fournit une méthode claire, reproductible et prête à l’emploi pour standardiser tous les nœuds, en particulier ceux initialement construits sous la mise en réseau 3.x v1, à la conception balisée VLAN PFxM 4.x afin de garantir un fonctionnement cohérent et fiable du réseau de données.

• Cluster PowerFlex initialement déployé sous PFxM 3.x avec des réseaux Data1/Data2 non marqués (accès VLAN).
• Le cluster a ensuite été mis à niveau vers PFxM 4.x, qui s’attend à des réseaux de données balisés VLAN.
• Des nœuds supplémentaires ajoutés sous PFxM 4.x avec des réseaux de données balisés VLAN sur les ports de commutation trunk.
• La conversion du système d’exploitation de CentOS vers SLES ne conservait pas la configuration non balisée sur les nœuds tout en utilisant les ports de commutateur VLAN d’accès.

Le cluster contient une combinaison de nœuds utilisant des réseaux de données non balisés et des nœuds utilisant des réseaux de données balisés VLAN. Lorsque les nœuds déployés avec des interfaces n’utilisant pas de balises VLAN ont été mis à niveau, le paramètre d’interface a été converti pour utiliser des balises VLAN. La configuration de l’interface du port du commutateur n’a pas été convertie du mode d’accès au mode jonction. Cela a créé un mappage incorrect des VLAN de données entre l’interface du nœud et le port du commutateur. Cela provoquait l’isolement des réseaux de données pour les nœuds concernés. L’environnement a désormais besoin d’une mesure corrective contrôlée, nœud par nœud, pour normaliser le comportement du VLAN.

Le processus de conversion du système d’exploitation met à jour le balisage NIC de l’hôte, mais ne met pas à jour ou ne valide pas le mode de port de commutation, ce qui entraîne une incompatibilité entre les configurations VLAN de l’hôte et les attentes VLAN du commutateur.

Procédez comme suit pour chaque nœud concerné. Corrigez uniquement un nœud à la fois pour maintenir la redondance du cluster et éviter les reconstructions inutiles.

Vérifications préalables

• Vérifiez que le cluster est intègre (aucune reconstruction en cours, tous les SDS sont en ligne).
• Identifiez les nœuds qui utilisent encore des réseaux de données non marqués (par exemple : Adresses IP configurées directement sur p2p2/em2 sans. VLAN suffixe)
• Enregistrez l’adresse IP Data1 et l’adresse IP Data2 du nœud.
• Sauvegardez les fichiers de configuration du réseau hôte (par exemple : /etc/sysconfig/network scripts/ifcfg-*).
• Capturez la configuration actuelle du port de commutation pour les ports Data1 et Data2 du nœud pour la restauration, si nécessaire.
• Confirmez les ID de VLAN utilisés pour Data1 et Data2 (par exemple : Données1 = 152, Données 2 = 160)

Modifications du réseau et de l’hôte :

Placer le nœud en mode maintenance

Utilisez PowerFlex Manager pour placer le nœud en mode maintenance.

Vérifiez que le SDS de ce nœud est en maintenance et qu’aucune opération de reconstruction n’a démarré.

Mettez à jour les ports du commutateur à partir de l’accès à la jonction.

Sur le commutateur, mettez à jour les ports Data1 et Data2 pour ce nœud.

Convertissez les ports des commutateurs Data1 et Data2 du mode d’accès au mode Trunk.

• Assurez-vous que les VLAN de données (par exemple, 152 et 160) sont inclus dans la liste des VLAN de jonction autorisés.
• Assurez-vous que le port de commutateur approprié est identifié (par exemple, l’interface du nœud p2p2 se connecte au port du commutateur Ethernet 1/1)
• Vérifiez que la MTU est définie sur 9216 (ou sur la norme d’environnement) sur le commutateur.
• Activez spanning-tree edge trunk, bpduguard et guard root conformément à la conception.

Exemple pour les données 1 (avant) :

 Show running-config interface Ethernet 1/1
    switchport
    switchport access vlan 152
    spanning-tree port type edge
    mtu 9216

Exemple pour data1 (après) :

 Show running-config interface Ethernet 1/1
    switchport
    switchport mode trunk
    switchport trunk allowed vlan 152
    spanning-tree port type edge trunk
    spanning-tree bpduguard enable
    spanning-tree guard root
    mtu 9216

Exemple de script d’exécution permettant de modifier les paramètres du port du commutateur.

configuration terminal
 interface ethernet 1/1
    switchport mode trunk
    switchport trunk allowed vlan 152
    no switchport access vlan 152
    spanning-tree port type edge trunk
    spanning-tree bpduguard enable
    spanning-tree guard root
    end
copy running-config startup-config

Mise à jour de la configuration réseau du système d’exploitation hôte

• Sauvegardez le files.cd réseau actuel /etc/sysconfig/network-scripts/
• Modifier et renommer les fichiers d’interface réseau.
• Redémarrez le réseau.
• Valider les chemins réseau des données.

• Connectez-vous au premier nœud SDS
• Vérifier l’interface utilisée :
• Afficher les interfaces actuelles et l’adresse IP :

ip address

• Examinez les routes statiques et enregistrez-les.
• Accédez au répertoire de fichiers réseau :

cd /etc/sysconfig/network-scripts/

Passez en revue les fichiers réseau actuels :

ls -ltr

Sauvegarde du fichier réseau actuel

cp /etc/sysconfig/network-scripts/ifcfg-<devicename>  /etc/sysconfig/network-scripts/ifcfg-<devicename>.bak

Renommer le fichier réseau actuel.

mv /etc/sysconfig/network-scripts/ifcfg-<devicename> /etc/sysconfig/network-scripts/ifcfg-<devicename>.<vlan>

Exemple :

mv /etc/sysconfig/network-scripts/ifcfg-em2 /etc/sysconfig/network-scripts/ifcfg-em2.152

Modifiez le fichier réseau.

vi /etc/sysconfig/network-scripts/ifcfg-<devicename>.vlan

Exemple :

vi /etc/sysconfig/network-scripts/ifcfg-em2.152

Mettez à jour le nom de l’appareil avec <l’ID VLAN avec point>et insérez VLAN=yes

DEVICE=em2.152

VLAN=yes

Quittez et enregistrez le fichier.

:wq!

Répétez l’opération pour les autres réseaux de données

Redémarrez le réseau et validez

Redémarrez le service réseau sur l’hôte ou effectuez un redémarrage contrôlé.

Configuration des routes statiques

Exécutez ssh sur le nœud SDS.

Exécutez la commande suivante :

ip route

Assurez-vous qu’aucune route ne fait référence à des interfaces non marquées (par exemple, em2, p2p2). Toutes les routes doivent faire référence à des équivalents balisés VLAN.

Exemple 

default via 172.18.133.1 dev bond0.1352

172.18.133.0/24 dev bond0.1352 proto kernel scope link src 172.18.133.100

192.168.152.0/21 dev p2p2.152 proto kernel scope link src 192.168.152.100

192.168.160.0/21 dev em2.160 proto kernel scope link src 192.168.160.100

Validations réseau

Vérifiez que les interfaces VLAN (par exemple, p2p2.152 et em2.160) sont actives.

Exemple

 ip address

À partir de l’hôte, envoyez un ping à un homologue connu ou sur chaque VLAN à l’aide de pings provenant de l’interface.

Exemple

ping -I p2p2.152 <peer>

Facultatif : Testez un MTU de trame géante à l’aide de la commande ping avec une charge utile importante.

Exemple

ping -I p2p2.152 -s 8972 -M do <peer>

Quitter le mode maintenance

 Dans PowerFlex Manager, vérifiez le SDS et l’intégrité du périphérique sur le nœud.

 Quittez le mode maintenance pour le nœud.

 Surveillez les alertes, les redémarrages SDS ou les rabats de liaison pendant plusieurs minutes.

Répétez l’opération pour les nœuds restants

Répétez la procédure pour chaque nœud restant qui utilise toujours des réseaux de données non marqués jusqu’à ce que l’ensemble du cluster soit standardisé sur des interfaces de données balisées VLAN cohérentes avec la conception PFxM 4.x.

Plan de test de validation (résumé)

• Validation MTU : Confirmez que les interfaces VLAN utilisent MTU 9000 et que les tests Jumbo Ping réussissent sur les homologues sur Data1 et Data2.
• Validation SDS : Vérifiez que le SDS est connecté, qu’aucun redémarrage ne se produit et que les chemins d’accès aux périphériques sont alignés.
• Connectivité réseau : Vérifiez la connectivité est-ouest à plusieurs homologues sur les deux VLAN de données (ping à partir de p2p2.152 et em2.160).
• Basculement: Désactivez temporairement les interfaces Data1 et Data2 une par une pour confirmer que le SDS reste en ligne à l’aide du chemin restant, et que la redondance est restaurée après la réactivation.
• SCR/PFxM : Exécutez des bilans de santé SCR et PowerFlex Manager pour confirmer l’absence d’erreurs liées au VLAN/MTU/au réseau.

Plates-formes/versions concernées

- Nœuds PowerFlex 3.6.x/3.7.x / 3.8.x déployés à l’origine avec des
VLAN en mode accès - Conversions PFMP PowerFlex 4.x vers SLES
- Serveurs
Dell R640/R740 - Commutateurs Cisco Nexus, commutateurs basés sur Dell OS10

Problème résolu dans la version

4.6.2.1