Armazenamento em camadas com BTRFS - como isso é feito?
NETGEAR usa BTRFS em seu sistema operacional ReadyNAS e implementa armazenamento hierárquico em suas versões mais recentes. Eles começaram com a camada "Metadados" apenas no ReadyNAS v6.9 e, em seguida, adicionaram a "Camada de dados" na v6.10. O sistema usa SSDs como Tier-0 para acelerar o acesso aos HDDs mais lentos no sistema. A descrição do sistema afirma que os metadados residirão nos SSDs em ambos os casos, e que no caso da "Camada de Dados" também os dados recém-gravados irão primeiro para os SSDs e, posteriormente, serão migrados para o HDD periodicamente, ou quando o A camada SSD é preenchida até um nível especificado.
ReadyNAS usa BTRFS em cima de HDDs RAID-ed em suas instalações normais - por exemplo, meu sistema tem um RAID5 feito de 4 discos, que BTRFS vê / usa como um único dispositivo.
Observando como o Tiering é implementado, parece que as configurações de "Metadados" e "Data Tier" são feitas adicionando uma segunda matriz RAID, feita apenas de SSDs, à matriz HDD RAID principal e transformando o dispositivo único inicial BTRFS em um dispositivo com vários dispositivos.
O que não consigo descobrir é como a migração é feita e também como o caso "Metadata" consegue separar os metadados dos dados, de modo que apenas os metadados vão para o SSD. Além disso, como o modo "Camada de dados" direciona as gravações inteiramente para a camada SSD?
Alguma ideia?
Respostas
OK, eis o que descobri acontecer durante os balanços periódicos:
O seguinte processo é iniciado no host:
btrfs balance start -dsweep lt:/dev/md127:7 /data LANG=en_US.UTF-8 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin DBUS_SESSION_BUS_ADDRESS=unix:path=/var/netatalk/spotlight.ipc TRACKER_USE_CONFIG_FILES=1 TRACKER_USE_LOG_FILES=1 XDG_DATA_HOME=/apps/.xdg/local/share XDG_CONFIG_HOME=/apps/.xdg/config XDG_CACHE_HOME=/apps/.xdg/cache
onde / data é meu volume de dados em camadas, / dev / md127 é a matriz SSD usada como buffer / cache.
Este processo é executado até que os dados da camada SSD sejam movidos quase completamente para a camada HDD - por exemplo, em algum lugar ao longo do caminho eu vejo:
btrfs fi sh /data
Label: '0a44c6bc:data' uuid: ed150b8f-c986-46d0-ada8-45ee219acbac
Total devices 2 FS bytes used 393.14GiB
devid 1 size 7.12TiB used 359.00GiB path /dev/md126
devid 2 size 114.68GiB used 42.06GiB path /dev/md127
e então diminui até que o uso da camada SSD vá quase a zero. O estranho é que até agora não consegui executar esse comando manualmente.
Ainda não consigo descobrir o filtro de equilíbrio de 'varredura'.
Isso é o que a ajuda mostra:
# btrfs balance start --help
usage: btrfs balance start [options] <path>
Balance chunks across the devices
Balance and/or convert (change allocation profile of) chunks that
passed all filters in a comma-separated list of filters for a
particular chunk type. If filter list is not given balance all
chunks of that type. In case none of the -d, -m or -s options is
given balance all chunks in a filesystem. This is potentially
long operation and the user is warned before this start, with
a delay to stop it.
-d[filters] act on data chunks
-m[filters] act on metadata chunks
-s[filters] act on system chunks (only under -f)
-v be verbose
-f force reducing of metadata integrity
--full-balance do not print warning and do not delay start
--background|--bg
run the balance as a background process
mas isso não explica como ele mapeia para a lt:/dev/md127:7
parte " " do comando que é executado periodicamente:
btrfs balance start -dsweep lt:/dev/md127:7 /data
Qual é o significado aqui: Executar até que o uso de dados / dev / md127 caia abaixo de 7%?!?
Deve ser um cronjob que executa regularmente e faz a migração.
Verifique em /etc/cron.d as entradas que podem estar fazendo isso.
Você está dizendo que a Netgear encontrou uma maneira de fazer o que MergerFS Tiered Caching já permite, em uma configuração amigável e extremamente simples: https://github.com/trapexit/mergerfs#tiered-caching
crie 2 pools MergerFS A) um com todas as unidades de HDD, incluindo o SSD ("POOL", tier0) e defina para gravar no dispositivo com menos espaço livre (a menos que tenha X quantidade de espaço livre restante). B) segundo pool ("POOL-ARCHIVE", tier1) contendo apenas os HDDs.
Seus usuários e todos os aplicativos usam apenas o caminho do primeiro pool.
Um script noturno que copia tudo o que não foi alterado nos últimos X dias, do primeiro pool para o segundo (fácil, já que as unidades são as mesmas, isso apenas fará com que os dados no SSD sejam copiados). Este é o único item que usa o caminho do segundo pool.
É exatamente assim que configurei meu servidor doméstico. Todas as unidades são formatadas em BtrFS. Eu não (não posso, com esta solução) uso o Raid.
Os prós:
- Quando uma unidade falha, você só perde dados nessa unidade (e eu atenuo isso usando o SnapRAID como primeiro sistema de backup). Você não perde o pool inteiro como com BtrFS-RAID0.
- Isso é extremamente fácil de configurar. 2 montagens em seu / etc / fstab. BAM, cache em camadas!
- Você sempre usa o SSD primeiro (a menos que ele tenha apenas uma quantidade X de espaço livre restante). Dando a você velocidade máxima.
Os contras:
- Você não pode usar subvolumes BtrFS (estendendo-se por discos) dentro de seu conjunto MergerFS, pois o MergerFS é executado no topo dos sistemas de arquivos no espaço do usuário.
- Isso também significa que você não pode fazer instantâneos de subvolumes dentro do seu pool. Eu adoraria ter uma máquina do tempo como instantâneos por pastas de dados do usuário em meu pool.
Eu absolutamente amo o MergerFS por sua simplicidade, mas con # 2 me deixa muito interessado em como a Netgear hackeado uma solução semelhante usando BTRFS.