Risolvi i problemi relativi a Pathways on Cloud

Prima di iniziare

Questo documento spiega come risolvere i problemi relativi ai workload Pathways.

Visualizzazione dei log

Puoi visualizzare i log dei workload Pathways direttamente utilizzando il comando gcluster job logs (passa --main-only=false per includere i log dei pod worker):

gcluster job logs WORKLOAD_NAME \
    --cluster=CLUSTER \
    --project=PROJECT_ID \
    --location=LOCATION \
    --main-only=false

Per elencare tutti i pod del tuo workload utilizzando kubectl, utilizza l'etichetta del workload di Cluster Toolkit:

kubectl get pods -l gcluster.google.com/workload=WORKLOAD_NAME

Per controllare lo stato del workload o elencare i job non riusciti, utilizza il comando gcluster job list:

gcluster job list --status Failed \
    --cluster=CLUSTER \
    --project=PROJECT_ID \
    --location=LOCATION

In alternativa, in Esplora log di Cloud Logging, utilizza la seguente query modificata in modo che corrisponda al progetto, alla regione, al cluster e al workload:

resource.type="k8s_container"
resource.labels.project_id="PROJECT"
resource.labels.location="LOCATION"
resource.labels.cluster_name="CLUSTER"
resource.labels.namespace_name="default"
resource.labels.pod_name:"WORKLOAD_NAME"

Sostituisci quanto segue:

  • PROJECT : il tuo ID progetto Google Cloud
  • LOCATION: la regione o la zona in cui hai creato il cluster GKE
  • CLUSTER : il nome del tuo cluster GKE
  • WORKLOAD_NAME: il nome del workload quando utilizzi Cluster Toolkit o il nome del JobSet quando utilizzi kubectl

Questa query corrisponderà a più container Kubernetes Pathways con nomi come pathways-rm, pathways-proxy, pathways-worker. Puoi restringere il campo per individuare il container che causa un problema aggiungendo un filtro sul nome del container, ad esempio resource.labels.container_name:"<container_name>"

Monitoraggio

Monitoraggio dello stato di integrità

Puoi monitorare l'integrità dei vari componenti di Pathways cercando le voci nei log dei container, ad esempio:

pathways-proxy è pronto per gestire nuove richieste di connessione quando viene scritto il seguente log:

kubectl logs ${HEAD_POD_NAME} --container pathways-proxy
...
I1101 04:51:41.967764       1 proxy_server.cc:125] IFRT proxy server started with status OK

pathways-rm è pronto per gestire nuove richieste di connessione quando viene scritto il seguente log:

kubectl logs $HEAD_POD_NAME --container pathways-rm
...
I1101 04:50:41.967764       1 server_lib.cc:1473] Pathways Server serving on [::]:29001

Per verificare che tutte le TPU registrate in Pathways Resource Manager siano pronte, puoi cercare ***<num slices>/<num slices> Pathways Slices Now Ready *** nei log del container pathways-rm:

kubectl logs $HEAD_POD_NAME --container pathways-rm
...
I1101 04:52:41.967764       1 multi_job_allocator.cc:1063] *** 2/2 Pathways Slices Now Ready ***

Il client Pathways può stabilire connessioni al server proxy IFRT, a condizione che il server proxy sia pronto, anche se non tutti gli slice lo sono. Il job funziona con le sezioni virtuali finché la sezione non diventa pronta. Le sezioni virtuali consentono l'esecuzione del codice quando le TPU non sono disponibili.

pathways-worker è pronto per gestire nuove richieste di connessione quando viene scritto il seguente log:

kubectl logs $WORKER_POD_NAME --container pathways-worker
...
I1101 04:50:41.967764       1 server_lib.cc:1473] Pathways Server serving on [::]:29001

Raccolta di metriche

Pathways può scrivere metriche di sistema di basso livello in Cloud Monitoring per il debug. Le metriche includono:

  • Latenza di trasferimento DCN
  • Latenza collettiva
  • Latenza di trasferimento da host a dispositivo
  • Latenza di trasferimento da dispositivo a host

Puoi trovare le metriche nella dashboard di Cloud Monitoring del progettoGoogle Cloud in cui è in esecuzione il cluster GKE.

Per monitorare queste metriche in Metrics Explorer:

  1. Vai a Esplora metriche.
  2. Filtra in base al nome della metrica utilizzando il campo Seleziona una metrica.
  3. Filtra in base al nome del workload e all'intervallo di tempo selezionando Aggiungi filtro e filtra in base a pod_name.
  4. Scegli un tipo di aggregazione appropriato in base alla metrica e ai workload che stai monitorando.

Latenza di trasferimento DCN

Questa è una metrica Megascale XLA (MXLA) che misura la distribuzione cumulativa delle latenze di trasferimento di rete per il traffico multislice. La misurazione della latenza inizia quando viene inviata una richiesta di trasferimento dei dati tramite la DCN e termina quando viene ricevuta una conferma del completamento del trasferimento dei dati. Per monitorare questa metrica, filtra in base al nome della metrica dcn_transfer_latencies.

Latenza collettiva

Si tratta di una metrica MXLA che misura la distribuzione cumulativa della latenza collettiva end-to-end per il traffico multislice. La misurazione della latenza inizia quando viene emessa una richiesta per un collettivo e termina quando viene ricevuta una conferma del completamento del trasferimento di dati. Per monitorare questa metrica, filtra in base al nome della metrica collective_e2e_latency.

Latenza di trasferimento da host a dispositivo

Questa è una metrica MXLA che misura la distribuzione cumulativa delle latenze di trasferimento da host a dispositivo per il traffico multislice. La misurazione della latenza inizia quando viene emessa una richiesta di trasferimento dei dati tramite la DCN e termina quando viene ricevuta una conferma del completamento del trasferimento dei dati. Per monitorare questa metrica, filtra in base al nome della metrica host_to_device_transfer_latencies.

Latenza di trasferimento da dispositivo a host

Si tratta di una metrica MXLA che misura la distribuzione cumulativa delle latenze di trasferimento da dispositivo a host per il traffico multislice. La misurazione della latenza inizia quando viene inviata una richiesta di trasferimento dei dati tramite la DCN e termina quando viene ricevuta la conferma del completamento del trasferimento dei dati. Per monitorare questa metrica, filtra in base al nome della metrica device_to_host_transfer_latencies.

Debug degli errori comuni

Impossibile eseguire l'hashing degli avvisi di configurazione dell'acceleratore

I seguenti messaggi sono solo avvisi e non influiscono sulle prestazioni del codice JAX.

INFO:jax._src.cache_key:get (_hash_accelerator_config): unable to hash accelerator config, falling back to hashing devices + platform: UNIMPLEMENTED: GetTopologyForDevices is not supported for the IFRT proxy client. (type <class 'jaxlib.xla_extension.XlaRuntimeError'>)

Autorizzazione logging.logEntries.create negata per la risorsa

Se visualizzi il seguente errore, assicurati che il service account Compute Engine utilizzato da Vertex AI Workbench disponga delle autorizzazioni per scrivere voci di log nel sistema di logging Google Cloud .

INFO:absl:Created 'ArrayHandler' with primary_host=0, replica-id=0
WARNING:absl:pathwaysutils: Detected Pathways-on-Cloud backend. Applying changes.
Failed to submit 1 logs.
Traceback (most recent call last):
  File "/opt/conda/lib/python3.10/site-packages/google/api_core/grpc_helpers.py", line 65, in error_remapped_callable
    return callable_(**args, **kwargs)
  File "/opt/conda/lib/python3.10/site-packages/grpc/_channel.py", line 1181, in __call__
    return _end_unary_response_blocking(state, call, False, None)
  File "/opt/conda/lib/python3.10/site-packages/google/api_core/grpc_helpers.py", line 1006, in _end_unary_response_blocking
    raise _InactiveRpcError(state) # pytype: disable-not-instantiable
grpc._channel._InactiveRpcError: <_InactiveRpcError of RPC that terminated with:
  status = StatusCode.PERMISSION_DENIED
  details = "Permission 'logging.logEntries.create' denied on resource (or it may not exist)."
  debug_error_string = "UNKNOWN:Error received from peer ipv4:216.239.34.174:443 {created_time:"2024-10-03T20:30:44.820425276+00.00", grpc_status:7, grpc_message:"Permission \'logging.logEntries.create\' denied on resource (or it may not exist)."}"
>

Per risolvere il problema, aggiungi il ruolo Writer log al account di servizio Compute Engine.

Impossibile connettersi al server proxy IFRT

Se visualizzi questo errore, il client proxy IFRT non è in grado di connettersi al server proxy IFRT.

  • Assicurati che la rete VPC sia configurata correttamente
  • Assicurati che il firewall sia configurato per consentire la connessione
  • Assicurati che sia stato eseguito il provisioning del cluster Pathways
  • Controlla la presenza di messaggi di errore di avvio

Quando il primo comando JAX che invia un comando IFRT al cluster Pathways tenta di essere eseguito, smetterà di rispondere per circa un minuto e poi mostrerà un RuntimeError come il seguente:

RuntimeError: Unable to initialize backend 'proxy': UNAVAILABLE: Unable to establish connection to ifrt_proxy server, please check provided address example-workload-proxy-0-0.example-workload.default.svc.example-cluster-domain.:38676'; detailed error: DNS resolution failed (set JAX_PLATFORMS='' to automatically choose an available backend)

Handshake ALTS non riuscito o socket chiuso durante la connessione al server proxy IFRT

Se vedi Alts handshake failed (TSI_INTERNAL_ERROR) o UNAVAILABLE: Unable to establish connection to ifrt_proxy server ... Socket closed quando esegui un manifest personalizzato senza il campo hostNetwork: true su un pool di nodi di GKE Workload Identity, imposta la variabile di ambiente IFRT_PROXY_USE_INSECURE_GRPC_CREDENTIALS: "true" sia sul container pathways-proxy sia sul container client JAX (entrambi i lati devono corrispondere). L'aggiunta di questa variabile di ambiente disattiva ALTS e utilizza gRPC non sicuro.

Esiste una connessione al cluster Pathways

Un cluster Pathways può mantenere una sessione con un solo client alla volta. Se due notebook separati tentano di connettersi allo stesso cluster Pathways, uno riuscirà a connettersi e l'altro mostrerà i seguenti errori.

INFO:absl:Created ArrayHandler with primary_host=0, replica_id=0
WARNING:absl:pathwaysutils: Detected Pathways-on-Cloud backend. Applying changes.
E0927 21:19:52.919607   37624 rpc_helper.cc:56] Connection to IFRT proxy server was terminated: CANCELLED: Cancelled
E0927 21:20:03.467547   37719 rpc_helper.cc:56] Connection to IFRT proxy server was terminated: CANCELLED: Cancelled
E0927 21:20:14.011645   37807 rpc_helper.cc:56] Connection to IFRT proxy server was terminated: CANCELLED: Cancelled
E0927 21:20:24.557955   37924 rpc_helper.cc:56] Connection to IFRT proxy server was terminated: CANCELLED: Cancelled
---------------------------------------------------------------------------
XlaRuntimeError                           Traceback (most recent call last)
File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:887, in backends()
    885   continue
--> 887 backend = _init_backend(platform)
    888 _backends[platform] = backend

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:973, in _init_backend(platform)
    972 logger.debug("Initializing backend '%s'", platform)
--> 973 backend = registration.factory()
    974 # TODO: consider raising more descriptive errors directly from backend
    975 # factories instead of returning None.

File /opt/conda/lib/python3.10/site-packages/pathwaysutils/proxy_backend.py:24, in register_backend_factory.<locals>.<lambda>()
     21 def register_backend_factory():
     22   xla_bridge.register_backend_factory(
     23       "proxy",
---> 24       lambda: ifrt_proxy.get_client(
     25           jax.config.read("jax_backend_target"),
     26           ifrt_proxy.ClientConnectionOptions(),
     27       ),
     28       priority=-1,
     29   )

XlaRuntimeError: UNAVAILABLE: Unable to establish connection to ifrt_proxy server, please check provided address example-workload-proxy-0-0.example-workload.default.svc.example-cluster-domain.:38676'; detailed error: Connection to IFRT proxy server was terminated: CANCELLED: Cancelled

During handling of the above exception, another exception occurred:

RuntimeError                              Traceback (most recent call last)
Cell In[2], line 4
      1 import pathwaysutils
      3 import jax
----> 4 print(jax.devices())

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:1085, in devices(backend)
   1060 def devices(
   1061     backend: str | xla_client.Client | None = None
   1062 ) -> list[xla_client.Device]:
   1063   """Returns a list of all devices for a given backend.
   1064
   1065   .. currentmodule:: jaxlib.xla_extension
   (...)
   1083     List of Device subclasses.
   1084   """
-> 1085   return get_backend(backend).devices()

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:1019, in get_backend(platform)
   1015 @lru_cache(maxsize=None)  # don't use util.memoize because there is no X64 dependence.
   1016 def get_backend(
   1017     platform: None | str | xla_client.Client = None
   1018 ) -> xla_client.Client:
-> 1019   return _get_backend_uncached(platform)

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:998, in _get_backend_uncached(platform)
    994   return platform
    996 platform = (platform or _XLA_BACKEND.value or _PLATFORM_NAME.value or None)
--> 998 bs = backends()
    999 if platform is not None:
   1000   platform = canonicalize_platform(platform)

File /opt/conda/lib/python3.10/site-packages/jax/_src/xla_bridge.py:903, in backends()
    901       else:
    902         err_msg += " (you may need to uninstall the failing plugin package, or set JAX_PLATFORMS=cpu to skip this backend.)"
--> 903       raise RuntimeError(err_msg)
    905 assert _default_backend is not None
    906 if not config.jax_platforms.value:

RuntimeError: Unable to initialize backend 'proxy': UNAVAILABLE: Unable to establish connection to ifrt_proxy server, please check provided address 'example-workload-proxy-0-0.example-workload.default.svc.example-cluster-domain.:38676'; detailed error: Connection to IFRT proxy server was terminated: CANCELLED: Cancelled (set JAX_PLATFORMS='' to automatically choose an available backend)

Una volta che il client originale si disconnette, il secondo client potrà connettersi. Dopo una disconnessione imprevista, potrebbe essere necessario riavviare il cluster Pathways per consentire la connessione di altri client.

LocalProxy.init() got an unexpected keyword argument 'unbound_message'

Se visualizzi questo errore dopo aver importato pathwaysutils, controlla se nel tuo ambiente sono installate versioni obsolete di Flask o Werkzeug:

 pip3 list --outdated (replacing pip with pip3 as needed)

Se Flask o Werkzeug sono elencati, valuta la possibilità di eseguirne l'upgrade, tenendo presente che questa operazione potrebbe interrompere altri pacchetti o dipendenze nel tuo progetto:

 pip install flask Werkzeug --upgrade ()

Errore interno del server proxy

"Internal error from proxy server during Array::IsDeleted(): UNAVAILABLE:Connection to IFRT proxy server was terminated: FAILED_PRECONDITION:
GrpcClientSession: writes no longer allowed."

Questo errore indica che il server proxy IFRT si è disconnesso dal client. Il problema può essere risolto riavviando il client. Per i notebook, puoi riavviare il kernel del notebook ed eseguirlo di nuovo.

SIGTERM e OOM HBM

Un SIGTERM trovato nei log associati a un errore RESOURCE_EXHAUSTED potrebbe indicare un OOM HBM. In questo caso, puoi ridurre la quantità di memoria HBM utilizzata nel codice JAX.

INVALID_ARGUMENT

"INVALID_ARGUMENT : Permanent error, with a last message of Lifecycle
matches_prefix cannot specify more than 50 prefixes per config.; Error while
initializing persistent cache storage Cloud Storage"

Questo errore si verifica se il bucket Cloud Storage passato al flag --pathways_gcs_location ha raggiunto il limite massimo della policy del ciclo di vita. In questo caso, esegui la pulizia delle policy del ciclo di vita di Cloud Storage che non vengono più utilizzate.

Errore permanente

Permanent error, with a last message of The specified bucket does not exist.; Error while initializing persistent cache storage gcs

Questo errore viene visualizzato sui worker di Resource Manager o Pathways quando fornisci una località Cloud Storage non valida ai container Pathways.

Error response from daemon

Error response from daemon: dockerfile parse error line 16: Unknown flag: exclude

Ciò è dovuto a una versione precedente di Docker. Esegui l'upgrade della versione di Docker.

Il client e il server proxy IFRT non sono riusciti a raggiungere un accordo

IFRT Proxy client and server failed to agree on the protocol version; supported versions: client = [1, 1], server = [3, 14]

Ciò indica che è in uso una versione precedente di MaxText. Assicurati di ricreare l'immagine MaxText più recente.

Passaggi successivi