ClonOS - Uma alternativa ao Proxmox baseado no FreeBSD

 Depois que Xen server passou a ser pago, muitos profissionais passaram a migrar os seus clientes para outra solução como o Proxmox, o xcp-ng, o oVirt e até mesmo o Openshift da Red Hat que possui suporte a virtualização; a Nutanix também entra nesta briga como uma briga como concorrente da VMWare e muitas vem migrando para containers o máximo de aplicações possíveis e que pode gerar economia ainda maior:

 No ano passado, a VMWare foi adquirida pela Boradcom pelo valor de US$ 61 bilhões (uma das mais caras aquisições da indústria de tecnologia). Após esta aquisição, os produtos e serviços da VMWare passaram a ficar mais caros e consequentemente, as empresas que as possuíam, passaram a buscar outras soluções em virtualização. Há empresas que já mantinham outras alternativas de virtualização atuando paralelamente dentro de suas infraestruturas exatamente para se prevenirem de casos inesperados (lógico que tudo isso tem um custo que a curto prazo pode parecer caro, mas não quando necessário remediar a situação). Bom, e no meio de tantas soluções de virtualização no Linux (Linux é o sistema operacional com o melhor suporte a virtualização que existe), uma equipe desenvolvedores de FreeBSD decidiu projetar uma alternativa que a chamaram ClonOS. 

• Virtualization limits for Red Hat Enterprise Linux with KVM - Red Hat Customer Portal
• Virtualization Tuning and Optimization Guide | Red Hat Product Documentation
• Manual: qm.conf - Proxmox VE

ClonOS: Uma alternativa ao Proxmox Baseada no FreeBSD

 ClonOS é uma plataforma baseada no FreeBSD e no framework CBSD que eu já abordei aqui no blog no artigo CBSD sendo portado para DragonflyBSD. O ClonOS vem com interface web para facilitar o controle, deploy e gerenciamento dos containers jails do FreeBSD e dos ambientes de virtualização tanto do Bhyve quanto do Xen. Além disso, o ClonOS disponibiliza suporte ao 9p (sistema de arquivos do plan9 utilizado o WSL) para ser utilizado no compartilhamento de diretórios do bhyve via virtio-p9; Bhyve management para criar e excluir VMs; conexão com console "físico" de convidado via VNC do navegador ou diretamente pelo sistema; monitoramento em tempo real; acesso a estatísticas de carga através do SQLite3 e beanstalkd; suporte a ZFS; import/export de ambientes virtuais; repositório público com virtual machine templates e ajuda baseada em puppet para a configuração de serviços populares. Há ferramentas que estão em andamento.

Site oficial do ClonOS

Mais sobre virtualização

Mais sobre FreeBSD

QUER APRENDER LINUX? ENTÃO CONFIRA O MEU CURSO DE MIGRAÇÃO PARA LINUX CLICANDO AQUI :)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

BetrFS: Um sistema de arquivos com otimização de B-trees

 Após publicar a matéria sobre o sistema de arquivos GEFS estar sendo portado para os OpenBSD, eu me senti inspirado em escrever este artigo sobre o sistema de arquivos BetrFS (já que o Bε trees serviu de base para a criação do GEFS).

 Bε-tree File System, ou BetrFS é um sistema de arquivos Linux que utiliza BƐ-trees ao invés do tradicional B-tree como sua estrutura de dados para a otimização de escrita. O BetrFS foi baseado na implementação do fractal tree da empresa Tokutek Inc. Apesar de ainda ser um projeto em desenvolvimento (ultima versão lançada foi a v0.6 em Fevereiro de 2022 mas a realmente verificada é a 0.4.1 de Janeiro de 2021), o BetrFS já apresenta grandes resultados em seus objetivos Como podem ser conferidas nas tabelas abaixo:

Benchmarks do BetrFS

 A equipe do projeto conseguiu atingir seus objetivos ao adotar recursos como Write-Optimized Indexes (também conhecido como WOIs que podem acelerar as operações do sistema de arquivos); Upserts; folhas maiores (Large leaves (2-4 MB); Blind Writes (essencial para o ganho de desempenho por tratar escritar mais rápidas do que as leituras e quando possível, evita leitura em favor da escrita); Lexicographic ordering on disk que ordena dados e metadados para leituras e buscas sequenciais.

 Mas como todo sistema de arquivos, o BetrFS também possui seu prós e contras (o que cabe a cada um de nós avaliar quando deve ser adotados). O pró do BetrFS está em trabalhar com escrita sequencial de arquivos menores, scan (como o comando grep) e buscas no sistema de arquivos (como o comando find). Por outro lado, o seu contra está em trabalhar com arquivos grandes de quase todas as formas (I/O sequencial de arquivos grandes, exclusão de arquivos grandes e renomear arquivos grandes); nesta parte ainda há trabalhos a serem feitos.

Conclusão

 Ainda há muito trabalho a ser feito, mas o BetrFS já está sendo cotado como um sistema de arquivos que pode ser utilizado no mundo real. Quando em uso, o BetrFs segue uma pilha no seguinte padrão:

VFS -> BetrFS * -> B^e Tree * -> ext4

BetrFS utilizado como pilha de sistema de arquivos

 O que me leva a pensar se no futuro a equipe de desenvolvimento do Ext4 não abandone o B-tree e passe a adotar o Bε-tree como arvore padrão (lembrando que não necessariamente um sistema de arquivos está preso a um modelo de estrutura de arvore. O Ext4 sobre sofre de certas limitações em seu design já que ele é baseado no sistema de arquivos do sistema operacional Minix mas pode ser que não na parte de tree). Isso poderia lhe dar uma sobrevida já que o Ext4 está sendo abandonado até mesmo no Android como filesystem padrão. E porque não também no Btrfs? Seria uma ideia interessante quando o Bε-tree evoluir mais.

Agradecimento

 A meu aluno Júlio Cezar que revisou o texto e descobriu que o link o BetrFS não estava acessível.

Site oficial do BetrFS

Mais sobre o Btrfs

Quer aprender Linux de verdade? Então confira o meu curso de migração para Linux clicando aqui 

Agora também disponível na PLATAFORMA WORKOVER

Quer aprender Linux de verdade? Então confira o meu curso de migração para Linux clicando aqui 

Agora também disponível na PLATAFORMA WORKOVER

Seja Membro Premuim do Regata OS e ganhe prêmios e suporte

OpenZFS receberá suporte a expansão de RAID

 Adicionar novos dispositivos a um sistema de arquivos Btrfs ou redimensiona-lo é algo muito simples devido a sua flexibilidade e eu ensino no meu curso de migração para Linux. O Btrfs ainda não implementa todos os recursos que o ZFS mas tratando de implementação dos mesmos recursos, o Btrfs está muito a frente do ZFS.

 Porém, e quanto ao ZFS? Esse é um recurso muito esperado no ZFS e que desde que surgiu (há uns 16 anos) que não havia sinais de um dia ter. Uma coisa que geralmente os admiradores do ZFS não contam (ao menos não no Brasil) é que o ele também possui suas limitações (algo que eu cheguei a abordar na minha série ZFS vs Btrfs).

 Porém, parece quem em breve o OpenZFS receberá suporte a expansão de RAID e a galera do FreeBSD comemorou com bastante entusiasmo.

 Até com certa razão porém, não vá com muita sede ao pote pois o recurso ainda tem suas limitações. Por enquanto parece que o recurso só funcionará no FreeBSD. Vamos aguardar para ver quando estará disponível para Linux.

 Eu promovo o Btrfs pois acho mais viável para o Linux. Apesar de ser possível utilizar o ZFS no Linux (o próprio FreeBSD passou a utilizar o ZFS on Linux como seu ZFS padrão), tanto é que Canonical passou a integrá-lo ao Ubuntu em 2016 e o habilitou no root em 2019, o problema do ZFS para o Linux está atrelado a incompatibilidade entre as duas licenças (a GPLv2 é incompatível com a CDDL). Lembrem que isso foi um problema muito grande no Debian quando Jörg Schilling mirgou o cdrtools de GPL para CDDL levando o debian a criar um fork.

Por conta disso, o próprio Linus informou para não utilizar o ZFS no Linux e caso quiser utilizar, isso fica por sua conta e risco de ter que encarar uma ação judicial da Oracle.

 Outro problema que percebo e que geralmente as pessoas não admitem é que os bugs que levam muito tempo para serem corrigidos. Dois deles eu já postei aqui sendo o primeiro foi reportado pelo engenheiro que trabalhava exatamente no ZFS e que levou coisa de dois anos para ser corrigido e o outro está no seu recurso de deduplicação e que não há previsão para ser corrigido.

 De todos os recursos presentes no Btrfs (que não são poucos), dificilmente alguma coisa é instável (seu status pode ser acompanhado aqui). O que é um marco pois eles contam com uma equipe consideravelmente pequena e é mais novo que o ZFS.

Status do Btrfs

Além do mais, o recurso que todos tanto gostam no ZFS e esperam um dia ver no Btrfs, que é a criptografia transparente, está sendo trabalhando por um engenheiro do Facebook (leia sobre isso clicando aqui).

Sobre a migração de licença do cdrtools para CDDL pode ser conferida aqui

QUER APRENDER LLINUX DE VERDADE? ENTÃO CONFIRA O MEU CURSO DE LINUX CLICANDO AQUI :) 

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Seja Membro Premuim do Regata OS e ganhe prêmios e suporte

Encontrada vulnerabilidade na deduplicação do Btrfs e do ZFS

 Deduplicação é uma técnica muito interessante para evitar redundância e duplicação de dados e assim melhor aproveitar os dados e metadados do sistema de arquivos. Este recurso é utilizado em sistemas de arquivos como o ZFS, o Btrfs e o Hammer do DragonflyBSD. Porém, esta semana foi descoberta uma vulnerabilidade muito grave neste recurso.

 

 Membros da universidade de Vrije  (Vrije Universiteit Amsterdam) encontraram uma falha de segurança no recurso de deduplicação dos sistemas de arquivos ZFS e Btrfs. O erro foi encontrado pelo grupo de pesquisadores Andrei Bacs, Saidgani Musaev, Kaveh Razavi, Cristiano Giuffrida, Herbert Bos que pretende apresentar na conferência FAST'22 (20th USENIX Conference on File and Storage Technologies) e tornar seu conhecimento publico  no dia 23 de Fevereiro deste ano.

 Essa vulnerabilidade ocorre especificamente no inline deduplication que permite o invasor utilizar uma classe de ataque chamada DUPEFS e obter arquivos sensíveis do sistema (e até arquivos secretos dos usuários) mesmo remotamente (tanto em LAN quanto em servidores na internet). Em seu paper, os pesquisadores apresentam como cada sistema de arquivos trabalha com inline deduplication para assim melhor entender como explorar a vulnerabilidade.

Como cada sistema de arquivos trabalha com inline deduplication.

 Este paper possui 15 páginas muito bem detalhado apresentando todo o cenário do ataque e todos os seus resultados tanto no Linux (utilizando ambos os sistemas de arquivos) quanto no FreeBSD. Eu incentivo a todos acompanhar sua apresentação no evento já que se trata de uma vulnerabilidade grave e que os desenvolvedores irão precisar concentrar esforços na solução do problema.

 Isso significa que estamos em risco? Em partes pode ser que sim como pode ser que não. Primeiro que, apesar da vulnerabilidade ser grave, não são todos que conseguem explorá-la; segundo que no paper os pesquisadores apresentam algumas formas de defesa (em Deduplication Defenses) como medidas paliativas como forçar a criptografia e ofuscação imposta por um gateway intermediário na rede até que soluções sejam apresentadas.

 E terceiro é que há um ponto a se considerar aqui tratando-se de Btrfs (já estou ouvindo o chilique de que sou fanboy de Btrfs). Em minha série ZFS VS Btrfs mencionei que ambos os sistemas de arquivos oferecem recursos iguais PORÉM, implementados de formas diferentes e com técnicas diferentes; deduplicação não é uma exceção a essa regra. No vídeo primeiro video da série que você pode conferir abaixo, eu explico a diferença na implementação de recursos entre os dois sistemas de arquivos. Confiram a diferença entre a deduplicação de ZFS e do Btrfs:

 Ou seja, essa vulnerabilidade não afeta o Btrfs como mencionado no paper apresentado pelos pesquisadores, pois inline deduplication já não é utilizado no Btrfs há um bom tempo. Inline deduplication para o Btrfs foi desenvolvido pela Fujitsu como pode ser lido clicando aqui e já não é mais mantido (ele foi simplesmente abandonado pois a Fujitsu não tem mais planos para ele), os patches eram incompletos e este recurso é muito complexo para ser implementado no kernel Linux.

 Qu Wenruo que foi um dos autores do inline deduplication para o Btrfs informou aos pesquisadores o:

 "Como um dos autores originais, eu e o meu empregador não temos mais interesse em continuar dedupe. Além do mais, a implementação original possui um limite, um extent tem que ser escrito no disco antes que possa ser utilizado pelo write-time dedupe."

 Para deduplicação o Btrfs utiliza a técnica out of band deduplication (como mencionei no meu vídeo), o módulo ioctl e ferramentas em userspace como BEES.

 Moral da história

 O que os pesquisadores utilizaram na verdade foi uma versão muito antiga do btrfs (talvez de 4 anos atrás) e deveriam ter testando ao menos uma versão que possui out of band deduplication (de preferencia versões mais recentes do kernel Linux).

 Vou reforçar que já estou ouvindo me chamarem de fanboy de Btrfs (SARCASMO ON: Não são eles que são fanboys de ZFS ou do Ext4, sou eu que sou fanboy de Btrfs... Eu não apresentei nenhum argumento técnico, foi só coisa de fanboy mesmo... Sempre assim...)

 E por ultimo vamos ver se os sites (como o que postou o artigo Examinando o Btrfs, o sistema de arquivos do Linux perpetuamente semi-acabado) chegarão a publicar sobre essa falha no ZFS (honestamente eu duvido) pois esse já não é a primeira que eu posto. Alias, vamos ver quanto tempo vai levar para isso ser corrigido no ZFS. Basta lembrar do caso do alto consumo de CPU no ZFS por exemplo que levou anos para ser corrigido. Este caso pode ser lindo clicando aqui.

Minha série "ZFS VS Btrfs"

Link para o paper DUPEFS: Leaking Data Over the Network With Filesystem Deduplication Side Channels

Link para o inline deduplication no btrfs desenvolvido pela Fujitsu

AGORA, QUER APRENDER BTRFS DE VERDADE? ENTÃO CONFIRA O MEU CURSO DE LINUX CLICANDO AQUI :) 

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Seja Membro Premuim do Regata OS e ganhe prêmios e suporte

Anunciado o fim do Project Trident

 Project Trident iniciou em 2018 como uma distribuição para desktop baseado no TrueOS. Com o fim do TrueOS, dois membros adotaram porções do seu desktop e reconstruíram a distribuição e em 2019 anunciaram que iam abandonar a base do TruOS/FreeBSD e iam basear no Void Linux. A transição foi concluída em Fevereiro de 2020.

 Alguns dos principais recursos do Project Trident era a interface Lumina como ambiente gráfico padrão, o ZFS como sistema de arquivos padrão, criptografia para todos os dados, facilidade de uso e muito mais.

 Infelizmente, o projeto anunciou o seu fim no dia 29 de Outubro devido a pandemia. Não está descrito exatamente assim, mas a informação do anuncio de seu fim deixa isso muito claro.

"Com as mudanças e eventos nos últimos dois anos na vida, trabalhos, família e etc; nossas prioridades individuais tem mudado também."

Todas as informações podem ser conferidas clicando aqui.

VENHA APRENDER LINUX COMIGO :)

E não esqueçam de conferir também o meu mini curso de atributos no Linux

Seja Membro Premuim do Regata OS e ganhe prêmios e suporte

O estranho caso do ZFS consumir muita CPU

O estranho caso do ZFS consumir muita CPU

 Por mais que muitos pintam a imagem do ZFS como um sistema de arquivos indestrutível, ele também possui suas ventagens e desvantagens (como tudo no mundo, lei natural). Eu já abordei esse assunto em uma série do meu canal chamado ZFS vs Btrfs. Quem vence essa batalha.

Criei uma playlist especial para essa série e você pode conferir clicando aqui.

 E por mais que seus defensores não consigam admitir, o ZFS também possui seus defeitos. Dois deles já foram mencionados aqui sendo o um o seu alto consumo de RAM e o outros o grande problema com de fragmentação.

Um pouco mais pode ser conferido aqui.

 No dia seis de Setembro, Brendan Gregg relatou em seu blog um problema muito estranho que ocorre com o ZFS. Uma equipe de microsserviços o contatou apresentando o caso em que o ZFS estava consumindo sozinho 30% da capacidade de CPU. E por que exatamente a Brendan Gregg? Para quem não o conhece, Brendan Gregg já foi representante senior Solaris na Netflix, engenheiro de kernel, já foi desenvolvedor do Solaris onde ficou conhecido na área de performance concentrando seus esforços na primeira nuvem baseada em container do mundo e no primeiro dispositivo de armazenamento ZFS no mundo.

 Brendan ainda é engenheiro senior de performance na Netflix voltando seus esforços para o Solaris, Linux e FreeBSD e ainda mantem seus trabalhos voltados ao ZFS sendo o desenvolvedor do ZFS L2ARC e de várias outras ferramentas que geraram economia mundial de US$1bilhão (além de suas ferramentas terem dado origem a várias startups). Brendan é também internacionalmente conhecido como expert em performance na área de computação sendo desenvolvedor de várias ferramentas de analise para tal fim, 

Vale a pena conhecer as várias ferramentas de autoria de Brendan Gregg, sua carreira e até mesmo seus livros. 

gwhiz, uma das ferramentas desenvolvidas por Brendan Gregg em perl que eu gosto.

 

 Mas voltando ao caso do ZFS, esse é um caso que Brendan já apresentou em 2017 na kernel recipes e sua primeira ideia foi algum engano que cometeram durante a configuração:

"Eu trabalhei nos componentes internos do ZFS na Sun Microsystems e, a menos que esteja mal configurado, não há como consumir tanta CPU."

 Foi aí que começou toda a surpresa. Brendan começou utilizando uma ferramenta da Netflix de monitoramento e nuvem chamada Atlas e de cara o ZFS estava consumindo 38% de CPU; algo muito incomum nada carga de trabalho na nuvem da Netflix. Depois de outras analises com outras ferramentas como o Vector e supos através disso que o problema estava relacionado a containers. O que para a surpresa de todos é que eles não estava utilizando containers e nem o ZFS...

Ferramenta Vector da Netflix

 Brendan então começou a debugar o sistema com comandos do sistema mesmo como df -h, mount e zfs list e estranhamente e ZFS não estava montado. Brendan então deduziu que containers poderiam ter sido criados anteriormente e destruídos; então Brendan decidiu analisar os arcstats que são contadores do kernel que rastreiam estatísticas do ZFS e o resultado foi que os contadores estavam zerados, o ZFS não estava montado e mesmo assim o ZFS estava consumindo 30% de CPU.

arcstats do ZFS

 Foi aí que Brendan decidiu olha o flame graph do Vector mais de perto e depois verificar no código fonte e no histórico de alterações e encontrou o erro no ARC que tinha como intenção melhorar o desempenho e acabou gerando tamanho problema.

 Brendan abriu a requisição de numero 6531 no GitHub da equipe do Open ZFS em 2017 (ano em que abordou esse assunto) que desde então vem dando atenção especial ao ARC e assim, não teve mais notificações por parte do cliente.

O artigo no blog do Brendan Gregg pode ser conferido aqui

Os livros do Brendan Gregg podem ser adquiridos aqui

Aqui você pode conhecer e adquirir mais livros sobre o ZFS

Mais sobre o ZFS, clique aqui

Mais sobre a Netflix

VENHA APRENDER SOBRE O BTRFS COMIGO :)

E não esqueçam de conferir também o meu mini curso de atributos no Linux e aprendam mais recursos nos sistemas de arquivos 

Seja Membro Premuim do Regata OS e ganhe prêmios e suporte