Auf dieser Seite werden Schritte zur Fehlerbehebung beschrieben, die bei Problemen mit Vertex AI Workbench hilfreich sein können.
Informationen zur Verwendung anderer Komponenten von Vertex AI finden Sie unter Fehlerbehebung für Vertex AI.
Klicken Sie auf ein Thema, um die Inhalte dieser Seite zu filtern:
Vertex AI Workbench-Instanzen
In diesem Abschnitt werden Schritte zur Fehlerbehebung für Vertex AI Workbench-Instanzen beschrieben.
Verbindung zu JupyterLab herstellen und JupyterLab öffnen
In diesem Abschnitt werden Schritte zur Fehlerbehebung beim Herstellen einer Verbindung zu und beim Öffnen von JupyterLab beschrieben.
Nach dem Klicken auf JupyterLab passiert nichts
Problem
Wenn Sie auf JupyterLab öffnen klicken, passiert nichts.
Lösung
Prüfen Sie, ob Ihr Browser das automatische Öffnen neuer Tabs blockiert. JupyterLab wird in einem neuen Browsertab geöffnet.
Zugriff auf das Terminal in einer Vertex AI Workbench-Instanz nicht möglich
Problem
Wenn Sie nicht auf das Terminal zugreifen können oder das Terminalfenster im Launcher nicht gefunden wird, liegt dies möglicherweise daran, dass auf Ihrer Vertex AI Workbench-Instanz der Terminalzugriff nicht aktiviert ist.
Lösung
Sie müssen eine neue Vertex AI Workbench-Instanz mit aktivierter Option zum Terminalzugriff erstellen. Diese Option kann nach dem Erstellen der Instanz nicht mehr geändert werden.
Beim Öffnen von JupyterLab wird ein 502-Fehler angezeigt
Problem
Der Fehler 502 bedeutet möglicherweise, dass die Vertex AI Workbench-Instanz noch nicht bereit ist.
Lösung
Warten Sie einige Minuten, aktualisieren Sie den Browsertab der Google Cloud Console und versuchen Sie es dann noch einmal.
Das Notebook reagiert nicht
Problem
Ihre Vertex AI Workbench-Instanz führt keine Zellen aus oder scheint eingefroren zu sein.
Lösung
Starten Sie zuerst den Kernel neu. Klicken Sie dazu im oberen Menü auf Kernel und dann auf Kernel neu starten. Wenn dies nicht funktioniert, versuchen Sie folgendes:
- Aktualisieren Sie die JupyterLab-Browserseite. Nicht gespeicherte Zellenausgaben werden nicht beibehalten. Daher müssen Sie diese Zellen noch einmal ausführen, um die Ausgabe neu zu generieren.
- Instanz zurücksetzen.
Verbindung zu einer Vertex AI Workbench-Instanz über SSH kann nicht hergestellt werden
Problem
Sie können keine Verbindung zu Ihrer Instanz über SSH über ein Terminalfenster herstellen.
Vertex AI Workbench-Instanzen verwenden OS Login, um den SSH-Zugriff zu ermöglichen. Wenn Sie eine Instanz erstellen, aktiviert Vertex AI Workbench standardmäßig OS Login, indem der Metadatenschlüssel enable-oslogin
auf TRUE
gesetzt wird. Wenn Sie keine SSH-Verbindung zur Instanz herstellen können, muss dieser Metadatenschlüssel möglicherweise auf TRUE
gesetzt werden.
Lösung
Die Verbindung zu einer Vertex AI Workbench-Instanz über die Google Cloud Console wird nicht unterstützt. Wenn Sie keine Verbindung zu Ihrer Instanz über SSH über ein Terminalfenster herstellen können, beachten Sie Folgendes:
Um den Metadatenschlüssel enable-oslogin
auf TRUE
zu setzen, verwenden Sie die Methode projects.locations.instances.patch
in der Notebooks API oder den Befehl gcloud workbench instances update
im Google Cloud SDK.
Das GPU-Kontingent wurde überschritten
Problem
Sie können keine Vertex AI Workbench-Instanz mit GPUs erstellen.
Lösung
Prüfen Sie auf der Seite Kontingente die Anzahl der in Ihrem Projekt verfügbaren GPUs. Wenn auf der Seite Kontingente keine GPUs aufgeführt sind oder Sie zusätzliche GPU-Kontingente benötigen, können Sie eine Erhöhung des Kontingents beantragen. Weitere Informationen finden Sie unter Höheres Kontingentlimit anfordern.
Vertex AI Workbench-Instanzen erstellen
In diesem Abschnitt wird beschrieben, wie Sie Probleme beim Erstellen von Vertex AI Workbench-Instanzen beheben.
Instanz bleibt auf unbestimmte Zeit im Status „Ausstehend“ oder hängt im Bereitstellungsstatus fest
Problem
Nachdem Sie eine Vertex AI Workbench-Instanz erstellt haben, bleibt sie unbegrenzt im Status „Ausstehend“. In den Protokollen für die serielle Kommunikation kann ein Fehler wie der folgende angezeigt werden:
Could not resolve host: notebooks.googleapis.com
Wenn der Bereitstellungsstatus Ihrer Instanz steckenbleibt, kann das an einer ungültigen Konfiguration für das private Netzwerk für Ihre Instanz liegen.
Lösung
Folgen Sie der Anleitung im Abschnitt In den Instanzprotokollen werden Verbindungs- oder Zeitüberschreitungsfehler angezeigt.
Instanz kann nicht in einem freigegebenen VPC-Netzwerk erstellt werden
Problem
Der Versuch, eine Instanz in einem freigegebenen VPC-Netzwerk zu erstellen, führt zu einer Fehlermeldung wie dieser:
Required 'compute.subnetworks.use' permission for 'projects/network-administration/regions/us-central1/subnetworks/v'
Lösung
Das Problem besteht darin, dass das Notebooks-Dienstkonto versucht, die Instanz ohne die richtigen Berechtigungen zu erstellen.
Um sicherzustellen, dass das Notebooks-Dienstkonto die erforderlichen Berechtigungen hat, damit das Notebooks-Dienstkonto eine Vertex AI Workbench-Instanz in einem freigegebenen VPC-Netzwerk erstellen kann, bitten Sie Ihren Administrator, dem Notebooks-Dienstkonto die IAM-Rolle "Compute-Netzwerknutzer" (roles/compute.networkUser
) im Hostprojekt zuzuweisen.
Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.
Diese vordefinierte Rolle enthält die Berechtigungen, die erforderlich sind, damit das Notebook-Dienstkonto eine Vertex AI Workbench-Instanz in einem freigegebenen VPC-Netzwerk erstellen kann. Erweitern Sie den Abschnitt Erforderliche Berechtigungen, um die erforderlichen Berechtigungen anzuzeigen:
Erforderliche Berechtigungen
Die folgenden Berechtigungen sind erforderlich, damit das Notebooks-Dienstkonto eine Vertex AI Workbench-Instanz in einem freigegebenen VPC-Netzwerk erstellen kann:
-
So verwenden Sie Subnetzwerke:
compute.subnetworks.use
Ihr Administrator kann dem Notebooks-Dienstkonto möglicherweise auch diese Berechtigungen mit benutzerdefinierten Rollen oder anderen vordefinierten Rollen erteilen.
kann keine Vertex AI Workbench-Instanz mit einem benutzerdefinierten Container erstellen
Problem
Beim Erstellen einer Vertex AI Workbench-Instanz in der Google Cloud Console können Sie keinen benutzerdefinierten Container verwenden.
Lösung
Das Hinzufügen eines benutzerdefinierten Containers zu einer Vertex AI Workbench-Instanz wird nicht unterstützt. Sie können einen benutzerdefinierten Container auch nicht über die Google Cloud Console hinzufügen.
Das Hinzufügen einer Conda-Umgebung statt eines benutzerdefinierten Containers wird empfohlen.
Sie können einer Vertex AI Workbench-Instanz mithilfe der Notebooks API einen benutzerdefinierten Container hinzufügen. Diese Funktion wird jedoch nicht unterstützt.
Schaltfläche „Freigegebenen Speicher bereitstellen“ ist nicht vorhanden
Problem
Die Schaltfläche Freigegebenen Speicher bereitstellen befindet sich nicht auf dem Tab Dateibrowser der JupyterLab-Benutzeroberfläche.
Lösung
Die Berechtigung storage.buckets.list
ist erforderlich, damit die Schaltfläche Freigegebenen Speicher bereitstellen in der JupyterLab-Oberfläche Ihrer Vertex AI Workbench-Instanz angezeigt wird. Bitten Sie Ihren Administrator, dem Dienstkonto Ihrer Vertex AI Workbench-Instanz die Berechtigung storage.buckets.list
für das Projekt zu erteilen.
Fehler 599 bei Verwendung von Dataproc
Problem
Wenn Sie versuchen, eine Dataproc-kompatible Instanz zu erstellen, wird eine Fehlermeldung wie die folgende ausgegeben:
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.)
Lösung
Fügen Sie in Ihrer Cloud DNS-Konfiguration einen Cloud DNS-Eintrag für die Domain *.googleusercontent.com
hinzu.
JupyterLab-Erweiterung von Drittanbietern kann nicht installiert werden
Problem
Der Versuch, eine JupyterLab-Erweiterung eines Drittanbieters zu installieren, führt zu einer Error: 500
-Nachricht.
Lösung
JupyterLab-Erweiterungen von Drittanbietern werden in Vertex AI Workbench-Instanzen nicht unterstützt.
Die zugrunde liegende virtuelle Maschine kann nicht bearbeitet werden
Problem
Wenn Sie versuchen, die zugrunde liegende virtuelle Maschine (VM) einer Vertex AI Workbench-Instanz zu bearbeiten, erhalten Sie möglicherweise eine Fehlermeldung ähnlich der folgenden:
Current principal doesn't have permission to mutate this resource.
Lösung
Dieser Fehler tritt auf, weil Sie die zugrunde liegende VM einer Instanz nicht mit der Google Cloud Console oder der Compute Engine API bearbeiten können.
Verwenden Sie zum Bearbeiten der zugrunde liegenden VM einer Vertex AI Workbench-Instanz die Methode projects.locations.instances.patch
in der Notebooks API oder den Befehl gcloud workbench instances update
im Google Cloud SDK.
pip
-Pakete sind nach dem Hinzufügen der Conda-Umgebung nicht verfügbar
Problem
Ihre pip
-Pakete sind nicht mehr verfügbar, nachdem Sie einen Conda-basierten Kernel hinzugefügt haben.
Lösung
Weitere Informationen zur Behebung des Problems finden Sie unter Conda-Umgebung hinzufügen. Versuchen Sie Folgendes:
Prüfen Sie, ob Sie die Variable
DL_ANACONDA_ENV_HOME
verwendet haben und ob sie den Namen Ihrer Umgebung enthält.Prüfen Sie, ob sich
pip
in einem Pfad befindet, deropt/conda/envs/ENVIRONMENT/bin/pip
ähnelt. Sie können den Befehlwhich pip
ausführen, um den Pfad abzurufen.
Auf eine Instanz mit Einzelnutzerzugriff kann nicht zugegriffen oder ihre Daten können nicht kopiert werden
Problem
Auf die Daten einer Instanz mit Einzelnutzerzugriff kann nicht zugegriffen werden.
Bei Vertex AI Workbench-Instanzen, die mit Einzelnutzerzugriff eingerichtet sind, kann nur der angegebene Einzelnutzer (der Inhaber) auf die Daten in der Instanz zugreifen.
Lösung
Öffnen Sie eine Supportanfrage, um auf die Daten zuzugreifen oder sie zu kopieren, wenn Sie nicht der Inhaber der Instanz sind.
Unerwartetes Herunterfahren
Problem
Ihre Vertex AI Workbench-Instanz wird unerwartet heruntergefahren.
Lösung
Wenn Ihre Instanz unerwartet heruntergefahren wird, könnte dies daran liegen, dass Herunterfahren bei Inaktivität initiiert wurde.
Wenn Sie das Herunterfahren bei Inaktivität aktiviert haben, wird Ihre Instanz heruntergefahren, wenn für den angegebenen Zeitraum keine Kernel-Aktivität vorhanden ist. Das Ausführen einer Zelle oder eines neuen Ausgabedrucks auf einem Notebook ist beispielsweise eine Aktivität, die den Timer für das Zeitlimit bei Inaktivität zurücksetzt. Die CPU-Nutzung setzt den Timer für das Zeitlimit bei Inaktivität nicht zurück.
In Instanzprotokollen werden Verbindungs- oder Zeitüberschreitungsfehler angezeigt
Problem
In den Protokollen Ihrer Vertex AI Workbench-Instanz werden Verbindungs- oder Zeitüberschreitungsfehler angezeigt.
Lösung
Wenn Sie in den Protokollen der Instanz Verbindungs- oder Zeitüberschreitungsfehler feststellen, prüfen Sie, ob der Jupyter-Server auf Port 8080 ausgeführt wird. Folgen Sie der Anleitung im Abschnitt Prüfen, ob die interne Jupyter API aktiv ist.
Wenn Sie External IP
deaktiviert haben und ein privates VPC-Netzwerk verwenden, lesen Sie auch die Dokumentation zu den Netzwerkkonfigurationsoptionen.
Berücksichtigen Sie Folgendes:
Sie müssen den privaten Google-Zugriff für das ausgewählte Subnetz in derselben Region aktivieren, in der sich Ihre Instanz im VPC-Hostprojekt befindet. Weitere Informationen zum Konfigurieren des privaten Google-Zugriffs finden Sie in der Dokumentation zum privaten Google-Zugriff.
Wenn Sie Cloud DNS verwenden, muss die Instanz die erforderlichen Cloud DNS-Domains auflösen können, die in der Dokumentation zu den Netzwerkkonfigurationsoptionen angegeben sind. Führen Sie dazu die Schritte im Abschnitt Prüfen, ob die Instanz die erforderlichen DNS-Domains auflösen kann aus.
In den Instanzprotokollen wird „Keine Verbindung zur Jupyter API herstellbar“ und „Zeitüberschreitung beim Lesen“ angezeigt.
Problem
In den Protokollen Ihrer Vertex AI Workbench-Instanz wird ein Fehler angezeigt, z. B.:
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
Lösung
Folgen Sie der Anleitung im Abschnitt In Instanzprotokollen werden Verbindungs- oder Zeitüberschreitungsfehler angezeigt.
Sie können auch versuchen, das Script des Notebooks Collection Agents zu ändern, um HTTP_TIMEOUT_SESSION
in einen größeren Wert zu ändern, z. B. 60
. So können Sie prüfen, ob die Anfrage fehlgeschlagen ist, weil der Aufruf zu lange gebraucht hat mit dem Antworten oder die angeforderte URL nicht erreicht werden kann.
docker0
-Adresse steht in Konflikt mit der VPC-Adressierung
Problem
Standardmäßig wird die docker0
-Schnittstelle mit der IP-Adresse 172.17.0.1/16
erstellt. Dies kann zu Konflikten mit der IP-Adressierung in Ihrem VPC-Netzwerk führen, sodass die Instanz keine Verbindung zu anderen Endpunkten mit 172.17.0.1/16
-Adressen herstellen kann.
Lösung
Sie können die docker0
-Schnittstelle mit einer IP-Adresse erstellen lassen, die nicht mit Ihrem VPC-Netzwerk in Konflikt steht. Verwenden Sie dazu das folgende Start-Script nach der Ersteinrichtung und legen Sie das Verhalten des Start-Scripts nach der Ersteinrichtung auf run_once
fest.
#!/bin/bash # Wait for Docker to be fully started while ! systemctl is-active docker; do sleep 1 done # Stop the Docker service systemctl stop docker # Modify /etc/docker/daemon.json cat </etc/docker/daemon.json { "bip": "CUSTOM_DOCKER_IP/16" } EOF # Restart the Docker service systemctl start docker
Verwaltete Notebooks
In diesem Abschnitt werden Schritte zur Fehlerbehebung für verwaltete Notebooks beschrieben.
Verbindung zu JupyterLab herstellen und JupyterLab öffnen
In diesem Abschnitt wird beschrieben, wie Sie Probleme beim Herstellen einer Verbindung zu und beim Öffnen von JupyterLab beheben.
Nach dem Klicken auf JupyterLab passiert nichts
Problem
Wenn Sie auf JupyterLab öffnen klicken, passiert nichts.
Lösung
Prüfen Sie, ob Ihr Browser das automatische Öffnen neuer Tabs blockiert. JupyterLab wird in einem neuen Browsertab geöffnet.
Verbindung zu einer verwalteten Notebooks-Instanz über SSH kann nicht hergestellt werden
Problem
Es gibt keine Möglichkeit, eine Verbindung zu verwalteten Notebookinstanzen über SSH herzustellen.
Lösung
Der SSH-Zugriff auf verwaltete Notebookinstanzen ist nicht verfügbar.
Zugriff auf Terminal in einer verwalteten Notebookinstanz nicht möglich
Problem
Wenn Sie nicht auf das Terminal zugreifen können oder das Terminalfenster im Launcher nicht gefunden wird, liegt dies möglicherweise daran, dass auf Ihrer verwalteten Notebookinstanz kein Terminalzugriff aktiviert ist.
Lösung
Sie müssen eine neue verwaltete Notebookinstanz mit aktivierter Option zum Terminalzugriff erstellen. Diese Option kann nach dem Erstellen der Instanz nicht mehr geändert werden.
Beim Öffnen von JupyterLab wird ein 502-Fehler angezeigt
Problem
Der Fehler 502 bedeutet möglicherweise, dass die verwaltete Notebookinstanz noch nicht bereit ist.
Lösung
Warten Sie einige Minuten, aktualisieren Sie den Browsertab der Google Cloud Console und versuchen Sie es dann noch einmal.
Beim Öffnen eines Notebooks wird ein 524-Fehler (A Timeout Occurred) angezeigt.
Problem
Ein 524-Fehler ist normalerweise ein Hinweis darauf, dass der Backinging-Proxy-Agent keine Verbindung zum Proxy-Server des Back-Ends herstellt oder die Anfragen auf der Back-End-Serverseite (Jupyter) zu lange dauern. Häufige Ursachen für diesen Fehler sind Netzwerkprobleme, der Inverting Proxy-Agent wird nicht ausgeführt oder der Jupyter-Dienst wird nicht ausgeführt.
Lösung
Prüfen Sie, ob Ihre verwaltete Notebookinstanz gestartet wird.
Das Notebook reagiert nicht
Problem
Verwaltete Notebooks Instanz führt keine Zellen aus oder scheint eingefroren zu sein.
Lösung
Starten Sie zuerst den Kernel neu. Klicken Sie dazu im oberen Menü auf Kernel und dann auf Kernel neu starten. Wenn dies nicht funktioniert, versuchen Sie folgendes:
- Aktualisieren Sie die JupyterLab-Browserseite. Nicht gespeicherte Zellenausgaben werden nicht beibehalten. Daher müssen Sie diese Zellen noch einmal ausführen, um die Ausgabe neu zu generieren.
- Instanz zurücksetzen.
Zu Vertex AI Workbench-Instanzen migrieren
In diesem Abschnitt werden Methoden zur Diagnose und Behebung von Problemen bei der Migration von einer verwalteten Notebooks-Instanz zu einer Vertex AI Workbench-Instanz beschrieben.
Kernel in der verwalteten Notebookinstanz nicht gefunden
Problem
Ein Kernel, der sich in Ihrer verwalteten Notebooks-Instanz befand, wird in der Vertex AI Workbench-Instanz, zu der Sie migriert sind, nicht angezeigt.
Benutzerdefinierte Container werden in verwalteten Notebooks als Kernel angezeigt. Das Vertex AI Workbench-Migrationstool unterstützt keine Migration benutzerdefinierter Container.
Lösung
Um dieses Problem zu beheben, fügen Sie Ihrer Vertex AI Workbench-Instanz eine Conda-Umgebung hinzu.
Andere Version des Frameworks in der migrierten Instanz
Problem
Ein Framework in Ihrer verwalteten Notebooks-Instanz hatte eine andere Version als das Framework in der Vertex AI Workbench-Instanz, zu der Sie migriert sind.
Vertex AI Workbench-Instanzen bieten eine Standardauswahl an Framework-Versionen. Das Migrationstool fügt keine Frameworkversionen aus Ihrer ursprünglichen verwalteten Notebookinstanz hinzu. Weitere Informationen finden Sie unter Standardverhalten des Migrationstools.
Lösung
Wenn Sie eine bestimmte Version eines Frameworks hinzufügen möchten, fügen Sie Ihrer Vertex AI Workbench-Instanz eine Conda-Umgebung hinzu.
GPUs werden nicht in die neue Vertex AI Workbench-Instanz migriert
Problem
GPUs, die sich in Ihrer verwalteten Notebooks-Instanz befanden, sind nicht in der Vertex AI Workbench-Instanz verfügbar, zu der Sie migriert sind.
Vertex AI Workbench-Instanzen unterstützen eine Reihe von Standard-GPUs. Wenn die GPUs in Ihrer ursprünglichen verwalteten Notebook-Instanz nicht verfügbar sind, wird Ihre Instanz ohne GPUs migriert.
Lösung
Nach der Migration können Sie Ihrer Vertex AI Workbench-Instanz mit der Methode projects.locations.instances.patch
in der Notebooks API oder dem Befehl gcloud workbench instances update
im Google Cloud SDK GPUs hinzufügen.
Der Maschinentyp der migrierten Instanz ist unterschiedlich
Problem
Der Maschinentyp Ihrer verwalteten Notebooks-Instanz unterscheidet sich von dem der Vertex AI Workbench-Instanz, zu der Sie migriert sind.
Vertex AI Workbench-Instanzen unterstützen nicht alle Maschinentypen. Wenn der Maschinentyp in Ihrer ursprünglichen verwalteten Notebook-Instanz nicht verfügbar ist, wird Ihre Instanz zum Maschinentyp e2-standard-4
migriert.
Lösung
Nach der Migration können Sie den Maschinentyp Ihrer Vertex AI Workbench-Instanz mit der Methode projects.locations.instances.patch
in der Notebooks API oder dem Befehl gcloud workbench instances update
im Google Cloud SDK ändern.
Das GPU-Kontingent wurde überschritten
Problem
Sie können keine verwaltete Notebookinstanz mit GPUs erstellen.
Lösung
Prüfen Sie auf der Seite Kontingente die Anzahl der in Ihrem Projekt verfügbaren GPUs. Wenn auf der Seite Kontingente keine GPUs aufgeführt sind oder Sie zusätzliche GPU-Kontingente benötigen, können Sie eine Erhöhung des Kontingents beantragen. Weitere Informationen finden Sie unter Höheres Kontingentlimit anfordern.
Container-Images verwenden
In diesem Abschnitt wird beschrieben, wie Sie Probleme bei der Verwendung von Container-Images beheben.
Container-Image wird in JupyterLab nicht als Kernel angezeigt
Problem
Container-Images ohne gültige Kernelspezifikation werden nicht erfolgreich als Kernel in JupyterLab geladen.
Lösung
Achten Sie darauf, dass Ihr Container unsere Anforderungen erfüllt. Weitere Informationen finden Sie unter Anforderungen für benutzerdefinierte Container.
Notebook-Verbindung wird bei einem Job mit langer Ausführungszeit getrennt
Problem
Wenn Sie beim Ausführen eines Jobs in einem Notebook die folgende Fehlermeldung sehen, kann das daran liegen, dass das Laden der Anfrage zu lange dauert oder die CPU- oder Arbeitsspeicherauslastung hoch ist, was dazu führen kann, dass der Jupyter-Dienst nicht mehr reagiert.
{"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"}
Lösung
Dieses Problem wird durch die Ausführung eines langwierigen Jobs in einem Notebook verursacht. Wenn Sie einen Job ausführen möchten, der möglicherweise lange dauert, wird empfohlen, den Ausführer zu verwenden.
Executor verwenden
In diesem Abschnitt wird beschrieben, wie Sie Probleme bei der Verwendung des Executors beheben.
Paketinstallationen sind für den Executor nicht verfügbar
Problem
Der Executor führt Ihren Notebookcode in einer anderen Umgebung als dem Kernel aus, in dem Sie den Code Ihrer Notebookdatei ausführen. Aus diesem Grund sind einige der installierten Pakete in der Executor-Umgebung möglicherweise nicht verfügbar.
Lösung
Informationen zum Beheben dieses Problems finden Sie unter Verfügbarkeit von Paketinstallationen für den Executor sicherstellen.
Beim Ausführen des Notebookcodes mit dem Executor wird ein 401- oder 403-Fehler angezeigt
Problem
Der Fehler 401 oder 403 beim Ausführen des Executors kann bedeuten, dass der Executor nicht auf Ressourcen zugreifen kann.
Lösung
Mögliche Ursachen finden Sie hier:
Der Executor führt Ihren Notebook-Code in einem Mandantenprojekt aus, das vom Projekt Ihrer verwalteten Notebookinstanz getrennt ist. Wenn Sie über den vom Executor ausgeführten Code auf Ressourcen zugreifen, stellt der Executor möglicherweise nicht standardmäßig eine Verbindung zum richtigen Google Cloud -Projekt her. Verwenden Sie die explizite Projektauswahl, um dieses Problem zu beheben.
Standardmäßig kann Ihre verwaltete Notebookinstanz auf Ressourcen zugreifen, die im selben Projekt vorhanden sind. Wenn Sie also den Code Ihrer Notebookdatei manuell ausführen, benötigen diese Ressourcen keine zusätzliche Authentifizierung. Da der Executor jedoch in einem separaten Mandantenprojekt ausgeführt wird, hat er nicht denselben Standardzugriff. Um dieses Problem zu beheben, authentifizieren Sie den Zugriff mithilfe von Dienstkonten.
Der Executor kann keine Anmeldedaten von Endnutzern verwenden, um den Zugriff auf Ressourcen zu authentifizieren, z. B. den Befehl
gcloud auth login
. Um dieses Problem zu beheben, authentifizieren Sie den Zugriff mithilfe von Dienstkonten.
Fehler exited with a non-zero status of 127
bei Verwendung des Executors
Problem
Ein exited with a non-zero status of 127
-Fehler bzw. „Befehl nicht gefunden“ kann auftreten, wenn Sie den Executor verwenden, um Code auf einem benutzerdefinierten Container auszuführen, auf dem die Erweiterung nbexecutor
nicht installiert ist.
Lösung
Damit Ihr benutzerdefinierter Container die Erweiterung nbexecutor
hat, können Sie ein abgeleitetes Container-Image aus einem Deep Learning Container-Image erstellen.
Deep Learning Container-Images enthalten die Erweiterung nbexecutor
.
Fehlermeldung zu ungültiger Dienstnetzwerkkonfiguration
Problem
Dieser Fehler könnte so aussehen:
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).
Das bedeutet, dass in den zugewiesenen IP-Bereichen Ihres Netzwerks keine freien Blöcke gefunden wurden.
Lösung
Verwenden Sie eine Subnetzmaske mit /24
oder weniger. Erstellen Sie einen größeren zugewiesenen IP-Adressbereich und hängen Sie diesen Bereich an, indem Sie die private Dienstverbindung für servicenetworking-googleapis-com
ändern.
Weitere Informationen finden Sie unter Netzwerk einrichten.
JupyterLab-Erweiterung von Drittanbietern kann nicht installiert werden
Problem
Der Versuch, eine JupyterLab-Erweiterung eines Drittanbieters zu installieren, führt zu einer Error: 500
-Nachricht.
Lösung
JupyterLab-Erweiterungen von Drittanbietern werden in verwalteten Notebookinstanzen nicht unterstützt.
Auf eine Instanz mit Einzelnutzerzugriff kann nicht zugegriffen oder ihre Daten können nicht kopiert werden
Problem
Auf die Daten einer Instanz mit Einzelnutzerzugriff kann nicht zugegriffen werden.
Lösung
Bei verwalteten Notebooks-Instanzen, die mit Einzelnutzerzugriff eingerichtet sind, kann nur der angegebene Einzelnutzer (der Inhaber) auf die Daten in der Instanz zugreifen.
Öffnen Sie eine Supportanfrage, um auf die Daten zuzugreifen oder sie zu kopieren, wenn Sie nicht der Inhaber der Instanz sind.
Unerwartetes Herunterfahren
Problem
Ihre Vertex AI Workbench-Instanz wird unerwartet heruntergefahren.
Lösung
Wenn Ihre Instanz unerwartet heruntergefahren wird, könnte dies daran liegen, dass Herunterfahren bei Inaktivität initiiert wurde.
Wenn Sie das Herunterfahren bei Inaktivität aktiviert haben, wird Ihre Instanz heruntergefahren, wenn für den angegebenen Zeitraum keine Kernel-Aktivität vorhanden ist. Das Ausführen einer Zelle oder eines neuen Ausgabedrucks auf einem Notebook ist beispielsweise eine Aktivität, die den Timer für das Zeitlimit bei Inaktivität zurücksetzt. Die CPU-Nutzung setzt den Timer für das Zeitlimit bei Inaktivität nicht zurück.
Instanz wiederherstellen
Problem
Das Wiederherstellen einer verwalteten Notebookinstanz nach dem Löschen wird nicht unterstützt.
Lösung
Sie können die Daten in Ihrer Instanz sichern, indem Sie Ihre Notebooks auf GitHub speichern.
Daten aus einer Instanz wiederherstellen
Problem
Die Wiederherstellung von Daten aus einer verwalteten Notebookinstanz nach dem Löschen der Instanz wird nicht unterstützt.
Lösung
Sie können die Daten von Ihrer Instanz sichern, indem Sie Ihre Notebooks auf GitHub speichern.
Verwaltete Notebookinstanzen erstellen
In diesem Abschnitt wird beschrieben, wie Sie Probleme beim Erstellen von verwalteter Notebooks Instanzen beheben.
Fehler: Problem beim Erstellen einer Verbindung
Problem
Beim Erstellen einer Instanz wird folgender Fehler angezeigt:
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'.
Lösung
Erstellen Sie einen zugewiesenen IP-Bereich, der größer als /24
ist, und hängen Sie diesen Bereich an, indem Sie die private Dienstverbindung für servicenetworking-googleapis-com
-Verbindung ändern.
Beim Erstellen einer Instanz wird ein Ressourcenverfügbarkeitsfehler ausgegeben
Problem
Sie können aufgrund eines Ressourcenverfügbarkeitsfehlers keine Instanz erstellen.
Dieser Fehler kann so aussehen:
Creating notebook INSTANCE_NAME: ZONE does not have enough resources available to fulfill the request. Retry later or try another zone in your configurations.
Ressourcenfehler treten auf, wenn Sie neue Ressourcen in einer Zone anfordern, die aufgrund der aktuellen Nichtverfügbarkeit von Compute Engine-Ressourcen wie GPUs oder CPUs Ihre Anfrage nicht bearbeiten kann.
Ressourcenfehler gelten nur für neue Ressourcenanfragen in der Zone und haben keine Auswirkungen auf vorhandene Ressourcen. Ressourcenfehler beziehen sich nicht auf Ihr Compute Engine-Kontingent. Ressourcenfehler sind temporär und können sich aufgrund schwankender Nachfrage laufend ändern.
Lösung
Versuchen Sie Folgendes, um fortzufahren:
- Erstellen Sie eine Instanz mit einem anderen Maschinentyp.
- Erstellen Sie die Instanz in einer anderen Zone.
- Wiederholen Sie die Anfrage später.
- Reduzieren Sie die Menge der angeforderten Ressourcen. Versuchen Sie beispielsweise, eine Instanz mit weniger GPUs, Laufwerken, vCPUs oder Arbeitsspeicher zu erstellen.
Beim Starten einer Instanz wird ein Ressourcenverfügbarkeitsfehler ausgegeben
Problem
Sie können eine Instanz aufgrund eines Ressourcenverfügbarkeitsfehlers nicht starten.
Dieser Fehler kann so aussehen:
The zone ZONE_NAME doesn't have enough resources available to fulfill the request. '(resource type:compute)'.
Ressourcenfehler treten auf, wenn Sie versuchen, eine Instanz in einer Zone zu starten, die Ihre Anfrage aufgrund der aktuellen Nichtverfügbarkeit von Compute Engine-Ressourcen wie GPUs oder CPUs nicht verarbeiten kann.
Ressourcenfehler gelten nur für die Ressourcen, die Sie beim Senden der Anfrage in Ihrer Anfrage angegeben haben, nicht für alle Ressourcen in der Zone. Ressourcenfehler beziehen sich nicht auf Ihr Compute Engine-Kontingent. Ressourcenfehler sind temporär und können sich aufgrund schwankender Nachfrage laufend ändern.
Lösung
Versuchen Sie Folgendes, um fortzufahren:
- Ändern Sie den Maschinentyp der Instanz.
- Migrieren Sie Ihre Dateien und Daten zu einer Instanz in einer anderen Zone.
- Wiederholen Sie die Anfrage später.
- Reduzieren Sie die Menge der angeforderten Ressourcen. Starten Sie beispielsweise eine andere Instanz mit weniger GPUs, Laufwerken, vCPUs oder Arbeitsspeicher.
No route to host
bei ausgehenden Verbindungen von verwalteten Notebooks
Problem
In der Regel werden in der Google Cloud Console nur die Routen angezeigt, die Ihrer eigenen VPC beknnat sind sowie die Bereiche, die reserviert werden, wenn Sie die VPC-Netzwerk-Peerings Konfiguration abschließen.
Verwaltete Notebookinstanzen befinden sich in einem von Google verwalteten Netzwerk und führen eine modifizierte Version von Jupyter in einem Docker-Netzwerk-Namespace innerhalb der Instanz aus.
Die Docker-Netzwerkschnittstelle und die Linux-Bridge auf dieser Instanz können eine lokale IP-Adresse auswählen, die mit IP-Bereichen in Konflikt steht, die von Ihrem VPC über das Peering exportiert werden. Sie liegen in der Regel im Bereich 172.16.0.0/161
bzw. 192.168.10.0/24
.
In diesen Fällen schlagen ausgehende Verbindungen von der Instanz zu diesen Bereichen fehl und es wird eine Fehlermeldung vom Typ No route to host
ausgegeben, obwohl die VPC-Routen korrekt freigegeben wurden.
Lösung
Rufen Sie ifconfig
in einer Terminalsitzung auf und prüfen Sie, ob keine IP-Adressen auf virtuellen Schnittstellen in der Instanz mit IP-Bereichen in Konflikt stehen, die Ihr VPC in die Peering-Verbindung exportiert.
Nutzerverwaltete Notebooks
In diesem Abschnitt werden Schritte zur Fehlerbehebung für von Nutzern verwaltete Notebooks beschrieben.
Verbindung zu JupyterLab herstellen und JupyterLab öffnen
In diesem Abschnitt wird beschrieben, wie Sie Probleme beim Herstellen einer Verbindung zu und beim Öffnen von JupyterLab beheben.
Nach dem Klicken auf JupyterLab passiert nichts
Problem
Wenn Sie auf JupyterLab öffnen klicken, passiert nichts.
Lösung
Prüfen Sie, ob Ihr Browser das automatische Öffnen neuer Tabs blockiert. JupyterLab wird in einem neuen Browsertab geöffnet.
Kein Proxy-Serverzugriff auf JupyterLab
Problem
Sie können nicht auf JupyterLab zugreifen.
Vertex AI Workbench nutzt einen internen Inverting-Proxy-Server von Google, um Zugriff auf JupyterLab zu gewähren. Einstellungen für nutzerverwaltete Notebookinstanzen, die Netzwerkkonfiguration und andere Faktoren können den Zugriff auf JupyterLab verhindern.
Lösung
Verbindung zu einer nutzerverwalteten Notebooks-Instanz über SSH kann nicht hergestellt werden
Problem
Sie können keine Verbindung zu Ihrer Instanz über SSH über ein Terminalfenster herstellen.
Nutzerverwaltete Notebooks-Instanzen verwenden OS Login, um den SSH-Zugriff zu ermöglichen. Wenn Sie eine Instanz erstellen, aktiviert Vertex AI Workbench standardmäßig OS Login, indem der Metadatenschlüssel enable-oslogin
auf TRUE
gesetzt wird. Wenn Sie keine SSH-Verbindung zur Instanz herstellen können, muss dieser Metadatenschlüssel möglicherweise auf TRUE
gesetzt werden.
Lösung
Führen Sie die Schritte zum Konfigurieren von OS Login-Rollen für Nutzerkonten aus, um den SSH-Zugriff für nutzerverwaltete Notebooks für Nutzer zu aktivieren.
Beim Öffnen einer nutzerverwalteten Notebookinstanz wird der Fehler 403 (Forbidden) angezeigt
Problem
Der Fehler 403 (Forbidden)
beim Öffnen einer vom Nutzer verwalteten Notebookinstanz bedeutet häufig, dass ein Zugriffsproblem vorliegt.
Lösung
Zur Behebung von Zugriffsproblemen sollten Sie die drei Möglichkeiten berücksichtigen, wie der Zugriff für eine vom Nutzer verwaltete Notebookinstanz gewährt werden kann:
- Einzelner Nutzer
- Dienstkonto
- Projektbearbeiter
Der Zugriffsmodus wird während der Erstellung von nutzerverwalteten Notebookinstanzen konfiguriert und in den Notebook-Metadaten definiert:
- Einzelner Nutzer:
proxy-mode=mail, proxy-user-mail=user@domain.com
- Dienstkonto:
proxy-mode=service_account
- Projektbearbeiter:
proxy-mode=project_editors
Wenn Sie beim Klicken auf JupyterLab öffnen nicht auf ein Notebook zugreifen können, versuchen Sie Folgendes:
Prüfen Sie, ob der Nutzer, der auf die Instanz zugreift, die Berechtigung
iam.serviceAccounts.ActAs
für das Dienstkonto der Instanz hat. Das Dienstkonto ist entweder das Compute Engine-Standarddienstkonto oder ein Dienstkonto, das beim Erstellen der Instanz angegeben wird.Wenn Ihre Instanz den Einzelnutzerzugriff mit einem bestimmten Dienstkonto als Einzelnutzer verwendet, finden Sie weitere Informationen unter Kein JupyterLab-Zugriff, Einzelnutzermodus aktiviert.
Das folgende Beispiel zeigt, wie Sie beim Erstellen einer Instanz ein Dienstkonto angeben:
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
Wenn Sie auf JupyterLab öffnen klicken, um ein Notebook aufzurufen, wird das Notebook in einem neuen Browsertab geöffnet. Falls Sie bei mehreren Google-Konten angemeldet sind, wird der neue Tab mit Ihrem Google-Standardkonto geöffnet. Wenn Sie Ihre nutzerverwaltete Notebookinstanz nicht mit Ihrem Google-Standardkonto erstellt haben, wird auf dem neuen Browsertab der Fehler 403 (Forbidden)
angezeigt.
Kein JupyterLab-Zugriff, Einzelnutzermodus aktiviert
Problem
Sie können nicht auf JupyterLab zugreifen.
Lösung
Wenn ein Nutzer nicht auf JupyterLab zugreifen kann und der Zugriff der Instanz auf JupyterLab auf Single user only
gesetzt ist, versuchen Sie Folgendes:
Klicken Sie auf der Seite „Nutzerverwaltete Notebooks“ der Google Cloud Console auf den Namen Ihrer Instanz, um die Seite Notebookdetails zu öffnen.
Klicken Sie neben VM-Details ansehen auf In Compute Engine ansehen.
Klicken Sie auf der Seite "VM-Details" auf Bearbeiten.
Prüfen Sie im Abschnitt Metadaten, ob der Metadateneintrag
proxy-mode
aufmail
festgelegt ist.Achten Sie darauf, dass der Metadateneintrag
proxy-user-mail
auf eine gültige Nutzer-E-Mail-Adresse festgelegt ist, nicht auf ein Dienstkonto.Klicken Sie auf Speichern.
Initialisieren Sie auf der Seite „Nutzerverwaltete Notebooks“ der Google Cloud Console die aktualisierten Metadaten. Beenden Sie dazu Ihre Instanz und starten Sie die Instanz wieder neu.
Beim Öffnen eines Notebooks wird ein 504-Fehler (Gateway Timeout) angezeigt.
Problem
Dies ist ein Hinweis auf ein internes Proxy-Zeitlimit oder das Zeitlimit eines Back-End-Servers (Jupyter Zeitlimit). Dies kann in folgenden Fällen angezeigt werden:
- Die Anfrage erreichte den internen Backing-Proxyserver nicht
- Backend (Jupyter) gibt einen 504-Fehler zurück.
Lösung
Öffnen Sie eine Supportanfrage.
Beim Öffnen eines Notebooks wird ein 524-Fehler (A Timeout Occurred) angezeigt.
Problem
Der interne Backing-Proxy-Server hat innerhalb des Zeitlimits keine Antwort vom Backverting-Proxy-Agent für die Anfrage erhalten. Der Inverting-Proxy-Agent wird in Ihrer nutzerverwalteten Notebookinstanz als Docker-Container ausgeführt. Ein 524-Fehler ist normalerweise ein Hinweis darauf, dass der Backinging-Proxy-Agent keine Verbindung zum Proxy-Server des Back-Ends herstellt oder die Anfragen auf der Back-End-Serverseite (Jupyter) zu lange dauern. Ein typischer Fall für diesen Fehler ist nutzerseitig (z. B. ein Netzwerkproblem oder der Inverting Proxy-Agent-Dienst wird nicht ausgeführt).
Lösung
Wenn Sie auf ein Notebook nicht zugreifen können, prüfen Sie, ob Ihre nutzerverwaltete Notebookinstanz gestartet wurde, und versuchen Sie Folgendes:
Option 1: Führen Sie das Diagnosetool aus, um die Hauptdienste für nutzerverwaltete Notebooks automatisch zu prüfen und zu reparieren, den verfügbaren Speicher zu prüfen und nützliche Logdateien zu generieren. Führen Sie die folgenden Schritte aus, um das Tool in Ihrer Instanz auszuführen:
Prüfen Sie, ob Ihre Instanz die Version M58 oder höher hat.
Stellen Sie eine SSH-Verbindung zur Deep Learning-VM-Instanz her.
Führen Sie dazu diesen Befehl aus:
sudo /opt/deeplearning/bin/diagnostic_tool.sh [--repair] [--bucket=$BUCKET]
Die Flags
--repair
und--bucket
sind optional. Das Flag--repair
versucht, häufige Hauptdienstfehler zu beheben, und mit dem Flag--bucket
können Sie einen Cloud Storage-Bucket angeben, um die erstellten Logdateien zu speichern.Die Ausgabe dieses Befehls zeigt nützliche Statusmeldungen für Hauptdienste für nutzerverwaltete Notebooks an und exportiert Logdateien der Ergebnisse.
Option 2: Führen Sie die folgenden Schritte aus, um bestimmte Anforderungen für nutzerverwaltete Notebooks einzeln zu prüfen.
Prüfen Sie, ob auf dem Laufwerk der nutzerverwalteten Notebookinstanz ausreichend Speicherplatz vorhanden ist.
Stellen Sie eine SSH-Verbindung zur Deep Learning-VM-Instanz her.
Führen Sie dazu diesen Befehl aus:
df -h -T /home/jupyter
Wenn die Nutzung% größer als
85%
ist, müssen Sie Dateien manuell aus/home/jupyter
löschen. Als ersten Schritt können Sie den Papierkorb mit dem folgenden Befehl leeren:sudo rm -rf /home/jupyter/.local/share/Trash/*
Prüfen Sie, ob der Backverting-Proxy-Agent ausgeführt wird. Wenn der Agent gestartet wurde, starten Sie ihn neu.
Prüfen Sie, ob der Back-End-Dienst ausgeführt wird. Falls ja, starten Sie den Computer neu.
Prüfen Sie die Arbeitsspeicherauslastung in der nutzerverwalteten Notebookinstanz.
Stellen Sie eine SSH-Verbindung zur Deep Learning-VM-Instanz her.
Führen Sie dazu diesen Befehl aus:
free -t -h
Wenn der genutzte Arbeitsspeicher mehr als
85%
des gesamten Arbeitsspeichers beträgt, sollten Sie den Maschinentyp ändern.Sie können den Cloud Monitoring-Agent installieren, um zu überwachen, ob in Ihrer nutzerverwalteten Notebookinstanz eine starke Arbeitsspeichernutzung auftritt. Preisinformationen
Prüfen Sie, ob Sie die Deep Learning VM-Version M55 oder höher verwenden. Weitere Informationen zu Upgrades finden Sie unter Umgebung einer nutzerverwalteten Notebookinstanz aktualisieren.
Beim Öffnen eines Notebooks wird ein 598-Fehler (Network Read Timeout) angezeigt
Problem
Der Backverting-Proxy-Server hat mehr als 10 Minuten vom "Inverting Proxy-Agent" nicht gehört. Dies ist ein starker Hinweis auf ein Problem mit umgekehrtem Proxy-Agent-Problem.
Lösung
Wenn Sie nicht auf ein Notebook zugreifen können, versuchen Sie folgendes:
Prüfen Sie, ob Ihre nutzerverwaltete Notebookinstanz gestartet wird.
Prüfen Sie, ob der Backverting-Proxy-Agent ausgeführt wird. Wenn der Agent gestartet wurde, starten Sie ihn neu.
Prüfen Sie, ob der Back-End-Dienst ausgeführt wird. Falls ja, starten Sie den Computer neu.
Prüfen Sie, ob Sie die Deep Learning VM-Version M55 oder höher verwenden. Weitere Informationen zu Upgrades finden Sie unter Umgebung einer nutzerverwalteten Notebookinstanz aktualisieren.
Das Notebook reagiert nicht
Problem
Ihre nutzerverwaltete Notebookinstanz führt keine Zellen aus oder scheint eingefroren zu sein.
Lösung
Starten Sie zuerst den Kernel neu. Klicken Sie dazu im oberen Menü auf Kernel und dann auf Kernel neu starten. Wenn dies nicht funktioniert, versuchen Sie folgendes:
- Aktualisieren Sie die JupyterLab-Browserseite. Alle nicht gespeicherten Zellenausgaben werden nicht beibehalten. Daher müssen Sie diese Zellen noch einmal ausführen, um die Ausgabe neu zu generieren.
- Führen Sie in einer Terminalsitzung im Notebook den Befehl
top
aus, um zu prüfen, ob Prozesse die CPU beanspruchen. - Prüfen Sie über das Terminal mit dem Befehl
df
den freien Speicherplatz oder prüfen Sie den verfügbaren RAM mit dem Befehlfree
. - Wählen Sie die Instanz auf der Seite Vom Nutzer verwaltete Notebooks aus und klicken Sie auf Beenden, um die Instanz herunterzufahren. Wenn sie vollständig heruntergefahren ist, wählen Sie die Instanz aus und klicken auf Starten.
Zu Vertex AI Workbench-Instanzen migrieren
In diesem Abschnitt werden Methoden zur Diagnose und Behebung von Problemen bei der Migration von einer nutzerverwalteten Notebooks-Instanz zu einer Vertex AI Workbench-Instanz beschrieben.
R, Beam oder andere Kernel, die sich in der nutzerverwalteten Notebook-Instanz befanden, können nicht gefunden werden
Problem
Ein Kernel, der sich in Ihrer nutzerverwalteten Notebooks-Instanz befand, wird in der Vertex AI Workbench-Instanz, zu der Sie migriert sind, nicht angezeigt.
Einige Kernel, z. B. die R- und Beam-Kernel, sind in Vertex AI Workbench-Instanzen standardmäßig nicht verfügbar. Die Migration dieser Kernel wird nicht unterstützt.
Lösung
Um dieses Problem zu beheben, fügen Sie Ihrer Vertex AI Workbench-Instanz eine Conda-Umgebung hinzu.
Dataproc Hub-Instanz kann nicht in der Vertex AI Workbench-Instanz eingerichtet werden
Problem
Dataproc Hub wird in Vertex AI Workbench-Instanzen nicht unterstützt.
Lösung
Verwenden Sie Dataproc Hub weiterhin in nutzerverwalteten Notebookinstanzen.
Andere Version des Frameworks in der migrierten Instanz
Problem
Ein Framework in Ihrer nutzerverwalteten Notebooks-Instanz hatte eine andere Version als die in der Vertex AI Workbench-Instanz, zu der Sie migriert sind.
Vertex AI Workbench-Instanzen bieten eine Standardauswahl an Framework-Versionen. Das Migrationstool fügt keine Framework-Versionen aus Ihrer ursprünglichen nutzerverwalteten Notebookinstanz hinzu. Weitere Informationen finden Sie unter Standardverhalten des Migrationstools.
Lösung
Wenn Sie eine bestimmte Version eines Frameworks hinzufügen möchten, fügen Sie Ihrer Vertex AI Workbench-Instanz eine Conda-Umgebung hinzu.
GPUs werden nicht in die neue Vertex AI Workbench-Instanz migriert
Problem
GPUs, die sich in Ihrer nutzerverwalteten Notebooks-Instanz befanden, sind nicht in der Vertex AI Workbench-Instanz verfügbar, zu der Sie migriert sind.
Vertex AI Workbench-Instanzen unterstützen eine Reihe von Standard-GPUs. Wenn die GPUs in Ihrer ursprünglichen nutzerverwalteten Notebookinstanz nicht verfügbar sind, wird Ihre Instanz ohne GPUs migriert.
Lösung
Nach der Migration können Sie Ihrer Vertex AI Workbench-Instanz mit der Methode projects.locations.instances.patch
in der Notebooks API oder dem Befehl gcloud workbench instances update
im Google Cloud SDK GPUs hinzufügen.
Der Maschinentyp der migrierten Instanz ist unterschiedlich
Problem
Der Maschinentyp Ihrer nutzerverwalteten Notebooks-Instanz unterscheidet sich von dem der Vertex AI Workbench-Instanz, zu der Sie migriert sind.
Vertex AI Workbench-Instanzen unterstützen nicht alle Maschinentypen.
Wenn der Maschinentyp in Ihrer ursprünglichen nutzerverwalteten Notebook-Instanz nicht verfügbar ist, wird Ihre Instanz zum Maschinentyp e2-standard-4
migriert.
Lösung
Nach der Migration können Sie den Maschinentyp Ihrer Vertex AI Workbench-Instanz mit der Methode projects.locations.instances.patch
in der Notebooks API oder dem Befehl gcloud workbench instances update
im Google Cloud SDK ändern.
Mit Dateien arbeiten
In diesem Abschnitt wird beschrieben, wie Sie Probleme mit Dateien für nutzerverwaltete Notebookinstanzen beheben.
Dateidownload deaktiviert, aber Nutzer können weiterhin Dateien herunterladen
Problem
Für nutzerverwaltete Dataproc Hub-Notebookinstanzen wird das Deaktivieren von Dateien, die von der JupyterLab-Benutzeroberfläche heruntergeladen werden, nicht unterstützt. Nutzerverwaltete Notebookinstanzen, die das Dataproc Hub-Framework verwenden, lassen das Herunterladen von Dateien auch dann zu, wenn Sie beim Erstellen der Instanz nicht die Option Herunterladen von Dateien über die JupyterLab-UI aktivieren auswählen.
Lösung
Bei nutzerverwalteten Dataproc Hub-Notebookinstanzen ist das Einschränken von Dateidownloads nicht möglich.
Heruntergeladene Dateien werden abgeschnitten oder als Download nicht abgeschlossen
Problem
Wenn Sie Dateien von Ihrer nutzerverwalteten Notebookinstanz herunterladen, begrenzt eine Zeitlimiteinstellung auf dem Proxy-Weiterleitungs-Agent die Verbindungszeit für den Download. Wenn der Download zu lange dauert, kann die heruntergeladene Datei gekürzt werden oder verhindert werden, dass sie heruntergeladen wird.
Lösung
Um die Datei herunterzuladen, kopieren Sie die Datei in Cloud Storage und laden Sie die Datei dann aus Cloud Storage herunter.
Erwägen Sie das Migrieren Ihrer Dateien und Daten zu einer neuen nutzerverwalteten Notebookinstanz.
Nach dem Neustart der VM kann nicht auf lokale Dateien über das Notebook-Terminal verwiesen werden
Problem
Manchmal kann nach dem Neustart einer nutzerverwalteten Notebookinstanz nicht von innerhalb eines Notebook-Terminals auf lokale Dateien verwiesen werden.
Lösung
Dieses Problem ist bekannt. Um in einem Notebook-Terminal auf Ihre lokalen Dateien zu verweisen, müssen Sie zuerst Ihr aktuelles Arbeitsverzeichnis mit dem folgenden Befehl wiederherstellen:
cd PWD
Ersetzen Sie in diesem Befehl PWD durch Ihr aktuelles Arbeitsverzeichnis. Wenn Ihr aktuelles Arbeitsverzeichnis beispielsweise /home/jupyter/
lautet, verwenden Sie den Befehl cd /home/jupyter/
.
Nachdem Sie Ihr aktuelles Arbeitsverzeichnis wiederhergestellt haben, können Sie vom Notebook-Terminal aus auf Ihre lokalen Dateien verweisen.
Nutzerverwaltete Notebookinstanzen erstellen
In diesem Abschnitt wird beschrieben, wie Sie Probleme beim Erstellen von nutzerverwalteten Notebookinstanzen beheben.
Das GPU-Kontingent wurde überschritten
Problem
Sie können keine nutzerverwaltete Notebookinstanz mit GPUs erstellen.
Lösung
Prüfen Sie auf der Seite Kontingente die Anzahl der in Ihrem Projekt verfügbaren GPUs. Wenn auf der Seite Kontingente keine GPUs aufgeführt sind oder Sie zusätzliche GPU-Kontingente benötigen, können Sie eine Erhöhung des Kontingents beantragen. Weitere Informationen finden Sie unter Höheres Kontingentlimit anfordern.
Problem: Pods bleiben nach der Konfiguration der Option „Node Allocatable“ im Status „Ausstehend“
Problem
Nach dem Erstellen einer nutzerverwalteten Notebookinstanz bleibt sie unbegrenzt im Status „Ausstehend“. In den Protokollen für die serielle Kommunikation kann ein Fehler wie der folgende angezeigt werden:
Could not resolve host: notebooks.googleapis.com
Lösung
Ihre Instanz kann aufgrund einer Cloud DNS-Konfiguration oder eines anderen Netzwerkproblems keine Verbindung zum Notebooks API-Server herstellen. Prüfen Sie Ihre Cloud DNS- und Netzwerkkonfigurationen, um das Problem zu beheben. Weitere Informationen finden Sie im Abschnitt Netzwerkkonfigurationsoptionen.
Neue nutzerverwaltete Notebookinstanz wird nicht erstellt (unzureichende Berechtigungen)
Problem
Das Erstellen einer nutzerverwalteten Notebookinstanz dauert in der Regel etwa eine Minute. Wenn Ihre neue nutzerverwaltete Notebookinstanz auf unbestimmte Zeit im Status pending
verbleibt, hat das zum Starten der nutzerverwalteten Notebookinstanz verwendete Dienstkonto möglicherweise nicht die erforderlichen Berechtigungen in Ihrem Google Cloud -Projekt.
Sie können eine nutzerverwaltete Notebookinstanz mit einem von Ihnen erstellten benutzerdefinierten Dienstkonto oder im Einzelnutzermodus mit einer Nutzer-ID starten. Wenn Sie eine nutzerverwaltete Notebookinstanz im Einzelnutzermodus starten, startet die nutzerverwaltete Notebookinstanz den Bootvorgang mit dem Standarddienstkonto von Compute Engine, bevor die Steuerung an Ihre Nutzer-ID übergeben wird.
Lösung
So können Sie prüfen, ob ein Dienstkonto die erforderlichen Berechtigungen hat:
Console
Öffnen Sie in der Google Cloud Console die Seite IAM.
Legen Sie eines der folgenden Dienstkonten für Ihre nutzerverwaltete Notebookinstanz fest:
Ein benutzerdefiniertes Dienstkonto, das Sie beim Erstellen Ihrer nutzerverwalteten Notebookinstanz angegeben haben.
Das Compute Engine-Standarddienstkonto für IhrGoogle Cloud -Projekt, das beim Start der nutzerverwalteten Notebookinstanz im Einzelnutzermodus verwendet wird. Das Compute Engine-Standarddienstkonto für Ihr Google Cloud -Projekt hat den Namen
PROJECT_NUMBER-compute@developer.gserviceaccount.com
. Beispiel:113377992299-compute@developer.gserviceaccount.com
.
Prüfen Sie, ob Ihr Dienstkonto die Rolle „Notebooks Runner“ (
roles/notebooks.runner
) hat. Andernfalls weisen Sie dem Dienstkonto die Rolle „Notebooks Runner“ (roles/notebooks.runner
) zu.
Weitere Informationen finden Sie unter Zugriff auf Ressourcen erteilen, ändern und entziehen in der IAM-Dokumentation.
gcloud
Installieren Sie das Google Cloud CLI, falls noch nicht geschehen.
Rufen Sie mit dem folgenden Befehl den Namen und die Projektnummer für Ihr Google Cloud -Projekt ab. Ersetzen Sie PROJECT_ID durch die Projekt-ID IhresGoogle Cloud -Projekts.
gcloud projects describe PROJECT_ID
Die Ausgabe, die den Namen (
name:
) und die Projektnummer (projectNumber:
) für Ihr Projekt enthält, sollte in etwa so aussehen: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'
Legen Sie eines der folgenden Dienstkonten für Ihre nutzerverwaltete Notebookinstanz fest:
Ein benutzerdefiniertes Dienstkonto, das Sie beim Erstellen Ihrer nutzerverwalteten Notebookinstanz angegeben haben.
Das Compute Engine-Standarddienstkonto für IhrGoogle Cloud -Projekt, das beim Start der nutzerverwalteten Notebookinstanz im Einzelnutzermodus verwendet wird. Das Compute Engine-Standarddienstkonto für Ihr Google Cloud -Projekt hat den Namen
PROJECT_NUMBER-compute@developer.gserviceaccount.com
. Beispiel:113377992299-compute@developer.gserviceaccount.com
.
Fügen Sie dem Dienstkonto die Rolle
roles/notebooks.runner
mit dem folgenden Befehl hinzu: Ersetzen Sie project-name durch den Namen Ihres Projekts und service-account-id durch die Dienstkonto-ID für Ihre nutzerverwaltete Notebookinstanz.gcloud projects add-iam-policy-binding project-name \ --member serviceAccount:service-account-id \ --role roles/notebooks.runner
Beim Erstellen einer Instanz wird der Fehler Permission denied
ausgegeben
Problem
Das Dienstkonto auf der Instanz bietet Zugriff auf andere Google Cloud-Dienste. Sie können jedes Dienstkonto innerhalb desselben Projekts verwenden, aber zum Erstellen der Instanz benötigen Sie die Rolle „Dienstkontonutzer“ (iam.serviceAccounts.actAs
). Wenn nicht angegeben, wird das Compute Engine-Standarddienstkonto verwendet.
Lösung
Prüfen Sie beim Erstellen einer Instanz, ob der Nutzer, der die Instanz erstellt, die Berechtigung iam.serviceAccounts.ActAs
für das definierte Dienstkonto hat.
Das folgende Beispiel zeigt, wie Sie beim Erstellen einer Instanz ein Dienstkonto angeben:
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
Informationen zum Zuweisen der Rolle „Dienstkontonutzer” finden Sie unter Zugriff auf Dienstkonten verwalten.
Beim Erstellen einer Instanz wird der Fehler already exists
ausgegeben
Problem
Prüfen Sie beim Erstellen einer Instanz, ob eine nutzerverwaltete Notebookinstanz mit demselben Namen nicht zuvor von Compute Engine gelöscht wurde und noch in der Notebooks API-Datenbank vorhanden ist.
Lösung
Das folgende Beispiel zeigt, wie Instanzen mithilfe der Notebooks API aufgelistet werden und ihr Status überprüft wird.
gcloud notebooks instances list --location=LOCATION
Wenn eine Instanz den Status DELETED
hat, führen Sie den folgenden Befehl aus, um sie endgültig zu löschen.
gcloud notebooks instances delete INSTANCE_NAME --location=LOCATION
Instanz kann nicht in einer freigegebenen VPC erstellt werden
Problem
Sie können keine Instanz in einer freigegebenen VPC erstellen.
Lösung
Wenn Sie eine freigegebene VPC verwenden, müssen Sie den Host und die Dienstprojekte in den Dienstperimeter einfügen. Im Hostprojekt müssen Sie dem Notebooks-Dienst-Agent auch die Rolle Compute-Netzwerknutzer (roles/compute.networkUser
) aus dem Dienstprojekt zuweisen. Weitere Informationen finden Sie unter Dienstperimeter verwalten.
Beim Erstellen einer Instanz wird ein Ressourcenverfügbarkeitsfehler ausgegeben
Problem
Sie können aufgrund eines Ressourcenverfügbarkeitsfehlers keine Instanz erstellen.
Dieser Fehler kann so aussehen:
Creating notebook INSTANCE_NAME: ZONE does not have enough resources available to fulfill the request. Retry later or try another zone in your configurations.
Ressourcenfehler treten auf, wenn Sie neue Ressourcen in einer Zone anfordern, die aufgrund der aktuellen Nichtverfügbarkeit von Compute Engine-Ressourcen wie GPUs oder CPUs Ihre Anfrage nicht bearbeiten kann.
Ressourcenfehler gelten nur für neue Ressourcenanfragen in der Zone und haben keine Auswirkungen auf vorhandene Ressourcen. Ressourcenfehler beziehen sich nicht auf Ihr Compute Engine-Kontingent. Ressourcenfehler sind temporär und können sich aufgrund schwankender Nachfrage laufend ändern.
Lösung
Versuchen Sie Folgendes, um fortzufahren:
- Erstellen Sie eine Instanz mit einem anderen Maschinentyp.
- Erstellen Sie die Instanz in einer anderen Zone.
- Wiederholen Sie die Anfrage später.
- Reduzieren Sie die Menge der angeforderten Ressourcen. Versuchen Sie beispielsweise, eine Instanz mit weniger GPUs, Laufwerken, vCPUs oder Arbeitsspeicher zu erstellen.
Beim Starten einer Instanz wird ein Ressourcenverfügbarkeitsfehler ausgegeben
Problem
Sie können eine Instanz aufgrund eines Ressourcenverfügbarkeitsfehlers nicht starten.
Dieser Fehler kann so aussehen:
The zone ZONE_NAME doesn't have enough resources available to fulfill the request. '(resource type:compute)'.
Ressourcenfehler treten auf, wenn Sie versuchen, eine Instanz in einer Zone zu starten, die Ihre Anfrage aufgrund der aktuellen Nichtverfügbarkeit von Compute Engine-Ressourcen wie GPUs oder CPUs nicht verarbeiten kann.
Ressourcenfehler gelten nur für die Ressourcen, die Sie beim Senden der Anfrage in Ihrer Anfrage angegeben haben, nicht für alle Ressourcen in der Zone. Ressourcenfehler beziehen sich nicht auf Ihr Compute Engine-Kontingent. Ressourcenfehler sind temporär und können sich aufgrund schwankender Nachfrage laufend ändern.
Lösung
Versuchen Sie Folgendes, um fortzufahren:
- Ändern Sie den Maschinentyp der Instanz.
- Migrieren Sie Ihre Dateien und Daten zu einer Instanz in einer anderen Zone.
- Wiederholen Sie die Anfrage später.
- Reduzieren Sie die Menge der angeforderten Ressourcen. Starten Sie beispielsweise eine andere Instanz mit weniger GPUs, Laufwerken, vCPUs oder Arbeitsspeicher.
Upgrade von nutzerverwalteten Notebookinstanzen durchführen
In diesem Abschnitt wird beschrieben, wie Sie Probleme beim Upgrade von nutzerverwalteten Notebookinstanzen beheben.
Upgrade nicht möglich, da keine Informationen zum Instanz-Laufwerk abgerufen werden können
Problem
Für nutzerverwaltete Notebookinstanzen mit einem einzigen Laufwerk wird kein Upgrade unterstützt.
Lösung
Sie können Ihre Nutzerdaten zu einer neuen nutzerverwalteten Notebookinstanz migrieren.
Upgrade ist nicht möglich, da die Instanz nicht UEFI-kompatibel ist
Problem
Vertex AI Workbench hängt von der UEFI-Kompatibilität ab, um ein Upgrade abschließen zu können.
Nutzerverwaltete Notebookinstanzen, die aus einigen älteren Images erstellt wurden, sind nicht UEFI-kompatibel und können daher nicht aktualisiert werden.
Lösung
Wenn Sie prüfen möchten, ob die Instanz UEFI-kompatibel ist, geben Sie in Cloud Shell oder in einer Umgebung, in der das Google Cloud CLI installiert ist, den folgenden Befehl ein.
gcloud compute instances describe INSTANCE_NAME \ --zone=ZONE | grep type
Ersetzen Sie Folgendes:
INSTANCE_NAME
: durch den Namen der InstanzZONE
: Zone, in der sich Ihre Instanz befindet.
Prüfen Sie mit dem folgenden Befehl, ob das zur Erstellung Ihrer Instanz verwendete Image UEFI-kompatibel ist:
gcloud compute images describe VM_IMAGE_FAMILY \ --project deeplearning-platform-release | grep type
Ersetzen Sie VM_IMAGE_FAMILY
durch den Image-Familiennamen, mit dem Sie die Instanz erstellt haben.
Wenn Sie feststellen, dass die Instanz oder das Image nicht UEFI-kompatibel ist, können Sie versuchen, Ihre Nutzerdaten zu einer neuen nutzerverwalteten Notebookinstanz zu migrieren. Führen Sie dazu folgende Schritte aus:
Prüfen Sie, ob das Image, das Sie zum Erstellen Ihrer neuen Instanz verwenden möchten, UEFI-kompatibel ist. Geben Sie dazu entweder in Cloud Shell oder in einer Umgebung, in der das Google Cloud CLI installiert ist, den folgenden Befehl ein.
gcloud compute images describe VM_IMAGE_FAMILY \ --project deeplearning-platform-release --format=json | grep type
Ersetzen Sie
VM_IMAGE_FAMILY
durch den Namen der Image-Familie, die Sie zum Erstellen Ihrer Instanz verwenden möchten.Migrieren Sie Ihre Nutzerdaten zu einer neuen nutzerverwalteten Notebookinstanz.
Nutzerverwaltete Notebookinstanz ist nach dem Upgrade nicht zugänglich
Problem
Wenn auf die nutzerverwaltete Notebookinstanz nach einem Upgrade nicht zugegriffen werden kann, ist beim Ersetzen des Bootlaufwerk-Images möglicherweise ein Fehler aufgetreten.
Nutzerverwaltete Notebookinstanzen, die aktualisiert werden können, haben zwei Laufwerke: ein Bootlaufwerk und ein Datenlaufwerk. Beim Upgradeprozess wird das Bootlaufwerk auf ein neues Image aktualisiert und die Daten bleiben erhalten.
Lösung
Führen Sie die folgenden Schritte aus, um dem Bootlaufwerk ein neues gültiges Image hinzuzufügen.
Geben Sie den folgenden Befehl in Cloud Shell oder in einer Umgebung ein, in der das Google Cloud CLI gespeichert wird, um die Werte zu speichern, die Sie für diesen Vorgang benötigen.
export INSTANCE_NAME=MY_INSTANCE_NAME export PROJECT_ID=MY_PROJECT_ID export ZONE=MY_ZONE
Dabei gilt:
MY_INSTANCE_NAME
: durch den Namen der InstanzMY_PROJECT_ID
: Ihre Projekt-IDMY_ZONE
: Zone, in der sich Ihre Instanz befindet.
Beenden Sie mit dem folgenden Befehl die Instanz:
gcloud compute instances stop $INSTANCE_NAME \ --project=$PROJECT_ID --zone=$ZONE
Trennen Sie das Bootlaufwerk von der Instanz.
gcloud compute instances detach-disk $INSTANCE_NAME --device-name=data \ --project=$PROJECT_ID --zone=$ZONE
Löschen Sie die VM der Instanz.
gcloud compute instances delete $INSTANCE_NAME --keep-disks=all --quiet \ --project=$PROJECT_ID --zone=$ZONE
Verwenden Sie die Notebooks API, um die nutzerverwaltete Notebookinstanz zu löschen.
gcloud notebooks instances delete $INSTANCE_NAME \ --project=$PROJECT_ID --location=$ZONE
Erstellen Sie eine nutzerverwaltete Notebookinstanz mit demselben Namen wie bei der vorherigen Instanz.
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
Dabei gilt:
MY_VM_IMAGE_FAMILY
ist der Name der Image-Familie.MY_INSTANCE_OWNER
ist der Inhaber Ihrer Instanz.MY_MACHINE_TYPE
: der Maschinentyp der VM-InstanzMY_SERVICE_ACCOUNT
ist das Dienstkonto, das für diese Instanz verwendet werden soll, oder"default"
MY_ACCELERATOR_TYPE
ist der Beschleunigertyp, z. B."NVIDIA_TESLA_T4"
.MY_ACCELERATOR_CORE_COUNT
ist die Anzahl der Kerne, z. B.1
Zustand von nutzerverwalteten Notebookinstanzen überwachen
In diesem Abschnitt wird beschrieben, wie Sie Probleme mit Fehlern beim Überwachen des Systemstatus beheben.
docker-proxy-agent
-Statusfehler
Führen Sie nach einem docker-proxy-agent
-Statusfehler die folgenden Schritte aus:
Prüfen Sie, ob der Inverting Proxy-Agent ausgeführt wird. Machen Sie andernfalls mit Schritt 3 weiter.
Registrieren Sie sich noch einmal beim Inverting-Proxy-Server.
docker-service
-Statusfehler
Führen Sie nach einem docker-service
-Statusfehler die folgenden Schritte aus:
jupyter-service
-Statusfehler
Führen Sie nach einem jupyter-service
-Statusfehler die folgenden Schritte aus:
jupyter-api
-Statusfehler
Führen Sie nach einem jupyter-api
-Statusfehler die folgenden Schritte aus:
Prozentsatz der Auslastung des Bootlaufwerks
Der Speicherplatzstatus des Bootlaufwerks ist „Fehlerhaft“, wenn der Speicherplatz zu mehr als 85 % belegt ist.
Wenn der Speicherplatzstatus des Bootlaufwerks „Fehlerhaft“ ist, versuchen Sie Folgendes:
Prüfen Sie über eine Terminalsitzung in der nutzerverwalteten Notebookinstanz oder über eine SSH-Verbindung den freien Speicherplatz mit dem Befehl
df -H
.Verwenden Sie den Befehl
find . -type d -size +100M
, um große Dateien zu finden, die Sie möglicherweise löschen können. Löschen Sie sie jedoch nur, wenn Sie sich sicher sind, dass das kein Problem ist. Wenn Sie sich nicht sicher sind, wenden Sie sich an den Support.Wenn das Problem durch die vorherigen Schritte nicht behoben wird, fordern Sie Support an.
Prozentsatz der Auslastung des Datenlaufwerks
Der Speicherplatzstatus des Datenlaufwerks ist „Fehlerhaft“, wenn der Speicherplatz zu mehr als 85 % belegt ist.
Wenn der Speicherplatzstatus des Datenlaufwerks „Fehlerhaft“ ist, versuchen Sie Folgendes:
Prüfen Sie über eine Terminalsitzung in der nutzerverwalteten Notebookinstanz oder über eine SSH-Verbindung den freien Speicherplatz mit dem Befehl
df -h -T /home/jupyter
.Löschen Sie große Dateien, um den verfügbaren Speicherplatz zu erhöhen. Mit dem Befehl
find . -type d -size +100M
können Sie große Dateien finden.Wenn das Problem durch die vorherigen Schritte nicht behoben wird, fordern Sie Support an.
JupyterLab-Erweiterung von Drittanbietern kann nicht installiert werden
Problem
Der Versuch, eine JupyterLab-Erweiterung eines Drittanbieters zu installieren, führt zu einer Error: 500
-Nachricht.
Lösung
JupyterLab-Erweiterungen von Drittanbietern werden in nutzerverwalteten Notebookinstanzen nicht unterstützt.
Instanz wiederherstellen
Problem
Das Wiederherstellen einer nutzerverwalteten Notebookinstanz nach dem Löschen wird nicht unterstützt.
Lösung
Sie können die Daten in Ihrer Instanz sichern, indem Sie Ihre Notebooks auf GitHub speichern oder einen Snapshot des Laufwerks erstellen.
Daten aus einer Instanz wiederherstellen
Problem
Das Wiederherstellen von Daten aus einer nutzerverwalteten Notebookinstanz nach dem Löschen wird nicht unterstützt.
Lösung
Sie können die Daten in Ihrer Instanz sichern, indem Sie Ihre Notebooks auf GitHub speichern oder einen Snapshot des Laufwerks erstellen.
Der gemeinsame Arbeitsspeicher kann nicht erhöht werden
Problem
Sie können den gemeinsamen Arbeitsspeicher einer vorhandenen nutzerverwalteten Notebookinstanz nicht erhöhen.
Lösung
Sie können jedoch beim Erstellen einer nutzerverwalteten Notebookinstanz die Größe des gemeinsam verwendeten Arbeitsspeichers angeben. Verwenden Sie dazu den Metadatenschlüssel container-custom-params
mit einem Wert wie dem folgenden:
--shm-size=SHARED_MEMORY_SIZE gb
Ersetzen Sie SHARED_MEMORY_SIZE
durch die gewünschte Größe in GB.
Nützliche Vorgehensweisen
In diesem Abschnitt werden Verfahren beschrieben, die Ihnen helfen können.
SSH verwenden, um eine Verbindung zu Ihrer nutzerverwalteten Notebookinstanz herzustellen
Verwenden Sie SSH, um eine Verbindung zu Ihrer Instanz herzustellen. Geben Sie dafür folgenden Befehl in Cloud Shell oder in einer Umgebung ein, in der das Google Cloud CLI installiert ist.
gcloud compute ssh --project PROJECT_ID \
--zone ZONE \
INSTANCE_NAME -- -L 8080:localhost:8080
Dabei gilt:
PROJECT_ID
: Ihre Projekt-IDZONE
: Die Google Cloud Zone, in der sich Ihre Instanz befindetINSTANCE_NAME
: Der Name Ihrer Instanz.
Sie können auch eine Verbindung zu Ihrer Instanz herstellen, indem Sie die Compute Engine-Detailseite der Instanz öffnen und dann auf die Schaltfläche SSH klicken.
Beim Inverting-Proxy-Server neu registrieren
Wenn Sie die nutzerverwaltete Notebookinstanz noch einmal beim internen Inverting-Proxy-Server registrieren möchten, können Sie die VM auf der Seite Nutzerverwaltete Notebooks anhalten und starten oder SSH verwenden, um eine Verbindung zu Ihrer nutzerverwalteten Notebookinstanz herzustellen, und dann Folgendes eingeben:
cd /opt/deeplearning/bin sudo ./attempt-register-vm-on-proxy.sh
Docker-Dienststatus überprüfen
Prüfen Sie den Docker-Dienststatus, indem Sie SSH verwenden, um eine Verbindung zu Ihrer nutzerverwalteten Notebookinstanz herzustellen, und dann Folgendes eingeben:
sudo service docker status
Prüfen, ob der Backverting-Proxy-Agent ausgeführt wird
Sie können prüfen, ob der Notebook-Inverting-Proxy-Agent ausgeführt wird. Stellen Sie dazu mit SSH eine Verbindung zu Ihrer nutzerverwalteten Notebookinstanz her und geben Sie Folgendes ein:
# 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
Jupyter-Dienststatus prüfen und Logs erfassen
Prüfen Sie den Jupyter-Dienststatus, indem Sie SSH verwenden, um eine Verbindung zu Ihrer nutzerverwalteten Notebookinstanz herzustellen, und dann Folgendes eingeben:
sudo service jupyter status
So erfassen Sie Jupyter-Dienstlogs:
sudo journalctl -u jupyter.service --no-pager
Prüfen, ob die interne Jupyter API aktiv ist
Die Jupyter API sollte immer auf Port 8080 ausgeführt werden. Sie können dies prüfen, indem Sie in den Syslogs der Instanz nach einem Eintrag suchen, der in etwa so aussieht:
Jupyter Server ... running at: http://localhost:8080
Sie können prüfen, ob die interne Jupyter API aktiv ist. Stellen Sie dazu mit SSH eine Verbindung zu Ihrer nutzerverwalteten Notebookinstanz her und geben Sie Folgendes ein:
curl http://127.0.0.1:8080/api/kernelspecs
Sie können auch die Zeit messen, die die API für die Antwort benötigt, falls die Anfragen zu lange dauern:
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
Wenn Sie diese Befehle in Ihrer Vertex AI Workbench-Instanz ausführen möchten, öffnen Sie JupyterLab und erstellen Sie ein neues Terminal.
Starten Sie den Docker-Dienst neu
Sie können den Docker-Dienst neu starten, indem Sie die VM über die Seite Nutzerverwaltete Notebooks anhalten und starten oder SSH verwenden, um eine Verbindung zu Ihrer nutzerverwalteten Notebookinstanz herzustellen, und dann Folgendes eingeben:
sudo service docker restart
Reverse-Proxy-Agent neu starten
Wenn Sie den Inverting-Proxy-Agent neu starten möchten, können Sie die VM über die Seite Nutzerverwaltete Notebooks anhalten und starten oder SSH verwenden, um eine Verbindung zu Ihrer nutzerverwalteten Notebookinstanz herzustellen, und dann Folgendes eingeben:
sudo docker restart proxy-agent
Jupyter-Dienst neu starten
Sie können den Jupyter-Dienst neu starten, indem Sie die VM über die Seite Nutzerverwaltete Notebooks anhalten und starten oder SSH verwenden, um eine Verbindung zu Ihrer nutzerverwalteten Notebookinstanz herzustellen, und dann Folgendes eingeben:
sudo service jupyter restart
Notebooks-Collection-Agent neu starten
Der Notebooks Collection Agent-Dienst führt einen Python-Prozess im Hintergrund aus, der den Status der Hauptdienste der Vertex AI Workbench-Instanz prüft.
Sie können den Dienst „Notebooks Collection Agent“ neu starten, indem Sie die VM über die Google Cloud Console anhalten und starten oder SSH verwenden, um eine Verbindung zu Ihrer Vertex AI Workbench-Instanz herzustellen, und dann Folgendes eingeben:
sudo systemctl stop notebooks-collection-agent.service
Gefolgt von:
sudo systemctl start notebooks-collection-agent.service
Wenn Sie diese Befehle in Ihrer Vertex AI Workbench-Instanz ausführen möchten, öffnen Sie JupyterLab und erstellen Sie ein neues Terminal.
Skript für Notebooks Collection Agent ändern
Wenn Sie auf das Script zugreifen und es bearbeiten möchten, öffnen Sie ein Terminal in unserer Instanz oder verbinden Sie sich per SSH mit Ihrer Vertex AI Workbench-Instanz und geben Sie Folgendes ein:
nano /opt/deeplearning/bin/notebooks_collection_agent.py
Denken Sie daran, die Datei nach der Bearbeitung zu speichern.
Anschließend müssen Sie den Dienst „Notebooks Collection Agent“ neu starten.
Prüfen, ob die Instanz die erforderlichen DNS-Domains auflösen kann
Sie können prüfen, ob die Instanz die erforderlichen DNS-Domains auflösen kann. Stellen Sie dazu mit SSH eine Verbindung zu Ihrer nutzerverwalteten Notebookinstanz her und geben Sie Folgendes ein:
host notebooks.googleapis.com
host *.notebooks.cloud.google.com
host *.notebooks.googleusercontent.com
host *.kernels.googleusercontent.com
oder:
curl --silent --output /dev/null "https://notebooks.cloud.google.com"; echo $?
Wenn für die Instanz Dataproc aktiviert ist, können Sie mit dem folgenden Befehl prüfen, ob die Instanz *.kernels.googleusercontent.com
auflöst:
curl --verbose -H "Authorization: Bearer $(gcloud auth print-access-token)" https://${PROJECT_NUMBER}-dot-${REGION}.kernels.googleusercontent.com/api/kernelspecs | jq .
Wenn Sie diese Befehle in Ihrer Vertex AI Workbench-Instanz ausführen möchten, öffnen Sie JupyterLab und erstellen Sie ein neues Terminal.
Kopie der Nutzerdaten auf einer Instanz erstellen
Führen Sie die folgenden Schritte aus, um eine Kopie der Nutzerdaten Ihrer Instanz in Cloud Storage zu speichern.
Cloud Storage-Bucket erstellen (optional)
Erstellen Sie in dem Projekt, in dem sich Ihre Instanz befindet und einen Cloud Storage-Bucket, in dem Sie Ihre Nutzerdaten speichern können. Wenn Sie bereits einen Cloud Storage-Bucket haben, überspringen Sie diesen Schritt.
-
Create a Cloud Storage bucket:
Replacegcloud storage buckets create gs://BUCKET_NAME
BUCKET_NAME
with a bucket name that meets the bucket naming requirements.
Nutzerdaten kopieren
Wählen Sie auf der JupyterLab-Benutzeroberfläche Ihrer verwalteten Notebookinstanz Datei >Neu > Terminal aus, um ein Terminalfenster zu öffnen. Bei nutzerverwalteten Notebookinstanzen können Sie stattdessen mit SSH eine Verbindung zum Terminal Ihrer Instanz herstellen.
Verwenden Sie die gcloud CLI, um Ihre Nutzerdaten in einen Cloud Storage-Bucket zu kopieren. Mit dem folgenden Beispielbefehl werden alle Dateien aus dem Verzeichnis
/home/jupyter/
Ihrer Instanz in ein Verzeichnis in einem Cloud Storage-Bucket kopiert.gcloud storage cp /home/jupyter/* gs://BUCKET_NAMEPATH --recursive
Ersetzen Sie dabei Folgendes:
BUCKET_NAME
: Der Name Ihres Cloud Storage-Buckets.PATH
: Der Pfad zu dem Verzeichnis, in das Sie Ihre Dateien kopieren möchten, z. B./copy/jupyter/
.
Problem mit einer Instanz, die in der Bereitstellung festhängt, mit gcpdiag untersuchen
gcpdiag
ist ein Open-Source-Tool. Es ist kein offiziell unterstütztes Google Cloud -Produkt.
Mit dem Tool gcpdiag
können Sie Probleme mit Google Cloud-Projekten identifizieren und beheben. Weitere Informationen finden Sie im gcpdiag-Projekt auf GitHub.
gcpdiag
-Runbook werden mögliche Ursachen dafür untersucht, dass der Bereitstellungsstatus einer Vertex AI Workbench-Instanz nicht fortgesetzt wird. Dazu gehören die folgenden Bereiche:
- Status: Prüft den aktuellen Status der Instanz, um sicherzustellen, dass sie in der Bereitstellung festhängt und nicht angehalten oder aktiv ist.
- Compute Engine-VM-Bootlaufwerk-Image der Instanz: Es Wird geprüft, ob die Instanz mit einem benutzerdefinierten Container, einem offiziellen
workbench-instances
-Image, Deep Learning-VM-Images oder nicht unterstützten Images erstellt wurde, die dazu führen können, dass die Instanz im Bereitstellungsstatus hängen bleibt. - Benutzerdefinierte Scripts: Prüft, ob für die Instanz benutzerdefinierte Start- oder Post-Start-Scripts verwendet werden, die den Standard-Jupyter-Port ändern oder Abhängigkeiten aufheben, die dazu führen können, dass die Instanz im Bereitstellungsstatus hängen bleibt.
- Umgebungsversion: Prüft, ob für die Instanz die neueste Umgebungsversion verwendet wird, indem die Möglichkeit zum Upgrade geprüft wird. Bei älteren Versionen bleibt die Instanz möglicherweise im Bereitstellungsstatus hängen.
- Compute Engine-VM-Leistung der Instanz: Wird die aktuelle Leistung der VM geprüft, um sicherzustellen, dass sie nicht durch eine hohe CPU-Auslastung, einen unzureichenden Arbeitsspeicher oder Probleme mit dem Speicherplatz beeinträchtigt wird, die den normalen Betrieb beeinträchtigen könnten.
- Compute Engine-Seriellport oder Systemprotokollierung der Instanz: Prüft, ob die Instanz Protokolle für den seriellen Port hat. Diese werden analysiert, um sicherzustellen, dass Jupyter an Port
127.0.0.1:8080
ausgeführt wird. - Compute Engine-SSH- und Terminalzugriff der Instanz: Prüft, ob die Compute Engine-VM der Instanz ausgeführt wird, damit der Nutzer SSH verwenden und ein Terminal öffnen kann, um zu prüfen, ob die Speichernutzung unter „home/jupyter“ unter 85 % liegt. Wenn kein Speicherplatz mehr vorhanden ist, bleibt die Instanz möglicherweise im Bereitstellungsstatus hängen.
- Externe IP deaktiviert: Prüft, ob der externe IP-Zugriff deaktiviert ist. Eine falsche Netzwerkkonfiguration kann dazu führen, dass die Instanz im Bereitstellungsstatus hängen bleibt.
Google Cloud Console
- Führen Sie den folgenden Befehl aus und kopieren Sie ihn.
- Öffnen Sie die Google Cloud Console und aktivieren Sie Cloud Shell. Cloud Console öffnen
- Fügen Sie den kopierten Befehl ein.
- Führen Sie den Befehl
gcpdiag
aus, um das Docker-Imagegcpdiag
herunterzuladen und dann Diagnoseprüfungen durchzuführen. Folgen Sie gegebenenfalls der Anleitung für die Ausgabe, um fehlgeschlagene Prüfungen zu beheben.
gcpdiag runbook vertex/workbench-instance-stuck-in-provisioning \
--parameter project_id=PROJECT_ID \
--parameter instance_name=INSTANCE_NAME \
--parameter zone=ZONE
Docker
Sie können
gcpdiag
mit einem Wrapper ausführen, der gcpdiag
in einem Docker-Container startet. Docker oder Podman muss installiert sein.
- Kopieren Sie den folgenden Befehl und führen Sie ihn auf Ihrer lokalen Workstation aus.
curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
- Führen Sie den Befehl
gcpdiag
aus../gcpdiag runbook vertex/workbench-instance-stuck-in-provisioning \ --parameter project_id=PROJECT_ID \ --parameter instance_name=INSTANCE_NAME \ --parameter zone=ZONE
Verfügbare Parameter für dieses Runbook ansehen
Ersetzen Sie Folgendes:
- PROJECT_ID: Die ID des Projekts, das die Ressource enthält.
- INSTANCE_NAME: Der Name der Ziel-Vertex AI Workbench-Instanz in Ihrem Projekt.
- ZONE: Die Zone, in der sich die Ziel-Vertex AI Workbench-Instanz befindet.
Nützliche Flags:
--universe-domain
: Die Domain Trusted Partner Sovereign Cloud, auf der die Ressource gehostet wird--parameter
oder-p
: Runbook-Parameter
Eine Liste und Beschreibung aller gcpdiag
-Tool-Flags finden Sie in der gcpdiag
-Nutzungsanleitung.