postgresql sous vmware : utilisation des Mapped RAW LUN... ou pas ?

jerome93 · 31/01/2013 16:17:45

Bonjour la Communauté

J'imagine que nombre d’entre vous se sont posé la question :
- est-ce que je mets mes tablespaces sur un disque virtuel géré par la couche vmware (mdk) ?
- ou bien est-ce que je court-circuite cette couche en mappant directement des LUNs de ma baie de stockage ?
Pourtant je n'ai pas trouvé de discussion sur ce thème...

Je vois deux problèmes que la couche vmware pourrait poser :
- non respect des écriture synchrones (fsync = on)
- ralentissement (en particulier lors des écritures synchrones)

Qui a un retour d'expérience sur ce sujet ? quelles sont les bonnes pratiques ?
Merci pour vos avis

Jérôme
DBA

Dernière modification par jerome93 (31/01/2013 16:18:28)

gleu · 31/01/2013 17:22:18

Si vous voulez des performances, ne surtout pas passer par un disque virtuel.

jerome93 · 31/01/2013 19:18:48

Merci, c'est bien ce que je craignais...
La perte de perf serait de quel ordre de grandeur ? 10% ? x2 ? x10 ?

On ne cherche pas forcément à être au top et 20% de perte de perf serait acceptable. Si c'est x2, c'est une autre histoire....

Je ne suis pas expert de vmware mais on me dit que, si on utilise les LUN mappés, on se priverai de certaines fonctionnalités de vmware comme les snapshots ou le déplacement de VM. D'un autre côté il me semble que les snapshot sont aussi pénalisants pour les perf. donc pas indiqué pour un SGBD.

Jérôme

SQLpro · 12/03/2013 23:12:41

jerome93 a écrit :

Merci, c'est bien ce que je craignais...
La perte de perf serait de quel ordre de grandeur ? 10% ? x2 ? x10 ?
On ne cherche pas forcément à être au top et 20% de perte de perf serait acceptable. Si c'est x2, c'est une autre histoire....
Je ne suis pas expert de vmware mais on me dit que, si on utilise les LUN mappés, on se priverai de certaines fonctionnalités de vmware comme les snapshots ou le déplacement de VM. D'un autre côté il me semble que les snapshot sont aussi pénalisants pour les perf. donc pas indiqué pour un SGBD.
Jérôme

Un snapshot de base de données fait par un système virtualisé NE PEUT NE AUCUN CAS garantir la bonne restitution de la base, sauf si la base est "offline". En effet, les écritures entre le journal de transaction et les fichiers de données sont asynchrone. Le snapshot, lui en général est séquentiel. Au final vous vous retrouverez avec une base corrompue.
Seule solution : arrêtez votre base le temps des snapshot des VM ou ne pas utiliser de VM.
De toute façon les VM et les SGBDR c'est franchement pas compatible.

À me lire : SGBDR et virtualisation

A +

gleu · 13/03/2013 00:04:52

Un snapshot de base de données fait par un système virtualisé NE PEUT NE AUCUN CAS garantir la bonne restitution de la base, sauf si la base est "offline".

C'est faux. Il est tout à fait possible de faire un snapshot, que ce soit par une fonctionnalité du SAN, du système de fichiers et, pourquoi pas, de la solution de virtualisation.

De toute façon les VM et les SGBDR c'est franchement pas compatible.

Là par contre, je suis bien d'accord.

SQLpro · 13/03/2013 12:28:49

gleu a écrit :

Un snapshot de base de données fait par un système virtualisé NE PEUT NE AUCUN CAS garantir la bonne restitution de la base, sauf si la base est "offline".
C'est faux. Il est tout à fait possible de faire un snapshot, que ce soit par une fonctionnalité du SAN, du système de fichiers et, pourquoi pas, de la solution de virtualisation.

Le snapshot peut se faire, ce n'est pas pour cela que la base sera en état de produire du fait que les opérations de journalisation et les checkpoints sont asynchrone entre fichiers de données et fichier du JT. Vous avez donc des chances à la restauration du snapshot d'avoir des tables "arrêtées" à la transaction X et le journal arrêté à la transaction Y, et donc au final une base incohérente, du fait de la séquentialité d'enregistrement des fichiers par le mécanisme de snapshot.... D'ailleurs tous les éditeurs de systèmes virtuels déclinent toute responsabilité d'usage pour les SGBDR.... C'est marqué dans les contrat, mais hélas en tout petit. C'est pourquoi des éditeurs comme MS ou Oracle ne garantissent aucunement la virtualisation (sauf pour Oracle sur son propre système virtuel) et demande par exemple de reproduire le bug sur une machine non virtualisé avant toute intervention en garantie....

A +

gleu · 13/03/2013 16:36:38

Le snapshot peut se faire, ce n'est pas pour cela que la base sera en état de produire du fait que les opérations de journalisation et les checkpoints sont asynchrone entre fichiers de données et fichier du JT

Si, grâce aux Copy On Write et au fait que PostgreSQL rejouera ces journaux (après restauration) pour gommer toute incohérence dans les fichiers de données.

SQLpro · 13/03/2013 17:06:44

gleu a écrit :

Le snapshot peut se faire, ce n'est pas pour cela que la base sera en état de produire du fait que les opérations de journalisation et les checkpoints sont asynchrone entre fichiers de données et fichier du JT
Si, grâce aux Copy On Write et au fait que PostgreSQL rejouera ces journaux (après restauration) pour gommer toute incohérence dans les fichiers de données.

Vous pouvez toujours espérer... Dans la plupart des cas, cela marchera. Mais si votre serveur était full-up au moment du snapshot, il y a peu de chance que cela marche....
Rien cependant vous oblige de croire une expérience déjà vécue....

Le seul moyen est de "freezer" la base pendant le snapshot, ce qui revient à interdire toute transaction pendant cette opération. Ce que fait VSS pour WVMWare par exemple....
Ce qui à mon sens est parfaitement imbécile, car VMWare est vendue comme solution de haute dispo, dans le but de basculer une VM d'une machine à l'autre. Et pour faire cette haute dispo, le snapshot réalisé sous VSS rend indisponible la base pour les transactions...

A priori, il y a donc quelque chose qui m'échappe : haute dipso rendant indisponible la base...

A +

Dernière modification par SQLpro (13/03/2013 17:17:17)

#1 31/01/2013 16:17:45

postgresql sous vmware : utilisation des Mapped RAW LUN... ou pas ?

#2 31/01/2013 17:22:18

Re : postgresql sous vmware : utilisation des Mapped RAW LUN... ou pas ?

#3 31/01/2013 19:18:48

Re : postgresql sous vmware : utilisation des Mapped RAW LUN... ou pas ?

#4 12/03/2013 23:12:41

Re : postgresql sous vmware : utilisation des Mapped RAW LUN... ou pas ?

#5 13/03/2013 00:04:52

Re : postgresql sous vmware : utilisation des Mapped RAW LUN... ou pas ?

#6 13/03/2013 12:28:49

Re : postgresql sous vmware : utilisation des Mapped RAW LUN... ou pas ?

#7 13/03/2013 16:36:38

Re : postgresql sous vmware : utilisation des Mapped RAW LUN... ou pas ?

#8 13/03/2013 17:06:44

Re : postgresql sous vmware : utilisation des Mapped RAW LUN... ou pas ?

Pied de page des forums

PostgreSQL.fr

À propos

Nous contacter

Groupes Locaux

Réseaux Sociaux