Résoudre les problèmes liés à Vertex AI Workbench

Cette page décrit les étapes de dépannage qui vous aideront si vous rencontrez des problèmes lors de l'utilisation de Vertex AI Workbench.

Consultez également la page Résoudre les problèmes liés à Vertex AI pour obtenir de l'aide sur l'utilisation d'autres composants de Vertex AI.

Cliquez sur l'une des catégories ci-après pour filtrer le contenu de cette page :

Instances Vertex AI Workbench

Cette section décrit les étapes de dépannage pour les instances Vertex AI Workbench.

Se connecter à JupyterLab et l'ouvrir

Cette section décrit les étapes de dépannage pour la connexion et l'ouverture de JupyterLab.

S'il ne se passe rien après avoir cliqué sur "Ouvrir JupyterLab"

Problème

Lorsque vous cliquez sur Ouvrir JupyterLab, rien ne se passe.

Solution

Vérifiez que votre navigateur ne bloque pas l'ouverture automatique de nouveaux onglets. JupyterLab s'ouvre dans un nouvel onglet du navigateur.

Impossible d'accéder au terminal dans une instance Vertex AI Workbench

Problème

Si vous ne parvenez pas à accéder au terminal ou si vous ne trouvez pas la fenêtre de terminal dans le lanceur, il se peut que l'accès au terminal ne soit pas activé pour votre instance Vertex AI Workbench.

Solution

Vous devez créer une instance Vertex AI Workbench avec l'option Accès au terminal activée. Cette option ne peut plus être modifiée après la création de l'instance.

Erreur 502 lors de l'ouverture de JupyterLab

Problème

Une erreur 502 peut indiquer que votre instance Vertex AI Workbench n'est pas encore prête.

Solution

Attendez quelques minutes, actualisez l'onglet du navigateur de la console Google Cloud, puis réessayez.

Le notebook ne répond pas

Problème

Votre instance Vertex AI Workbench n'exécute pas de cellules ou semble être figée.

Solution

Essayez d'abord de redémarrer le noyau en cliquant sur Noyau dans le menu supérieur, puis sur Redémarrer le noyau. Si cela ne fonctionne pas, vous pouvez essayer les solutions suivantes :

Actualisez la page du navigateur JupyterLab. Une sortie de cellule non enregistrée n'est pas conservée. Vous devez donc exécuter à nouveau ces cellules pour générer à nouveau la sortie.
Réinitialisez votre instance.

Impossible de se connecter à l'instance Vertex AI Workbench via SSH

Problème

Vous ne parvenez pas à vous connecter à votre instance à l'aide de SSH via une fenêtre de terminal.

Les instances Vertex AI Workbench utilisent OS Login pour activer l'accès SSH. Lorsque vous créez une instance, Vertex AI Workbench active OS Login par défaut en définissant la clé de métadonnées enable-oslogin sur TRUE. Si vous ne parvenez pas à vous connecter en SSH à votre instance, il est possible que cette clé de métadonnées doive être définie sur TRUE.

Solution

Il n'est pas possible de se connecter à une instance Vertex AI Workbench à l'aide de la console Google Cloud. Si vous ne parvenez pas à vous connecter à votre instance à l'aide de SSH via une fenêtre de terminal, consultez les articles suivants :

Pour définir la clé de métadonnéesenable-oslogin sur TRUE, utilisez la méthode projects.locations.instances.patch dans l'API Notebooks ou la commande gcloud workbench instances update dans le SDK Google Cloud.

Le quota de GPU a été dépassé

Problème

Vous ne pouvez pas créer d'instance Vertex AI Workbench avec des GPU.

Solution

Pour déterminer le nombre de GPU disponibles dans votre projet, accédez à la page Quotas. Si les GPU ne figurent pas sur la page "Quotas" ou que vous avez besoin d'un quota de GPU supplémentaire, demandez une augmentation de quota. Consultez la section Demander une limite de quota supérieure.

Créer des instances Vertex AI Workbench

Cette section explique comment résoudre les problèmes liés à la création d'instances Vertex AI Workbench.

L'instance reste en attente indéfiniment ou est bloquée en état de provisionnement

Problème

Une fois que vous avez créé une instance Vertex AI Workbench, elle reste en attente indéfiniment. Une erreur semblable à l'erreur suivante peut apparaître dans les journaux série :

Could not resolve host: notebooks.googleapis.com

Si votre instance est bloquée à l'état de provisionnement, il est possible que la configuration de votre réseau privé soit incorrecte.

Solution

Suivez la procédure décrite dans la section Les journaux d'instance affichent des erreurs de connexion ou de délai avant expiration.

Impossible de créer une instance dans un réseau VPC partagé

Problème

Toute tentative de création d'une instance au sein d'un réseau VPC partagé génère un message d'erreur semblable à celui-ci :

Required 'compute.subnetworks.use' permission for
'projects/network-administration/regions/us-central1/subnetworks/v'

Solution

Le problème est que le compte de service Notebooks tente de créer l'instance sans les autorisations appropriées.

Pour vous assurer que le compte de service Notebooks dispose des autorisations nécessaires pour vous assurer que le compte de service Notebooks peut créer une instance Vertex AI Workbench dans un réseau VPC partagé, demandez à votre administrateur d'accorder au compte de service Notebooks le rôle IAM d'utilisateur de réseau Compute (roles/compute.networkUser) sur le projet hôte. Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

Ce rôle prédéfini contient les autorisations requises pour garantir que le compte de service Notebooks peut créer une instance Vertex AI Workbench dans un réseau VPC partagé. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour garantir que le compte de service Notebooks peut créer une instance Vertex AI Workbench dans un réseau VPC partagé :

Pour utiliser des sous-réseaux : compute.subnetworks.use

Votre administrateur peut également attribuer au compte de service ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Impossible de créer une instance Vertex AI Workbench avec un conteneur personnalisé

Problème

Il n'existe aucune option permettant d'utiliser un conteneur personnalisé lors de la création d'une instance Vertex AI Workbench dans la console Google Cloud.

Solution

Il n'est pas possible d'ajouter un conteneur personnalisé à une instance Vertex AI Workbench, et vous ne pouvez pas ajouter de conteneur personnalisé à l'aide de la console Google Cloud.

Il est recommandé d'ajouter un environnement Conda au lieu d'utiliser un conteneur personnalisé.

L'API Notebooks permet l'ajout d'un conteneur personnalisé à une instance Vertex AI Workbench, mais cette capacité n'est pas disponible.

Le bouton d'installation du stockage partagé ne s'affiche pas

Problème

Le bouton Mount shared storage (Installer le stockage partagé) ne se trouve pas dans l'onglet Explorateur de fichiers de l'interface JupyterLab.

Solution

L'autorisation storage.buckets.list est requise pour que le bouton Mount shared storage (Installer le stockage partagé) s'affiche dans l'interface JupyterLab de votre instance Vertex AI Workbench. Demandez à votre administrateur d'accorder au compte de service de votre instance Vertex AI Workbench l'autorisation storage.buckets.list sur le projet.

Erreur 599 lors de l'utilisation de Dataproc

Problème

Toute tentative de création d'une instance compatible avec Dataproc génère un message d'erreur semblable à celui-ci :

HTTP 599: Unknown (Error from Gateway: [Timeout while connecting]
Exception while attempting to connect to Gateway server url.
Ensure gateway url is valid and the Gateway instance is running.)

Solution

Dans votre configuration Cloud DNS, ajoutez une entrée Cloud DNS pour le domaine *.googleusercontent.com.

Impossible d'installer l'extension JupyterLab tierce

Problème

Toute tentative d'installation d'une extension JupyterLab tierce génère un message Error: 500.

Solution

Les extensions JupyterLab tierces ne sont pas compatibles avec les instances Vertex AI Workbench.

Impossible de modifier la machine virtuelle sous-jacente

Problème

Lorsque vous essayez de modifier la machine virtuelle (VM) sous-jacente d'une instance Vertex AI Workbench, vous obtenez un message d'erreur semblable à celui-ci :

Current principal doesn't have permission to mutate this resource.

Solution

Cette erreur se produit car vous ne pouvez pas modifier la VM sous-jacente d'une instance à l'aide de la console Google Cloud ou de l'API Compute Engine.

Pour modifier la VM sous-jacente d'une instance Vertex AI Workbench, utilisez la méthode projects.locations.instances.patch de l'API Notebooks, ou bien la commande gcloud workbench instances update dans Google Cloud SDK.

Les packages `pip` ne sont plus disponibles après l'ajout de l'environnement Conda.

Problème

Vos packages pip ne sont plus disponibles après l'ajout d'un noyau basé sur Conda.

Solution

Pour résoudre le problème, consultez la section Ajouter un environnement Conda et essayez les solutions suivantes :

Vérifiez que vous avez utilisé la variable DL_ANACONDA_ENV_HOME et qu'elle contient le nom de votre environnement.
Vérifiez que pip se trouve dans un chemin semblable à opt/conda/envs/ENVIRONMENT/bin/pip. Vous pouvez exécuter la commande which pip pour obtenir le chemin.

Impossible de copier ou d'accéder aux données d'une instance avec accès utilisateur unique

Problème

Les données d'une instance avec accès utilisateur unique sont inaccessibles.

Pour les instances Vertex AI Workbench configurées avec accès utilisateur unique, seul l'utilisateur unique (le propriétaire) peut accéder aux données de l'instance.

Solution

Pour accéder aux données ou les copier lorsque vous n'êtes pas le propriétaire de l'instance, ouvrez une demande d'assistance.

Arrêt inattendu

Problème

Votre instance Vertex AI Workbench s'arrête de manière inattendue.

Solution

Si votre instance s'arrête de manière inattendue, cela peut être dû au fait que l'arrêt en cas d'inactivité a été lancé.

Si vous avez activé l'arrêt en cas d'inactivité, votre instance s'arrête en l'absence d'activité du noyau pour la période spécifiée. Par exemple, l'exécution d'une cellule ou une nouvelle impression de sortie sur un notebook est une activité qui réinitialise le minuteur de délai d'inactivité. L'utilisation du processeur ne réinitialise pas le minuteur de délai d'inactivité.

Les journaux de l'instance affichent des erreurs de connexion ou de délai avant expiration

Problème

Les journaux de votre instance Vertex AI Workbench affichent des erreurs de connexion ou de délai avant expiration.

Solution

Si vous constatez des erreurs de connexion ou de délai avant expiration dans les journaux de l'instance, assurez-vous que le serveur Jupyter s'exécute sur le port 8080. Suivez la procédure décrite dans la section Vérifier que l'API interne Jupyter est active.

Si vous avez désactivé External IP et que vous utilisez un réseau VPC privé, assurez-vous également d'avoir suivi la documentation sur les options de configuration du réseau. Réfléchissez aux éléments suivants :

Vous devez activer l'accès privé à Google sur le sous-réseau choisi dans la même région que votre instance dans le projet hôte du VPC. Pour en savoir plus sur la configuration de l'accès privé à Google, consultez la documentation sur l'accès privé à Google.
Si vous utilisez Cloud DNS, l'instance doit pouvoir résoudre les domaines Cloud DNS requis spécifiés dans la documentation sur les options de configuration du réseau. Pour vérifier cela, suivez la procédure décrite dans la section Vérifier que l'instance peut résoudre les domaines DNS requis.

Les journaux d'instance indiquent "Impossible de contacter l'API Jupyter" ou "ReadTimeoutError"

Problème

Les journaux de votre instance Vertex AI Workbench affichent une erreur semblable à celle-ci :

notebooks_collection_agent. Unable to contact Jupyter API:
HTTPConnectionPool(host=\'127.0.0.1\', port=8080):
Max retries exceeded ReadTimeoutError(\"HTTPConnectionPool(host=\'127.0.0.1\', port=8080

Solution

Suivez la procédure décrite dans la section Les journaux d'instance affichent des erreurs de connexion ou de délai avant expiration. Vous pouvez également essayer de modifier le script de l'agent de collecte des notebooks pour remplacer HTTP_TIMEOUT_SESSION par une valeur plus élevée, par exemple 60, afin de vérifier si la requête a échoué parce que l'appel prend trop de temps à répondre ou que l'URL demandée ne peut pas être atteinte.

Notebooks gérés

Cette section décrit les étapes de dépannage pour les notebooks gérés.

Se connecter à JupyterLab et l'ouvrir

Cette section explique comment remédier aux problèmes liés à la connexion à JupyterLab et à son ouverture.

S'il ne se passe rien après avoir cliqué sur "Ouvrir JupyterLab"

Problème

Lorsque vous cliquez sur Ouvrir JupyterLab, rien ne se passe.

Solution

Vérifiez que votre navigateur ne bloque pas l'ouverture automatique de nouveaux onglets. JupyterLab s'ouvre dans un nouvel onglet du navigateur.

Impossible de se connecter à l'instance de notebooks gérés via SSH

Problème

Il n'existe aucune option permettant de se connecter aux instances de notebooks gérés à l'aide de SSH.

Solution

L'accès SSH aux instances de notebooks gérés n'est pas disponible.

Impossible d'accéder au terminal d'une instance de notebooks gérés

Problème

Solution

Vous devez créer une instance de notebooks gérés avec l'option Accès au terminal activée. Cette option ne peut plus être modifiée après la création de l'instance.

Erreur 502 lors de l'ouverture de JupyterLab

Problème

Une erreur 502 peut indiquer que votre instance de notebooks gérés n'est pas encore prête.

Solution

Attendez quelques minutes, actualisez l'onglet du navigateur de la console Google Cloud, puis réessayez.

L'ouverture d'un notebook génère une erreur 524 (Le délai d'attente a expiré).

Problème

Une erreur 524 indique généralement que l'agent de proxy inverse ne se connecte pas au serveur proxy inverse ou que les requêtes prennent trop de temps du côté du serveur backend (Jupyter). Cette erreur se produit généralement en cas de problèmes de mise en réseau, ou lorsque l'agent de proxy inverse ou le service Jupyter ne fonctionne pas.

Solution

Vérifiez que votre instance de notebooks gérés est démarrée.

Le notebook ne répond pas

Problème

L'instance de notebooks gérés n'exécute pas de cellules ou semble être figée.

Solution

Essayez d'abord de redémarrer le noyau en cliquant sur Noyau dans le menu supérieur, puis sur Redémarrer le noyau. Si cela ne fonctionne pas, vous pouvez essayer les solutions suivantes :

Actualisez la page du navigateur JupyterLab. Une sortie de cellule non enregistrée n'est pas conservée. Vous devez donc exécuter à nouveau ces cellules pour générer à nouveau la sortie.
Réinitialisez votre instance.

Migrer vers des instances Vertex AI Workbench

Cette section décrit les méthodes de diagnostic et de résolution des problèmes liés à la migration d'une instance de notebooks gérés vers une instance Vertex AI Workbench.

Impossible de trouver un kernel qui figurait dans l'instance de notebooks gérés

Problème

Un kernel qui figurait dans votre instance de notebooks gérés n'apparaît pas dans l'instance Vertex AI Workbench vers laquelle vous avez migré.

Les conteneurs personnalisés apparaissent sous forme de kernels dans les notebooks gérés. L'outil de migration vers Vertex AI Workbench n'est pas compatible avec la migration de conteneurs personnalisés.

Solution

Pour résoudre ce problème, ajoutez un environnement Conda à votre instance Vertex AI Workbench.

Version de framework différente dans l'instance migrée

Problème

La version d'un framework qui figurait dans votre instance de notebooks gérés diffère de celle du framework figurant dans l'instance Vertex AI Workbench vers laquelle vous avez migré.

Les instances Vertex AI Workbench fournissent un ensemble par défaut de versions de framework. L'outil de migration n'ajoute pas les versions de framework de votre instance de notebooks gérés d'origine. Consultez la section Comportements par défaut de l'outil de migration.

Solution

Pour ajouter une version spécifique d'un framework, ajoutez un environnement Conda à votre instance Vertex AI Workbench.

Les GPU ne sont pas migrés vers la nouvelle instance Vertex AI Workbench

Problème

Les GPU qui se trouvaient dans votre instance de notebooks gérés ne figurent pas dans l'instance Vertex AI Workbench vers laquelle vous avez migré.

Les instances Vertex AI Workbench sont compatibles avec un ensemble de GPU par défaut. Si les GPU de votre instance de notebooks gérés d'origine ne sont pas disponibles, votre instance est migrée sans GPU.

Solution

Après la migration, vous pouvez ajouter des GPU à votre instance Vertex AI Workbench à l'aide de la méthode projects.locations.instances.patch dans l'API Notebooks, ou à l'aide de la commande gcloud workbench instances update dans le Google Cloud SDK.

Différence au niveau du type de machine de l'instance migrée

Problème

Le type de machine de votre instance de notebooks gérés diffère de celui de l'instance Vertex AI Workbench vers laquelle vous avez migré.

Les instances Vertex AI Workbench ne sont pas compatibles avec tous les types de machines. Si le type de machine de votre instance de notebooks gérés d'origine n'est pas disponible, votre instance est migrée vers le type de machine e2-standard-4.

Solution

Après la migration, vous pouvez modifier le type de machine de votre instance Vertex AI Workbench en utilisant la méthode projects.locations.instances.patch dans l'API Notebooks, ou la commande gcloud workbench instances update dans le Google Cloud SDK.

Le quota de GPU a été dépassé

Problème

Vous ne pouvez pas créer d'instance de notebooks gérés avec des GPU.

Solution

Utiliser des images de conteneurs

Cette section explique comment remédier aux problèmes liés à l'utilisation d'images de conteneurs.

L'image de conteneur n'apparaît pas en tant que noyau dans JupyterLab

Problème

Les images de conteneurs qui ne possèdent pas de spécification de noyau valide ne sont pas chargées en tant que noyaux dans JupyterLab.

Solution

Assurez-vous que votre conteneur répond à nos exigences. Pour en savoir plus, consultez la section Exigences concernant les conteneurs personnalisés.

Le notebook se déconnecte pendant un job de longue durée

Problème

Si le message d'erreur suivant s'affiche lors de l'exécution d'un job dans un notebook, cela peut être dû au fait que le chargement de la requête est trop long, ou que l'utilisation du processeur ou de la mémoire est élevée, ce qui peut empêcher le service Jupyter de répondre.

{"log":"2021/06/29 18:10:33 failure fetching a VM ID: compute: Received 500
`internal error`\n","stream":"stderr","time":"2021-06-29T18:10:33.383650241Z"}
{"log":"2021/06/29 18:38:26 Websocket failure: failed to read a websocket
message from the server: read tcp [::1]:40168-\u003e[::1]:8080: use of closed
network connection\n","stream":"stderr","time":"2021-06-29T18:38:26.057622824Z"}

Solution

Ce problème est causé par l'exécution d'un job de longue durée dans un notebook. Pour exécuter un job pouvant prendre un certain temps, il est recommandé d'utiliser l'exécuteur.

Utiliser l'exécuteur

Cette section explique comment remédier aux problèmes liés à l'utilisation de l'exécuteur.

Installations de packages non disponibles pour l'exécuteur

Problème

L'exécuteur exécute le code de votre notebook dans un environnement distinct du noyau où se trouve le code de votre fichier notebook. De ce fait, certains des packages que vous avez installés peuvent ne pas être disponibles dans l'environnement de l'exécuteur.

Solution

Pour résoudre ce problème, consultez la section Vérifier que les installations de packages sont disponibles pour l'exécuteur.

Erreurs 401 ou 403 lors de l'exécution du code de notebook à l'aide de l'exécuteur

Problème

Une erreur 401 ou 403 lorsque vous exécutez l'exécuteur peut signifier que l'exécuteur ne peut pas accéder aux ressources.

Solution

Voici les causes possibles :

L'exécuteur exécute le code de votre notebook dans un projet locataire distinct de celui de votre instance de notebooks gérés. Par conséquent, lorsque vous accédez à des ressources via le code exécuté par l'exécuteur, il se peut que l'exécuteur ne se connecte pas au bon projet Google Cloud par défaut. Pour résoudre ce problème, utilisez la sélection explicite de projets.
Par défaut, votre instance de notebooks gérés peut avoir accès aux ressources du même projet. Par conséquent, lorsque vous exécutez manuellement le code de votre fichier notebook, ces ressources ne nécessitent aucune authentification supplémentaire. Cependant, étant donné que l'exécuteur s'exécute dans un projet locataire distinct, il n'a pas le même accès par défaut. Pour résoudre ce problème, authentifiez l'accès à l'aide de comptes de service.
L'exécuteur ne peut pas utiliser les identifiants de l'utilisateur final pour authentifier l'accès aux ressources, par exemple la commande gcloud auth login. Pour résoudre ce problème, authentifiez l'accès à l'aide de comptes de service.

Erreur `exited with a non-zero status of 127` lors de l'utilisation de l'exécuteur

Problème

Une erreur exited with a non-zero status of 127 ou une erreur "commande introuvable" peut se produire lorsque vous utilisez l'exécuteur pour exécuter du code sur un conteneur personnalisé sur lequel l'extension nbexecutor n'est pas installée.

Solution

Pour vous assurer que votre conteneur personnalisé possède l'extension nbexecutor, vous pouvez créer une image de conteneur dérivée à partir d'une image de conteneurs de deep learning. Les images de conteneurs de deep learning incluent l'extension nbexecutor.

Message d'erreur indiquant une configuration de mise en réseau de services non valide

Problème

Cette erreur peut se présenter comme suit :

Invalid Service Networking configuration. Couldn't find free blocks in allocated IP ranges.
Please use a valid range using: /24 mask or below (/23,/22, etc).

Cela signifie qu'aucun bloc libre n'a été trouvé dans les plages d'adresses IP allouées de votre réseau.

Solution

Utilisez un masque de sous-réseau de /24 ou inférieur. Créez une plage d'adresses IP allouée plus étendue et associez cette plage en modifiant la connexion de service privée pour servicenetworking-googleapis-com.

Pour en savoir plus, consultez la page Configurer un réseau.

Impossible d'installer l'extension JupyterLab tierce

Problème

Toute tentative d'installation d'une extension JupyterLab tierce génère un message Error: 500.

Solution

Les extensions JupyterLab tierces ne sont pas compatibles avec les instances de notebooks gérés.

Impossible de copier ou d'accéder aux données d'une instance avec accès utilisateur unique

Problème

Les données d'une instance avec accès utilisateur unique sont inaccessibles.

Solution

Pour les instances de notebooks gérés configurées avec un accès utilisateur unique, seul l'utilisateur unique spécifié (le propriétaire) peut accéder aux données de l'instance.

Pour accéder aux données ou les copier lorsque vous n'êtes pas le propriétaire de l'instance, ouvrez une demande d'assistance.

Arrêt inattendu

Problème

Votre instance Vertex AI Workbench s'arrête de manière inattendue.

Solution

Si votre instance s'arrête de manière inattendue, cela peut être dû au fait que l'arrêt en cas d'inactivité a été lancé.

Restaurer une instance

Problème

Il n'est pas possible de restaurer une instance de notebooks gérés après sa suppression.

Solution

Pour sauvegarder les données de votre instance, vous pouvez enregistrer vos notebooks sur GitHub.

Récupérer les données d'une instance

Problème

Il n'est pas possible de récupérer les données d'une instance de notebooks gérés après sa suppression.

Solution

Pour sauvegarder les données de votre instance, vous pouvez enregistrer vos notebooks sur GitHub.

Créer des instances de notebooks gérés

Cette section explique comment remédier aux problèmes liés à la création d'instances de notebooks gérés.

Erreur : Problème lors de la création d'une connexion

Problème

Vous rencontrez cette erreur lors de la création d'une instance :

We encountered a problem while creating a connection.

Service 'servicenetworking.googleapis.com' requires at least
one allocated range to have minimal size; please make sure
at least one allocated range will have prefix length at most '24'.

Solution

Créez une plage d'adresses IP allouée plus étendue que /24 et associez cette plage en modifiant la connexion de service privée pour la connexion servicenetworking-googleapis-com.

La création d'une instance entraîne une erreur de disponibilité des ressources

Problème

Vous ne pouvez pas créer d'instance en raison d'une erreur de disponibilité des ressources.

Cette erreur peut se présenter comme suit :

Creating notebook INSTANCE_NAME: ZONE does not have
enough resources available to fulfill the request.
Retry later or try another zone in your configurations.

Des erreurs de ressources se produisent lorsque vous demandez de nouvelles ressources dans une zone qui ne peut pas traiter votre requête du fait de l'indisponibilité actuelle des ressources Compute Engine, telles que les GPU ou les processeurs.

Les erreurs de ressources ne s'appliquent qu'aux requêtes sur les nouvelles ressources dans la zone, et n'affectent pas les ressources existantes. Les erreurs de ressources ne sont pas liées à votre quota Compute Engine. Les erreurs de ressources sont temporaires et peuvent changer fréquemment en fonction des fluctuations des demandes.

Solution

Pour continuer, procédez comme suit :

Créez une instance avec un autre type de machine.
Créez l'instance dans une autre zone.
Réessayez d'envoyer la requête ultérieurement.
Réduisez la quantité de ressources que vous demandez. Par exemple, essayez de créer une instance avec moins de GPU, de disques, de vCPU ou de mémoire.

Le démarrage d'une instance entraîne une erreur de disponibilité des ressources

Problème

Vous ne pouvez pas démarrer une instance en raison d'une erreur de disponibilité des ressources.

Cette erreur peut se présenter comme suit :

The zone ZONE_NAME doesn't have enough resources available to fulfill
the request. '(resource type:compute)'.

Des erreurs de ressources se produisent lorsque vous tentez de démarrer une instance dans une zone qui ne peut pas traiter votre requête en raison de l'indisponibilité actuelle des ressources Compute Engine, telles que les GPU ou les processeurs.

Les erreurs de ressources ne s'appliquent qu'aux ressources spécifiées dans votre requête au moment de l'envoi de celle-ci, et non à toutes les ressources de la zone. Les erreurs de ressources ne sont pas liées à votre quota Compute Engine. Les erreurs de ressources sont temporaires et peuvent changer fréquemment en fonction des fluctuations des demandes.

Solution

Pour continuer, procédez comme suit :

Modifiez le type de machine de votre instance.
Migrez vos fichiers et vos données vers une instance située dans une autre zone.
Réessayez d'envoyer la requête ultérieurement.
Réduisez la quantité de ressources que vous demandez. Par exemple, démarrez une instance différente avec moins de GPU, de disques, de vCPU ou de mémoire.

`No route to host` sur les connexions sortantes depuis des notebooks gérés

Problème

En règle générale, les seules routes que vous pouvez voir dans la console Google Cloud sont celles connues de votre propre VPC, ainsi que les plages réservées lorsque vous configurez l'appairage de réseaux VPC.

Les instances de notebooks gérés se trouvent dans un réseau géré par Google et exécutent une version modifiée de Jupyter dans un espace de noms réseau Docker au sein de l'instance.

L'interface réseau Docker et le pont Linux de cette instance peuvent sélectionner une adresse IP locale qui entre en conflit avec les plages d'adresses IP exportées via l'appairage par votre VPC. Les adresses IP se situent généralement dans les plages 172.16.0.0/161 et 192.168.10.0/24, respectivement.

Dans ces circonstances, les connexions sortantes de l'instance vers ces plages échouent et renvoient une réclamation qui est une variante de No route to host, malgré le partage approprié des routes VPC.

Solution

Appelez ifconfig dans une session de terminal et assurez-vous qu'aucune adresse IP sur les interfaces virtuelles de l'instance n'entre en conflit avec les plages d'adresses IP que votre VPC exporte vers la connexion d'appairage.

Notebooks gérés par l'utilisateur

Cette section décrit les étapes de dépannage pour les notebooks gérés par l'utilisateur.

Se connecter à JupyterLab et l'ouvrir

Cette section explique comment remédier aux problèmes liés à la connexion à JupyterLab et à son ouverture.

S'il ne se passe rien après avoir cliqué sur "Ouvrir JupyterLab"

Problème

Lorsque vous cliquez sur Ouvrir JupyterLab, rien ne se passe.

Solution

Vérifiez que votre navigateur ne bloque pas l'ouverture automatique de nouveaux onglets. JupyterLab s'ouvre dans un nouvel onglet du navigateur.

Aucun accès à JupyterLab avec le serveur proxy inverse

Problème

Impossible d'accéder à JupyterLab.

Vertex AI Workbench utilise un serveur proxy inverse interne de Google pour accéder à JupyterLab. Les paramètres d'instance de notebooks gérés par l'utilisateur, la configuration réseau et d'autres facteurs peuvent empêcher l'accès à JupyterLab.

Solution

Utilisez SSH pour vous connecter à JupyterLab et découvrez les raisons pour lesquelles vous ne pouvez pas utiliser le proxy inverse.

Impossible de se connecter à l'instance de notebooks gérés par l'utilisateur via SSH

Problème

Vous ne parvenez pas à vous connecter à votre instance à l'aide de SSH via une fenêtre de terminal.

Les instances de notebooks gérés par l'utilisateur utilisent OS Login pour activer l'accès SSH. Lorsque vous créez une instance, Vertex AI Workbench active OS Login par défaut en définissant la clé de métadonnées enable-oslogin sur TRUE. Si vous ne parvenez pas à vous connecter en SSH à votre instance, il est possible que cette clé de métadonnées doive être définie sur TRUE.

Solution

Pour activer l'accès SSH pour les utilisateurs de notebooks gérés par l'utilisateur, suivez la procédure permettant de configurer les rôles OS Login sur les comptes utilisateur.

L'ouverture d'une instance de notebooks gérés par l'utilisateur génère une erreur 403 (Interdit)

Problème

Une erreur 403 (Forbidden) lors de l'ouverture d'une instance de notebooks gérés par l'utilisateur indique souvent un problème d'accès.

Solution

Pour résoudre des problèmes d'accès, réfléchissez aux trois manières d'accorder l'accès à une instance de notebooks gérés par l'utilisateur :

Utilisateur unique
Compte de service
Éditeurs du projet

Le mode d'accès est configuré lors de la création de l'instance de notebooks gérés par l'utilisateur et est défini dans les métadonnées du notebook :

Utilisateur unique : proxy-mode=mail, proxy-user-mail=user@domain.com
Compte de service : proxy-mode=service_account
Éditeurs du projet : proxy-mode=project_editors

Si vous ne parvenez pas à accéder à un notebook lorsque vous cliquez sur Ouvrir JupyterLab, essayez les solutions suivantes :

Vérifiez que l'entrée de métadonnées proxy-mode est correcte.
Vérifiez que l'utilisateur qui accède à l'instance dispose de l'autorisation iam.serviceAccounts.ActAs pour le compte de service de l'instance. Le compte de service est soit le compte de service Compute Engine par défaut, soit un compte de service spécifié lors de la création de l'instance.
Si votre instance utilise un accès utilisateur unique avec un compte de service spécifié comme utilisateur unique, consultez la section Aucun accès à JupyterLab, mode utilisateur unique activé.

L'exemple suivant montre comment spécifier un compte de service lorsque vous créez une instance :

gcloud notebooks instances create nb-1 \
  --vm-image-family=tf-latest-cpu \
  --metadata=proxy-mode=mail,proxy-user-mail=user@domain.com \
  --service-account=your_service_account@project_id.iam.gserviceaccount.com \
  --location=us-west1-a

Lorsque vous cliquez sur Ouvrir JupyterLab pour ouvrir un notebook, celui-ci s'ouvre dans un nouvel onglet de navigateur. Si vous êtes connecté à plusieurs comptes Google, le nouvel onglet s'ouvre avec votre compte Google par défaut. Si vous n'avez pas créé votre instance de notebooks gérés par l'utilisateur avec votre compte Google par défaut, le nouvel onglet de navigateur affiche l'erreur 403 (Forbidden).

Aucun accès à JupyterLab, mode utilisateur unique activé

Problème

Impossible d'accéder à JupyterLab.

Solution

Si un utilisateur ne parvient pas à accéder à JupyterLab et que l'accès de l'instance à JupyterLab est défini sur Single user only, procédez comme suit :

Sur la page Notebooks gérés par l'utilisateur de la console Google Cloud, cliquez sur le nom de votre instance pour ouvrir la page Détails du notebook.
À côté de Afficher les détails de la VM, cliquez sur Afficher dans Compute Engine.
Sur la page Informations sur l'instance de VM, cliquez sur Modifier.
Dans la section Métadonnées, vérifiez que l'entrée de métadonnées proxy-mode est définie sur mail.
Vérifiez que l'entrée de métadonnées proxy-user-mail est définie sur une adresse e-mail d'utilisateur valide, et non sur un compte de service.
Cliquez sur Enregistrer.
Sur la page Notebooks gérés par l'utilisateur de la console Google Cloud, initialisez les métadonnées mises à jour en arrêtant votre instance et en redémarrant l'instance à nouveau.

L'ouverture d'un notebook génère une erreur 504 (Expiration du délai de la passerelle)

Problème

Il s'agit d'une indication du délai expiration du proxy interne ou du délai d'expiration du serveur backend (Jupyter). Cela peut se produire dans les cas suivants :

La requête n'a jamais accédé au serveur proxy inverse interne.
Le backend (Jupyter) renvoie une erreur 504.

Solution

Ouvrez une demande d'assistance Google.

L'ouverture d'un notebook génère une erreur 524 (Le délai d'attente a expiré).

Problème

Le serveur proxy inverse interne n'a pas reçu de réponse de l'agent de proxy inverse pour la requête dans le délai imparti. L'agent de proxy inverse s'exécute en tant que conteneur Docker dans votre instance de notebooks gérés par l'utilisateur. Une erreur 524 indique généralement que l'agent de proxy inverse ne se connecte pas au serveur proxy inverse ou que les requêtes prennent trop de temps du côté du serveur backend (Jupyter). Cette erreur se produit en général du côté de l'utilisateur (par exemple, un problème de réseau, ou le service de l'agent de proxy inverse ne fonctionne pas).

Solution

Si vous ne parvenez pas à accéder à un notebook, vérifiez que votre instance de notebooks gérés par l'utilisateur est démarrée et essayez les solutions suivantes :

Option 1 : exécutez l'outil de diagnostic pour vérifier et réparer automatiquement les services principaux des notebooks gérés par l'utilisateur, vérifier l'espace de stockage disponible, et générer des fichiers journaux utiles. Pour exécuter l'outil dans votre instance, procédez comme suit :

Assurez-vous que votre instance utilise la version M58 ou une version ultérieure.
Connectez-vous à votre instance Deep Learning VM Image à l'aide de SSH.
Exécutez la commande suivante :
```
sudo /opt/deeplearning/bin/diagnostic_tool.sh [--repair] [--bucket=$BUCKET]
```
Notez que les options --repair et --bucket sont facultatives. L'option --repair tente de corriger les erreurs courantes des services principaux, et l'option --bucket vous permet de spécifier un bucket Cloud Storage pour stocker les fichiers journaux créés.

Cette commande affiche en sortie des messages d'état utiles pour les services principaux des notebooks gérés par l'utilisateur et exporte les fichiers journaux de ses résultats.

Option 2 : procédez comme suit pour vérifier individuellement les conditions spécifiques aux notebooks gérés par l'utilisateur.

Vérifiez qu'il vous reste de l'espace disque sur l'instance de notebooks gérés par l'utilisateur.
1. Connectez-vous à votre instance Deep Learning VM Image à l'aide de SSH.
2. Exécutez la commande suivante :
```
df -h -T /home/jupyter
```
  Si la valeur Use% est supérieure à 85%, vous devez supprimer manuellement les fichiers de /home/jupyter. Dans un premier temps, vous pouvez vider la corbeille à l'aide de la commande suivante :
```
sudo rm -rf  /home/jupyter/.local/share/Trash/*
```
Vérifiez que le service Docker est lancé.
Vérifiez que l'agent de proxy inverse est en cours d'exécution. Si l'agent est démarré, essayez de le redémarrer.
Assurez-vous que le service Jupyter est en cours d'exécution. Si tel est le cas, essayez de le redémarrer.
Vérifiez l'utilisation de la mémoire sur l'instance de notebooks gérés par l'utilisateur.
1. Connectez-vous à votre instance Deep Learning VM à l'aide de SSH.
2. Exécutez la commande suivante :
```
free -t -h
```
  Si la part de la mémoire utilisée est supérieure à 85% de la mémoire totale, vous devriez envisager de modifier le type de machine.
3. Vous pouvez installer l'agent Cloud Monitoring pour déterminer s'il y a une utilisation intensive de la mémoire dans votre instance de notebooks gérés par l'utilisateur. Consultez les informations tarifaires.
Vérifiez que vous utilisez la version M55 ou une version ultérieure de Deep Learning VM. Pour en savoir plus sur la mise à niveau, consultez la section Mettre à niveau l'environnement d'une instance de notebooks gérés par l'utilisateur.

L'ouverture d'un notebook génère une erreur 598 (Expiration du délai de lecture du réseau)

Problème

Le serveur de proxy d'inversion n'a reçu aucune réponse de l'agent de proxy d'inversion depuis plus de 10 minutes. Cela indique bien un problème au niveau de l'agent de proxy d'inversion.

Solution

Si vous ne parvenez pas à accéder à un notebook, essayez les solutions suivantes :

Vérifiez que votre instance de notebooks gérés par l'utilisateur est démarrée.
Vérifiez que le service Docker est lancé.
Vérifiez que l'agent de proxy inverse est en cours d'exécution. Si l'agent est démarré, essayez de le redémarrer.
Assurez-vous que le service Jupyter est en cours d'exécution. Si tel est le cas, essayez de le redémarrer.
Vérifiez que vous utilisez la version M55 ou une version ultérieure de Deep Learning VM. Pour en savoir plus sur la mise à niveau, consultez la section Mettre à niveau l'environnement d'une instance de notebooks gérés par l'utilisateur.

Le notebook ne répond pas

Problème

Votre instance de notebooks gérés par l'utilisateur n'exécute pas de cellules ou semble bloquée.

Solution

Essayez d'abord de redémarrer le noyau en cliquant sur Noyau dans le menu supérieur, puis sur Redémarrer le noyau. Si cela ne fonctionne pas, vous pouvez essayer les solutions suivantes :

Actualisez la page du navigateur JupyterLab. Toute sortie de cellule non enregistrée ne sera pas conservée. Vous devez donc exécuter à nouveau ces cellules pour générer à nouveau la sortie.
À partir d'une session de terminal du notebook, exécutez la commande top pour voir si des processus utilisent le processeur.
Depuis le terminal, vérifiez la quantité d'espace disque disponible à l'aide de la commande df, ou la mémoire RAM disponible à l'aide de la commande free.
Arrêtez votre instance en la sélectionnant sur la page Notebooks gérés par l'utilisateur et en cliquant sur Arrêter. Une fois qu'elle est complètement arrêtée, sélectionnez-la et cliquez sur Démarrer.

Migrer vers des instances Vertex AI Workbench

Cette section décrit les méthodes de diagnostic et de résolution des problèmes liés à la migration d'une instance de notebooks gérés par l'utilisateur vers une instance Vertex AI Workbench.

Impossible de trouver R, Beam ou d'autres kernels qui figuraient dans l'instance de notebooks gérés par l'utilisateur

Problème

Un kernel qui figurait dans votre instance de notebooks gérés par l'utilisateur n'apparaît pas dans l'instance Vertex AI Workbench vers laquelle vous avez migré.

Certains kernels, tels que les kernels R et Beam, ne sont pas disponibles par défaut dans les instances Vertex AI Workbench. La migration de ces kernels n'est pas possible.

Solution

Pour résoudre ce problème, ajoutez un environnement Conda à votre instance Vertex AI Workbench.

Impossible de configurer une instance Dataproc Hub dans l'instance Vertex AI Workbench

Problème

Dataproc Hub n'est pas compatible avec les instances Vertex AI Workbench.

Solution

Continuez à utiliser Dataproc Hub dans des instances de notebooks gérés par l'utilisateur.

Version de framework différente dans l'instance migrée

Problème

La version d'un framework qui figurait dans votre instance de notebooks gérés par l'utilisateur diffère de celle du framework figurant dans l'instance Vertex AI Workbench vers laquelle vous avez migré.

Les instances Vertex AI Workbench fournissent un ensemble par défaut de versions de framework. L'outil de migration n'ajoute pas les versions de framework de votre instance de notebooks gérés par l'utilisateur d'origine. Consultez la section Comportements par défaut de l'outil de migration.

Solution

Pour ajouter une version spécifique d'un framework, ajoutez un environnement Conda à votre instance Vertex AI Workbench.

Les GPU ne sont pas migrés vers la nouvelle instance Vertex AI Workbench

Problème

Les GPU qui se trouvaient dans votre instance de notebooks gérés par l'utilisateur ne figurent pas dans l'instance Vertex AI Workbench vers laquelle vous avez migré.

Les instances Vertex AI Workbench sont compatibles avec un ensemble de GPU par défaut. Si les GPU de votre instance de notebooks gérés par l'utilisateur d'origine ne sont pas disponibles, votre instance est migrée sans GPU.

Solution

Différence au niveau du type de machine de l'instance migrée

Problème

Le type de machine de votre instance de notebooks gérés par l'utilisateur diffère de celui de l'instance Vertex AI Workbench vers laquelle vous avez migré.

Les instances Vertex AI Workbench ne sont pas compatibles avec tous les types de machines. Si le type de machine de votre instance de notebooks gérés par l'utilisateur d'origine n'est pas disponible, votre instance est migrée vers le type de machine e2-standard-4.

Solution

Utiliser des fichiers

Cette section explique comment remédier aux problèmes liés aux fichiers des instances de notebooks gérés par l'utilisateur.

Le téléchargement des fichiers est désactivé, mais l'utilisateur peut toujours télécharger des fichiers

Problème

Pour les instances de notebooks gérés par l'utilisateur Dataproc Hub, la désactivation du téléchargement de fichier depuis l'interface utilisateur de JupyterLab n'est pas possible. Les instances de notebooks gérés par l'utilisateur qui utilisent le framework Dataproc Hub autorisent le téléchargement de fichiers même si vous ne sélectionnez pas l'option Activer le téléchargement de fichiers à partir de l'interface utilisateur JupyterLab lors de la création de l'instance.

Solution

Les instances de notebooks gérés par l'utilisateur Dataproc Hub ne permettent pas de restreindre le téléchargement de fichiers.

Les fichiers téléchargés sont tronqués ou leur téléchargement n'est pas terminé

Problème

Lorsque vous téléchargez des fichiers à partir de votre instance de notebooks gérés par l'utilisateur, un paramètre de délai avant expiration sur l'agent de transfert proxy limite la durée de la connexion pour le téléchargement. Si le téléchargement prend trop de temps, cela peut tronquer votre fichier téléchargé ou empêcher son téléchargement.

Solution

Pour télécharger le fichier, copiez-le dans Cloud Storage, puis téléchargez-le à partir de Cloud Storage.

Envisagez de migrer vos fichiers et vos données vers une nouvelle instance de notebooks gérés par l'utilisateur.

Après le redémarrage de la VM, les fichiers locaux ne peuvent plus être référencés depuis le terminal de notebook

Problème

Parfois, après le redémarrage d'une instance de notebooks gérés par l'utilisateur, les fichiers locaux ne peuvent plus être référencés depuis un terminal de notebook.

Solution

Il s'agit d'un problème connu. Pour référencer vos fichiers locaux à partir d'un terminal de notebook, rétablissez d'abord votre répertoire de travail actuel à l'aide de la commande suivante :

cd PWD

Dans cette commande, remplacez PWD par votre répertoire de travail actuel. Par exemple, si votre répertoire de travail actuel est /home/jupyter/, exécutez la commande cd /home/jupyter/.

Une fois votre répertoire de travail actuel rétabli, vos fichiers locaux peuvent être référencés à partir du terminal de notebook.

Créer des instances de notebooks gérées par l'utilisateur

Cette section explique comment remédier aux problèmes liés à la création d'instances de notebooks gérés par l'utilisateur.

Le quota de GPU a été dépassé

Problème

Vous ne pouvez pas créer d'instance de notebooks gérés par l'utilisateur avec des GPU.

Solution

L'instance reste en attente indéfiniment

Problème

Une fois une instance de notebooks gérés par l'utilisateur créée, elle reste en attente indéfiniment. Une erreur semblable à l'erreur suivante peut apparaître dans les journaux série :

Could not resolve host: notebooks.googleapis.com

Solution

Votre instance ne peut pas se connecter au serveur d'API Notebooks en raison d'une configuration Cloud DNS ou d'un autre problème de réseau. Pour résoudre le problème, vérifiez vos configurations Cloud DNS et réseau. Pour en savoir plus, consultez la section Options de configuration du réseau.

Impossible de créer une instance de notebooks gérés par l'utilisateur (autorisations insuffisantes)

Problème

En règle générale, il faut environ une minute pour créer une instance de notebooks gérés par l'utilisateur. Si votre nouvelle instance de notebooks gérés par l'utilisateur reste dans l'état pending indéfiniment, il est possible que le compte de service utilisé pour démarrer l'instance de notebooks gérés par l'utilisateur ne dispose pas des autorisations requises dans votre projet Google Cloud.

Vous pouvez démarrer une instance de notebooks gérés par l'utilisateur avec un compte de service personnalisé que vous créez ou en mode mono-utilisateur avec un ID utilisateur. Si vous démarrez une instance de notebooks gérés par l'utilisateur en mode mono-utilisateur, elle commence le processus de démarrage avec le compte de service par défaut Compute Engine avant de transférer le contrôle à votre ID utilisateur.

Solution

Pour vérifier qu'un compte de service dispose des autorisations appropriées, procédez comme suit :

Console

Ouvrez la page "IAM" dans Google Cloud Console.
Ouvrir la page IAM
Déterminez le compte de service utilisé avec votre instance de notebooks gérés par l'utilisateur, à savoir :
- Un compte de service personnalisé que vous avez spécifié lors de la création de l'instance de notebooks gérés par l'utilisateur
- Le compte de service par défaut Compute Engine pour votre projet Google Cloud, utilisé lorsque vous démarrez votre instance de notebooks gérés par l'utilisateur en mode mono-utilisateur. Le compte de service Compute Engine par défaut pour votre projet Google Cloud est nommé PROJECT_NUMBER-compute@developer.gserviceaccount.com. Exemple : 113377992299-compute@developer.gserviceaccount.com.
Vérifiez que votre compte de service dispose du rôle "Exécuteur de notebooks" (roles/notebooks.runner). Si ce n'est pas le cas, attribuez au compte de service le rôle "Exécuteur de notebooks" (roles/notebooks.runner).

Pour en savoir plus, consultez la page Accorder, modifier et révoquer les accès à des ressources dans la documentation IAM.

gcloud

Si ce n'est pas déjà fait, installez Google Cloud CLI.
Obtenez le nom et le numéro de projet correspondant à votre projet Google Cloud à l'aide de la commande suivante. Remplacez PROJECT_ID par l'ID de votre projet Google Cloud.
```
gcloud projects describe PROJECT_ID
```
Vous devriez voir un résultat semblable au suivant, y compris le nom (name:) et le numéro de projet (projectNumber:) pour votre projet.
```
createTime: '2018-10-18T21:03:31.408Z'
lifecycleState: ACTIVE
name: my-project-name
parent:
 id: '396521612403'
 type: folder
projectId: my-project-id-1234
projectNumber: '113377992299'
```
Déterminez le compte de service utilisé avec votre instance de notebooks gérés par l'utilisateur, à savoir :
- Un compte de service personnalisé que vous avez spécifié lors de la création de l'instance de notebooks gérés par l'utilisateur
- Le compte de service par défaut Compute Engine pour votre projet Google Cloud, utilisé lorsque vous démarrez votre instance de notebooks gérés par l'utilisateur en mode mono-utilisateur. Le compte de service Compute Engine par défaut pour votre projet Google Cloud est nommé PROJECT_NUMBER-compute@developer.gserviceaccount.com. Exemple : 113377992299-compute@developer.gserviceaccount.com.
Ajoutez le rôle roles/notebooks.runner au compte de service à l'aide de la commande suivante. Remplacez project-name par le nom de votre projet et service-account-id par l'ID de compte de service de votre instance de notebooks gérés par l'utilisateur.
```
gcloud projects add-iam-policy-binding project-name \
 --member serviceAccount:service-account-id \
 --role roles/notebooks.runner
```

Créer une instance génère une erreur `Permission denied`

Problème

Le compte de service de l'instance permet d'accéder à d'autres services Google Cloud. Vous pouvez utiliser n'importe quel compte de service au sein du même projet, mais vous devez disposer de l'autorisation Utilisateur du compte de service (iam.serviceAccounts.actAs) pour créer l'instance. S'il n'est pas spécifié, le compte de service Compute Engine par défaut est utilisé.

Solution

Lors de la création d'une instance, vérifiez que l'utilisateur qui crée l'instance dispose de l'autorisation iam.serviceAccounts.ActAs pour le compte de service défini.

L'exemple suivant montre comment spécifier un compte de service lorsque vous créez une instance :

gcloud notebooks instances create nb-1 \
  --vm-image-family=tf-latest-cpu \
  --service-account=your_service_account@project_id.iam.gserviceaccount.com \
  --location=us-west1-a

Pour savoir comment accorder le rôle "Utilisateur du compte de service", consultez la section Gérer l'accès aux comptes de service.

Créer une instance génère une erreur `already exists`

Problème

Lors de la création d'une instance, vérifiez qu'une instance de notebooks gérés par l'utilisateur portant le même nom n'a pas été supprimée auparavant par Compute Engine et qu'elle existe toujours dans la base de données de l'API Notebooks.

Solution

L'exemple suivant montre comment lister les instances à l'aide de l'API Notebooks et vérifier leur état.

gcloud notebooks instances list --location=LOCATION

Si l'état d'une instance est DELETED, exécutez la commande suivante pour la supprimer définitivement.

gcloud notebooks instances delete INSTANCE_NAME --location=LOCATION

Impossible de créer une instance dans un VPC partagé

Problème

Vous ne pouvez pas créer d'instance dans un VPC partagé.

Solution

Si vous utilisez un VPC partagé, vous devez ajouter le projet hôte et les projets de service au périmètre de service. Dans le projet hôte, vous devez également attribuer le rôle Utilisateur de réseau Compute (roles/compute.networkUser) à l'agent de service Notebooks du projet de service. Pour en savoir plus, consultez la page Gérer les périmètres de service.

La création d'une instance entraîne une erreur de disponibilité des ressources

Problème

Vous ne pouvez pas créer d'instance en raison d'une erreur de disponibilité des ressources.

Cette erreur peut se présenter comme suit :

Creating notebook INSTANCE_NAME: ZONE does not have enough
resources available to fulfill the request. Retry later or try another zone in
your configurations.

Solution

Pour continuer, vous pouvez essayer les solutions suivantes :

Créez une instance avec un autre type de machine.
Créez l'instance dans une autre zone.
Réessayez d'envoyer la requête ultérieurement.
Réduisez la quantité de ressources que vous demandez. Par exemple, essayez de créer une instance avec moins de GPU, de disques, de vCPU ou de mémoire.

Le démarrage d'une instance entraîne une erreur de disponibilité des ressources

Problème

Vous ne pouvez pas démarrer une instance en raison d'une erreur de disponibilité des ressources.

Cette erreur peut se présenter comme suit :

The zone ZONE_NAME doesn't have enough resources available to fulfill
the request. '(resource type:compute)'.

Solution

Pour continuer, vous pouvez essayer les solutions suivantes :

Modifiez le type de machine de votre instance.
Migrez vos fichiers et vos données vers une instance située dans une autre zone.
Réessayez d'envoyer la requête ultérieurement.
Réduisez la quantité de ressources que vous demandez. Par exemple, démarrez une instance différente avec moins de GPU, de disques, de vCPU ou de mémoire.

Mettre à niveau des instances de notebooks gérés par l'utilisateur

Cette section explique comment remédier aux problèmes liés à la mise à niveau des instances de notebooks gérés par l'utilisateur.

Mise à niveau impossible, car il est impossible d'obtenir les informations sur le disque de l'instance

Problème

La mise à niveau n'est pas compatible avec les instances de notebooks gérés par l'utilisateur à disque unique.

Solution

Vous pouvez migrer vos données utilisateur vers une nouvelle instance de notebooks gérés par l'utilisateur.

Mise à niveau impossible, car l'instance n'est pas compatible UEFI.

Problème

Vertex AI Workbench dépend de la compatibilité UEFI pour effectuer une mise à niveau.

Les instances de notebooks gérés par l'utilisateur créées à partir d'images plus anciennes ne sont pas compatibles UEFI et ne peuvent donc pas être mises à niveau.

Solution

Pour vérifier que votre instance est compatible UEFI, saisissez la commande suivante dans Cloud Shell ou dans tout environnement dans lequel Google Cloud CLI est installé.

gcloud compute instances describe INSTANCE_NAME \
  --zone=ZONE | grep type

Remplacez les éléments suivants :

INSTANCE_NAME : nom de l'instance
ZONE : zone où se trouve votre instance

Pour vérifier que l'image que vous avez utilisée pour créer votre instance est compatible UEFI, exécutez la commande suivante :

gcloud compute images describe VM_IMAGE_FAMILY \
  --project deeplearning-platform-release | grep type

Remplacez VM_IMAGE_FAMILY par le nom de la famille d'images que vous avez utilisée pour créer votre instance.

Si vous constatez que votre instance ou votre image n'est pas compatible UEFI, vous pouvez essayer de migrer vos données utilisateur vers une nouvelle instance de notebooks gérés par l'utilisateur. Pour cela, procédez comme suit :

Vérifiez que l'image que vous souhaitez utiliser pour créer votre nouvelle instance est compatible UEFI. Pour ce faire, saisissez la commande suivante dans Cloud Shell ou dans tout environnement dans lequel Google Cloud CLI est installé.
```
gcloud compute images describe VM_IMAGE_FAMILY \
  --project deeplearning-platform-release --format=json | grep type
```
Remplacez VM_IMAGE_FAMILY par le nom de la famille d'images que vous souhaitez utiliser pour créer votre instance.
Migrez vos données utilisateur vers une nouvelle instance de notebooks gérés par l'utilisateur.

L'instance de notebooks gérés par l'utilisateur n'est pas accessible après la mise à niveau

Problème

Si l'instance de notebooks gérés par l'utilisateur n'est plus accessible après une mise à niveau, il est possible qu'un échec soit survenu lors du remplacement de l'image du disque de démarrage.

Les instances de notebooks gérés par l'utilisateur pouvant être mises à niveau sont des instances à deux disques, avec un disque de démarrage et un disque de données. Le processus met à niveau le disque de démarrage vers une nouvelle image tout en conservant les données sur le disque de données.

Solution

Procédez comme suit pour associer une nouvelle image valide au disque de démarrage.

Pour stocker les valeurs que vous utiliserez dans le cadre de cette procédure, saisissez la commande suivante dans Cloud Shell ou dans tout environnement dans lequel Google Cloud CLI est installé.
```
export INSTANCE_NAME=MY_INSTANCE_NAME
export PROJECT_ID=MY_PROJECT_ID
export ZONE=MY_ZONE
```
Remplacez les éléments suivants :
- MY_INSTANCE_NAME : nom de l'instance
- MY_PROJECT_ID : ID de votre projet.
- MY_ZONE : zone où se trouve votre instance

Pour arrêter l'instance, utilisez la commande suivante :

gcloud compute instances stop $INSTANCE_NAME \
  --project=$PROJECT_ID --zone=$ZONE

Dissociez le disque de données de l'instance.

gcloud compute instances detach-disk $INSTANCE_NAME --device-name=data \
  --project=$PROJECT_ID --zone=$ZONE

Supprimez la VM de l'instance.

gcloud compute instances delete $INSTANCE_NAME --keep-disks=all --quiet \
  --project=$PROJECT_ID --zone=$ZONE

Utilisez l'API Notebooks pour supprimer l'instance de notebooks gérés par l'utilisateur.

gcloud notebooks instances delete $INSTANCE_NAME \
  --project=$PROJECT_ID --location=$ZONE

Créez une nouvelle instance de notebooks gérés par l'utilisateur portant le même nom que l'instance précédente.
```
gcloud notebooks instances create $INSTANCE_NAME \
  --vm-image-project="deeplearning-platform-release" \
  --vm-image-family=MY_VM_IMAGE_FAMILY \
  --instance-owners=MY_INSTANCE_OWNER \
  --machine-type=MY_MACHINE_TYPE \
  --service-account=MY_SERVICE_ACCOUNT \
  --accelerator-type=MY_ACCELERATOR_TYPE \
  --accelerator-core-count=MY_ACCELERATOR_CORE_COUNT \
  --install-gpu-driver \
  --project=$PROJECT_ID \
  --location=$ZONE
```
Remplacez les éléments suivants :
- MY_VM_IMAGE_FAMILY : nom de la famille d'images
- MY_INSTANCE_OWNER : propriétaire de votre instance
- MY_MACHINE_TYPE : type de machine de la VM de votre instance
- MY_SERVICE_ACCOUNT : compte de service à utiliser avec cette instance, ou utilisez la valeur "default"
- MY_ACCELERATOR_TYPE : type d'accélérateur, par exemple "NVIDIA_TESLA_T4"
- MY_ACCELERATOR_CORE_COUNT : nombre de cœurs, par exemple 1

Surveiller l'état de fonctionnement des instances de notebooks gérés par l'utilisateur

Cette section explique comment résoudre les problèmes liés à la surveillance des états de fonctionnement.

Échec de l'état de `docker-proxy-agent`

Suivez ces étapes après un échec d'état de docker-proxy-agent :

Vérifiez que l'agent de proxy d'inversion est en cours d'exécution. Sinon, passez à l'étape 3.
Redémarrez l'agent de proxy inverse.
Réenregistrez-vous auprès du serveur proxy inverse.

Échec de l'état de `docker-service`

Suivez ces étapes après un échec d'état de docker-service :

Vérifiez que le service Docker est en cours d'exécution.
Redémarrez le service Docker.

Échec de l'état de `jupyter-service`

Suivez ces étapes après un échec d'état de jupyter-service :

Vérifiez que le service Jupyter est en cours d'exécution.
Redémarrez le service Jupyter.

Échec de l'état de `jupyter-api`

Suivez ces étapes après un échec d'état de jupyter-api :

Vérifiez que l'API interne Jupyter est active.
Redémarrez le service Jupyter.

Pourcentage d'utilisation du disque de démarrage

L'état associé à l'espace du disque de démarrage n'est pas opérationnel si l'espace disque utilisé est supérieur à 85 %.

Si l'état de votre espace de disque de démarrage n'est pas opérationnel, procédez comme suit :

À partir d'une session de terminal de l'instance de notebooks gérés par l'utilisateur ou en utilisant SSH pour vous connecter, vérifiez la quantité d'espace disque disponible à l'aide de la commande df -H.
Utilisez la commande find . -type d -size +100M pour vous aider à trouver des fichiers volumineux pouvant être supprimés, mais ne les supprimez pas, sauf si vous êtes sûr de pouvoir le faire en toute sécurité. En cas de doute, vous pouvez obtenir de l'aide auprès de l'assistance.
Si les étapes précédentes ne permettent pas de résoudre votre problème, contactez l'assistance.

Pourcentage d'utilisation du disque de données

L'état associé à l'espace du disque de données n'est pas opérationnel si l'espace disque utilisé est supérieur à 85 %.

Si l'état de votre espace de disque de données n'est pas opérationnel, procédez comme suit :

À partir d'une session de terminal de l'instance de notebooks gérés par l'utilisateur ou en utilisant SSH pour vous connecter, vérifiez la quantité d'espace disque disponible à l'aide de la commande df -h -T /home/jupyter.
Supprimez des fichiers volumineux pour augmenter l'espace disque disponible. Utilisez la commande find . -type d -size +100M pour faciliter la recherche des fichiers volumineux.
Si les étapes précédentes ne permettent pas de résoudre votre problème, contactez l'assistance.

Impossible d'installer l'extension JupyterLab tierce

Problème

Toute tentative d'installation d'une extension JupyterLab tierce génère un message Error: 500.

Solution

Les extensions JupyterLab tierces ne sont pas compatibles avec les instances de notebooks gérés par l'utilisateur.

Restaurer une instance

Problème

Il n'est pas possible de restaurer une instance de notebooks gérés par l'utilisateur après sa suppression.

Solution

Pour sauvegarder les données de votre instance, vous pouvez enregistrer vos notebooks sur GitHub ou créer un instantané du disque.

Récupérer les données d'une instance

Problème

Il n'est pas possible de récupérer des données à partir d'une instance de notebooks gérés par l'utilisateur après sa suppression.

Solution

Pour sauvegarder les données de votre instance, vous pouvez enregistrer vos notebooks sur GitHub ou créer un instantané du disque.

Impossible d'augmenter la mémoire partagée

Problème

Vous ne pouvez pas augmenter la mémoire partagée sur une instance existante de notebooks gérés par l'utilisateur.

Solution

Toutefois, vous pouvez spécifier une taille de mémoire partagée lorsque vous créez une instance de notebooks gérés par l'utilisateur à l'aide de la clé de métadonnées container-custom-params, avec une valeur semblable à celle-ci :

--shm-size=SHARED_MEMORY_SIZE gb

Remplacez SHARED_MEMORY_SIZE par la taille souhaitée, exprimée en Go.

Procédures utiles

Cette section décrit des procédures qui pourraient vous être utiles.

Utiliser SSH pour se connecter à une instance de notebooks gérés par l'utilisateur

Utilisez ssh pour vous connecter à votre instance en saisissant la commande suivante dans Cloud Shell ou dans tout environnement dans lequel Google Cloud CLI est installé.

gcloud compute ssh --project PROJECT_ID \
  --zone ZONE \
  INSTANCE_NAME -- -L 8080:localhost:8080

Remplacez les éléments suivants :

PROJECT_ID : ID de votre projet
ZONE : zone Google Cloud dans laquelle se trouve votre instance.
INSTANCE_NAME : nom de l'instance

Vous pouvez également vous connecter à votre instance en ouvrant la page d'informations Compute Engine de votre instance, puis en cliquant sur le bouton SSH.

Se réenregistrer auprès du serveur de proxy d'inversion

Pour réenregistrer l'instance de notebooks gérés par l'utilisateur auprès du serveur de proxy d'inversion interne, vous pouvez arrêter et démarrer la VM à partir de la page Notebooks gérés par l'utilisateur, ou utiliser SSH pour vous connecter à l'instance de notebooks gérés par l'utilisateur et saisir la commande suivante :

cd /opt/deeplearning/bin
sudo ./attempt-register-vm-on-proxy.sh

Vérifier l'état du service Docker

Pour vérifier l'état du service Docker, vous pouvez utiliser ssh pour vous connecter à votre instance de notebooks gérés par l'utilisateur, puis saisir la commande suivante :

sudo service docker status

Vérifier que l'agent de proxy inverse est en cours d'exécution

Pour vérifier si l'agent de proxy inverse du notebook est en cours d'exécution, utilisez ssh pour vous connecter à votre instance de notebooks gérés par l'utilisateur, puis saisissez la commande suivante :

# Confirm Inverting Proxy agent Docker container is running (proxy-agent)
sudo docker ps

# Verify State.Status is running and State.Running is true.
sudo docker inspect proxy-agent

# Grab logs
sudo docker logs proxy-agent

Vérifier l'état du service Jupyter et collecter les journaux

Pour vérifier l'état du service Jupyter, vous pouvez utiliser ssh pour vous connecter à votre instance de notebooks gérés par l'utilisateur, puis saisir la commande suivante :

sudo service jupyter status

Pour collecter les journaux du service Jupyter, procédez comme suit :

sudo journalctl -u jupyter.service --no-pager

Vérifier que l'API interne Jupyter est active

L'API Jupyter doit toujours s'exécuter sur le port 8080. Pour vérifier cela, inspectez les syslogs de l'instance pour trouver une entrée semblable à la suivante :

Jupyter Server ... running at:
http://localhost:8080

Pour vérifier que l'API interne Jupyter est active, vous pouvez utiliser SSH pour vous connecter à votre instance de notebooks gérés par l'utilisateur, puis saisir la commande suivante :

curl http://127.0.0.1:8080/api/kernelspecs

Vous pouvez également mesurer le temps nécessaire à l'API pour répondre en cas de requêtes trop longues :

time curl -V http://127.0.0.1:8080/api/status
time curl -V http://127.0.0.1:8080/api/kernels
time curl -V http://127.0.0.1:8080/api/connections

Pour exécuter ces commandes dans votre instance Vertex AI Workbench, ouvrez JupyterLab et créez un terminal.

Redémarrer le service Docker

Pour redémarrer le service Docker, vous pouvez arrêter et démarrer la VM à partir de la page Notebooks gérés par l'utilisateur, ou utiliser ssh pour vous connecter à votre instance de notebooks gérés par l'utilisateur, puis saisir la commande suivante :

sudo service docker restart

Redémarrer l'agent de proxy inverse

Pour redémarrer l'agent de proxy inverse, vous pouvez arrêter et démarrer la VM à partir de la page Notebooks gérés par l'utilisateur ou utiliser ssh pour vous connecter à votre instance de notebooks gérés par l'utilisateur, puis saisir la commande suivante :

sudo docker restart proxy-agent

Redémarrer le service Jupyter

Pour redémarrer le service Jupyter, vous pouvez arrêter et démarrer la VM à partir de la page Notebooks gérés par l'utilisateur ou utiliser ssh pour vous connecter à votre instance de notebooks gérés par l'utilisateur, puis saisir la commande suivante :

sudo service jupyter restart

Redémarrer l'agent de collecte de notebooks

Le service d'agent de collecte de notebooks exécute un processus Python en arrière-plan qui vérifie l'état des services principaux de l'instance Vertex AI Workbench.

Pour redémarrer le service d'agent de collecte de notebooks, vous pouvez arrêter et démarrer la VM à partir de la console Google Cloud ou utiliser SSH pour vous connecter à votre instance Vertex AI Workbench, puis saisir :

sudo systemctl stop notebooks-collection-agent.service

suivi de :

sudo systemctl start notebooks-collection-agent.service

Pour exécuter ces commandes dans votre instance Vertex AI Workbench, ouvrez JupyterLab et créez un terminal.

Modifier le script de l'agent de collecte de notebooks

Pour accéder au script et le modifier, ouvrez un terminal dans notre instance ou utilisez SSH pour vous connecter à votre instance Vertex AI Workbench, puis saisissez :

nano /opt/deeplearning/bin/notebooks_collection_agent.py

N'oubliez pas d'enregistrer le fichier après l'avoir modifié.

Vous devez ensuite redémarrer le service d'agent de collecte de notebooks.

Vérifier que l'instance peut résoudre les domaines DNS requis

Pour vérifier que l'instance peut résoudre les domaines DNS requis, vous pouvez utiliser SSH pour vous connecter à votre instance de notebooks gérés par l'utilisateur, puis saisir :

host notebooks.googleapis.com
host *.notebooks.cloud.google.com
host *.notebooks.googleusercontent.com
host *.kernels.googleusercontent.com

ou :

curl --silent --output /dev/null "https://notebooks.cloud.google.com"; echo $?

Si Dataproc est activé sur l'instance, vous pouvez vérifier qu'elle résout *.kernels.googleusercontent.com en exécutant la commande suivante :

curl --verbose -H "Authorization: Bearer $(gcloud auth print-access-token)" https://${PROJECT_NUMBER}-dot-${REGION}.kernels.googleusercontent.com/api/kernelspecs | jq .

Pour exécuter ces commandes dans votre instance Vertex AI Workbench, ouvrez JupyterLab et créez un terminal.

Créer une copie des données utilisateur sur une instance

Pour stocker une copie des données utilisateur d'une instance dans Cloud Storage, suivez la procédure suivante.

Créer un bucket Cloud Storage (facultatif)

Dans le même projet que celui où se trouve votre instance, créez un bucket Cloud Storage dans lequel vous pouvez stocker vos données utilisateur. Si vous disposez déjà d'un bucket Cloud Storage, ignorez cette étape.

Create a Cloud Storage bucket:
```
gcloud storage buckets create gs://BUCKET_NAME
```
Replace BUCKET_NAME with a bucket name that meets the bucket naming requirements.

Copier vos données utilisateur

Dans l'interface JupyterLab de votre instance, sélectionnez Fichier > Nouveau > Terminal pour ouvrir une fenêtre de terminal. Pour les instances de notebooks gérés par l'utilisateur, vous pouvez vous connecter au terminal de votre instance à l'aide de SSH.
Utilisez gcloud CLI pour copier vos données utilisateur dans un bucket Cloud Storage. L'exemple de commande suivant copie tous les fichiers du répertoire /home/jupyter/ de votre instance dans un répertoire situé dans un bucket Cloud Storage.
```
gcloud storage cp /home/jupyter/* gs://BUCKET_NAMEPATH --recursive
```
Remplacez les éléments suivants :
- BUCKET_NAME : nom du bucket Cloud Storage.
- PATH : chemin d'accès au répertoire dans lequel vous souhaitez copier vos fichiers, par exemple : /copy/jupyter/

Examiner une instance bloquée lors du provisionnement à l'aide de gcpdiag

gcpdiag est un outil Open Source. Il ne s'agit pas d'un produit Google Cloud faisant l'objet d'une assistance officielle. Vous pouvez utiliser l'outil gcpdiag pour vous aider à identifier et à résoudre les problèmes liés au projet Google Cloud. Pour plus d'informations, consultez le projet gcpdiag sur GitHub.

Ce runbook gcpdiag examine les causes potentielles pour lesquelles une instance Vertex AI Workbench peut rester bloquée dans l'état de provisionnement, y compris les domaines suivants :

État : vérifie l'état actuel de l'instance pour s'assurer qu'elle est bloquée au niveau du provisionnement et qu'elle n'est pas arrêtée ni active.
Image du disque de démarrage de la VM Compute Engine de l'instance : vérifie si l'instance a été créée avec un conteneur personnalisé, une image workbench-instances officielle, des images Deep Learning VM Image ou des images non compatibles qui pourraient empêcher l'instance de se provisionner.
Scripts personnalisés : vérifie si l'instance utilise des scripts de démarrage ou post-démarrage personnalisés qui modifient le port Jupyter par défaut ou rompent les dépendances qui pourraient empêcher l'instance de se provisionner.
Version de l'environnement : vérifie si l'instance utilise la dernière version de l'environnement en vérifiant sa possibilité de mise à niveau. Les versions antérieures peuvent entraîner un blocage de l'instance à l'état de provisionnement.
Performances de la VM Compute Engine de l'instance : vérifie les performances actuelles de la VM pour s'assurer qu'elle n'est pas affectée par une utilisation élevée du processeur, une mémoire insuffisante ou des problèmes d'espace disque qui pourraient perturber les opérations normales.
Journalisation du port série ou du système de l'instance Compute Engine : vérifie si l'instance dispose de journaux de port série, qui sont analysés pour s'assurer que Jupyter s'exécute sur le port 127.0.0.1:8080.
Accès SSH et terminal Compute Engine de l'instance : vérifie si la VM Compute Engine de l'instance est en cours d'exécution afin que l'utilisateur puisse utiliser SSH et ouvrir un terminal pour vérifier que l'espace utilisé dans "home/jupyter" est inférieur à 85 %. Si aucun espace n'est disponible, l'instance peut rester bloquée à l'état de provisionnement.
Adresse IP externe désactivée : vérifie si l'accès à l'adresse IP externe est désactivé. Une configuration réseau incorrecte peut empêcher l'instance de provisionner.

console Google Cloud

Terminez l'exécution, puis copiez la commande suivante.

gcpdiag runbook vertex/workbench-instance-stuck-in-provisioning \
    --project=PROJECT_ID \
    --parameter instance_name=INSTANCE_NAME \
    --parameter zone=ZONE

Ouvrez la console Google Cloud et activez Cloud Shell.

Ouvrir la console Cloud

Collez la commande copiée.
Exécutez la commande gcpdiag, qui télécharge l'image Docker gcpdiag, puis effectue des vérifications de diagnostic. Le cas échéant, suivez les instructions de sortie pour corriger les échecs de vérification.

Docker

Vous pouvez exécuter gcpdiag à l'aide d'un wrapper qui démarre gcpdiag dans un conteneur Docker. Docker ou Podman doivent être installés.

Copiez et exécutez la commande suivante sur votre station de travail locale :
```
curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
```

Exécutez la commande gcpdiag.

./gcpdiag runbook vertex/workbench-instance-stuck-in-provisioning \
    --project=PROJECT_ID \
    --parameter instance_name=INSTANCE_NAME \
    --parameter zone=ZONE

Affichez les paramètres disponibles pour ce runbook.

Remplacez les éléments suivants :

PROJECT_ID : ID du projet contenant la ressource.
INSTANCE_NAME : nom de l'instance Vertex AI Workbench cible dans votre projet.
ZONE : zone dans laquelle se trouve votre instance Vertex AI Workbench cible.

Options utiles :

--project : L'PROJECT_ID
--universe-domain: le cas échéant, le domaine cloud souverain du partenaire de confiance hébergeant la ressource.
--parameter ou -p: paramètres du runbook

Pour obtenir la liste et la description de toutes les options de l'outil gcpdiag, consultez les instructions d'utilisation de gcpdiag.

Résoudre les problèmes liés à Vertex AI Workbench

Instances Vertex AI Workbench

Se connecter à JupyterLab et l'ouvrir

S'il ne se passe rien après avoir cliqué sur "Ouvrir JupyterLab"

Impossible d'accéder au terminal dans une instance Vertex AI Workbench

Erreur 502 lors de l'ouverture de JupyterLab

Le notebook ne répond pas

Impossible de se connecter à l'instance Vertex AI Workbench via SSH

Le quota de GPU a été dépassé

Créer des instances Vertex AI Workbench

L'instance reste en attente indéfiniment ou est bloquée en état de provisionnement

Impossible de créer une instance dans un réseau VPC partagé

Autorisations requises

Impossible de créer une instance Vertex AI Workbench avec un conteneur personnalisé

Le bouton d'installation du stockage partagé ne s'affiche pas

Erreur 599 lors de l'utilisation de Dataproc

Impossible d'installer l'extension JupyterLab tierce

Impossible de modifier la machine virtuelle sous-jacente

Les packages pip ne sont plus disponibles après l'ajout de l'environnement Conda.

Impossible de copier ou d'accéder aux données d'une instance avec accès utilisateur unique

Arrêt inattendu

Les journaux de l'instance affichent des erreurs de connexion ou de délai avant expiration

Les journaux d'instance indiquent "Impossible de contacter l'API Jupyter" ou "ReadTimeoutError"

Notebooks gérés

Se connecter à JupyterLab et l'ouvrir

S'il ne se passe rien après avoir cliqué sur "Ouvrir JupyterLab"

Impossible de se connecter à l'instance de notebooks gérés via SSH

Impossible d'accéder au terminal d'une instance de notebooks gérés

Erreur 502 lors de l'ouverture de JupyterLab

L'ouverture d'un notebook génère une erreur 524 (Le délai d'attente a expiré).

Le notebook ne répond pas

Migrer vers des instances Vertex AI Workbench

Impossible de trouver un kernel qui figurait dans l'instance de notebooks gérés

Version de framework différente dans l'instance migrée

Les GPU ne sont pas migrés vers la nouvelle instance Vertex AI Workbench

Différence au niveau du type de machine de l'instance migrée

Le quota de GPU a été dépassé

Utiliser des images de conteneurs

L'image de conteneur n'apparaît pas en tant que noyau dans JupyterLab

Le notebook se déconnecte pendant un job de longue durée

Utiliser l'exécuteur

Installations de packages non disponibles pour l'exécuteur

Erreurs 401 ou 403 lors de l'exécution du code de notebook à l'aide de l'exécuteur

Erreur exited with a non-zero status of 127 lors de l'utilisation de l'exécuteur

Message d'erreur indiquant une configuration de mise en réseau de services non valide

Impossible d'installer l'extension JupyterLab tierce

Impossible de copier ou d'accéder aux données d'une instance avec accès utilisateur unique

Arrêt inattendu

Restaurer une instance

Récupérer les données d'une instance

Créer des instances de notebooks gérés

Erreur : Problème lors de la création d'une connexion

La création d'une instance entraîne une erreur de disponibilité des ressources

Le démarrage d'une instance entraîne une erreur de disponibilité des ressources

No route to host sur les connexions sortantes depuis des notebooks gérés

Notebooks gérés par l'utilisateur

Se connecter à JupyterLab et l'ouvrir

S'il ne se passe rien après avoir cliqué sur "Ouvrir JupyterLab"

Aucun accès à JupyterLab avec le serveur proxy inverse

Impossible de se connecter à l'instance de notebooks gérés par l'utilisateur via SSH

L'ouverture d'une instance de notebooks gérés par l'utilisateur génère une erreur 403 (Interdit)

Aucun accès à JupyterLab, mode utilisateur unique activé

L'ouverture d'un notebook génère une erreur 504 (Expiration du délai de la passerelle)

L'ouverture d'un notebook génère une erreur 524 (Le délai d'attente a expiré).

L'ouverture d'un notebook génère une erreur 598 (Expiration du délai de lecture du réseau)

Le notebook ne répond pas

Migrer vers des instances Vertex AI Workbench

Impossible de trouver R, Beam ou d'autres kernels qui figuraient dans l'instance de notebooks gérés par l'utilisateur

Impossible de configurer une instance Dataproc Hub dans l'instance Vertex AI Workbench

Version de framework différente dans l'instance migrée

Les GPU ne sont pas migrés vers la nouvelle instance Vertex AI Workbench

Différence au niveau du type de machine de l'instance migrée

Utiliser des fichiers

Le téléchargement des fichiers est désactivé, mais l'utilisateur peut toujours télécharger des fichiers

Les fichiers téléchargés sont tronqués ou leur téléchargement n'est pas terminé

Après le redémarrage de la VM, les fichiers locaux ne peuvent plus être référencés depuis le terminal de notebook

Créer des instances de notebooks gérées par l'utilisateur

Le quota de GPU a été dépassé

L'instance reste en attente indéfiniment

Impossible de créer une instance de notebooks gérés par l'utilisateur (autorisations insuffisantes)

Les packages `pip` ne sont plus disponibles après l'ajout de l'environnement Conda.

Erreur `exited with a non-zero status of 127` lors de l'utilisation de l'exécuteur

`No route to host` sur les connexions sortantes depuis des notebooks gérés

Créer une instance génère une erreur `Permission denied`

Créer une instance génère une erreur `already exists`

Échec de l'état de `docker-proxy-agent`

Échec de l'état de `docker-service`

Échec de l'état de `jupyter-service`

Échec de l'état de `jupyter-api`