.png)
Fiável e bem integrado no OpenStack, o Ceph foi durante vários anos a nossa solução de Block Storage. Mas, para oferecer um melhor desempenho a um custo inferior, adquirimos a Exten, pelo que agora somos capazes de desenvolver a nossa própria solução de Block Storage NVMe
- em C++ e Go. Os nossos objetivos de desenvolvimento são:
- Utilizar unidades NVMe para oferecer volumes de alto desempenho
- Usar algoritmos de codificação inteligentes para reduzir o espaço ocupado em disco (codificação Reed-Solomon, compressão)
Manter os clusters pequenos e fáceis de gerir
O Exten tem estado em produção há mais de um ano. Neste artigo, detalhamos o seu funcionamento e o que a sua arquitetura permitirá de futuro. Clique no link ao fundo para dar o seu feedback e ajudar a moldar o futuro do Exten
Anatomia de um cluster
Um cluster Exten típico é composto por seis servidores. Estes servidores estão próximos uns dos outros, de modo que a latência entre eles seja baixa, mas não demasiado próximos para não aumentar o risco de vários servidores falharem em simultâneo. Cada servidor tem dezenas de unidades NVMe para armazenar dados de utilizador.
O Exten foi construído em torno do protocolo NVMe. Utiliza unidades NVMe, mas também usa o protocolo NVMe over Fabrics para expor volumes de utilizador e para comunicar entre hosts. Os volumes são unidades virtuais que os clientes podem ligar às suas máquinas virtuais (MV). Este protocolo usa os mesmos comandos que as unidades NVMe, mas através de uma ligação de rede (TCP ou RDMA), e foi concebido para elevado desempenho e baixa latência.
Uma vantagem do NVMe over Fabrics é que o kernel Linux o suporta de forma nativa. Ligar um volume Exten a um host Linux é tão simples como executar um comando nvme connect com os parâmetros corretos: o volume surge então exatamente como qualquer outra unidade NVMe local. O cliente Public Cloud não vê nada disto — o volume é simplesmente ligado à sua instância, exatamente como com o Ceph.
O Exten está dividido num plano de dados escrito em C++ e num plano de controlo escrito em Go. Ambos comunicam através de gRPC. O plano de dados recebe operações de E/S através do NVMe over Fabrics e encaminha-as para as unidades NVMe. O plano de controlo fornece uma API para criar e eliminar volumes, mas também para gerir o cluster.
Como manter os dados seguros
Manter os dados dos clientes seguros é a maior responsabilidade de um cluster Exten, e tratamos disso a vários níveis.
No lado do plano de controlo, utilizamos o conhecido Raft Consensus Algorithm para garantir a integridade do cluster com tolerância a falhas. Funciona elegendo um líder e registando qualquer informação nova — um novo volume criado, uma unidade ativada — num registo replicado em todos os hosts. Se um host falhar, os outros continuam a funcionar. O único limite é que a maioria dos hosts tem de se manter em funcionamento para evitar problemas de split-brain, pelo que um cluster de seis nós pode perder dois hosts e continuar a operar.
Os dados do utilizador em si, ou as operações reais de E/S efetuadas nos volumes, não passam pelo Raft; isso seria demasiado lento. Ao invés, usamos outro algoritmo bem conhecido: o código Reed-Solomon.
Este código de correção de erros é conceptualmente simples. Tomemos o RS 4+2: dividimos os dados em quatro partes iguais e, em seguida, calculamos duas novas partes do mesmo tamanho. Se conseguir ler quatro dessas seis partes, pode recuperar os dados originais: o código permite-lhe calcular as duas que faltam. Isso dá um rácio de 1,5 (dados armazenados/dados recebidos), pelo que podemos perder dois discos sem perder quaisquer dados. É uma forma altamente eficiente de adicionar redundância. A alternativa ingénua — em geral chamada espelhamento, que consiste simplesmente em copiar a totalidade dos dados várias vezes para discos diferentes — precisaria de três cópias para resistir à perda de dois discos. Com o Reed-Solomon, armazenamos metade dos dados para o mesmo nível de redundância.
A falha de discos pode ser detetada de duas formas: ou uma leitura simplesmente falha, ou devolve dados corrompidos — o que é detetado graças a um checksum que adicionamos a cada setor. Quando um disco falha, um processo automático recalcula a parte em falta e armazena-a num disco saudável, reduzindo o risco de perda de dados.
Processar E/S de forma rápida
Com as CPU e a RAM a funcionar mais rapidamente, o armazenamento tem de ser capaz de acompanhar. O objetivo do Exten é tirar o máximo partido do hardware em que é executado e fornecer aos clientes E/S de alto desempenho. A escolha do protocolo NVMe over Fabrics é um primeiro passo para um desempenho de E/S com o mínimo overhead possível, mas toda a pilha de software foi concebida a pensar no desempenho.
O modelo de processamento é centrado nos dados. Ao nível do Network Interface Card (NIC), recebemos e enviamos dados através de uma lista de buffers de tamanho fixo armazenados na RAM. Determinada CPU processa cada buffer com dois propósitos: evitar cópias de dados e evitar trocas de contexto.
De modo a evitar cópias de dados, o código manipula buffers pré-alocados através de ponteiros desde o NIC até ao disco, e só modificamos os dados quando é inevitável (compressão, codificação Reed-Solomon...). De modo a evitar trocas de contexto, gerimos a E/S através de métodos totalmente assíncronos que funcionam com pequenas porções de dados. Determinada CPU realiza o máximo de processamento possível num buffer antes de passar ao seguinte, mas trata-se de um equilíbrio: o buffer seguinte não pode ser demasiado atrasado e o processamento tem de se manter equitativo. Desenvolvemos uma framework completa em C++ adaptada a estas necessidades, para manter o código claro e de fácil manutenção.
Além do código em si, vários outros fatores ajudam a melhorar o desempenho:
- a escolha do algoritmo de compressão (a ausência de compressão é por vezes a melhor escolha, por exemplo em tráfego encriptado)
- a escolha do protocolo de rede: RDMA é mais rápido do que TCP, mas implica mais restrições de implementação
- a forma como se alocam núcleos de CPU aos volumes
Nas nossas ofertas Public Cloud, também aplicamos regras de QoS para garantir a equidade entre todos os volumes.
O que se avizinha para o Exten
O Exten encontra-se em produção e neste momento fornece volumes aos clientes Public Cloud. É transparente para os clientes e suporta as mesmas ofertas que o Ceph — mas é uma pilha de software que controlamos totalmente, construída em torno de NVMe para um desempenho elevado.
Estamos constantemente a aperfeiçoá-lo, com o objetivo de oferecer aos clientes volumes de maior desempenho, mais flexibilidade e maior fiabilidade. Estamos, por exemplo, a explorar a utilização de RDMA para melhorar o desempenho (atualmente usamos TCP).
O primeiro passo da jornada do Exten foi fornecer uma oferta fiável que substituísse o Ceph. Agora que controlamos totalmente a pilha, estamos prontos para adicionar novas funcionalidades e adaptar a oferta às necessidades dos nossos clientes.
Tem algum caso de uso do Block Storage que devamos conhecer, ou funcionalidades que considere que faltam? Conte-nos tudo no Discord ou pela cloud mailing-list — o seu feedback vai moldar o futuro do Exten.