Meilleures pratiques pour les serveurs Linux à allocation dynamique (sur VMware)


9

J'ai une configuration d'environ 20 machines Linux, chacune avec environ 30 à 150 gigaoctets de données client. La taille des données augmentera probablement beaucoup plus rapidement sur certaines machines que sur d'autres. Ce sont des machines virtuelles sur un cluster VMware vSphere. Les images de disque sont stockées sur un système SAN.

J'essaie de trouver une solution qui utiliserait l'espace disque avec parcimonie, tout en permettant une croissance facile des machines individuelles.

En théorie, je créerais simplement de gros disques pour chaque machine et utiliserais l'allocation dynamique. Chaque disque se développerait selon les besoins. Cependant, il semble qu'un système de fichiers ext3 de 500 Go avec seulement 50 Go de données et un nombre assez faible d'écritures augmente facilement l'image disque, par exemple. 250 Go au fil du temps. Ou peut-être que je fais quelque chose de mal ici? (J'ai été surpris du peu que j'ai trouvé sur le sujet avec Google. BTW, il n'y a même pas de balise de provisionnement fin sur serverfault.com.)

Actuellement, je prévois de créer de gros disques à allocation dynamique - mais avec un petit volume LVM dessus. Par exemple: un volume de 100 Go sur un disque de 500 Go. De cette façon, je pouvais plus facilement augmenter le volume LVM et la taille du système de fichiers selon les besoins, même en ligne.

Maintenant pour la vraie question:

Y a-t-il de meilleures façons de procéder? (c'est-à-dire, pour augmenter la taille des données au besoin sans temps d'arrêt.)

Les solutions possibles incluent:

  • Utiliser un système de fichiers convivial à allocation dynamique qui essaie d'occuper les mêmes endroits encore et encore, n'augmentant ainsi pas la taille de l'image.

  • Trouver une méthode simple pour récupérer de l'espace libre sur la partition (re-thinning?)

  • Autre chose?

Une question bonus: si j'adopte mon plan actuel, recommanderiez-vous de créer des partitions sur les disques ( pvcreate /dev/sdX1vs pvcreate /dev/sdX)? Je pense que c'est contre les conventions d'utiliser des disques bruts sans partitions, mais cela faciliterait un peu la croissance des disques, si cela était nécessaire. Ce n'est qu'une question de goût, non?

Réponses:


7

Si je comprends bien l'allocation dynamique, cela pourrait vraiment causer des problèmes si vous ne surveillez pas de près la croissance de vos systèmes de fichiers VMFS et ne permettez pas à vos VMDK de remplir vos volumes VMFS. Vous avez vu au cours de vos tests que les disques à allocation dynamique ont tendance à se développer pour remplir rapidement leur espace disponible et qu'ils ne peuvent pas récupérer de l'espace qui peut être libre à l'intérieur du système d'exploitation.

L'autre option consiste à créer des fichiers VMDK de taille suffisante pour gérer votre utilisation actuelle et les pics de croissance attendus et ajouter simplement plus de fichiers VMDK à mesure que l'utilisation des données de votre application augmente. De nouveaux fichiers VMDK peuvent être ajoutés en direct à une machine virtuelle, il vous suffit de ré-analyser (echo "- - -"> / sys / class / scsi_host / host? / Scan). Vous pouvez partitionner le nouveau disque, l'ajouter à votre LVM et étendre le système de fichiers en direct. De cette façon, vous êtes toujours conscient de la quantité d'espace alloué à chacune des machines virtuelles et vous ne pouvez pas accidentellement exécuter votre VMFS hors de l'espace à partir d'un invité.

En ce qui concerne la partition ou non si le disque ne sera utilisé que par LVM, je partitionne toujours. Le partitionnement du disque empêche tout avertissement concernant les tables de partition bidon de s'afficher lorsque la machine démarre et indique clairement que le disque est alloué. C'est un peu vaudou, mais je m'assure également de démarrer la partition à 64 pour vous assurer que la partition et le système de fichiers sont alignés en bloc avec le stockage sous-jacent. Il est difficile de détecter et de catégoriser car vous n'avez généralement pas quelque chose à comparer facilement, mais si le système de fichiers du système d'exploitation n'est pas aligné correctement avec le stockage sous-jacent, vous pouvez vous retrouver avec des IOPS supplémentaires nécessaires pour répondre aux demandes qui franchissent les limites de bloc sur le stockage sous-jacent.


1
Merci pour l'idée d'ajouter de nouveaux fichiers vmdk (au lieu de simplement augmenter les fichiers existants).
tuomassalo

3

La meilleure suggestion à laquelle je peux penser est de créer une configuration LVM avec des volumes physiques, des groupes de volumes et des volumes logiques, puis de monter ces volumes logiques en tant que système de fichiers de votre machine virtuelle via iSCSI .

Cela vous permettra de redimensionner le volume logique, puis tout ce que vous aurez à faire après cela est de redémarrer votre démon iscsi et votre logiciel de machine virtuelle et de vérifier qu'il a les nouveaux paramètres de taille, puis de redimensionner le système de fichiers de l'invité pour qu'il corresponde.

Le partitionnement fonctionnerait comme avec un disque dur standard, comme c'est la façon dont le LV apparaîtrait à l'invité de la machine virtuelle.

Edit: peu importe cela, j'ai eu la fausse impression que vous exécutiez vmware sous linux, pas linux sous vmware.



1

Autre suggestion: configurer un serveur de fichiers qui contiendra toutes vos données utilisateur.

Ce serveur de fichiers doit bien sûr être géré avec LVM pour vos besoins de gestion de capacité en ligne.

Si vous le souhaitez, vous pouvez créer une configuration ha (drbd + heartbeat) avec une copie de votre serveur de fichiers dans le SAN et une deuxième copie à l'extérieur ou similaire. (pour les paranoïdes)

Étant donné que vos clients sont basés sur Linux, vous pouvez utiliser NFS qui serait plus rapide que Samba. Un FileServer vous permettra une stratégie de sauvegarde centralisée ainsi qu'une surveillance centralisée de l'utilisation du stockage. Et en termes de votre question de provisionnement léger:

Créez votre configuration LVM comme vous le souhaitiez (dans votre exemple, un LV de 100 Go sur un PV de 500 Go, modifiez simplement les nombres correspondant à la somme de stockage dont vos machines virtuelles ont besoin). Développez ce LV si nécessaire, comme vous l'avez prévu de faire dans chaque machine virtuelle séparément. Mais faites-le UNE FOIS sur votre serveur de fichiers. Chaque fois qu'une machine virtuelle réduit son utilisation du stockage, cet espace deviendra disponible pour toutes vos machines virtuelles ;-)

Utilisez des quotas sur votre serveur de fichiers si nécessaire ou souhaité pour empêcher une seule machine virtuelle de remplir votre serveur de fichiers.


1

Pouvez-vous étendre un volume sans arrêter la machine virtuelle qui l'utilise? Je fais souvent cela, mais je ne sais pas à quoi ressemble votre configuration de stockage ou comment VMware pourrait compliquer les choses. Si vous le pouvez, je ferais ceci

1) Ne pas éclaircir la disposition. Faites de chaque volume la taille dont vous pensez avoir besoin. 2) N'utilisez pas de partitions. Faites de chaque système de fichiers son propre volume. 3) Surveillez la croissance du système de fichiers afin de pouvoir redimensionner les volumes de manière proactive.

Quand vient le temps d'augmenter un volume

1) Sur votre SAN ou dans VMware, faites tout ce dont vous avez besoin pour augmenter le volume. 2) Sous Linux, exécutez echo 1 > /sys/block/EXAMPLE/device/rescan, où EXEMPLE est le nom des périphériques sous / sys / block /. 3) Sous Linux, exécutez resize2fs /dev/EXAMPLE, où EXAMPLE est le nom du périphérique sous / dev.

Cette approche fonctionne bien pour moi. J'ai pris en compte votre approche avec l'allocation dynamique et LVM, et je pense que cela fonctionnerait également.

Si vous décidez de suivre la route LVM, je vous recommande de ne pas partitionner les disques. Comme vous l'avez dit, l'absence de table de partition facilite la croissance du disque virtuel. Sans table de partition, vous pouvez simplement exécuter pvresize et Linux reconnaîtra que le volume physique a augmenté. Avec une table de partition, vous devez démonter tout système de fichiers, supprimer la table de partition, recréer la table de partition, puis exécuter pvresize. C'est beaucoup plus de travail et cela nécessite des temps d'arrêt.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.