Prolongar
/
O OpenZFS suporta muitas topologias de disco complexas, mas "pilha em espiral sobre uma mesa" ainda não é uma delas.
Jim Salter
comentários do leitor
102
com 48 pôsteres participantes, incluindo o autor da história
Compartilhe esta história
Compartilhar no Facebook
Compartilhar no Twitter
Compartilhe no Reddit
O desenvolvedor fundador do OpenZFS, Matthew Ahrens, abriu um PR para um dos recursos mais procurados da história do ZFS - a expansão RAIDz - na semana passada. O novo recurso permite que um usuário ZFS expanda o tamanho de um único RAIDz vdev. Por exemplo, você pode usar o novo recurso para transformar um RAIDz1 de três discos em um RAIDz1 de quatro, cinco ou seis.
Leitura Adicional
ZFS 101 - Compreendendo o armazenamento e o desempenho do ZFS
O OpenZFS é um sistema de arquivos complexo, e as coisas necessariamente ficarão um pouco complicadas ao explicar como o recurso funciona. Portanto, se você é um novato no ZFS, pode consultar nosso abrangente ZFS 101
introdução
.
Expandindo o armazenamento no ZFS
Além de ser um sistema de arquivos, o ZFS é uma matriz de armazenamento e gerenciador de volume, o que significa que você pode alimentá-lo com uma pilha inteira de dispositivos de disco, não apenas um. O coração de um sistema de armazenamento ZFS é o
zpool
—Este é o nível mais fundamental de armazenamento ZFS. o
zpool
por sua vez contém
vdevs
, e
vdevs
contêm discos reais dentro deles. As gravações são divididas em unidades chamadas
registros
ou
blocos
, que são então distribuídos de maneira semi-uniforme entre os
vdevs
.
Um armazenamento
vdev
pode ser um dos cinco tipos - um único disco, espelho,
RAIDz1
,
RAIDz2
, ou
RAIDz3
. Você pode adicionar mais
vdevs
para um
zpool
, e você pode
anexar
mais discos para um único ou espelho
vdev
. Mas gerenciar o armazenamento dessa forma requer algum planejamento prévio e orçamento - o que os entusiastas e caseiros frequentemente não estão muito entusiasmados.
Convencional
INCURSÃO
, que não compartilha o conceito de "pool" com o ZFS, geralmente oferece a capacidade de expandir e / ou remodelar um array no local. Por exemplo, você pode adicionar um único disco a um disco de seis
RAID6
array, transformando-o em um disco de sete
RAID6
variedade. Passar por uma remodelagem ao vivo pode ser muito doloroso, especialmente em matrizes quase completas; é inteiramente possível que tal tarefa exija uma semana ou mais, com o desempenho do array limitado a um quarto ou menos do normal o tempo todo.
Historicamente, o ZFS evitou esse tipo de expansão. O ZFS foi originalmente desenvolvido para uso comercial, e a remodelagem de array em tempo real é geralmente um não-iniciante no mundo dos negócios. Reduzir o desempenho do armazenamento a níveis inutilizáveis por dias a fio geralmente custa mais em folha de pagamento e despesas gerais do que comprar um conjunto inteiramente novo de hardware. A expansão ao vivo também é potencialmente muito perigosa, pois envolve a leitura e reescrita de todos os dados e coloca o array em uma condição temporária e muito menos testada "metade disso, metade daquilo" até que seja concluído.
Para usuários com muitos discos, o novo
RAIDz
é improvável que a expansão mude materialmente a forma como eles usam o ZFS. Ainda será mais fácil e prático de gerenciar
vdevs
como unidades completas, em vez de tentar sujar dentro delas. Mas amadores, caseiros e pequenos usuários que executam o ZFS com um único
vdev
provavelmente obterá muito uso do novo recurso.
Como funciona?
Prolongar
/
Neste slide, vemos um RAIDz1 de quatro discos (à esquerda) expandido para um RAIDz1 de cinco discos (à direita). Observe que os dados ainda são gravados em quatro faixas de largura!
Matthew Ahrens
De uma perspectiva prática, o novo
vdev
recurso de expansão apenas adiciona novos recursos a um comando existente, a saber,
zpool attach
, que normalmente é usado para adicionar um disco a um único disco
vdev
(transformando-o em um
espelho vdev
) ou adicione um disco extra a um
espelho
(por exemplo, girando um disco de dois
espelho
em três discos
espelho
)
Propaganda
Com o novo código, você será capaz de
anexar
novos discos para um existente
RAIDz
vdev também. Isso expande o vdev em largura, mas não altera o
vdev
tipo, então você pode virar um disco de seis
RAIDz2
vdev em um disco de sete
RAIDz2
vdev, mas você
não pode
transformá-lo em um disco de sete
RAIDz3
.
Ao emitir o seu
zpool attach
comando, a expansão começa. Durante a expansão, cada
bloquear
ou
registro
é lido do
vdev
sendo expandido e então reescrito. Os setores da reescrita
bloquear
são distribuídos entre todos os discos no
vdev
, incluindo o (s) novo (s) disco (s), mas a largura da faixa em si não é alterada. Então um
RAIDz2 vdev
expandido de seis para dez discos ainda estará cheio de seis faixas de largura após a conclusão da expansão.
Portanto, embora o usuário veja o espaço extra disponibilizado pelos novos discos, a eficiência de armazenamento dos dados expandidos não terá melhorado devido aos novos discos. No exemplo acima, partimos de um disco de seis
RAIDz2
com uma eficiência de armazenamento nominal de 67 por cento (quatro de cada seis setores são dados) para um disco de dez
RAIDz2
. Dados
recentemente
gravado no RAIDz2 de dez discos tem uma eficiência de armazenamento nominal de 80 por cento - oito em cada dez setores são dados - mas os dados expandidos antigos ainda são gravados em seis faixas de largura, portanto, ainda tem os antigos 67 por cento de eficiência de armazenamento.
É importante notar que este não é um estado inesperado ou bizarro para um vdev estar -
RAIDz
já usa uma largura de faixa dinâmica e variável para contabilizar
blocos
ou
registros
muito pequeno para distribuir em todos os discos em um único
vdev
.
Por exemplo, se você escrever um único bloco de metadados - os dados que contêm o nome de um arquivo, permissões e localização no disco - ele caberá em um único
setor
no disco. Se você gravar esse bloco de metadados em um
RAIDz2
, você não escreve uma faixa dez de largura completa - em vez disso, você
escreve uma faixa subdimensionadabloquear
apenas três discos de largura; um único dado
setor
mais duas paridade
setores
. Portanto, o "subdimensionado"
blocos
em um recém-expandido
RAIDz
vdev não é algo para o ZFS se confundir. Eles são apenas mais um dia no escritório.
Existe algum impacto duradouro no desempenho?
Como discutimos acima, um recém-expandido
RAIDz vdev
não se parecerá exatamente com um projetado assim desde o "nascimento" - pelo menos, não no início. Embora haja mais discos na combinação, a estrutura interna dos dados não é alterada.
Adicionando um ou mais novos discos ao
vdev
significa que deve ser capaz de um rendimento um pouco mais alto. Mesmo que o legado
blocos
não abranja toda a largura do
vdev
, os discos adicionados significam mais eixos para distribuir o trabalho ao redor. Isso provavelmente não aumentará a velocidade de cair o queixo, no entanto - seis faixas de largura em um disco de sete
vdev
significa que você ainda não consegue ler ou escrever dois
blocos
simultaneamente, portanto, quaisquer melhorias de velocidade provavelmente serão mínimas.
O impacto líquido no desempenho pode ser difícil de prever. Se você estiver expandindo de um disco de seis
RAIDz2
para um de sete discos
RAIDz2
, por exemplo, sua configuração original de seis discos não precisava de nenhum preenchimento. A 128 KiB
bloquear
pode ser cortado uniformemente em quatro partes de dados de 32 KiB, com duas partes de paridade de 32 KiB. O mesmo registro dividido entre
Sete
os discos requerem preenchimento porque 128KiB / cinco partes de dados não chegam a um número par de setores.
Propaganda
Da mesma forma, em alguns casos, especialmente com um pequeno
tamanho do registro
ou
volblocksize
conjunto - a carga de trabalho por disco individual pode ser significativamente menos desafiadora no layout mais antigo e estreito do que no mais novo e mais amplo. A 128 KiB
bloquear
dividido em peças de 32 KiB para um
RAIDz2
pode ser lido ou escrito com mais eficiência
por disco
do que um dividido em peças de 16 KiB para um dez de largura
RAIDz2
, por exemplo - então é um pouco complicado saber se mais discos, mas peças menores, fornecerão mais rendimento do que menos discos, mas peças maiores forneceram.
A única coisa de que você pode ter certeza é que a configuração recém-expandida deve normalmente funcionar tão bem quanto a versão não expandida original - e que, uma vez que a maioria dos dados é (re) escrita na nova largura, o
vdev
não terá um desempenho diferente ou será menos confiável do que um que foi projetado dessa forma desde o início.
Por que não remodelar registros / blocos durante a expansão?
Pode parecer estranho que o processo de expansão inicial não reescreva todos os
blocos
para a nova largura enquanto está em execução - afinal, ele está lendo e reescrevendo os dados de qualquer maneira, certo? Perguntamos a Ahrens por que a largura original foi deixada como está, e a resposta se resume a "é mais fácil e seguro assim".
Um fator importante a reconhecer é que, tecnicamente, a expansão
não é
em movimento
blocos
; está apenas se movendo
setores
. Da forma como está escrito, o código de expansão não precisa saber onde a lógica do ZFS
bloquear
limites são - a rotina de expansão não tem ideia se um indivíduo
setor
é paridade ou dados, quanto mais qual
bloquear
isso pertence a.
A expansão pode atravessar todos os
bloquear
ponteiros para localizar
bloquear
limites, e
então
saberia qual
setor
pertence ao que
bloquear
e como remodelar o
bloquear
, mas de acordo com Ahrens, fazer as coisas dessa maneira seria extremamente invasivo para o formato em disco do ZFS. A expansão precisaria ser atualizada continuamente
mapas espaciais
sobre
metaslabs
para levar em conta as mudanças no tamanho do disco de cada
bloquear
—E se o
bloquear
faz parte de um
conjunto de dados
ao invés de um
zvol
, atualize a contabilidade por conjunto de dados e por espaço de arquivo também.
Se realmente faz seus dentes coçarem sabendo que você tem quatro faixas de largura em um vdev de cinco de largura recentemente, você pode simplesmente ler e reescrever seus dados após a conclusão da expansão. A maneira mais simples de fazer isso é usar
snapshot zfs
,
zfs enviar
, e
zfs recebem
para replicar todo
conjuntos de dados
e
zvols
. Se você não está preocupado com as propriedades do ZFS, um simples
mv
operação fará o truque.
No entanto, recomendamos, na maioria dos casos, apenas relaxar e deixar o ZFS fazer seu trabalho. Seu tamanho menor
blocos
de dados mais antigos não estão prejudicando nada, e como você naturalmente exclui e / ou altera os dados ao longo da vida do
vdev
, a maioria deles será reescrita naturalmente conforme necessário, sem a necessidade de intervenção do administrador ou longos períodos de alta carga de armazenamento devido à obsessiva leitura e reescrita de tudo de uma vez.
Quando a expansão do RAIDz chegará à produção?
O novo código de Ahrens ainda não faz parte de nenhuma versão do OpenZFS, muito menos adicionado aos repositórios de outra pessoa. Perguntamos a Ahrens quando poderíamos ver o código em produção e, infelizmente, demorará um pouco.
É muito tarde para a expansão RAIDz ser incluída no próximo lançamento do OpenZFS 2.1, esperado para muito em breve (o candidato a lançamento 2.1 7 já está disponível). Deve ser incluído na próxima versão principal do OpenZFS; é muito cedo para datas concretas, mas os principais lançamentos geralmente acontecem uma vez por ano.
Em termos gerais, esperamos que a expansão do RAIDz chegue à produção de produtos como Ubuntu e FreeBSD por volta de agosto de 2022, mas isso é apenas um palpite. TrueNAS pode muito bem colocá-lo em produção antes disso, uma vez que ixSystems tende a puxar recursos do ZFS do master antes de atingirem oficialmente o status de lançamento.
Matt Ahrens apresentou a expansão RAIDz no FreeBSD Developer Summit - sua palestra começa em 1 hora e 41 minutos neste vídeo.
