Soluciona problemas

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

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 la instancia de Filestore no esté al máximo o cerca de su máxima capacidad. Cuando la capacidad está casi llena, cualquier espacio restante está muy fragmentado, lo que hace que las operaciones de lectura y escritura disminuyan. La cantidad de espacio libre necesario para evitar esta situación depende del caso. Recomendamos configurar alertas de poco espacio en 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 al almacenamiento antes de responder las solicitudes desde la VM de cliente. Cuando varios 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 esta situación es cuando extraes un archivo de los archivos compartidos, como 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 varios 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

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

Cuando se activa 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 ingresa 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 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 puede verificar si el cliente puede acceder a la información de RPC de Filestore si ejecutas el 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 responder debido a 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. Si no necesitas la instancia de Filestore, puedes desactivar el archivo compartido y borrarla.

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 por causas internas más allá del control del usuario y se repara automáticamente. La instancia no estará disponible durante este tiempo, y no deberás realizar 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 recurso compartido de archivos, 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.

Las instancias de nivel SSD de nivel empresarial y de escala masiva tienen aproximadamente el uso de la capacidad de alrededor del 89% de la capacidad aprovisionada. La capacidad restante se reserva para los recursos y las operaciones internas. Para obtener más detalles, consulta Problemas conocidos.

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

Cuando se borra un archivo que está abierto por un proceso en ejecución, el espacio en disco que consume no se libera hasta que se cierra el archivo. Los comandos df representan el espacio que consumen los archivos abiertos borrados, mientras que el comando du no. Esta diferencia en el cálculo es por qué el comando du a menudo muestra más espacio libre que df.

Para mostrar los archivos borrados que todavía están abiertos por 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. Cada instancia de Filestore debe tener un rango de direcciones IP asociado que no se superponga con otro rango en uso. Para obtener una lista detallada de las restricciones, consulta Configura un rango de direcciones IP reservadas.

  3. Verifica si tienes la función roles/file.editor. Para obtener más detalles, consulta Funciones y permisos de IAM.

  4. 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 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 número de tu 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
    

Error de System limit for internal resources has been reached cuando se crea una instancia

Este error se debe a que Filestore alcanza una cuota de red interna. Para cada red de VPC en la que creas una instancia de Filestore, este 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 llega a 49 para un proyecto, Filestore no puede crear nuevas redes internas, lo que evita que crees instancias de Filestore en redes de VPC nuevas. Si intenta hacerlo, se generará uno de los siguientes errores:

System limit for internal resources has been reached. Please request to adjust limit here: https://forms.gle/PFPJ2QD4KnCHzYEx9

Puedes borrar las redes internas si inhabilitas y vuelves a habilitar la API 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 no puedes borrar o porque no quieres perder la cuota que se te otorgó mediante solicitudes de aumento de cuota, puedes completar el siguiente formulario para que se ajusten los límites de tu red:

https://forms.gle/PFPJ2QD4KnCHzYEx9

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, luego, volver a crearlas.

No se pueden activar los archivos compartidos

Mi VM o Pod de GKE no pueden acceder a Filestore

Confirma si se puede acceder a la instancia de Filestore (no se admiten ping y traceroute):

sudo showmount -e <filestore-ip>

El comando debería responder con una lista de sistemas de archivos exportados. Luego, ejecuta el siguiente comando para verificar 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 la configuración de red o una configuración incorrecta de LCA, o intentes 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 encontrar los detalles aquí.
  2. Verifica la configuración de tu 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 al archivo compartido 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.

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 directamente archivos compartidos de Filestore 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 información sobre la solución de problemas relacionados con Kubernetes o Google Kubernetes Engine, también puedes consultar la Guía oficial de solución de problemas de Kubernetes y la Guía de solución de problemas de GKE.

Error: Output: mount.nfs: access denied by server while mounting x.x.x.x:/file-share-name

Asegúrate de que los valores del 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

La API de Filestore no se puede inhabilitar

Asegúrese de que se borren todos los recursos relacionados con Filestore, como las instancias y las copias de seguridad de Filestore. No puede 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.

Si deseas obtener detalles para resolver este problema, consulta Agotamiento del rango de direcciones IP.