Transformei armazenamento em nuvem barato em um disco local de 1PB (com JuiceFS)

PortuguêsالعربيةDeutschEnglishEspañolFrançaisहिन्दीBahasa Indonesia日本語한국어Русский中文
BBetter Stack
Computing/SoftwareInternet Technology

Transcript

00:00:00Este é o Juice.FS. É um sistema de arquivos distribuído de código aberto e alto desempenho, projetado para oferecer a escalabilidade infinita do armazenamento de objetos em nuvem com a funcionalidade completa e a velocidade de um sistema de arquivos local.
00:00:14Neste vídeo, vamos dar uma olhada no Juice.FS, ver como ele funciona e vou mostrar como você pode configurar sua própria solução de armazenamento em rede (NAS) local de alto desempenho com o Juice.FS.
00:00:24Vai ser muito divertido, então vamos começar.
00:00:30Armazenamentos de objetos padrão como S3, Google Cloud Storage ou Backblaze B2 são incrivelmente econômicos, mas interagir com eles normalmente exige APIs ou ferramentas especializadas que quebram os fluxos de trabalho tradicionais das aplicações.
00:00:48O Juice.FS atua como uma camada de abstração transparente.
00:00:51Ele separa seus dados dos metadados, enviando blocos de dados brutos diretamente para o seu provedor de nuvem, enquanto gerencia o layout do sistema de arquivos, permissões e estruturas de diretórios dentro de um banco de dados rápido como Redis, Postgres ou TiKV.
00:01:07O que torna o Juice.FS completamente diferente dos gateways de nuvem tradicionais ou compartilhamentos de arquivos de rede padrão é essa separação arquitetural estrita e seu mecanismo de cache multi-nível agressivo.
00:01:19Em vez de forçar suas aplicações a esperarem por solicitações de rede em nuvem de alta latência toda vez que um arquivo é acessado,
00:01:26o Juice.FS quebra arquivos em blocos pequenos e otimizados e utiliza uma partição NVMe ou SSD local como um espaço de trabalho rápido.
00:01:35Na primeira vez que uma aplicação lê ou grava dados, ela se comunica pela rede, mas na segunda vez que esses dados são solicitados, eles são servidos instantaneamente a partir do armazenamento local na velocidade do hardware.
00:01:47Isso permite que aplicações legadas, bancos de dados, treinamento de aprendizado de máquina e ambientes de contêiner rodem diretamente sobre o armazenamento de objetos sem reescrever uma única linha de código.
00:01:59Tudo isso parece ótimo, mas vamos testar e ver como funciona.
00:02:04Para esta demonstração, vou configurar um armazenamento em rede (NAS) local, que hospedará todos os meus dados no meu próprio bucket S3 remoto e usará o Redis como nosso mecanismo de metadados.
00:02:16A primeira coisa que você deve fazer é subir uma instância do Redis com Docker, e você pode fazer isso facilmente com este comando.
00:02:24E então precisamos inicializar o sistema de arquivos executando o comando de formatação do juice.FS.
00:02:29Esta etapa diz ao juice.FS exatamente como mapear nosso banco de dados para nosso bucket de armazenamento.
00:02:34Passamos nossa string de conexão Redis, o nome do nosso bucket AWS S3 e nossas credenciais de acesso à nuvem.
00:02:41Mas antes de fazer tudo isso, certifique-se de ter criado um bucket S3, uma chave de acesso e uma chave secreta antes de executar este comando.
00:02:48Eu já tinha criado os meus anteriormente.
00:02:50Então, agora, quando executo isso, o juice.FS ainda não altera nada dentro do nosso bucket S3.
00:02:56Ele simplesmente configura o esquema de armazenamento dentro do Redis e atribui um UUID exclusivo ao nosso novo sistema de arquivos virtual.
00:03:03E uma vez concluída a etapa de formatação, montamos o dispositivo em nossa máquina local usando o comando de montagem do juice.FS.
00:03:10Apontamos o juice.FS para nossa instância do Redis e fornecemos um caminho de diretório local.
00:03:15No meu caso, uma pasta dentro do meu diretório pessoal.
00:03:18E antes de executar isso, há um aviso importante.
00:03:21Se você estiver em um Mac, como o Mac OS não suporta sistemas de arquivos personalizados nativamente, você precisa instalar primeiro um utilitário de extensão de kernel chamado Mac Fuse.
00:03:30Isso fornece os ganchos de software subjacentes que o juice.FS precisa para se comunicar com o sistema operacional Mac.
00:03:37E também estou fornecendo este parâmetro com a proporção de espaço livre, porque, por padrão, ele define como 20% do seu drive, o que é bem alto.
00:03:47Basicamente, ele diz ao juice.FS que, se o drive local que hospeda seu cache cair abaixo de uma certa porcentagem da sua capacidade total,
00:03:55ele precisa parar de gravar novos arquivos de cache e começar a purgar agressivamente os blocos mais antigos e menos acessados.
00:04:01Isso evita que seu sistema operacional local fique completamente sem espaço em disco.
00:04:05Tudo bem.
00:04:06Então, agora vamos executar este comando.
00:04:07E no segundo em que ele é executado, o sistema operacional registra uma montagem de sistema de arquivos compatível com POSIX.
00:04:15E para o computador, parece que acabamos de conectar um enorme disco rígido externo com um terabyte de espaço disponível.
00:04:23E agora posso arrastar arquivos facilmente para este diretório como se fosse um drive externo.
00:04:28E se formos agora para o painel do bucket S3, veremos que o juice.FS armazenou nossos arquivos e os dividiu em blocos de dados.
00:04:37E tudo isso acontece nos bastidores e não precisamos fazer nenhum trabalho pesado.
00:04:42E para mostrar como o cache funciona, vamos avaliar o desempenho do sistema de arquivos usando um comando de terminal clássico: o DD.
00:04:49Se você ainda não usou o DD, ele é um utilitário integrado usado para cópia de dados brutos.
00:04:55E neste comando específico, 'if' significa arquivo de entrada, que está apontando para um de nossos arquivos de vídeo grandes que adicionei ao nosso drive juice.FS.
00:05:03E o 'of' significa arquivo de saída.
00:05:06Estamos direcionando esses dados diretamente para /dev/null, que é basicamente um buraco negro em nosso sistema operacional que descarta os dados instantaneamente, porque não estamos realmente copiando os dados.
00:05:17Estamos apenas fazendo um benchmark neste exemplo.
00:05:19Também definimos o tamanho do bloco para quatro megabytes para corresponder à forma como o juice.FS fatia os blocos de dados.
00:05:25E, finalmente, prefixamos toda a linha com o utilitário 'time' para podermos ver exatamente quanto tempo leva a transferência do arquivo.
00:05:32E na primeira vez que pressionamos Enter, isso é o que chamamos de leitura a frio, porque o arquivo acabou de ser enviado.
00:05:38Nossa máquina local ainda não tem uma cópia dele.
00:05:41Então, o juiceFS precisa se conectar pela Internet ao nosso bucket S3, buscar todos esses blocos de dados de quatro megabytes um por um e transmiti-los.
00:05:50E na minha conexão, a primeira execução leva, como você pode ver, um tempo consideravelmente longo.
00:05:55Mas veja o que acontece quando executamos exatamente o mesmo comando pela segunda vez.
00:05:59Então, bum.
00:06:00Aí está.
00:06:01O prompt do terminal retorna quase instantaneamente.
00:06:03A segunda execução levou menos de um segundo porque agora está em nosso cache e estamos lendo organicamente.
00:06:10Então, é assim que o mecanismo de cache multi-nível funciona na prática.
00:06:14Enquanto o juiceFS estava ocupado baixando esses blocos durante nossa primeira execução, ele estava silenciosamente copiando-os para nosso disco local NVMe.
00:06:22Mas na segunda passagem, o sistema ignorou a Internet completamente, extraindo os dados diretamente da velocidade do hardware local.
00:06:29Então você obtém a capacidade de armazenamento infinita e barata da nuvem combinada com a velocidade de latência zero de um drive local.
00:06:37Nesta demonstração, usei arquivos de vídeo para mostrar a funcionalidade, mas isso se aplica a quase qualquer cenário de infraestrutura do mundo real.
00:06:45Se você é um engenheiro de DevOps gerenciando ambientes de contêiner, pode simplesmente usar o juiceFS para fornecer armazenamento persistente compartilhado em um cluster Kubernetes.
00:06:54E em vez de pagar por caro armazenamento em bloco na nuvem para cada nó, todos os seus pods podem montar o mesmo volume juiceFS simultaneamente.
00:07:03Compartilhando arquivos de configuração, ativos de aplicação ou uploads de usuários globalmente enquanto mantém os custos incrivelmente baixos.
00:07:10E também é uma grande vitória para pipelines de aprendizado de máquina e ciência de dados.
00:07:14Porque, se você tem um conjunto de dados enorme, digamos, centenas de gigabytes de imagens de treinamento ou dados de texto em um bucket S3, treinar um modelo de ML geralmente requer baixar todo esse conjunto de dados localmente primeiro, o que desperdiça tempo e espaço de armazenamento.
00:07:30Mas com o juiceFS, seu script de treinamento pode começar a rodar instantaneamente.
00:07:35O pipeline lê os dados sequencialmente através da montagem e o juiceFS lida com a transmissão de alta taxa de transferência e cache local em segundo plano, mantendo suas GPUs totalmente saturadas sem gargalos de armazenamento local.
00:07:49E tem mais uma coisa legal que quero mostrar.
00:07:51Você também pode conectar facilmente métricas ao seu sistema de arquivos com o Better Stack.
00:07:55Toda vez que você monta um volume juiceFS, ele inicia silenciosamente um servidor de métricas compatível com Prometheus em segundo plano.
00:08:03Se você abrir seu navegador e for para este URL, poderá ver todas as métricas aqui em texto simples, rastreando cada acerto de cache, duração da leitura e erros de solicitação S3 em tempo real.
00:08:13E para enviar esses dados de telemetria diretamente para nosso painel, podemos usar o recurso de scraping Prometheus nativo do Better Stack.
00:08:21Primeiro, precisamos ir para as fontes e conectar nosso juiceFS como uma fonte.
00:08:25E vamos escolher Prometheus scrape na aba de métricas e clicar em conectar fonte.
00:08:31Agora precisamos ingerir nossos logs.
00:08:33Mas antes de fazer isso, precisamos abrir um túnel público seguro para nossa porta de métricas local usando uma ferramenta como o ngrok e então colar nosso URL do ngrok.
00:08:43Mas para funcionar com o ngrok, também precisamos ir para as opções avançadas e adicionar um cabeçalho HTTP personalizado chamado “ngrok-skip-browser-warning” e defini-lo como “true”.
00:08:53Isso diz ao ngrok para ignorar a página de aviso completamente, permitindo que o Better Stack raspe métricas brutas com segurança a cada poucos segundos.
00:09:01E agora nossas métricas devem começar a ser ingeridas automaticamente.
00:09:05E deixe-me mostrar a parte mais legal.
00:09:07Se formos agora para o AI SRE do Better Stack, podemos simplesmente pedir ao AI SRE para criar um painel que monitore o desempenho do cache ou a latência e a taxa de transferência do nosso sistema.
00:09:19E em alguns segundos, o AI SRE criará um painel lindo e personalizado com todas as métricas vindas do juiceFS.
00:09:27E também podemos ver que ele está atualizando em tempo real.
00:09:32Então, quão legal é isso?
00:09:34Então, espero que esta pequena demonstração mostre o quão poderoso o juiceFS pode ser quando você o combina com o monitoramento de infraestrutura moderno.
00:09:41Conseguimos pegar um bucket de armazenamento em nuvem barato e padrão, transformá-lo em um drive local infinitamente escalável operando na velocidade do hardware e conectá-lo a um painel de observabilidade totalmente automatizado em apenas alguns minutos.
00:09:57Então, aí está, pessoal.
00:09:58Isso é o juiceFS em poucas palavras.
00:10:00O que você acha do juiceFS?
00:10:02Você já experimentou?
00:10:03Você vai usar?
00:10:04Deixe-nos saber na seção de comentários abaixo.
00:10:06E pessoal, se vocês gostam desses tipos de detalhamentos técnicos, por favor, me avisem esmagando esse botão de curtir abaixo do vídeo.
00:10:12E também não se esqueçam de se inscrever no nosso canal.
00:10:15Este foi Andrus, do BetterStack, e vejo vocês nos próximos vídeos.

Key Takeaway

O JuiceFS transforma armazenamento em nuvem de baixo custo em uma unidade local de alto desempenho ao utilizar uma arquitetura de metadados separada e um cache local agressivo em discos NVMe.

Highlights

  • O JuiceFS separa metadados em bancos de dados como Redis ou Postgres e armazena blocos de dados brutos em serviços de nuvem como S3 ou Backblaze B2.

  • O mecanismo de cache multi-nível do JuiceFS utiliza discos locais NVMe ou SSD para reduzir a latência de acesso a dados armazenados na nuvem.

  • A montagem de um volume JuiceFS disponibiliza um sistema de arquivos compatível com POSIX, permitindo que aplicações interajam com o armazenamento de nuvem sem alterações no código.

  • A purga automática de arquivos em cache garante que o armazenamento local não exceda a capacidade definida, com o limite padrão configurado para 20% do volume total.

  • Integrações nativas permitem o monitoramento em tempo real de métricas como acertos de cache e latência de leitura via endpoints compatíveis com Prometheus.

Timeline

Arquitetura e funcionamento do JuiceFS

  • O JuiceFS atua como uma camada de abstração entre aplicações e armazenamento em nuvem.
  • Dados brutos são armazenados em buckets de objeto, enquanto metadados residem em bancos de dados rápidos como Redis.
  • O cache local em NVMe ou SSD elimina a latência de rede em acessos subsequentes aos mesmos dados.

O sistema diferencia-se de gateways tradicionais através da separação estrita de dados e metadados. Ao dividir arquivos em blocos otimizados, o sistema permite que aplicações acessem dados via rede apenas na primeira leitura. Posteriormente, o hardware local serve as solicitações, viabilizando o uso de nuvem para cargas de trabalho de alta performance, como aprendizado de máquina e contêineres, sem necessidade de reescrita de código.

Configuração do sistema de arquivos

  • A inicialização requer uma instância do Redis e um bucket S3 com credenciais ativas.
  • A formatação do sistema cria um UUID exclusivo que mapeia o banco de dados aos dados em nuvem.
  • Sistemas macOS exigem o utilitário Mac Fuse para suportar a montagem de sistemas de arquivos personalizados.

A implementação inicia-se com a execução do comando de formatação do JuiceFS para definir o esquema de armazenamento. Após o mapeamento, o volume é montado no diretório local, comportando-se como um disco rígido externo de grande capacidade. O gerenciamento de espaço livre impede que o cache local sature o disco do sistema operacional, removendo automaticamente blocos antigos ou menos acessados.

Benchmarking e casos de uso

  • Testes com o utilitário DD demonstram que acessos a arquivos em cache ocorrem quase instantaneamente.
  • Ambientes Kubernetes utilizam o sistema para oferecer armazenamento persistente compartilhado entre múltiplos pods.
  • Pipelines de ciência de dados evitam o download completo de datasets ao ler dados sequencialmente através do cache do JuiceFS.

O desempenho do cache é validado ao comparar a leitura a frio, que depende da latência da rede, com a segunda execução, que utiliza o cache local para velocidade de hardware. Esta funcionalidade reduz custos de armazenamento em bloco na nuvem e otimiza fluxos de treinamento de modelos de ML, mantendo GPUs saturadas ao eliminar gargalos de transferência.

Observabilidade e monitoramento

  • Servidores de métricas compatíveis com Prometheus iniciam automaticamente durante a montagem do volume.
  • Ferramentas como o Better Stack permitem o monitoramento de acertos de cache e erros de solicitação em tempo real.
  • Túneis seguros via ngrok viabilizam a coleta externa de métricas de infraestrutura.

O JuiceFS expõe telemetria bruta via um servidor Prometheus nativo. Ao utilizar ferramentas como o ngrok com cabeçalhos personalizados para contornar avisos, é possível ingerir dados de telemetria em painéis de monitoramento modernos. O uso de IA para análise de SRE permite criar visualizações automatizadas de latência e taxa de transferência baseadas nos dados coletados do sistema de arquivos.

Community Posts

No posts yet. Be the first to write about this video!

Write about this video