Soluciona problemas de Pathways on Cloud

Antes de comenzar

En este documento, se explica cómo solucionar problemas de tus cargas de trabajo de Pathways.

Visualiza registros

Puedes ver los registros de tus cargas de trabajo de Pathways directamente con el comando gcluster job logs (pasa --main-only=false para incluir los registros de los Pods de trabajadores):

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

Para enumerar todos los Pods de tu carga de trabajo con kubectl, usa la etiqueta de carga de trabajo de Cluster Toolkit:

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

Para verificar el estado de la carga de trabajo o enumerar los trabajos con errores, usa el comando gcluster job list:

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

Como alternativa, en el Explorador de registros de Cloud Logging, usa la siguiente consulta ajustada para que coincida con tu proyecto, región, clúster y carga de trabajo:

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"

Reemplaza lo siguiente:

  • PROJECT : Es el ID de tu proyecto de Google Cloud .
  • LOCATION: Es la región o zona en la que creaste el clúster de GKE.
  • CLUSTER : Es el nombre de tu clúster de GKE.
  • WORKLOAD_NAME: Es el nombre de tu carga de trabajo cuando usas Cluster Toolkit o el nombre de JobSet cuando usas kubectl.

Esta consulta coincidirá con varios contenedores de Kubernetes de Pathways con nombres como pathways-rm, pathways-proxy y pathways-worker. Puedes limitar el contenedor que causa un problema agregando un filtro en el nombre del contenedor, como resource.labels.container_name:"<container_name>"

Supervisión

Supervisión del estado

Puedes supervisar el estado de varios componentes de Pathways buscando entradas en los registros del contenedor, por ejemplo:

pathways-proxy está listo para entregar solicitudes de conexión nuevas cuando se escribe el siguiente registro:

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 está listo para entregar solicitudes de conexión nuevas cuando se escribe el siguiente registro:

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

Para verificar que todas las TPU registradas en el administrador de recursos de Pathways estén listas, puedes buscar ***<num slices>/<num slices> Pathways Slices Now Ready *** en los registros del contenedor 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 ***

El cliente de Pathways puede establecer conexiones con el servidor proxy de IFRT siempre que el servidor proxy esté listo, incluso si no todas las porciones están listas. Tu trabajo funciona con porciones virtuales hasta que la porción esté lista. Las porciones virtuales permiten que tu código se ejecute cuando las TPU no están disponibles.

pathways-worker está listo para entregar solicitudes de conexión nuevas cuando se escribe el siguiente registro:

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

Recopilación de métricas

Pathways puede escribir métricas del sistema de bajo nivel en Cloud Monitoring para la depuración. Las métricas incluyen lo siguiente:

  • Latencia de transferencia de DCN
  • Latencia colectiva
  • Latencia de transferencia de host a dispositivo
  • Latencia de transferencia de dispositivo a host

Puedes encontrar las métricas en el panel de Cloud Monitoring del proyecto deGoogle Cloud en el que se ejecuta el clúster de GKE.

Para supervisar estas métricas en el Explorador de métricas, sigue estos pasos:

  1. Navega al Explorador de métricas.
  2. Filtra por el nombre de la métrica con el campo Seleccionar una métrica.
  3. Filtra por el nombre de tu carga de trabajo y el período. Para ello, selecciona Agregar filtro y filtra por pod_name.
  4. Elige un tipo de agregación adecuado según la métrica y las cargas de trabajo que supervisas.

Latencia de transferencia de DCN

Esta es una métrica de Megascale XLA (MXLA) que mide la distribución acumulativa de las latencias de transferencia de red para el tráfico de Multislice. La medición de la latencia comienza cuando se emite una solicitud para que se transfieran datos a través de la DCN y finaliza cuando se recibe un acuse de recibo de que se completó la transferencia de datos. Para supervisar esta métrica, filtra por el nombre de la métrica dcn_transfer_latencies.

Latencia colectiva

Esta es una métrica de MXLA que mide la distribución acumulativa de la latencia colectiva de extremo a extremo para el tráfico de varias porciones. La medición de la latencia comienza cuando se emite una solicitud para un colectivo y finaliza cuando se recibe una confirmación de que se completó la transferencia de datos. Para supervisar esta métrica, filtra por el nombre de la métrica collective_e2e_latency.

Latencia de transferencia de host a dispositivo

Esta es una métrica de MXLA que mide la distribución acumulativa de las latencias de transferencia de host a dispositivo para el tráfico de varias porciones. La medición de la latencia comienza cuando se emite una solicitud para que los datos se transfieran a través de la DCN y finaliza cuando se recibe un acuse de recibo de que se completó la transferencia de datos. Para supervisar esta métrica, filtra por el nombre de la métrica host_to_device_transfer_latencies.

Latencia de transferencia de dispositivo a host

Esta es una métrica de MXLA que mide la distribución acumulativa de las latencias de transferencia de dispositivo a host para el tráfico de Multislice. La medición de la latencia comienza cuando se emite una solicitud de transferencia de datos a través de la DCN y finaliza cuando se recibe un acuse de recibo de que se completó la transferencia de datos. Para supervisar esta métrica, filtra por el nombre de la métrica device_to_host_transfer_latencies.

Depura los errores comunes

No se pueden generar hashes de las advertencias de configuración del acelerador

Los siguientes mensajes son solo advertencias y no afectan el rendimiento de tu código de 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'>)

Se denegó el permiso logging.logEntries.create en el recurso

Si ves el siguiente error, asegúrate de que la cuenta de servicio de Compute Engine que usa Vertex AI Workbench tenga permisos para escribir entradas de registro en el sistema de registro de 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)."}"
>

Para solucionar este problema, agrega el rol de Escritor de registros a la cuenta de servicio de Compute Engine.

No se puede establecer conexión con el servidor proxy de IFRT

Si ves este error, significa que tu cliente de proxy de IFRT no puede conectarse al servidor proxy de IFRT.

  • Asegúrate de que tu red de VPC esté configurada correctamente
  • Asegúrate de que el firewall esté configurado para permitir la conexión
  • Asegúrate de que se haya aprovisionado tu clúster de Pathways
  • Verifica si hay mensajes de error de inicio

Cuando el primer comando de JAX que envía un comando de IFRT al clúster de Pathways intente ejecutarse, dejará de responder durante un minuto y, luego, mostrará un RuntimeError como el siguiente:

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)

Se produjo un error en el protocolo de enlace de ALTS o se cerró el socket cuando se estableció la conexión con el servidor proxy de IFRT

Si ves Alts handshake failed (TSI_INTERNAL_ERROR) o UNAVAILABLE: Unable to establish connection to ifrt_proxy server ... Socket closed cuando ejecutas un manifiesto personalizado sin el campo hostNetwork: true en un grupo de nodos de Workload Identity de GKE, establece la variable de entorno IFRT_PROXY_USE_INSECURE_GRPC_CREDENTIALS: "true" en el contenedor pathways-proxy y en el contenedor del cliente de JAX (ambos lados deben coincidir). Agregar esta variable de entorno inhabilita ALTS y, en su lugar, usa gRPC no seguro.

Hay una conexión existente con el clúster de Pathways

Un clúster de Pathways solo puede mantener una sesión con un cliente a la vez. Si dos notebooks independientes intentan conectarse al mismo clúster de Pathways, uno podrá conectarse y el otro mostrará los siguientes errores.

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 vez que el cliente original se desconecte, el segundo cliente podrá conectarse. Después de una desconexión inesperada, es posible que debas reiniciar el clúster de Pathways para permitir que se conecten otros clientes.

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

Si ves este error después de importar pathwaysutils, verifica si hay versiones desactualizadas de Flask o Werkzeug instaladas en tu entorno:

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

Si Flask o Werkzeug aparecen en la lista, considera actualizarlos con la advertencia de que, si lo haces, es posible que se dañen otros paquetes o dependencias de tu proyecto:

 pip install flask Werkzeug --upgrade ()

Error interno del servidor proxy

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

Este error indica que el servidor proxy de IFRT se desconectó del cliente. Para solucionar este problema, reinicia el cliente. En el caso de los notebooks, puedes reiniciar el kernel y volver a ejecutar el notebook.

SIGTERM y OOM de HBM

Un SIGTERM que se encuentra en los registros asociados con un error RESOURCE_EXHAUSTED puede indicar un OOM de HBM. En este caso, puedes reducir la cantidad de memoria de HBM que se usa en tu código de 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"

Este error se produce si el bucket de Cloud Storage que se pasa a la marca --pathways_gcs_location alcanzó el límite máximo de la política de ciclo de vida. Si esto ocurre, limpia las políticas de ciclo de vida de Cloud Storage que ya no se usen.

Error permanente

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

Este error se imprime en los trabajadores de Resource Manager o Pathways cuando proporcionas una ubicación de Cloud Storage no válida a los contenedores de Pathways.

Error response from daemon

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

Esto se debe a que tienes una versión anterior de Docker. Actualízala.

El cliente y el servidor del proxy de IFRT no pudieron establecer un acuerdo

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

Esto indica que se está usando una versión anterior de MaxText. Asegúrate de volver a compilar la imagen más reciente de MaxText.

¿Qué sigue?