it-swarm-pt.tech

Perigos e advertências do LVM

Recentemente, comecei a usar o LVM em alguns servidores para discos rígidos maiores que 1 TB. Eles são úteis, expansíveis e fáceis de instalar. No entanto, não consegui encontrar nenhum dado sobre os perigos e advertências do LVM.

Quais são as desvantagens do uso do LVM?

192
Adam Matan

Resumo

Riscos do uso de LVM:

  • Vulnerável para gravar problemas de armazenamento em cache com SSD ou hypervisor VM
  • Mais difícil de recuperar dados devido a estruturas em disco mais complexas
  • Mais difícil de redimensionar os sistemas de arquivos corretamente
  • Instantâneos são difíceis de usar, lentos e com erros
  • Requer alguma habilidade para configurar corretamente, considerando esses problemas

Os dois primeiros problemas do LVM se combinam: se o cache de gravação não estiver funcionando corretamente e você tiver uma perda de energia (por exemplo, falha na PSU ou no UPS), poderá ser necessário recuperar do backup, o que significa um tempo de inatividade significativo. Um dos principais motivos para usar o LVM é o tempo de atividade mais alto (ao adicionar discos, redimensionar sistemas de arquivos, etc.), mas é importante corrigir a configuração do cache de gravação para evitar que o LVM reduza o tempo de atividade.

- Atualizado em dezembro de 2019: pequena atualização no btrfs e no ZFS como alternativas aos instantâneos do LVM

Atenuando os riscos

O LVM ainda pode funcionar bem se você:

  • Obtenha a configuração correta do cache de gravação em hypervisor, kernel e SSDs
  • Evite instantâneos do LVM
  • Use versões recentes do LVM para redimensionar sistemas de arquivos
  • Tenha bons backups

Detalhes

Eu pesquisei isso bastante no passado, tendo experimentado alguma perda de dados associada ao LVM. Os principais riscos e problemas do LVM que eu conheço são:

Vulnerável ao cache de gravação no disco rígido devido a VM hipervisores, cache de disco ou kernels antigos do Linux e dificulta para recuperar dados devido a estruturas em disco mais complexas - veja abaixo os detalhes. Vi configurações completas do LVM em vários discos serem corrompidas sem chance de recuperação, e o LVM mais o cache de gravação no disco rígido são uma combinação perigosa.

  • O cache de gravação e a reordenação de gravação pelo disco rígido são importantes para o bom desempenho, mas podem falhar na liberação correta dos blocos no disco devido a hipervisores VM, cache de gravação no disco rígido, kernels antigos do Linux, etc.
    • Barreiras de gravação significa que o kernel garante que ele concluirá determinadas gravações em disco antes da gravação em disco "barreira", para garantir que os sistemas de arquivos e o RAID possam se recuperar no caso de uma súbita perda de energia ou travamento. Essas barreiras podem usar uma operação FUA (Force Unit Access) para gravar imediatamente certos blocos no disco, o que é mais eficiente do que uma descarga de cache completo. As barreiras podem ser combinadas com o enfileiramento eficiente de comandos tagged / native (/ emitindo várias solicitações de E/S de disco de uma só vez) para permitir que o disco rígido execute gravações inteligentes -ordenação sem aumentar o risco de perda de dados.
  • Os hipervisores de VM podem ter problemas semelhantes: executar o LVM em um convidado do Linux sobre um hipervisor VM, como VMware, Xen , KVM, O Hyper-V ou o VirtualBox podem criar problemas semelhantes para um kernel sem barreiras de gravação, devido ao cache de gravação e reordenação de gravação. Verifique cuidadosamente a documentação do hypervisor para uma opção de "liberação para disco" ou cache de gravação (presente em KVM , VMware , Xen , VirtualBox e outros) - e teste-o com sua configuração. Alguns hipervisores como o VirtualBox possuem uma configuração padrão que ignora qualquer liberação de disco do convidado.
  • Os servidores corporativos com LVM sempre devem usar um controlador RAID com bateria e desabilitar o cache de gravação no disco rígido (o controlador possui um cache de gravação com bateria que é rápido e seguro) - consulte este comentário pelo autor de this XFS FAQ entry . Também pode ser seguro desativar as barreiras de gravação no kernel, mas o teste é recomendado.
  • Se você não tiver um controlador RAID com bateria, desabilitar o cache de gravação no disco rígido diminuirá significativamente as gravações, mas tornará o LVM seguro. Você também deve usar o equivalente da opção data=ordered do ext3 (ou data=journal para segurança extra), além de barrier=1 para garantir que o cache do kernel não afete a integridade. (Ou use ext4 que habilite barreiras por padrão .) Essa é a opção mais simples e fornece boa integridade de dados a custo de desempenho. (Linux alterou a opção ext3 padrão para a mais perigosa data=writeback há um tempo, por isso não confie nas configurações padrão do FS.)
  • Para desativar o cache de gravação do disco rígido : adicione hdparm -q -W0 /dev/sdX para todas as unidades em /etc/rc.local (para SATA) ou use sdparm para SCSI/SAS. No entanto, de acordo com this entry no XFS FAQ (que é muito bom neste tópico), uma unidade SATA pode esquecer essa configuração após uma recuperação de erro da unidade - portanto, você deve usar SCSI/SAS ou, se você precisar usar o SATA, coloque o comando hdparm em um trabalho cron executando a cada minuto aproximadamente.
  • Para manter o cache de gravação SSD/disco rígido ativado para obter melhor desempenho: essa é uma área complexa - consulte a seção abaixo.
  • Se você estiver usando unidades de formato avançado , ou seja, setores físicos de 4 KB, veja abaixo - desativar o cache de gravação pode ter outros problemas.
  • [~ # ~] ups [~ # ~] é essencial para empresas e SOHO, mas não é suficiente para tornar o LVM seguro: qualquer coisa que cause uma falha grave ou uma perda de energia (por exemplo, falha do no-break) , Falha na PSU ou esgotamento da bateria do laptop) podem perder dados nos caches do disco rígido.
  • Kernels Linux muito antigos (2.6.x de 2009) : Há suporte incompleto à barreira de gravação nas versões muito antigas do kernel, 2.6.32 e anteriores ( 2.6.31 tem algum suporte , enquanto 2.6.33 funciona para todos os tipos de destino de dispositivo) - RHEL 6 usa 2.6.32 com muitos patches. Se esses kernels 2.6 antigos não tiverem patches para esses problemas, uma grande quantidade de metadados FS (incluindo diários) poderá ser perdida por uma falha grave que deixa os dados nos buffers de gravação dos discos rígidos (por exemplo, 32 MB por unidade Unidades SATA). Perder 32 MB dos metadados e dos dados do diário FS gravados mais recentemente, que o kernel pensa que já está no disco, geralmente significa muita corrupção do FS e, portanto, perda de dados.
  • Resumo:você deve cuidar do sistema de arquivos, RAID, VM hypervisor e configuração do disco rígido/SSD usado com o LVM. Você deve ter backups muito bons se estiver usando o LVM e não se esqueça de fazer backup específico dos setores de metadados, configuração da partição física, MBR e inicialização de volume do LVM. Também é aconselhável usar unidades SCSI/SAS, pois é menos provável que elas mentam sobre como eles fazem o cache de gravação - é necessário mais cuidado com o uso de unidades SATA.

Mantendo o cache de gravação ativadopara desempenho (e lidando com unidades em repouso)

Uma opção mais complexa, porém com desempenho, é manter o cache de gravação SSD/disco rígido ativado e confiar nas barreiras de gravação do kernel que trabalham com o LVM no kernel 2.6.33+ (verifique novamente procurando mensagens de "barreira" nos logs).

Você também deve garantir que a configuração RAID, VM configuração do hipervisor e o sistema de arquivos use barreiras de gravação (isto é, exige que a unidade libere gravações pendentes antes e depois dos principais metadados/gravações de diário). XFS usa barreiras por padrão, mas o ext3 não usa , portanto, com o ext3, você deve usar barrier=1 nas opções de montagem e ainda usar data=ordered ou data=journal como acima.

  • Infelizmente, alguns discos rígidos e SSDsmentem sobre se realmente liberaram seu cachepara o disco (particularmente unidades mais antigas, mas incluindo algumas unidades SATA e alguma empresa). SSDs ) - mais detalhes aqui . Existe um ótimo resumo de de um desenvolvedor de XFS .
  • Existe uma ferramenta de teste simples para unidades em repouso (script Perl), ou consulte este plano de fundo com outra ferramenta testing para reordenar a gravação como resultado da unidade cache. Esta resposta abrangeu testes semelhantes de unidades SATA que descobriram um problema de barreira de gravação no RAID de software - esses testes realmente exercitam toda a pilha de armazenamento.
  • As unidades SATA mais recentes que suportam Native Command Queuing (NCQ) podem ter menos probabilidade de mentir - ou talvez tenham um bom desempenho sem cache de gravação devido ao NCQ e muito algumas unidades não podem desativar o cache de gravação.
  • As unidades SCSI/SAS geralmente são boas, pois não precisam de cache de gravação para ter um bom desempenho (por meio do SCSI Tagged Command Queuing , semelhante ao NCQ da SATA).
  • Se seus discos rígidos ou SSDs mentirem sobre a liberação de cache em disco, você realmente não pode confiar em barreiras de gravação e deve desativar o cache de gravação. Este é um problema para todos os sistemas de arquivos, bancos de dados, gerenciadores de volume e software RAID /, não apenas para o LVM.

SSDssão problemáticos porque o uso do cache de gravação é crítico para a vida útil do SSD. É melhor usar um SSD que tenha um supercapacitor (para habilitar a liberação do cache em caso de falta de energia e, portanto, permitir que o cache seja gravado de volta, não gravado).

Formato avançadoconfiguração da unidade - cache de gravação, alinhamento, RAID, GPT

  • Com as unidades Advanced Format mais recentes que usam 4 setores físicos de KiB, pode ser importante manter o cache de gravação de unidade ativado, pois a maioria dessas unidades atualmente simula setores lógicos de 512 bytes ( "emulação 512" " ), e alguns até afirmam ter setores físicos de 512 bytes enquanto realmente usam 4 KiB.
  • Desativar o cache de gravação de uma unidade de Formato Avançado pode causar um impacto muito grande no desempenho se o aplicativo/kernel estiver executando gravações de 512 bytes, pois essas unidades dependem do cache para acumular gravações de 8 x 512 bytes antes de executar um único físico de 4 KiB Escreva. O teste é recomendado para confirmar qualquer impacto se você desativar o cache.
  • Alinhar os LVs em um limite de 4 KiB é importante para o desempenho, mas deve acontecer automaticamente, desde que as partições subjacentes aos PVs estejam alinhadas, pois as LVM Physical Extents (PEs) são 4 MiB por padrão. O RAID deve ser considerado aqui - esta página de configuração do LVM e do software RAID sugere colocar o superbloqueio de RAID no final do volume e (se necessário) usando uma opção em pvcreate para alinhar os PVs. Este tópico da lista de email do LVM aponta para o trabalho realizado nos kernels durante 2011 e a questão das gravações parciais em bloco ao misturar discos com setores de 512 bytes e 4 KiB em um único LV.
  • O partição GPT com Advanced Format precisa de cuidados, especialmente para discos de inicialização + raiz, para garantir que a primeira partição LVM (PV) inicie em um limite de 4 KiB.

Mais difícil de recuperar dados devido a estruturas em disco mais complexas :

  • Qualquer recuperação de dados LVM necessária após uma falha grave ou perda de energia (devido ao cache de gravação incorreto) é um processo manual, na melhor das hipóteses, porque aparentemente não existem ferramentas adequadas. O LVM é bom em fazer backup de seus metadados em /etc/lvm, o que pode ajudar a restaurar a estrutura básica de LVs, VGs e PVs, mas não ajuda com os metadados perdidos do sistema de arquivos.
  • Portanto, é provável que seja necessária uma restauração completa do backup. Isso envolve muito mais tempo de inatividade do que um fsck rápido baseado em diário quando não estiver usando o LVM, e os dados gravados desde o último backup serão perdidos.
  • TestDisk , ext3grep , ext3undel e outras ferramentas pode recuperar partições e arquivos de discos não LVM, mas eles não suportam diretamente a recuperação de dados LVM. O TestDisk pode descobrir que uma partição física perdida contém um PV do LVM, mas nenhuma dessas ferramentas entende os volumes lógicos do LVM. Gravação de arquivos ferramentas como PhotoRec / e muitas outras funcionariam ao contornar o sistema de arquivos para remontar arquivos de blocos de dados, mas este é o último recurso , abordagem de baixo nível para dados valiosos e funciona menos bem com arquivos fragmentados.
  • A recuperação manual do LVM é possível em alguns casos, mas é complexa e demorada - consulte este exemplo e this , this e this para saber como recuperar.

Mais difícil de redimensionar os sistemas de arquivos corretamente - o redimensionamento fácil do sistema de arquivos é geralmente oferecido como um benefício do LVM, mas você precisa executar meia dúzia Comandos do shell para redimensionar um FS baseado em LVM - isso pode ser feito com o servidor inteiro ainda ativo e, em alguns casos, com o FS montado, mas eu nunca arriscaria esse último sem backups atualizados e usando comandos pré-testados em um servidor equivalente (por exemplo, clone de recuperação de desastre do servidor de produção).

  • Update:Versões mais recentes de lvextend suportam a opção -r (--resizefs) - se esta for disponível, é uma maneira mais segura e rápida de redimensionar o LV e o sistema de arquivos, principalmente se você estiver diminuindo o FS, e você pode pular esta seção.
  • A maioria dos guias para redimensionar FSs baseados em LVM não leva em consideração o fato de que o FS deve ser um pouco menor que o tamanho do LV: explicação detalhada aqui . Ao reduzir um sistema de arquivos, você precisará especificar o novo tamanho da ferramenta de redimensionamento FS, por exemplo resize2fs para ext3 e para lvextend ou lvreduce. Sem muito cuidado, os tamanhos podem ser ligeiramente diferentes devido à diferença entre 1 GB (10 ^ 9) e 1 GiB (2 ^ 30), ou pela maneira como as várias ferramentas arredondam o tamanho ou baixa.
  • Se você não fizer os cálculos exatamente da maneira correta (ou usar algumas etapas adicionais além das mais óbvias), poderá acabar com um FS que é muito grande para o LV. Tudo ficará bem por meses ou anos, até que você preencha completamente o FS, e nesse ponto você sofrerá uma grave corrupção - e, a menos que esteja ciente desse problema, é difícil descobrir o motivo, pois você também pode ter erros reais de disco até então. que obscurecem a situação. (É possível que esse problema afete apenas a redução do tamanho dos sistemas de arquivos - no entanto, é claro que o redimensionamento dos sistemas de arquivos em qualquer direção aumenta o risco de perda de dados, possivelmente devido a erro do usuário.)
  • Parece que o tamanho do LV deve ser maior que o tamanho FS em 2 x o tamanho da extensão física (PE) do LVM - mas verifique o link acima para obter detalhes, pois a fonte para isso não é autorizada. Geralmente, permitir 8 MiB é suficiente, mas pode ser melhor permitir mais, por exemplo 100 MiB ou 1 GiB, apenas por segurança. Para verificar o tamanho do PE e seu volume lógico + tamanhos de FS, usando blocos de 4 KiB = 4096 bytes:

    Mostra o tamanho do PE em KiB:
    vgdisplay --units k myVGname | grep "PE Size"

    Tamanho de todos os LVs:
    lvs --units 4096b

    Tamanho do (ext3) FS, assume 4 KiB FS tamanho do bloco:
    tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

  • Por outro lado, uma configuração que não seja LVM torna o redimensionamento do FS muito confiável e fácil - execute Gparted / e redimensione os FSs necessários, e fará tudo por você. Nos servidores, você pode usar parted do Shell.

    • Geralmente, é melhor usar o Gparted Live CD ou Parted Magic /, pois eles possuem um kernel e um kernel recente e frequentemente mais livre de bugs do que a versão de distribuição - Certa vez, perdi um FS inteiro devido ao Gparted da distro não atualizar as partições corretamente no kernel em execução. Se estiver usando o Gparted da distribuição, certifique-se de reiniciar imediatamente após alterar as partições para que a visualização do kernel esteja correta.

Instantâneos são difíceis de usar, lentos e com bugs - se o instantâneo ficar sem espaço pré-alocado, será automaticamente caiu . Cada captura instantânea de um determinado LV é um delta contra esse LV (não contra as capturas instantâneas anteriores) que pode exigir muito espaço ao capturar sistemas de arquivos com atividade de gravação significativa (cada captura instantânea é maior que a anterior). É seguro criar um LV de instantâneo com o mesmo tamanho do LV original, pois o instantâneo nunca ficará sem espaço livre.

Os instantâneos também podem ser muito lentos (o que significa 3 a 6 vezes mais lento que sem o LVM para esses testes do MySQL ) - veja esta resposta cobrindo vários problemas de instantâneo . A lentidão é parcialmente porque snapshots requerem muitas gravações síncronas .

Os snapshots tiveram alguns bugs significativos, por exemplo em alguns casos eles podem tornar a inicialização muito lenta ou causar uma falha completa na inicialização (porque o kernel pode atingir o tempo limite / aguardando a raiz FS quando é um instantâneo do LVM [corrigido no Debian initramfs-tools update, mar 2015]).

  • No entanto, muitos erros de condição de corrida de captura instantânea foram aparentemente corrigidos até 2015.
  • O LVM sem snapshots geralmente parece muito bem depurado, talvez porque os snapshots não são usados ​​tanto quanto os recursos principais.

Alternativas à captura instantânea- sistemas de arquivos e hipervisores VM

Instantâneos de VM/nuvem:

  • Se você estiver usando um hipervisor VM ou um provedor de nuvem IaaS (por exemplo, VMware, VirtualBox ou Amazon EC2/EBS), seus instantâneos geralmente são uma alternativa muito melhor aos instantâneos LVM. Você pode facilmente tirar um instantâneo para fins de backup (mas considere congelar o FS antes de fazê-lo).

Instantâneos do sistema de arquivos:

  • as capturas instantâneas no nível do sistema de arquivos com ZFS ou btrfs são fáceis de usar e geralmente melhores que o LVM, se você estiver usando bare metal (mas o ZFS parece muito mais maduro, apenas mais problemas para instalar):

    • ZFS: agora existe uma implementação de kernel ZFS , que está em uso há alguns anos, e o ZFS parece estar ganhando adoção. O Ubuntu agora possui o ZFS como uma opção 'pronta para uso', incluindo o ZFS experimental no root em 19.10 .
    • btrfs: ainda não está pronto para uso em produção ( mesmo no openSUSE que o envia por padrão e possui uma equipe dedicada ao btrfs), enquanto o RHEL parou de suportá-lo). O btrfs agora tem uma ferramenta fsck (FAQ) , mas o FAQ recomenda que você consulte um desenvolvedor, se precisar fsck um sistema de arquivos quebrado.

Instantâneos para backups on-line e fsck

As capturas instantâneas podem ser usadas para fornecer uma fonte consistente para backups, desde que você tenha cuidado com o espaço alocado (idealmente, a captura instantânea tem o mesmo tamanho do backup do LV). O excelente rsnapshot (desde 1.3.1) até gerencia a criação/exclusão de instantâneos do LVM para você - veja este HOWTO no rsnapshot usando LVM /. No entanto, observe os problemas gerais dos instantâneos e que um instantâneo não deve ser considerado um backup por si só.

Você também pode usar os instantâneos do LVM para executar um fsck on-line: faça o snapshot do LV e do fsck o snapshot, enquanto ainda estiver usando o non-snapshot principal FS - descrito aqui - no entanto, é não totalmente direto então é melhor usar e2croncheck as descrito por Ted Ts'o , mantenedor do ext3.

Você deve "congelar" o sistema de arquivos temporariamente enquanto tira a captura instantânea - alguns sistemas de arquivos como ext3 e XFS fazem isso automaticamente quando o LVM cria a captura instantânea.

Conclusões

Apesar de tudo isso, ainda uso o LVM em alguns sistemas, mas para uma configuração de área de trabalho, prefiro partições brutas. O principal benefício que vejo do LVM é a flexibilidade de mover e redimensionar FSs quando você deve ter um tempo de atividade alto em um servidor - se você não precisar, o gparted é mais fácil e tem menos risco de perda de dados.

O LVM requer muito cuidado na configuração do cache de gravação devido a hipervisores VM, cache de gravação no disco rígido/SSD e assim por diante - mas o mesmo se aplica ao uso do Linux como servidor de banco de dados. A falta de suporte da maioria das ferramentas (gparted incluindo os cálculos críticos de tamanho e testdisk etc) torna mais difícil o uso do que deveria.

Se estiver usando o LVM, tome muito cuidado com os instantâneos: use instantâneos de VM/nuvem, se possível, ou investigue o ZFS/btrfs para evitar o LVM completamente - você pode achar que o ZFS ou btrs é suficientemente maduro em comparação com o LVM com instantâneos.

Conclusão: se você não conhece os problemas listados acima e como resolvê-los, é melhor não usar o LVM.

255
RichVel

Eu [+1] nessa postagem e, pelo menos para mim, acho que a maioria dos problemas existe. Você os viu executando alguns 100 servidores e alguns 100 TB de dados. Para mim, o LVM2 no Linux parece uma "idéia inteligente" que alguém teve. Como alguns desses, eles acabam sendo "pouco inteligentes" às vezes. I.e. não ter os estados estritamente separados do kernel e do espaço do usuário (lvmtab) pode ter sido realmente inteligente para acabar com isso, porque pode haver problemas de corrupção (se você não entender o código corretamente)

Bem, apenas que essa separação estava lá por uma razão - as diferenças são mostradas com o tratamento de perdas de PV e a reativação on-line de um VG com PVs ausentes para trazê-los de volta ao jogo - O que é fácil nos "LVMs originais" (AIX, HP-UX) se transforma em lixo no LVM2, pois o tratamento de estado não é bom o suficiente. E nem me fale sobre detecção de perda de quorum (haha) ou manipulação de estado (se eu remover um disco, isso não será sinalizado como indisponível. Ele nem possui a maldita coluna de status)

Re: estabilidadepvmove ... por que é

perda de dados pvmove

um artigo tão bem classificado no meu blog, hmmm? Agora, eu olho para um disco em que os dados phyiscal lvm ainda estão suspensos no estado no meio do pvmove. Acho que existem alguns erros de memória, e a ideia geral de que é bom copiar dados de blocos ao vivo do espaço do usuário é triste. Uma boa citação da lista lvm "parece que vgreduce --missing não lida com pvmove" Significa que, se um disco se desconecta durante o pvmove, a ferramenta de gerenciamento do lvm muda de lvm para vi. Ah, e também houve um bug em que o pvmove continua após um erro de leitura/gravação em bloco e, de fato, não grava mais dados no dispositivo de destino. WTF?

Re: Snapshots O CoW é feito de maneira insegura, atualizando os NOVOS dados na área lv do snapshot e depois mesclando novamente quando você excluir o snap. Isso significa que você tem picos fortes de IO durante a mesclagem final de novos dados no LV original e, muito mais importante, é claro que você também tem um risco muito maior de corrupção de dados, porque não o instantâneo será quebrado assim que você bater na parede, mas o original.

A vantagem está no desempenho, fazer 1 gravação em vez de 3. Escolher o algoritmo rápido, mas não seguro, é algo que obviamente se espera de pessoas como VMware e MS, no "Unix". Eu prefiro pensar que as coisas seriam "feitas corretamente". Não vi muitos problemas de desempenho desde que eu tenha o armazenamento de backup de instantâneo em uma unidade de disco diferente do que os dados primários (e faça backup para outra um é claro)

Re: Barreiras Não tenho certeza se alguém pode culpar isso no LVM. Era uma questão de devmapper, até onde eu sei. Mas pode haver alguma culpa por não se importar muito com esse problema, pelo menos do kernel 2.6 até 2.6.33. O AFAIK Xen é o único hypervisor que usa O_DIRECT para as máquinas virtuais, o problema costumava ser quando "loop" era usado porque o kernel ainda armazenaria em cache usando isso. O Virtualbox tem pelo menos alguma configuração para desativar coisas como essa e o Qemu/KVM geralmente parece permitir o armazenamento em cache. Todos os fusíveis FS também estão tendo problemas lá (sem O_DIRECT)

Re: Sizes Acho que o LVM faz "arredondamento" do tamanho exibido. Ou ele usa GiB. De qualquer forma, você precisa usar o tamanho VG Pe e multiplicá-lo pelo número LE do LV. Isso deve fornecer o tamanho correto da rede e esse problema é sempre um problema de uso. É piorado por sistemas de arquivos que não percebem isso durante o fsck/mount (hello, ext3) ou não têm um "fsck -n" on-line em funcionamento (hello, ext3)

É claro que é revelador que você não consegue encontrar boas fontes para essas informações. "quantos LE para o VRA?" "qual é o deslocamento phyiscal para PVRA, VGDA, ... etc"

Comparado ao original, o LVM2 é o principal exemplo de "Quem não entende o UNIX está condenado a reinventá-lo mal".

Atualize alguns meses depois: já estou acessando o cenário "snapshot completo" para um teste. Se ficarem cheios, o instantâneo será bloqueado, não o LV original. Eu estava errado lá quando publiquei isso pela primeira vez. Peguei informações erradas de algum documento, ou talvez eu tivesse entendido. Nas minhas configurações, eu sempre fui muito paranóico em não deixá-los encher e, portanto, nunca acabei corrigido. Também é possível estender/reduzir snapshots, o que é um prazer.

O que ainda não consegui resolver é como identificar a idade de um instantâneo. Quanto ao seu desempenho, há uma observação na página do projeto "thinp" do Fedora, que diz que a técnica de snapshot está sendo revisada para que eles não fiquem mais lentos a cada snapshot. Não sei como eles estão implementando.

15
Florian Heigl

se você planeja usar snapshots para backups - esteja preparado para grandes ocorrências de desempenho quando o snapshot estiver presente. leia mais aqui . caso contrário, está tudo bem. uso o lvm em produção há alguns anos em dezenas de servidores, embora o meu principal motivo para usá-lo seja a capacidade de snapshot atômico não expandir volumes facilmente.

aliás, se você usar uma unidade de 1 TB, lembre-se do alinhamento de partições - essa unidade provavelmente possui setores físicos de 4kB.

12
pQd

Adão,

Outra vantagem: você pode adicionar um novo volume físico (PV), mover todos os dados para esse PV e remover o PV antigo sem interrupções de serviço. Eu usei essa capacidade pelo menos quatro vezes nos últimos cinco anos.

Uma desvantagem que ainda não vi apontada claramente: há uma curva de aprendizado um tanto íngreme para o LVM2. Principalmente na abstração criada entre seus arquivos e a mídia subjacente. Se você trabalha com apenas algumas pessoas que compartilham tarefas em um conjunto de servidores, poderá encontrar uma complexidade extra esmagadora para sua equipe como um todo. Equipes maiores dedicadas ao trabalho de TI geralmente não terão esse problema.

Por exemplo, usamos amplamente aqui no meu trabalho e levamos tempo para ensinar a toda a equipe o básico, o idioma e o essencial sobre a recuperação de sistemas que não inicializam corretamente.

Um cuidado especificamente a ser destacado: se você inicializar a partir de um volume lógico LVM2, você encontrará dificuldades nas operações de recuperação quando o servidor travar. Knoppix e amigos nem sempre têm o material certo para isso. Então, decidimos que nosso diretório/boot estaria em sua própria partição e sempre seria pequeno e nativo.

No geral, sou fã de LVM2.

5
Mike Diehn

Algumas coisas:

Abrangendo LVs em vários PVs

Eu já vi pessoas defendendo (StackExchange e outros lugares) estendendo [~ # ~] vm [~ # ~] espaço lateralmente: aumentando o espaço adicionando [~ # ~] adicional [~ # ~] PVs para um VG vs aumentando um [~ # ~] single [~ # ~] PV. É feio e espalha seu (s) sistema (s) de arquivos por vários PVs, criando uma dependência em uma cadeia de PVs cada vez mais longa. É assim que seus sistemas de arquivos serão se você dimensionar o armazenamento da sua VM lateralmente:

Illustrative graphic add vs increase PV

Perda de dados se um PV perdeu a hospedagem Parte de um LV estendido

Eu já vi muita confusão sobre isso. Se um LV Linear- - e o sistema de arquivos que nele habita - são distribuídos por vários PVs, experimentariam COMPLETO ou Perda de dados parciais? Aqui está a resposta ilustrada:

Illustration of data loss for Spanned LV if PV lost

Logicamente, é isso que devemos esperar. Se as extensões que mantêm nossos dados de LV forem espalhadas por vários PVs e um desses PVs desaparecer, o sistema de arquivos nesse LV seria catastroficamente danificado.

Espero que esses pequenos rabiscos tornem um assunto complexo um pouco mais fácil de entender os riscos ao trabalhar com LVM

0
F1Linux