SGBD et virtualisation

Hello,

Suite à un post intéressant sur la virtualisation et les bases de données (http://www.developpez.net/forums/d91...nvironnements/)...

...je serais curieux de savoir si quelqu'un a déjà implémenté une VM aux petits oignons sur vSphere 4 (Intel-VT, RDM, VMDirectPath, 64 bits et compagnie) et testé un bench OLTP pour voir ce que celà donne.

Je sais que mike a eu l'occasion de travailler sur le sujet récemment, apparemment il y a un intérêt certain à bosser en RDM on s'en doutait un peu, ainsi qu'à correctement aligner les partitions pour les vmdk. Quelqu'un aurait-il eu l'occasion d'activer l'assistance matérielle sur Nehalem par exemple et de voir ce que l'on gagne ?

Quels sont les inconvénients à faire du RDM ? Merci pour le retour...


David B.

Salut David,

Là ou je suis nous avons implémenté du VSPHERE 4.0. Quand tu parles de Intel VT c'est pour utiliser la fonctionnalité : Virtual Machine Device Queues ?

Bref nous avons fait différents benchmarks avec RDM et VMDK.

Nos conclusions :

Pas de grande différence entre les 2 types de fichiers. Des performances un peu plus élevées pour des types d'accès aléatoires sur les fichiers RDM. Pour les accès séquentiels aucune.

Cependant on observe quand même des performances "meilleures" avec les fichiers RDM dans le cas d'une fragmentation physique du fichier. (Cela s'explique facilement par le fait que la gestion d'allocation des blocs via la couche virtualisée est plus difficile).

VMWARE déconseille d'utiliser RDM pour des raisons de gestion mais ici ils n'utilisent que du VMDK donc je n'ai pas de réel retour d'expérience quant à l'utlisation de ce type de fichier. Cependant avec les configurations en cluster (de chez microsoft) c'est obligatoire.

++

VT= virtualization technology. Dans les nouveaux procs type Nehalem ou les AMD-V Pacifica, un cinquième ring peut être activé dans le BIOS, dans lequel un hyperviseur peut s'exécuter.

A l'origine le x86 offre 4 niveaux d'exécution, ou rings. Chaque niveau est parfaitement hermétique avec son voisin: pas le même espace mémoire, pas les mêmes jeux d'instructions. Sans hyperviseur, un OS sur x86 s'exécute dans le niveau de privilège le plus élevé (ring0), et les applications dans le niveau le moins élevé (ring3)

Erreur de stratégie au départ, Windows 16bits devait être aussi compatible avec les procs Alpha et SGI, qui eux n'avaient que 2 rings. Donc Windows a été compilé pour ne déclarer que deux niveaux de privilèges ('USER','KERNEL'). Manque de bol, SGI et Alpha ont cessé d'être produits et supportés, et Windows s'est retrouvé avec 2 niveaux seulement d'implémentés pour ne plus s'exécuter que sur un type de proc qui en offre 4. D'où tous les pb d'écrans bleu ensuite faute aux drivers pourris qui se retrouvent à tourner en kernel mode, au lieu de tourner dans les rings intermédiaires. Bref c'est une autre histoire.

Les premières implémentations de Vmkernel proposaient de la 'full' virtualization. L'hyperviseur s'exécutait en ring0, les guestOS en ring3. Problème majeur, 17 instructions x86 nécessitaient de tourner en ring0, toutes les autres en ring3 *. Donc les 17 instructions devaient être captées et translatées par l'hyperviseur, ce qui génèrait un overhead. Ca a été le fonctionnement de ESX , workstation, Vmserver, etc... jusqu'à l'arrivée de l'assistance matérielle côté constructeurs, où un nouveau ring a été créé juste pour l'hyperviseur. Du coup les guest OS tournent de nouveau en ring0 et plus aucune instruction n'a besoin d'être translatée. On est en CPU-direct.

VMDirectPath, c'est plus pour les périphériques PCI (disques, cartes réseaux).

Merci pour le reste des infos !

David B.

* Il y a une étude de faisabilité faite par deux types de l'US Air Force vers la fin des années 90, mais je n'arrive pas à remettre la main dessus !

J'ai retrouvé le doc (Robin & Irvine - 2000):

http://www.usenix.org/events/sec2000...obin/robin.pdf

A lire absolument !

David B.

L'autre aspect que j'ai évoqué concerne également cette technologie mais appliquéee aux contrôleurs de carte ethernet Gigabit.

Pour les machines virtuelles tournant sous VMWARE c'est l'hyperviseur qui est responsable de la distribution des packets réseaux vers les VM respectives. Cet hyperviseur utilise une certaine quantité de ressources CPU pour effectuer le travail de tri et de routage des paquets. Ceci peut être pénalisant dans le cas où l'ESX hôte possède un certain nombre de VM qui génére un traffic réseau important (ce qui peut être le cas d'un serveur sql) car l'hyperviseur demande plus de cycles de cpu pour les traitements.

VMDq fait partie de cette technologie VT mais pour la partie connectivité. Les VMDq permettent d'améliorer les performances réseaux et de diminuer l'utilisation des ressources CPU dans le cas de la virtualisation.

Le contrôleur ethernet possède une couche supplémentaire de tri et de classification des packets réseaux. Lorsqu'un packet arrive à la carte réseau, celui-ci est placé directement dans une file d'attente assignée à chaque VM. Celles-ci possèdent leur propre file d'attente par conséquent. L'hyperviseur n'a donc plus qu'à prendre les paquets réseaux et de les distribuer aux VM respectives, ce qui allège considérablement son travail. Le processeur peut donc consacrer plus de cyles CPU aux traitements des applications et le débit réseau est également augmenté.

Merci pour le lien ;)

++

Sur les applis que j'ai testé, le RDM n'a pas apporté de meilleurs débits.

Citation:

---

si quelqu'un a déjà implémenté une VM aux petits oignons sur vSphere 4

---

Déjà qu'il a fallu batailler pour avoir des datastores sur des LUN non RAID5 :cry:

Il y a ce doc qui présente un comparatif : http://www.vmware.com/files/pdf/perf...r_vmfs_rdm.pdf

Merci Manu,

Ca confirme ce que vous dites, pas de grosse différence entre VMFS et RDM. Normalement on doit récupérer ici une bonne machine pour faire du Vsphere4, et on pourra lancer quelques tests, ça fera peut être l'objet d'un autre article. J'aimerai bien voir ce que donne l'activation du VT du point de vue CPU, et si ça améliore l'acuité des compteurs perfmon dans les guests aussi... VT ça a l'air très séduisant sur le papier, mais pour la pratique, on manque pas mal de retour.

Merci à tous les deux ! A+ David B.