How to accelerate access to OSS files by using JindoFS - Container Service for Kubernetes: Central de Documentação do Alibaba Cloud

O JindoRuntime é o mecanismo de execução do JindoFS, desenvolvido pela equipe do Alibaba Cloud E-MapReduce (EMR) e implementado em C++. Ele oferece gerenciamento de conjuntos de dados e cache para dados do Object Storage Service (OSS) em um cluster Kubernetes. A Alibaba Cloud fornece suporte no nível de serviço em nuvem para o JindoFS. O Fluid gerencia e agenda o JindoRuntime para proporcionar observabilidade, Auto Scaling e portabilidade de conjuntos de dados.

Este tópico orienta você a fazer upload de um conjunto de dados de teste para o OSS, criar um Dataset e um JindoRuntime e verificar o efeito de aceleração de cache com um pod de benchmark.

Limitações

O JindoRuntime exige um cluster ACK Pro com sistema operacional não ContainerOS. Atualmente, o componente ack-fluid não oferece suporte ao ContainerOS.
Se você já instalou o Fluid open-source, desinstale-o antes de implantar o componente ack-fluid. Não há suporte para a execução simultânea de ambos.

Pré-requisitos

Antes de começar, verifique se você tem:

Um cluster ACK Pro com sistema operacional não ContainerOS, executando Kubernetes 1.18 ou posterior. Consulte Criar um cluster ACK Pro.
O componente ack-fluid implantado no cluster:
- Se o pacote de IA nativa da nuvem não estiver instalado, ative a Fluid acceleration durante a instalação. Consulte Implantar o pacote de IA nativa da nuvem.
- Se o pacote de IA nativa da nuvem já estiver instalado, acesse a página Cloud-native AI Suite no console do ACK e implante o componente ack-fluid.
Um cliente kubectl conectado ao cluster ACK Pro. Consulte Conectar-se a um cluster usando kubectl.
OSS ativado. Consulte Ativar o OSS.

Etapa 1: Fazer upload de dados para o OSS

As etapas a seguir usam uma instância do Elastic Compute Service (ECS) com Alibaba Cloud Linux 3.2104 LTS 64 bits para fazer upload de um conjunto de dados de teste. Para outros sistemas operacionais, consulte ossutil e ossutil 1.0.

Baixe o conjunto de dados de teste para a instância ECS.

wget https://archive.apache.org/dist/spark/spark-3.0.1/spark-3.0.1-bin-hadoop2.7.tgz

Instale o ossutil na instância ECS.
Crie um bucket do OSS chamado examplebucket.
```
ossutil64 mb oss://examplebucket
```
Saída esperada:
```
0.668238(s) elapsed
```

Faça upload do conjunto de dados de teste para o bucket.

ossutil64 cp spark-3.0.1-bin-hadoop2.7.tgz oss://examplebucket

Etapa 2: Criar um dataset e um JindoRuntime

O JindoRuntime lê as credenciais do OSS de um Secret do Kubernetes. Portanto, crie o Secret antes de criar o Dataset.

Crie um arquivo chamado mySecret.yaml com o conteúdo a seguir. Substitua xxx pelo AccessKey ID e AccessKey secret com permissão de leitura no bucket do OSS criado na Etapa 1.
```
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
stringData:
  fs.oss.accessKeyId: xxx
  fs.oss.accessKeySecret: xxx
```
Aplique o Secret. O Kubernetes criptografa os valores armazenados para evitar exposição como texto simples.
```
kubectl create -f mySecret.yaml
```

Crie um arquivo chamado resource.yaml com o conteúdo a seguir. Esse arquivo define o Dataset (que aponta para seus dados no OSS) e o JindoRuntime (que inicia o cluster de cache).

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: hadoop
spec:
  mounts:
    - mountPoint: oss://<oss_bucket>/<bucket_dir>
      options:
        fs.oss.endpoint: <oss_endpoint>
      name: hadoop
      path: "/"
      encryptOptions:
        - name: fs.oss.accessKeyId
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: fs.oss.accessKeyId
        - name: fs.oss.accessKeySecret
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: fs.oss.accessKeySecret
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: hadoop
spec:
  replicas: 2
  tieredstore:
    levels:
      - mediumtype: MEM
        path: /dev/shm
        volumeType: emptyDir
        quota: 2Gi
        high: "0.99"
        low: "0.95"

A tabela a seguir descreve os principais parâmetros.

Parâmetro	Descrição	Obrigatório	Padrão
`mountPoint`	Caminho para o sistema de arquivos subjacente (UFS) no formato `oss://<oss_bucket>/<bucket_dir>`. O endpoint do OSS não está incluído aqui.	Sim	—
`fs.oss.endpoint`	Endpoint público ou interno do bucket do OSS. Consulte Regiões e endpoints.	Sim	—
`replicas`	Número de workers no cluster de cache do JindoFS.	Sim	—
`mediumtype`	Meio de armazenamento de cache. Valores válidos: `HDD`, `SSD`, `MEM`.	Sim	—
`path`	Caminho de armazenamento local no nó worker. Apenas um caminho é permitido. Obrigatório quando `mediumtype` é `MEM` para armazenar dados como logs.	Sim	—
`quota`	Tamanho máximo de cache por worker.	Sim	—
`high`	Limiar de evicção de cache (marca d'água alta). Quando o uso excede essa proporção, a evicção começa.	Não	—
`low`	Limiar de retenção de cache (marca d'água baixa). A evicção para quando o uso cai para essa proporção.	Não	—

Crie o Dataset e o JindoRuntime.
```
kubectl create -f resource.yaml
```

Verifique se o Dataset está vinculado.

kubectl get dataset hadoop

Saída esperada:

NAME     UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
hadoop        210MiB       0.00B    4.00GiB              0.0%          Bound   1h

Confirme se o JindoRuntime está pronto.

kubectl get jindoruntime hadoop

Saída esperada:

NAME     MASTER PHASE   WORKER PHASE   FUSE PHASE   AGE
hadoop   Ready          Ready          Ready        4m45s

Valide se o volume persistente (PV) e a solicitação de volume persistente (PVC) foram criados.

kubectl get pv,pvc

Saída esperada:

NAME                      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGE
persistentvolume/hadoop   100Gi      RWX            Retain           Bound    default/hadoop                           52m

NAME                           STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/hadoop   Bound    hadoop   100Gi      RWX                           52m

O Dataset e o JindoRuntime estarão prontos quando todas as fases mostrarem Ready e o status do PVC for Bound.

Etapa 3: Testar a aceleração de dados

Implante um pod que monte o PVC do Dataset e compare os tempos de leitura de arquivos antes e depois do armazenamento dos dados em cache.

Crie um arquivo chamado app.yaml com o seguinte conteúdo.

apiVersion: v1
kind: Pod
metadata:
  name: demo-app
spec:
  containers:
    - name: demo
      image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
      volumeMounts:
        - mountPath: /data
          name: hadoop
  volumes:
    - name: hadoop
      persistentVolumeClaim:
        claimName: hadoop

Implante o pod.
```
kubectl create -f app.yaml
```

Abra um shell no pod e verifique o tamanho do arquivo.

kubectl exec -it demo-app -- bash
du -sh /data/spark-3.0.1-bin-hadoop2.7.tgz

Saída esperada:

210M    /data/spark-3.0.1-bin-hadoop2.7.tgz

Meça o tempo inicial de leitura. Esse acesso vem diretamente do OSS, sem cache.
```
time cp /data/spark-3.0.1-bin-hadoop2.7.tgz /dev/null
```
Saída esperada:
```
real    0m18.386s
user    0m0.002s
sys    0m0.105s
```
A leitura do arquivo leva cerca de 18 segundos.

Verifique os dados em cache após a leitura.

kubectl get dataset hadoop

Saída esperada:

NAME     UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
hadoop   210.00MiB       210.00MiB    4.00GiB        100.0%           Bound   1h

Todos os 210 MiB agora estão em cache no armazenamento local.

Exclua e recrie o pod para limpar o cache de páginas do SO. Assim, a próxima leitura virá do cache do JindoFS em vez da memória.
```
kubectl delete -f app.yaml && kubectl create -f app.yaml
```
Meça o tempo de leitura novamente com os dados servidos a partir do cache.
```
kubectl exec -it demo-app -- bash
time cp /data/spark-3.0.1-bin-hadoop2.7.tgz /dev/null
```
Saída esperada:
```
real    0m0.048s
user    0m0.001s
sys     0m0.046s
```
Com o cache do JindoFS, a leitura do mesmo arquivo é concluída em 48 milissegundos — mais de 300 vezes mais rápido que o acesso direto ao OSS.

(Opcional) Limpeza

Quando a aceleração de dados não for mais necessária, exclua o pod, o Dataset e o JindoRuntime.

Exclua o pod:

kubectl delete pod demo-app

Exclua o Dataset e o JindoRuntime:

kubectl delete dataset hadoop

Próximos passos

Para enviar jobs de treinamento de machine learning que usam dados acelerados pelo JindoFS, consulte a documentação do pacote de IA nativa da nuvem.
Para explorar outras opções de armazenamento de cache (HDD, SSD), atualize os campos mediumtype e path em resource.yaml.