Solução de problemas e problemas conhecidos

Esta página inclui etapas de solução de problemas para alguns erros e problemas comuns.

Problemas conhecidos

  • Quando não há E/S no sistema de arquivos, os gráficos de desempenho mostram a mensagem "Não há dados disponíveis para o período selecionado". Isso ocorre porque as métricas de desempenho são geradas apenas quando há E/S. Para mais informações sobre métricas, consulte Monitorar instâncias e operações.
  • Os seguintes recursos do Lustre não são compatíveis:
    • Compactação de dados do lado do cliente
    • Armazenamento em cache persistente do cliente
  • Alguns comandos do Lustre não são compatíveis.
  • Existem algumas exceções à conformidade com POSIX.

Problemas de operação da instância

As seções a seguir descrevem problemas relacionados a operações de instância.

Não foi possível enfileirar a operação

Se você encontrar um erro semelhante a um dos seguintes ao tentar iniciar uma operação:

ERROR: (gcloud.lustre.instances.import-data) ABORTED: unable to queue the operation
ERROR: (gcloud.lustre.instances.export-data) ABORTED: unable to queue the operation
ERROR: (gcloud.lustre.instances.update) ABORTED: unable to queue the operation

Esse erro ocorre quando você tenta iniciar uma operação enquanto outra operação do mesmo tipo já está em andamento na mesma instância.

  • Importação/exportação:o Lustre gerenciado aceita apenas uma operação de transferência ativa por instância por vez. O enfileiramento não é compatível com operações de transferência.
  • Atualização de instância:o Managed Lustre permite uma atualização ativa por instância por vez e permite que outra operação de atualização seja enfileirada.

Para resolver esse problema, aguarde a conclusão da operação atual antes de iniciar uma nova.

Problemas do Compute Engine

Ao encontrar problemas ao montar um sistema de arquivos Managed Lustre em uma instância do Compute Engine, siga estas etapas para diagnosticar o problema.

Verificar se a instância do Managed Lustre está acessível

Primeiro, verifique se a instância do Managed Lustre pode ser acessada pela instância do Compute Engine:

sudo lctl ping IP_ADDRESS@tcp

Para receber o valor de IP_ADDRESS, consulte Receber uma instância.

Um ping bem-sucedido retorna uma resposta semelhante a esta:

12345-0@lo
12345-10.115.0.3@tcp

Um ping com falha retorna o seguinte:

failed to ping 10.115.0.3@tcp: Input/output error

Se o ping falhar:

  • Verifique se a instância gerenciada do Lustre e a instância do Compute Engine estão na mesma rede VPC. Compare a saída dos seguintes comandos:

    gcloud compute instances describe VM_NAME \
  --zone=VM_ZONE \
  --format='get(networkInterfaces[0].network)'

gcloud lustre instances describe INSTANCE_NAME \
  --location=ZONE --format='get(network)'

    A saída é semelhante a esta:

    https://www.googleapis.com/compute/v1/projects/my-project/global/networks/my-network
projects/my-project/global/networks/my-network

    A saída do comando gcloud compute instances describe tem o prefixo https://www.googleapis.com/compute/v1/. Tudo o que segue essa string precisa corresponder à saída do comando gcloud lustre instances describe.

  • Revise as regras de firewall e as configurações de roteamento da rede VPC para garantir que elas permitam o tráfego entre a instância do Compute Engine e a instância gerenciada do Lustre.

Verificar a porta de aceitação do LNet

As instâncias gerenciadas do Lustre podem ser configuradas para oferecer suporte a clientes do GKE especificando a flag --gke-support-enabled no momento da criação.

Se o suporte do GKE estiver ativado, configure o LNet em todas as instâncias do Compute Engine para usar accept_port 6988. Consulte Configurar LNet para instâncias gke-support-enabled.

Para determinar se a instância foi configurada para oferecer suporte a clientes do GKE, execute o seguinte comando:

gcloud lustre instances describe INSTANCE_NAME \
  --location=LOCATION | grep gkeSupportEnabled

Se o comando retornar gkeSupportEnabled: true, configure a LNet.

Incompatibilidade entre a versão do kernel do Ubuntu e o cliente Lustre

Para instâncias do Compute Engine que executam o Ubuntu, a versão do kernel do Ubuntu precisa corresponder à versão específica dos pacotes do cliente Lustre. Se as ferramentas do cliente Lustre estiverem falhando, verifique se a instância do Compute Engine foi atualizada automaticamente para um kernel mais recente.

Para verificar a versão do kernel:

uname -r

A resposta é semelhante ao exemplo a seguir:

6.8.0-1029-gcp

Para verificar a versão do pacote de cliente do Lustre:

dpkg -l | grep -i lustre

A resposta é semelhante ao exemplo a seguir:

ii  lustre-client-modules-6.8.0-1029-gcp 2.14.0-ddn198-1  amd64  Lustre Linux kernel module (kernel 6.8.0-1029-gcp)
ii  lustre-client-utils                  2.14.0-ddn198-1  amd64  Userspace utilities for the Lustre filesystem (client)

Se houver uma incompatibilidade entre as versões do kernel listadas nos dois comandos, reinstale os pacotes de cliente do Lustre.

Verificar se há erros do Lustre no dmesg

Muitos avisos e erros do Lustre são registrados no buffer de anel do kernel do Linux. O comando dmesg imprime o buffer de anel do kernel.

Para pesquisar mensagens específicas do Lustre, use grep com dmesg:

dmesg | grep -i lustre

Ou, para procurar erros mais gerais que possam estar relacionados:

dmesg | grep -i error

Informações a serem incluídas em uma solicitação de suporte

Se não for possível resolver a falha de montagem, colete informações de diagnóstico antes de criar um caso de suporte.

Execute o sosreport:esse utilitário coleta registros do sistema e informações de configuração e gera um tarball compactado:

sudo sosreport

Anexe o arquivo sosreport e qualquer saída relevante de dmesg ao seu caso de suporte.

Problemas do GKE

Antes de seguir as etapas de solução de problemas nesta seção, consulte as limitações ao se conectar ao Lustre gerenciado do GKE.

Capacidade mínima de instância atualizada

A capacidade mínima das instâncias gerenciadas do Lustre foi atualizada para 9.000 GiB. Para criar instâncias de 9.000 GiB usando o driver CSI do Lustre gerenciado, faça upgrade da versão do cluster para 1.34.0-gke.2285000 ou mais recente.

Nível de desempenho incorreto para instâncias do Lustre provisionadas dinamicamente

Ao provisionar dinamicamente uma instância do Lustre, a criação da instância falha com um erro InvalidArgument para PerUnitStorageThroughput, independente do valor perUnitStorageThroughput especificado na solicitação da API. Isso afeta as versões do GKE 1.33 anteriores à 1.33.4-gke.1036000.

Alternativa:

Faça upgrade do cluster do GKE para a versão 1.33.4-gke.1036000 ou mais recente. Se você estiver usando o canal estável, talvez uma versão mais recente ainda não esteja disponível. Nesse caso, selecione manualmente uma versão dos canais Regular ou Rápido que inclua a correção.

Portas de comunicação do Managed Lustre

O driver CSI do Managed Lustre usa portas diferentes para comunicação com instâncias do Managed Lustre, dependendo da versão do cluster do GKE e das configurações do Managed Lustre.

  • Porta padrão (988): para novos clusters do GKE que executam a versão 1.33.2-gke.4780000 ou mais recente, o driver usa a porta 988 para comunicação do Lustre por padrão.

  • Porta legada (6988): o driver usa a porta 6988 nos seguintes cenários:

    • Versões anteriores do GKE:se o cluster do GKE executar uma versão anterior a 1.33.2-gke.4780000, a flag --enable-legacy-lustre-port será necessária ao ativar o driver CSI. Ativar essa flag contorna um conflito de porta com o gke-metadata-server em nós do GKE.
    • Instâncias gerenciadas do Lustre com suporte do GKE:se você estiver se conectando a uma instância gerenciada do Lustre criada com a flag --gke-support-enabled, inclua --enable-legacy-lustre-port ao ativar o driver CSI, independente da versão do cluster. Sem essa flag, o cluster do GKE não vai montar a instância do Lustre.

    Para mais detalhes sobre como ativar o driver CSI com a porta legada, consulte Portas de comunicação do Lustre.

Consultas de registros

Para verificar os registros, execute a seguinte consulta no Explorador de registros.

Para retornar os registros do servidor de nós do driver CSI do Lustre gerenciado:

resource.type="k8s_container"
resource.labels.pod_name=~"lustre-csi-node*"

Resolver problemas de provisionamento de volume

Se o PersistentVolumeClaim (PVC) permanecer no estado Pending e nenhum PersistentVolume (PV) for criado após 20 a 30 minutos, talvez tenha ocorrido um erro.

  1. Verifique os eventos do PVC:

    kubectl describe pvc PVC_NAME

  2. Se o erro indicar problemas de configuração ou argumentos inválidos, verifique os parâmetros StorageClass.

  3. Recrie a PVC.

  4. Se o problema persistir, entre em contato com o Cloud Customer Care.

Resolver problemas de montagem de volume

Depois que o pod é programado para um nó, o volume é montado. Se isso falhar, verifique os eventos do pod e os registros do kubelet.

kubectl describe pod POD_NAME

Problemas de ativação do driver CSI

Sintoma:

MountVolume.MountDevice failed for volume "yyy" : kubernetes.io/csi: attacher.MountDevice failed to create newCsiDriverClient: driver name lustre.csi.storage.gke.io not found in the list of registered CSI drivers

ou

MountVolume.SetUp failed for volume "yyy" : kubernetes.io/csi: mounter.SetUpAt failed to get CSI client: driver name lustre.csi.storage.gke.io not found in the list of registered CSI drivers

Causa:o driver CSI não está ativado ou ainda não está em execução.

Resolução:

  1. Verifique se o driver CSI está ativado.
  2. Se o cluster foi escalonado ou atualizado recentemente, aguarde alguns minutos para que o driver funcione.
  3. Se o erro persistir, verifique os registros lustre-csi-node para "Operação não permitida". Isso indica que a versão do nó é muito antiga para oferecer suporte ao Lustre gerenciado. Para resolver isso, faça upgrade do pool de nós para a versão 1.33.2-gke.1111000 ou mais recente.
  4. Se os registros mostrarem "LNET_PORT mismatch", faça upgrade do pool de nós para garantir que os módulos do kernel Lustre compatíveis estejam instalados.

O ponto de montagem já existe

Sintoma:

MountVolume.MountDevice failed for volume "yyy" : rpc error: code = AlreadyExists
desc = A mountpoint with the same lustre filesystem name "yyy" already exists on
node "yyy". Please mount different lustre filesystems

Causa:não é possível montar vários volumes de diferentes instâncias gerenciadas do Lustre com o mesmo nome de sistema de arquivos em um único nó.

Resolução:use um nome exclusivo para cada instância do Managed Lustre.

Falha na montagem: arquivo ou diretório não encontrado

Sintoma:

MountVolume.MountDevice failed for volume "yyy" : rpc error: code = Internal desc = Could not mount ... failed: No such file or directory

Causa:o nome do sistema de arquivos especificado está incorreto ou não existe.

Resolução:verifique se o fs_name na configuração do StorageClass ou do PV corresponde à instância do Managed Lustre.

Falha na montagem: erro de entrada/saída

Sintoma:

MountVolume.MountDevice failed for volume "yyy" : rpc error: code = Internal desc = Could not mount ... failed: Input/output error

Causa:o cluster não consegue se conectar à instância gerenciada do Lustre.

Resolução:

  1. Verifique o endereço IP da instância do Lustre gerenciado.
  2. Verifique se o cluster do GKE e a instância gerenciada do Lustre estão na mesma rede VPC ou se têm peering correto.

Erros internos

Sintoma: rpc error: code = Internal desc = ...

Resolução:se o erro persistir, entre em contato com o Cloud Customer Care.

Resolver problemas de desconexão de volume

Sintoma:

UnmountVolume.TearDown failed for volume "yyy" : rpc error: code = Internal desc = ...

Resolução:

  1. Forçar a exclusão do pod:

    kubectl delete pod POD_NAME --force

  2. Se o problema persistir, entre em contato com o Cloud Customer Care.

Resolver problemas na exclusão de volumes

Se o PV permanecer no estado "Liberado" por um período prolongado (por exemplo, mais de uma hora) após a exclusão do PVC, entre em contato com o Cloud Customer Care.

Resolver problemas de expansão de volume

PVC preso em ExternalExpanding

Sintoma:o status do PVC não muda para Resizing, e os eventos mostram ExternalExpanding.

Causa:o campo allowVolumeExpansion pode estar ausente ou definido como false.

Resolução:verifique se o StorageClass tem allowVolumeExpansion: true.

kubectl get storageclass STORAGE_CLASS_NAME -o yaml

Falha na expansão: argumento inválido

Sintoma: VolumeResizeFailed: rpc error: code = InvalidArgument ...

Causa:o tamanho solicitado é inválido (por exemplo, não é um múltiplo do tamanho da etapa ou está fora dos limites).

Resolução:confira os intervalos de capacidade válidos e atualize o PVC com um tamanho válido.

Falha na expansão: erro interno

Sintoma: VolumeResizeFailed ... rpc error: code = Internal

Resolução:repita a expansão reaplicando o PVC. Se ele falhar repetidamente, entre em contato com o Cloud Customer Care.

Prazo excedido

Sintoma:VolumeResizeFailed com DEADLINE_EXCEEDED.

Causa:a operação está demorando mais do que o esperado, mas ainda pode estar em andamento.

Resolução:Aguarde a conclusão da operação. O redimensionador vai tentar de novo automaticamente. Se ele ficar travado por muito tempo (por exemplo, > 90 minutos), entre em contato com o suporte.

Cota excedida

Sintoma:a expansão falha devido a limites de cota.

Resolução:solicite um aumento de cota ou um aumento de capacidade menor.

Problemas de rede VPC

As seções a seguir descrevem problemas comuns de rede VPC.

Não é possível acessar o Managed Lustre de um projeto de peering

Para acessar a instância do Managed Lustre de uma VM em uma rede VPC com peering, use o Network Connectivity Center (NCC). Com o NCC, é possível conectar várias redes VPC e locais a um hub central, oferecendo conectividade entre elas.

Para instruções sobre como configurar o NCC, consulte a documentação do Network Connectivity Center.

A montagem do Lustre em uma VM multi-NIC falha

Quando uma VM tem vários controladores de interface de rede (NICs) e a instância do Lustre gerenciado está em uma VPC conectada a uma NIC secundária (por exemplo, eth1), a montagem da instância pode falhar. Para resolver esse problema, siga as instruções para fazer a montagem usando uma NIC secundária.

Não é possível se conectar do intervalo de sub-rede 172.17.0.0/16

Os clientes do Compute Engine e do GKE com um endereço IP no intervalo de sub-rede 172.17.0.0/16 não podem montar instâncias do Managed Lustre.

Permissão negada para adicionar peering ao serviço servicenetworking.googleapis.com

ERROR: (gcloud.services.vpc-peerings.connect) User [$(USER)] does not have
permission to access services instance [servicenetworking.googleapis.com]
(or it may not exist): Permission denied to add peering for service
'servicenetworking.googleapis.com'.

Esse erro significa que você não tem a permissão do IAM servicenetworking.services.addPeering na sua conta de usuário.

Consulte Controle de acesso com o IAM para instruções sobre como adicionar um dos seguintes papéis à sua conta:

  • roles/compute.networkAdmin ou
  • roles/servicenetworking.networksAdmin

Não é possível modificar intervalos alocados em CreateConnection

ERROR: (gcloud.services.vpc-peerings.connect) The operation
"operations/[operation_id]" resulted in a failure "Cannot modify allocated
ranges in CreateConnection. Please use UpdateConnection."

Esse erro é retornado quando você já criou um peering de VPC nessa rede com intervalos de IP diferentes. Há duas soluções possíveis:

Substitua os intervalos de IP atuais:

gcloud services vpc-peerings update \
  --network=NETWORK_NAME \
  --ranges=IP_RANGE_NAME \
  --service=servicenetworking.googleapis.com \
  --force

Ou adicione o novo intervalo de IP à conexão atual:

  1. Recupere a lista de intervalos de IP atuais para o peering:

    EXISTING_RANGES="$(
  gcloud services vpc-peerings list \
    --network=NETWORK_NAME \
    --service=servicenetworking.googleapis.com \
    --format="value(reservedPeeringRanges.list())" \
    --flatten=reservedPeeringRanges
)

  2. Em seguida, adicione o novo intervalo ao peering:

    gcloud services vpc-peerings update \
  --network=NETWORK_NAME \
  --ranges="${EXISTING_RANGES}",IP_RANGE_NAME \
  --service=servicenetworking.googleapis.com

Intervalo de endereços IP esgotado

Se a criação da instância falhar com o erro "intervalo esgotado":

ERROR: (gcloud.alpha.Google Cloud Managed Lustre.instances.create) FAILED_PRECONDITION: Invalid
resource state for "NETWORK_RANGES_NOT_AVAILABLE": IP address range exhausted

Siga o guia da VPC para modificar a conexão particular atual e adicionar intervalos de endereços IP.

Recomendamos um comprimento de prefixo de pelo menos /20 (1.024 endereços).