Container Service for Kubernetes:Melhores práticas para otimização de desempenho de volumes persistentes do OSS

Seleção de cliente

Em comparação com o ossfs 1,0, os volumes persistentes ossfs 2,0 e strmvol oferecem melhorias significativas de desempenho para operações sequenciais de leitura/gravação e leituras de alta concorrência de arquivos pequenos. Se sua aplicação não realiza gravações aleatórias, recomendamos o uso do ossfs 2,0.

Caso não tenha certeza se sua aplicação realiza gravações aleatórias, tente montar um volume persistente ossfs 2,0 em um ambiente de teste. Se a aplicação executar uma operação de gravação aleatória, um erro EINVAL será retornado.

Para maximizar o desempenho ao usar o cliente ossfs 2,0, as operações chmod e chown não relatam erros, mas não têm efeito. Para definir permissões para arquivos ou pastas no ponto de montagem, adicione parâmetros de montagem ao campo otherOpts do volume persistente (PV). Para chmod , use -o file_mode=<permission_code> ou -o dir_mode=<permission_code> . Para chown , use -o gid= ou -o uid= .

Para recomendações detalhadas de seleção, consulte Referência de seleção de cliente.

Expectativas de desempenho

Como sistema de arquivos de rede, o desempenho de um volume persistente do OSS é afetado pelas camadas de rede e de protocolo. Um problema de desempenho normalmente indica um desvio significativo dos resultados de benchmark fornecidos, e não apenas uma diferença de desempenho em comparação a um sistema de arquivos local. O desempenho básico para diferentes clientes é o seguinte:

• Desempenho básico de leitura/gravação de volumes persistentes ossfs 1,0

• Desempenho básico de leitura/gravação de volumes persistentes ossfs 2,0

• Desempenho básico de leitura/gravação de volumes persistentes strmvol

Um endpoint de Internet está configurado no PV

Quando seu cluster e o bucket do OSS estão na mesma região, o uso de um endpoint interno reduz significativamente a latência da rede.

• Método de solução de problemas: Execute o comando a seguir para verificar o endpoint do OSS configurado para o PV.

  kubectl get pv <pv-name> -o jsonpath='{.spec.csi.volumeAttributes.url}'

• Solução: Se a saída for um endpoint de Internet, como http://oss-<region-id>.aliyuncs.com, recrie o PV e use um endpoint interno, como http://oss-<region-id>-internal.aliyuncs.com.

Limitação no servidor OSS

O OSS possui limites na largura de banda total e nas consultas por segundo (QPS) para um único bucket. Para serviços em algumas regiões e em cenários que envolvem acesso de alta concorrência ao OSS, como fluxos de trabalho, podem ocorrer limitações de largura de banda e QPS.

• Método de solução de problemas: No console do OSS, visualize as métricas de monitoramento do bucket do OSS para verificar se métricas como uso de largura de banda e número de solicitações estão se aproximando ou excedendo os limites.

• Soluções:

  • Alterar a região: Os limites de largura de banda e QPS para um único bucket do OSS variam conforme a região. Se sua aplicação ainda estiver na fase de testes, considere movê-la para outra região.

  • Gargalo de largura de banda:

    • Se os dados não precisarem ser lidos repetidamente: Anexe dinamicamente um disco ao pod para armazenamento temporário. Para dados temporários, utilize um disco efêmero elástico (EED). Para obter mais informações, consulte Usar um volume provisionado dinamicamente. Para visualizar as métricas de desempenho de diferentes tipos de disco, consulte Desempenho do Elastic Block Storage.

    • Se os dados forem lidos repetidamente entre réplicas ou lotes de aplicações: Utilize um cache distribuído, como Fluid com JindoFS, para pré-buscar dados do OSS para o sistema de cache do cluster. Isso evita solicitações repetidas de dados ao OSS. Para obter mais informações, consulte Acelerar o acesso a arquivos do OSS usando JindoFS.

  • Gargalo de QPS (ou IOPS): Na maioria das aplicações, a alta concorrência faz com que o limite de largura de banda seja atingido antes do limite de QPS. Se apenas o gargalo de QPS for acionado, a causa pode ser a recuperação frequente de metadados, como ls e stat, ou a abertura e fechamento frequentes de arquivos. Nesse caso, verifique a configuração do cliente e o método de leitura/gravação da aplicação. Para informações sobre otimização, consulte Otimizar a lógica de leitura/gravação da aplicação e os parâmetros do cliente.

A largura de banda interna do nó da aplicação atinge o gargalo

O cliente e o pod da aplicação executam no mesmo nó e compartilham seus recursos de rede. Em cenários de poder de computação serverless, eles compartilham os recursos de uma única instância ACS. Portanto, o limite de largura de banda de rede do nó restringe o desempenho máximo do volume persistente do OSS.

• Método de solução de problemas: Visualize as informações de monitoramento do nó ou as informações de monitoramento da instância ECS para verificar se há um gargalo de largura de banda.

• Soluções:

  • Priorize o agendamento do pod da aplicação em um nó que tenha maior largura de banda de rede disponível.

  • Você pode atualizar ou reduzir a configuração do nó para obter mais largura de banda.

  • Se essas soluções não forem viáveis e a tarefa for intensiva em I/O, considere mudar para um volume persistente baseado em disco.

O cache de dados do volume persistente ossfs 1,0 é limitado pelo throughput máximo do disco

Para oferecer suporte a operações de gravação POSIX completas e garantir a consistência dos dados para um único cliente, o cliente ossfs 1,0 armazena alguns dados em cache no disco por padrão ao acessar arquivos. Essa operação de cache ocorre no diretório /tmp do pod ossfs. Esse espaço corresponde ao disco no nó usado para dados de runtime de contêiner. Portanto, o desempenho do ossfs 1,0 é diretamente limitado pelas operações de entrada/saída por segundo (IOPS) e pelos limites de throughput desse disco.

• Método de solução de problemas:

  O método a seguir não se aplica a nós ContainerOS.

  1. Execute o comando a seguir para localizar o ID do disco de dados de runtime de contêiner no nó onde o pod da aplicação está em execução.

     kubectl get node <node-name> -o yaml | grep alibabacloud.com/data-disk-serial-id

     Com base no data-disk-serial-id na saída, o espaço temporário está localizado na instância de disco d-uf69tilfftjoa3qb****.

     alibabacloud.com/data-disk-serial-id: uf69tilfftjoa3qb****

     Se o ID na saída estiver vazio, acesse o Console ECS - Elastic Block Storage - Disks . Localize o disco com base na instância anexada e consulte suas informações de monitoramento.

  2. Com base no ID da instância, você pode visualizar as informações de monitoramento do disco para determinar se o disco tem um gargalo de IOPS ou throughput.

• Soluções:

  • Para cenários somente leitura ou de gravação sequencial: O cliente ossfs 1,0 não consegue prever se um arquivo aberto sofrerá gravação aleatória. Portanto, mesmo uma operação somente leitura pode acionar o cache de dados no disco. Recomendamos migrar essas aplicações para um cliente mais adequado, como o ossfs 2,0, ou implementar divisão de leitura/gravação para a aplicação.

  • Para cenários de gravação aleatória: O desempenho de gravações aleatórias por meio de um cliente Filesystem in Userspace (FUSE), como o ossfs 1,0, geralmente é baixo. Recomendamos modifique a aplicação para acessar o OSS diretamente através do SDK do OSS ou mudar para um volume persistente NAS, que é mais adequado para esse cenário.

Alto uso do disco que armazena dados temporários para volumes persistentes ossfs 1,0

Se o monitoramento do disco mostrar que o uso do disco para cache de dados do ossfs 1,0 está consistentemente alto, especialmente em cenários de poder de computação serverless, a evicção e rotação frequentes de dados temporários podem degradar ainda mais o desempenho de acesso.

• Método de solução de problemas:

  1. Siga a solução em O cache de dados do volume persistente ossfs 1,0 é limitado pelo throughput máximo do disco para identificar o disco usado para dados de runtime de contêiner.

  2. Verifique o uso de recursos do disco através do monitoramento. Se o uso permanecer em um nível alto estável, mas a aplicação em si gravar poucos dados no disco, o problema de desempenho pode ser causado pela rotação de dados temporários pelo cliente ossfs 1,0.

• Soluções:

  1. Verificar a lógica da aplicação: Confirme se o código da aplicação mantém descritores de arquivo por muito tempo (ou seja, mantém arquivos abertos por períodos prolongados). Enquanto um descritor de arquivo é mantido, seus dados temporários relacionados não podem ser liberados. Isso pode consumir uma grande quantidade de espaço em disco local.

  2. Expandir o disco local: Se a lógica da aplicação estiver correta e o throughput máximo do disco atual atender aos requisitos, considere aumentar a capacidade do disco.

TTL curto de autenticação causa muitas solicitações RAM

Ao usar uma função do Resource Access Management (RAM) para autenticação, o cliente ossfs (versões 1,0 e 2,0) obtém um token e registra seu tempo de expiração no primeiro acesso ao OSS. Para garantir a continuidade da sessão, o cliente obtém um novo token e atualiza o tempo de expiração 20 minutos antes do token atual expirar.

Portanto, a duração máxima da sessão (max_session_duration) para a função RAM deve ser superior a 20 minutos.

Por exemplo, se a duração da sessão for de 30 minutos, o cliente atualiza o token após 10 minutos de uso (30 - 20 = 10), o que não afeta o throughput normal. Se a duração da sessão for inferior a 20 minutos, o cliente considera que o token está sempre prestes a expirar. Ele então tenta obter um novo token antes de cada solicitação ao OSS. Isso aciona muitas solicitações RAM e afeta o desempenho.

• Método de solução de problemas: O nível de log padrão do cliente pode não registrar o comportamento frequente de atualização de token. Você deve confirmar se a função RAM usada pela aplicação está configurada corretamente.

• Solução: Consulte Defina a duração máxima da sessão para uma função RAM para consultar e modifique a duração máxima da sessão da função RAM. Certifique-se de que a configuração esteja correta.

Otimize o cache de metadados (e evite desativá-lo)

O cache de metadados é um mecanismo central para melhorar o desempenho de operações de alta frequência, como ls e stat. Ele reduz significativamente as solicitações de rede que consomem tempo. Se você o desativar ou configurar incorretamente, o cliente poderá solicitar dados do OSS frequentemente para garantir a consistência, criando um gargalo de desempenho.

• Método de solução de problemas: Execute o comando a seguir para verificar se os parâmetros do cliente configurados para o PV incluem opções para desativar o cache.

  kubectl get pv <pv-name> -o jsonpath='{.spec.csi.volumeAttributes.otherOpts}'

• Soluções:

  • Evite desativar o cache: Se a saída do comando incluir max_stat_cache_size=0 (para ossfs 1,0) ou close_to_open=true (para ossfs 2,0), e seu cenário não exigir consistência forte, recrie o volume persistente e remova esses parâmetros.

  • Otimize a configuração de cache: Se os dados lidos pela sua aplicação forem atualizados com pouca frequência, aumente o tamanho e o tempo de expiração do cache de metadados para melhorar ainda mais o desempenho.

    • Volumes persistentes ossfs 1,0: Consulte Cache de metadados.

    • Volumes persistentes ossfs 2,0: Consulte Reduzir solicitações do OSS e melhorar o desempenho do ponto de montagem.

    • Volumes persistentes strmvol: Por padrão, todos os metadados no ponto de montagem são armazenados em cache e não expiram. Normalmente, nenhuma configuração extra é necessária.

Evite manter informações estendidas de objeto (apenas para ossfs 1,0)

Metadados do sistema de arquivos, como mode, gid e uid, são considerados informações estendidas para objetos no OSS. O cliente ossfs 1,0 precisa fazer solicitações HTTP extras para recuperar essas informações. Embora o cliente armazene esses metadados (incluindo propriedades básicas e estendidas) em cache por padrão para melhorar o desempenho de acesso a dados, a recuperação frequente de metadados, especialmente de propriedades estendidas, continua sendo um gargalo de desempenho.

Portanto, a otimização de desempenho para esses cenários concentra-se em dois pontos:

1. Minimize o número de operações de recuperação de metadados. Para obter mais informações, consulte Otimizar o cache de metadados (e evitar desativá-lo).

2. Evite solicitar propriedades estendidas que tenham alta sobrecarga para reduzir o custo de tempo de cada recuperação.

Soluções:

• A aplicação não depende de metadados do sistema de arquivos: Recomendamos defina o parâmetro readdir_optimize para desativar a manutenção de informações estendidas. O comportamento de chmod, chown, stat e outras operações será então igual ao do ossfs 2,0.

• A aplicação requer apenas configuração global de permissões: Para cenários em que contêineres não root precisam de permissões, recomendamos defina o parâmetro readdir_optimize. Ao mesmo tempo, utilize os parâmetros gid, uid e file_mode/dir_mode para modifique globalmente o usuário padrão ou as permissões do sistema de arquivos.

• A aplicação requer políticas de acesso refinadas: Recomendamos não usar permissões do sistema de arquivos para controle de acesso. Em vez disso, utilize o sistema de autenticação do lado do servidor do OSS para implementar isolamento de caminho. Por exemplo, crie diferentes usuários ou funções RAM para diferentes aplicações e use uma política de bucket ou política RAM para restringir os subcaminhos que eles podem acessar. Ainda assim, defina o parâmetro readdir_optimize para otimizar o desempenho.

Otimize o modo de gravação de arquivo

A operação de gravação padrão para objetos do OSS é a substituição. Quando o cliente lida com modificações de arquivo, ele deve seguir um padrão de leitura e depois gravação. Primeiro, lê o objeto completo do OSS para a máquina local. Depois, após o arquivo ser fechado, reenvia todo o arquivo para o servidor. Portanto, em casos extremos de abertura, gravação e fechamento frequentes de arquivos, a aplicação baixe e envia repetidamente os dados completos.

Soluções:

• Use gravações em lote em vez de múltiplas gravações: Evite múltiplas gravações desnecessárias sempre que possível. Prepare o conteúdo na memória e chame uma única operação de gravação para concluí-lo. Observe que algumas funções de gravação encapsuladas, como FileUtils.write do Java, já incluem um fluxo completo de open, write e close. Se você chamar tais funções repetidamente em um loop, ocorrerão problemas de desempenho.

• Use arquivos temporários para modificações frequentes: Se um arquivo precisar ser aberto e modificado várias vezes durante uma tarefa de processamento de dados, copie-o primeiro do ponto de montagem do OSS para um caminho temporário no contêiner, como /tmp. Realize todas as modificações no arquivo temporário local. Finalmente, copie a versão final para o ponto de montagem do OSS em uma única operação para enviá-la.

• Ative o recurso appendable para cenários de gravação por acréscimo: Se o cenário da sua aplicação envolver apenas pequenas gravações por acréscimo frequentes, como gravação de logs, considere usar o ossfs 2,0 e ative o parâmetro enable_appendable_object=true. Após ativar esse parâmetro, o cliente usa Objetos Appendable do OSS. Ao acrescentar dados, o cliente não precisa baixe e reenviar o arquivo inteiro a cada vez. No entanto, observe o seguinte:

  • Se o arquivo de objeto já existir, mas não for um objeto Appendable, você não poderá usar esta solução para acrescentar dados a ele.

  • enable_appendable_object é um parâmetro global para todo o volume persistente. Depois de ativado, todas as operações de gravação neste volume são realizadas através da API AppendObject. Isso afeta o desempenho de substituição de arquivos grandes, mas não a leitura deles. Recomendamos crie um volume persistente dedicado para esse tipo de aplicação de gravação por acréscimo.

Otimize o modo de leitura concorrente (especialmente para cenários de carregamento de modelo)

Quando vários processos leem dados simultaneamente de locais diferentes dentro de um único arquivo grande, o modo de acesso é semelhante a uma leitura aleatória. Isso pode fazer com que o cliente leia dados redundantes, levando a um uso anormalmente alto da largura de banda. Por exemplo, em cenários de carregamento de modelos de IA, estruturas de modelos convencionais frequentemente têm vários processos concorrentes que leem o mesmo arquivo de parâmetros do modelo. Isso pode acionar um gargalo de desempenho.

Se você notar que o desempenho do ossfs 2,0 nesses cenários é pior do que o do ossfs 1,0, ou se seu desempenho diferir significativamente do desempenho de teste de estresse do cliente ossfs 2,0, confirme que este é o problema.

Soluções:

• Pré-busca de dados (recomendado): Antes que o pod da aplicação inicie, use um script para pré-buscar os dados. O princípio central é usar leituras sequenciais concorrentes de alta largura de banda para carregar todo o arquivo do modelo na memória do nó (Page Cache) antecipadamente. Após a conclusão da pré-busca, as leituras aleatórias da aplicação acessam diretamente a memória, contornando o gargalo de desempenho.

  Você pode usar o seguinte script autônomo de pré-busca, que lê concorrentemente o conteúdo do arquivo para /dev/null:

  #!/bin/bash
  # Set the maximum concurrency.
  MAX_JOBS=4
  
  # Check if a folder is provided as an argument.
  if [ -z "$1" ]; then
      echo "Usage: $0 <folder_path>"
      exit 1
  fi
  
  DIR="$1"
  
  # Check if the folder exists.
  if [ ! -d "$DIR" ]; then
      echo "Error: '$DIR' is not a valid folder."
      exit 1
  fi
  
  # Use find to locate all regular files and use xargs to concurrently run cat to /dev/null.
  find "$DIR" -type f -print0 | xargs -0 -I {} -P "$MAX_JOBS" sh -c 'cat "{}" > /dev/null'
  
  echo "Finished reading all files."

  Simplifique a lógica principal deste script e execute-o no hook lifecycle.postStart do pod.

  # ...
  spec:
    containers:
    - image: your-image
      env:
      # Define the folder path where the model files are located. If not configured or the folder does not exist, the script skips data prefetching.
      - name: MODEL_DIR
        value: /where/is/your/model/
      # Define the concurrency for the prefetching script. The default is 4.
      - name: PRELOADER_CONC
        value: "8"
      lifecycle:
        postStart:
          exec:
            command: ["/bin/sh", "-c", "CONC=${PRELOADER_CONC:-4}; if [ -d \"$MODEL_DIR\" ]; then find \"$MODEL_DIR\" -type f -print0 | xargs -0 -I {} -P \"$CONC\" sh -c 'cat \"{}\" > /dev/null'; fi"]
  # ...

• Refatore a lógica da aplicação: Avalie e refatore a lógica da aplicação para mudar de leituras concorrentes multiprocesso dentro de um único arquivo para leituras concorrentes de vários arquivos diferentes. Essa mudança pode aproveitar a vantagem de alto throughput do OSS.