이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Vertex AI Workbench 문제 해결

이 페이지에서는 Vertex AI Workbench 사용 시 문제가 발생할 경우 도움이 될 수 있는 문제 해결 단계를 설명합니다.

Vertex AI의 다른 구성요소를 사용하는 데 도움이 필요하면 Vertex AI 문제 해결도 참고하세요.

이 페이지의 콘텐츠를 필터링하려면 주제를 클릭합니다.

Vertex AI Workbench 인스턴스

이 섹션에서는 Vertex AI Workbench 인스턴스의 문제 해결 단계를 설명합니다.

JupyterLab에 연결 및 열기

이 섹션에서는 JupyterLab 연결 및 열기와 관련된 문제 해결 단계에 대해 설명합니다.

JupyterLab 열기를 클릭해도 아무 반응이 없음

문제

JupyterLab 열기를 클릭해도 아무 반응이 없습니다.

해결책

브라우저에서 새 탭 자동 열기가 차단되지 않았는지 확인합니다. JupyterLab은 새 브라우저 탭에서 열립니다.

Vertex AI Workbench 인스턴스에서 터미널에 액세스할 수 없음

문제

터미널에 액세스할 수 없거나 런처에서 터미널 창을 찾을 수 없다면 Vertex AI Workbench 인스턴스에 터미널 액세스가 사용 설정되지 않았기 때문일 수 있습니다.

해결책

터미널 액세스 옵션을 사용 설정하여 새 Vertex AI Workbench 인스턴스를 만들어야 합니다. 인스턴스를 만든 후에는 이 옵션을 변경할 수 없습니다.

JupyterLab을 열 때 502 오류 발생

문제

502 오류는 Vertex AI Workbench 인스턴스가 아직 준비되지 않았음을 의미합니다.

해결책

몇 분 정도 기다린 후 Google Cloud 콘솔 브라우저 탭을 새로고침하고 다시 시도합니다.

노트북이 응답하지 않음

문제

Vertex AI Workbench 인스턴스가 셀을 실행 중이 아니거나 고정된 것으로 보입니다.

해결책

먼저 상단 메뉴에서 커널을 클릭하고 커널 다시 시작을 클릭하여 커널을 다시 시작해봅니다. 그래도 문제가 해결되지 않으면 다음 안내를 따르세요.

JupyterLab 브라우저 페이지를 새로고침합니다. 저장되지 않은 셀 출력은 지속되지 않으므로 이러한 셀을 다시 실행하여 출력을 다시 생성해야 합니다.
인스턴스를 재설정합니다.

SSH를 사용하여 Vertex AI Workbench 인스턴스에 연결할 수 없음

문제

터미널 창을 통해 SSH를 사용해서 인스턴스에 연결할 수 없습니다.

Vertex AI Workbench 인스턴스는 OS 로그인을 사용하여 SSH 액세스를 사용 설정합니다. 인스턴스를 만들 때 Vertex AI Workbench는 메타데이터 키 enable-oslogin을 TRUE로 설정하여 기본적으로 OS 로그인을 사용 설정합니다. SSH를 사용해서 인스턴스에 액세스할 수 없으면 이 메타데이터 키를 TRUE로 설정해야 할 수 있습니다.

해결책

Google Cloud 콘솔을 사용하여 Vertex AI Workbench 인스턴스에 연결하는 방식은 지원되지 않습니다. 터미널 창을 통해 SSH를 사용하여 인스턴스에 연결할 수 없으면 다음을 참조하세요.

메타데이터 키 enable-oslogin을 TRUE로 설정하려면 Notebooks API의 projects.locations.instances.patch 메서드 또는 Google Cloud SDK에서 gcloud workbench instances update 명령어를 사용합니다.

GPU 할당량이 초과됨

문제

GPU를 사용해서 Vertex AI Workbench 인스턴스를 만들 수 없습니다.

해결책

할당량 페이지에서 프로젝트의 현재 사용 가능한 GPU 수를 확인합니다. GPU가 할당량 페이지에 나와 있지 않거나 추가 GPU 할당량이 필요한 경우 할당량 상향 조정을 요청하세요. 할당량 한도 상향 요청을 참고하세요.

Vertex AI Workbench 인스턴스 만들기

이 섹션에서는 Vertex AI Workbench 인스턴스 만들기와 관련된 문제 해결 방법을 설명합니다.

인스턴스가 무기한 대기 중 상태로 유지되거나 프로비저닝 상태에서 멈춤

문제

Vertex AI Workbench 인스턴스를 만든 후에는 인스턴스가 무기한 대기 상태로 유지됩니다. 다음과 같은 오류가 직렬 로그에 표시될 수 있습니다.

Could not resolve host: notebooks.googleapis.com

인스턴스가 프로비저닝 상태에서 멈춘 경우 인스턴스에 잘못된 비공개 네트워킹 구성이 적용되어 있을 수 있습니다.

해결책

인스턴스 로그에 연결 또는 시간 초과 오류가 표시됨 섹션의 단계를 따릅니다.

공유 VPC 네트워크 내에서 인스턴스를 만들 수 없음

문제

공유 VPC 네트워크 내에서 인스턴스를 만들려고 시도하면 다음과 같은 오류 메시지가 표시됩니다.

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

해결책

문제는 Notebooks 서비스 계정이 올바른 권한 없이 인스턴스를 만들려고 시도 중이기 때문입니다.

Notebooks 서비스 계정이 공유 VPC 네트워크 내에서 Vertex AI Workbench 인스턴스를 만들 수 있도록 하려면 관리자에게 Notebooks 서비스 계정에 호스트 프로젝트에 대한 컴퓨팅 네트워크 사용자 역할 (roles/compute.networkUser) IAM 역할을 부여해 달라고 요청하세요. 역할 부여에 대한 상세 설명은 프로젝트, 폴더, 조직에 대한 액세스 관리를 참조하세요.

이 사전 정의된 역할에는 Notebooks 서비스 계정이 공유 VPC 네트워크 내에서 Vertex AI Workbench 인스턴스를 만들 수 있는지 확인하는 데 필요한 권한이 포함되어 있습니다. 필요한 정확한 권한을 보려면 필수 권한 섹션을 펼치세요.

필수 권한

Notebooks 서비스 계정이 공유 VPC 네트워크 내에서 Vertex AI Workbench 인스턴스를 만들 수 있도록 하려면 다음 권한이 필요합니다.

서브네트워크를 사용하려면 다음 단계를 따르세요. compute.subnetworks.use

관리자는 커스텀 역할이나 다른 사전 정의된 역할을 사용하여 Notebooks 서비스 계정에 이러한 권한을 부여할 수도 있습니다.

커스텀 컨테이너로 Vertex AI Workbench 인스턴스를 만들 수 없음

문제

Google Cloud 콘솔에서 Vertex AI Workbench 인스턴스를 만들 때는 커스텀 컨테이너를 사용하는 옵션이 없습니다.

해결책

커스텀 컨테이너를 Vertex AI Workbench 인스턴스에 추가할 수 없으며 Google Cloud 콘솔을 사용하여 커스텀 컨테이너를 추가할 수 없습니다.

커스텀 컨테이너를 사용하는 대신 conda 환경을 추가하는 것이 좋습니다.

Notebooks API를 사용하여 커스텀 컨테이너를 Vertex AI Workbench 인스턴스에 추가할 수 있지만 이 기능은 지원되지 않습니다.

공유 스토리지 마운트 버튼이 없음

문제

JupyterLab 인터페이스의 파일 브라우저 탭에 공유 스토리지 마운트 버튼이 없습니다.

해결책

Vertex AI Workbench 인스턴스의 JupyterLab 인터페이스에 공유 스토리지 마운트 버튼을 표시하려면 storage.buckets.list 권한이 필요합니다. 관리자에게 Vertex AI Workbench 인스턴스의 서비스 계정에 프로젝트에 대한 storage.buckets.list 권한을 부여해 달라고 요청하세요.

Dataproc을 사용할 때 599 오류 발생

문제

Dataproc이 사용 설정된 인스턴스를 만들려고 시도하면 다음과 같은 오류 메시지가 표시됩니다.

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

해결책

Cloud DNS 구성에서 *.googleusercontent.com 도메인의 Cloud DNS 항목을 추가합니다.

서드 파티 JupyterLab 확장 프로그램을 설치할 수 없음

문제

서드 파티 JupyterLab 확장 프로그램을 설치하려고 시도하면 Error: 500 메시지가 표시됩니다.

해결책

서드 파티 JupyterLab 확장 프로그램은 Vertex AI Workbench 인스턴스에서 지원되지 않습니다.

기본 가상 머신을 수정할 수 없음

문제

Vertex AI Workbench 인스턴스의 기본 가상 머신(VM)을 수정하려고 하면 다음과 비슷한 오류 메시지가 표시될 수 있습니다.

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

해결책

이 오류는 Google Cloud 콘솔 또는 Compute Engine API를 사용하여 인스턴스의 기본 VM을 수정할 수 없기 때문에 발생합니다.

Vertex AI Workbench 인스턴스의 기본 VM을 수정하려면 Notebooks API의 projects.locations.instances.patch 메서드 또는 Google Cloud SDK의 gcloud workbench instances update 명령어를 사용합니다.

conda 환경을 추가한 후 `pip` 패키지를 사용할 수 없음

문제

conda 기반 커널을 추가한 후 pip 패키지를 사용할 수 없습니다.

해결책

이 문제를 해결하려면 conda 환경 추가를 참조하고 다음을 시도하세요.

DL_ANACONDA_ENV_HOME 변수가 사용되었고 환경 이름이 포함되었는지 확인합니다.
pip가 opt/conda/envs/ENVIRONMENT/bin/pip와 비슷한 경로에 있는지 확인합니다. which pip 명령어를 사용하여 경로를 가져올 수 있습니다.

단일 사용자 액세스로 인스턴스의 데이터에 액세스하거나 복사할 수 없음

문제

단일 사용자 액세스로 인스턴스의 데이터에 액세스할 수 없습니다.

단일 사용자 액세스로 설정된 Vertex AI Workbench 인스턴스의 경우 지정된 단일 사용자(소유자)만 인스턴스의 데이터에 액세스할 수 있습니다.

해결책

인스턴스 소유자가 아닐 때 데이터를 액세스하거나 복사하려면 지원 케이스를 개설합니다.

예기치 않은 종료

문제

Vertex AI Workbench 인스턴스가 예기치 않게 종료됩니다.

해결책

인스턴스가 예기치 않게 종료되면 유휴 상태 종료가 초기화되었기 때문일 수 있습니다.

유휴 상태 종료를 사용 설정했으면 지정된 기간 동안 커널 활동이 없을 때 인스턴스가 종료됩니다. 예를 들어 노트북에 셀 또는 새 출력 인쇄를 실행하는 것은 유휴 제한 시간 타이머를 재설정하는 활동입니다. CPU 사용량은 유휴 제한 시간 타이머를 재설정하지 않습니다.

인스턴스 로그에 연결 또는 시간 초과 오류가 표시됨

문제

Vertex AI Workbench 인스턴스의 로그에 연결 또는 시간 초과 오류가 표시됩니다.

해결책

인스턴스 로그에 연결 또는 시간 초과 오류가 표시되면 Jupyter 서버가 포트 8080에서 실행 중인지 확인합니다. Jupyter 내부 API가 활성 상태인지 확인 섹션의 단계를 따릅니다.

External IP를 사용 중지하고 비공개 VPC 네트워크를 사용하는 경우 네트워크 구성 옵션 문서도 따르세요. 다음 사항을 고려하세요.

VPC 호스트 프로젝트에서 인스턴스가 있는 리전과 동일한 리전에 있는 선택한 서브넷에서 비공개 Google 액세스를 사용 설정해야 합니다. 비공개 Google 액세스 구성에 관한 자세한 내용은 비공개 Google 액세스 문서를 참고하세요.
Cloud DNS를 사용하는 경우 인스턴스가 네트워크 구성 옵션 문서에 지정된 필수 Cloud DNS 도메인을 확인할 수 있어야 합니다. 이를 확인하려면 인스턴스가 필요한 DNS 도메인을 확인할 수 있는지 확인하기 섹션의 단계를 따르세요.

인스턴스 로그에 'Jupyter API에 연결할 수 없음' 'ReadTimeoutError'가 표시됨

문제

Vertex AI Workbench 인스턴스 로그에 다음과 같은 오류가 표시됩니다.

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

해결책

인스턴스 로그에 연결 또는 시간 초과 오류가 표시됨 섹션의 단계를 따릅니다. Notebooks 수집 에이전트 스크립트를 수정하여 HTTP_TIMEOUT_SESSION를 더 큰 값(예: 60)으로 변경하여 호출이 응답하는 데 시간이 너무 오래 걸리거나 요청된 URL에 연결할 수 없어 요청이 실패했는지 확인할 수도 있습니다.

`docker0` 주소가 VPC 주소 지정과 충돌함

문제

기본적으로 docker0 인터페이스는 IP 주소 172.17.0.1/16로 생성됩니다. 이로 인해 VPC 네트워크의 IP 주소 지정과 충돌하여 인스턴스가 172.17.0.1/16 주소가 있는 다른 엔드포인트에 연결할 수 없게 될 수 있습니다.

해결책

다음 시작 후 스크립트를 사용하고 시작 후 스크립트 동작을 run_once로 설정하여 VPC 네트워크와 충돌하지 않는 IP 주소로 docker0 인터페이스가 생성되도록 강제할 수 있습니다.

   #!/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

지정된 예약이 없음

문제

인스턴스를 만드는 작업으로 인해 Specified reservations do not exist 오류 메시지가 표시됩니다. 작업의 출력은 다음과 유사할 수 있습니다.

{
  "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"
      }
    ]
  }
}

해결책

일부 Compute Engine 머신 유형은 생성 시 로컬 디스크나 최소 CPU 플랫폼과 같은 추가 매개변수가 필요합니다. 인스턴스 사양에는 이러한 추가 필드가 포함되어야 합니다.

예를 들어 a3-megagpu-8g 머신 유형에는 로컬 SSD 디스크 16개가 필요하며, 이 디스크는 예약에 포함되어야 하고 인스턴스 생성 요청에 지정되어야 합니다.

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",
      },
    ],
  }
}'

관리형 노트북

이 섹션에서는 관리형 노트북의 문제 해결 단계를 설명합니다.

JupyterLab에 연결 및 열기

이 섹션에서는 JupyterLab 연결 및 열기와 관련된 문제 해결 방법에 대해 설명합니다.

JupyterLab 열기를 클릭해도 아무 반응이 없음

문제

JupyterLab 열기를 클릭해도 아무 반응이 없습니다.

해결책

브라우저에서 새 탭 자동 열기가 차단되지 않았는지 확인합니다. JupyterLab은 새 브라우저 탭에서 열립니다.

SSH를 사용해서 관리형 노트북 인스턴스에 연결할 수 없음

문제

SSH를 사용하여 관리형 노트북 인스턴스에 연결하는 옵션이 없습니다.

해결책

관리형 노트북 인스턴스에 대해 SSH 액세스 권한을 사용할 수 없습니다.

관리형 노트북 인스턴스의 터미널에 액세스할 수 없음

문제

터미널에 액세스할 수 없거나 런처에서 터미널 창을 찾을 수 없는 경우 관리형 노트북 인스턴스에 터미널 액세스가 사용 설정되지 않았기 때문일 수 있습니다.

해결책

터미널 액세스 옵션을 사용 설정하여 새 관리형 노트북 인스턴스를 만들어야 합니다. 인스턴스를 만든 후에는 이 옵션을 변경할 수 없습니다.

JupyterLab을 열 때 502 오류 발생

문제

502 오류는 관리형 노트북 인스턴스가 아직 준비되지 않았음을 의미합니다.

해결책

몇 분 정도 기다린 후 Google Cloud 콘솔 브라우저 탭을 새로고침하고 다시 시도합니다.

노트북을 열면 524(시간 초과 발생) 오류 발생

문제

524 오류는 대개 역방향 프록시 에이전트가 역방향 프록시 서버에 연결되지 않거나 백엔드 서버 측(Jupyter)에서 시간이 너무 오래 걸리는 경우에 발생합니다. 이 오류의 일반적인 원인은 네트워킹 문제가 있거나, 역방향 프록시 에이전트가 실행되고 있지 않거나, Jupyter 서비스가 실행되고 있지 않기 때문입니다.

해결책

관리형 노트북 인스턴스가 시작되었는지 확인합니다.

노트북이 응답하지 않음

문제

관리형 노트북이 셀을 실행 중이 아니거나 고정된 것으로 보입니다.

해결책

JupyterLab 브라우저 페이지를 새로고침합니다. 저장되지 않은 셀 출력은 지속되지 않으므로 이러한 셀을 다시 실행하여 출력을 다시 생성해야 합니다.
인스턴스를 재설정합니다.

Vertex AI Workbench 인스턴스로 마이그레이션

이 섹션에서는 관리형 노트북 인스턴스에서 Vertex AI Workbench 인스턴스로 마이그레이션과 관련된 문제를 진단하고 해결하기 위한 방법들에 대해 설명합니다.

관리형 노트북 인스턴스에 있던 커널을 찾을 수 없음

문제

관리형 노트북 인스턴스에 있던 커널이 사용자가 마이그레이션한 Vertex AI Workbench 인스턴스에 표시되지 않습니다.

커스텀 컨테이너는 관리형 노트북에 커널로 표시됩니다. Vertex AI Workbench 마이그레이션 도구는 커스텀 컨테이너 마이그레이션을 지원하지 않습니다.

해결책

이 문제를 해결하려면 Vertex AI Workbench 인스턴스에 conda 환경을 추가합니다.

마이그레이션된 인스턴스의 프레임워크 버전이 서로 다름

문제

관리형 노트북 인스턴스에 있던 프레임워크가 사용자가 마이그레이션한 Vertex AI Workbench 인스턴스에 있는 것과 버전이 다릅니다.

Vertex AI Workbench 인스턴스는 기본 프레임워크 버전 집합을 제공합니다. 마이그레이션 도구는 원래 관리형 노트북 인스턴스에서 프레임워크 버전을 추가하지 않습니다. 기본 마이그레이션 도구 동작을 참조하세요.

해결책

특정 버전의 프레임워크를 추가하려면 Vertex AI Workbench 인스턴스에 conda 환경을 추가합니다.

GPU가 새 Vertex AI Workbench 인스턴스에 마이그레이션되지 않음

문제

관리형 노트북 인스턴스에 있던 GPU가 사용자가 마이그레이션한 Vertex AI Workbench 인스턴스에 없습니다.

Vertex AI Workbench 인스턴스는 기본 GPU 집합을 지원합니다. 원래 관리형 노트북 인스턴스의 GPU를 사용할 수 없으면 GPU 없이 인스턴스가 마이그레이션됩니다.

해결책

마이그레이션 후에는 Notebooks API의 projects.locations.instances.patch 메서드 또는 Google Cloud SDK의 gcloud workbench instances update 명령어를 사용해서 Vertex AI Workbench 인스턴스에 GPU를 추가할 수 있습니다.

마이그레이션된 인스턴스의 머신 유형이 서로 다름

문제

관리형 노트북 인스턴스의 머신 유형이 사용자가 마이그레이션한 Vertex AI Workbench 인스턴스와 다릅니다.

Vertex AI Workbench 인스턴스는 모든 머신 유형을 지원하지 않습니다. 원래 관리형 노트북 인스턴스의 머신 유형을 사용할 수 없으면 인스턴스가 e2-standard-4 머신 유형으로 마이그레이션됩니다.

해결책

마이그레이션 후에는 Notebooks API의 projects.locations.instances.patch 메서드 또는 Google Cloud SDK의 gcloud workbench instances update 명령어를 사용하여 Vertex AI Workbench 인스턴스의 머신 유형을 변경할 수 있습니다.

GPU 할당량이 초과됨

문제

GPU를 사용하여 관리형 노트북 인스턴스를 만들 수 없습니다.

해결책

컨테이너 이미지 사용

이 섹션에서는 컨테이너 이미지 사용과 관련된 문제 해결에 대해 설명합니다.

JupyterLab에서 컨테이너 이미지가 커널로 표시되지 않음

문제

유효한 kernelspec이 없는 컨테이너 이미지는 JupyterLab에서 커널로 성공적으로 로드되지 않습니다.

해결책

컨테이너가 요구사항을 충족하는지 확인합니다. 자세한 내용은 커스텀 컨테이너 요구사항을 참조하세요.

장기 실행 작업 중 노트북 연결이 해제됨

문제

노트북에서 작업을 실행할 때 다음 오류 메시지가 표시되는 경우에는 요청이 로드되는 데 너무 오래 걸리거나, CPU 또는 메모리 사용률이 너무 높아서 Jupyter 서비스가 응답하지 않을 수 있기 때문에 발생할 수 있습니다.

{"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"}

해결책

이 문제는 노트북 내에서 장기 실행 작업을 실행하여 발생합니다. 완료하는 데 오래 걸릴 수 있는 작업을 실행하려면 실행자를 사용하는 것이 좋습니다.

실행자 사용

이 섹션에서는 실행자 사용과 관련된 문제 해결에 대해 설명합니다.

실행자가 패키지 설치를 사용할 수 없음

문제

실행자는 노트북 파일의 코드를 실행하는 커널과 별도의 환경에서 노트북 코드를 실행합니다. 이로 인해 설치한 일부 패키지를 실행자 환경에서 사용하지 못할 수 있습니다.

해결책

이 문제를 해결하려면 실행자가 패키지 설치를 사용할 수 있는지 확인을 참조하세요.

실행자를 사용하여 노트북 코드를 실행할 때 401 또는 403 오류

문제

실행자를 실행할 때 401 또는 403 오류가 발생하면 실행자가 리소스에 액세스할 수 없음을 의미합니다.

해결책

가능한 원인은 다음을 참조하세요.

실행자는 관리형 노트북 인스턴스의 프로젝트와 별도의 테넌트 프로젝트에서 노트북 코드를 실행합니다. 따라서 실행자가 실행하는 코드를 통해 리소스에 액세스할 때 실행자가 기본적으로 올바른 Google Cloud 프로젝트에 연결되지 않을 수 있습니다. 이 문제를 해결하려면 명시적 프로젝트 선택을 사용합니다.
기본적으로 관리형 노트북 인스턴스는 동일한 프로젝트에 있는 리소스에 액세스할 수 있으므로, 노트북 파일의 코드를 수동으로 실행하면 이러한 리소스에 추가 인증이 필요하지 않습니다. 그러나 실행자는 별도의 테넌트 프로젝트에서 실행되므로 실행자에는 동일한 기본 액세스 권한이 없습니다. 이 문제를 해결하려면 서비스 계정을 사용하여 액세스를 인증하세요.
실행자는 최종 사용자 인증 정보를 사용하여 gcloud auth login 명령어와 같은 리소스에 대한 액세스를 인증할 수 없습니다. 이 문제를 해결하려면 서비스 계정을 사용하여 액세스를 인증하세요.

실행자를 사용할 때의 `exited with a non-zero status of 127` 오류

문제

exited with a non-zero status of 127 오류 또는 '명령을 찾을 수 없음' 오류는 nbexecutor 확장 프로그램이 설치되지 않은 커스텀 컨테이너에서 실행자를 사용하여 코드를 실행하려고 할 때 발생할 수 있습니다.

해결책

커스텀 컨테이너에 nbexecutor 확장이 포함되었는지 확인하려면 Deep Learning Containers 이미지에서 파생 컨테이너 이미지를 만들 수 있습니다. Deep Learning Containers 이미지에는 nbexecutor 확장 프로그램이 포함되어 있습니다.

잘못된 서비스 네트워킹 구성 오류 메시지

문제

이 오류는 다음과 같이 표시될 수 있습니다.

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

네트워크에 할당된 IP 범위에서 사용 가능한 블록이 없다는 의미입니다.

해결책

/24 이하의 서브넷 마스크를 사용하세요. 더 큰 할당된 IP 주소 범위를 만들고 servicenetworking-googleapis-com에 대해 비공개 서비스 연결을 수정하여 이 범위를 연결합니다.

자세한 내용은 네트워크 설정을 참조하세요.

서드 파티 JupyterLab 확장 프로그램을 설치할 수 없음

문제

서드 파티 JupyterLab 확장 프로그램을 설치하려고 시도하면 Error: 500 메시지가 표시됩니다.

해결책

서드 파티 JupyterLab 확장 프로그램은 관리형 노트북 인스턴스에서 지원되지 않습니다.

단일 사용자 액세스로 인스턴스의 데이터에 액세스하거나 복사할 수 없음

문제

단일 사용자 액세스로 인스턴스의 데이터에 액세스할 수 없습니다.

해결책

단일 사용자 액세스로 설정된 관리형 노트북 인스턴스의 경우 지정된 단일 사용자(소유자)만 인스턴스의 데이터에 액세스할 수 있습니다.

인스턴스 소유자가 아닐 때 데이터를 액세스하거나 복사하려면 지원 케이스를 개설합니다.

예기치 않은 종료

문제

Vertex AI Workbench 인스턴스가 예기치 않게 종료됩니다.

해결책

인스턴스가 예기치 않게 종료되면 유휴 상태 종료가 초기화되었기 때문일 수 있습니다.

인스턴스 복원

문제

관리형 노트북 인스턴스를 삭제한 후 복원하는 기능은 지원되지 않습니다.

해결책

인스턴스의 데이터를 백업하려면 노트북을 GitHub에 저장하면 됩니다.

인스턴스에서 데이터 복구

문제

관리형 노트북 인스턴스를 삭제한 후 해당 인스턴스의 데이터를 복구하는 기능은 지원되지 않습니다.

해결책

인스턴스의 데이터를 백업하려면 노트북을 GitHub에 저장하면 됩니다.

관리형 노트북 인스턴스 만들기

이 섹션에서는 관리형 노트북 인스턴스 만들기와 관련된 문제 해결에 대해 설명합니다.

오류: 연결을 만드는 중 문제 발생

문제

인스턴스를 만드는 동안 이 오류가 발생합니다.

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

해결책

/24 보다 큰 할당된 IP 범위를 만들고 servicenetworking-googleapis-com 연결에 대한 비공개 서비스 연결을 수정하여 이 범위를 연결합니다.

인스턴스를 만들면 리소스 가용성 오류가 발생함

문제

리소스 가용성 오류로 인해 인스턴스를 만들 수 없습니다.

이 오류는 다음과 같이 표시될 수 있습니다.

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

GPU 또는 CPU와 같은 Compute Engine 리소스를 현재 사용할 수 없어서 요청을 처리할 수 없는 영역에서 새 리소스를 요청하면 오류가 발생합니다.

리소스 오류는 영역의 새 리소스 요청에만 적용되며 기존 리소스에는 영향을 미치지 않습니다. 리소스 오류는 Compute Engine 할당량과 관련이 없습니다. 리소스 오류는 일시적이며 수요 변동에 따라 자주 바뀔 수 있습니다.

해결책

계속하려면 다음을 시도합니다.

다른 머신 유형으로 인스턴스를 만듭니다.
다른 영역에 인스턴스를 만듭니다.
나중에 요청을 다시 시도합니다.
요청하는 리소스의 양을 줄입니다. 예를 들어 GPU, 디스크, vCPU 또는 메모리를 줄여서 인스턴스를 만들어 보세요.

인스턴스를 시작하면 리소스 가용성 오류가 발생함

문제

리소스 가용성 오류로 인해 인스턴스를 시작할 수 없습니다.

이 오류는 다음과 같이 표시될 수 있습니다.

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

GPU 또는 CPU 등, Compute Engine 리소스를 현재 사용할 수 없어서 요청을 처리할 수 없는 영역에서 인스턴스를 시작하려고 하면 오류가 발생합니다.

리소스 오류는 영역에 있는 모든 리소스가 아니라 요청을 전송한 시간에 요청에 지정된 리소스에만 적용됩니다. 리소스 오류는 Compute Engine 할당량과 관련이 없습니다. 리소스 오류는 일시적이며 수요 변동에 따라 자주 바뀔 수 있습니다.

해결책

계속하려면 다음을 시도합니다.

인스턴스의 머신 유형을 변경합니다.
파일과 데이터를 다른 영역의 인스턴스로 이전합니다.
나중에 요청을 다시 시도합니다.
요청하는 리소스의 양을 줄입니다. 예를 들어 GPU, 디스크, vCPU 또는 메모리를 줄여 다른 인스턴스를 시작합니다.

관리형 노트북의 아웃바운드 연결에 대한 `No route to host`

문제

일반적으로 Google Cloud 콘솔에 표시되는 유일한 경로는 VPC 네트워크 피어링 구성을 완료할 때 예약된 범위와 자체 VPC에 알려진 경로입니다.

관리형 노트북 인스턴스는 Google 관리 네트워크에 있으며 인스턴스 내 Docker 네트워킹 네임스페이스에서 수정된 버전의 Jupyter를 실행합니다.

이 인스턴스의 Docker 네트워크 인터페이스와 Linux 브리지는 VPC의 피어링을 통해 내보내는 IP 범위와 충돌하는 로컬 IP를 선택할 수 있습니다. 일반적으로 172.16.0.0/161 및 192.168.10.0/24 범위에 있습니다.

이러한 상황에서 VPC 경로가 올바르게 공유되더라도 인스턴스에서 해당 범위로의 아웃바운드 연결이 실패하고 No route to host와 약간 다른 오류가 표시됩니다.

해결책

터미널 세션에서 ifconfig를 호출하고 인스턴스의 가상 인터페이스에 있는 IP 주소가 VPC가 피어링 연결로 내보내는 IP 범위와 충돌하지 않는지 확인합니다.

사용자 관리 노트북

이 섹션에서는 사용자 관리 노트북의 문제 해결 단계를 설명합니다.

JupyterLab에 연결 및 열기

이 섹션에서는 JupyterLab 연결 및 열기와 관련된 문제 해결 방법에 대해 설명합니다.

JupyterLab 열기를 클릭해도 아무 반응이 없음

문제

JupyterLab 열기를 클릭해도 아무 반응이 없습니다.

해결책

브라우저에서 새 탭 자동 열기가 차단되지 않았는지 확인합니다. JupyterLab은 새 브라우저 탭에서 열립니다.

JupyterLab에 대한 역방향 프록시 서버 액세스 없음

문제

JupyterLab에 액세스할 수 없습니다.

Vertex AI Workbench는 Google 내부 역방향 프록시 서버를 사용하여 JupyterLab에 대한 액세스 권한을 제공합니다. 사용자 관리 노트북 인스턴스 설정, 네트워크 구성, 기타 요인으로 인해 JupyterLab에 대한 액세스가 차단될 수 있습니다.

해결책

SSH를 통해 JupyterLab에 연결하고 역방향 프록시를 통해 액세스할 수 없는 이유를 자세히 알아보세요.

SSH를 사용해서 사용자 관리 노트북 인스턴스에 연결할 수 없음

문제

터미널 창을 통해 SSH를 사용해서 인스턴스에 연결할 수 없습니다.

사용자 관리 노트북 인스턴스는 OS 로그인을 사용하여 SSH 액세스를 사용 설정합니다. 인스턴스를 만들 때 Vertex AI Workbench는 메타데이터 키 enable-oslogin을 TRUE로 설정하여 기본적으로 OS 로그인을 사용 설정합니다. SSH를 사용해서 인스턴스에 액세스할 수 없으면 이 메타데이터 키를 TRUE로 설정해야 할 수 있습니다.

해결책

사용자의 사용자 관리 노트북에 SSH 액세스를 사용 설정하려면 사용자 계정에 OS 로그인 역할을 구성하는 단계를 완료합니다.

사용자 관리 노트북 인스턴스를 열면 403(금지됨) 오류 발생

문제

사용자 관리 노트북 인스턴스를 열 때 403 (Forbidden) 오류는 액세스 문제가 있음을 의미하는 경우가 많습니다.

해결책

액세스 문제를 해결하려면 사용자 관리 노트북 인스턴스에 액세스 권한을 부여하는 다음의 세 가지 방법을 고려하세요.

단일 사용자
서비스 계정
프로젝트 편집자

액세스 모드는 사용자 관리 노트북 인스턴스 생성 중에 구성되며 노트북 메타데이터에 정의됩니다.

단일 사용자: proxy-mode=mail, proxy-user-mail=user@domain.com
서비스 계정: proxy-mode=service_account
프로젝트 편집자: proxy-mode=project_editors

JupyterLab 열기를 클릭하여 노트북에 액세스할 수 없는 경우 다음을 시도해 봅니다.

proxy-mode 메타데이터 항목이 올바른지 확인합니다.
인스턴스에 액세스하는 사용자에게 인스턴스의 서비스 계정에 대한 iam.serviceAccounts.ActAs 권한이 있는지 확인합니다. 서비스 계정은 Compute Engine 기본 서비스 계정 또는 인스턴스를 만들 때 지정된 서비스 계정입니다.
인스턴스가 단일 사용자로 지정된 서비스 계정으로 단일 사용자 액세스를 사용하는 경우 JupyterLab 액세스 없음, 단일 사용자 모드 사용 설정됨을 참조하세요.

다음 예시에서는 인스턴스를 만들 때 서비스 계정을 지정하는 방법을 보여줍니다.

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

JupyterLab 열기를 클릭하여 노트북을 열면 새 브라우저 탭에서 노트북이 열립니다. 두 개 이상의 Google 계정에 로그인되어 있으면 기본 Google 계정으로 새 탭이 열립니다. 기본 Google 계정을 사용하여 사용자 관리 노트북 인스턴스를 만들지 않은 경우 새 브라우저 탭에 403 (Forbidden) 오류가 표시됩니다.

JupyterLab 액세스 없음, 단일 사용자 모드 사용 설정됨

문제

JupyterLab에 액세스할 수 없습니다.

해결책

사용자가 JupyterLab에 액세스할 수 없고 JupyterLab에 대한 인스턴스의 액세스 권한이 Single user only로 설정되어 있으면 다음을 시도해 보세요.

Google Cloud 콘솔의 사용자 관리 노트북 페이지에서 인스턴스 이름을 클릭하여 노트북 세부정보 페이지를 엽니다.
VM 세부정보 보기 옆에서 Compute Engine에서 보기를 클릭합니다.
VM 세부정보 페이지에서 수정을 클릭합니다.
메타데이터 섹션에서 proxy-mode 메타데이터 항목이 mail로 설정되었는지 확인합니다.
proxy-user-mail 메타데이터 항목이 서비스 계정이 아닌 유효한 사용자 이메일 주소로 설정되었는지 확인합니다.
저장을 클릭합니다.
Google Cloud 콘솔의 사용자 관리 노트북 페이지에서 인스턴스를 중지하고 인스턴스 백업을 다시 시작하여 업데이트된 메타데이터를 초기화합니다.

노트북을 열면 504(게이트웨이 시간 초과) 오류 발생

문제

이는 내부 프록시 시간 초과 또는 백엔드 서버(Jupyter) 시간 초과를 나타냅니다. 다음과 같은 경우에 표시됩니다.

요청이 내부 역방향 프록시 서버에 도달하지 않았습니다.
백엔드(Jupyter)가 504 오류를 반환합니다.

해결책

Google 지원 케이스를 엽니다.

노트북을 열면 524(시간 초과 발생) 오류 발생

문제

내부 역방향 프록시 서버가 역방향 제한 시간 내에 프록시 에이전트로부터 요청에 대한 응답을 받지 못했습니다. Inverting Proxy 에이전트는 사용자 관리 노트북 인스턴스 내에서 Docker 컨테이너로 실행됩니다. 524 오류는 대개 역방향 프록시 에이전트가 역방향 프록시 서버에 연결되지 않거나 백엔드 서버 측(Jupyter)에서 시간이 너무 오래 걸리는 경우에 발생합니다. 이 오류의 일반적인 사례는 사용자 측입니다(예: 네트워킹 문제 또는 역방향 프록시 에이전트 서비스가 실행되고 있지 않음).

해결책

노트북에 액세스할 수 없는 경우 사용자 관리 노트북 인스턴스가 시작되었는지 확인하고 다음을 시도합니다.

옵션 1: 진단 도구를 실행하여 사용자 관리 노트북 핵심 서비스를 자동으로 확인 및 복구하고, 사용 가능한 스토리지를 확인하고, 유용한 로그 파일을 생성합니다. 인스턴스에서 도구를 실행하려면 다음 단계를 수행합니다.

인스턴스가 M58 버전 이상인지 확인합니다.
SSH를 통해 Deep Learning VM Image 인스턴스에 연결합니다.
다음 명령어를 실행합니다.
```
sudo /opt/deeplearning/bin/diagnostic_tool.sh [--repair] [--bucket=$BUCKET]
```
--repair 플래그와 --bucket 플래그는 선택사항입니다. --repair 플래그는 일반적인 핵심 서비스 오류를 수정하려고 시도하고 --bucket 플래그를 사용하면 생성된 로그 파일을 저장할 Cloud Storage 버킷을 지정할 수 있습니다.

이 명령어 결과는 사용자 관리 노트북 핵심 서비스의 유용한 상태 메시지를 표시하고 발견 항목의 로그 파일을 내보냅니다.

옵션 2: 다음 단계를 따라 특정 사용자 관리 노트북 요구사항을 개별적으로 확인합니다.

사용자 관리 노트북 인스턴스 디스크의 공간이 충분한지 확인합니다.
1. SSH를 통해 Deep Learning VM Image 인스턴스에 연결합니다.
2. 다음 명령어를 실행합니다.
```
df -h -T /home/jupyter
```
  Use%가 85%보다 크면 /home/jupyter에서 파일을 수동으로 삭제해야 합니다. 첫 번째 단계로 다음 명령어를 사용하여 휴지통을 비울 수 있습니다.
```
sudo rm -rf  /home/jupyter/.local/share/Trash/*
```
Docker 서비스가 시작되었는지 확인합니다.
역방향 프록시 에이전트가 실행 중인지 확인합니다. 에이전트가 시작된 경우 다시 시작해 봅니다.
Jupyter 서비스가 실행 중인지 확인합니다. 실행 중인 경우 다시 시작해 봅니다.
사용자 관리 노트북 인스턴스에서 메모리 사용률을 확인합니다.
1. SSH를 통해 Deep Learning VM 인스턴스에 연결합니다.
2. 다음 명령어를 실행합니다.
```
free -t -h
```
  사용된 메모리가 총 메모리의 85%보다 큰 경우 머신 유형을 변경하는 것이 좋습니다.
3. Cloud Monitoring 에이전트를 설치하여 사용자 관리 노트북 인스턴스에서 메모리 사용량이 높은지 모니터링할 수 있습니다. 가격 책정 정보를 참조하세요.
Deep Learning VM 버전 M55 이상을 사용하고 있는지 확인합니다. 업그레이드에 대한 자세한 내용은 사용자 관리 노트북 인스턴스의 환경 업그레이드를 참조하세요.

노트북을 열면 598(네트워크 읽기 시간 초과) 오류 발생

문제

역방향 프록시 서버가 역방향 프록시 에이전트로부터 10분 넘게 아무런 응답을 받지 않은 경우, 이는 거의 역방향 프록시와 관련된 문제가 있다는 의미입니다.

해결책

노트북에 액세스할 수 없는 경우 다음 안내를 따르세요.

사용자 관리 노트북 인스턴스가 시작되었는지 확인합니다.
Docker 서비스가 시작되었는지 확인합니다.
역방향 프록시 에이전트가 실행 중인지 확인합니다. 에이전트가 시작된 경우 다시 시작해 봅니다.
Jupyter 서비스가 실행 중인지 확인합니다. 실행 중인 경우 다시 시작해 봅니다.
Deep Learning VM 버전 M55 이상을 사용하고 있는지 확인합니다. 업그레이드에 대한 자세한 내용은 사용자 관리 노트북 인스턴스의 환경 업그레이드를 참조하세요.

노트북이 응답하지 않음

문제

사용자 관리 노트북 인스턴스가 셀을 실행 중이 아니거나 고정된 것으로 보입니다.

해결책

JupyterLab 브라우저 페이지를 새로고침합니다. 저장되지 않은 셀 출력은 지속되지 않으므로 이러한 셀을 다시 실행하여 출력을 다시 생성해야 합니다.
노트북의 터미널 세션에서 top 명령어를 실행하여 CPU를 사용하는 프로세스가 있는지 확인합니다.
터미널에서 df 명령어를 사용하여 여유 디스크 공간을 확인하거나 free 명령어를 사용하여 사용 가능한 RAM을 확인합니다.
사용자 관리 노트북 페이지에서 인스턴스를 선택하고 중지를 클릭하여 인스턴스를 종료합니다. 완전히 중지된 후에 인스턴스를 선택하고 시작을 클릭합니다.

Vertex AI Workbench 인스턴스로 마이그레이션

이 섹션에서는 사용자 관리 노트북 인스턴스에서 Vertex AI Workbench 인스턴스로 마이그레이션과 관련된 문제를 진단하고 해결하기 위한 방법들에 대해 설명합니다.

사용자 관리 노트북 인스턴스에 있던 R, Beam, 기타 커널을 찾을 수 없음

문제

사용자 관리 노트북 인스턴스에 있던 커널이 사용자가 마이그레이션한 Vertex AI Workbench 인스턴스에 표시되지 않습니다.

R 및 Beam 커널과 같은 일부 커널은 기본적으로 Vertex AI Workbench 인스턴스에서 사용할 수 없습니다. 이러한 커널은 마이그레이션이 지원되지 않습니다.

해결책

이 문제를 해결하려면 Vertex AI Workbench 인스턴스에 conda 환경을 추가합니다.

Vertex AI Workbench 인스턴스에서 Dataproc Hub 인스턴스를 설정할 수 없음

문제

Dataproc Hub는 Vertex AI Workbench 인스턴스에서 지원되지 않습니다.

해결책

사용자 관리 노트북 인스턴스에서 Dataproc Hub를 계속 사용합니다.

마이그레이션된 인스턴스의 프레임워크 버전이 서로 다름

문제

사용자 관리 노트북 인스턴스에 있던 프레임워크가 사용자가 마이그레이션한 Vertex AI Workbench 인스턴스에 있는 것과 버전이 다릅니다.

Vertex AI Workbench 인스턴스는 기본 프레임워크 버전 집합을 제공합니다. 마이그레이션 도구는 원래 사용자 관리 노트북 인스턴스에서 프레임워크 버전을 추가하지 않습니다. 기본 마이그레이션 도구 동작을 참조하세요.

해결책

특정 버전의 프레임워크를 추가하려면 Vertex AI Workbench 인스턴스에 conda 환경을 추가합니다.

GPU가 새 Vertex AI Workbench 인스턴스에 마이그레이션되지 않음

문제

사용자 관리 노트북 인스턴스에 있던 GPU가 사용자가 마이그레이션한 Vertex AI Workbench 인스턴스에 없습니다.

Vertex AI Workbench 인스턴스는 기본 GPU 집합을 지원합니다. 원래 사용자 관리 노트북 인스턴스의 GPU를 사용할 수 없으면 GPU 없이 인스턴스가 마이그레이션됩니다.

해결책

마이그레이션된 인스턴스의 머신 유형이 서로 다름

문제

사용자 관리 노트북 인스턴스의 머신 유형이 사용자가 마이그레이션한 Vertex AI Workbench 인스턴스와 다릅니다.

Vertex AI Workbench 인스턴스는 모든 머신 유형을 지원하지 않습니다. 원래 사용자 관리 노트북 인스턴스의 머신 유형을 사용할 수 없으면 인스턴스가 e2-standard-4 머신 유형으로 마이그레이션됩니다.

해결책

파일 작업

이 섹션에서는 사용자 관리 노트북 인스턴스의 파일과 관련된 문제 해결에 대해 설명합니다.

파일 다운로드가 중지되었지만 여전히 사용자가 파일을 다운로드할 수 있음

문제

Dataproc 허브 사용자 관리 노트북 인스턴스의 경우 JupyterLab 사용자 인터페이스에서 파일 다운로드를 중지할 수 없습니다. Dataproc Hub 프레임워크를 사용하는 사용자 관리 노트북 인스턴스는 인스턴스를 만들 때 JupyterLab UI에서 파일 다운로드 사용 설정을 선택하지 않은 경우에도 파일 다운로드를 허용합니다.

해결책

Dataproc Hub 사용자 관리 노트북 인스턴스는 파일 다운로드 제한을 지원하지 않습니다.

다운로드한 파일이 잘리거나 다운로드가 완료되지 않음

문제

사용자 관리 노트북 인스턴스에서 파일을 다운로드할 때 프록시 전달 에이전트의 제한 시간 설정은 다운로드 완료 시간을 제한합니다. 다운로드하는 데 시간이 너무 오래 걸리면 다운로드한 파일이 잘리거나 다운로드되지 않을 수 있습니다.

해결책

이 파일을 다운로드하려면 Cloud Storage에 파일을 복사한 후 Cloud Storage에서 해당 파일을 다운로드합니다.

새로운 사용자 관리 노트북 인스턴스로 파일 및 데이터를 마이그레이션하는 방법을 고려하세요.

VM을 다시 시작한 후에 노트북 터미널에서 로컬 파일을 참조할 수 없음

문제

사용자 관리 노트북 인스턴스를 다시 시작한 후 노트북 터미널 내에서 로컬 파일을 참조할 수 없는 경우가 있습니다.

해결책

이는 알려진 문제입니다. 노트북 터미널 내에서 로컬 파일을 참조하려면 먼저 다음 명령어를 사용하여 현재 작업 디렉터리를 다시 설정합니다.

cd PWD

이 명령어에서 PWD을 현재 작업 디렉터리로 바꿉니다. 예를 들어 현재 작업 디렉터리가 /home/jupyter/이면 cd /home/jupyter/ 명령어를 사용합니다.

Notebooks 인스턴스에 사용되는 서비스 계정이 다음 중 어느 것인지 확인합니다.

사용자 관리 노트북 인스턴스 만들기

이 섹션에서는 사용자 관리 노트북 인스턴스 만들기와 관련된 문제 해결에 대해 설명합니다.

GPU 할당량이 초과됨

문제

GPU를 사용하여 사용자 관리 노트북 인스턴스를 만들 수 없습니다.

해결책

인스턴스가 대기 중 상태로 무기한 유지됨

문제

사용자 관리 노트북 인스턴스를 만든 후에는 대기 상태로 무기한 유지됩니다. 다음과 같은 오류가 직렬 로그에 표시될 수 있습니다.

Could not resolve host: notebooks.googleapis.com

해결책

Cloud DNS 구성 또는 기타 네트워크 문제로 인해 인스턴스가 Notebooks API 서버에 연결할 수 없습니다. 이 문제를 해결하려면 Cloud DNS 및 네트워크 구성을 확인하세요. 자세한 내용은 네트워크 구성 옵션 섹션을 참고하세요.

새 사용자 관리 노트북 인스턴스가 생성되지 않음(권한 없음)

문제

사용자 관리 노트북 인스턴스를 만드는 데는 일반적으로 약 1분이 소요됩니다. 새 사용자 관리 노트북 인스턴스가 무기한으로 pending 상태에 있다면, 이는 사용자 관리 노트북 인스턴스를 시작하는 데 사용되는 서비스 계정에 Google Cloud 프로젝트에 필요한 권한이 없기 때문일 수 있습니다.

만든 커스텀 서비스 계정을 사용하거나 단일 사용자 모드에서 사용자 ID를 제공하여 사용자 관리 노트북 인스턴스를 시작할 수 있습니다. 단일 사용자 모드에서 사용자 관리 노트북 인스턴스를 시작하면 사용자 관리 노트북 인스턴스가 Compute Engine 기본 서비스 계정을 사용하여 부팅 프로세스를 시작한 후 제어 권한을 사용자 ID에 넘깁니다.

해결책

서비스 계정에 적절한 권한이 있는지 확인하려면 다음 단계를 따르세요.

콘솔

Google Cloud 콘솔에서 IAM 페이지를 엽니다.
IAM 페이지 열기
사용자 관리 노트북 인스턴스에 사용되는 서비스 계정이 다음 중 어느 것인지 확인합니다.
- 사용자 관리 노트북 인스턴스를 만들 때 지정한 커스텀 서비스 계정
- 단일 사용자 모드에서 사용자 관리 노트북 인스턴스를 시작할 때 사용한Google Cloud 프로젝트의 Compute Engine 기본 서비스 계정입니다. 프로젝트의 Compute Engine 기본 서비스 계정 이름은 Google Cloud PROJECT_NUMBER-compute@developer.gserviceaccount.com입니다. 예를 들면 113377992299-compute@developer.gserviceaccount.com입니다.
서비스 계정에 Notebooks Runner (roles/notebooks.runner) 역할이 있는지 확인합니다. 그렇지 않으면 서비스 계정에 Notebooks Runner (roles/notebooks.runner) 역할을 부여합니다.

자세한 내용은 IAM 문서의 리소스에 대한 액세스 권한 부여, 변경, 취소를 참조하세요.

gcloud

아직 설치하지 않았으면 Google Cloud CLI를 설치합니다.
다음 명령어를 사용하여 프로젝트의 이름과 프로젝트 번호를 가져옵니다. Google Cloud PROJECT_ID를Google Cloud 프로젝트의 프로젝트 ID로 바꿉니다.
```
gcloud projects describe PROJECT_ID
```
다음과 비슷한 출력이 표시되며, 여기에는 프로젝트 이름(name:)과 프로젝트 번호(projectNumber:)가 포함됩니다.
```
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'
```
사용자 관리 노트북 인스턴스에 사용되는 서비스 계정이 다음 중 어느 것인지 확인합니다.
- 사용자 관리 노트북 인스턴스를 만들 때 지정한 커스텀 서비스 계정
- 단일 사용자 모드에서 사용자 관리 노트북 인스턴스를 시작할 때 사용한Google Cloud 프로젝트의 Compute Engine 기본 서비스 계정입니다. 프로젝트의 Compute Engine 기본 서비스 계정 이름은 Google Cloud PROJECT_NUMBER-compute@developer.gserviceaccount.com입니다. 예를 들면 113377992299-compute@developer.gserviceaccount.com입니다.
다음 명령어를 실행하여 roles/notebooks.runner 역할을 서비스 계정에 추가합니다. project-name을 프로젝트 이름으로 바꾸고 service-account-id을 사용자 관리 노트북 인스턴스의 서비스 계정 ID로 바꿉니다.
```
gcloud projects add-iam-policy-binding project-name \
 --member serviceAccount:service-account-id \
 --role roles/notebooks.runner
```

인스턴스를 만들면 `Permission denied` 오류 발생

문제

인스턴스의 서비스 계정은 다른 서비스에 대한 액세스를 제공합니다. Google Cloud 동일한 프로젝트 내의 모든 서비스 계정을 사용할 수 있지만 인스턴스를 만들려면 서비스 계정 사용자 권한 (iam.serviceAccounts.actAs)이 있어야 합니다. 지정하지 않으면 Compute Engine 기본 서비스 계정이 사용됩니다.

해결책

인스턴스를 만들 때 인스턴스를 만드는 사용자에게 정의된 서비스 계정에 대한 iam.serviceAccounts.ActAs 권한이 있는지 확인합니다.

다음 예시에서는 인스턴스를 만들 때 서비스 계정을 지정하는 방법을 보여줍니다.

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

서비스 계정 사용자 역할을 부여하려면 서비스 계정에 대한 액세스 관리를 참조하세요.

인스턴스를 만들면 `already exists` 오류 발생

문제

인스턴스를 만들 때 이름이 같은 사용자 관리 노트북 인스턴스가 이전에 Compute Engine에서 삭제되지 않고 Notebooks API 데이터베이스에 여전히 남아 있는지 확인합니다.

해결책

다음 예시에서는 Notebooks API를 사용하여 인스턴스를 나열하고 상태를 확인하는 방법을 보여줍니다.

gcloud notebooks instances list --location=LOCATION

인스턴스 상태가 DELETED이면 다음 명령어를 실행하여 영구적으로 삭제합니다.

gcloud notebooks instances delete INSTANCE_NAME --location=LOCATION

공유 VPC에서 인스턴스를 만들 수 없음

문제

공유 VPC에서 인스턴스를 만들 수 없습니다.

해결책

공유 VPC를 사용하는 경우 호스트와 서비스 프로젝트를 서비스 경계에 추가해야 합니다. 호스트 프로젝트에서도 컴퓨팅 네트워크 사용자 역할(roles/compute.networkUser)을 서비스 프로젝트의 Notebooks 서비스 에이전트에 부여해야 합니다. 자세한 내용은 서비스 경계 관리를 참조하세요.

인스턴스를 만들면 리소스 가용성 오류가 발생함

문제

리소스 가용성 오류로 인해 인스턴스를 만들 수 없습니다.

이 오류는 다음과 같이 표시될 수 있습니다.

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

GPU 또는 CPU와 같은 Compute Engine 리소스를 현재 사용할 수 없어서 요청을 처리할 수 없는 영역에서 새 리소스를 요청하면 오류가 발생합니다.

해결책

계속하려면 다음을 시도할 수 있습니다.

다른 머신 유형으로 인스턴스를 만듭니다.
다른 영역에 인스턴스를 만듭니다.
나중에 요청을 다시 시도합니다.
요청하는 리소스의 양을 줄입니다. 예를 들어 GPU, 디스크, vCPU 또는 메모리를 줄여서 인스턴스를 만들어 보세요.

인스턴스를 시작하면 리소스 가용성 오류가 발생함

문제

리소스 가용성 오류로 인해 인스턴스를 시작할 수 없습니다.

이 오류는 다음과 같이 표시될 수 있습니다.

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

GPU 또는 CPU 등, Compute Engine 리소스를 현재 사용할 수 없어서 요청을 처리할 수 없는 영역에서 인스턴스를 시작하려고 하면 오류가 발생합니다.

해결책

계속하려면 다음을 시도할 수 있습니다.

인스턴스의 머신 유형을 변경합니다.
파일과 데이터를 다른 영역의 인스턴스로 이전합니다.
나중에 요청을 다시 시도합니다.
요청하는 리소스의 양을 줄입니다. 예를 들어 GPU, 디스크, vCPU 또는 메모리를 줄여 다른 인스턴스를 시작합니다.

사용자 관리 노트북 인스턴스 업그레이드

이 섹션에서는 사용자 관리 노트북 인스턴스 업그레이드와 관련된 문제 해결에 대해 설명합니다.

인스턴스 디스크 정보를 가져올 수 없으므로 업그레이드할 수 없음

문제

단일 디스크 사용자 관리 노트북 인스턴스에는 업그레이드가 지원되지 않습니다.

해결책

새 사용자 관리 노트북 인스턴스로 사용자 데이터를 마이그레이션하는 것이 좋습니다.

인스턴스가 UEFI와 호환되지 않아 업그레이드할 수 없음

문제

Vertex AI Workbench는 UEFI 호환성에 따라 업그레이드를 완료합니다.

이전의 일부 이미지에서 생성된 사용자 관리 노트북 인스턴스는 UEFI와 호환되지 않으므로 업그레이드할 수 없습니다.

해결책

인스턴스가 UEFI와 호환되는지 확인하려면 Cloud Shell이나 Google Cloud CLI가 설치된 환경에서 다음 명령어를 입력하세요.

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

다음을 바꿉니다.

INSTANCE_NAME: 인스턴스의 이름입니다.
ZONE: 인스턴스가 있는 영역

인스턴스를 만드는 데 사용한 이미지가 UEFI와 호환되는지 확인하려면 다음 명령어를 사용하세요.

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

VM_IMAGE_FAMILY를 인스턴스를 만들 때 사용한 이미지 계열 이름으로 바꿉니다.

인스턴스 또는 이미지가 UEFI와 호환되지 않는 것으로 확인되면 사용자 데이터를 새 사용자 관리 노트북 인스턴스로 마이그레이션하려고 시도할 수 있습니다. 그러려면 다음 절차를 완료하세요.

새 인스턴스를 만드는 데 사용할 이미지가 UEFI와 호환되는지 확인하세요. 이렇게 하려면 Cloud Shell에서 또는 Google Cloud CLI가 설치된 환경에서 다음 명령어를 입력합니다.
```
gcloud compute images describe VM_IMAGE_FAMILY \
  --project deeplearning-platform-release --format=json | grep type
```
VM_IMAGE_FAMILY를 인스턴스를 만드는 데 사용할 이미지 계열 이름으로 바꿉니다.
사용자 데이터를 새 사용자 관리 노트북 인스턴스로 마이그레이션합니다.

업그레이드 후 사용자 관리 노트북 인스턴스에 액세스할 수 없음

문제

업그레이드 후 사용자 관리 노트북 인스턴스에 액세스할 수 없는 경우 부팅 디스크의 이미지를 바꾸는 동안 오류가 발생했을 수 있습니다.

업그레이드할 수 있는 사용자 관리 노트북 인스턴스는 부팅 디스크 1개와 데이터 디스크 1개가 있는 이중 디스크입니다. 업그레이드 프로세스는 데이터 디스크에 데이터를 보존하면서 부팅 디스크를 새 이미지로 업그레이드합니다.

해결책

다음 단계를 완료하여 유효한 새 이미지를 부팅 디스크에 연결합니다.

이 절차를 완료하는 데 사용할 값을 저장하려면 Cloud Shell에서 또는 Google Cloud CLI가 설치된 환경에서 다음 명령어를 입력합니다.
```
export INSTANCE_NAME=MY_INSTANCE_NAME
export PROJECT_ID=MY_PROJECT_ID
export ZONE=MY_ZONE
```
다음을 바꿉니다.
- MY_INSTANCE_NAME: 인스턴스의 이름
- MY_PROJECT_ID: 프로젝트 ID
- MY_ZONE: 인스턴스가 있는 영역

다음 명령어를 사용하여 인스턴스를 중지합니다.

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

인스턴스에서 부팅 디스크를 분리합니다.

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

인스턴스의 VM을 삭제합니다.

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

Notebooks API를 사용하여 사용자 관리 노트북 인스턴스를 삭제합니다.

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

이전 인스턴스와 동일한 이름으로 사용자 관리 노트북 인스턴스를 만듭니다.

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

다음을 바꿉니다.

MY_VM_IMAGE_FAMILY: 이미지 계열 이름
MY_INSTANCE_OWNER: 인스턴스 소유자
MY_MACHINE_TYPE: 인스턴스 VM의 머신 유형
MY_SERVICE_ACCOUNT: 이 인스턴스에 사용할 서비스 계정(또는 "default" 사용)
MY_ACCELERATOR_TYPE: 가속기 유형(예: "NVIDIA_TESLA_T4")
MY_ACCELERATOR_CORE_COUNT: 코어 수(예: 1)

사용자 관리 노트북 인스턴스의 상태 모니터링

이 섹션에서는 상태 오류 모니터링과 관련된 문제 해결에 대해 설명합니다.

`docker-proxy-agent` 상태 실패

docker-proxy-agent 상태 실패 후 다음 단계를 수행합니다.

역방향 프록시 에이전트가 실행 중인지 확인합니다. 아닌 경우 3단계로 이동합니다.
역방향 프록시 에이전트를 다시 시작합니다.
역방향 프록시 서버에 다시 등록합니다.

`docker-service` 상태 실패

docker-service 상태 실패 후 다음 단계를 수행합니다.

Docker 서비스가 실행 중인지 확인합니다.
Docker 서비스를 다시 시작합니다.

`jupyter-service` 상태 실패

jupyter-service 상태 실패 후 다음 단계를 수행합니다.

Jupyter 서비스가 실행 중인지 확인합니다.
Jupyter 서비스를 다시 시작합니다.

`jupyter-api` 상태 실패

jupyter-api 상태 실패 후 다음 단계를 수행합니다.

Jupyter 내부 API가 활성 상태인지 확인합니다.
Jupyter 서비스를 다시 시작합니다.

부팅 디스크 사용률

디스크 공간이 85%를 초과하면 부팅 디스크 공간 상태가 비정상이 됩니다.

부팅 디스크 공간 상태가 비정상인 경우 다음을 시도해 보세요.

사용자 관리 노트북 인스턴스의 터미널 세션 또는 ssh를 사용하여 연결에서 df -H 명령어를 사용하여 여유 디스크 공간을 확인합니다.
find . -type d -size +100M 명령어를 사용하면 삭제할 수 있는 대용량 파일을 찾을 수 있지만 확실히 안전하게 삭제할 수 있는 경우가 아니라면 삭제하지 마세요. 잘 모르겠으면 지원을 받을 수 있습니다.
이전 단계를 통해 문제가 해결되지 않으면 지원을 받으세요.

데이터 디스크 사용률

디스크 공간이 85%를 초과하면 데이터 디스크 공간 상태가 비정상이 됩니다.

데이터 디스크 공간 상태가 비정상인 경우 다음을 시도해 보세요.

사용자 관리 노트북 인스턴스의 터미널 세션 또는 ssh를 사용하여 연결에서 df -h -T /home/jupyter 명령어를 사용하여 여유 디스크 공간을 확인합니다.
대용량 파일을 삭제하여 사용 가능한 디스크 공간을 늘립니다. find . -type d -size +100M 명령어를 사용하면 대용량 파일을 찾을 수 있습니다.
이전 단계를 통해 문제가 해결되지 않으면 지원을 받으세요.

서드 파티 JupyterLab 확장 프로그램을 설치할 수 없음

문제

서드 파티 JupyterLab 확장 프로그램을 설치하려고 시도하면 Error: 500 메시지가 표시됩니다.

해결책

서드 파티 JupyterLab 확장 프로그램은 사용자 관리 노트북 인스턴스에서 지원되지 않습니다.

인스턴스 복원

문제

사용자 관리 노트북 인스턴스를 삭제한 후 복원하는 기능은 지원되지 않습니다.

해결책

인스턴스의 데이터를 백업하려면 노트북을 GitHub에 저장하거나 디스크 스냅샷을 만들면 됩니다.

인스턴스에서 데이터 복구

문제

사용자 관리 노트북 인스턴스를 삭제한 후 해당 인스턴스의 데이터를 복구하는 기능은 지원되지 않습니다.

해결책

인스턴스의 데이터를 백업하려면 노트북을 GitHub에 저장하거나 디스크 스냅샷을 만들면 됩니다.

공유 메모리를 늘릴 수 없음

문제

기존 사용자 관리 노트북 인스턴스에서 공유 메모리를 늘릴 수 없습니다.

해결책

그러나 container-custom-params 메타데이터 키를 사용하여 다음과 같이 값으로 사용자 관리 노트북 인스턴스를 만들 때 공유 메모리 크기를 지정할 수 있습니다.

--shm-size=SHARED_MEMORY_SIZE gb

SHARED_MEMORY_SIZE를 원하는 크기(GB)로 바꿉니다.

유용한 절차

이 섹션에서는 유용한 절차에 대해 설명합니다.

SSH를 사용하여 사용자 관리 노트북 인스턴스에 연결

Cloud Shell에서 또는 Google Cloud CLI가 설치된 환경에서 다음 명령어를 입력하여 ssh를 통해 인스턴스에 연결합니다.

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

다음을 바꿉니다.

PROJECT_ID: 프로젝트 ID
ZONE: 인스턴스가 있는 Google Cloud 영역
INSTANCE_NAME: 인스턴스의 이름

인스턴스의 Compute Engine 세부정보 페이지를 연 다음 SSH 버튼을 클릭하여 인스턴스에 연결할 수도 있습니다.

할 수 있습니다.

역방향 프록시 서버에 다시 등록

사용자 관리 노트북 인스턴스를 내부 역방향 프록시 서버에 다시 등록하려면 사용자 관리 노트북 페이지에서 VM을 중지하고 시작하거나 ssh를 사용자 관리 노트북 인스턴스에 연결하고 다음을 입력합니다.

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

Docker 서비스 상태 확인

Docker 서비스 상태를 확인하려면 ssh를 사용하여 사용자 관리 노트북 인스턴스에 연결하고 다음을 입력합니다.

sudo service docker status

역방향 프록시 에이전트가 실행 중인지 확인

노트북 역방향 에이전트가 실행 중인지 확인하려면 ssh를 사용하여 사용자 관리 노트북 인스턴스에 연결하고 다음을 입력합니다.

# 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 서비스 상태 확인 및 로그 수집

Jupyter 서비스 상태를 확인하려면 ssh를 사용하여 사용자 관리 노트북 인스턴스에 연결하고 다음을 입력합니다.

sudo service jupyter status

Jupyter 서비스 로그를 수집하려면 다음을 실행합니다.

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

Jupyter 내부 API가 활성 상태인지 확인

Jupyter API는 항상 포트 8080에서 실행되어야 합니다. 인스턴스의 syslog에서 다음과 유사한 항목이 있는지 확인하여 이를 확인할 수 있습니다.

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

Jupyter 내부 API가 활성 상태인지 확인하려면 ssh를 사용하여 사용자 관리 노트북 인스턴스에 연결하고 다음을 입력해도 됩니다.

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

요청이 너무 오래 걸리는 경우 API가 응답하는 데 걸리는 시간을 측정할 수도 있습니다.

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

Vertex AI Workbench 인스턴스에서 이러한 명령어를 실행하려면 JupyterLab을 열고 새 터미널을 만듭니다.

Docker 서비스 다시 시작

Docker 서비스를 다시 시작하려면 사용자 관리 노트북 페이지에서 VM을 중지하고 시작하거나 ssh를 사용하여 사용자 관리 노트북 인스턴스에 연결하고 다음을 입력합니다.

sudo service docker restart

역방향 프록시 에이전트 다시 시작

역방향 프록시 에이전트를 다시 시작하려면 사용자 관리 노트북 페이지에서 VM을 중지하고 시작하거나 ssh를 사용하여 사용자 관리 노트북 인스턴스에 연결하고 다음을 입력합니다.

sudo docker restart proxy-agent

Jupyter 서비스 다시 시작

Jupyter 서비스를 다시 시작하려면 사용자 관리 노트북 페이지에서 VM을 중지하고 시작하거나 ssh를 사용하여 사용자 관리 노트북 인스턴스에 연결하고 다음을 입력합니다.

sudo service jupyter restart

Notebooks 수집 에이전트 다시 시작

Notebooks 수집 에이전트 서비스는 백그라운드에서 Vertex AI Workbench 인스턴스의 핵심 서비스의 상태를 확인하는 Python 프로세스를 실행합니다.

Notebooks Collection Agent 서비스를 다시 시작하려면 Google Cloud 콘솔에서 VM을 중지하고 시작하거나 ssh를 사용하여 Vertex AI Workbench 인스턴스에 연결하고 다음을 입력합니다.

sudo systemctl stop notebooks-collection-agent.service

다음과 같이 표시됩니다.

sudo systemctl start notebooks-collection-agent.service

Vertex AI Workbench 인스턴스에서 이러한 명령어를 실행하려면 JupyterLab을 열고 새 터미널을 만듭니다.

노트북 수집 에이전트 스크립트 수정

스크립트에 액세스하고 수정하려면 인스턴스에서 터미널을 열거나 ssh를 사용하여 Vertex AI Workbench 인스턴스에 연결하고 다음을 입력합니다.

nano /opt/deeplearning/bin/notebooks_collection_agent.py

파일을 수정한 후에는 저장해야 합니다.

그런 다음 Notebooks 수집 에이전트 서비스를 다시 시작해야 합니다.

인스턴스가 필요한 DNS 도메인을 확인할 수 있는지 확인

인스턴스가 필요한 DNS 도메인을 확인할 수 있는지 확인하려면 ssh를 사용하여 사용자 관리 노트북 인스턴스에 연결하고 다음을 입력합니다.

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

또는

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

인스턴스에 Dataproc이 사용 설정된 경우 다음을 실행하여 인스턴스가 *.kernels.googleusercontent.com를 확인하는지 확인할 수 있습니다.

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

Vertex AI Workbench 인스턴스에서 이러한 명령어를 실행하려면 JupyterLab을 열고 새 터미널을 만듭니다.

인스턴스의 사용자 데이터 사본 만들기

인스턴스의 사용자 데이터 사본을 Cloud Storage에 저장하려면 다음 단계를 완료합니다.

Cloud Storage 버킷 만들기(선택사항)

인스턴스가 있는 동일한 프로젝트에서 사용자 데이터를 저장할 수 있는 Cloud Storage 버킷을 만듭니다. Cloud Storage 버킷이 이미 있으면 이 단계를 건너뜁니다.

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.

사용자 데이터 복사

인스턴스의 JupyterLab 인터페이스에서 파일 > 새로 만들기 > 터미널을 선택하여 터미널 창을 엽니다. 사용자 관리 노트북 인스턴스의 경우 대신 SSH를 사용하여 인스턴스 터미널에 연결할 수 있습니다.
gcloud CLI를 사용하여 사용자 데이터를 Cloud Storage 버킷에 복사합니다. 다음 예시 명령어는 인스턴스의 /home/jupyter/ 디렉터리에 있는 모든 파일을 Cloud Storage 버킷의 디렉터리에 복사합니다.
```
gcloud storage cp /home/jupyter/* gs://BUCKET_NAMEPATH --recursive
```
다음을 바꿉니다.
- BUCKET_NAME: Cloud Storage 버킷 이름
- PATH: 파일을 복사할 디렉터리의 경로(예: /copy/jupyter/)

gcpdiag를 사용하여 프로비저닝 중 중단된 인스턴스 조사

gcpdiag는 오픈소스 도구입니다. 공식적으로 지원되는 Google Cloud 제품이 아닙니다. gcpdiag 도구를 사용하여 Google Cloud프로젝트 문제를 식별하고 해결할 수 있습니다. 자세한 내용은 GitHub의 gcpdiag 프로젝트를 참고하세요.

이 gcpdiag 런북에서는 Vertex AI Workbench 인스턴스가 프로비저닝 상태에서 중단되는 잠재적 원인을 조사합니다. 여기에는 다음 영역이 포함됩니다.

상태: 인스턴스의 현재 상태를 확인하여 프로비저닝 중 중지되거나 활성 상태가 아닌지 확인합니다.
인스턴스의 Compute Engine VM 부팅 디스크 이미지: 인스턴스가 커스텀 컨테이너, 공식 workbench-instances 이미지, Deep Learning VM 이미지 또는 인스턴스가 프로비저닝 상태에서 중단될 수 있는 지원되지 않는 이미지로 만들어졌는지 확인합니다.
커스텀 스크립트: 인스턴스에서 기본 Jupyter 포트를 변경하거나 인스턴스가 프로비저닝 상태에서 중단될 수 있는 종속 항목을 중단하는 커스텀 시작 또는 시작 후 스크립트를 사용하고 있는지 확인합니다.
환경 버전: 업그레이드 가능성을 확인하여 인스턴스가 최신 환경 버전을 사용하고 있는지 확인합니다. 이전 버전에서는 인스턴스가 프로비저닝 상태에서 중단될 수 있습니다.
인스턴스의 Compute Engine VM 성능: VM의 현재 성능을 확인하여 높은 CPU 사용량, 메모리 부족 또는 디스크 공간 문제로 인해 정상적인 작업이 중단되지 않았는지 확인합니다.
인스턴스의 Compute Engine 직렬 포트 또는 시스템 로깅: 인스턴스에 직렬 포트 로그가 있는지 확인합니다. 이 로그는 Jupyter가 포트 127.0.0.1:8080에서 실행 중인지 확인하기 위해 분석됩니다.
인스턴스의 Compute Engine SSH 및 터미널 액세스: 사용자가 SSH를 실행하고 터미널을 열어 'home/jupyter'의 공간 사용량이 85% 미만인지 확인할 수 있도록 인스턴스의 Compute Engine VM이 실행 중인지 확인합니다. 여유 공간이 없으면 인스턴스가 프로비저닝 상태에서 중단될 수 있습니다.
외부 IP 사용 중지됨: 외부 IP 액세스가 사용 중지되었는지 확인합니다. 잘못된 네트워킹 구성으로 인해 인스턴스가 프로비저닝 상태에서 중단될 수 있습니다.

Google Cloud 콘솔

다음 명령어를 작성하고 복사합니다.

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

Google Cloud 콘솔을 열고 Cloud Shell을 활성화합니다.

Cloud 콘솔 열기

복사한 명령어를 붙여넣습니다.
gcpdiag 명령어를 실행하면 gcpdiag Docker 이미지를 다운로드한 후 진단 검사를 수행합니다. 해당하는 경우 출력 안내에 따라 실패한 검사를 수정합니다.

Docker

Docker 컨테이너에서 gcpdiag를 시작하는 래퍼를 사용하여 gcpdiag를 실행할 수 있습니다. Docker 또는 Podman이 설치되어 있어야 합니다.

로컬 워크스테이션에서 다음 명령어를 복사하고 실행합니다.
```
curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
```

gcpdiag 명령어를 실행합니다.

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

이 런북에 사용 가능한 매개변수를 봅니다.

다음을 바꿉니다.

PROJECT_ID: 리소스가 포함된 프로젝트의 ID입니다.
INSTANCE_NAME: 프로젝트 내 타겟 Vertex AI Workbench 인스턴스의 이름입니다.
ZONE: 대상 Vertex AI Workbench 인스턴스가 있는 영역입니다.

유용한 플래그:

--universe-domain: 해당되는 경우 리소스를 호스팅하는 신뢰할 수 있는 파트너 주권 클라우드 도메인
--parameter 또는 -p: 런북 파라미터

모든 gcpdiag 도구 플래그의 목록과 설명은 gcpdiag 사용 안내를 참조하세요.

Vertex AI Workbench 문제 해결

Vertex AI Workbench 인스턴스

JupyterLab에 연결 및 열기

JupyterLab 열기를 클릭해도 아무 반응이 없음

Vertex AI Workbench 인스턴스에서 터미널에 액세스할 수 없음

JupyterLab을 열 때 502 오류 발생

노트북이 응답하지 않음

SSH를 사용하여 Vertex AI Workbench 인스턴스에 연결할 수 없음

GPU 할당량이 초과됨

Vertex AI Workbench 인스턴스 만들기

인스턴스가 무기한 대기 중 상태로 유지되거나 프로비저닝 상태에서 멈춤

공유 VPC 네트워크 내에서 인스턴스를 만들 수 없음

필수 권한

커스텀 컨테이너로 Vertex AI Workbench 인스턴스를 만들 수 없음

공유 스토리지 마운트 버튼이 없음

Dataproc을 사용할 때 599 오류 발생

서드 파티 JupyterLab 확장 프로그램을 설치할 수 없음

기본 가상 머신을 수정할 수 없음

conda 환경을 추가한 후 pip 패키지를 사용할 수 없음

단일 사용자 액세스로 인스턴스의 데이터에 액세스하거나 복사할 수 없음

예기치 않은 종료

인스턴스 로그에 연결 또는 시간 초과 오류가 표시됨

인스턴스 로그에 'Jupyter API에 연결할 수 없음' 'ReadTimeoutError'가 표시됨

docker0 주소가 VPC 주소 지정과 충돌함

지정된 예약이 없음

관리형 노트북

JupyterLab에 연결 및 열기

JupyterLab 열기를 클릭해도 아무 반응이 없음

SSH를 사용해서 관리형 노트북 인스턴스에 연결할 수 없음

관리형 노트북 인스턴스의 터미널에 액세스할 수 없음

JupyterLab을 열 때 502 오류 발생

노트북을 열면 524(시간 초과 발생) 오류 발생

노트북이 응답하지 않음

Vertex AI Workbench 인스턴스로 마이그레이션

관리형 노트북 인스턴스에 있던 커널을 찾을 수 없음

마이그레이션된 인스턴스의 프레임워크 버전이 서로 다름

GPU가 새 Vertex AI Workbench 인스턴스에 마이그레이션되지 않음

마이그레이션된 인스턴스의 머신 유형이 서로 다름

GPU 할당량이 초과됨

컨테이너 이미지 사용

JupyterLab에서 컨테이너 이미지가 커널로 표시되지 않음

장기 실행 작업 중 노트북 연결이 해제됨

실행자 사용

실행자가 패키지 설치를 사용할 수 없음

실행자를 사용하여 노트북 코드를 실행할 때 401 또는 403 오류

실행자를 사용할 때의 exited with a non-zero status of 127 오류

잘못된 서비스 네트워킹 구성 오류 메시지

서드 파티 JupyterLab 확장 프로그램을 설치할 수 없음

단일 사용자 액세스로 인스턴스의 데이터에 액세스하거나 복사할 수 없음

예기치 않은 종료

인스턴스 복원

인스턴스에서 데이터 복구

관리형 노트북 인스턴스 만들기

오류: 연결을 만드는 중 문제 발생

인스턴스를 만들면 리소스 가용성 오류가 발생함

인스턴스를 시작하면 리소스 가용성 오류가 발생함

관리형 노트북의 아웃바운드 연결에 대한 No route to host

사용자 관리 노트북

JupyterLab에 연결 및 열기

JupyterLab 열기를 클릭해도 아무 반응이 없음

JupyterLab에 대한 역방향 프록시 서버 액세스 없음

SSH를 사용해서 사용자 관리 노트북 인스턴스에 연결할 수 없음

사용자 관리 노트북 인스턴스를 열면 403(금지됨) 오류 발생

JupyterLab 액세스 없음, 단일 사용자 모드 사용 설정됨

노트북을 열면 504(게이트웨이 시간 초과) 오류 발생

노트북을 열면 524(시간 초과 발생) 오류 발생

노트북을 열면 598(네트워크 읽기 시간 초과) 오류 발생

노트북이 응답하지 않음

Vertex AI Workbench 인스턴스로 마이그레이션

사용자 관리 노트북 인스턴스에 있던 R, Beam, 기타 커널을 찾을 수 없음

Vertex AI Workbench 인스턴스에서 Dataproc Hub 인스턴스를 설정할 수 없음

마이그레이션된 인스턴스의 프레임워크 버전이 서로 다름

GPU가 새 Vertex AI Workbench 인스턴스에 마이그레이션되지 않음

마이그레이션된 인스턴스의 머신 유형이 서로 다름

파일 작업

파일 다운로드가 중지되었지만 여전히 사용자가 파일을 다운로드할 수 있음

다운로드한 파일이 잘리거나 다운로드가 완료되지 않음

VM을 다시 시작한 후에 노트북 터미널에서 로컬 파일을 참조할 수 없음

사용자 관리 노트북 인스턴스 만들기

GPU 할당량이 초과됨

conda 환경을 추가한 후 `pip` 패키지를 사용할 수 없음

`docker0` 주소가 VPC 주소 지정과 충돌함

실행자를 사용할 때의 `exited with a non-zero status of 127` 오류

관리형 노트북의 아웃바운드 연결에 대한 `No route to host`

인스턴스를 만들면 `Permission denied` 오류 발생

인스턴스를 만들면 `already exists` 오류 발생

`docker-proxy-agent` 상태 실패

`docker-service` 상태 실패

`jupyter-service` 상태 실패

`jupyter-api` 상태 실패