Recursos do ossfs 1.0 e versões posteriores e benchmarking de desempenho do ossfs - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

Mudanças da versão 1,88.x para a 1,91

As seções a seguir descrevem as alterações de recursos no ossfs 1,91 e versões posteriores. Para ver as notas de lançamento completas, acesse o changelog do ossfs.

Correções de operações POSIX e padrões de parâmetros

O ossfs 1,91 inclui diversas correções e atualizações de valores padrão:

Agora é possível montar volumes OSS em subcaminhos inexistentes nos buckets do OSS.
Arquivos com zero bytes deixaram de ser carregados durante a criação de objetos. O erro EntityTooSmall, que ocorria ocasionalmente no upload multipart, foi corrigido. As operações de append também foram aprimoradas.
Os valores padrão dos parâmetros foram atualizados com base na versão upstream do ossfs e em resultados de benchmarking de desempenho.

A tabela abaixo apresenta os parâmetros cujos valores padrão mudaram entre as versões 1,88.x e 1,91:

Parâmetro	Descrição	Padrão na 1,88.x	Padrão na 1,91+
`stat_cache_expire`	TTL do cache de metadados. Unidade: segundos.	-1 (nunca expira)	900
`multipart_threshold`	Limiar de tamanho de arquivo para upload multipart. Unidade: MB.	5 x 1024	25
`max_dirty_data`	Limiar de tamanho de dados sujos para flush forçado em disco. Unidade: MB.	-1 (nunca faz flush)	5120

Os parâmetros listados a seguir mantêm os mesmos valores padrão da versão 1,88.x, mas diferem da versão open-source do ossfs 1,91 para preservar o nível de desempenho:

Parâmetro	Descrição	Padrão no open-source 1,91+	Padrão no Alibaba Cloud 1,91+
`multipart_size`	Tamanho da parte para upload multipart. Unidade: MB.	10	30
`parallel_count`	Número de partes carregadas simultaneamente.	5	20

Para modificar qualquer um desses parâmetros, atualize o campo otherOpts no seu PV.

Otimização de readdir

Ao montar um volume OSS, o ossfs executa uma chamada HeadObject para cada objeto no caminho montado a fim de obter metadados como permissões, horário de modificação, UIDs e GIDs. Em caminhos com muitos objetos, essas chamadas HeadObject podem atrasar significativamente operações de travessia de diretórios, como ls e find.

O recurso de otimização de readdir ignora essas chamadas HeadObject, reduzindo a latência nas operações de diretório. Antes de ativá-lo, considere as seguintes contrapartidas:

Os comandos chmod e chown não surtem efeito.
Links simbólicos podem não funcionar conforme o esperado. Hard links não são suportados.

A tabela a seguir detalha os parâmetros do recurso de otimização de readdir:

Parâmetro	Descrição	Padrão
`readdir_optimize`	Ativa a otimização de readdir. Use `-o readdir_optimize` para ativar (não requer valor).	Desativado
`symlink_in_meta`	Registra metadados de links simbólicos para garantir sua exibição correta. Use `-o symlink_in_meta` para ativar (não requer valor).	Desativado

Leitura direta

O recurso de leitura direta foi projetado para cargas de trabalho de leitura sequencial em arquivos grandes. Sem a leitura direta, o ossfs baixa os arquivos do OSS para o disco antes de lê-los, limitando o throughput de leitura ao I/O do disco. Com a leitura direta, o ossfs pré-carrega os dados do OSS diretamente na memória e realiza a leitura a partir dela, eliminando o gargalo de I/O do disco.

Antes de ativar a leitura direta, observe as seguintes restrições:

Uso exclusivo para leituras sequenciais. Leituras aleatórias fazem o ossfs reiniciar a janela de pré-carregamento, o que degrada o throughput.
Operações de escrita descarregam a memória no disco para manter a consistência dos dados.
Após ativar a leitura direta, o parâmetro use_cache perde o efeito.

A tabela abaixo descreve os parâmetros do recurso de leitura direta:

Parâmetro	Descrição	Padrão
`direct_read`	Ativa o recurso de leitura direta. Use `-o direct_read` para ativar (não requer valor).	Desativado
`direct_read_prefetch_limit`	Memória máxima para dados pré-carregados em todos os processos do ossfs. Unidade: MB.	1024 (mínimo: 128)

Quando os dados pré-carregados atingem o limite definido em direct_read_prefetch_limit, o ossfs interrompe o pré-carregamento e o throughput de leitura passa a depender da velocidade de I/O da rede. Para desativar totalmente o pré-carregamento em memória e ler diretamente do OSS, defina -o direct_read_prefetch_chunks=0.

Escolha uma configuração de leitura

Utilize a tabela abaixo para selecionar a configuração mais adequada à sua carga de trabalho:

Carga de trabalho	Configuração recomendada	Motivo
Leituras sequenciais em arquivos grandes, acessados uma única vez	Ative `direct_read` (`-o direct_read`)	Pré-carrega dados na memória e elimina o I/O do disco
Arquivos pequenos ou médios lidos repetidamente no mesmo nó	Ative o page cache do kernel (`-o kernel_cache`)	Reutiliza o page cache do SO entre leituras
Arquivos lidos repetidamente cujo cache deve sobreviver a reinícios de processo	Ative o cache em disco (`-o use_cache=/path/to/cache`)	Persiste entre reinícios; oferece maior capacidade que o page cache
Grande quantidade de objetos, sem necessidade de metadados pelos serviços	Ative `readdir_optimize` (`-o readdir_optimize`)	Elimina chamadas HeadObject por objeto durante a travessia de diretórios

Os parâmetros direct_read e use_cache são mutuamente exclusivos. Quando o direct_read está ativado, o use_cache não tem efeito.

Melhores práticas

Cenários de leitura e escrita

Separe as operações de leitura e escrita em endpoints distintos do OSS para obter o melhor desempenho. Consulte Melhores práticas para separação de leitura/escrita no OSS.

Caso a separação não seja viável, atualize para o ossfs 1,91 ou posterior para corrigir o erro EntityTooSmall em uploads multipart. Para garantir a consistência dos dados, adicione -o max_stat_cache_size=0 ao campo otherOpts.

Cenários somente leitura

Siga as orientações abaixo para escolher a estratégia de cache ideal:

Leitura direta (-o direct_read): Ideal para leituras sequenciais únicas de arquivos grandes, quando os dados não serão acessados novamente. Elimina o I/O do disco ao pré-carregar os dados na memória.
Page cache do kernel (-o kernel_cache): Recomendado para arquivos lidos repetidamente no mesmo nó. Reutiliza dados em cache entre leituras, sem sobrecarga de escrita em disco.
Cache em disco (-o use_cache=/path/to/cache): Indicado para arquivos lidos frequentemente, quando o cache precisa persistir entre reinícios de processos ou exceder a memória disponível.

Cargas de trabalho intensivas em diretórios

Se o bucket do OSS contiver um grande número de objetos e seus serviços não precisarem de metadados dos objetos, ative -o readdir_optimize. Caso o versionamento esteja habilitado no bucket do OSS, adicione também -o listobjectsv2.

Benchmarks de desempenho

Os resultados apresentados abaixo foram obtidos com Sysbench ou scripts personalizados. Os valores podem variar conforme a ferramenta e o ambiente utilizados.

Importante

Todos os benchmarks utilizaram um nó ecs.g7.xlarge com disco de sistema PL0.

Throughput (com otimização de readdir e leitura direta desativadas)

O Sysbench testou 128 arquivos de 8 MiB cada, com leituras sequenciais, escritas sequenciais, leituras aleatórias e escritas aleatórias. Em comparação com a versão 1,88.x:

O ossfs 1,88.x entrega maior throughput na criação de arquivos e em leituras sequenciais.
O ossfs 1,91 e versões posteriores oferecem maior throughput em leituras sequenciais, leituras aleatórias e escritas aleatórias.

Latência de travessia de diretórios após ativar a otimização de readdir

O teste executou ls e find sobre 1.000 arquivos, registrando a latência por execução. Comparado ao ossfs 1,88.x e ao ossfs 1,91 com a otimização de readdir desativada:

A latência do ls é 74,8% menor que na versão 1,88.x e 74,3% menor que na 1,91 sem a otimização — representando uma melhoria de 4,0x e 3,9x, respectivamente.
A latência do find é 58,8% menor tanto em relação à 1,88.x quanto à 1,91 sem a otimização — uma melhoria de 2,4x em ambos os casos.

Latência de leitura sequencial de arquivos grandes após ativar a leitura direta

O teste leu simultaneamente 10 arquivos de 10 GiB cada, registrando latência, pico de uso de disco e pico de uso de memória.

O pico de uso de memória abrange todos os processos do ossfs, incluindo dados pré-carregados e outras sobrecargas da leitura direta.

Em comparação com a versão 1,88.x e a 1,91 com leitura direta desativada:

A latência é 85,3% menor que na 1,88.x e 79% menor que na 1,91 sem leitura direta.
O pico de uso de disco é 0 — nenhum arquivo temporário foi gravado no disco.
O pico de uso de memória é ligeiramente superior, o que viabiliza a ausência total de uso de disco mencionada acima.

Execute seus próprios benchmarks

Realize benchmarks do ossfs em containers ou diretamente em instâncias ECS. Os passos a seguir utilizam um ambiente Sysbench containerizado.

Pré-requisitos

Antes de começar, certifique-se de ter:

Um bucket OSS e uma persistent volume claim (PVC). Para configuração, consulte Montar um volume OSS com provisionamento estático

Implantar o ambiente de teste Sysbench

Crie um arquivo chamado sysbench.yaml com o conteúdo abaixo. Ele implanta um container Sysbench com a PVC montada em /data.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sysbench
  labels:
    app: sysbench
spec:
  replicas: 1
  selector:
    matchLabels:
      app: sysbench
  template:
    metadata:
      labels:
        app: sysbench
    spec:
      containers:
      - name: sysbench
        image: registry.cn-beijing.aliyuncs.com/tool-sys/tf-train-demo:sysbench-sleep
        ports:
        - containerPort: 80
        volumeMounts:
          - name: pvc-oss
            mountPath: "/data"
        livenessProbe:
          exec:
            command:
            - sh
            - -c
            - cd /data
          initialDelaySeconds: 30
          periodSeconds: 30
      volumes:
        - name: pvc-oss
          persistentVolumeClaim:
            claimName: pvc-oss

Implante a aplicação Sysbench:
```
kubectl apply -f sysbench.yaml
```

Faça login no container Sysbench e execute os comandos abaixo no caminho de montagem para medir o throughput de leitura e escrita.

Ajuste os valores dos parâmetros conforme as especificações do seu nó. Em testes consecutivos, prepare novos arquivos de teste a cada execução para evitar interferência do cache.

Operação	Comando
Preparar arquivos de teste	`sysbench --num-threads=2 --max-requests=0 --max-time=120 --file-num=128 --file-block-size=16384 --test=fileio --file-total-size=1G --file-test-mode=rndrw prepare`
Testar I/O de escrita sequencial	`sysbench --num-threads=2 --max-requests=0 --max-time=120 --file-num=128 --file-block-size=16384 --test=fileio --file-total-size=1G --file-test-mode=seqwr --file-fsync-freq=0 run`
Testar I/O de leitura sequencial	`sysbench --num-threads=2 --max-requests=0 --max-time=120 --file-num=128 --file-block-size=16384 --test=fileio --file-total-size=1G --file-test-mode=seqrd --file-fsync-freq=0 run`
Testar I/O de leitura/escrita aleatória	`sysbench --num-threads=2 --max-requests=0 --max-time=120 --file-num=128 --file-block-size=16384 --test=fileio --file-total-size=1G --file-test-mode=rndrw --file-fsync-freq=0 run`
Excluir arquivos de teste	`sysbench --test=fileio --file-total-size=1G cleanup`

Próximos passos

Realize benchmarks de diferentes versões do ossfs utilizando a ferramenta de benchmarking MySQL fornecida pelo Sysbench.
Teste a otimização de readdir executando ls e find no caminho de montagem.
Teste a leitura direta adicionando -o direct_read ao campo otherOpts do seu PV e executando leituras sequenciais simultâneas.