De uma empresa de tecnologia com foco no processamento de fala e linguagem, a Yunzhisheng desenvolveu sua pilha de tecnologia para ter recursos completos de IA, como imagem, processamento de linguagem natural e sinal. É a principal empresa unicórnio de inteligência artificial na China. A empresa adota a computação em nuvem e possui soluções correspondentes em saúde inteligente, hotéis inteligentes e educação inteligente.
Atlas é a plataforma de tecnologia subjacente do Unisound, suportando a iteração de todos os modelos do Unisound:
A primeira camada é a camada de negócios, principalmente os negócios da empresa, como processamento de voz, processamento de imagem, processamento de linguagem natural, etc.
A segunda camada é o centro de controle, que pode ser concluído em uma parada desde a produção de dados, acesso aos dados até a liberação do modelo.
A terceira camada é a camada de computação central, que suporta principalmente aprendizado profundo e pré-processamento de dados.
A camada inferior é a camada de infraestrutura, que é composta principalmente de cluster de GPU, cluster de CPU e armazenamento distribuído. Todas as máquinas são conectadas por rede de alta velocidade InfiniBand de 100 Gbps.
Cenários e requisitos de armazenamento
O objetivo de construção inicial da Unisound é construir uma plataforma de IA completa, incluindo produção de modelo de IA, pré-processamento de dados, desenvolvimento de modelo, treinamento de modelo e lançamento do modelo final.
Conforme mostrado na figura acima, cada etapa precisa interagir com os dados, e o pré-processamento de dados e o treinamento do modelo exigem IO relativamente grande .
• O pré-processamento de dados, principalmente o processamento de fala, extrairá recursos de fala e converterá recursos de fala em arquivos de formato numpy; no processo de processamento de imagem, as imagens serão pré-processadas e a conversão de formato dos dados de treinamento será feita; • Desenvolvimento de modelo, principalmente É o algoritmo engenheiro que edita o código e depura o algoritmo do modelo; • Para o treinamento do modelo, várias rodadas de leitura de dados serão necessárias no caminho e o modelo será enviado para o armazenamento correspondente. O IO necessário para esta etapa é muito grande; , o serviço lerá os arquivos de modelo no sistema de armazenamento. Para resumir nossos requisitos de armazenamento:
- O link completo que pode ser conectado a todo o desenvolvimento do modelo deve ser suportado em vários blocos funcionais principais;
- Suporta tarefas de leitura de dados de CPU e GPU;
- Nossos cenários são principalmente dados de voz, texto e imagem. Esses cenários são caracterizados por tamanhos de arquivo relativamente pequenos, portanto, o processamento de alto desempenho em cenários de arquivos pequenos deve ser suportado.
- Nosso cenário de negócios é principalmente ler mais e escrever menos. Durante o treinamento do modelo, a maioria dos dados é lida e basicamente nenhum dado é gravado. Com base nos requisitos acima, precisamos de um sistema de armazenamento distribuído confiável e de alto desempenho.
História da Construção do Armazenamento Unisound
No início, tínhamos apenas cerca de uma dúzia de GPUs e usamos o NFS para criar um cluster de pequena escala. Ao mesmo tempo, o ambiente de teste CephFS foi introduzido em 2016. Naquela época, o desempenho dessa versão do CephFS não era muito bom no cenário de arquivos pequenos, então o CephFS não foi trazido para o ambiente de produção.
Mais tarde, continuamos a fazer pesquisas e descobrimos que o Lustre é o sistema de arquivos de alto desempenho mais comumente usado no campo HPC. Os testes mostram que o Lustre tem um bom desempenho em termos de construção e desempenho em larga escala, portanto, de 2017 a 2022, usaremos o Lustre para transportar todos os serviços de dados.
No entanto, à medida que mais e mais GPUs são usadas e agora têm uma capacidade de processamento de ponto flutuante de cerca de 570 exaflops/s, o IO do armazenamento subjacente não consegue mais acompanhar a capacidade de computação da camada superior . Portanto, começamos a explorar um novo armazenamento e atualizar para expansão de armazenamento subsequente.Ao mesmo tempo, também encontramos alguns problemas no processo de uso do Lustre.
Primeiro: o método de operação e manutenção . O Luster é baseado principalmente no kernel e está diretamente embutido no kernel. Às vezes, o problema de posicionamento envolverá operações como reiniciar a máquina;
Segundo: pilha de tecnologia , porque o desenvolvimento de nossa plataforma de nuvem é baseado principalmente em golang, então preferimos usar armazenamento mais compatível com a linguagem de desenvolvimento. O Luster usa a linguagem C, que requer mais mão de obra em termos de customização e otimização.
Terceiro: confiabilidade de dados . O Lustre depende principalmente da confiabilidade do hardware (como a tecnologia RAID), e a camada de software implementa principalmente a solução HA de nós de metadados e nós de objetos e dados. Em comparação com estes, ainda preferimos usar soluções de software mais confiáveis, como três cópias ou códigos de eliminação.
Quarto: os requisitos funcionais do cache multinível . Em 2021, usaremos o Fluid + Alluxio como a aceleração distribuída do Lustre. O Alluxio pode acelerar melhor o cálculo do nosso cluster e reduzir a pressão no armazenamento subjacente. No entanto, temos explorado a possibilidade de realizar o cache do lado do cliente diretamente do sistema de armazenamento, de modo que a operação seja mais transparente para os usuários.
Quando o JuiceFS foi aberto pela primeira vez em 2021, realizamos pesquisas sobre seus recursos.
Primeiro, características do produto : JuiceFS suporta interface POSIX e pode ser montado na forma de HostPath. Este método é exatamente o mesmo que usamos NAS, e os usuários basicamente não precisam fazer nenhuma alteração ao usá-lo; storage , existem muitas alternativas, como Redis e TiKV são mais adequadas no campo da IA. O Ceph subjacente, MinIO e alguns usuários de armazenamento de objeto de nuvem pública podem escolher por si mesmos.
Em segundo lugar, agendamento da camada superior : o JuiceFS não apenas oferece suporte ao HostPath, mas também oferece suporte ao modo de unidade CSI, que permite aos usuários acessar o armazenamento correspondente de uma maneira mais nativa da nuvem.
Terceiro, adaptação da estrutura de negócios : a interface POSIX é adaptada à estrutura de aprendizagem profunda. Quarto, operação e manutenção: o mecanismo de metadados e o armazenamento de objetos são relativamente maduros no setor e há muitas opções, e o JuiceFS possui funções automáticas de backup de metadados e lixeira. O JuiceFS se encaixa bem no negócio, então realizamos um teste POC.
O ambiente de teste é mostrado na figura acima. Comparado com o JuiceFS, descobriu-se que o JuiceFS usa diretamente o cache da página do kernel e, em comparação com o acesso direto do Luster ao disco mecânico, o desempenho é bastante aprimorado (conforme mostrado na figura abaixo, quanto menor melhor).
Após o teste POC, decidimos trazer o JuiceFS para o ambiente de produção. No momento, todos os nós de computação GPU de todo o cluster Atlas, bem como todos os nós de desenvolvimento e depuração, instalaram o cliente JuiceFS.
O JuiceFS se conecta diretamente ao cluster redis e ceph, e a maioria dos nós de computação usa o HostPath para acessar. Ao mesmo tempo, o JuiceFS CSI Driver também é implantado no cluster Atlas e os usuários podem acessá-lo de maneira nativa da nuvem.
Como o JuiceFS é usado no Atlas
Para garantir a segurança dos dados, cada grupo na plataforma de supercomputação pertence a um diretório diferente, cada diretório são os membros do respectivo grupo ou departamento e os diretórios entre diferentes grupos são invisíveis .
As permissões do diretório são baseadas no mecanismo de controle de permissão do Linux. Quando um usuário envia uma tarefa de treinamento no cluster Atlas, a ferramenta de envio de tarefas do cluster lê automaticamente as informações de UID e GID do usuário no sistema e as injeta no campo SecurityContext do pod de tarefa enviado pelo usuário e, em seguida, no contêiner O pod em execução no cluster Atlas irá Os UIDs dos processos em execução de todos os contêineres são consistentes com as informações no sistema de armazenamento para garantir que as permissões não ultrapassem o limite.
Os nós acessam o JuiceFS para implementar o cache multinível:
-
O primeiro nível: o cache é o cache da página da memória.
-
Nível 2: vários SSDs em todos os nós de computação fornecem recursos de aceleração de nível 2.
-
O terceiro nível: use o Ceph. Se três SSDs de 1 t ainda não puderem suportar dados do usuário, eles serão lidos do Ceph.
No início de 2021, a Unisound e a equipe do JuiceFS integrarão o JuiceFSRuntime ao Fluid. Como o cache é usado de maneira bare-metal, descobrimos que a visibilidade do cache não é boa para os usuários. O sistema limpa automaticamente o cache e a capacidade de controle do usuário não é tão alta. É por isso que integramos o JuiceFS em Fluido.
O Fluid iniciará os componentes relacionados ao JuiceFS, incluindo FUSE e Worker Pod. Entre eles, o FUSE Pod fornece a capacidade de cache do cliente JuiceFS, e o Worker Pod realiza o gerenciamento do ciclo de vida do cache. A tarefa de treinamento offline AI da plataforma Atlas interage com o cliente FUSE Pod para ler dados de treinamento AI .
Por meio dos recursos de agendamento de cache fornecidos pelo Fluid e da observabilidade de conjuntos de dados, os usuários da plataforma podem implantar caches em nós de computação específicos por meio de agendamento de afinidade e, ao mesmo tempo, os usuários podem ver intuitivamente o uso de caches (como os dados em cache conjuntos) tamanho, porcentagem de cache, capacidade de cache, etc.).
Prática de construção de JuiceFS
Atualmente, o Atlas não pode acessar a rede pública e está em uma rede isolada dedicada, portanto, todas as nossas implantações são privatizadas.
O mecanismo de metadados do nosso ambiente de produção usa Redis. Em 2020, a conexão entre TiKV e JuiceFS não está muito madura. Planejamos usar Redis primeiro para a transição e usar Ceph para armazenamento de objetos. O disco do sistema do nó Redis é configurado com RAID1 e os dados persistentes do Redis serão sincronizados periodicamente com outro nó de backup. Para persistência de dados Redis, usamos a solução AOF + RDB para persistir dados a cada segundo.
O armazenamento de objetos usa um cluster Ceph criado automaticamente e o cluster Ceph é implantado usando Cephadm. O ambiente de produção atual usa a versão Octopus. Naquela época, pegamos muitas soluções da indústria, otimizamos a memória no nível da memória e fizemos os ajustes correspondentes no nível do software, principalmente da seguinte forma:
Nível do servidor (referência) : • 42 núcleos 256GB 24 18T HDD • Disco do sistema: 2 960G SAS SSD • BlueStore • Desativar NUMA • Atualizar kernel: 5.4.146 Ativar io_uring • Kernel pid max, modificar /proc/sys/kernel/pid_max
Configuração do Ceph : • Ceph RADOS: chame diretamente a interface librados, não use o protocolo S3 • Bucket shard • Desative a função de ajuste automático de pg • Armazenamento de log OSD (usando bluestore, a proporção recomendada de capacidade bruta - bloco : bloco.db : block. wal = 100:1:1, SSD ou SSD NVMe é recomendado para os dois últimos) • 3 cópias
É importante mencionar que o kernel do cluster Ceph deve ser atualizado para uma versão mais recente e, em seguida, a função io_uring deve ser habilitada, para que o desempenho seja bastante aprimorado. Em termos de software, chamamos diretamente a interface rados em vez de usar o protocolo S3, e a eficiência será um pouco maior.Todos os nós estão interconectados com a rede 100G InfiniBand de alta velocidade.
O armazenamento de objetos conectado ao JuiceFS no ambiente Yunzhisheng é o Ceph RADOS. O JuiceFS usa librados para interagir com o Ceph, portanto, o cliente JuiceFS precisa ser recompilado. Recomenda-se que a versão do librados corresponda à do Ceph. Preste atenção a isso apontar. Caso você utilize o Driver CSI, ele será lido na criação do PV/PVC, devendo /etc/ceph/ceph.conftambém atento ao suporte da versão.
Sistema de monitoramento perfeito
Agora, todo o link é relativamente longo. A camada inferior tem clusters de mecanismo de metadados, clusters de armazenamento de objetos Ceph e clientes e serviços da camada superior. Cada camada deve ter uma solução de monitoramento correspondente.
Para o nó cliente, coletamos principalmente logs. Deve-se observar que os logs do cliente JuiceFS de cada ponto de montagem precisam ser agregados e alarmes de erro são necessários para evitar que os logs explodam o disco do sistema ou o nó não possa ser gravado.
Cada cliente JuiceFS também deve ter métodos de monitoramento correspondentes, como verificar se os arquivos .stat e os indicadores de observação de log de cada ponto de montagem estão normais e, em seguida, verificar o IO e os logs dos clusters Redis e Ceph para garantir que todo o link seja controlável Sim , é mais conveniente localizar o problema dessa maneira.
A imagem acima é a imagem de monitoramento do Ceph, porque nossos nós clientes usam cache SSD e agora os dados basicamente não são lidos no Ceph, a maioria dos dados é lida do cache, portanto, o tráfego do Ceph não é grande.
A imagem acima são os dados interceptados pelo monitoramento do JuiceFS. Pode-se ver que 100% a 90% dos nós podem ser atingidos. A taxa de acerto do cache ainda é relativamente alta e a maioria dos dados ainda está no cache.
Participe da construção da comunidade JuiceFS
A UniSound tem participado ativamente na construção da comunidade durante o processo de uso do JuiceFS Community Edition. Em 2021, trabalhei com a equipe JuiceData para desenvolver o Fluid JuiceFS Runtime mencionado acima. Recentemente, descobrimos que a cota baseada em diretório da versão da comunidade ainda não foi desenvolvida, então desenvolvemos uma versão há alguns meses, que limita o número de arquivos no diretório e o tamanho do arquivo. O PR foi enviado e agora está trabalhando com a comunidade JuiceFS Faça o trabalho de mesclagem.
Cenários de uso e benefícios do JuiceFS no Atlas
Atualmente, o cache multinível do cliente JuiceFS é usado principalmente em nossos cenários de reconhecimento de texto, redução de ruído de fala e reconhecimento de fala. Como a leitura de dados do treinamento do modelo de IA é caracterizada por mais leitura e menos gravação, fazemos uso total do cache do cliente JuiceFS para trazer os benefícios de aceleração da leitura de IO.
Benefício 1: Acelere o treinamento do modelo de IA
1) Teste de redução de ruído de fala
Arquivos dispersos são usados no teste do modelo de cena de redução de ruído. Cada dado está no formato wav, um pequeno arquivo de voz menor que 100k. Na cena de redução de ruído, testamos os dados de I/O no estágio de carregamento de dados e o memória do nó cliente JuiceFS. O cache é de 512 G, e o teste é realizado com um tamanho de lote de 40 sob os dados da escala de 500h.
A partir dos resultados do teste, apenas em termos de eficiência de leitura de dados, em termos de pequenos arquivos wav, o JuiceFS é de 6,45 it/s, enquanto o Luster é de 5,15 it/s, e o desempenho é melhorado em 25%. O JuiceFS acelerou efetivamente nosso treinamento de modelo de ponta a ponta e encurtou o tempo geral de saída do modelo.
2) Cena de reconhecimento de texto
No cenário de reconhecimento de texto, o modelo é CRNN backbone e MobileNet v2, e o ambiente de teste é o seguinte:
Um grande arquivo de dados de LMDB é gerado. Neste momento, o IO tem requisitos de largura de banda relativamente altos, em vez de requisitos de desempenho para arquivos pequenos. O cache de memória de 200G pode suportar todos os dados, portanto, em vez de usar o armazenamento subjacente, lemos diretamente do cliente e o desempenho geral também foi bastante aprimorado.
Neste teste, a comparação de velocidade entre JuiceFS e Lustre é feita principalmente. De acordo com os resultados experimentais, leva-se 1,5s para ler cada lote do Lustre e 1,1s para ler cada lote do JuiceFS, um aumento de 36%. Da perspectiva do tempo de convergência do modelo, das 96 horas do Luster para as 86 horas do JuiceFS, o uso do JuiceFS pode reduzir o tempo de saída do modelo CRNN em 10 horas.
Depuração de modelo e processamento de dados
Ao fazer a depuração de código, vários usuários executarão testes de modelo e passagem de código em uma máquina de depuração ao mesmo tempo. Naquela época, a maioria dos usuários usaria alguns IDEs remotos, conectar-se-ia a nós de depuração e, em seguida, criaria seu próprio ambiente virtual, instalaria um grande número de pacotes de instalação no Lustre com antecedência.
A maioria deles são pequenos arquivos de dezenas de k ou centenas de k, e precisamos importar esses pacotes para nossa memória. Ao usar o Lustre antes, porque há muitos usuários, a taxa de transferência necessária é alta. Ao mesmo tempo, os requisitos de desempenho para arquivos pequenos são relativamente altos. Descobri que o efeito não é muito bom. Ao importar pacotes, será relativamente travado, resultando em depuração de código lenta e eficiência geral relativamente baixa.
Mais tarde, foi usado o cache do cliente JuiceFS, e a primeira compilação também foi relativamente lenta, mas a segunda compilação porque todos os dados foram colocados no cache, a velocidade e a eficiência foram maiores e o salto de código foi mais rápido. importações insinuantes também são mais rápidas. Após o teste do usuário, há um aumento de velocidade de cerca de 2 a 4 vezes.
epílogo
Do Luster ao JuiceFS
De 2017 a 2021, quando usamos o Lustre, também é relativamente estável. Quando a capacidade de armazenamento do cluster é inferior a 50%, a estabilidade do software é relativamente alta.
Como um sistema de armazenamento no campo veterano de HPC, o Lustre tem alimentado muitos dos maiores sistemas de supercomputação do mundo e tem muitos anos de experiência em ambientes de produção. Tem as vantagens de estar em conformidade com o padrão POSIX, suporta várias redes de alto desempenho e baixa latência e permite acesso RDMA, é adequado para computação de alto desempenho no campo tradicional de HPC e é compatível com a interface de aprendizado profundo. Todos os negócios não precisam ser modificados no código. Mas também existem algumas desvantagens:
Primeiro, o Lustre não oferece suporte ao driver CSI nativo da nuvem.
Em segundo lugar, o Lustre tem requisitos relativamente altos para o pessoal de operação e manutenção, porque é todo escrito em linguagem C, às vezes alguns bugs não podem ser resolvidos rapidamente e a comunidade em geral não é muito aberta e ativa.
O JuiceFS possui os seguintes recursos:
Em primeiro lugar, o JuiceFS é um produto de sistema de armazenamento distribuído no campo nativo da nuvem . Ele fornece CSI Driver e Fluid para uma melhor integração com o Kubernetes.
Em segundo lugar, o esquema de implantação do JuiceFS é relativamente flexível e o mecanismo de metadados é altamente opcional.Se a rede do usuário permitir o armazenamento de objetos, na verdade é melhor conectar-se ao armazenamento de objetos da nuvem pública.
Em terceiro lugar, é relativamente simples em termos de operação e manutenção de expansão de armazenamento . Totalmente compatível com o padrão POSIX, a aplicação de aprendizado profundo pode ser migrada sem problemas, mas devido às características do armazenamento de objetos de back-end, o JuiceFS terá um alto atraso na gravação aleatória.
Quarto, o JuiceFS suporta cache local e cache de página do kernel, que realiza a sobreposição e aceleração de dados quentes e frios . Isso é o que mais valorizamos, é mais adequado em nossos cenários de negócios, mas não é adequado para escrita aleatória. A função de cache distribuído da versão da comunidade ainda não está disponível.
Planejamento subsequente
• Atualização do mecanismo de metadados, o TiKV é adequado para cenários com mais de 100 milhões de arquivos (pode suportar até 10 bilhões de arquivos) e possui altos requisitos de desempenho e segurança de dados. No momento, concluímos o teste interno do TiKV e estamos ativamente trabalhando nisso Para acompanhar o progresso da comunidade, o mecanismo de metadados será migrado para o TiKV no futuro. • Otimização da cota do diretório. No momento, as funções da versão básica foram integradas à versão da comunidade JuiceFS. Também foram realizadas discussões com a comunidade JuiceFS. Em alguns cenários, algum desempenho precisa ser otimizado. • Espero fazer algumas funções não root. Agora todos os nós têm autoridade de root para acessar todos os dados. A autoridade é muito grande. Esperamos abrir autoridade de root apenas em nós específicos. • Por fim, verificaremos se existe uma solução de QoS na comunidade, como limite de velocidade baseado em UID ou GID.
Se você for útil, preste atenção ao nosso projeto Juicedata/JuiceFS ! (0ᴗ0✿)