Práticas recomendadas para servidores Linux de aprovisionamento dinâmico (no VMware)

Question

Eu tenho uma configuração de cerca de 20 máquinas Linux, cada uma com cerca de 30-150 gigabytes de dados do cliente. Provavelmente, o tamanho dos dados crescerá significativamente mais rápido em algumas máquinas do que em outras. Estas são máquinas virtuais em um cluster do VMware vSphere. As imagens do disco são armazenadas em um sistema SAN.

Estou tentando encontrar uma solução que use pouco espaço em disco, permitindo o crescimento fácil de máquinas individuais.

Em teoria, eu criaria discos grandes para cada máquina e usaria o provisionamento thin. Cada disco cresceria conforme necessário. No entanto, parece que um sistema de arquivos ext3 de 500 GB com apenas 50 GB de dados e um número bastante baixo de gravações ainda aumenta facilmente a imagem do disco para, por exemplo. 250 GB ao longo do tempo. Ou talvez eu esteja fazendo algo errado aqui? (Fiquei surpreso com o quão pouco eu encontrei sobre o assunto com o Google. BTW, não há ainda nenhuma tag de thin-provisioning no serverfault.com).

Atualmente, estou planejando criar discos grandes e com provisionamento thin, mas com um pequeno volume LVM neles. Por exemplo: um volume de 100 GB em um disco de 500 GB. Dessa forma, eu poderia mais facilmente aumentar o volume do LVM e o tamanho do sistema de arquivos conforme necessário, mesmo online.

Agora, para a pergunta atual:

Existem maneiras melhores de fazer isso? (isto é, aumentar o tamanho dos dados conforme necessário, sem tempo de inatividade).

Possíveis soluções incluem:

• Usando um sistema de arquivos amigável de thin provisioning que tenta ocupar os mesmos pontos repetidamente, não aumentando o tamanho da imagem.

• Encontrando um método fácil de recuperar espaço livre na partição (refino?)

• Outra coisa?

Uma pergunta bônus: se eu for com meu plano atual, você recomendaria criar partições nos discos ( pvcreate /dev/sdX1 vs pvcreate /dev/sdX )? Eu acho que é contra convenções usar discos brutos sem partições, mas seria um pouco mais fácil aumentar os discos, se isso for necessário. Isso tudo é apenas uma questão de gosto, certo?

    

Answer 1

Se eu entendi o provisionamento thin corretamente, isso pode realmente causar problemas se você não estiver monitorando de perto o crescimento do seu sistema de arquivos VMFS e permitir que seus VMDKs preencham seus volumes VMFS. Você viu em seu teste que os discos thin provisioned tendem a crescer para preencher rapidamente seu espaço disponível e não podem recuperar espaço que pode estar livre dentro do sistema operacional.

A outra opção é criar arquivos VMDK com tamanho suficiente para lidar com seu uso atual e esperados picos de crescimento e apenas adicionar mais arquivos VMDK à medida que o uso de dados do aplicativo aumenta. Novos arquivos VMDK podem ser adicionados ao vivo para uma VM, você só precisa verificar novamente (echo "- - -" > / sys / class / scsi_host / host? / Scan). Você pode particionar o novo disco, adicioná-lo ao seu LVM e estender o sistema de arquivos ao vivo. Dessa forma, você está sempre ciente de quanto espaço está alocado para cada uma das VMs e não é possível executar acidentalmente o VMFS sem espaço de dentro de um convidado.

No que diz respeito a particionar ou não se o disco só vai ser usado pelo LVM, eu participo sempre. O particionamento do disco impede que quaisquer avisos sobre tabelas de partições falsas apareçam quando a máquina inicializa e deixa claro que o disco está alocado. É um pouco de vodu, mas eu também me certifico de iniciar a partição em 64 para ajudar a garantir que a partição e o sistema de arquivos estejam alinhados com o armazenamento subjacente. É difícil de detectar e categorizar, pois normalmente você não tem algo para comparar facilmente, mas se o sistema de arquivos do OS não estiver alinhado corretamente com o armazenamento subjacente, você pode acabar com IOPS extras necessários para atender as solicitações que cruzam limites de blocos. armazenamento subjacente.

    

Answer 2

A melhor sugestão que posso imaginar é criar uma configuração do LVM com volumes físicos, grupos de volumes e volumes lógicos, depois montar esses volumes lógicos como o sistema de arquivos da sua máquina virtual via iSCSI .

Isso permitirá redimensionar o volume lógico e, em seguida, tudo o que você precisará fazer depois disso é reiniciar o daemon do iscsi e o software da máquina virtual e verificar se possui os novos parâmetros de tamanho e redimensionar o sistema de arquivos do convidado para corresponder.

O particionamento funcionaria como em um disco rígido padrão, pois é como o LV apareceria para a máquina virtual guest.

Edit: não importa, eu tenho a falsa impressão de que você estava rodando o vmware no Linux, não o Linux no VMware.

    

Answer 3

Eu não sei como funciona no VMware, mas o Redhat RHEV-M / RHEV-H é possível e suporta RHEL 4.8 a 5.X e o mesmo tempo para ganhar 2k3 R2 e ganhar 2k8. Para obter mais informações link

    

Answer 4

Sugestão diferente: configure um servidor de arquivos que conterá todos os seus dados de usuário.

Esse servidor de arquivos deve ser gerenciado com o LVM para fins de gerenciamento de capacidade on-line.

Se desejar, você pode criar um ha-setup (drbd + heartbeat) com uma cópia de seu servidor de arquivos na SAN e uma segunda cópia externa ou semelhante. (para os paranóicos)

Como seus clientes são baseados em Linux, você pode usar o NFS, que é dito ser mais rápido que o Samba. Um FileServer permitirá uma estratégia de backup centralizada, bem como um monitoramento de uso de armazenamento centralizado. E em termos de sua questão de provisionamento reduzido:

Crie sua configuração do LVM como você pretendia (no seu exemplo 100gb LV em um PV de 500gb, apenas altere os números correspondentes à soma do armazenamento que suas VMs precisam). Expanda este LV quando necessário, como planejava fazer em cada VM separadamente. Mas apenas faça uma vez no seu servidor de arquivos. Cada vez que uma VM reduz seu uso de armazenamento, esse espaço ficará disponível para todas as suas VMs; -)

Use cotas no seu servidor de arquivos, se necessário ou desejado, para evitar que uma única VM preencha seu servidor de arquivos.

    

Answer 5

Você é capaz de expandir um volume sem desligar a máquina virtual usando-o? Eu geralmente faço isso, mas não sei como é a configuração do seu armazenamento ou como o VMware pode complicar as coisas. Se você puder, o que eu faria é isso

1) Não finja. Faça cada volume do tamanho que você acha que precisa. 2) Não use partições. Faça com que todo sistema de arquivos tenha seu próprio volume. 3) Monitore o crescimento do sistema de arquivos para que você possa redimensionar volumes proativamente.

Quando chega a hora de aumentar um volume

1) Em sua SAN ou em VMware, faça o que for necessário para expandir o volume. 2) No linux, execute echo 1 > /sys/block/EXAMPLE/device/rescan , onde EXAMPLE é o nome do dispositivo em / sys / block /. 3) No linux, execute resize2fs /dev/EXAMPLE , onde EXAMPLE é o nome do dispositivo em / dev.

Essa abordagem está funcionando bem para mim. Eu considerei sua abordagem com thin provisioning e LVM, e acho que funcionaria também.

Se você decidir seguir a rota LVM, recomendo não particionar os discos. Como você disse, não ter uma tabela de partição facilita o crescimento do disco virtual. Sem tabela de partições, você pode simplesmente executar pvresize e o linux reconhecerá que o volume físico cresceu. Com uma tabela de partição, você precisa desmontar qualquer sistema de arquivos, excluir a tabela de partição, recriar a tabela de partição e executar pvresize. Isso é muito mais trabalho e requer tempo de inatividade.