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é a plena capacidad o no cerca de ella. Cuando la capacidad está casi llena, cualquier espacio restante está muy fragmentado, lo que hace que las operaciones de lectura y escritura se ralenticen. La cantidad de espacio libre necesaria para evitar esta situación depende del caso. Te recomendamos que configures 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. Para la mayoría de las operaciones de modificación de datos, la instancia de Filestore espera a que los datos se confirmen en el almacenamiento antes de responder a las solicitudes de la VM cliente. Cuando hay muchos archivos involucrados en una operación, el cliente realiza una serie larga de operaciones síncronas y la latencia acumulada se acumula.

Un ejemplo de esta situación es cuando extraes un archivo en el recurso compartido de archivos, como los archivos tar. TAR realiza muchas operaciones síncronas en una serie cuando se extrae un archivo que contiene muchos archivos. Como resultado, el rendimiento se reduce.

Si intentas copiar muchos archivos pequeños en un archivo compartido, 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 copiar datos de Cloud Storage a una instancia de Filestore mediante gsutil es lento. No hay una mitigación conocida.

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

Cuando activas un archivo compartido mediante las opciones de activación predeterminadas, el comando de activación intenta descubrir el método de transporte compatible de la instancia de Filestore, que genera una latencia de tres segundos.

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

Esta opción de activación es importante en particular si quieres activar automáticamente 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 mediante la ejecución del siguiente comando:

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

De vez en cuando, Filestore deja de responder por unos minutos y vuelve a hacerlo debido a un evento de mantenimiento programado. Para el ANS de Filestore, consulta la página del 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. Si no necesitas la instancia de Filestore, puedes desactivar el archivo compartido y borrarlo.

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 debido a causas internas que exceden el control del usuario. Además, se está reparando automáticamente. La instancia no está disponible durante este tiempo y no es necesario que realices ninguna otra acción.

Problemas de capacidad

“No queda espacio en el dispositivo”

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 IUse% alcanza el 100%, no podrás almacenar más archivos en el archivo compartido, incluso si no alcanzaste la capacidad máxima asignada. La cantidad de inodo escala con capacidad. Si deseas agregar más inodo, debes agregar más capacidad.

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

Cuando se borra un archivo que está abierto mediante un proceso en ejecución, el espacio en disco que consume no se libera hasta que se cierra el archivo. Los comandos df tienen en cuenta el espacio que consumen los archivos abiertos borrados, mientras que el comando du no. Esta diferencia de cálculo es la razón por la que el comando du suele mostrar más espacio libre que df.

Para mostrar los archivos borrados que se encuentran abiertos mediante un proceso en ejecución, ejecuta lo siguiente:

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 todavía experimentas el error, es posible que se haya quitado la función file.serviceAgent a la cuenta de servicio de Filestore. Para comprobar si este es el caso, ejecuta el siguiente comando:

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

    Donde:

    • project-id-or-number es el ID o el número del proyecto de Google Cloud.
    • project-number es el número 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-or-number  \
        --member serviceAccount:service-project-number@cloud-filer.iam.gserviceaccount.com  \
        --role roles/file.serviceAgent
    

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.

Para cada red de VPC en la que creas una instancia de Filestore, Filestore debe crear una red interna que realice un intercambio de 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 el número de redes internas alcanza 49 para un proyecto, Filestore ya no puede crear redes internas nuevas, lo que evita que crees 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 volver a habilitar la API de Filestore. Antes de inhabilitar la API, debes borrar todos los recursos relacionados con Filestore, como las instancias y las copias de seguridad de Filestore.

gcloud services disable file.googleapis.com

gcloud services enable file.googleapis.com

Si no puedes inhabilitar la API porque tienes instancias de Filestore que necesitas y no puedes borrar, debes comunicarte con el representante de tu cuenta para borrar las redes con intercambio de tráfico 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.

  • Recorre un grupo de no más de 49 redes de VPC en lugar de borrarlas y volver a crearlas.

No se pueden activar los archivos compartidos

Mi pod de VM o GKE no puede acceder a Filestore

Para confirmar si se puede acceder a la instancia de Filestore (ping y traceroute no son compatibles), ejecuta lo siguiente:

sudo showmount -e <filestore-ip>

El comando debería responder con una lista de sistemas de archivos exportados. Luego, verifica si el cliente puede acceder a la información de RPC de Filestore mediante la ejecución del siguiente comando:

sudo rpcinfo -p <filestore-ip>

Si no se puede acceder a la instancia de Filestore, las causas comunes incluyen una configuración de red o configuración de LCA que no se configuró de forma correcta o que intentas activar la instancia incorrecta.

  1. Verifica si el control de acceso basado en IP está habilitado y si la dirección IP del cliente está restringida. Puedes encontrar los 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 recibes 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 es así, debes editar las opciones de exportación de NFS.

No se puede activar un archivo compartido en App Engine

Filestore no es compatible con App Engine.

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

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

No se puede acceder al archivo compartido 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, también puedes consultar el sitio oficialGuía de solución de problemas de Kubernetes yGuía de solución de problemas de GKE ,

Error: Resultado: mount.nfs: acceso denegado por el servidor mientras se activa xxxx:/file-share-name

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

Ejemplo:

Si el 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.

Error: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges.

En una conexión privada determinada, si agotas el espacio de direcciones IP asignado, Google Cloud muestra este error: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges.

Para obtener detalles sobre cómo resolver este problema, consulta Agotamiento del rango de direcciones IP.