Limites et problèmes connus

Vous pouvez consulter les problèmes connus, les limites de service et les solutions de contournement pour Google Cloud NetApp Volumes afin de vous aider à résoudre les erreurs liées aux opérations générales sur les volumes, à l'intégration d'Active Directory, aux clés de chiffrement gérées par le client (CMEK), à la réplication de volumes, aux volumes de grande capacité et à FlexCache.

Problèmes d'ordre général

Cette section décrit les problèmes connus courants liés à NetApp Volumes.

Problèmes de compatibilité avec les adresses IP client non-RFC 1918 (PUPI) avec le niveau de service Flex Unified

Problème : Le niveau de service Flex Unified n'est pas compatible avec les adresses IP client non-RFC 1918 (PUPI).

Raison : Cette limitation est due aux contraintes des règles de pare-feu dans le projet locataire VSA.

Solution : pour résoudre ce problème, envisagez les options suivantes :

  • Attribuer des adresses IP RFC 1918 : configurez vos clients pour qu'ils utilisent des adresses IP privées RFC 1918.

  • Utilisez un autre niveau de service : utilisez un niveau de service compatible avec les adresses IP client PUPI, par exemple Standard, Premium, Extreme ou Flex File.

  • Demander une configuration manuelle du pare-feu : comme solution de contournement temporaire, vous pouvez contacter Google Cloud Customer Care pour configurer manuellement des règles d'entrée de pare-feu pour votre plage de clients PUPI. Notez que la configuration manuelle peut nécessiter des efforts d'assistance continus. Pour continuer avec cette option, envoyez une demande d'assistance contenant les informations suivantes :

    • Votre plage d'adresses IP PUPI clientes (par exemple, 100.64.0.0/10)

    • Ports de protocole requis (NFS, SMB ou iSCSI)

    • La région cible et le nom du pool de stockage

Erreurs Not found lors de l'exécution d'opérations de sauvegarde après la création d'un volume

Problème : Si vous exécutez des opérations de sauvegarde telles que CreateBackup, RestoreVolume ou UpdateBackupConfig immédiatement après avoir créé un volume en mode ONTAP, les opérations peuvent échouer avec une erreur Not found.

Motif : Une fois que vous avez créé un volume, il peut s'écouler un court laps de temps avant que le volume et ses ressources liées à la sauvegarde ne soient entièrement disponibles pour le service de sauvegarde. Pendant cette période de propagation, le service de sauvegarde peut acheminer les requêtes de sauvegarde avant que le volume ne soit détectable, ce qui entraîne une erreur Not found.

Solution : Attendez au moins trois minutes après avoir créé le volume avant d'exécuter des opérations liées à la sauvegarde.

Les volumes Flex File ne répondent pas au ping

Pour en savoir plus sur ce problème, consultez Tester la connectivité à NetApp Volumes.

Perte de connectivité intermittente lors de l'utilisation de connexions d'accès aux services privés qui se chevauchent

Lorsque vous configurez l'accès aux services privés pour la connexion netapp.servicenetworking.goog, si la plage CIDR chevauche celle utilisée par une autre connexion d'accès aux services privés sur le même cloud privé virtuel (VPC), cela peut entraîner une perte de connectivité intermittente de la connexion d'installation du volume. Utilisez des plages qui ne se chevauchent pas pour éviter ce problème.

Perturbation possible de l'accès client aux volumes ayant fait l'objet d'une transition de Cloud Volumes Service vers NetApp Volumes lors de la mise à jour des paramètres d'un volume NFS

Problème : l'accès des clients aux volumes est interrompu lorsque vous mettez à jour des paramètres sur le volume source ou de destination d'une réplication de volume active avec un état de transfert en miroir.

Motif : La mise à jour d'un volume peut entraîner la synchronisation de sa règle d'exportation avec le volume du partenaire de réplication. Si le volume mis à jour comporte une règle d'exportation incorrecte ou manquante, les clients installés sur le volume source de production risquent de perdre l'accès, ce qui peut entraîner une panne.

Contexte : lorsqu'une réplication est dans un état de mise en miroir, NetApp Volumes synchronise automatiquement les règles d'exportation des volumes source et de destination. Cette synchronisation garantit un accès client cohérent sans intervention manuelle de l'administrateur, car toute modification de règle sur un volume est automatiquement appliquée à l'autre volume.

Dans Cloud Volumes Service (CVS), l'administrateur doit synchroniser manuellement les paramètres des volumes source et de destination. Lors de la transition du volume de CVS vers NetApp Volumes, les règles d'exportation existantes ont été transférées sans modification, ce qui peut entraîner des règles d'exportation incohérentes dans les volumes répliqués. Lorsque vous mettez à jour la règle d'exportation du volume source ou de destination dans une relation de réplication de volume, NetApp Volumes synchronise automatiquement les règles sur les deux volumes.

Volumes concernés :

Ce problème concerne les volumes qui répondent à tous les critères suivants :

  • Volumes qui se trouvent dans une réplication de volume active et dupliquée. La reprise de la réplication après son arrêt peut provoquer le problème.

  • Tous les volumes compatibles NFS qui ont une règle d'exportation.

  • Volumes pour lesquels la règle d'exportation diffère entre la source et la destination.

Solution : pour résoudre ce problème, la règle d'exportation des volumes source et de destination doit être synchronisée une fois. Procédez comme suit :

  1. Examinez et comparez les règles d'exportation des volumes source et de destination.

    • Si les règles d'exportation sont identiques, aucune action n'est requise.

    • Si les règles d'exportation sont différentes, fusionnez-les pour créer une règle d'exportation qui autorise tous les hôtes spécifiés dans les deux règles.

  2. Appliquez la règle d'exportation fusionnée au volume source. Cette règle est également appliquée automatiquement au volume de destination.

En synchronisant les règles d'exportation, vous pouvez garantir un accès cohérent et éviter d'éventuelles perturbations pour les clients.

Message d'erreur lors de l'utilisation conjointe de ressources Cloud Volumes Service (CVS) et NetApp Volumes

Vous pouvez recevoir un message d'erreur concernant l'utilisation conjointe de ressources CVS et NetApp Volumes dans un VPC, un projet ou une région. Ce problème peut se produire lorsque vous essayez de créer des ressources telles que des pools et des règles, si l'une des conditions suivantes est remplie pour le projet :

  • Le projet était auparavant utilisé pour CVS.

  • Une opération de liste de ressources CVS a été effectuée dans un projet qui ne contient aucune ressource NetApp Volumes.

Voici les messages d'erreur courants :

  • Host project and service project must be using the same service.

  • Resources from CVS and NetApp Volumes may not be used together in a single region

  • Cannot share VPC between 3P and 1P networks.

Pour résoudre ce problème, contactez l'assistance clientèle Google Cloud et demandez une réinitialisation de vos projets ou régions spécifiques afin d'utiliser exclusivement les ressources NetApp Volumes.

La création de fichiers échoue avec des erreurs No space left on device ou File too large dans un répertoire spécifique

Problème : lorsque vous tentez d'écrire, de copier ou de créer des fichiers ou des sous-répertoires sur un volume installé, l'opération échoue avec une erreur No space left on device (errno 28 / ENOSPC) ou File too large (errno 27 / EFBIG).

Cette erreur se produit même lorsque les requêtes d'espace disque côté client (telles que df -h) et la console Google Cloud indiquent que le volume dispose d'une capacité logique suffisante. L'erreur est localisée dans un répertoire spécifique. La création de fichiers réussit dans d'autres répertoires du même volume.

Cause : ce problème se produit lorsqu'un seul répertoire devient trop volumineux et atteint les limites internes, ce qui empêche le système de stockage d'indexer d'autres fichiers ou sous-répertoires à cet emplacement spécifique.

Validation :

Vérifiez si vous avez atteint les limites de taille de répertoire en effectuant les étapes de diagnostic suivantes sur un client installé :

  1. Tester la création de fichiers localisés : essayez de créer un fichier dans un répertoire complètement différent, nouvellement créé, sur le même volume : bash mkdir /mount_point/test_dir && touch /mount_point/test_dir/test_file.txt Si cette commande réussit, mais que l'écriture dans le répertoire d'origine échoue, la limite du répertoire a probablement été atteinte.

  2. Estimer le nombre d'entrées du répertoire : comptez le nombre d'entrées dans le répertoire incriminé : bash find /mount_point/offending_directory -maxdepth 1 | wc -l

  3. Inspecter la taille du fichier d'index du répertoire : vérifiez l'empreinte des métadonnées du répertoire : bash ls -ld /mount_point/offending_directory Une taille de fichier de répertoire exceptionnellement élevée indique une augmentation massive des métadonnées du répertoire.

Solution :

Pour résoudre ce problème et maintenir l'intégrité de vos structures de répertoires, appliquez les méthodes suivantes :

  • Implémenter le partitionnement de répertoires : restructurez votre application ou votre charge de travail pour répartir les fichiers dans des sous-répertoires hiérarchiques imbriqués (par exemple, /aa/bb/filename.txt au lieu de conserver un grand nombre de fichiers dans un seul répertoire plat).

  • Reconstruire les répertoires volumineux : la simple suppression de fichiers d'un répertoire qui dépasse la limite supprime leurs noms, mais ne réduit pas automatiquement la taille physique du fichier d'index du répertoire dans le système de fichiers sous-jacent. Pour récupérer complètement l'espace du répertoire, copiez ou déplacez les fichiers actifs dans un nouveau répertoire, puis supprimez l'ancien répertoire volumineux.

Problèmes d'intégration d'Active Directory

Les sections suivantes contiennent les problèmes connus liés à l'intégration d'Active Directory.

Problèmes de connectivité

Les connexions aux contrôleurs de domaine sur site échouent en raison des limitations suivantes :

  • Appairage de VPC : NetApp Volumes ne peut atteindre que les contrôleurs de domaine qui se trouvent sur le VPC du pool de stockage ou qui y sont connectés par VPN. NetApp Volumes ne peut pas atteindre les contrôleurs de domaine d'un autre VPC, y compris ceux qui sont appairés au VPC du pool de stockage et qui s'y connectent.

  • Pare-feu : la connexion sur site échoue si vous n'autorisez pas NetApp Volumes à contacter vos contrôleurs de domaine. Pour en savoir plus, consultez Règles de pare-feu pour l'accès à Active Directory.

La modification du paramètre de site Active Directory d'une règle Active Directory n'affecte pas les pools de stockage de niveau de service Flex File. Ce paramètre fonctionne pour les pools Flex Unified.

NetApp Volumes ne peut pas rejoindre les contrôleurs de domaine basés sur Windows 2025

En raison d'une régression dans Windows 2025, NetApp Volumes ne peut pas rejoindre un domaine à l'aide d'un contrôleur de domaine Windows 2025.

Le 9 septembre 2025, Microsoft a publié les mises à jour KB5065431 et KB5065426 pour résoudre ce problème. Windows 2025 n'est pas compatible avec le chiffrement RC4. Vous devez donc activer le chiffrement AES pour l'authentification Active Directory.

Pour en savoir plus, consultez La communication du contrôleur de domaine avec Windows 2025 ou des versions antérieures peut échouer en raison de l'application de SMB 3.1.1.

La communication du contrôleur de domaine avec Windows 2025 ou des versions antérieures peut échouer en raison de l'application de SMB 3.1.1

Les contrôleurs de domaine Windows 2025 appliquent SMB 3.1.1 pour la communication avec les clients Active Directory. La règle 18.6.7.6 du Center for Internet Security (CIS) recommande également d'utiliser SMB 3.1.1 pour les versions antérieures de Windows.

Bien que NetApp Volumes soit compatible avec SMB 3.1.1 pour la communication entre les clients SMB et le serveur SMB NetApp Volumes, il n'est compatible qu'avec SMB 2.1 et SMB 3.0 lors de la connexion à Active Directory en tant que client.

Si les contrôleurs de domaine n'autorisent que les connexions SMB 3.1.1, NetApp Volumes ne peut pas se connecter à Active Directory, ce qui entraîne des interruptions de service.

Pour maintenir la compatibilité, définissez SMB 2.1 comme version minimale de SMB compatible sur vos contrôleurs de domaine. Vous devez appliquer ce paramètre à tous les contrôleurs de domaine, ou à chaque contrôleur de domaine du site Active Directory si vous utilisez des règles Active Directory basées sur le site.

L'exemple suivant montre comment définir la version minimale de SMB compatible sur 2.1 :

 Set-SmbServerConfiguration -Smb2DialectMax SMB311 -Smb2DialectMin SMB210

Pour en savoir plus sur la modification des paramètres SMB à l'aide de PowerShell ou de stratégies de groupe, consultez Gérer les dialectes SMB dans Windows et Windows Server 2025.

Échec des connexions LDAP à Active Directory après les mises à jour du contrôleur de domaine Microsoft d'octobre 2026

Problème : Après avoir installé les mises à jour de sécurité Microsoft d'octobre 2026 sur vos contrôleurs de domaine Active Directory, les pools de stockage et les volumes connectés à Active Directory ne peuvent pas effectuer de liaison LDAP avec ces contrôleurs de domaine. Par conséquent, vous pouvez rencontrer des erreurs lors de la connexion à des partages SMB, de l'ajout d'utilisateurs à des partages, ou de l'utilisation ou du test d'une nouvelle règle Active Directory.

Motif : Les mises à jour de sécurité cumulatives de Microsoft suivantes modifient le comportement de la connexion LDAP, ce qui perturbe la communication avec NetApp Volumes :

NetApp suit ce problème dans le bulletin d'assistance NetApp SU628.

Solution : Pour résoudre ce problème sur vos contrôleurs de domaine, annulez les mises à jour de sécurité ou appliquez la solution de contournement de modification du registre décrite dans L'accès aux partages SMB NetApp peut échouer après l'installation de la mise à jour de sécurité Windows d'octobre 2026.

Si vous utilisez le mode Flex Unified ONTAP, vous pouvez également configurer la sécurité des sessions LDAP sur vos machines virtuelles de stockage (SVM) :

  • Avant ou après avoir appliqué un correctif à vos contrôleurs de domaine, définissez la sécurité de la session LDAP sur sign ou seal sur chaque SVM concerné. Les deux valeurs répondent à l'exigence, bien que seal fournisse un chiffrement supplémentaire pour les données de charge utile LDAP :

    vserver cifs security show -fields session-security-for-ad-ldap
vserver cifs security modify -vserver SVM_NAME -session-security-for-ad-ldap sign
vserver cifs domain discovered-servers reset-servers -vserver SVM_NAME

  • Si une configuration de client LDAP sur la SVM est liée en tant que serveur CIFS à l'aide de vserver services name-service ldap client avec -bind-as-cifs-server true, ou à un domaine Active Directory avec -bind-dn et -ad-domain configurés, définissez -session-security sur sign ou seal sur cette configuration de client :

    vserver services name-service ldap client show -vserver SVM_NAME
vserver services name-service ldap client modify -vserver SVM_NAME -client-config CONFIG_NAME -session-security sign

  • Vérifiez que l'authentification Kerberos fonctionne entre la SVM et vos contrôleurs de domaine, ce qui est requis lorsque vous utilisez sign ou seal. Vos contrôleurs de domaine doivent disposer d'enregistrements DNS de transfert (A) et inverse (PTR) pouvant être résolus. Des enregistrements PTR manquants ou incorrects peuvent entraîner l'échec de la liaison LDAP avec des erreurs GSSAPI, telles que Cannot determine realm for numeric host address ou Server not found in Kerberos database.

  • Après avoir appliqué les modifications, testez la connexion pour confirmer la connectivité LDAP :

    set -privilege diag
secd connections test -node NODE -vserver SVM_NAME

  • La mise à jour du paramètre de sécurité de la session ne nécessite pas d'identifiants de domaine ni de réinitialisation du mot de passe du compte de machine Active Directory. Comme LDAP est évalué lors des opérations de liaison et de recherche, les sessions client SMB existantes restent connectées.

  • Pour les SVM NFS uniquement qui utilisent un client LDAP lié à Active Directory, définissez également -session-security sur sign ou seal sur le client LDAP, le cas échéant, y compris dans les environnements qui utilisent LDAPS sur le port 636.

Si le problème persiste ou si vous avez besoin d'aide, contactez Google Cloud Customer Care.

Problèmes liés aux CMEK

Les sections suivantes décrivent les problèmes connus liés aux opérations de clé de chiffrement gérée par le client (CMEK).

ListKmsConfigs renvoie l'erreur Invalid value for enum type

Lorsqu'un volume migre d'un chiffrement géré par le système vers un chiffrement géré par le client, la commande ListKmsConfigs renvoie parfois une erreur Invalid value for enum type pendant la migration. Une fois la migration terminée, la commande ListKmsConfigs fonctionne à nouveau normalement.

Échec de la création de la règle KmsConfig

Il arrive que la création d'une règle KmsConfig échoue et vous empêche d'en créer une autre. Si ce problème se produit, contactez Google Cloud Customer Care.

Problèmes et limites de la réplication de volume

Les sections suivantes fournissent des détails sur les problèmes connus et les limites de la fonctionnalité de réplication de volume.

Les paramètres de quota du volume de destination peuvent échouer dans une réplication active

Lorsque vous modifiez les paramètres d'un volume dans une réplication active, les paramètres sont appliqués aux volumes source et de destination. Toutefois, les modifications de quota spécifiques aux volumes de destination sont préparées et appliquées au volume de destination une fois la réplication arrêtée. Il peut arriver que ce paramètre de quota échoue et que vous receviez un message d'erreur à la fin de l'opération. Même si l'opération Stop réussit, il est possible que tous les quotas n'aient pas été appliqués au volume de destination. Si vous recevez une erreur de quota lors d'une opération Arrêter, comparez les règles de quota sur les volumes source et de destination, puis mettez à jour les règles de quota manquantes sur la destination pour qu'elles correspondent aux paramètres du volume source.

La consoleGoogle Cloud affiche les pools de stockage sans règles Active Directory associées.

Dans la console Google Cloud , lorsque vous créez une réplication de volume pour un volume source, la liste des pools de stockage parmi lesquels choisir pour créer le volume de destination contient des pools de stockage qui n'ont pas de règle Active Directory. La sélection d'un pool de stockage sans stratégie Active Directory entraîne un échec de réplication.

Problèmes connus liés aux volumes de grande capacité

La section suivante décrit les problèmes connus de la fonctionnalité de volumes de grande capacité.

Pools incompatibles affichés

Lorsque vous modifiez le pool de stockage (niveau de service), la console Google Cloud peut afficher des pools incompatibles. Si vous essayez de passer à un pool de stockage incompatible, la tentative échoue et un message d'erreur s'affiche.

Migration CMEK non bloquée

La console Google Cloud ne bloque pas la migration CMEK lorsque des volumes de grande capacité sont présents. Toutefois, si vous essayez d'effectuer une migration CMEK lorsque des volumes de grande capacité sont configurés, la tentative échoue.

Problèmes liés à FlexCache

Cette section décrit les problèmes connus de la fonctionnalité FlexCache.

Les modifications de volume FlexCache dans la console Google Cloud peuvent échouer

Vous ne pouvez modifier les volumes FlexCache qu'à l'aide de l'API ou de la Google Cloud CLI. Bien que la console Google Cloud affiche les volumes FlexCache après leur création et vous permette de les afficher ou de les supprimer, toute tentative de mise à jour dans la console Google Cloud peut échouer. Dans ce cas, utilisez la Google Cloud CLI ou l'API pour effectuer des modifications.

Échec de la création du volume FlexCache avec snapshot-directory défini sur "true"

Les volumes FlexCache ne sont pas compatibles avec l'option snapshot-directory. Bien que l'API définisse ce paramètre sur false par défaut, Google Cloud CLI le définit sur true par défaut. Par conséquent, lorsque vous créez un volume FlexCache à l'aide de la Google Cloud CLI, vous devez inclure explicitement --snapshot-directory false pour éviter l'échec de la création.