Bonjour,
Frédéric a écrit :
> Bonjour,
>
> On a une machine au boulot qui pilote un instrument et qui doit tourner
> 24h/24. On a donc 2 disques en raid 1 total (4 partitions, y compris le
> swap).
>
> Depuis 2 ans, on change un disque tous les 6 mois (on utilise des petits
> disques de 40Go en pATA, et on n'a pas un grand choix) ; j'ai l'impression
> que ces 'vieux' disques sont fabriqués à la va-vite, et n'ont pas la
> robustesse des disques récents.
>
> Il arrive aussi que le raid plante sans raison. Après reboot, certaines
> partitions d'un disque sont marqués comme 'non-fresh' et sont virées du
> raid ; il faut les remettre à la main avec 'mdadm --add'.
>
> Du coup, je suis en train de me poser la question pour remplacer ces 2
> disques en raid 1 par un unique SSD. Les données écrites par notre appli
> sont de l'ordre de 10Mo (logs) par jour. Pensez-vous que ce soit viable ?
> Je sais que les SSD dispatchent l'écriture sur tout le disque, histoire de
> l'user de manière uniforme. Pour combien de cycles d'écriture sont-ils
> donnés ? En en prenant un assez gros, combien de temps peut-on espérer
> tenir avant qu'il lache (hors panne, bien sûr) ?
>
> Merci d'avance.
Nous avons un peu le même problème au boulot. Du fait du process, des
applis génèrent en moyenne 100ko/s de données en écritude, mais toujours
ou moins au même endroit. Résultat, la surface magnétique des disques
"s'usent" (le terme n'est pas exact, on pourrait plutôt parler de "perte
partiel de magnétisation").
Une analyse faite avec le constructeur indique que lorsque certaines
pistes sont ré-écrites souvent, cela influence aussi les pistes d'à
coté, et peut cause des changements de bits non voulus.
Afin de limiter les effets négatifs, on peut faire plusieurs choses au
niveau logiciel :
- Se débrouiller pour que ton logiciel temps-réel n'écrive pas toujours
au même endroit. Par exemple, si il écrit des logs toujours dans les
mêmes fichiers (log1, log2, log3, ...) tu peux déplacer les "vieux" logs
**sur la même partition**, mais dans un autre répertoire. Physiquement,
les octets du fichiers ne seront touchés (seul l'i-node sera changé), et
ce sera un autre emplacement physique du disque qui sera utilisé pour
les logs. Ainsi, l'usure du disque sera plus réparti. Charge à toi alors
de supprimer manuellement ces fichiers, lorsque tu as besoin de place.
- Tu peux monter les partitions avec des options particulières afin
d'éviter les ECRITURES lorsque qu'un fichier est LU (non, il n'y a pas
d'erreur dans ma phrase). Pour cela, utilise les options de montages
"noatime,nodiratime" dans le /etc/fstab. "man mount" pour plus d'infos :
<extrait>
noatime
Do not update inode access times on this file system (e.g,
for faster access on the news spool to speed up news servers).
nodiratime
Do not update directory inode access times on this filesystem.
</extrait>
- Si la machine a assez de mémoire vive, tu peux jouer avec le cache en
lecture (voir fichier en attachement)
- Enfin, SI, je dis bien SI, il y a un onduleur sur la machine, et pas
de risque d'arrêt intempestif, tu peux aussi jouer sur le cache en
écriture. Le fichier en attachement donne des commandes pour cela. Mais
tu peux aussi jouer avec les options de montage "async" et "commit=xx"
du /etc/fstab. Mais ATTENTION, cela rend le système plus sensible aux
arrêts brusques de la machine, d'où l'intérêt de l'onduleur.
En attachement, je t'envoie un script que j'ai écris qui est destiné à
augmenter l'usage du cache disque, autant en lecture qu'en écriture. Il
est largement commenté sur l'usage des commandes Linux utilisés. Je l'ai
écris suite à un mail sur la ML, son auteur originel pourra peut-être se
reconnaître ;)
Au cas où il ne passe pas par mail, il est aussi disponible ici :
http://olivieraj.free.fr/temp/optimisation_dd.gz
Coté purement hardware, on peut faire quelque chose qui ne coûte pas
chère : Refroidir les disques. Pour cela, il faut sur-ventiler le
disque, afin que sa température ne dépassé pas 20-30°C. Chez moi par
exemple, sur ma passerelle ADSL j'ai posé un ventilo de 120mm
perpendiculairement à un disque 3,5'. L'air externe est directement
envoyé sur sa tranche, et sa surface est toujours froide. Ce disque
avait été déclaré comme mort il y a 3 ans (secteurs défectueux), mais je
le fais tourner sans problème de cette manière depuis lors.
Enfin, le type de disque acheté est important. Les disques durs du
commerce ne sont pas fait pour fonctionner en 24hx24h et 7jx7j. Les
temps de MTBF de centaines de millier d'heures (5-10 ans) ne sont
valables QUE si le disque est utilisé 8h par jours, et 5 jour semaine.
Si les disque sont utilisés en mode 24x24 / 7x7, alors leur durée de vie
tombe à 1-2 ans. Informations données par les constructeurs.
Vers 2000, les constructeurs ont dûs "lâcher le morceaux" sur le
problème du MTBF, lorsque le taux de retour des disques à commencer à
augmenter, suite à la généralisation du P2P : Les machines bureautiques
de particuliers s'étant "brusquement" mise à fonctionner en 24x24, afin
de faire du download.
Certains constructeurs proposent donc des disques "certifiés" pour un
usage en 24x24 / 7x7. Ils sont plus chers, mais résistent mieux. Au
boulot, l'utilisation de ce type de disque nous a permis de passer d'un
changement annuel de disque, à "seulement" une fois tout les 3 ans.
Ces disques n'ont rien de magiques. Ils sont simplement sélectionné sur
la partie droite d'un gaussienne de répartition des disques en fonction
de leur qualité.
- La partie "centrale" de la gaussienne est destiné à Mr tout le monde
- La partie "droite" sont les disques destinés à un usage en 24x24 / 7x7
- La partie "gauche" est jeté.
Enfin, pour les SSD je suis assez réservé. Au boulot, nous avons fait
des tests de SSD. Mais ils ont été jugés non fiables, car ils ne
supportaient pas les variations des tensions d'alimentations (les
disques sont dans des machines qui consomment beaucoup, avec des à-coups
assez violent dans leur consommation).
Cordialement,
Olivier
--
~~~~~~~ _____/\_____ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phoenix / _ \/ _ \ Olivier Allard-Jacquin
/ / \ / \ \ Web: http://olivieraj.free.fr/
/___/ / \ \___\ Mail: olivieraj@???
~~~~ ///// ///\\\ \\\\\ ~~~~~~~~~~~~~~~~~~~~~~~ Linux Powered !!
