Soluciona problemas

En esta página, se muestran pasos de solución de problemas que pueden resultarte útiles si tienes problemas para usar Filestore.

Rendimiento lento

  1. Asegúrate de usar el tipo de máquina recomendado para la VM de cliente.
  2. Si tu VM de cliente ejecuta Linux, confirma que estás usando las opciones de activación predeterminadas.

  3. Asegúrate de que la VM de cliente esté ubicada en la misma región que la instancia de Filestore. La activación entre regiones no solo reduce el rendimiento, sino que también genera un costo de red.

  4. Asegúrate de que tu instancia de Filestore no esté al máximo o esté cerca de su capacidad. Cuando la capacidad está casi llena, el espacio restante queda muy fragmentado, lo que hace que las operaciones de lectura y escritura se demoren. El límite de espacio libre necesario para evitar esta situación depende de cada caso. Te recomendamos configurar alertas de poco espacio en el disco.

  5. Prueba el rendimiento de tu instancia de Filestore con la herramienta fio.

    Si los resultados de la prueba muestran un rendimiento poco lento, comunícate con tu representante de cuenta. Si los resultados de la prueba muestran un rendimiento similar o superior al esperado, continúa con la sección siguiente.

Casos de uso que causan rendimiento lento

Estos son algunos casos prácticos y situaciones que causan un rendimiento deficiente:

Cargas de trabajo que involucran grandes volúmenes de archivos pequeños

Los archivos compartidos de Filestore usan la opción de exportación sync para la seguridad de datos y el cumplimiento del protocolo NFS. Esto significa que para la mayoría de las operaciones de modificación de datos, la instancia de Filestore espera a que los datos se confirmen al almacenamiento antes de responder las solicitudes desde la VM de cliente. Cuando muchos archivos están involucrados en una operación, el cliente realiza una larga serie de operaciones síncronas y suma la latencia acumulativa.

Un ejemplo de esto es extraer un archivo de los archivos compartidos, como archivos TAR. TAR realiza una gran cantidad de operaciones síncronas en una serie cuando se extrae un archivo que contiene muchos archivos. Como resultado, el rendimiento se reduce considerablemente.

Si intentas copiar una gran cantidad de archivos pequeños en un sistema de archivos compartidos, intenta paralelizar la creación de archivos con una herramienta como gsutil:

mkdir -p /mnt/nfs/many_files_rsync/
time gsutil -m -q rsync -rp many_files /mnt/nfs/many_files_rsync/

Copia datos entre Cloud Storage y Filestore

Se sabe que la copia de datos de Cloud Storage en una instancia de Filestore con gsutil es lenta. No hay una mitigación conocida.

Latencia durante la activación y desactivación de archivos compartidos

Existe una latencia de tres segundos que se ingresa cuando se activa un archivo compartido mediante las opciones de activación predeterminadas, que se generan cuando el intento de comando de activación detecta el método de transporte compatible de la instancia de Filestore.

El daemon mountd primero intenta usar UDP, que Filestore no admite. Una vez que se agota el tiempo de espera inicial, vuelve al TCP. Para omitir este proceso de descubrimiento y eliminar la latencia agregada, puedes especificar la opción de activación tcp, por ejemplo:

sudo mount -o tcp 10.0.0.2:/vol1 /mnt/nfs

Esto es muy importante si realizas una automatización con autofs.

Filestore no responde

La instancia de Filestore no responde a las solicitudes ping o traceroute

Las instancias de Filestore no responden a las solicitudes ping o traceroute porque Filestore no permite ICMP.

Para probar la conectividad a una instancia de Filestore, puedes ejecutar showmount desde el cliente:

sudo showmount -e filestore-ip

La instancia de Filestore responde con su sistema de archivos exportado, por ejemplo:

Export list for 10.139.19.98:
/vol1 192.168.0.0/16,172.16.0.0/12,10.0.0.0/8

También puedes verificar si el cliente puede acceder a la información de RPC de Filestore si ejecutas lo siguiente:

sudo rpcinfo -p <filestore-ip>

La respuesta es similar a la siguiente:

program vers proto   port  service
 100000    4   tcp    111  portmapper
 100000    3   tcp    111  portmapper
 100000    2   tcp    111  portmapper
 100000    4   udp    111  portmapper
 100000    3   udp    111  portmapper
 100000    2   udp    111  portmapper
 100024    1   udp   2046  status
 100024    1   tcp   2046  status
 100003    3   tcp   2049  nfs
 100227    3   tcp   2049
 100021    1   udp   4045  nlockmgr
 100021    3   udp   4045  nlockmgr
 100021    4   udp   4045  nlockmgr
 100021    1   tcp   4045  nlockmgr
 100021    3   tcp   4045  nlockmgr
 100021    4   tcp   4045  nlockmgr
 100005    3   udp   2050  mountd
 100005    3   tcp   2050  mountd

Mantenimiento programado

Si Filestore no responde por unos minutos y, luego, vuelve a responder, es probable que el período de respuesta no sea la causa de un evento de mantenimiento programado. Para obtener información sobre el ANS de Filestore, consulta la página de ANS.

Filestore no admite períodos de mantenimiento definidos por el cliente. El programa de períodos de mantenimiento de Filestore tampoco está disponible para los clientes.

Se borró la instancia mientras se activaba en el cliente

Si una operación de archivo o un comando de Unix, como df, ls o cualquier operación de lectura o escritura deja de responder, es probable que la instancia de Filestore se haya borrado mientras estaba montada en el cliente.

Verifica si la instancia aún existe:

    gcloud filestore instances list

Si la instancia ya no aparece en la lista, puedes recuperar el control mediante la creación de una instancia nueva con la misma dirección IP y el mismo nombre de archivo compartido que la instancia que se borró. Una vez que se crea la instancia, la operación que no responde cierra con un error. Puedes desactivar el uso compartido de archivos y borrar la instancia de Filestore si no es necesaria.

Para evitar que esto suceda en el futuro, asegúrate de desactivar la instancia de Filestore antes de borrarla.

La instancia muestra el estado REPAIRING

La instancia de Filestore se encuentra en mal estado de las causas internas más allá del control del usuario y se repara de forma automática. La instancia no estará disponible durante este tiempo y no necesitas realizar ninguna otra acción.

Problemas de capacidad

“No queda espacio en el dispositivo”

  1. Ejecuta el siguiente comando en la VM cliente para verificar si hay suficientes inodos en la instancia de Filestore:

    df -i
    

    El comando muestra un resultado similar al siguiente:

    Filesystem           Inodes        IUsed      IFree         IUse%  Mounted on
    10.0.0.2:/vol1    134217728        13         134217715     1%     /mnt/test
    

    Cada archivo almacenado en el recurso compartido de archivos consume un inodo. Si el IUse% está en el 100%, significa que no hay inodes disponibles y no puedes almacenar más archivos en el sistema de archivos compartidos, incluso si no alcanzaste la capacidad máxima asignada. La cantidad de inodos escala según la capacidad. Si deseas agregar más nodos, debes agregar más capacidad.

  2. Si aún te quedan nodos, es posible que hayas alcanzado la cantidad máxima de entradas (ya sean archivos o subdirectorios) de un directorio. La cantidad máxima de entradas que puedes tener en un directorio depende de las longitudes de nombres de esas entradas. Sin embargo, alcanzar este límite es una probabilidad en lugar de un límite estricto. Para solucionar este problema, tendrás que crear una jerarquía de archivos más profunda mediante la distribución de las entradas en subdirectorios.

Los comandos 'df' y 'du' informan cantidades diferentes de espacio libre en el disco

Cuando se borra un archivo abierto por un proceso en ejecución, el espacio en disco que consume el archivo no se libera hasta que se cierra el archivo. Los comandos df consideran el espacio que consumen los archivos abiertos borrados, mientras que el comando du no. Por eso, el comando du a menudo muestra más espacio libre que df.

Para mostrar los archivos borrados que aún están abiertos por un proceso en ejecución, ejecuta el siguiente comando:

lsof | grep deleted

No se pudo crear una instancia

PERMISSION DENIED cuando se crea una instancia de Filestore

  1. Verifica si la API de Filestore está habilitada:

    gcloud services enable file.googleapis.com
    
  2. Verifica si tienes la función roles/file.editor. Para obtener más detalles, consulta Funciones y permisos de IAM.

  3. Si aún encuentras el error, es posible que se haya quitado la función file.serviceAgent a la cuenta de servicio de Filestore. Para verificar esto, ejecuta el siguiente comando:

    gcloud projects get-iam-policy project-name  \
        --flatten="bindings[].members" \
        --format='table(bindings.role)' \
        --filter="bindings.members:service-project-id@cloud-filer.iam.gserviceaccount.com"
    

    Donde:

    • project-name es el nombre del proyecto de Google Cloud.
    • project-id es el número de ID de tu proyecto de Google Cloud.

    El comando debería mostrar algo similar a lo siguiente:

    ROLE
    roles/file.serviceAgent
    

    Si roles/file.serviceAgent no aparece en la lista, puedes restablecerlo si ejecutas lo siguiente:

    gcloud projects add-iam-policy-binding project-id --member serviceAccount:service-project-id@cloud-filer.iam.gserviceaccount.com --role roles/file.serviceAgent
    

    En el ejemplo anterior, project-id es el número de ID de tu proyecto de Google Cloud.

Recibes un código de error 13 cuando creas una instancia

Existen algunas causas posibles de los errores del código de error 13 durante la creación de la instancia, pero la causa más común es Filestore que llega a una cuota de red interna.

En cada red de VPC en la que crees una instancia de Filestore, Filestore debe crear una red interna que intercambie tráfico con esa red. Estas redes internas se conservan incluso cuando se borran las instancias de Filestore y las redes de VPC asociadas a ellas.

Una vez que la cantidad de redes internas alcanza 49 para un proyecto, Filestore ya no puede crear redes internas nuevas, lo que te impide crear instancias de Filestore en redes de VPC nuevas. Intentar hacerlo da como resultado un error.

Error code 13, message: an internal error has occurred

La única forma de borrar las redes internas es inhabilitar y, luego, volver a habilitar la API de Filestore. Antes de inhabilitar la API, debes borrar todos los recursos relacionados con Filestore, como las instancias de Filestore y las copias de seguridad.

gcloud services disable file.googleapis.com

gcloud services enable file.googleapis.com

Si esto no es posible debido a que tienes instancias de Filestore que necesitas y no puedes borrar, debes comunicarte con tu representante de cuenta para que las redes con intercambio de tráfico se borren de forma manual.

Si necesitas borrar y crear redes de VPC y, también, instancias de Filestore con regularidad, hay dos formas de evitar que te quedes sin cuota de red:

  • Cuando crees una red de VPC, usa el mismo nombre que la red anterior que se usó para crear la instancia de Filestore.

  • Ciclo a través de un grupo de más de 49 redes de VPC en lugar de borrarlas y volver a crearlas.

No se pueden activar los archivos compartidos

Mi VM o pod de GKE no puede acceder a Filestore

Ejecuta lo siguiente para confirmar si se puede acceder a la instancia de Filestore (ping y traceroute).

sudo showmount -e <filestore-ip>

El comando debe responder con una lista de los sistemas de archivos exportados. Luego, ejecuta lo siguiente para comprobar si el cliente puede acceder a la información de RPC de Filestore:

sudo rpcinfo -p <filestore-ip>

Si no se puede acceder a la instancia de Filestore, las causas comunes incluyen una configuración de red mal configurada o una configuración de LCA, o si se intenta activar la instancia incorrecta.

  1. Verifica si el control de acceso basado en IP está habilitado y verifica si la dirección IP del cliente está restringida. Puedes obtener más detalles aquí.
  2. Verifica la configuración del firewall para asegurarte de que los puertos requeridos estén abiertos. Para obtener más información, consulta Configura reglas de firewall.
  3. Si intentas acceder a Filestore desde un clúster de GKE y obtienes el error mount.nfs: access denied by server while mounting ..., consulta No se puede acceder a los archivos compartidos desde los clústeres de GKE.

Permiso denegado cuando intentas activar un archivo compartido

Confirma si hay opciones de exportación de NFS para la instancia:

gcloud filestore instances describe instance-id \
    --zone=zone

Donde:

  • instance-id es el ID de la instancia de Filestore.
  • zone es la zona en la que se encuentra la instancia de Filestore.

El comando muestra algo similar a lo siguiente:

createTime: '2019-10-11T17:28:23.340943077Z'
fileShares:
- capacityGb: '1024'
  name: vol1
  nfsExportOptions:
  - accessMode: READ_WRITE
    ipRanges:
    - 128.0.0.0/29
    squashMode: NO_ROOT_SQUASH
name: projects/yourproject/locations/us-central1-c/instances/nfs-server
networks:
- ipAddresses:
  - 10.0.0.2
  modes:
  - MODE_IPV4
  network: default
  reservedIpRange: 10.0.0.0/29
state: READY
tier: BASIC_HDD

Si encuentras nfsExportOptions en la lista, verifica si la dirección IP de tu cliente está dentro de uno de los rangos enumerados en ipRanges para el accessMode esperado. Si no lo es, debes editar las opciones de exportación de NFS. Si deseas obtener instrucciones para hacer esto, consulta Edita instancias.

No se puede activar un archivo compartido en App Engine

Filestore no es compatible con App Engine.

No se puede activar un archivo compartido de un clúster de GKE

No puedes activar de forma directa archivos compartidos de Filestore en clústeres de GKE. En su lugar, debes configurar un PV y un PVC.

No se puede acceder a archivos compartidos desde los clústeres de GKE

Para obtener más información sobre la solución de problemas relacionada con Kubernetes o Google Kubernetes Engine, puedes consultar elGuía de solución de problemas de Kubernetes yGuía de solución de problemas de GKE las rutas "a GCP".

Error: Resultado: mount.nfs: Acceso denegado por el servidor al activar xxxx:/file-share-name

Asegúrate de que los valores de spec.nfs.path y spec.nfs.server del PV coincidan con el nombre del archivo compartido y la dirección IP de la instancia de Filestore, respectivamente.

Ejemplo:

Si tu archivo compartido se llama vol1 y la dirección IP de la instancia de Filestore es 10.0.0.2, el PV spec.nfs.path y spec.nfs.server deben coincidir con esos valores:

apiVersion: v1
kind: PersistentVolume
metadata:
 name: fileserver
spec:
 capacity:
   storage: 2T
 accessModes:
 - ReadWriteMany
 nfs:
   path: /vol1
   server: 10.0.0.2

No se puede inhabilitar la API de Filestore

Asegúrate de que se borren todos los recursos relacionados con Filestore, como las instancias y las copias de seguridad de Filestore. No puedes inhabilitar la API de Filestore mientras se implementan las instancias de Filestore.