Documentation Oracle Cloud Infrastructure

Dépannage des attachements de volume à performances très élevées

Cette rubrique présente les étapes de dépannage disponibles ainsi que les prérequis permettant de vérifier les volumes configurés avec le niveau Performances très élevées lorsque l'attachement de volume a échoué ou n'est pas à chemins d'accès multiples.

Dépannage des échecs d'attachement de volume

Le module d'extension de gestion des volumes de blocs est requis pour les volumes qui sont configurés avec le niveau Performances très élevées et attachés à l'aide d'un attachement de type iSCSI. En cas d'échec de l'attachement du volume à l'instance, le problème est probablement dû à la configuration incorrecte du module d'extension de gestion des volumes de blocs. Reportez-vous aux suggestions de dépannage présentées dans cette section pour résoudre ces problèmes.

Erreur de journal du module d'extension de gestion des volumes de blocs : erreur d'attachement de volume non autorisé ou introuvable

Si vous n'avez pas configuré correctement les droits d'accès du module d'extension de gestion des volumes de blocs, le volume ne peut pas être attaché à l'instance.

Détails

Le volume n'apparaît pas comme attaché dans la console et le message d'erreur NotAuthorizedOrNotFound apparaît dans le journal du module d'extension de gestion des volumes de blocs.

Vous trouverez le journal du module d'extension de gestion des volumes de blocs à l'emplacement suivant :

"/var/log/oracle-cloud-agent/plugins/oci-blockautoconfig/oci-blockautoconfig.log

Voici un exemple d'entrée de journal d'erreurs pour ce problème :

2021/08/13 09:14:25.864932 compute_client_command.go:255: Updating volume attachment to the state LOGIN_SUCCEEDED ...
2021/08/13 09:14:26.155473 compute_client_command.go:260: Service error:NotAuthorizedOrNotFound.
volume attachment ocid1.volumeattachment.oc1.iad.<volume-attachment_ID> not found.
http status code: 404. Opc request id: <request_ID>

Cause

Le module d'extension de gestion des volumes de blocs ne dispose pas des droits d'accès permettant d'envoyer la notification de statut de connexion iSCSI au service.

Résolution

Pour configurer les droits d'accès du module d'extension de gestion des volumes de blocs, procédez comme suit :

  1. Créez un groupe dynamique avec les règles de mise en correspondance illustrées dans l'exemple de code suivant afin d'inclure toutes les instances contenues dans les compartiments indiqués :

    ANY {instance.compartment.id = 'ocid1.tenancy.oc1..<tenancy_ID>', instance.compartment.id = 'ocid1.compartment.oc1..<compartment_OCID>'

  2. Configurez une stratégie pour le groupe dynamique : configurez une stratégie octroyant les droits d'accès requis au groupe dynamique créé à l'étape précédente afin d'autoriser l'agent d'instance à appeler le service Block Volume pour extraire la configuration d'attachement.

    Allow dynamic-group InstantAgent to use instances in tenancy
Allow dynamic-group InstantAgent to use volume-attachments in tenancy

Ressources

Erreur de journal du module d'extension de gestion des volumes de blocs : l'agent utilisateur ne peut pas être vide

L'instance de calcul doit disposer d'une adresse IP publique ou d'une passerelle de service pour pouvoir se connecter aux services Oracle. Dans le cas contraire, l'attachement du volume échoue.

Détails

Le volume n'apparaît pas comme attaché dans la console et le message d'erreur user agent can not be blank apparaît dans le journal du module d'extension de gestion des volumes de blocs.

Vous trouverez le journal du module d'extension de gestion des volumes de blocs à l'emplacement suivant :

"/var/log/oracle-cloud-agent/plugins/oci-blockautoconfig/oci-blockautoconfig.log

Voici un exemple d'entrée de journal d'erreurs pour ce problème :

2021/10/15 22:16:07.881953 compute_client_command.go:255: Updating volume attachment to the state LOGIN_SUCCEEDED ...
2021/10/15 22:16:07.882185 compute_client_command.go:260: user agent can not be blank
2021/10/15 22:16:07.882204 iscsi_commands_helper.go:302: user agent can not be blank
2021/10/15 22:16:07.882212 iscsi_commands_helper.go:310: user agent can not be blank

Cause

Le module d'extension de gestion des volumes de blocs ne peut pas envoyer la notification de statut de connexion iSCSI au service en raison de la configuration réseau.

Résolution

Si l'instance ne dispose pas d'une adresse IP publique, configurez une passerelle de service sur le réseau cloud virtuel. Une passerelle de service permet à votre instance d'accéder de façon privée à des services Oracle sans exposer les données sur le réseau Internet public. Voici des remarques spéciales concernant la configuration de la passerelle de service pour le module d'extension de gestion des volumes de blocs :

  • Lors de la création de la passerelle de service, activez le libellé de service Tous les services <region> dans Oracle Services Network.
  • Lors de la configuration du routage pour le sous-réseau qui contient l'instance, configurez une règle de routage dont le type de cible est défini sur Passerelle de service, et le service de destination sur Tous les services <region> dans Oracle Services Network.

Pour obtenir des instructions détaillées, reportez-vous à Accès aux services Oracle : passerelle de service.

Ressources

L'attachement de volume n'est pas à chemins d'accès multiples

Afin d'offrir des performances optimales lorsque vous attachez un volume configuré pour le niveau Performances très élevées, les chemins d'accès multiples doivent être activés pour l'attachement de volume. Le service Block Volume tente d'activer les chemins d'accès multiples lors de l'attachement du volume. Si toutes les conditions préalables n'ont pas été remplies, les chemins d'accès multiples ne seront pas activés pour l'attachement de volume.

Vérification de la compatibilité d'un attachement de volume et des chemins d'accès multiples

Pour vérifier si un attachement de volume est à chemins d'accès multiples, accédez à la page Détails de volume de la console et procédez comme suit :

  1. Ouvrez le menu de navigation et sélectionnez Stockage. Sous Stockage de blocs, sélectionnez Volumes de blocs.

  2. Sélectionnez le volume de blocs dont vous voulez vérifier l'attachement de volume.

  3. Sélectionnez Instances attachées dans la section Ressources.

  4. Examinez la valeur affichée dans la colonne Chemins d'accès multiples.

    • Oui : le volume est configuré pour le niveau Performances très élevées et l'attachement de volume est à chemins d'accès multiples. Aucune action supplémentaire n'est requise.

    • Non : le volume n'est pas configuré pour le niveau Performances très élevées et la fonctionnalité de chemins d'accès multiples n'a pas besoin d'être activée. Aucune action supplémentaire n'est requise.
    • Non avec une icône d'avertissement : le volume est configuré pour le niveau Performances très élevées, mais l'attachement de volume n'est pas à chemins d'accès multiples. Pour bénéficier de performances optimales, vous devez vous assurer que le volume est attaché à une forme d'instance prise en charge et que les prérequis sont configurés.

Si le volume est configuré pour le niveau Performances très élevées, mais qu'il n'est pas configuré comme requis pour la fonctionnalité de chemins d'accès multiples, la colonne Chemins d'accès multiple contient Non avec une icône d'avertissement.

Pour découvrir d'autres procédures permettant de vérifier si un volume est à chemins d'accès multipaths, y compris à l'utilisation de l'interface de ligne de commande ou l'API, reportez-vous à la section Checking If a Volume Attachment is Multipath-Enabled.

Si votre volume n'est pas configuré pour la fonctionnalité de chemins d'accès multiples, consultez les informations abordées dans cette section et résolvez les problèmes constatés.

L'instance doit reposer sur une forme de calcul prise en charge

Vous devez attacher un volume configuré pour le niveau Performances très élevées à une instance basée sur une forme prise en charge et configurée avec au moins 16 coeurs.

Formes prises en charge

Toutes les formes Bare Metal actuelles prennent en charge les attachements iSCSI à chemins d'accès multiples. Pour plus d'informations sur les caractéristiques de performances des volumes de blocs attachés aux instances Bare Metal, reportez-vous à Formes Bare Metal.

Les formes de machine virtuelle actuelles configurées pour 16 coeurs ou plus prennent en charge les attachements à chemins d'accès multiples. Pour plus d'informations sur les caractéristiques de performances des volumes attachés à des machines virtuelles, reportez-vous à Formes de machine virtuelle pour iSCSI et volumes attachés paravirtualisés.

Résolution

Si le volume n'est pas attaché à une instance avec une configuration de forme prise en charge, vous devez détacher le volume et l'associer à une instance avec une configuration de forme prise en charge.

Vous pouvez également modifier l'instance existante de façon à lui donner la configuration de forme appropriée, mais vous devez veiller à détacher et à rattacher le volume après la modification de l'instance.

Avertissement

Si l'instance comporte moins de 8 OCPU, vous risquez de voir un problème : même après avoir modifié l'instance pour qu'elle prenne en charge les attachements à chemins d'accès multiples, les chemins d'accès multiples ne sont toujours pas activés pour l'attachement de volume, même après le détachement et le réattachement du volume. Dans ce scénario, vous devez créer à nouveau l'instance à partir d'une forme prise en charge, puis attacher le volume à la nouvelle instance. Pour plus d'informations, reportez-vous à Les chemins d'accès multiples ne sont pas activés pour l'attachement de volume paravirtualisé une fois l'instance redimensionnée.

Ressources

L'image de calcul doit prendre en charge les attachements à chemins d'accès multiples

Vous devez attacher un volume configuré pour le niveau Performances très élevées à une instance exécutant une image qui prend en charge les attachements à chemins d'accès multiples. Cela inclut les images personnalisées.

Images prises en charge pour les attachements iSCSI

Seules les images de plate-forme exécutant Oracle Linux et les images personnalisées basées sur une image Oracle Linux prennent en charge les attachements à chemins d'accès multiples.

Utilisez l'une des dernières images de plate-forme Oracle Linux avec un noyau Unbreakable Enterprise Kernel (UEK) de version UEK6U1 ou supérieure.

Pour les images personnalisées, la version du noyau UEK doit également être égale ou supérieure à la version UEK6U1. La version UEK6U1 du noyau UEK est associée à la version (release) majeure 5.4.17-2036, publiée en novembre 2020. Vous devez également mettre à jour la propriété Storage.Iscsi.MultipathDeviceSupported de l'image personnalisée en remplaçant sa valeur par true, puis relancer l'instance. Pour plus d'informations, reportez-vous à Configuration des fonctionnalités d'image pour les images personnalisées

Images prises en charge pour les attachements paravirtualisés

Pour les attachements à chemins d'accès multiples, l'instance attachée doit exécuter l'une des images suivantes ou une image personnalisée basée sur l'une de ces images :

  • Oracle Linux
  • Ubuntu
  • CentOS
  • Windows
Remarque

Les attachements à chemins d'accès multiples ne sont pas pris en charge pour les instances Oracle Autonomous Linux.

Utilisez l'une des dernières images de plate-forme Oracle Linux avec un noyau Unbreakable Enterprise Kernel (UEK) de version UEK6U1 ou supérieure.

Ressources

Rattachement du volume

Si vous avez mis à jour la configuration de forme ou l'image d'une instance de façon à prendre en charge les attachements à chemins d'accès multiples, vous devez détacher le volume de l'instance, puis le rattacher à celle-ci.

Ressources

Génération d'un fichier de diagnostic pour les attachements iSCSI

Pour les attachements iSCSI, si vous avez effectué toutes les étapes décrites dans cette rubrique et que vous rencontrez toujours un problème avec l'attachement de volume, suivez les étapes décrites dans Etape 4 : génération d'un fichier de diagnostic pour l'agent Oracle Cloud afin de générer un fichier de diagnostic, puis contactez le support technique Oracle. Cette étape ne s'applique pas aux attachements paravirtualisés.

Ressources

Attachement de volume indiqué à tort comme compatible avec les chemins d'accès multiples

Dans certains scénarios, un attachement de volume apparaît comme compatible avec les chemins d'accès multiples dans la console, mais ce n'est pas le cas et le volume n'atteint pas les performances attendues pour le niveau Performances très élevées. Ce problème peut survenir lorsque vous utilisez simultanément les outils oci-utils et oci-iscsi-config pour configurer un volume.

Utilisez l'une des méthodes suivantes pour vérifier si vous rencontrez ce problème.

Option 1 : commande multipath de Linux
Utilisez la commande multipath pour vérifier si un attachement de volume est vraiment compatible avec les chemins d'accès multiples sur une instance Linux. Connectez-vous à l'instance et exécutez la commande multipath avec la balise ll, comme dans l'exemple suivant :
# multipath -ll
Si la sortie de la commande ne renvoie aucun résultat, cela confirme que l'instance n'a pas d'attachements avec chemins d'accès multiples.
Option 2 : vérification de node.startup
Vérifiez les enregistrements de noeud dans /var/lib/iscsi/nodes/{IQN} pour node.startup de la façon suivante :
#cd /var/lib/iscsi/nodes/{IQN}
#grep -Hrn 'node.startup'
Si l'un d'eux a node.startup=automatic, les chemins d'accès multiples ne sont pas activés pour l'attachement de volume. Les deux doivent afficher node.startup=manual.

Résolution

Si vous déterminez que les chemins d'accès multiples ne sont pas activés pour l'attachement, vous pouvez contourner ce problème en utilisant le fichier /etc/fstab. Mettez à jour le fichier /etc/fstab pour indiquer au service systemd d'attendre que le service multipathd soit exécuté avant de monter le système de fichiers. Pour ce faire, ajoutez x-systemd.requires=multipathd.service pour le volume. Par exemple :
UUID={$AFFECTED_VOLUME_UUID} /test ext4 defaults,_netdev,nofail,x-systemd.requires=multipathd.service 0 2

Redémarrez l'instance après avoir mis à jour le fichier /etc/fstab.

Pour plus d'informations sur le fichier /etc/fstab, reportez-vous à Options fstab traditionnelles et Options fstab pour les volumes de blocs avec des chemins de dispositif cohérents.