O LVM afeta o desempenho?

Preciso migrar alguns servidores para o Linux, e um aspecto importante que preciso avaliar é que meu novo sistema host deve ter capacidade de armazenamento elástico. Naturalmente, fazendo algumas pesquisas básicas, me deparei com o LVM.

Existe alguma penalidade de desempenho por usar o lvm? Se sim, como posso medi-lo?

O que estou pensando agora é ter o Linux como um SO host com LVM e caixas Linux virtualizadas em execução (devo adicionar o LVM também no SO convidado?).

O LVM é projetado de uma maneira que impede que realmente atrapalhe muito o caminho. Do ponto de vista do espaço do usuário, parece outra camada de "material virtual" na parte superior do disco, e parece natural imaginar que toda a E / S precisa passar por isso antes de chegar ou sair do real hardware.

Mas não é assim. O kernel já precisa ter um mapeamento (ou várias camadas de mapeamento, na verdade) que conecte operações de alto nível como "grave isso em um arquivo" aos drivers de dispositivo que, por sua vez, se conectam aos blocos reais no disco.

Quando o LVM está em uso, essa pesquisa é alterada, mas é tudo. (Como isso tem que acontecer de qualquer maneira, fazê-lo de maneira um pouco diferente é um impacto insignificante no desempenho.) Quando se trata de gravar o arquivo, os bits seguem um caminho tão direto para a mídia física quanto o contrário.

Há casos em que o LVM pode causar problemas de desempenho. Você deseja garantir que os blocos LVM estejam alinhados corretamente com o sistema subjacente, o que deve ocorrer automaticamente nas distribuições modernas. E certifique-se de não usar kernels antigos sujeitos a erros como este . Ah, e o uso de instantâneos LVM diminui o desempenho (e cada vez mais a cada instantâneo ativo). Mas, principalmente, o impacto deve ser muito pequeno.

Quanto ao último: como você pode testar? A ferramenta de benchmarking de disco padrão é o bonnie ++ . Faça uma partição com o LVM, teste-a, limpe-a e (no mesmo local, para manter outros fatores idênticos) crie um sistema de arquivos simples e faça uma comparação novamente. Eles devem ser quase idênticos.

LVM, como todo o resto, é uma bênção mista.

Com relação ao desempenho, o LVM o atrapalhará um pouco, pois é outra camada de abstração que precisa ser trabalhada antes que os bits atinjam (ou possam ser lidos a partir) do disco. Na maioria das situações, esse impacto no desempenho será praticamente incomensurável.

As vantagens do LVM incluem o fato de que você pode adicionar mais armazenamento aos sistemas de arquivos existentes sem precisar mover dados. A maioria das pessoas gosta dessa vantagem.

Uma desvantagem do LVM usada dessa maneira é que, se seu armazenamento adicional abrange discos (isto é, envolve mais de um disco), você aumenta a probabilidade de que uma falha no disco lhe custe os dados. Se o seu sistema de arquivos abranger dois discos, e um deles falhar, você provavelmente está perdido. Para a maioria das pessoas, esse é um risco aceitável devido a razões de espaço versus custo (ou seja, se isso é realmente importante, haverá um orçamento para fazê-lo corretamente) - e porque, como dizem, os backups são bons, certo?

Para mim, o único motivo para não usar o LVM é que a recuperação de desastres não está (ou pelo menos não foi) bem definida. Um disco com volumes LVM com um SO embaralhado não podia ser conectado trivialmente a outro computador e os dados recuperados; muitas das instruções para recuperar volumes LVM pareciam incluir etapas como voltar no tempo e executar vgcfgbackup e copiar o arquivo / etc / lvmconf resultante para o sistema que hospeda seu volume hospedado . Espero que as coisas tenham mudado nos últimos três ou quatro anos desde a última vez que olhei para isso, mas pessoalmente nunca uso o LVM por esse motivo.

Dito isto.

No seu caso, eu presumo que as VMs serão relativamente pequenas em comparação com o sistema host. Isso significa para mim que é mais provável que você queira expandir o armazenamento em uma VM mais tarde; isso é melhor feito adicionando outro disco virtual à VM e aumentando os sistemas de arquivos da VM afetados. Você não tem a vulnerabilidade de expansão de vários discos, porque os discos virtuais provavelmente estarão no mesmo dispositivo físico no sistema host.

Se as VMs tiverem alguma importância para você, você estará RAID no sistema host de alguma forma, o que reduzirá a flexibilidade para aumentar o armazenamento posteriormente. Portanto, a flexibilidade do LVM provavelmente não será necessária.

Então, eu presumo que você não usaria o LVM no sistema host, mas instalaria VMs para usar o LVM.

Em geral: se você adicionar uma nova camada de complexidade ("mais a fazer") nada será mais rápido. Nota: Você apenas adiciona trabalho e não 'altera' a maneira como o trabalho é feito.

Como você pode medir algo? Bem, você cria uma partição com o LVM e outra sem, depois usa uma referência normal e apenas a executa. Como o pessoal da

http://www.umiacs.umd.edu/~toaster/lvm-testing/

Como parece, apenas um pouco de impacto para a velocidade. Isso parece estar sincronizado com as descobertas de outra pessoa que executou uma referência:

"ext4 é mais rápido com LVM do que sem e outros benchmarks do sistema de arquivos" Thread da Lista de discussão do kernel do Linux

Mas faça o benchmark sozinho e veja se o hardware e o sistema operacional que você deseja usar se comportam da mesma maneira e se você pode ignorar o impacto (talvez um pouco) de uma camada adicional de complexidade que oferece armazenamento elástico.

Você deve adicionar o LVM ao sistema operacional convidado: isso depende se você precisa que o sistema operacional convidado também tenha armazenamento elástico, não é? Suas necessidades ditam o que você deve implantar.

Devo adicionar o LVM também no SO convidado?

Você não deve, pois ter um sistema de arquivos ext3 ou ext 4 dentro do volume lógico do host deve ser suficiente. Não há necessidade de adicionar outro grupo de volumes, volume físico e volume lógico.

Não haveria muito impacto no desempenho apenas no lvm, mas se você estiver disposto a aceitá-lo, use o zfs. Você obtém gerenciamento de volume e capacidade de recuperação e todos os tipos de outros ótimos recursos.

Ninguém menciona lvm2 pode fazer com que a velocidade de leitura e gravação seja multiplicada (semelhante ao raid0). Pessoalmente, uso 3 discos idênticos e, sobre eles, lvm2 no modo strip, as operações de leitura e gravação levam 1/3 do tempo, isso é um grande impacto, o sistema de arquivos é três vezes mais rápido. Eu sei: qualquer disco falha e todos os dados neles não serão acessíveis; mas isso não significa perda, já que os backups são obrigatórios, nada como Raid, LVM2, ZFS evitará ter backups; então eu nunca uso espelhamento, raid5 e tal, eu sempre uso strip (para obter o máximo desempenho) e sincronizei os BackUPs. O ZFS é ótimo para compactação on-the-fly, e com o parâmetro de cópias maior que um é como espelhamento, mas uma coisa que o ZFS possui e mais ninguém possui é recuperar automaticamente a podridão em tempo real (bits que mudam espontaneamente enquanto o disco está desligado),

Para resumir: eu uso o ZFS apenas para meus BackUPs em discos externos, vários (dois ou três) ssd com lvm2 distribuído para o SO (após atualizações refazer o clone do SO), tendem a usar o SO imutável; e eu uso vários (seis) discos spinnin com lvm2 despojado para dados, como máquinas virtuais, novamente depois de qualquer alteração e refazer BackUPs; então, após qualquer falha no disco, só preciso substituí-lo e restaurar o último backup; hoje em dia, tenho velocidade de gravação próxima a 1,8 GiB / s, portanto, restaurar uma máquina virtual do BackUP leva apenas menos de 30 segundos (32 GiB por disco da máquina virtual).

Portanto, minha resposta é: não use apenas uma coisa, seja inteligente e use o melhor de cada parte, o lvm2 stripped é mais rápido que o mdraid nível 0, mais ao usar seis discos giratórios; um aviso com remoção de ssd, dois e três é bom, quatro ssd podem prejudicar o desempenho (meus testes forneceram velocidade de gravação mais baixa quando eu usei quatro ssd idênticos no modo stripped, não importa se lvm, mdraid0, etc.), parece que o SSD TRIM e outros A amplificação de gravação pode ser a principal causa da adição de mais ssd ao volume reduzido, reduzindo a velocidade de gravação.

Waring com ssd e qualquer raid0 (volumes removidos), alinhar as coisas perfeitamente, atribuir tamanhos de cluster no sistema de arquivos corretamente, tamanho stip, etc, para que ninguém cause degradação; como exemplo: o setor de disco é 2048, portanto, 2K em qualquer leitura / gravação como mínimo, nunca use um sistema de arquivos que use um clusyer de 512 bytes; além disso, é melhor usar o tamanho de cluster 2K ou 4K; Agora, imagine que você usa 3xHDD, cada um dos setores de 2K, portanto, em qualquer cluster de sistema de arquivos com otimização de leitura / gravação seria 3x2K = 6K, mas isso não é possível em muitos sistemas de arquivos, pense em se usar um tamanho de cluster de 64K, 64K / 6K = 32 / 3, que causa desequilíbrio, então não é o ideal e assim por diante. Faça matemática para obter o tamanho ideal do cluster.

Meus melhores resultados são: Tamanho do cluster = tamanho da faixa * número de disco na faixa; dessa maneira, cada leitura / gravação é do tamanho exato que faz com que todos os discos funcionem, portanto, a melhoria da velocidade é ralmente grande. Um exemplo de tamanho de cluster de 192K para 3 discos com tamanho de faixa de 64K; outro exemplo de tamanho de cluster de 192K para 6 discos com tamanho de faixa de 32K.

E lembre-se sempre de testar um disco em bloco de 4K, 8K, 16K, 32K, 64K; muitos discos oferecem velocidades realmente ruins com números mais baixos, como 4K, mas oferecem um tempo dez vezes mais rápido quando em 64K, 128K ou superior.

Sim, o uso de tamanhos grandes de cluster pode reduzir o desperdício de espaço no cluster de cada arquivo (se você usar milhões de arquivos com apenas 1 byte cada), use melhor um sistema compacto / em tempo real sobre o sistema de arquivos, como uma amostra, um disco de 4TiB com um tamanho de cluster 4K pode ter apenas menos de 4TiB / 4K = 1073741824 arquivos de 1Byte cada, isto é apenas 1GiB se todos os arquivos tiverem tamanho de 1Byte (tamanho de cluster 4K), maior proporção de tamanho de cluster pior, mas se os arquivos são enormes, como máquinas virtuais (perto de 32GiB como uma amostra ou apenas alguns megabytes), a perda é apenas no último cluster; Para arquivos grandes, o tamanho de um cluster grande é muito melhor para o desempenho, mas tenha cuidado com o uso da máquina virtual.

Ninguém lhe dirá esse segredo: dentro do convidado, não use o tamanho do cluster 4K, use o mesmo tamanho do cluster onde o disco virtual reside ou um múltiplo dele.

Sim, sou maníaco por obter o máximo de velocidade dentro dos discos convidados, como disse com 6 discos rotativos, chego perto de 1,7 GiB / s, a velocidade do barramento SATA III é o gargalo, não os discos em si. Uso discos de ponta (não baratos), cache de 128MiB com velocidade de gravação de 283MiB / s cada.

Para você e para todas as pessoas: É muito melhor aprender como o tamanho do cluster, o tamanho da faixa e o tamanho do bloco devem estar relacionados antes de qualquer teste de velocidade, caso contrário, testar o LVM2 ou qualquer outro RAID (também ZFS) pode dar conclusões FALSE.

Apenas uma amostra para isso: eu testo meus tempos de inicialização do linux com discos Sata 2x60MiB / s de 2,5 polegadas e 5400rpm em uma placa mãe de portas Sata II e testo com 2xSSD Sata III (eles podem gravar mais de 250MiB / s se estiverem conectados ao Sata III portas), os tempos de inicialização levam apenas dois segundos a menos, apenas dois segundos em uma inicialização de cinco minutos, por que? Como a maioria dos discos de tempo de inicialização não está sendo usada, ela está executando coisas no RAM e na CPU, mas não na E / S.

Sempre teste o que você fará no dia real, não apenas as velocidades brutas (em outras palavras, velocidade máxima).

A velocidade máxima é boa para saber que o bit não é representável; você pode não estar usando os discos na velocidade máxima 100% do tempo; os SOs e os APPs devem fazer coisas no RAM e na CPU sem E / S; portanto, nesse momento, a velocidade do disco não importa em tudo.

Todas as pessoas dizem que o SSD melhora muito a velocidade de inicialização do Windows. Nos meus testes, que também é FALSO, isso prova apenas 28 segundos em um tempo de inicialização de quase oito minutos.

Portanto, se você gosta de mim: Linux copiar para ram na inicialização, o SSD não será melhor do que discos rígidos rotativos, eu também testei o USB 3.1 Gen2 stick (139MiB / s lido), o tempo de inicialização é afetado apenas alguns segundos em um inicialização de cinco minutos, por quê? fácil, a leitura é feita ao copiar para o ram, depois que o disco / ssd / usb-stick não é usado novamente no restante do parafuso, os dados estão no ram, como um drive de ram.

Agora, estou vendendo todo o meu SSD que tenho, eles não melhoram o Linux no boot-on, mas os benchmarking dizem que são 5 vezes mais rápidos ... veja, o benchmark dá FALSE conclusões ... teste, teste e teste real dia de trabalho.

Espero que isso possa esclarecer as coisas masculinas ... O LVM com tamanhos de cluster e de faixas ruins afeta muito mais do que a sobrecarga da camada.