Journal Vitesse reconstruction Raid 1 et noyau 2.4.24

Posté par  (site web personnel) .
Étiquettes : aucune
0
24
août
2004
Tout d'abord bonjour à tous.

Nous mettons en place (dans notre service) un serveur de sauvegarde (serveur HP) constitué d'un raid logiciel (raid 1) sous Debian.

Nous avons 1 disque en permanence dans la machine, ainsi que 2 disques dans des racks. Chaque fin de semaine, la machine est éteinte, on enlève le rack se trouvant dans le pc pour le remplacer par le second (pour au final disposer d'un disque (stocker chez un collaborateur) contenant une sauvegarde datant au pire d'une semaine).
Enfin ça, c'est juste pour expliquer un peu le contexte et mieux comprendre les tests de vitesse de reconstruction du raid.

Après avoir configuré correctement hdparm pour que l'ultra DMA soit activé, nous arrivons à une vitesse de reconstruction de 22 Mo/s lorsque nous changeons de disque.
Cependant, afin de pouvoir utiliser le haut parleur du PC de sauvegarde (notamment pour informer de l'état du raid), nous avons téléchargé puis compilé le noyau 2.4.24.

La carte son (intégré) est correctement gérée, mais la vitesse de reconstruction du raid est descendue à 11Mo/s (même chose avec le 2.4.27).
Nous avons pourtant vérifier que toutes les options cochées (modules ou en dur) dans le 2.4.19 soit présente dans le 2.4.24.

Si vous avez des suggestions/remarques, elles sont les bienvenues.

  • # swap disque pour backup ?

    Posté par  (site web personnel) . Évalué à 2.

    Si vous avez des suggestions/remarques

    Je trouve ca bourrin de swapper des disques sur un raid, pour une histoire de backup. Pourquoi ne laisseriez vous pas le raid tranquille, et faire des backups du RAID sur un autre disque (celui qui ira chez votre collaborateur) ?

    En plus, vous n'aurez plus besoin d'arreter le serveur.

    • [^] # Re: swap disque pour backup ?

      Posté par  (site web personnel) . Évalué à 1.

      C'est évidemment assez bourrin, mais avec cette façon de procéder, il n'y a pas de problème d'intégrité des données. En effet, en faisant des backup du RAID, si un collègue va sauvegarder ses données au même moment, on peut se retrouver avec seulement une partie des fichiers d'un répertoire (on aurait pu certes programmer avec at ou cron la sauvegarde des données la nuit)

      Ensuite, d'un point de vue pratique (nous sommes seulement 2 informaticiens dans le service), c'est plus simple pour la personne qui change le disque, d'éteindre la machine, changer le dur, et de rallumer que de lancer la sauvegarde un certain temps avant (risque d'oubli), puis de venir chercher le dur.

      Enfin il y a aussi le coût. Si on veut disposer d'un disque dur toujours à l'extérieur de l'entreprise, il nous faut 3 disques + 1 disque (pour le système) actuellement, contre 4 disques en faisant un backup du raid.

      Merci pour ton intervention

      • [^] # Re: swap disque pour backup ?

        Posté par  . Évalué à 3.

        Euh, là, je comprends pas.

        Pourquoi ne pas utiliser un disque SCSI (une interface U160 ça doit se trouve pour que dalle aujourd'hui) d'une capacité équivalente voire moindre (enfin, suivant la taille des données), et utiliser un équivalent du freeze de XFS pour faire un snapshot du système sans arrêter la machine, copier les données du snapshot et relâcher le snapshot ? En résumé tu aurais :

        IDE1: premier disque R1
        IDE2: deuxième disque R1
        IDE3: petit disque de petite capacité pour stocker les changements faits pendant le freeze du snapshot
        SCSI1: un disque hotplug sur lequel tu copies le snapshot.

        Et tout ça sans arrêter la machine. Mais ça reste bourrin. Tu connais les 7 Tao du Backup ? http://www.taobackup.com/(...)
        Cela dit qu'on ne réutilise jamais une backup pour en refaire une autre. Imagine que tu corrompes un fichier et que tu ne t'en rendes compte que 7 semaines après la corruption. Tu seras bien avancé avec ta backup d'une semaine... Les bandes sont plus intéressantes, et elles n'empêchent pas d'appliquer ce que j'ai présenté précédement.

        (PS: Oui, je sais, il n'y a que 1 types de personnes dans le monde, celles qui comptent à partir de 0, et celles qui commencent à 1, désolé pour le IDE1 et pas IDE0)

        • [^] # Re: swap disque pour backup ?

          Posté par  (site web personnel) . Évalué à 1.

          Ta façon de procéder pourrait convenir, c'est évident.

          Je pense qu'on va revoir quelque peu l'organisation de notre futur serveur de sauvegarde (par exemple en faisant des archives tgz toutes les semaines plutot qu'utiliser directement des disques entiers).

          Merci, notamment pour les 7 Tao du Backup.

      • [^] # Re: swap disque pour backup ?

        Posté par  (site web personnel) . Évalué à 2.

        Ensuite, d'un point de vue pratique (nous sommes seulement 2 informaticiens dans le service), c'est plus simple pour la personne qui change le disque, d'éteindre la machine, changer le dur, et de rallumer que de lancer la sauvegarde un certain temps avant (risque d'oubli), puis de venir chercher le dur.

        Je suis desolé mais je ne comprend pas ... Pourquoi une intervention manuelle serait plus "pratique" qu'un cron qui sauvegarde (via le reseau/ou en local) vos disques RAID ?

        Vous y gagnerez en :
        rapidité : plus d'intervention manuelle,
        fiabilité : plus aucun risque d'oubli,
        disponibilité : plus d'interuption de service.

        Sinon, ben je suis le seul informaticien dans mon service :)

        Enfin il y a aussi le coût. Si on veut disposer d'un disque dur toujours à l'extérieur de l'entreprise, il nous faut 3 disques + 1 disque (pour le système) actuellement, contre 4 disques en faisant un backup du raid.

        La non plus, je ne comprend pas comment la meme quantité d'information a backuper, prendrait plus de place dans un cas que dans l'autre.

  • # hdparm

    Posté par  . Évalué à 2.

    passe un coup d'hdparm sur chaque disque et compare les resultats entre chaque kernel. Tu peux aussi faire un petit test de vitesse avec hdparm (hdparm -tT /dev/tondev), bien que ca ne servira qu'a demontrer que le raid logiciel tourne moins vite sur un kernel + recent si jamais tu ne constate pas de difference entre les benchs.
    Si les parametres renvoyes par hdparm sont differents d'un kernel a l'autre, colle un script hdparm quelque part a l'init de la box pour retrouver toujours les memes parametres quel que soit le noyau utilise.
    Attention, certains disques et certaines cartes controlleurs n'aiment vraimment pas hdparm, teste chaque parametre separement avant de tout balancer dans le script.

    • [^] # Re: hdparm

      Posté par  (site web personnel) . Évalué à 1.

      Je viens d'effectuer les test avec hdparm -Tt. C'est affreux :-O

      Donc nous avons respectivement :
      Noyal (un noyal des noyaux ;-) ) 2.4.19 :
      _ Reconstruction du raid : 22 Mo/s
      _ Buffered disk reads : environ 40 Mo/s


      Noyal 2.4.27 :
      _ Reconstruction du raid : 11 Mo/s
      _ Buffered disk reads : environ 55 Mo/s


      Donc pour conclure, plus le disque transfert vite, moins le raid synchronise vite. Logique, non ?

      • [^] # Re: hdparm

        Posté par  . Évalué à 1.

        Et les parametres renvoyes par hdparm (sans flag) sont identiques d'un kernel a l'autre ?

        • [^] # Re: hdparm

          Posté par  (site web personnel) . Évalué à 1.

          Oui totalement identique.

          J'ai fait un hdparm /dev/hdb et un hdparm /dev/hdd avec sortie dans un fichier (différent pour chaque kernel).

          Puis un diff des 2 fichiers -> aucune différences.

  • # Limitation logicielle ...

    Posté par  . Évalué à 2.

    Et tu as quoi dans

    /proc/sys/dev/raid/speed_limit_max


    Normalement par défaut c'est 100 Mbs si je me souviens bien, mais il faut vérifier (j'ai pas de machine sous la main).

    M

  • # /proc

    Posté par  (site web personnel) . Évalué à 2.

    Il y a un paramètre de vitesse de reconstruction de volume RAID dans /proc, je me souviens plus quel fichier... désolé... faire un cat n > /proc/chemin/fichier... matte dans le RAID-HOWTO, je crois l'avoir lu là dedans.

    • [^] # Re: /proc

      Posté par  (site web personnel) . Évalué à 1.

      Concernant le fichier /proc/sys/dev/raid/speed_limit_max
      nous avons déja vérifié celui-ci, et la vitesse max est de 100Mb/s

  • # Conclusion

    Posté par  (site web personnel) . Évalué à 1.

    On a compilé et installé le noyau 2.6.8
    Apres une petite recherche sur internet, on s'est rendu compte qu'il fallait installer module-init-tools pour que lsmod et modprob fonctionnent (on aurait aimé une petite dépendance lors de l'installation des sources via apt, mais bon)

    Au final, ca reconstruit bien (encore plus vite, 27 Mo/s) et on a le son.
    Super


    Merci pour vos interventions.
    @ bientôt.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.