Esta página mostra etapas de solução de problemas que podem ser úteis em caso de problemas ao usar o Filestore.
Baixo desempenho
- Verifique se você está usando o tipo de máquina recomendado para a VM cliente.
Se sua VM de cliente estiver executando o Linux, verifique se você está usando as opções de ativação padrão.
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.
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.
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
Verifique se a API do Filestore está ativada:
gcloud services enable file.googleapis.com
Verifique se você tem o papel de
roles/file.editor
. Para detalhes, consulte Papéis e permissões do IAM.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.
- 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.
- Verifique as configurações do firewall para confirmar que as portas necessárias estão abertas. Para detalhes, consulte Como configurar regras de firewall.
- 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.