write-cache on dans /etc/tgt/targets.conf ?

[elanclan]

Bonjour,

Dans toutes les documentations de tgt (cible iSCSI sous Linux), je trouve la ligne suivante dans /etc/tgt/targets.conf

<target ....>...write-cache off...</target>

excepté ici

http://samcaldwell.n...se-linux-rhel-6

où on lit simplement

# In the test case for this article, write-cache was turned on. However, there are many other

# cases where turning write-cache off may be appropriate, such as shared storage.

J'ai fait des essais avec Crystal Disk Mark sur l'initiateur (serveur virtuel sous Windows) : j'obtiens une belle amélioration des performances écriture aléatoire en activant cette option (allant de x1.5 à x10 selon la taille de la file).

D'ailleurs, c'est l'option par défaut : en l'absence de directive contraire, tgt active le cache en écriture.

A un autre niveau, le mode "Write Back" du contrôleur RAID matériel est déjà activé. Mais il dispose d'une protection locale par batterie, lui...

• Quel est votre avis sur la question ?
  
• Dois-je activer cette option sur un serveur de fichiers en production ?
  
• Pourquoi peut-il être plus adapté de mettre "write-cache off" pour du stockage partagé ?
  
• Que se passe-t-il en cas de rupture de l'alimentation électrique ? (sachant que cela arrive parfois, et que les serveurs ne savent pas s'éteindre correctement lorsque les onduleurs arrivent en fin de capacité)
  

Merci !

[dudul88]

Disons que ce sont de bonnes questions, voici mon avis (je n'ai jamais utilisé tgt) :

En principe sur un réseau ce n'est pas tellement les disques qui bride la vitesse mais le réseau en lui même. De plus le cache n'est pas sûr puisque qu'en cas de coupure de courant / plantage du système les donnés en cache sont perdues. Voilà à mon avis pourquoi il est conseillé de désactiver le cache en stockage partagé. (Après ce sont des suppositions, je ne suis pas un expert !)

[elanclan]

Concernant le réseau, on a heureusement des latences assez courtes (ping moyen 0,350 ms entre le serveur iSCSI et une machine virtuelle). Le réseau bride surtout la bande passante (Gigabit = 125 Mo/s max) mais en théorie ne rajoute pas trop de latence dans notre cas => pas trop d'impact en lecture/écriture aléatoire ? (là où le cache est le plus efficace...)

En y réfléchissant à tête reposée, la bonne gestion du scénario "panne de courant" me parait être un prérequis indispensable au write-cache niveau serveur.

Je vais donc opter pour plus de sécurité au détriment des performances en aléatoire. Je désactive cette option.

Merci pour la réponse (et pour les lectures)

[seboss666]

Disons que le seul moyen pour éviter la moindre coupure de courant est d'onduler la totalité du "circuit" : poste de travail, serveur, et surtout switchs/routeurs. C'est pas donné, le jeu n'en vaut probablement pas la chandelle.

[elanclan]

Actuellement c'est ondulé, mais les serveurs et switches continuent à fonctionner normalement en cas de panne de courant. Lorsque les batteries sont vides, et si le secteur n'a pas été rétabli à temps, l'alimentation des serveurs et des switches est interrompue brutalement.

Pour bien faire, il faudrait qu'en cas de panne de courant dépassant une certaine durée, les serveurs virtuels s'arrêtent (proprement) en premier, puis les serveurs de cibles iSCSI et les serveurs hôtes, et enfin les switches.

Le projet est assez compliqué car il y a deux circuits d'alimentation différents, et la procédure d'arrêt sécurisé ne doit se lancer que si les deux onduleurs à la fois sont en fin de capacité : une simple liaison onduleurs-serveurs ne suffit pas.