Recentemente me deparei com uma recomendação da Microsoft sobre a configuração do Logical Volume Management (LVM) em ambientes de nuvem, e achei isso um tanto intrigante. A recomendação afirma que, embora seja possível configurar o LVM em qualquer disco conectado a uma máquina virtual (VM), a maioria das imagens em nuvem não terá o LVM configurado no disco do sistema operacional por padrão. O raciocínio fornecido é evitar problemas com grupos de volumes duplicados se o disco do sistema operacional for anexado a outra VM da mesma distribuição e tipo, especialmente durante cenários de recuperação. Conseqüentemente, a recomendação sugere o uso do LVM apenas em discos de dados.
No entanto, estou lutando para entender a praticidade de anexar o disco do sistema operacional a outra VM, especialmente considerando que as tarefas de solução de problemas e diagnóstico podem ser facilmente executadas em instâncias de VM separadas. No caso de recuperação de dados, criar uma nova VM sem partições LVM e montar o volume LVM parece uma solução simples.
Além disso, o argumento para usar partições padrão sobre LVM devido à sua rigidez não parece convincente. O LVM oferece flexibilidade no gerenciamento do espaço em disco, permitindo uma expansão mais fácil dos volumes em comparação com partições padrão, o que pode ser particularmente benéfico se o volume estiver entre outras partições.
Estou curioso para saber se alguém pode fornecer informações sobre cenários em que seria necessário ou vantajoso anexar o disco do sistema operacional a outra VM em um ambiente de nuvem. Na minha experiência, separar discos de sistema e de dados e anexar discos de dados a novas VMs tem sido uma abordagem mais prática.
Eu apreciaria quaisquer insights ou experiências que outras pessoas possam ter sobre este tópico.
DR: LVM é redundante em uma VM.
Isso realmente parece um raciocínio de culto à carga. Tive alguns casos em que movemos um disco virtual de uma VM para outra, mas sempre foi um disco de dados; por exemplo, esse foi o nosso caminho de atualização: preparamos a nova versão de uma VM com um disco de dados fictício e, quando estava pronto, apenas conectamos o disco de dados real da VM mais antiga.
Mal me lembro de ter uma VM tão estragada que não inicializava. De qualquer forma, nesses casos, a recuperação a partir de um backup ou o reprovisionamento completo da VM certamente será mais apropriado do que montar um disco do sistema em outra VM para consertar algo.
Quando você está executando em uma VM, você já possui algum gerenciamento de volume, externo à VM. Os discos apresentados a ele já são virtuais e muito flexíveis; você não precisa desperdiçar recursos para oferecer suporte a instalações adicionais e redundantes. (Não apenas uma camada de tradução em tempo de execução é um desperdício, mas a necessidade de monitorá-la e gerenciá-la em uma VM também consome recursos.)
Considere isso uma continuação da idéia de que você não constrói, por exemplo, RAID de software e multipath dentro da VM, mas no host; agora, você não cria gerenciamento de volume uniforme na VM, mas no host.
Conseqüentemente, o estilo de uso do disco para VMs tende a ser diferente do estilo de uso de servidores bare metal. Em vez de adicionar um ou mais discos grandes e particioná-los na VM, adicione cada volume potencial como um disco individual contendo no máximo uma partição. Quando precisar ampliar o espaço, você aumenta o disco virtual no ambiente de virtualização e, em seguida, aumenta uma partição e FS em uma VM. Este é agora o seu LVM.
Na maioria dos casos, você precisará de um FS raiz e um FS de dados, por exemplo, dois discos virtuais, e é provável que o disco FS raiz de aproximadamente 30 GB nunca precise ser redimensionado. Os bancos de dados geralmente sugerem o uso de armazenamento separado para logs de gravação antecipada; isso exigirá a adição de um disco virtual dedicado de qualquer maneira, para colocá-lo em armazenamento separado no ambiente de virtualização.
Houve algumas ocasiões em que usei mais de quatro discos virtuais, mas todos esses casos foram degenerados, resultantes de um péssimo planejamento de alguém, e eventualmente esses sistemas foram refatorados com menos discos.
Não estou familiarizado especificamente com os processos no Azure, mas com o qemu e no AWS, o processo de redimensionar um volume é muito mais simples do que configurar um PV/LV.
Porque o /boot está bagunçado? Ou o modo de usuário único é protegido por senha e você não tem a senha.
Se você criar duas VMs a partir da mesma imagem base, e essa imagem base estiver usando LVM, e então anexar um disco coberto por essa imagem base de uma para a outra:
O mesmo problema também pode acontecer com sistemas regulares, mas é muito menos comum, a menos que você faça algo como clonar sistemas regularmente.
Também pode ser um problema no nível do sistema de arquivos (UUIDs duplicados para sistemas de arquivos podem fazer coisas desagradáveis), mas isso geralmente é apenas um problema no momento da inicialização, a menos que você esteja usando BTRFS, e é fácil de contornar na maioria dos casos porque você pode opte por identificar os sistemas de arquivos por rótulo ou dispositivo.
Com que frequência você realmente precisou redimensionar uma partição? A norma para uma VM não é dezenas de partições em um disco gigante, é de uma a três no disco do sistema (volume de inicialização do firmware, se necessário, opcional
/boot
e a partição raiz) e quaisquer volumes de dados são discos separados e dedicados .Como a norma para tudo, exceto o disco do sistema, é uma partição por disco, o LVM tem pouco ou nenhum valor em qualquer lugar além do disco do sistema (porque para redimensionar essas partições, você precisa redimensionar o próprio disco , o que geralmente é fácil nas configurações da VM) . E para o disco do sistema, é bastante raro que você precise redimensionar qualquer uma das partições (o volume de inicialização do firmware geralmente tem tamanho fixo,
/boot
talvez seja 1G no máximo na maioria dos casos, e a partição raiz será o restante do disco), então há pouco valor aí.Resposta curta: quando se trata de armazenamento, quanto mais simples, melhor. As recomendações da Microsoft devem ser lidas tendo isso em mente, especialmente considerando que se dirigem a um público amplo.
Resposta longa: embora usar partição simples seja mais simples, deve-se pensar cuidadosamente no layout da partição. A partição raiz deve ser a última, pois ter outras partições depois significa que o espaço em disco adicionado não será imediatamente utilizável pelo sistema de arquivos raiz. Por exemplo, expandir um disco com uma partição swap no final significa que qualquer espaço adicionado será contíguo ao swap, não ao sistema de arquivos raiz. Para expandir este último, você deve remover ou realocar a partição swap.
Por esse motivo, e para manter as coisas simples, geralmente não uso o LVM quando consigo usar uma única partição/sistema de arquivos para o disco raiz (com a possível exceção de uma partição de inicialização dedicada), mas uso o LVM para operações mais complexas. configurar.
Observe que, para discos de dados , o LVM tem algumas vantagens importantes, como provisionamento dinâmico, cache, instantâneos, desduplicação, etc. Embora alguns também sejam fornecidos pela plataforma de hipervisor/nuvem, o LVM continua sendo uma ferramenta muito útil para gerenciamento de volume de dados.
A configuração simples de partições é a configuração padrão do Ubuntu (e outras distros baseadas em Debian), que eu acho que é a principal motivação por trás da afirmação acima. O Ubuntu também usa um arquivo swap (em vez de uma partição swap) por padrão. Observe que as distros baseadas em RHEL usam LVM (e um volume de troca dedicado) por padrão.
Embora seja verdade, isso dificilmente é um problema intransponível: pode-se identificar/ativar qualquer PV/VG por seu UUID e renomeá-lo conforme necessário, ou simplesmente usar uma máquina de partição simples para montar e diagnosticar o sistema de arquivos raiz problemático. Ainda assim, isso significa complexidade adicional durante a recuperação.