Aller au contenu principal

Éviter les pannes matérielles

Sécuriser physiquement votre serveur​

Très souvent les personnes qui s'autohébergent n'ont pas de rangement correct pour leur système. Laisser le serveur en plusieurs parties, dans un lieu de passage, accessible à des enfants ou des animaux, ou dans un endroit peu aéré peut vite tourner à la catastrophe.

Fixer vos disques durs​

Idéalement, vos disques durs doivent être fixés pour éviter les vibrations qui peuvent accélérer l'usure du matériel voire atténuer ses performances, notamment s'il y a un autre disque à côté.

Réduire la swapiness pour les cartes SD et disques SSD​

Si vous utilisez un fichier de swap avec un SSD ou une carte SD avec une swapiness trop élevée, votre support de stockage pourrait rendre l'âme prématurément en raison d'un trop grand nombre d'écritures.

Pour éviter ça:

cat /proc/sys/vm/swappiness

Si elle est au-dessus de 10:

sysctl vm.swappiness=10
nano /etc/sysctl.conf

Si la ligne est présente, changez la valeur vm.swappiness à 10.Sinon, ajoutez la ligne:

vm.swappiness = 10

Redondance de stockage​

Afin de limiter les pannes matérielles des supports de stockage, il peut être pertinent de mettre en place une grappe de disques en miroir (RAID, ZFS). L'idée ici est que tout ce qui est écrit sur un disque le sera sur l'autre. Ainsi, si l'un tombe en panne, l'autre continue de fonctionner et le serveur est toujours pleinement fonctionnel.

Il existe aussi des grappes plus évoluées qui maximisent la tolérance de panne (panne de 2 disques comme le RAID6) ou le stockage (voir RAID 5).

Toutefois, ces techniques de grappes de disques ne devraient pas être considérées comme des copies de sauvegarde. Une grappe RAID devrait être considérée comme un seul support de stockage. En effet, si cette technique permet d'éviter de devoir réinstaller en cas de crash probable d'un disque, on est loin du risque zéro.

Quelques exemples de situations connues des administrateurs systèmes professionnels:

  • the disks of a cluster mounted with disks of the same brand can fail almost at the same time within a few hours
  • without monitoring the health of the disks, there is a good chance that the failure of one disk in the cluster will only be noticed when a second one fails (><)
  • if you don't have a spare disk, the delay in purchasing one may result in the other disk crashing
  • a half-functional disk that produces errors can propagate its error through the cluster
  • the disk connectors or the RAID controller can also produce errors or fail
  • the more complex you make the architecture with many components, the more likely it is that one of them will fail
info

Si vous souhaitez mettre en place une grappe RAID ou utiliser btrfs, le plus simple est de le faire à l'installation avec l'iso YunoHost en mode expert (lors du partitionnement du système).