Problèmes de mise en réseau

Une liste de tous les problèmes de dépannage et des problèmes connus qui existent dans la mise en réseau de IBM Fusion HCI.

Configuration de l'équilibreur de charge F5

Instruction d'incident
Vous pouvez utiliser un équilibreur de charge externe à la place de l'équilibreur de charge par défaut pour accéder à la base de données de l Red Hat® OpenShift® cluster après l'installation de IBM Fusion HCI.
Résolution
Vous pouvez utiliser le placement et la tolérance des noeuds pour placer des pods router-default sur les noeuds d'infrastructure de votre environnement, puis vous pouvez configurer un équilibreur de charge externe pour acheminer le trafic vers les noeuds d'infrastructure.
  1. Exécutez la commande suivante pour étiqueter les noeuds worker en tant que noeuds d'infrastructure. Utilisez les noeuds de traitement appropriés pour votre environnement.
    oc label nodes compute-1-ru5.rackd.mydomain.com node-role.kubernetes.io/infra=''
oc label nodes compute-1-ru6.rackd.mydomain.com node-role.kubernetes.io/infra=''
  2. Créez un fichier default.yaml pour placer des pods router-default sur les noeuds d'infrastructure.
    apiVersion: operator.openshift.io/v1
kind: IngressController
metadata:
  name: default
  namespace: openshift-ingress-operator
spec:
  nodePlacement:
    nodeSelector:
      matchLabels:
        node-role.kubernetes.io/infra: ""
    tolerations:
    - effect: NoSchedule
      operator: Exists
  replicas: 2
status: {}
  3. Exécutez la commande suivante pour appliquer la modification.
    oc apply -f default.yaml
  4. Exécutez la commande suivante pour vérifier que les pods router-default sont en cours d'exécution sur les noeuds d'infrastructure.
    oc -n openshift-ingress get pod -o wide
    Résultat de l'exemple :
    NOM PRET STATUT REDÉMARRAGES AGE AGE IP NOEUD NOMINÉ NOEUD PRET JALONS
router-default-6c8f978c-9bd9j 1/1 Exécution de 0 23m 172.20.240.29 compute-1-ru6.rackd.mydomain.com < none> < none>
router-default-6c8f978c-zglxz 1/1 Exécution de 0 23m 172.20.240.28 compute-1-ru5.rackd.mydomain.com < none> < none>
  5. Configurez votre équilibreur de charge externe. Pour plus d'informations, voir Configuration d'un équilibreur de charge externe.

Evénements réseau manquants émis lors de l'arrêt ou de la mise en service d'un port sur un commutateur de gestion

Instruction d'incident
Si un événement cumulusLinkDown est observé sur l'interface utilisateur de IBM Fusion HCI pour tout commutateur à grande vitesse ou de gestion, suivez les étapes mentionnées dans la section de résolution suivante.
Résolution
Effectuez les étapes de contournement suivantes:
  1. Accédez à Infrastructure > Réseau > Commutateurs .
  2. Dans le menu des points de suspension du commutateur, cliquez sur Exécuter la commande.
  3. Sélectionnez net show interface all dans la liste et cliquez sur Exécuter.
  4. Vérifiez si l'état du port est UP, DNou ADMDN.
    1. Si l'état du port est UP, le port est récupéré et est opérationnel. Dans ce scénario, l'événement n'est pas une nouvelle entrée et peut être ignoré.
    2. Si l'état du port est DN ou ADMDN, contactez le supportIBM pour vérifier le commutateur.

Indisponibilité du commutateur de gestion

Instruction d'incident
Aucun commutateur de gestion n'est disponible.
Résolution
Procédez comme suit pour vous connecter au commutateur de gestion et résoudre le problème.
  1. Exécutez la commande suivante oc pour obtenir l'adresse du commutateur correspondant IPv6 ou IPv4.
     oc get switches <switchName> -o yaml | grep switchIpadress

    Par exemple :

    Si le nom du commutateur est mgmt1-rackc, exécutez la commande suivante:
     oc get switches mgmt1-rackc -o yaml | grep switchIpadress
  2. Exécutez la commande oc suivante pour obtenir les données d'identification de connexion du commutateur à partir du secret du commutateur.
    oc get secrets <switchName>-secret -oyaml | grep defaultUserName
oc get secrets <switchName>-secret -oyaml | grep defaultUserPasswrd
    Par exemple :
     oc get secrets mgmt1-rackc-secret -oyaml | grep defaultUserName
oc get secrets mgmt1-rackc-secret -oyaml | grep defaultUserPasswrd
  3. Exécutez la commande suivante pour décoder à la fois le nom d'utilisateur et le mot de passe, obtenus à l'étape précédente.
    echo <username/password> | base64 -d
  4. Utilisez le nom d'utilisateur et le mot de passe décodés à l'étape précédente pour vous connecter au commutateur à partir de l'un des noeuds de traitement. A partir de l'interface utilisateur Red Hat OpenShift , accédez à l'un des terminaux de noeud de traitement.
    ssh `<username>@<switchIpadress>`
  5. SSH pour se connecter au commutateur et accéder à l'utilisateur root.
    sudo su
  6. Vérifiez les valeurs de ClientAliveInterval et ClientAliveCountMax dans sshd_config.
    root@mgmt1-rackc:mgmt:~$ cat  /etc/ssh/sshd_config | egrep "ClientAliveInterval|ClientAliveCountMax"
          #ClientAliveInterval 0
          #ClientAliveCountMax 3
  7. Mettez à jour le fichier /etc/ssh/sshd_config avec ClientAliveInterval à 600 et ClientAliveCountMax à 0, puis sauvegardez le fichier.
    vi /etc/ssh/sshd_config
          "Remove "#" on both lines and change the values as given below and Save the file(Press Esc to enter Command mode, and then type :wq to write and quit the file)"
          ClientAliveInterval 600
          ClientAliveCountMax 0
  8. Vérifiez que les valeurs de ClientAliveInterval et de ClientAliveCountMax sont correctement définies.
    root@mgmt1-rackc:mgmt:~$ cat  /etc/ssh/sshd_config | egrep "ClientAliveInterval|ClientAliveCountMax"
          ClientAliveInterval 600
          ClientAliveCountMax 0
          root@mgmt1-rackc:mgmt:~$
  9. Redémarrez le service sshd .
    root@mgmt1-rackc:mgmt:~$ sudo systemctl restart sshd
  10. Exécutez la commande suivante pour effacer les sessions SSH qui appartiennent à ISFUSER (la plupart des sessions SSH appartiennent à ISFUSER).
    for i in `ps -aef | grep ssh | grep ISFUSER | awk {'print $2'}`; do echo $i; kill -9 $i; done

Les commutateurs sont passés à l'état critique après la mise hors tension de TOR

Instruction d'incident
Les commutateurs sont dans un état critique car la connectivité du cluster à haute disponibilité se rompt entre les armoires.
Cause
Les commutateurs d'une armoire ne partagent pas d'adresse IP de bouclage Anycast avec la colonne vertébrale et d'autres commutateurs.
Résolution
Important: Ce problème et ses étapes de contournement ne s'appliquent qu'à un cluster à haute disponibilité.
  1. Connexion à tous les commutateurs à haut débit
  2. Exécutez la commande suivante oc pour obtenir l'adresse du commutateur correspondant IPv6 ou IPv4.
    oc get switches <switchName> -o yaml | grep switchIpadress
    Par exemple, si le nom du commutateur est hspeed1-rackc, exécutez la commande suivante:
    oc get switches hspeed1-rackc -o yaml | grep switchIpadress
  3. Exécutez la commande oc suivante pour obtenir les données d'identification de connexion du commutateur à partir du secret du commutateur.
    oc get secrets <switchName>-secret -oyaml | grep defaultUserName
oc get secrets <switchName>-secret -oyaml | grep defaultUserPasswrd
    Par exemple, si le nom du commutateur est hspeed1-rackc, exécutez la commande suivante:
    oc get secrets hspeed1-rackc-secret -oyaml | grep defaultUserName
oc get secrets hspeed1-rackc-secret -oyaml | grep defaultUserPasswrd
  4. Exécutez la commande suivante pour décoder à la fois le nom d'utilisateur et le mot de passe, obtenus à l'étape précédente.
    echo <username/password> | base64 -d
  5. Utilisez le nom d'utilisateur et le mot de passe décodés de l'étape précédente pour vous connecter au commutateur à partir de l'un des noeuds de traitement. A partir de l'interface utilisateur Red Hat OpenShift , accédez à l'un des terminaux de noeud de traitement.
    ssh `<username>@<switchIpadress>`
  6. Exécutez la commande suivante pour redémarrer le service frr sur le commutateur.
    sudo systemctl restart frr

Echec de l'ajout d'un réseau local virtuel sur une configuration d'armoire d'extension

Instruction d'incident
L'ajout d'un réseau local virtuel échoue sur une configuration d'armoire d'extension avec la combinaison d'armoires gen1 et gen2 .
Résolution
Si vous rencontrez des problèmes lors de l'ajout d'un réseau local virtuel sur une configuration d'armoire d'extension, contactez le supportIBM .

Échec de la validation des adaptateurs réseau

Instruction d'incident
La validation de la carte réseau échoue lors du remplacement d'une carte réseau.
Résolution
Pour résoudre ce problème, veillez à mettre à jour le fichier kickstart chaque fois que vous remplacez une carte réseau. Mettez également à jour le kickstart avec l'adresse MAC de la carte réseau remplacée.

Réseau d'administration dans un état critique

Instruction d'incident
Le réseau d'administration est dans un état critique, affichant une erreur sur l'interface utilisateur IBM Fusion HCI parce que les pods ne peuvent pas communiquer entre les sites.
Cause
Les pods de passerelle de sous-marin ne parviennent pas à établir une connexion après la récupération de Site1, ce qui empêche le sous-marin de se connecter avec succès.
Diagnostic
Suivez les étapes pour établir un diagnostic à l'aide de l'interface utilisateur :
  1. Connectez-vous à l'interface utilisateur site2 OpenShift Container Platform.
  2. Allez dans Administration > CustomResourceDefinitions.
  3. Recherchez MetroDR et sélectionnez MetroDR dans la liste.
  4. Allez dans l'onglet Instances et sélectionnez metrodrsite.
  5. Allez dans l'onglet YAML et cochez submarinerMonitoringCommandOutput sous metroDRSiteStatus.
  6. Vérifiez si l'erreur suivante s'affiche pour le nœud.
    control-1-ru4.rackae1.mydomain actif 0 connexions sur 1 sont établies
  7. Notez le nom du nœud.
Suivez les étapes pour établir un diagnostic à l'aide de l'interface CLI :
  1. Connectez-vous à l'interface utilisateur site2 OpenShift Container Platform.
  2. Exécutez la commande suivante.
    oc get mdr -o yaml
  3. Vérifiez submarinerMonitoringCommandOutput sous metroDRSiteStatus dans le résultat.
  4. Vérifiez si l'erreur suivante s'affiche pour le nœud.
    control-1-ru4.rackae1.mydomain actif 0 connexions sur 1 sont établies
  5. Notez le nom du nœud.
Résolution
Suivez les étapes pour résoudre le problème via l'interface utilisateur :
  1. Connectez-vous à l'interface OpenShift Container Platform l'interface utilisateur du site site2.
  2. Accéder à Workloads > Pods
  3. Sélectionnez sous-marinier-opérateur dans la liste déroulante Projet.
  4. Cliquez sur l'icône Gérer les colonnes qui se trouve à côté de la barre de recherche.
  5. Sélectionnez Nœud dans les colonnes supplémentaires.

    Les détails des pods s'affichent.

  6. Redémarrez ou supprimez le pod submariner-gateway qui se trouve sur le nom de nœud que vous avez noté dans les étapes de diagnostic.
  7. L'erreur se résout automatiquement après l'application des étapes de résolution. Si le problème persiste, contactez l'assistance IBM.
Suivez les étapes pour résoudre le problème à l'aide de l'interface CLI :
  1. Se connecter à l'interface OpenShift Container Platform l'interface utilisateur du site 2.
  2. Exécutez la commande suivante pour obtenir la liste des pods de passerelle sous-marine.
    oc get pods -o wide -n submariner-operator | grep submariner-gateway
    Résultat de l'exemple :
    submariner-gateway-jc6pt 1/1 Exécution 1 16h 172.20.102.26 control-1-ru3.rackae2.mydomain.ibm.com <none> <none>
submariner-gateway-kpqpc 1/1 Running 1 16h 172.20.102.25 control-1-ru2.rackae2.mydomain.ibm.com <none> <none>
submariner-gateway-mp7jt 1/1 Exécution 2 ( 16h ago) 16h 172.20.102.27 control-1-ru4.rackae2.mydomain.ibm.com <none> <none>
  3. Exécutez la commande suivante pour supprimer le pod de passerelle qui se trouve sur le nom de nœud que vous avez noté dans les étapes de diagnostic.
    oc delete pod <podname> -n submariner-operator
    Résultat de l'exemple :
    oc delete pod submariner-gateway-mp7jt -n submariner-operator 
pod " submariner-gateway-mp7jt " supprimé
  4. L'erreur se résout automatiquement après l'application des étapes de résolution. Si le problème persiste, contactez l'assistance IBM.