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. Verifique se a instância do Filestore não está perto da capacidade total. Quando a capacidade estiver quase cheia, qualquer espaço restante será altamente fragmentado, desacelerando as operações de leitura e gravação. A quantidade de espaço livre necessária para evitar esse cenário depende de maiúsculas e minúsculas. 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 a solicitações da VM cliente. Quando muitos arquivos estão envolvidos em uma operação, o cliente faz uma longa série de operações síncronas, e a latência cumulativa se acumula.

Um exemplo desse cenário é quando você extrai um arquivo no compartilhamento de arquivos, como arquivos .tar. A TAR faz muitas operações síncronas em uma 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, carregue em paralelo a criação de arquivos 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

Copiar dados do Cloud Storage para uma instância do Filestore usando o gsutil é conhecido por ser lento. 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 ativação padrão, o comando de ativação tenta descobrir o método de transporte compatível com a instância do Filestore, que introduz 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 montagem é especialmente importante se você estiver montando automaticamente 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

Também é possível verificar se o cliente pode acessar as informações de RPC do Filestore, executando:

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 deixa de responder por alguns minutos e depois responde novamente por causa de um evento de manutenção programado. Para o SLA do Filestore, consulte a página 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 precisa da instância do Filestore, desmonte o compartilhamento de arquivos e exclua-o.

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.

A instância do Filestore está em um estado não íntegro por causa de causas internas além do controle do usuário e está se reparando automaticamente. A instância permanece indisponível durante esse período e não é necessário realizar outras ações.

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 com a capacidade. Se você quiser adicionar mais inodes, inclua mais capacidade.

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

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

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

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 persistir, então a conta de serviço do Filestore poderá ter o papel file.serviceAgent removido. Para verificar se esse é o caso, execute:

    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 ID ou o número do projeto do Google Cloud.
    • project-number é o número do 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
    

Como receber um código de erro 13 ao criar uma instância

Há algumas causas possíveis para erros de código de erro 13 durante a criação da instância, mas a causa mais comum é o Filestore atingir uma cota de rede interna.

Para cada rede VPC em que você cria uma instância do Filestore, o Filestore precisa criar uma rede interna que faça 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 alcança 49 em um projeto, o Filestore não consegue 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 erro:

Error code 13, message: an internal error has occurred

A única maneira de limpar as redes internas é desativar e reativar a API Filestore. Antes de desativar a API, é necessário excluir todos os recursos relacionados ao Filestore, como instâncias e backups do 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 precisam ou não podem ser excluídas, entre em contato com o representante da conta para que as redes com peering sejam apagadas manualmente.

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 com até 49 redes VPC em vez de excluir e recriá-las.

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

Minha VM ou pod do GKE não conseguem acessar o Filestore

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

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 configurações de ACL configuradas incorretamente ou a tentativa de montar a instância errada.

  1. Verifique se o controle de acesso baseado em IP está ativado e se o endereço IP do cliente está restrito. Veja os detalhes aqui.
  2. Verifique as configurações do firewall para ver se as portas necessárias estão abertas. Para detalhes, consulte Como configurar regras de firewall.
  3. Se você estiver tentando acessar o Filestore a partir de um cluster do GKE e receber o erro mount.nfs: access denied by server while mounting ..., consulte Não foi 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. Caso contrário, 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 foi possível acessar o compartilhamento de arquivos dos clusters do GKE

Para mais informações sobre solução de problemas do Kubernetes ou do Google Kubernetes Engine, consulte o diretório oficial Guia de solução de problemas do Kubernetes e Guia de solução de problemas do GKE ,

Erro: resultado: mount.nfs: acesso negado pelo servidor durante a ativação de xxxx:/file-share-name

Verifique se os valores de PV spec.nfs.path e spec.nfs.server 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 nomeado vol1 e o endereço IP da instância do Filestore for 10.0.0.2, o PV spec.nfs.path e spec.nfs.server precisarão corresponder a esses valores:

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

Não é possível desativar a API Filestore

Exclua todos os recursos relacionados ao Filestore, como instâncias e backups do Filestore. Não é possível desativar a API do Filestore enquanto as instâncias do Filestore forem 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á o seguinte erro: Failed to create subnetwork. Couldn't find free blocks in allocated IP ranges.

Para detalhes sobre como resolver esse problema, consulte Exaustão do intervalo de endereços IP.