Rook Ceph

Escalando as Nuvens

Softwares x Storages

- O mercado de storage sempre foi dominado por hardware desde a era do Raid,
até as super controladoras, que criavam discos e fitotecas, para armazenamento
massivo, mesmo com a adoção do raid via software havia além de uma perda
considerável de performance por uso de CPU, o mau aproveitamento de disco.

Uma mesma controladora poderia em alguns casos ter vários tipos de disco, mas esses
deveriam estar agrupados fisicamente em posições corretas e setados muitas vezes via
bios, sendo necessário desligar o equipamento para dar a manutenção adequada e
reconfigurar o novo disco na bios, em caso de falha.

Após algumas evoluções foram criados hardwares que identificavam o tipo de disco e era
necessário apenas adicionar ele aos blocos correspondentes.
SDS
Removendo uma mais uma fronteira

Com a criação dos Softwares Defined Storages, muita coisa começou a mudar
rapidamente em um mercado já considerado consolidado e sem muitas evoluções
drásticas, apesar dos discos estarem aumentando e evoluindo as controladoras
mantinham em sua essência a mesma logica padrão de manutenção de disco por
posição, mesmo sendo esses hot-swap.( que podem ser trocados sem desligar as
maquinas). O hot-swap havia sido a ultima grande invenção do mercado comecei a dar os
primeiros passos nessa área.

Com surgimento do SDS, as camadas se software e hardware se separaram de forma

que havia um software capas de controlar as logicas de armazenamento sem depender
especificamente de um hardware, isso mudou drasticamente a forma como as coisas
iriam evoluir nos próximos anos, principalmente nos segmentos menores, onde pequenos
silos de armazenamento poderiam ser construídos em pouco espaço e hardware comum,
bem longe das antigas logicas de robôs e fitotecas.

Em pouco tempo as soluções de baseadas em software ganharam terreno nas pequenas

empresas com setores de tecnologia, principalmente as tecnologias de software live,
como FreeNAS, entre outros grandes nomes que já ouvi ou trabalhei em algum momento.

Objetos
A mudança de paradigma que mudou o jogo dos storages de vez

A grande mudança que tive contato veio ao jogo com os armazenamento em forma de
objetos, com isso a logica já estabelecida de grandes arvores de diretórios que eram
fortemente hierárquicos, gradualmente deixou de ser o padrão, para dar lugar a estruturas
mais livres de dados que podia estar em qualquer lugar.

Os object storages usam uma tecnologia que gera um identificador único pra cada parte
(objeto) a ser guardado em um dispositivo de armazenamento. Um software de leitura
consegue encontrar esse objeto usando seu identificador onde quer que eles esteja, por
mais que pareça muito mais complexo, e realmente é, a vantagem se dá nos grandes
volumes de dados. Enquanto um armazenamento comum, tem que vasculhar os dados
sempre partindo de um começo, um Object Storage sabe exatamente onde o dado está
além de garantir que aquele identificador é único, reduzindo a taxa de erros, hoje usamos
a mesma logica nos nossos computadores gerando uma camada a mais de indexação.

Com a grande adoção da nuvem como meio de comunicação e transporte de dados os

object storages provaram seu valor e hoje são dominantes nos servidores e mercados
empresarias deixando o armazenamento do “velho padrão”, para dispositivos pessoas
como computadores e notebooks.
Ceph
um excelente storage

O Ceph nasceu de uma tese de doutorado de Sage Wail em 2004, após anos de
desenvolvimento ativo e crescimento da equipe o Ceph já despontava com uma grande
promessa de software sendo incorporado ao Kernel linux em 19 de março de 2010, mas a
primeira versão estável veio só 2 anos mais tarde em Julho de 2012, com codinome
Argonaut..

Inicio revolucionário e uma longa jornada

Mesmo com seu conceito revolucionário o ceph ainda tinha muita estrada a percorrer, a
instalação dos componentes eram todas manuais e exigiam praticamente a mesma
dedicação que o Dr. Wail tivera em seu inicio, as coisas ficaram um pouco mais amigáveis
em 2013 com o ceph-deploy, uma ferramenta que automatizava muitas partes da
instalação, colocando o ceph no jogo de vez, o ceph-deploy foi por muitos anos a
ferramenta padrão de instalação dos clusters baseados em ceph.

Ao mesmo tempo em que estabilizava-se o sistema e demais componentes, o ceph não

parou de inovar e foi lançando recursos e componentes cada vez mais interessantes
dando uma nova pegada a cada atualização. Muitos dos componentes que vemos hoje
como BlueStore e CephFS, só se tornaram estáveis em 2017, que por sinal foi época que
passei usar diariamente esses recursos.

A virtualização como porta de entrada dos SDS

A virtualização é uma velha amiga dos nossos dias TI, estamos a tanto tempo rodeados
por ela que mal me lembro como era não ter esse recurso, servidores enormes podendo
ser vários mini servidores virtuais, ou mesmo nosso notebook de trabalho executando
sistemas operacionais diferentes ao mesmo tempo.

Como sempre no mundo do software livre, boas ideias e softwares se interligam e criam
algo maior, mais robusto e expandem seus níveis e recursos. Estava estudando
OpenStack, mais especificamente o Cinder quando vi que haveria em breve uma camada
de compatibilidade do Ceph, em pouco tempo vários virtualizadores como ProxmoX e
OpenNebula estavam implementando seus scripts de automação do Ceph, unindo no
mesmo hardware em que rodavam suas vms um poderoso storage de objetos, com
capacidades incrivelmente desejadas e nas pontas do mouse.

Com poucos cliques e configurações estávamos no céu dos virtualizadores, com baixo
custo, alta resiliência e capacidade expansão.

Esses pequenos fatos hoje já históricos, mudaram os formatos das empresas que tive o
privilegio de trabalhar.
O ceph não era mais um software experimental, havia estabilidade e recursos incríveis,
mas havia uma enorme curva de aprendizado que aqueles poucos cliques não traziam
nem nas letras miúdas e talvez se existissem essas letrinhas muitas noites teriam sido
economizadas, o que seira uma pena enorme, por que mesmo com todos os problemas
que tive por falta de conhecimento, o ceph sempre me deu mais alegria do que dor de
cabeça.

Dockerização
Um novo mundo

O Crescimento dos serviços estava ficando inacreditavelmente complexo, a cada nova

implementação, novos desafios softwares e versões conflitavam sem parar e no meio
disso a demanda por espaço e processamento não parava de acontecer, não era
incomum ao colocar um novo software em homologação ouvir a frase “Mas na minha
maquina funciona” e muitas vezes funcionava mesmo.

A diferença de hardware, sistema operacional bibliotecas entra outas formas de se

escrever um programa de computador causava nos analistas de infraestrutura calafrios
que nunca mais vão esquecer, nessa mesma época uma nova variante da virtualização
via LXC estava ganhando terreno rapidamente, com sua engenharia diferenciada e alto
nível de abstração de hardware, o docker entrou nos laboratórios de informática pela
janela mas em pouco tempo estaria sentado a mesa de negócios sendo um dos carros
chefs do desenvolvimento mundial.

Junto com o docker e sua sopa de letrinhas vieram também as complexidades dos
containers, em pouco tempo ao invés de alguns servidores, passamos a dezenas de
contêineres e uma coisa chamada microsserviços, que desafiava ainda mais os storages
que tínhamos até ali.

O gerenciamento era a pior parte, como o ceph usa Posix, era comum sair montando
vários “containeres de dados” e cada um com um volume RBD em um path gerenciado
manualmente ou por scripts que desenvolvemos internamente.

Entendo que não era a melhor forma de fazer isso, mas estamos falando da época do
nascimento do docker, ele era um bebe, não fazia nada sozinho e dava muito mas muito
trabalho, mas tinha um grande futuro pela frente e o ceph estava ali pronto crescer junto
com ele.
A nuvem, e seus desafios

Quando falamos em nuvem, como estamos no backend a palavra que eu acho mais
indicada é escala: escalar serviços, servidores, rede, storage. Empilhar recursos cada vez
mais e mais para atender a uma demanda de conectividade sem fim, sem região
geográfica, sem limite de banda, sem hora pra dormir e com vários horários de pico.

Se por um lado a procura cresce de forma descontrolada do outro lado ficamos nós os
analistas surtando com os alertas e criando muitas vezes “na mão” os recursos pra suprir
essa demanda, esse cenário se repetia muitas vezes e mesmo com o ceph estando
razoavelmente implementado ainda demorava um pouco mais do que eu gostaria para
entregar um ambiente pronto a atender essa explosão de demanda chamada “pico de
acesso”. Junte as isso o recurso escasso que muitas micro empresas de TI tem e teremos
o caos perfeito.

Kubernetes
Deixando o docker mais resiliente e mais complexo também

O docker já estava mais velho, já haviam coisas normalizadas no mercado e alguns de

seus recursos estavam bem formatados e difundidos. Nessa época me foram aprestados
os orchestradores de containers, e seus mais variados modos de trabalho, alguns como
rancher e docker swarm, já eram escolhas certeiras, na grande maioria dos casos era ou
ou outro, o que sempre pegava na hora da escolha era o ceph, e como fazer ele se
adaptar a uma plataforma ou a outra.

Já vi acontecer e participei em vários casos, de produção usar uma VM com com disco
montado em um path especifico pro docker e o ceph por baixo servindo de storage do
virtualizador.
Sabemos que é bem rudimentar, varias camadas de virtualização desperdiçando recursos
valiosos piorando a performance porque não temos uma alternativa mais simples.

Eis que o mercado mais uma vez inova e me apresenta o Kubernetes uma tecnologia
muito mais assustadora de gestão e gerenciamento de containers, que honestamente eu
achei no começo que não iria vingar, devido a alta complexidade das soluções.

Mesmo achando meio doido aquilo, o kubernetes estava crescendo muito e rapido,
lembro dos primeiros artigos da RedHat que li sobre o tema, e como vários
orquestradores estavam se adaptando para a nova tendencia de gerenciamento.

Ao mesmo tempo o ceph estava cada vez mais avançado e haviam projetos ainda em
faze beta, que traziam o ceph pra esse mundo dos containers, era o inicio da jornada que
eu vivenciaria na parte de storage a cada lançamento dias e horas testando na tentativa e
falha, muitas e muitas falhas depois eu conheci o Rook.
Ceph e Kubernetes

Com o kubernetes consolidado alguns plugins foram lançados e um plugin para o ceph foi
um deles. Era um plugin bem manual, que me dava calafrios em cada montagem pois era
errar uma letra e lá se iam horas até achar o problema, fora o medo de apagar alguma
coisa por cansaço, das muitas horas trabalhadas em uma micro empresa de SP.

O Kubernetes seguiu crescendo e os containers dominando o mercado, foi quando

pesquisando descobrimos um projeto chamado Rook, que estava em faze beta, mas viria
a ser nosso próximo lab por muito tempo.

Rook
Casamento perfeito.
O rook inicialmente seria uma plataforma de automação para vários backends de storage
SDS, nessa época o próprio rook estava descobrindo como deveria seguir adiante.
Assim que o rook chegou em sua primeira versão estável a 0.9 passamos a usar ele de
forma oficial na empresa. O rook resolveu vários problemas, trazendo uma pegada de
virtualizador, para o mundo das super escalas do kubernetes, ainda usávamos uns
plugins não muito animadores mas agora haviam pods ( uma forma evoluida dos deploys
de containers) passamos a adicionar os volumes com algumas annotations do próprio
kubernetes, o rook fazia o trabalho preciso de um bom middleware, traduzindo parte das
chamadas do kubenetes para o ceph, tornando o processo mais amigavel e sem a
necessidade das velhas vms de produção.

Não demorou muito pra o rook passar usar a CSI, uma camada de storage nativa do
kubernetes, que também fala com o ceph.

Os deploys de ceph usando o rook se tonaram cada vez mais integrados a estrutura do
kubernertes e a medida que o ceph evoluía o rook ia adotando cada vez mais e mais o
ceph como seu backend principal.

Hoje temos resiliência e escalabilidade de TBs de forma simplificada e dentro da mesma

logica declarativa de yaml de configuração. Usando o rook eu reduzi os deployments de
clusters inteiros de dias de configuração pra horas e as vezes até minutos, fazendo o uso
do ceph um mesmo servidor on premise, ou baremetal, pode comportar todos os meus
workloads e dados sem comprometer a performance, o I/O e a disponibilidade dos
serviços.

Não é novidade que atualmente consegimos usar hardware simples, mas de boa
qualidade pra criar verdadeiras nuvens privadas com escalabilidade impressionante.

Tudo graças e essa dupla complexa de Kubernetes e Ceph que o rook junta e organiza
com carinho.