Bonjour,
 
J'ai des VMs (6 pour le moment) avec 6 ou 7 Go de ram sous 2008 R2 et je cherche des infos sur la configuration à adopter pour le fichier Pagefiles.sys
 
Pour le moment tout est par défaut, c'est à dire que c'est Windows qui gère la taille et le fichier se trouve sur le C:\.  
Le C:\ et le D:\ sont sur le même VMFS, le E:\ est sur un autre VMFS. Chaque VM à un VMFS propre mais tous les E:\ sont sur le même VMFS. Tout ça se trouve sur le même SAN.
 
D'après mes recherches certain préconise 1.5x la ram, d'autre 2x, certain dise que le swap ne sert plus à rien avec autant de ram, Microsoft ne semble pas trop se mouiller, certain pense qu'il faut mieux le laisser sur le C:\, d'autres sur un autre disque.
 
Tout ça pour dire que je suis un peu perdu.
 
J'aurais tendance à fixer la taille à 1.5x la ram, mais j'hésite sur son emplacement.  
Est ce que je le met sur le D:\, le E:\ ou encore un VMFS dédié?  
Si je le met sur un VMFS dédié, est ce que je créé un grand S:\ avec tous les Pagefile.sys ou un S:\ par VM?
 
Merci d'avance pour vos réponses.

Par chez moi on a tendance à créer un datastore dédié aux pagefile.sys.

En effet, regrouper les pagefile.sys a sur un même datastore a un avantage assez intéressant lorsque tu as deux storages qui sont répliqués.
 
Ainsi pas besoin de répliquer la swap des machines entre tes SAN/NAS
 
Maintenant c'est un peu plus lourd à gérer

1) Tu laisses le pagefile.sys sur C:
2) La taille de pagefile.sys dépend de l'utilisation de ta VM, et si tu as besoin ou non de dump kernel en cas de crash.

Effectivement j'avais oublié la réplication avec le PRA.
 
C'est la première fois que je fais un PRA mais j'imagine qu'il faut quand même répliquer le datastore des pagefile.sys une fois sinon, au redémarrage des VMs sur le PRA, windows va chercher le pagefile.sys sur un lecteur sur un datastore qui n'existe pas. Windows essaiera peut être de le mettre à l'emplacement par défaut mais il n'y aura peut être pas assez de place sur le C:\.
Comme le pagefile.sys aura une taille fixe, ça ne servira a rien de le répliquer régulièrement, ça fait toujours plusieurs dizaine de Go de moins à répliquer.

@nebulios
 
Je n'ai jamais laissé le pagefile.sys sur le C:\, pourquoi faut-il le laissé dessus?

Parce qu'il n'y a aucune raison de le déplacer, et qu'en le déplaçant tu perds certaines fonctionnalités au niveau des dumps (de mémoire).

Aucune raison? Gain de place sur le C:\, gain de temps sur la réplication et gain de perf si on a un simple disque.
 
J'avoue ne pas voir d'autre fonctionnalités au pagefile.sys que d'étendre la ram quand elle est pleine et c'est peut être là mon problème. Tu pourrais donner un peu plus de détails stp?

Gain de place sur le C: -> non si les partitions sont correctement dimensionnées
Gain de temps de réplication -> réplication de quoi ?
Gain de perf sur simple disque -> non, ça peut être même le contraire
 
Le pagefile.sys n'a pas pour but d'étendre la RAM sous Windows, il est utilisé en permanence par l'OS pour stocker les informations les moins utilisées (entre autres).
Si tu veux le détail du fonctionnement jette un coup d'oeil au blog de Mark Russinovich

Gain de place sur le C: > Correctement dimensionnées ou pas, 8go sur une partition système ça fait toujours 8go.
Gain de temps de réplication > il semblerait que sebastien4012 possèdent deux baies en réplication. De fait poser ses pagefile.sys sur un datastore séparé permet de ne pas les inclure dans SRM. Le tout étant que de l'autre côté du miroir un datastore présentant les mêmes caractéristiques existe.
Gain de perf sur simple disque : je me perds un peu là... Mais dans la mesure où ce datastore dédié n'est pas répliqué, les écritures y gagnent forcément.

Si tu choisis de ne pas respecter les précos MS en terme de dimensionnement ça devient ton problème (et j'ai déjà listé l'impact de déplacer le pagefile.sys)
Pour coller tous les pagefile.sys sur un datastore, ça me parait mettre tous ces oeufs dans un même panier donc pas une solution idéale (sauf si la récupération d'un datastore se fait de manière instantanée)
Gain de perf sur simple disque : on parle de quoi exactement ? Je pensais qu'on parlais d'un disque physique unique ici.

Pour le gain de perf sur simple disque, je parlais surtout pour un simple pc pas pour un SAN. D'ailleurs en me relisant je me rend compte que je me suis embrouillé. Je pensais simple disque comparé à des systèmes RAID.
Ce que je voulais dire c'est que déplacer le pagefile.sys sur un 2e disque permet d'avoir moins d'accès disque sur le C:\ donc un gain de perf. Je ne sais pas si on peut partir du même principe avec un SAN puisque de toute façon ça écrit sur tous les disques physiques alors que vu de Windows c'est un disque différent.
 
Pour la réplication, j'ai en effet 2 SAN sur 2 sites dans des villes différentes relié par une fibre 6M. La réplication ne passe pas dans la nuit. Je cherche donc un moyen de la réduire et le déplacement des pagefile.sys sur un autre datastore non répliqué serait une solution. Je ferais une unique réplication pour que les fichiers existent sur les 2 sites. Je suis donc à la recherche d'avis sur cette modif.

J'ai été faire un tour sur le blog de Mark Russinovich et j'ai trouvé le lien suivant dans les commentaires d'un article.
http://support.microsoft.com/?id=969028
 
Ils expliquent qu'on peut mettre le fichier de vidage mémoire sur un autre disque que le disque système et qu'on peut créer un autre fichier qu'utiliser le pagefile.sys.

Si tu déplaces le pagefile.sys sur un disque moins performant tu auras moins d'écriture mais aussi moins de perf par exemple.
De plus les accès au pagefile.sys sont normalement restreints si la RAM de ta VM est correctement dimensionnée.
 
Edit : effectivement l'article mentionne la possibilité de déplacer du pagefile.sys tout en permettant la création de memory dump, mais attention cela peut aller à l'encontre des recommendations de certaines applications.
 
Si tu manques vraiment de place, commence par réduire la taille du pagefile.sys en vérifiant bien de ne pas pourrir les performances de ta VM. Il faudra faire du cas par cas à ce niveau, pour chaque VM.

Dans les formations, il était conseillé de mettre les pagefilles sur d'autre disque que le C: (cela un impact important sur le windows client aprés plusieurs années de prod), (disque tout fragmenter, tout ça, tout ça) ...  
 
Avec un pagefile variable qui change tout le temps sur une partition D: le C reste toujours carré...
 
Sur les VM (serveur) sur VMFS, j'applique la méthode de néojack qui à mes yeux est la bonne d'abord parce-que ESX creer aussi un fichier swap que je ne réplique pas sur le SAN et j'en profite aussi pour creer lorsque j'ai un peu de temps le pagefile sur un disque nom répliqué sur le même volume que celui des swap esx.  
 
Il est préférable de créer un volume SAN que pour ce type de fichier.
Pas de réplication, pas de snapshot.
Un disque virtuel rien que pour le pagefile en VMFS dynamique.
Et voila.
 
Au sujet de la taille, privilégié taille fixe 2x fois la ram; si tu as de l'espace disque ... tu t'en moque ... l’intérêt de la taille fixe m'avait-ton expliqué en formation (pfffffouuuuu, c'est loin) était de ne pas avoir de fichier pagefile trop fragmenté ...
Voilà.  

Concernant le déplacement du pagefile sur un autre disque, je suis plutôt également partisan à faire ça habituellement.
Mais pour un datastore dédié, je trouve ça un peu "effrayant"...
Par contre la taille, également mettre du fixe OUI et avec une taille de "ca dépend l'utilisation de la RAM"
En fait faut faire un petit peu d'analyse de comment le serveur tourne pour faire du spécifique car je pars du principal qu'il est préférable de tout controler... sinon si t'as pas envie de t'embeter...
 
Pour le monitorer, ya le perfom.msc qui peut t'aider

Je vais laisser ça comme ça pour le moment et jeter un œil sur l'utilisation réelle du pagefile.sys avec perfmon, ça m'évitera de mettre bêtement la même conf sur toutes les VMs.
 
En quoi est-ce effrayant d'avoir un datastore dédié?
 
Merci en tout cas pour toutes vos réponses.

Tu mets tous tes oeufs dans un même panier. Si ton datastore devient inaccessible pour une raison ou une autre cela va impacter toutes les VM.

Par exemple. Bonne remarque de Nebulios. L'autre truc qui me chiffone c'est que si c'est des VMs, il faut donc que ca soit stocké sur une autre baie SAN que les systèmes sinon un datastore sur la même baie pour le pagefile et l'OS, je vois pas l'intêret (à moins que je dise de grosse conneries, ça m'arrive héhé)

grosses conneries... à voir...
L'intérêt comme expliqué plus de séparer OS et pagefile dans un contexte de baies SAN en réplication est de ne pas avoir à répliquer le datastore des pagefile. Ce qui veut dire moins d'impact sur les disques mais aussi sur les liens de réplications.

Je n'ai qu'un SAN sur chaque site, mais la réplication se fait au niveau des datastores et non du SAN complet donc si je met le pagefile.sys sur un autre datastore je peux choisir de ne pas le répliquer mais il sera sur le même SAN que le système.

J'ignore que les ESX géraient la réplication de leurs datastores via le lan.

C'est géré par les baies EqualLogic, je ne sais pas pour les autres marques.

Donc tes baies Equalogic sont en réplication...
Ensuite, libre à toi de répliquer un ou plusieurs volumes, ou aucun.