Solução de problemas e problemas conhecidos

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

• Problemas conhecidos
• Problemas de operação da instância
• Manutenção
• Problemas do Compute Engine
• Problemas do GKE
• Problemas da rede VPC

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.
• Não é possível montar o Managed Lustre em VMs protegidas. A tentativa de carregar o módulo do kernel do Lustre em um ambiente de inicialização segura falha com o erro: ERROR: could not insert 'lustre': Required key not available.

Problemas de operação da instância

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

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

Se você receber 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 do mesmo tipo já está em andamento na mesma instância.

• Importação/exportação:o Managed Lustre oferece suporte a 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 da 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.

Manutenção

O estado MAINTENANCE indica que a instância está passando por uma manutenção planejada do host.

Para instâncias com capacidades maiores que o limite de taxa de aprendizado para o nível de desempenho, a manutenção do host exige que as máquinas virtuais subjacentes sejam encerradas e reiniciadas. Isso resulta em um tempo de inatividade planejado de até 4 horas.

Se a instância estiver no estado MAINTENANCE:

• Tempo de inatividade:a instância fica indisponível nesse estado.
• Programação:o Google coordena esses eventos periodicamente com você com antecedência. Essa coordenação é normalmente feita pelos contatos de suporte designados, como um gerente técnico de contas (TAM).
• Faturamento:você ainda recebe cobranças pela instância enquanto ela está no estado MAINTENANCE, porque seus dados são mantidos.
• SLO:as instâncias no estado MAINTENANCE são excluídas dos cálculos de objetivo de nível de serviço (SLO).

Quando a manutenção é concluída, a instância retorna automaticamente ao estado ACTIVE.

Problemas do Compute Engine

Ao encontrar problemas ao montar um sistema de arquivos do 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 está acessível na 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 do Managed 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 é prefixada com https://www.googleapis.com/compute/v1/; tudo o que segue essa string precisa corresponder à saída do comando gcloud lustre instances describe.

• Analise 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 do Managed Lustre.

Verificar a porta de aceitação do LNet

As instâncias do Managed 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 o LNet para gke-support-enabled instâncias.

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, você precisará configurar o LNet.

Incompatibilidade da versão do kernel do Ubuntu com o cliente do 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 de cliente do Lustre. Se as ferramentas de cliente do 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 a versão do kernel listada nos dois comandos, você deve reinstalar os pacotes de cliente do Lustre.

Verificar 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 em conjunto 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.

Executar 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 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 Managed Lustre no GKE.

Capacidade mínima atualizada da instância

A capacidade mínima das instâncias do Managed Lustre foi atualizada para 9.000 GiB. Para criar instâncias de 9.000 GiB usando o driver CSI do Managed Lustre, 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, independentemente do valor perUnitStorageThroughput especificado na solicitação de API. Isso afeta as versões do GKE 1.33 anteriores a 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, uma versão mais recente talvez ainda não esteja disponível. Nesse caso, é possível selecionar 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. A ativação dessa flag contorna um conflito de porta com o gke-metadata-server em nós do GKE.
  • Instâncias do Managed Lustre com suporte do GKE:se você estiver se conectando a uma instância do Managed Lustre criada com a flag --gke-support-enabled, inclua --enable-legacy-lustre-port ao ativar o driver CSI, independentemente da versão do cluster. Sem essa flag, o cluster do GKE não vai conseguir montar a instância do Lustre.

  Para mais informações 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 consulta a seguir em Análise de registros.

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

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, um erro poderá ter ocorrido.

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 do StorageClass.

3. Recrie o 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 se torne funcional.
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 Managed Lustre. 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 "Incompatibilidade de LNET_PORT", faça upgrade do pool de nós para garantir que os módulos do kernel do 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 há suporte para a montagem de vários volumes de diferentes instâncias do Managed Lustre com o mesmo nome de sistema de arquivos em um único nó.

Resolução:use um nome de sistema de arquivos 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 do Managed Lustre.

Resolução :

1. Verifique o endereço IP da instância do Managed Lustre.
2. Verifique se o cluster do GKE e a instância do Managed Lustre estão na mesma rede VPC ou se estão corretamente pareados.

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 desmontagem 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 de exclusão de volume

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: Verifique 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 a falha ocorrer 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 novamente de forma automática. Se ele permanecer preso 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: Peça um aumento de cota ou um aumento de capacidade menor.

Problemas da rede VPC

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

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

Para acessar a instância do Managed Lustre de uma VM em uma rede VPC pareada, use o Network Connectivity Center (NCC). O NCC permite conectar várias redes VPC e redes locais a um hub central, fornecendo 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 Managed Lustre 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 montar 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 servicenetworking.services.addPeering do IAM 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 um erro de intervalo de endereços IP 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 (4096 endereços).