Prácticas recomendadas para optimizar el rendimiento

En esta página se explica cómo mejorar Cloud Storage FUSE mediante las funciones y configuraciones clave de Cloud Storage FUSE para conseguir el máximo rendimiento y un rendimiento óptimo, especialmente en cargas de trabajo de inteligencia artificial y aprendizaje automático (IA/AA), como el entrenamiento, el servicio y la creación de puntos de control.

Cuestiones importantes

Antes de aplicar las configuraciones que recomendamos en esta página, tenga en cuenta lo siguiente:

• Puedes aplicar las configuraciones recomendadas de esta página de tres formas:

  • Archivo de configuración de Cloud Storage FUSE

  • Opciones de la CLI de Cloud Storage FUSE

  • Solo para Google Kubernetes Engine: archivos YAML de ejemplo de Google Kubernetes Engine

• Asegúrate de que estás usando la versión más reciente de Cloud Storage FUSE. Las configuraciones recomendadas solo se deben aplicar a Cloud Storage FUSE 3.0 o versiones posteriores y al controlador CSI de Cloud Storage FUSE para Google Kubernetes Engine que se ejecuta en clústeres de GKE con la versión 1.32.2-gke.1297001 o posterior.

• Las configuraciones recomendadas almacenan en caché los metadatos de Cloud Storage durante la duración de la tarea y no se comprueban después del montaje inicial del sistema de archivos. Por lo tanto, te recomendamos que el sistema de archivos sea de solo lectura o que la semántica del sistema de archivos sea de aplicaciones de escritura en archivos nuevos, lo que significa que las aplicaciones siempre escriben en archivos nuevos, para obtener un rendimiento óptimo. Las siguientes cargas de trabajo de IA y aprendizaje automático son de escritura en nuevo:

  • Creación de puntos de control

  • Formación

  • sirviendo

  • Almacenamiento en caché de jax.jit()

• Las configuraciones recomendadas de esta página se han validado para tipos de máquinas grandes de Cloud GPUs y Cloud TPUs a gran escala, donde hay una gran cantidad de memoria y una interfaz de red de gran ancho de banda. Los tipos de máquinas de GPUs y TPUs de Cloud pueden diferir en cuanto al número de recursos disponibles, como la CPU, la memoria y el almacenamiento local, en la configuración de su nodo host. Esto puede afectar directamente al rendimiento de configuraciones como las siguientes:

  • A3 Ultra

  • A3 Mega: 1, 8 TiB de memoria y 6 TiB de LSSD

  • TPU de Cloud v5e: 188 GiB de memoria, sin LSSD

  • TPU de Cloud v5p: 448 GiB de memoria, sin LSSD

  • TPU de Cloud v6 (Trillium): 1,5 TiB de memoria, sin LSSD

Usar segmentos con el espacio de nombres jerárquico habilitado

Usa siempre segmentos con el espacio de nombres jerárquico habilitado. El espacio de nombres jerárquico organiza los datos en una estructura jerárquica del sistema de archivos, lo que hace que las operaciones en el contenedor sean más eficientes, lo que se traduce en tiempos de respuesta más rápidos y menos llamadas de lista en general para cada operación.

Estas son algunas de las ventajas del espacio de nombres jerárquico:

• Los segmentos con espacio de nombres jerárquico proporcionan hasta ocho veces más consultas por segundo (QPS) iniciales que los segmentos planos. El espacio de nombres jerárquico admite 40.000 solicitudes de lectura de objetos iniciales por segundo y 8000 solicitudes de escritura de objetos iniciales, lo que supone un aumento significativo en comparación con los segmentos planos de Cloud Storage FUSE, que solo ofrecen 5000 solicitudes de lectura de objetos iniciales por segundo y 1000 solicitudes de escritura de objetos iniciales.

• El espacio de nombres jerárquico proporciona cambios de nombre de directorio atómicos, que son necesarios para la creación de puntos de control con Cloud Storage FUSE para asegurar la atomicidad. Usar segmentos con el espacio de nombres jerárquico habilitado es especialmente útil cuando se crean puntos de control a gran escala, ya que los frameworks de aprendizaje automático usan cambios de nombre de directorio para finalizar los puntos de control, que es un comando rápido y atómico, y solo se admite en segmentos con el espacio de nombres jerárquico habilitado. Si decides no usar un segmento con el espacio de nombres jerárquico habilitado, consulta Aumentar el límite de cambio de nombre de los segmentos que no tienen HNS.

Para saber cómo crear un segmento con el espacio de nombres jerárquico habilitado, consulta Crear segmentos con el espacio de nombres jerárquico habilitado. Para saber cómo montar un segmento con espacio de nombres jerárquico habilitado, consulte Montar segmentos con espacio de nombres jerárquico habilitado. Los espacios de nombres jerárquicos son compatibles con las versiones 1.31.1-gke.2008000 o posteriores de Google Kubernetes Engine.

Realizar un montaje específico de un directorio

Si quieres acceder a un directorio específico de un segmento, puedes montar solo ese directorio con la opción de montaje only-dir en lugar de montar todo el segmento. Al montar un directorio específico, se aceleran las llamadas de lista y se reduce el número total de llamadas de lista y de estado, ya que se limita el número de directorios que se deben recorrer al resolver un nombre de archivo. Esto se debe a que las llamadas de LookUpInode y las solicitudes de acceso a un contenedor o a un directorio generan automáticamente llamadas de lista y de estado para cada archivo o directorio de la ruta.

Para montar un directorio específico, utilice uno de los siguientes métodos:

volumeHandle: BUCKET_NAME
    - only-dir:DIRECTORY_NAME

gcsfuse --only-dir DIRECTORY_NAME BUCKET_NAME MOUNT_POINT

Para obtener más información sobre cómo montar un directorio, consulta Montar un directorio en un contenedor.

Aumentar los valores de la caché de metadatos

Para mejorar el rendimiento de las lecturas repetidas, puedes configurar Cloud Storage FUSE para que almacene en caché una gran cantidad de metadatos y omita la caducidad de los metadatos. De esta forma, se evitan las solicitudes de metadatos repetidas a Cloud Storage y se mejora significativamente el rendimiento.

Aumentar los valores de la caché de metadatos es útil para las cargas de trabajo con lecturas repetidas, ya que se evitan las llamadas repetitivas a Cloud Storage, y para los volúmenes de solo lectura, en los que se puede definir un TTL infinito.

Antes de aumentar los valores de la caché de metadatos, ten en cuenta lo siguiente:

• El tiempo de vida (TTL) infinito solo se debe definir para los volúmenes que sean de solo lectura o de escritura solo en nuevos.

• La caché de metadatos solo debe habilitarse para que aumente de tamaño de forma significativa en los nodos con configuraciones de memoria grandes, ya que almacena en caché todos los metadatos del punto de montaje especificado en cada nodo y elimina la necesidad de acceder a Cloud Storage.

• Las configuraciones de esta sección almacenan en caché todos los metadatos a los que se accede con un TTL infinito, lo que puede afectar a las garantías de coherencia cuando cualquier otro cliente realiza cambios en el mismo segmento de Cloud Storage, por ejemplo, cuando se sobrescribe o se elimina un archivo.

• Para verificar que el consumo de memoria no se vea afectado, comprueba que la cantidad de memoria consumida por la caché de metadatos sea aceptable. Esta cantidad puede llegar a ser de varios gigabytes y depende del número de archivos de los contenedores montados y de cuántos puntos de montaje se estén usando. Por ejemplo, los metadatos de cada archivo ocupan aproximadamente 1,5 KiB de memoria y, por tanto, los metadatos de un millón de archivos ocupan aproximadamente 1,5 GiB de memoria. Para obtener más información, consulta la descripción general del almacenamiento en caché.

Sigue estas instrucciones para configurar Cloud Storage FUSE de forma que almacene en caché una gran cantidad de metadatos y omita la caducidad de los metadatos:

gcsfuse --metadata-cache-ttl-secs=-1 \
      --stat-cache-max-size-mb=-1 \
      --type-cache-max-size-mb=-1 \
      BUCKET_NAME MOUNT_POINT

metadata-cache:
stat-cache-max-size-mb: -1
ttl-secs: -1
type-cache-max-size-mb: -1

  mountOptions:
      - metadata-cache:ttl-secs:-1
      - metadata-cache:stat-cache-max-size-mb:-1
      - metadata-cache:type-cache-max-size-mb:-1

gcsfuse --metadata-cache-ttl-secs=-1 \
      --stat-cache-max-size-mb=-1 \
      --type-cache-max-size-mb=-1 \
      BUCKET_NAME MOUNT_POINT

Rellenar previamente la caché de metadatos

Antes de ejecutar una carga de trabajo, te recomendamos que rellenes previamente la caché de metadatos, lo que mejora significativamente el rendimiento y reduce considerablemente el número de llamadas de metadatos a Cloud Storage, sobre todo si se usa la opción de configuración implicit-dirs. El controlador CSI de Cloud Storage FUSE para GKE proporciona una API que gestiona el precargado de la caché de metadatos. Consulta Usar la prefetración de metadatos para precargar la caché de metadatos.

Para rellenar previamente la caché de metadatos, utilice uno de los siguientes métodos:

  apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: training-bucket-pv
  spec:
    ...
    csi:
      volumeHandle: BUCKET_NAME
      volumeAttributes:
        ...
        gcsfuseMetadataPrefetchOnMount: "true"
  

ls -R MOUNT_POINT > /dev/null

ls -R MOUNT_POINT > /dev/null

Habilitar el almacenamiento en caché de archivos y las descargas paralelas

El almacenamiento en caché de archivos te permite almacenar datos de archivos a los que se accede con frecuencia de forma local en tu máquina, lo que acelera las lecturas repetidas y reduce los costes de Cloud Storage. Cuando habilitas el almacenamiento en caché de archivos, las descargas paralelas también se habilitan automáticamente. Las descargas paralelas utilizan varios trabajadores para descargar un archivo en paralelo usando el directorio de caché de archivos como búfer de prefetched, lo que da como resultado un tiempo de carga del modelo nueve veces más rápido.

Para saber cómo habilitar y configurar el almacenamiento en caché de archivos y las descargas paralelas, consulta Habilitar y configurar el comportamiento del almacenamiento en caché de archivos. Para usar una configuración de ejemplo, consulta Configuración de ejemplo para habilitar el almacenamiento en caché de archivos y las descargas paralelas.

Consideraciones sobre las GPUs de Cloud y las TPUs de Cloud para usar el almacenamiento en caché de archivos y las descargas paralelas

La caché de archivos se puede alojar en SSDs locales, RAM, Persistent Disk o Hyperdisk de Google Cloud siguiendo estas directrices. En todos los casos, los datos o el archivo grande individual deben caber en el directorio de caché de archivos, cuya capacidad disponible se controla mediante la configuración max-size-mb.

Consideraciones sobre las GPUs de Cloud

Las SSDs locales son ideales para los datos de entrenamiento y las descargas de puntos de control. Los tipos de máquina de GPUs de Cloud incluyen capacidad de SSD que se puede usar, como los tipos de máquina A4, que incluyen 12 TiBs de SSD.

• Un disco RAM ofrece el mejor rendimiento para cargar los pesos del modelo debido a su pequeño tamaño en comparación con la cantidad de RAM sin usar del sistema.

• Persistent Disk o Google Cloud Hyperdisk se pueden usar como caché.

Consideraciones sobre las TPU de Cloud

Las TPUs de Cloud no admiten SSDs locales. Si usas el almacenamiento en caché de archivos en Cloud TPU sin modificarlo, la ubicación predeterminada es el volumen de arranque, lo que no se recomienda y da como resultado un rendimiento deficiente.

En lugar del volumen de arranque, te recomendamos que utilices un disco RAM, que es la opción preferida por su rendimiento y porque no tiene ningún coste adicional. Sin embargo, el tamaño de un disco RAM suele ser limitado y resulta más útil para servir pesos de modelos o descargas de puntos de control en función del tamaño del punto de control y de la RAM disponible. Además, te recomendamos que utilices Persistent Disk y Google Cloud Hyperdisk para el almacenamiento en caché.

Configuración de ejemplo para habilitar el almacenamiento en caché de archivos y las descargas paralelas

De forma predeterminada, la caché de archivos usa un SSD local si el modo ephemeral-storage-local-ssd está habilitado en el nodo de Google Kubernetes Engine. Si no hay ningún SSD local disponible (por ejemplo, en las máquinas de TPU de Cloud), la caché de archivos usa el disco de arranque del nodo de Google Kubernetes Engine, lo que no es recomendable. En este caso, puedes usar un disco RAM como directorio de caché, pero ten en cuenta la cantidad de RAM disponible para el almacenamiento en caché de archivos en comparación con lo que necesita el pod.

gcsfuse --file-cache-max-size-mb= -1 \
      --file-cache-cache-file-for-range-read= true \
      --file-cache-enable-parallel-downloads= true \
      BUCKET_NAME

file-cache:
  max-size-mb: -1
  cache-file-for-range-read: true
  enable-parallel-downloads: true

mountOptions:
    - file-cache:max-size-mb:-1
    - file-cache:cache-file-for-range-read:true
    - file-cache:enable-parallel-downloads:true

# RAM disk file cache if LSSD not available. Uncomment to use
# volumes:
#   - name: gke-gcsfuse-cache
#     emptyDir:
#       medium: Memory

mountOptions:
    - file-cache:max-size-mb:-1
    - file-cache:cache-file-for-range-read:true
    - file-cache:enable-parallel-downloads:true

volumes:
    - name: gke-gcsfuse-cache
      emptyDir:
        medium: Memory

gcsfuse --file-cache-max-size-mb: -1 \
      --file-cache-cache-file-for-range-read: true \
      --file-cache-enable-parallel-downloads: true \
      BUCKET_NAME MOUNT_POINT

Inhabilitar entradas de caché de estadísticas negativas

De forma predeterminada, Cloud Storage FUSE almacena en caché las entradas de estadísticas negativas, es decir, las entradas de archivos que no existen, con un TTL de cinco segundos. En cargas de trabajo en las que los archivos se crean o se eliminan con frecuencia, como la creación de puntos de control distribuidos, estas entradas almacenadas en caché pueden quedar obsoletas rápidamente, lo que provoca problemas de rendimiento. Para evitarlo, te recomendamos que inhabilites la caché de estadísticas negativas para las cargas de trabajo de entrenamiento, publicación y creación de puntos de control mediante la opción de configuración negative-ttl-secs.

Sigue estas instrucciones para inhabilitar la caché de estadísticas negativas:

gcsfuse --metadata-cache-negative-ttl-secs= 0 \
  BUCKET_NAME

metadata-cache:
 negative-ttl-secs: 0

mountOptions:
    - metadata-cache:negative-ttl-secs:0

gcsfuse --metadata-cache-negative-ttl-secs: 0 \
  BUCKET_NAME MOUNT_POINT

Habilitar escritura de streaming

Las escrituras de streaming suben datos directamente a Cloud Storage a medida que se escriben, lo que reduce la latencia y el uso del espacio en disco. Esto resulta especialmente útil para las escrituras secuenciales de gran tamaño, como los puntos de control. Las escrituras de streaming están habilitadas de forma predeterminada en Cloud Storage FUSE 3.0 y versiones posteriores.

Si las escrituras de streaming no están habilitadas de forma predeterminada, sigue estas instrucciones para habilitarlas. Para habilitar las escrituras de streaming, se necesita la versión 3.0 de Cloud Storage FUSE, que está disponible en Google Kubernetes Engine 1.32.1-gke.1729000 o versiones posteriores.

gcsfuse --enable-streaming-writes= true \
  BUCKET_NAME

write:
 enable-streaming-writes: true

mountOptions:
    - write:enable-streaming-writes:true

gcsfuse --enable-streaming-writes: true \
  BUCKET_NAME MOUNT_POINT

Habilitar lecturas almacenadas en búfer

Las lecturas almacenadas en búfer pueden mejorar el rendimiento de lectura secuencial de archivos grandes entre dos y cinco veces. Para ello, se prefetchan de forma asíncrona partes de un objeto de Cloud Storage en un búfer en memoria. De esta forma, las lecturas posteriores se pueden servir desde el búfer en lugar de requerir llamadas de red.

Antes de habilitar las lecturas almacenadas en búfer, tenga en cuenta lo siguiente:

• Las lecturas almacenadas en búfer no son compatibles con el almacenamiento en caché de archivos. Si se habilitan tanto las lecturas almacenadas en búfer como el almacenamiento en caché de archivos, este último tiene prioridad y las lecturas almacenadas en búfer se ignoran.

• Las lecturas almacenadas en búfer pueden ocupar una cantidad considerable de memoria y recursos computacionales.

Para habilitar las lecturas almacenadas en búfer, sigue estas instrucciones:

gcsfuse --enable-buffered-read= true \
  BUCKET_NAME

write:
 enable-buffered-read: true

Aumentar el tamaño de lectura anticipada del kernel

En el caso de las cargas de trabajo que implican principalmente lecturas secuenciales de archivos grandes, como las restauraciones de puntos de control y de servicio, aumentar el tamaño de lectura anticipada puede mejorar significativamente el rendimiento. Para ello, puedes usar el read_ahead_kb parámetro del kernel de Linux en tu máquina local. Te recomendamos que aumentes el parámetro del kernel read_ahead_kb a 1 MB en lugar de usar la cantidad predeterminada de 128 KB que se establece en la mayoría de las distribuciones de Linux. En las instancias de Compute Engine, se necesitan los permisos sudo o root para aumentar correctamente el parámetro del kernel.

Para aumentar el parámetro del kernel read_ahead_kb a 1 MB en un directorio montado de Cloud Storage FUSE específico, sigue estas instrucciones. El bucket debe estar montado en Cloud Storage FUSE antes de ejecutar el comando. De lo contrario, el parámetro del kernel no aumentará.

mountOptions:
    - read_ahead_kb=1024

export MOUNT_POINT=/path/to/mount/point
echo 1024 | sudo tee /sys/class/bdi/0:$(stat -c "%d" $MOUNT_POINT)/read_ahead_kb

Inhabilitar el servicio de token de seguridad para evitar comprobaciones redundantes

El controlador CSI de Cloud Storage FUSE para Google Kubernetes Engine tiene comprobaciones de acceso para asegurar la recuperación de pods debido a una configuración incorrecta por parte del usuario de las vinculaciones de identidad de carga de trabajo entre el bucket y la cuenta de servicio de GKE, lo que puede alcanzar las cuotas predeterminadas de la API Security Token Service a gran escala. Para inhabilitarlo, define el atributo de volumen skipCSIBucketAccessCheck del controlador CSI de volumen persistente. Te recomendamos que te asegures de que la cuenta de servicio de GKE tenga el acceso adecuado al segmento de Cloud Storage de destino para evitar errores de montaje del pod.

Además, la cuota del servicio de tokens de seguridad debe aumentarse por encima del valor predeterminado de 6000 si un clúster de Google Kubernetes Engine consta de más de 6000 nodos, lo que puede provocar errores de 429 si no se aumenta en las implementaciones a gran escala. La cuota de Security Token Service debe aumentarse en la página Cuotas y límites. Te recomendamos que mantengas la cuota igual al número de montajes. Por ejemplo, si hay 10.000 montajes en el clúster, la cuota debe aumentarse a 10000.

Para definir el atributo de volumen skipCSIBucketAccessCheck, consulta la siguiente configuración de ejemplo:

  volumeAttributes:
      - skipCSIBucketAccessCheck: "true"
   

Otras consideraciones sobre el rendimiento

Además de las optimizaciones principales que hemos comentado, hay otros factores que pueden influir significativamente en el rendimiento general de Cloud Storage FUSE. En las siguientes secciones se describen otras consideraciones sobre el rendimiento que te recomendamos tener en cuenta al usar Cloud Storage FUSE.

Aumentar el límite de cambio de nombre de los contenedores que no son HNS

Las cargas de trabajo de creación de puntos de control siempre deben realizarse con un segmento que tenga habilitado el espacio de nombres jerárquico debido a los cambios de nombre atómicos y más rápidos, y a un QPS más alto para las lecturas y escrituras. Sin embargo, si aceptas el riesgo de que los cambios de nombre de los directorios no sean atómicos y tarden más, puedes usar la opción de configuración rename-dir-limit si estás realizando un punto de control con contenedores sin espacio de nombres jerárquico para especificar un límite en el número de archivos u operaciones que implica una operación de cambio de nombre de un directorio en un momento dado.

Te recomendamos que asignes un valor alto a la opción de configuración rename-dir-limit para evitar errores de creación de puntos de control. Como Cloud Storage FUSE usa un espacio de nombres plano y los objetos son inmutables, una operación de cambio de nombre de un directorio implica cambiar el nombre y eliminar todos los archivos individuales del directorio. Puedes controlar el número de archivos afectados por una operación de cambio de nombre configurando la opción rename-dir-limit de configuración.

Sigue estas instrucciones para definir la opción de configuración rename-dir-limit:

gcsfuse --rename-dir-limit= 200000 \
  BUCKET_NAME

file-system:
 rename-dir-limit: 200000

mountOptions:
    - rename-dir-limit=200000

gcsfuse --rename-dir-limit: 200000 \
  BUCKET_NAME MOUNT_POINT

Almacenamiento en caché de la lista de kernels

La caché de listas es una caché de listas de directorios y archivos, o ls, respuestas que mejoran la velocidad de las operaciones de listas. A diferencia de las cachés de estadísticas y de tipos, que gestiona Cloud Storage FUSE, la caché de listas se mantiene en la caché de páginas del kernel y el kernel la controla en función de la disponibilidad de memoria.

Habilitar el almacenamiento en caché de la lista del kernel es más útil en los siguientes casos prácticos:

• Cargas de trabajo con listados de directorios repetidos: esta configuración es especialmente útil para cargas de trabajo que realizan listados de directorios completos con frecuencia, como las ejecuciones de entrenamiento de IA o aprendizaje automático. Esto puede beneficiar tanto a las cargas de trabajo de servicio como a las de entrenamiento.

• Montajes de solo lectura: se recomienda usar el almacenamiento en caché de listas con montajes de solo lectura para evitar problemas de coherencia.

La habilitación del almacenamiento en caché de la lista del kernel debe hacerse con precaución y solo debe usarse si el sistema de archivos es de solo lectura y no se esperan cambios en el contenido del directorio durante la ejecución de un trabajo. Esto se debe a que, con esta marca, la aplicación local nunca ve actualizaciones, sobre todo si el TTL se ha definido en -1.

Por ejemplo, la lista Cliente 1 incluye directoryA, lo que provoca que directoryA se convierta en residente en la caché de la lista del kernel. El cliente 2 crea fileB en directoryA en el segmento de Cloud Storage. El cliente 1 comprueba continuamente si hay fileB en directoryA, lo que equivale a comprobar la entrada de la caché de la lista del kernel y nunca se conecta a la red. Cliente 1 no ve que haya un archivo nuevo en el directorio porque la lista de archivos se sirve continuamente desde la caché de la lista del kernel local. Cliente 1 agota el tiempo de espera y el programa deja de funcionar.

Sigue estas instrucciones para habilitar el almacenamiento en caché de listas:

gcsfuse --kernel-list-cache-ttl-secs= -1 \
  BUCKET_NAME

file-system:
 kernel-list-cache-ttl-secs: -1

mountOptions:
    - file-system:kernel-list-cache-ttl-secs:-1

gcsfuse --kernel-list-cache-ttl-secs: -1 \
  BUCKET_NAME MOUNT_POINT

Cuando usas la opción de montaje file-system:kernel-list-cache-ttl-secs, los valores tienen los siguientes significados:

• Un valor positivo representa el TTL en segundos para mantener la respuesta de la lista de directorios en la caché de páginas del kernel.

• El valor -1 omite el vencimiento de la entrada y devuelve la respuesta de la lista de la caché cuando está disponible.

Usar la caché de compilación persistente (JIT) de JAX con Cloud Storage FUSE

JAX admite la caché en tiempo de ejecución (JIT), una caché de compilación persistente opcional que almacena artefactos de funciones compiladas. Si usas esta caché, puedes acelerar significativamente las ejecuciones posteriores de la secuencia de comandos, ya que se evitan pasos de compilación redundantes.

Para habilitar el almacenamiento en caché JIT, debes cumplir los siguientes requisitos:

• Usa la versión más reciente de JAX: usa las versiones 0.5.1 o posteriores de JAX para disfrutar de las optimizaciones y las funciones de caché más recientes.

• Maximizar la capacidad de la caché: para evitar que el rendimiento se vea afectado por la expulsión de la caché, plantéate definir un tamaño de caché ilimitado, sobre todo si quieres anular la configuración predeterminada. Para ello, define la variable de entorno:

  export JAX_COMPILATION_CACHE_MAX_SIZE=-1
  

• Asegúrate de que el archivo YAML del pod de puntos de control: usa la configuración de puntos de control para el punto de montaje de la caché JIT de JAX.

Siguientes pasos

• Usa un archivo YAML de ejemplo de Google Kubernetes Engine para configurar las prácticas recomendadas de ajuste.

• Consulta más información sobre las opciones del archivo de configuración de FUSE de Cloud Storage.

• Consulta más información sobre las opciones de la CLI de FUSE de Cloud Storage.