Olá a todos,
Desde as minha experiência inicial com o bcache já em 2015, tenho seguido o tema com muito interesse. É verdade que já existem discos SSD’s de grande capacidade ou discos mecânicos híbridos disponíveis, mas ambas as opções, a meu ver ainda são demasiado caras.
No meu caso, o que descrevo abaixo foi feito com €79,8 para um array de 4 discos mecânicos de 3TB que já tinha. O valor equivalente em SSDs puros era bem mais alto. Por um fator multiplicativo.
A somar a isto, a maior parte de nós temos já investimentos em armazenamento (alguns dentro de garantia) pelo que deitar fora o que existe não é aceitável.
Com isto em mente, andei em tempos a investigar a forma de hibridar um disco mecânico, utilizando para tal um SSD e cheguei a uma tecnologia emergente em Linux (existe equivalente para windows) chamado Bcache. Fiz o post original sobre o tema aqui.
O que é o Bcache?
O bcache é um Linux kernel block layer cache e permite usar o SSD (e a sua velocidade superior) para fornecer cache a um disco mecânico.
No meu caso especifico e tendo em conta que o meu problema – e aparentemente o de muita gente com homelabs – é a performance quando tem num array em RIAD5/6 , iremos usar dois SSD’s em mirror raid1 para alimentar a cache do nosso array com redundância dos cache devices que suportam o array mecânico.
Para o meu caso especifico utilizei dois A400 de 240GB, comprados com um mês de intervalo entre os dois, para garantir que haveria desfasagem na avaria por desgaste dos dois (hopefully).
Para criar o array de SSD’s que irá alimentar o array criei um array em degraded state:
npar0:~# mdadm –create /dev/md1 -l raid1 -f -n 1 /dev/sdb1
Sendo o resultado:
md1 : active raid1 sdb1[0]
234298944 blocks super 1.2 [2/1] [U_]
bitmap: 2/2 pages [8KB], 65536KB chunk
Em seguida inicializamos o array do SSD device (md1) para responder como a cache:
npar0:~ # make-bcache -C /dev/md1p1
UUID: 8d0c8fc6-f488-426a-a7c9-1eed16a05d62
Set UUID: 54e38954-c90e-4fee-9a1c-365e3513a530
(nota: a partição foi feita por gosto -p1- , não por pré requisito).
Após este passo, e pelo o backing device (discos mecânicos) não suportarem ter já dados lá – no meu caso VM’s, fiz backup delas e destruí o array e criei um novo, com LVM, e um LV que é o backing device do bcache.
De novo, este passo não é necessário, mas para o método de organização que estou habituado, e que permite alguma liberdade foi o que usei:
mdadm –create /dev/md0 -l raid6 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1
vgcreate vgraid6 /dev/md0
lvcreate -n VM_NOCACHE -L 500G /dev/vgraid6
lvcreate -n VM_CACHE -L 2000G /dev/vgraid6
Com isto fiquei com dois logical volumes. Um para utilizar com o bcache o outro para vm’s que já sei a partida que vão fazer trashing de disco e como tal não queremos a destruir o array de SSDs
npar0:~ # make-bcache -B /dev/vgraid6/VM_CACHE
UUID: f49e7f63-b0aa-4f87-9b5e-19a75af9bccd
Set UUID: 54e38954-c90e-4fee-9a1c-365e3513a530
Após a inicialização dos devices chega a altura de os registar como bcache devices:
root@npar0:~# echo /dev/md1p1 > /sys/fs/bcache/register
root@npar0:~# echo /dev/vgraid6/VM_CACHE > /sys/fs/bcache/register
root@npar0:~# echo 54e38954-c90e-4fee-9a1c-365e3513a530 > /sys/block/bcache0/bcache/attach
root@npar0:~# echo writeback > /sys/block/bcache0/bcache/cache_mode
Nota: o novo device criado com a união do array de SSD com o array de HDD é o /dev/bcache0 e os echos acima tornam-se persistentes após colocação. De notar o metodo de cache a ser usado no ultimo echo.
Finalmente podemos testar novamente a velocidade obtida utilizando a configuração em bcache:
npar0:~ # hdparm -T /dev/bcache0
/dev/bcache0: Timing cached reads: 12936 MB in 2.00 seconds = 6474.47 MB/sec: Timing cached reads: 6780 MB in 2.00 seconds = 3391.91 MB/sec
Todos os dados do exemplo aqui apresentado, foram recolhidos com já com VM’s a correr e apenas reads, pelo que os valores divergem, mas estejam descansados. Nota-se *MESMO* a diferença para melhor.
Caso já tenham formatado o bache0 e tenham lá coisas a correr, não recomendo testes de write.
A alteração irá obrigar a várias alterações, migrações de dados entre o que tem agora e novos arrays de disco, atenção ao estado de wear dos SSD’s e ao estado dos arrays.
Para isto nada é mais vosso amigo que o smartd e que o mdadm.
Mas vão ter um aumento maciço de velocidade e como os vossos discos mecânicos vão conseguir estar mais parados (sim é possível) o vosso consumo elétrico irá descer e a temperatura onde tem o vosso homelab irá diminuir. Por outro lado, os SSD’s passarão a ser objetos de consumo como cartuchos de impressão, de utilizar e ao fim de algum tempo deitar fora.
A minha estimativa pessoal, com estes SSD’s, é que mesmo com 16 VM’s em execução em permanecia em cima do bcache0, ao ritmo atual, a falha irá ocorrer em 1825 dias (+- 5anos).
Cuidados especiais a ter:
Não se esqueçam que enquanto tiverem apenas um SSD cache device, sem redundância, é fundamental terem backups do que lá tem. Uma falha nesse SSD irá causar perca de dados por corrupção pois os dados no cache device nunca chegaram a ser escritos para o backend mecanico, portanto assim que passar um intervalo de tempo que julguem prudente, comprem um segundo e adicionem ao raid de SSD’s.
É importante que caso necessitem por alguma razão de usar um rescue cd/live cd, ambos os arrays terão de ser montados a mão, e o mecanismo do bcache terá de ser ativado à mão.
Isto porque podem haver dados na vossa cache que ainda não foram descarregadas aos discos mecânicos, e atuar sobre eles sem essa cache ser limpa pelos mecanismos do bcache irá causar perca de dados.
Desativem todos os mecanismos de trimming que usem para estes SSD’s em especifico. Se tiverem outros, sem estarem no bcache, podem manter ativos apenas para esses.
No caso dos SSD’s do bcache, ele gere internamente o tema.
A vossa turbo-velocidade irá apenas durar até ele encher o cache device, sendo depois necessário aguardar que ele faça o dump da cache. No entanto, com a minha configuração e carga permanente ainda não bati nesse limite com SSDs de 240GB. Este dump é automático e transparente para o utilizador final.
Finalmente e ao nível do vosso virtualizador, usem EXT4 ou XFS para formatar o bcache0. O BTRFS é conhecido por ter algumas interações estranhas com bcache que podem levar a corrupção de dados.
Espero que tenham gostado. Até ao próximo post sobre o tema, sabem onde me encontrar!
Abr
Higgs
Bibliografia:
https://grepular.com/Disk_Caching_with_SSDs_Linux_and_Windows
https://wiki.archlinux.org/index.php/bcache