Linux no VMware - por que usar o particionamento?

Ao instalar VMs Linux em um ambiente virtualizado (ESXi no meu caso), existem razões convincentes para particionar os discos (ao usar ext4), em vez de apenas adicionar discos separados para cada ponto de montagem?

O único que posso ver é que facilita um pouco a ver se há dados presentes em um disco com, por exemplo, o fdisk.

Por outro lado, posso ver algumas boas razões para não usar partições (para outras que não sejam / boot, obviamente).

• Muito mais fácil estender discos. É apenas para aumentar o tamanho do disco da VM (normalmente no VCenter), depois redigitalizar o dispositivo na VM e redimensionar o sistema de arquivos online.
• Não há mais problemas com o alinhamento de partições com os LUNs subjacentes.

Não encontrei muito sobre esse assunto. Perdi algo importante?

Esta é uma pergunta interessante ...

Acho que não há uma resposta definitiva, mas posso fornecer um contexto histórico sobre como as melhores práticas em torno deste tópico podem ter mudado ao longo do tempo.

Eu tive que suportar milhares de VMs Linux implantadas de várias formas nos ambientes VMware desde 2007. Minha abordagem à implantação evoluiu e tive a experiência única ( às vezes infeliz ) de herdar e refatorar sistemas construídos por outros engenheiros.

Os velhos tempos...

Na época (2007), meus primeiros sistemas VMware foram particionados como meus sistemas bare metal. No lado da VMware, eu estava usando arquivos espessos de 2 GB para compor os dados da VM e nem pensei na noção de vários VMDKs, porque fiquei feliz que a virtualização pudesse funcionar!

Infraestrutura virtual ...

No ESX 3.5 e nas primeiras versões do ESX / ESXi 4.x (2009-2011), eu usava o Linux, particionado como normal no topo de arquivos VMDK monolíticos e espessados provisionados. Ter que pré-alocar o armazenamento me forçou a pensar no design do Linux da mesma maneira que faria com o hardware real. Eu estava criando VMDKs de 36 GB, 72 GB e 146 GB para o sistema operacional, particionando os usuais /, / boot, / usr, / var, / tmp e adicionando outro VMDK para a partição "data" ou "growth" (seja / home, / opt ou algo específico do aplicativo). Novamente, o ponto ideal no tamanho do disco rígido físico durante essa era foi de 146 GB e, como a pré-alocação era um requisito (a menos que se usasse o NFS), eu precisava ser conservador quanto ao espaço.

O advento do thin provisioning

A VMware desenvolveu melhores recursos com relação ao provisionamento dinâmico em versões posteriores do ESXi 4.x, e isso mudou a maneira como comecei a instalar novos sistemas. Com o conjunto completo de recursos sendo adicionado em 5.0 / 5.1, um novo tipo de flexibilidade permitiu projetos mais criativos. Lembre-se, isso acompanhava o aumento dos recursos em máquinas virtuais, em termos de quantos vCPUS e quanta RAM poderia ser comprometida em VMs individuais. Mais tipos de servidores e aplicativos podem ser virtualizados do que no passado. Isso é verdade, pois os ambientes de computação começaram a ficar completamente virtuais.

LVM é horrível ...

Quando a funcionalidade de adição a quente completa no nível da VM estava em vigor e era comum (2011-2012), eu trabalhava com uma empresa que se esforçava para manter o tempo de atividade das VMs de seus clientes a qualquer custo ( estúpido ). Portanto, isso inclui aumentos on-line da CPU / RAM do VMware e o redimensionamento arriscado do disco LVM nos VMDKs existentes. A maioria dos sistemas Linux nesse ambiente eram configurações únicas do VMDK com partições ext3 no topo do LVM. Isso foi terrível porque a camada LVM adicionou complexidade e riscos desnecessários às operações. A falta de espaço no / usr, por exemplo, pode resultar em uma cadeia de decisões ruins que eventualmente significam restaurar um sistema a partir de backups ... Isso foi parcialmente relacionado ao processo e à cultura, mas ainda assim ...

Snobbery partição ...

Aproveitei esta oportunidade para tentar mudar isso. Sou um pouco desajeitado em partições no Linux e sinto que os sistemas de arquivos devem ser separados para atender às necessidades operacionais e de monitoramento. Também não gosto do LVM, especialmente do VMware e da capacidade de fazer o que você está perguntando. Então, eu expandi a adição de arquivos VMDK para partições que poderiam crescer potencialmente. / opt, / var, / home pode obter seus próprios arquivos de máquina virtual, se necessário. E esses seriam discos brutos. Às vezes, esse era um método mais fácil de expandir partições subdimensionadas em tempo real.

Obamacare ...

Com a integração de um cliente de alto perfil , fui encarregado do design do modelo de referência da VM do Linux que seria usado para criar seu ambiente de aplicativo extremamente visível. Os requisitos de segurança do aplicativo exigiam um conjunto exclusivo de montagens , então trabalhei com os desenvolvedores para tentar empilhar as partições sem crescimento em um VMDK e adicionar VMDKs separados para cada montagem que tivesse potencial de crescimento ou tivesse requisitos específicos (criptografia, auditoria etc.) Portanto, no final, essas VMs eram compostas por 5 ou mais VMDKs, mas forneciam a melhor flexibilidade para redimensionamento e proteção futuros de dados.

O que eu faço hoje ...

Hoje, meu design geral para Linux e sistemas de arquivos tradicionais é o SO em um VMDK fino (particionado) e VMDKs discretos para qualquer outra coisa. Vou adicionar a quente, conforme necessário. Para sistemas de arquivos avançados como o ZFS, é um VMDK para o sistema operacional e outro VMDK que serve como um zpool do ZFS e pode ser redimensionado, esculpido em sistemas de arquivos ZFS adicionais, etc.

Você está certo de várias maneiras, posso ver o argumento - há um problema que pode ser complicado. Se você usar Pools de Recursos (e eu sei que não, coisas odiosas), as VMs poderão obter mais tempo de IO se tiverem mais discos - em situações extremas de restrição de recursos, uma VM com dois discos poderá obter o dobro de recursos de E / S que um com um único disco. Isso pode não ser um problema para você, mas pensei em apontar isso.

Editar - ah, e isso tornaria o encaixe um pouco mais lento também, mas novamente isso pode não ser um problema.

Quando trabalhei na infraestrutura de uma "grande empresa de software de virtualização" em particular, muitas vezes precisávamos aumentar o tamanho do sistema de arquivos de uma VM. Usamos ext3 / 4 na época.

Aumentar o disco virtual é muito fácil, pegar o novo tamanho do dispositivo em um sistema operacional ativo é relativamente fácil (bisbilhotar em / sys), redimensionar o sistema de arquivos ext3 / 4 ao vivo era fácil, mas o que sempre parecia impossível (executar ao vivo) era redimensionando a partição.

Você tinha que usar gparted ou reescrever / redimensionar a tabela de partição usando o fdisk - mas ela sempre estava bloqueada pelo kernel e exigia uma reinicialização para que o kernel escolhesse o novo layout (o partprobe também não fazia isso).

Mudei muitos sistemas para o LVM e redimensionar os sistemas de arquivos tornou-se uma experiência fácil, quase agradável!

• Aumente a imagem do disco virtual fora da VM
• Na VM,
  • Poke / sys para verificar novamente as métricas do disco (eco "1"> / sys / class / scsi_device // device / rescan)
  • pvresize / dev / sdX (redimensione o volume físico no LVM)
  • lvresize --extents + 100% GRÁTIS / dev / VG / lvolXX (redimensiona o volume lógico no LVM)
  • resize2fs (redimensione o sistema de arquivos)

Tudo isso pode ser feito com segurança em um sistema ativo - e não é necessário reiniciar!

Por que não um disco vazio? Isso me deixa nervoso - ainda não acho que os discos nus sejam amplamente aceitos o suficiente, mas acho que estamos à beira de uma aceitação muito mais ampla. Havia um tópico na lista de discussão btrfs relacionado a isso:

http://www.spinics.net/lists/linux-btrfs/msg24730.html

Mas um disco vazio precisaria apenas da redigitalização e redimensionamento2fs.

Então, em resumo, sim, evite tabelas de partição, se puder.

Enquanto sua pergunta, como está escrita, é sobre o VMWare (ESXi), gostaria de adicionar uma situação em que voltei a usar as tabelas de partição depois de ter a mesma idéia no KVM.

Acontece que, se você tiver volumes LVM como discos para VMs e criar um grupo de volumes LVM dentro da VM sem usar partições (usando todo o disco virtual como PV), esse VG estará visível fora da VM na máquina host. Este não é o caso se você usar partições como PV.

Concedido, é um caso de canto, mas vale a pena considerar se você precisar dessa configuração.

Se é melhor fazer isso ou não, depende do seu sistema.

Existem prós e contras de cada configuração.

No entanto, as principais vantagens de uma única unidade são as seguintes:

1. Simplicidade: uma única unidade possui um único arquivo, que pode ser facilmente distribuído e replicado.
2. Sugestões para o sistema operacional host: um único arquivo será tratado como um único bloco de dados e, portanto, o sistema operacional host saberá que as seqüências de acesso à máquina convidada estarão todas nesse arquivo. Isso pode ser alcançado em algumas configurações de SO host, simplesmente colocando todas as imagens da unidade no mesmo arquivo, mas não será necessariamente o caso.

No entanto, existem vantagens para o multi-drive.

1. Afinidade bare metal / localização manual: com uma única unidade, você está bloqueado para uma única afinidade bare-metal da unidade.
2. Limitações de tamanho: se o seu sistema tiver limites de tamanho da unidade ou de arquivos, você poderá atingi-los em sistemas muito grandes.
3. Volumes somente leitura para segurança: essa é a grande vantagem. Se o volume principal do sistema operacional for somente leitura no lado da VM, ele oferece grandes vantagens de segurança, impedindo essencialmente a capacidade de programas dentro da VM de editar o sistema operacional base do convidado. O uso de uma unidade de dados separada permite criar unidades somente leitura, que podem ser inicializadas como leitura e gravação para manutenção e atualizações sem apenas dados de modelo de sala limpa, impedindo a modificação de diretórios vitais do SO de dentro do servidor.

existe outra opção: montar os dados do aplicativo nos volumes NFS. Você precisa de bons arquivadores (nem todas as implementações do NFS são iguais).

Quando os volumes NFS forem preenchidos, expanda o volume, o cliente linux verá o espaço extra imediatamente.

Seu aplicativo e fornecedor devem suportar os dados no NFS, e você precisa de um design NAS cuidadoso, mas o mesmo acontece com todas as soluções de armazenamento para o seu ambiente virtualizado.

Outro ponto de bônus para essa abordagem é que, se o seu fornecedor de armazenamento tiver tecnologia de clonagem / captura de imagens (como zfs ou Netapp), faça o backup dos dados e crie ambientes de teste / desenvolvimento realmente muito fáceis.

A razão pela qual você ainda precisa particionar o disco para algumas distribuições Linux deve-se ao fato de haver um gerenciador de inicialização e todos os componentes herdados, como o BIOS emulado. Isso dificulta o redimensionamento de um disco e muitos acabariam usando o LVM ou outro absurdo similar.

Pode-se simplesmente criar um sistema de arquivos em todo o volume e montá-lo /, o que funcionará com uma distribuição Linux muito personalizada (ou personalizável / sem opinião). A última vez que tentei isso com o Ubuntu 12.04, o instalador não sabia como lidar com isso, pois precisava instalar sua estúpida tabela de partições e todo o jazz. Esse é um problema das distribuições de uso geral no mundo virtualizado.

Por outro lado, é possível colocar o particionamento em um uso menos tradicional, por exemplo, o ChromeOS e o CoreOS têm duas partições raiz somente leitura para atualizações do sistema.

Um motivo que não foi mencionado até agora é que, em algumas infraestruturas como o Google Compute, o desempenho das E / S do disco aumenta linearmente com o tamanho do disco . Em outras palavras, uma grande unidade particionada terá melhor desempenho de E / S do que várias pequenas unidades.

Observe que esse geralmente não é o caso. Conforme mencionado por Chopper3, na maioria das vezes, várias unidades terão melhor desempenho de E / S. Por fim, se todas as suas unidades virtuais forem mapeadas para uma única unidade física, não haverá diferença.

Na minha experiência, a melhor abordagem é usar o 1 VMDK para OS e geralmente particiono da seguinte maneira:

/dev/sda1 - /boot - 256M
/dev/sda2 - swap  - ~4GB
/dev/sda3 - /     - ~8GB

Descobri que 8 GB são suficientes para /, porque geralmente instalo o mínimo de distribuição Linux (~ 800 MB) + o software necessário. Os logs também vão para essa partição, mas se configurados corretamente (rotação do log por uma semana) e enviados para outro local (syslog / elasticsearch), geralmente não representam um prazer para preencher a partição.

Os dados são adicionados como outro VMDK, e geralmente formato o sistema de arquivos diretamente em disco vazio (por exemplo, / dev / sdb). Isso me permite redimensionar o volume no VmWare e redimensioná-lo diretamente na VM sem necessidade de reparticionar / desmontar / reiniciar.

Eu particiono por dois motivos:

1. Documentação - Certa vez, um administrador da EMC "treinado" roubou LUNs debaixo de mim porque eles não estavam documentados e pareciam não estar alocados e, no meio da noite, foram paginados para um banco de dados Oracle que de repente ficou offline. Ele havia provisionado novamente meus LUNs para outro volume para um aplicativo não relacionado. Desde então, estou paranóico com a documentação.
2. Provisionamento em excesso do meu disco. Com os pratos, mantém os dados fora dos cilindros mais lentos e, com o SSD, prolonga a vida útil / MTBF.