Skip to main content
Une version plus récente de ce produit est disponible.
La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Résolvez les problèmes de réseau, de matériel et de plateforme dans StorageGRID

PDF

${post_edited_translations.segment}

[[422-unprocessable-entity-errors]] == ${post_edited_translations.segment}

L'erreur 422 : Entité non traitable peut survenir pour différentes raisons. Consultez le message d'erreur pour déterminer la cause de votre problème.

Si vous voyez l'un des messages d'erreur listés, effectuez l'action recommandée.

Message d'erreur Cause profonde et mesures correctives 
422: Unprocessable Entity

Validation failed. Please check
the values you entered for
errors. Test connection failed.
Please verify your
configuration. Unable to
authenticate, please verify
your username and password:
LDAP Result Code 8 "Strong
Auth Required": 00002028:
LdapErr: DSID-0C090256,
comment: The server requires
binds to turn on integrity
checking if SSL\TLS are not
already active on the
connection, data 0, v3839

Ce message peut apparaître si vous sélectionnez l'option Ne pas utiliser TLS pour Transport Layer Security (TLS) lors de la configuration de la fédération d'identités à l'aide de Windows Active Directory (AD).

L'utilisation de l'option Ne pas utiliser TLS n'est pas prise en charge avec les serveurs AD qui imposent la signature LDAP. Vous devez sélectionner soit l'option Utiliser STARTTLS, soit l'option Utiliser LDAPS pour TLS.

 
422: Unprocessable Entity

Validation failed. Please check
the values you entered for
errors. Test connection failed.
Please verify your
configuration.Unable to
begin TLS, verify your
certificate and TLS
configuration: LDAP Result
Code 200 "Network Error":
TLS handshake failed
    (EOF)

${post_edited_translations.segment}

Vérifiez les algorithmes de chiffrement proposés par le système externe. Le système doit utiliser l'un des "${post_edited_translations.segment}" pour les connexions TLS sortantes, comme indiqué dans les instructions d'administration de StorageGRID.

Alerte de non-concordance MTU du réseau de grille

${post_edited_translations.segment}

À propos de cette tâche

Les différences de paramètres MTU pourraient indiquer que certains réseaux eth0, mais pas tous, sont configurés pour les trames jumbo. Un écart de taille de MTU supérieur à 1000 pourrait entraîner des problèmes de performances réseau.

Étapes

  1. L'accès SSH externe est bloqué par défaut. Si nécessaire, "autoriser temporairement l'accès".

  2. Indiquez les paramètres MTU pour eth0 sur tous les nœuds.

    • ${post_edited_translations.segment}

    • Accédez à primary Admin Node IP address/metrics/graph et saisissez la requête suivante : node_network_mtu_bytes{device="eth0"}

  3. "Modifier les paramètres MTU" si nécessaire pour vous assurer qu'ils sont identiques pour l'interface réseau Grid (eth0) sur tous les nœuds.

    • Pour les nœuds basés sur Linux et VMware, utilisez la commande suivante : /usr/sbin/change-ip.py [-h] [-n node] mtu network [network...]

      Exemple: change-ip.py -n node 1500 grid admin

      Remarque : Sur les nœuds Linux, si la valeur MTU souhaitée pour le réseau dans le conteneur dépasse la valeur déjà configurée sur l’interface d'hôte, vous devez d’abord configurer l’interface d'hôte avec la valeur MTU souhaitée, puis utiliser le change-ip.py script pour modifier la valeur MTU du réseau dans le conteneur.

      Utilisez les arguments suivants pour modifier la MTU sur les nœuds basés sur Linux ou VMware.

    ${post_edited_translations.segment} Description

    mtu

    La valeur MTU à définir. Doit être comprise entre 1280 et 9216.

    network

    Les réseaux auxquels appliquer le MTU. Incluez un ou plusieurs des types de réseau suivants :

    • grille

    • administrateur

    • ${post_edited_translations.segment}

    +

    ${post_edited_translations.segment} Description

    -h, – help

    Afficher le message d'aide et quitter.

    -n node, --node node

    Le nœud. Par défaut, il s'agit du nœud local.

  4. Si vous avez autorisé l'accès SSH externe, "bloquer l'accès" lorsque vous avez terminé la tâche.

Alerte d'erreur de réception de trame du réseau de nœuds

Les alertes d'erreur de réception de trame réseau du nœud peuvent être causées par des problèmes de connectivité entre StorageGRID et votre matériel réseau. Cette alerte est automatiquement supprimée une fois le problème sous-jacent résolu.

À propos de cette tâche

${post_edited_translations.segment}

  • La correction d'erreurs sans voie de retour (FEC) est requise et n'est pas utilisée

  • ${post_edited_translations.segment}

  • ${post_edited_translations.segment}

  • ${post_edited_translations.segment}

Étapes

  1. ${post_edited_translations.segment}

  2. ${post_edited_translations.segment}

    ${post_edited_translations.segment}
    Remarque Ces étapes s'appliquent uniquement aux alertes d'erreur de trame de réception du réseau de nœud causées par une incompatibilité FEC sur les appliances StorageGRID.

    1. ${post_edited_translations.segment}

    2. Vérifiez l'intégrité physique des câbles reliant l'appareil au commutateur.

    3. Si vous souhaitez modifier les paramètres FEC pour tenter de résoudre l'alerte, assurez-vous d'abord que l'appliance est configurée en mode Auto sur la page Link Configuration de l'installateur d'appliance StorageGRID (voir les instructions pour votre appliance :

    4. Modifiez les paramètres FEC des ports du commutateur. Les ports de l'appliance StorageGRID adapteront leurs paramètres FEC pour correspondre, si possible.

      Vous ne pouvez pas configurer les paramètres FEC sur les appliances StorageGRID. À la place, les appliances tentent de découvrir et de reproduire les paramètres FEC des ports du commutateur auxquels elles sont connectées. Si les liaisons sont forcées à des débits réseau de 25-GbE ou 100-GbE, le commutateur et la carte réseau peuvent ne pas parvenir à négocier un paramètre FEC commun. Sans paramètre FEC commun, le réseau basculera en mode "sans FEC". Lorsque le FEC n'est pas activé, les connexions sont plus sensibles aux erreurs causées par le bruit électrique.

      Remarque Les appliances StorageGRID prennent en charge Firecode (FC) et Reed Solomon (RS) FEC, ainsi que l'absence de FEC.
    ${post_edited_translations.segment}

    ${post_edited_translations.segment}

    La taille MTU configurée sur le nœud peut être inférieure à celle du port du commutateur auquel il est connecté. Si un nœud StorageGRID reçoit une trame Ethernet plus grande que sa MTU, ce qui est possible avec cette configuration, l’alerte Node network reception frame error peut être signalée. Si vous pensez que c’est le cas, modifiez soit la MTU du port du commutateur pour qu’elle corresponde à la MTU de l’interface réseau StorageGRID, soit la MTU de l’interface réseau StorageGRID pour qu’elle corresponde à celle du port du commutateur, selon vos objectifs ou exigences MTU de bout en bout.

    Remarque Pour des performances réseau optimales, tous les nœuds doivent être configurés avec des valeurs MTU similaires sur leurs interfaces Grid Network. L'alerte Grid Network MTU mismatch est déclenchée s'il existe une différence significative dans les paramètres MTU pour le Grid Network sur les nœuds individuels. Les valeurs MTU ne doivent pas obligatoirement être identiques pour tous les types de réseau. Consultez ${post_edited_translations.segment} pour plus d'informations.
    Remarque Voir aussi "Modifier le paramètre MTU".
    ${post_edited_translations.segment}

    1. Activez le FEC, s'il n'est pas déjà activé.

    2. Vérifiez que votre câblage réseau est de bonne qualité et qu'il n'est ni endommagé ni mal connecté.

    3. Si les câbles ne semblent pas être à l'origine du problème, contactez le support technique.

      Remarque ${post_edited_translations.segment}
    ${post_edited_translations.segment}

    ${post_edited_translations.segment}

    La mémoire tampon circulaire peut être saturée lorsque le système StorageGRID est surchargé et incapable de traiter les événements réseau en temps opportun.

  3. ${post_edited_translations.segment}

Erreurs de synchronisation horaire

${post_edited_translations.segment}

Si vous rencontrez des problèmes de synchronisation horaire, vérifiez que vous avez spécifié au moins quatre sources NTP externes, chacune fournissant une référence Stratum 3 ou supérieure, et que toutes les sources NTP externes fonctionnent normalement et sont accessibles par vos nœuds StorageGRID.

Remarque Lors de l'"${post_edited_translations.segment}"installation de StorageGRID en production, n'utilisez pas le service Windows Time (W32Time) sur une version de Windows antérieure à Windows Server 2016. Le service de temps sur les versions antérieures de Windows n'est pas suffisamment précis et n'est pas pris en charge par Microsoft pour une utilisation dans des environnements de haute précision, tels que StorageGRID.

Linux : Problèmes de connectivité réseau

${post_edited_translations.segment}

Clonage d'adresse MAC

Dans certains cas, les problèmes de réseau peuvent être résolus en utilisant le clonage d'adresse MAC. Si vous utilisez des hôtes virtuels, définissez la valeur de la clé de clonage d'adresse MAC sur « true » pour chacun de vos réseaux dans votre fichier de configuration de nœud. Ce paramètre fait en sorte que l'adresse MAC du conteneur StorageGRID utilise l'adresse MAC de l'hôte. Consultez les instructions pour "créer des fichiers de configuration de nœud".

Remarque Créez des interfaces réseau virtuelles distinctes destinées à être utilisées par le système d'exploitation hôte Linux. L'utilisation des mêmes interfaces réseau pour le système d'exploitation hôte Linux et le conteneur StorageGRID peut rendre le système d'exploitation hôte inaccessible si le mode promiscu n'a pas été activé sur l'hyperviseur.

Pour plus d'informations, consultez les instructions pour "activation du clonage MAC".

Mode promiscuité

Si vous ne souhaitez pas utiliser le clonage d'adresses MAC et préférez autoriser toutes les interfaces à recevoir et à transmettre des données pour des adresses MAC autres que celles attribuées par l'hyperviseur, assurez-vous que les propriétés de sécurité au niveau du commutateur virtuel et du groupe de ports sont définies sur Accepter pour le Mode promiscuité, les Changements d'adresse MAC et les Transmissions de faux. Les valeurs définies sur le commutateur virtuel peuvent être remplacées par les valeurs au niveau du groupe de ports, assurez-vous donc que les paramètres sont identiques aux deux endroits.

Pour plus d'informations sur l'utilisation du mode promiscuité, consultez les instructions pour "${post_edited_translations.segment}".

${post_edited_translations.segment}

Un nœud Linux en état orphelin indique généralement que soit le service storagegrid, soit le démon StorageGRID du nœud contrôlant le conteneur du nœud est tombé en panne de manière inattendue.

À propos de cette tâche

${post_edited_translations.segment}

  • ${post_edited_translations.segment}

  • Essayez de redémarrer le nœud.

  • Si nécessaire, utilisez les commandes du moteur de conteneur pour arrêter le conteneur de nœud existant.

  • ${post_edited_translations.segment}

Étapes

  1. Vérifiez les journaux du démon de service et du nœud orphelin pour détecter les erreurs évidentes ou les messages concernant une sortie inattendue.

  2. ${post_edited_translations.segment}

  3. Tentez de démarrer à nouveau le nœud en exécutant la commande suivante : $ sudo storagegrid node start node-name

    $ sudo storagegrid node start DC1-S1-172-16-1-172

    Si le nœud est orphelin, la réponse est

    Not starting ORPHANED node DC1-S1-172-16-1-172

  4. Depuis Linux, arrêtez le moteur de conteneur et tous les processus de contrôle storagegrid-node. Par exemple :sudo docker stop --time secondscontainer-name

    Pour seconds, saisissez le nombre de secondes pendant lesquelles vous souhaitez attendre l'arrêt du conteneur (généralement 15 minutes ou moins). Par exemple :

    sudo docker stop --time 900 storagegrid-DC1-S1-172-16-1-172

  5. Redémarrez le nœud : storagegrid node start node-name

    storagegrid node start DC1-S1-172-16-1-172

Linux : Dépanner la prise en charge d’IPv6

${post_edited_translations.segment}

À propos de cette tâche

${post_edited_translations.segment}

  1. ${post_edited_translations.segment}

  2. ${post_edited_translations.segment}

Si l'adresse IPv6 n'est pas affichée et que le nœud est installé sur un hôte Linux, suivez ces étapes pour activer la prise en charge IPv6 dans le noyau.

Étapes

  1. ${post_edited_translations.segment}

  2. Exécutez la commande suivante : sysctl net.ipv6.conf.all.disable_ipv6

    root@SG:~ # sysctl net.ipv6.conf.all.disable_ipv6

    Le résultat doit être 0.

    net.ipv6.conf.all.disable_ipv6 = 0
    Remarque Si le résultat est différent de 0, consultez la documentation de votre système d'exploitation pour modifier sysctl les paramètres. Ensuite, remplacez la valeur par 0 avant de continuer.

  3. Accédez au conteneur de nœud StorageGRID : storagegrid node enter node-name

  4. Exécutez la commande suivante : sysctl net.ipv6.conf.all.disable_ipv6

    root@DC1-S1:~ # sysctl net.ipv6.conf.all.disable_ipv6

    ${post_edited_translations.segment}

    net.ipv6.conf.all.disable_ipv6 = 1
    Remarque Si le résultat n'est pas 1, cette procédure ne s'applique pas. Contactez le support technique.

  5. Quittez le conteneur : exit

    root@DC1-S1:~ # exit

  6. En tant que superutilisateur, modifiez le fichier suivant : /var/lib/storagegrid/settings/sysctl.d/net.conf.

    sudo vi /var/lib/storagegrid/settings/sysctl.d/net.conf

  7. Recherchez les deux lignes suivantes et supprimez les balises de commentaire. Ensuite, enregistrez et fermez le fichier.

    net.ipv6.conf.all.disable_ipv6 = 0
    net.ipv6.conf.default.disable_ipv6 = 0

  8. ${post_edited_translations.segment}

    storagegrid node stop node-name
    storagegrid node start node-name