Solução de problemas

Esta página mostra etapas de solução de problemas que podem ser úteis em caso de problemas ao usar o Filestore.

Baixo desempenho

  1. Verifique se você está usando o tipo de máquina recomendado para a VM cliente.

  2. Se sua VM de cliente estiver executando o Linux, verifique se você está usando as opções de ativação padrão.

  3. Verifique se a VM cliente está localizada na mesma região que a instância do Filestore. A ativação entre regiões não apenas reduz o desempenho, como também gera um custo de rede.

  4. Certifique-se de que sua instância do Filestore não esteja atingindo ou perto de atingir a capacidade total. Quando a capacidade estiver quase cheia, qualquer espaço restante será altamente fragmentado, causando lentidão nas operações de leitura e gravação. A quantidade de espaço livre necessária para evitar esse cenário depende do caso. Recomendamos que você configure alertas de pouco espaço em disco.

  5. Teste o desempenho da instância do Filestore usando a ferramenta fio.

    Se os resultados do teste apresentarem um desempenho lento fora do normal, entre em contato com seu representante da conta. Se os resultados do teste apresentarem um desempenho semelhante ou superior ao esperado, prossiga para a próxima seção.

Casos de uso que provocam desempenho lento

Veja abaixo alguns casos de uso e cenários que causam baixo desempenho:

Cargas de trabalho que envolvem grandes volumes de arquivos pequenos

Os compartilhamentos de arquivos do Filestore usam a opção de exportação sync para segurança de dados e conformidade com o protocolo NFS. Para a maioria das operações de modificação de dados, a instância do Filestore espera que os dados sejam confirmados para armazenamento antes de responder às solicitações da VM do cliente. Quando uma operação envolve muitos arquivos, o cliente faz uma longa série de operações síncronas, e a latência cumulativa aumenta.

Um exemplo desse cenário é quando você extrai um arquivo do compartilhamento de arquivos, como arquivos .tar. O TAR faz muitas operações síncronas em série ao extrair um arquivo que contém muitos arquivos. Como resultado, o desempenho é reduzido.

Se você estiver tentando copiar muitos arquivos pequenos para um compartilhamento de arquivos, tente criar os arquivos em paralelo com uma ferramenta como gsutil:

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

Como copiar dados entre o Cloud Storage e o Filestore

Sabe-se até o momento que a cópia de dados do Cloud Storage para uma instância do Filestore usando o gsutil é lenta. Não há mitigação conhecida.

Latência ao montar e desconectar um compartilhamento de arquivos

Ao montar um compartilhamento de arquivos usando as opções de montagem padrão, o comando de montagem tenta descobrir o método de transporte compatível com a instância do Filestore, que apresenta uma latência de três segundos.

O daemon mountd primeiro tenta usar o UDP, o que não é compatível com o Filestore. Quando a tentativa inicial expirar, ela voltará para o TCP. Para ignorar esse processo de descoberta e eliminar a latência adicionada, especifique a opção de ativação tcp, por exemplo:

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

Essa opção de ativação é importante principalmente na ativação automática com autofs.

O Filestore não responde

A instância do Filestore não responde a solicitações ping ou traceroute

As instâncias do Filestore não respondem a solicitações ping ou traceroute porque o Filestore não permite ICMP.

Para testar a conectividade com uma instância do Filestore, execute showmount no cliente:

sudo showmount -e filestore-ip

A instância do Filestore responde com o sistema de arquivos exportado, por exemplo:

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

Para verificar se o cliente pode acessar as informações de RPC do Filestore, execute:

sudo rpcinfo -p <filestore-ip>

A resposta é semelhante ao exemplo a seguir:

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

Manutenção programada

De vez em quando, o Filestore fica sem resposta por alguns minutos e voltar a responder por causa de um evento de manutenção programado. Com relação ao SLA do Filestore, consulte a página do SLA.

O Filestore não é compatível com janelas de manutenção definidas pelo cliente. A programação de janelas de manutenção do Filestore também não está disponível para os clientes.

A instância foi excluída enquanto ainda está ativada no cliente

Se uma operação de arquivo ou um comando Unix, como df, ls ou qualquer operação de leitura/gravação parar de responder, a instância do Filestore provavelmente foi excluída enquanto ainda está ativada no cliente.

Verifique se a instância ainda existe:

    gcloud filestore instances list

Se a instância não estiver mais listada, recupere o controle criando uma nova instância com o mesmo endereço IP e nome de compartilhamento de arquivo da instância que foi excluída. Depois de criá-la, a operação que não responde sai com um erro. Se você não precisar da instância do Filestore, poderá desmontar o compartilhamento de arquivos e excluí-lo.

Para evitar que isso se repita mais pra frente, desative a instância do Filestore antes de excluí-la.

A instância mostra o status REPAIRING

O estado da instância do Filestore não é íntegro por motivos internos fora do controle do usuário, e ela está se reparando automaticamente. A instância fica indisponível durante esse período, e você não precisa fazer mais nada.

Problemas de capacidade

"Não há espaço livre no dispositivo"

Verifique se a instância do Filestore tem inodes suficientes executando o seguinte comando na VM cliente:

df -i

O comando retorna algo semelhante ao seguinte:

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

Cada arquivo armazenado no compartilhamento de arquivos consome um inode. Se IUse% atingir 100%, não será possível armazenar mais arquivos no compartilhamento de arquivos, mesmo que você não tenha atingido a capacidade máxima alocada. O número de inodes é escalonado de acordo com a capacidade. Para incluir mais nós, aumente a capacidade.

Os comandos "df" e "du" informam quantidades diferentes de espaço livre em disco

Quando um arquivo aberto por um processo em execução é excluído, o espaço em disco que o arquivo consome não é liberado até o arquivo ser fechado. Os comandos df consideram o espaço consumido pelos arquivos abertos excluídos, mas o comando du não. Essa diferença no cálculo é por que o comando du geralmente mostra mais espaço livre que df.

Para exibir os arquivos excluídos que ainda estão abertos por um processo em execução, faça o seguinte:

lsof | grep deleted

Não foi possível criar uma instância

PERMISSION DENIED ao criar uma instância do Filestore

  1. Verifique se a API do Filestore está ativada:

    gcloud services enable file.googleapis.com

  2. Verifique se você tem o papel de roles/file.editor. Para detalhes, consulte Papéis e permissões do IAM.

  3. Se o erro ainda aparecer, o papel file.serviceAgent da conta de serviço do Filestore pode ter sido removido. Faça isto para verificar se esse é o caso:

    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"

    onde:

    • project-id-or-number é o número do ID do projeto do Google Cloud.
    • project-number é o número do seu projeto do Google Cloud;

    O comando retornará algo semelhante ao seguinte:

    ROLE
roles/file.serviceAgent

    Se roles/file.serviceAgent não estiver listado, restaure-o executando o seguinte:

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

System limit for internal resources has been reached ao criar uma instância

Esse erro é causado quando o Filestore atinge uma cota de rede interna. Em cada rede VPC que você cria uma instância do Filestore, o Filestore precisa criar uma rede interna que esteja em peering com essa rede. Essas redes internas são preservadas mesmo quando as instâncias do Filestore e as redes VPC associadas a elas são excluídas.

Quando o número de redes internas atinge 50 para um projeto, o Filestore não pode mais criar novas redes internas, o que impede a criação de instâncias do Filestore em novas redes VPC. A tentativa de fazer isso resultará em um dos seguintes erros:

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

É possível limpar as redes internas desativando e, em seguida, reativando a API Filestore:

gcloud services disable file.googleapis.com

gcloud services enable file.googleapis.com

Se não for possível desativar a API porque você tem instâncias do Filestore que não podem ser excluídas ou não quer perder a cota concedida por meio de solicitações de aumento de cota, preencha o seguinte formulário para ajustar os limites de rede:

https://forms.gle/PFPJ2QD4KnCHzYEx9

Se você precisa excluir e criar regularmente redes VPC e instâncias do Filestore, há duas maneiras de evitar o esgotamento da cota de rede:

  • Ao criar uma rede VPC, use o mesmo nome de uma rede anterior que foi usada na criação de instâncias do Filestore.

  • Percorra um pool de, no máximo, 49 redes VPC em vez de excluí-las e recriá-las.

Não foi possível ativar o compartilhamento de arquivos

Minha VM ou conjunto do GKE não pode acessar o Filestore

Confirme se a instância do Filestore pode ser acessada (ping e traceroute não são compatíveis) executando:

sudo showmount -e <filestore-ip>

O comando responderá com uma lista de sistemas de arquivos exportados. Em seguida, verifique se o cliente pode acessar as informações de RPC do Filestore executando:

sudo rpcinfo -p <filestore-ip>

Se a instância do Filestore não estiver acessível, as causas comuns incluem configurações de rede ou de ACL incorretas, ou você está tentando ativar a instância errada.

  1. Verifique se o controle de acesso baseado em IP está ativado e se o endereço IP do cliente é restrito. Os detalhes estão disponíveis aqui.
  2. Verifique as configurações do firewall para confirmar que as portas necessárias estão abertas. Para detalhes, consulte Como configurar regras de firewall.
  3. Se você estiver tentando acessar o Filestore de um cluster do GKE e receber o erro mount.nfs: access denied by server while mounting ..., consulte Não é possível acessar o compartilhamento de arquivos dos clusters do GKE.

Permissão negada ao tentar ativar um compartilhamento de arquivos

Verifique se há opções de exportação do NFS listadas para a instância:

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

onde:

  • instance-id é o ID de instância do Filestore;
  • zone é a zona em que a instância do Filestore reside.

O comando retorna algo semelhante a:

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

Se você encontrar nfsExportOptions listado, verifique se o endereço IP do seu cliente está dentro de um dos intervalos listados em ipRanges para o accessMode esperado. Se não estiver, edite as opções de exportação do NFS.

Não foi possível ativar o compartilhamento de arquivos no App Engine

O Filestore não é compatível com o App Engine.

Não é possível ativar um compartilhamento de arquivos de um cluster do GKE

Não é possível ativar diretamente os compartilhamentos de arquivos do Filestore em clusters do GKE. Em vez disso, configure um PV e um PVC.

Não é possível acessar o compartilhamento de arquivos dos clusters do GKE

Para mais informações sobre solução de problemas relacionadas ao Kubernetes ou ao Google Kubernetes Engine, consulte também o Guia de solução de problemas do Kubernetes oficial e o Guia de solução de problemas do GKE.

Erro: saída: mount.nfs: acesso negado pelo servidor ao ativar x.x.x.x:/file-share-name

Verifique se os valores spec.nfs.path e spec.nfs.server do PV correspondem ao nome do compartilhamento de arquivos e ao endereço IP da instância do Filestore, respectivamente.

Exemplo:

Se o compartilhamento de arquivos for chamado vol1 e o endereço IP da instância do Filestore for 10.0.0.2, o spec.nfs.path e spec.nfs.server do PV precisam corresponder a estes valores:

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

A API Filestore não pode ser desativada

Verifique se todos os recursos relacionados ao Filestore, como instâncias e backups, foram excluídos. Não é possível desativar a API Filestore enquanto as instâncias do Filestore estão implantadas.

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

Se você esgotar o espaço de endereços IP alocado de uma determinada conexão particular, o Google Cloud retornará este erro: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges.

Para detalhes de como resolver esse problema, consulte Intervalo de endereços IP esgotado.