Fehlerbehebung bei Vertex AI Workbench

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, der opt/conda/envs/ENVIRONMENT/bin/pip ähnelt. Sie können den Befehl which 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:

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 dem Start und legen Sie das Verhalten des Start-Scripts nach dem Start 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

Die angegebenen Reservierungen sind nicht vorhanden

Problem

Beim Erstellen der Instanz wird die Fehlermeldung Specified reservations do not exist ausgegeben. Die Ausgabe des Vorgangs könnte in etwa so aussehen:

{
  "name": "projects/PROJECT/locations/LOCATION/operations/OPERATION_ID",
  "metadata": {
    "@type": "type.googleapis.com/google.cloud.notebooks.v2.OperationMetadata",
    "createTime": "2025-01-01T01:00:01.000000000Z",
    "endTime": "2025-01-01T01:00:01.000000000Z",
    "target": "projects/PROJECT/locations/LOCATION/instances/INSTANCE_NAME",
    "verb": "create",
    "requestedCancellation": false,
    "apiVersion": "v2",
    "endpoint": "CreateInstance"
  },
  "done": true,
  "error": {
    "code": 3,
    "message": "Invalid value for field 'resource.reservationAffinity': '{  \"consumeReservationType\": \"SPECIFIC_ALLOCATION\",  \"key\": \"compute.googleapis.com/reservation-name...'. Specified reservations [projects/PROJECT/zones/ZONE/futureReservations/RESERVATION_NAME] do not exist.",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.RequestInfo",
        "requestId": "REQUEST_ID"
      }
    ]
  }
}

Lösung

Für einige Compute Engine-Maschinentypen sind beim Erstellen zusätzliche Parameter erforderlich, z. B. lokale Laufwerke oder eine minimale CPU-Plattform. Die Instanzspezifikation muss diese zusätzlichen Felder enthalten.

Für den Maschinentyp a3-megagpu-8g sind beispielsweise 16 lokale SSDs erforderlich, die in der Reservierung enthalten und in der Anfrage zum Erstellen der Instanz angegeben werden müssen.

BODY='{
  "gce_setup": {
    "machine_type": "a3-megagpu-8g",
    "reservation_affinity": {
      "consume_reservation_type": "RESERVATION_SPECIFIC",
      "key": "compute.googleapis.com/reservation-name",
      "values": ["RESERVATION_NAME"]
    },
    "bootDisk": {
        "disk_type": "PD_SSD",
        "diskSizeGb": "150",
        "diskEncryption": "GMEK"
    },
    "data_disks": [
      {
        "disk_type": "PD_SSD",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
      {
        "disk_type": "SCRATCH",
        "interface_type": "NVME",
      },
    ],
  }
}'

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 Standardgruppe von 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 Fehlers bei der Ressourcenverfügbarkeit 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

Stellen Sie mithilfe von SSH eine Verbindung zu JupyterLab her und lesen Sie mehr dazu, warum Sie möglicherweise nicht über den Inverting Proxy darauf zugreifen können.

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:

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:

  1. Klicken Sie auf der Seite „Nutzerverwaltete Notebooks“ der Google Cloud Console auf den Namen Ihrer Instanz, um die Seite Notebookdetails zu öffnen.

  2. Klicken Sie neben VM-Details ansehen auf In Compute Engine ansehen.

  3. Klicken Sie auf der Seite "VM-Details" auf Bearbeiten.

  4. Prüfen Sie im Abschnitt Metadaten, ob der Metadateneintrag proxy-mode auf mail festgelegt ist.

  5. Achten Sie darauf, dass der Metadateneintrag proxy-user-mail auf eine gültige Nutzer-E-Mail-Adresse festgelegt ist, nicht auf ein Dienstkonto.

  6. Klicken Sie auf Speichern.

  7. 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:

  1. Prüfen Sie, ob Ihre Instanz die Version M58 oder höher hat.

  2. Stellen Sie eine SSH-Verbindung zur Deep Learning-VM-Instanz her.

  3. 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.

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:

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 Befehl free.
  • 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

  1. Öffnen Sie in der Google Cloud Console die Seite IAM.

    IAM-Seite öffnen

  2. 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.

  3. 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

  1. Installieren Sie das Google Cloud CLI, falls noch nicht geschehen.

  2. 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'

  3. 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.

  4. 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 Fehlers bei der Ressourcenverfügbarkeit 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 Instanz
  • ZONE: 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:

  1. 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.

  2. 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.

  1. 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 Instanz
    • MY_PROJECT_ID: Ihre Projekt-ID
    • MY_ZONE: Zone, in der sich Ihre Instanz befindet.

  2. Beenden Sie mit dem folgenden Befehl die Instanz:

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

  3. Trennen Sie das Bootlaufwerk von der Instanz.

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

  4. Löschen Sie die VM der Instanz.

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

  5. Verwenden Sie die Notebooks API, um die nutzerverwaltete Notebookinstanz zu löschen.

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

  6. 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-Instanz
    • MY_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:

  1. Prüfen Sie, ob der Inverting Proxy-Agent ausgeführt wird. Machen Sie andernfalls mit Schritt 3 weiter.

  2. Starten Sie den Inverting-Proxy-Agent neu.

  3. Registrieren Sie sich noch einmal beim Inverting-Proxy-Server.

docker-service-Statusfehler

Führen Sie nach einem docker-service-Statusfehler die folgenden Schritte aus:

  1. Prüfen Sie, ob der Docker-Dienst ausgeführt wird.

  2. Starten Sie den Docker-Dienst neu.

jupyter-service-Statusfehler

Führen Sie nach einem jupyter-service-Statusfehler die folgenden Schritte aus:

  1. Prüfen Sie, ob der Jupyter-Dienst ausgeführt wird.

  2. Starten Sie den Jupyter-Dienst neu.

jupyter-api-Statusfehler

Führen Sie nach einem jupyter-api-Statusfehler die folgenden Schritte aus:

  1. Prüfen, ob die interne Jupyter API aktiv ist.

  2. Starten Sie den Jupyter-Dienst neu.

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:

  1. Prüfen Sie über eine Terminalsitzung in der nutzerverwalteten Notebookinstanz oder über eine SSH-Verbindung den freien Speicherplatz mit dem Befehl df -H.

  2. 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.

  3. 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:

  1. 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.

  2. 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.

  3. 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-ID
  • ZONE: Die Google Cloud Zone, in der sich Ihre Instanz befindet
  • INSTANCE_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: 
    gcloud storage buckets create gs://BUCKET_NAME
     Replace BUCKET_NAME with a bucket name that meets the bucket naming requirements.

Nutzerdaten kopieren

  1. 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.

  2. 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.

In diesem 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

  1. Führen Sie den folgenden Befehl aus und kopieren Sie ihn. 
    2. gcpdiag runbook vertex/workbench-instance-stuck-in-provisioning \
    --parameter project_id=PROJECT_ID \
    --parameter instance_name=INSTANCE_NAME \
    --parameter zone=ZONE
  2. Öffnen Sie die Google Cloud Console und aktivieren Sie Cloud Shell.
    3. Cloud Console öffnen
  3. Fügen Sie den kopierten Befehl ein.
  4. Führen Sie den Befehl gcpdiag aus, um das Docker-Image gcpdiag herunterzuladen und dann Diagnoseprüfungen durchzuführen. Folgen Sie gegebenenfalls der Anleitung für die Ausgabe, um fehlgeschlagene Prüfungen zu beheben.

Docker

Sie können gcpdiag mit einem Wrapper ausführen, der gcpdiag in einem Docker-Container startet. Docker oder Podman muss installiert sein.

  1. 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
  2. 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:

Eine Liste und Beschreibung aller gcpdiag-Tool-Flags finden Sie in der gcpdiag-Nutzungsanleitung.