Je lis souvent que le RAID matériel c'est mal car on se retrouve prisonnier du hardware et cela peut poser des problèmes en cas de panne. C'est une idée un peu simpliste c'est pourquoi j'ai décidé de rédiger cet article.
Définition : RAID matériel, semi-matériel, logiciel ?
Même si je pense que tout le monde connaît déjà les différences, voici un petit résumé :
- Logiciel : entièrement géré par le système d'exploitation, ce dernier voit les disques physiques et les utilise pour créer un ou plusieurs périphériques block virtuels qui peuvent ensuite être formatés avec n'importe quel système de fichiers. Sous Linux, c'est md qui remplit ce rôle et il est pris en charge par l'installeur Debian. Il est possible de booter sur du RAID logiciel.
- Matériel : une carte additionnelle disposant d'un contrôleur (CPU + firmware + RAM) sert de couche d'abstraction. Le système d'exploitation ne voit plus les disques, uniquement les grappes (ou unités) gérées par la carte RAID. Il faut parfois un driver additionnel, mais la plupart du temps ils sont en upstream dans le kernel Linux (même avec Debian et son kernel sans blob propriétaire).
- Semi-matériel : aussi appelé fake-RAID, c'est ce qui est proposé sur les cartes mères en complément de l'AHCI et de l'IDE par votre contrôleur de stockage (Intel, JMicron...). Ce dernier agit comme une espèce de parasite et puise dans les ressources système et a besoin de pilotes spécifiques pour être reconnu par le système d'exploitation, sous Linux c'est dmraid, sous Windows ça dépend.<-- Lire entre les lignes : c'est de la merde lowcost et vous ne devez jamais l'utiliser.
- Géré par le FS (ex: ZFS ) : Certains systèmes de fichiers n'ont pas besoin de RAID à proprement parler, ils savent gérer directement la répartition/réplication des données. C'est le cas avec LVM qui dispose d'une implémentation basique ou encore ZFS, le meilleur FS du monde, qui lui dispose de fonctionalités avancées (mirror, stripping, raidz, spares...). <-- Lire entre les lignes : je suis un fanatique de zfs, vous devez l'utiliser.
Mon expérience
Le RAID matériel est souvent le plus simple car abstrait pour l'OS. Le changement des disques se fait à chaud et sur certains modèles il n'y a aucune manipulation à faire pour enclencher la reconstruction de la grappe. Il apporte aussi un gain en performances en raison du cache mais aussi parce qu'il soulage votre système lorsqu'il s'agit de calculer des parités (RAID5,6,50...). Il devient quasiment indispensable si vous souhaitez gérer de très nombreux disques (les cartes mères n'ont souvent pas plus de 8 ports SATA). En revanche, il est vrai que le RAID matériel peut poser des problèmes. Je n'ai jamais vu un contrôleur claquer mais j'ai "souvent" (au moins 3 fois par an sur une dizaine de cartes) subit des lag ou micro-coupures qui peuvent faire passer le système de fichiers en read-only et donc planter le serveur.
Le RAID semi-matériel c'est de la merde, très difficile à faire prendre en charge sous Linux en raison de drivers exotiques non libres. Il puise dans les ressources système pour fonctionner et on ne sait pas comment il se comporte si on change de carte mère ou même si on décide de reset le bios. A réserver au bidouillage ou aux gamers windowsiens qui veulent avoir 2 disques en RAID0 pour gagner en performances (encore qu'un unique SSD les écrase de loin). Mais à fuir en prod.
Le RAID logiciel est le plus sûr, il est upstream, non buggué et le CLI est assez évident. Attention je parle de Linux uniquement, je n'ai pas d'expérience avec le RAID logiciel de Windows. Pensez à installer Grub sur vos deux disques en cas de mirroring (RAID1). En cas de panne du serveur vous pouvez monter vos disques dans une autre machine et récupérer vos données. En cas de changement de disque il y a des opérations à faire en CLI mais ce n'est pas très compliqué.
La gestion par le FS (ZFS) est la méthode la plus souple et la plus puissante puisqu'on élimine une couche. Le FS a accès aux disques et à leur cache et sait comment les gérer et contrôler l'intégrité des données. En plus, en cas de changement de disque l'identification est plus simple et la procédure facilitée. Là encore vous devez faire les opérations en CLI, mais les commandes ZFS sont bien conçues et quasi intuitives.
Conclusion
Tout dépend de l'utilisation du serveur :
- ZFS est à privilégier si votre serveur est destiné à stocker des données (usage NAS ou SAN) très clairement. Et contrairement à ce qu'on pense, il ne faut pas des quantités astronomiques de mémoire vive, 8GB suffisent pour ZFS + vos services habituels (après ça dépend de la quantité de cache ZARC que vous souhaitez avoir).
- Le RAID logiciel pour vos serveurs Linux parce que c'est facile à installer, c'est fiable, et le CLI n'est pas très compliqué quand il s'agit de remplacer un disque.
- Le RAID matériel pour vos serveurs Windows (plus facile pour le boot) ou encore Linux si vous ne souhaitez pas vous embêter à gérer vous-même le RAID ou si vous avez des besoins spécifiques (très grand nombre de disques).
Attention ce titre est volontairement putaclick. Je voulais réagir à ce journal Linuxfr qui m'a beaucoup inspiré : BTRFS ne serait plus le futur. On y apprend que Red Hat laisse tomber le support de Btrfs et il ne sera plus présent dans les futures versions.
Ce n'est pas très rassurant, car sans aller jusqu'à dire que Red Hat fait figure d'autorité dans le libre, leur rayonnement en terme de contribution est tellement important que la grande majorité des distributions décident souvent de faire les mêmes choix. Et c'est compréhensible, c'est une forme "d'union du libre" que certains réclament depuis des années et qui permet de mutualiser les correctifs et évolutions chez les mainteneurs.
Vous allez me rétorquer qu'avec Btrfs c'est différent car c'est un composant upstream de Linux et qu'il n'y a rien à faire en particulier pour l'utiliser, oui sauf que le problème se situe pour le support et le backport des correctifs. Red Hat supporte ses versions 10 ans, cela veut dire qu'il y a un énorme boulot pour intégrer du code récent et changeant dans un kernel stable figé. Beaucoup se reposent sur Red Hat / CentOS, donc si le premier lâche l'affaire, ils suivront.
L'abandon du support de Btrfs est aussi un message fort, en effet Red Hat doit répondre aux attentes de ses clients et c'est notamment ce qui a provoqué le retour en force de xfs que je pensais obsolète depuis des années. Donc il semble qu'il n'y a pas de demande sur le marché et dans les datacenter pour Btrfs. Pourquoi ? Je vais proposer quelques idées.
Personnellement, plus le temps passe et moins je vois d'intérêt à Btrfs. Présenté comme un super système de fichiers moderne de la mort qui tue, son développement semble interminable puisqu'il a débuté en 2007 ! Et non seulement il n'est toujours pas stable, mais en plus toutes les fonctionnalités ne sont pas encore présentes. Sans rentrer dans le détail des possibilités du fs, on se rend compte que presque tout est déjà faisable aujourd'hui avec mdraid et lvm. Et je ne parle même pas de ZFS qui est à des années-lumière devant sur tous les points, qui est stable, éprouvé, et qui rencontre un certain succès. J'en veux pour preuve qu'il est entré dans les dépôts Debian, Ubuntu, et qu'il était déjà présent depuis longtemps chez Archlinux. Même avec les problèmes de licence les distributions choisissent de le supporter !
Ma réflexion me mène donc à une question : Btrfs est-il déjà mort ? Ce projet interminable qui veut concurrencer ZFS sans en avoir les épaules a-t-il une chance de se faire une place ? Étant un convaincu et un fanatique de ZFS je ne pense pas. Les gens qui n'ont pas besoin de fonctionnalités avancées resteront sur ext4, fiable et performant, tandis que les autres se tourneront vers ZFS qui n'est pas si gourmand qu'on le dit et qui offre une souplesse inégalée en terme de gestion des disques, pool et données. Nous verrons ce que l'avenir nous réserve, peut-être qu'une autre distribution réussira à lancer Btrfs.
Mageia 6 est sortie et Sebastien C, ceinture noire de troll et de changement de distribution nous livre un avis assez acide. Très peu d'évolutions sur cette version, une distribution qui se veut à la hauteur de debian sans en avoir les moyens, de trop nombreux bureaux, etc.
Je suis assez d'accord, car si on regarde Mageia quelle est sa force ? Sa communauté, son accessibilité et son centre de configuration. Concernant la communauté, je n'ai pas grand chose à en dire car je n'en fais pas partie mais je ne peux que supposer qu'elle se limite au desktop. En effet je n'ai jamais vu de Mandriva, Mandrake ou Mageia sur les serveurs, c'est 90% de debian/ubuntu et 10% de centos/rhel, le reste est anecdotique. Et si on parle de taille de communauté rien ne battra jamais celle de ubuntu/debian car on trouve énormément de ressources sur le web : forums, mailinglist, stackexchange, wiki, irc...
Concernant l'accessibilité aux débutants je suis assez réservé. Je n'ai jamais compris pourquoi Mageia continue de proposer son propre outil de gestion du réseau au lieu d'utiliser Network-manager comme tout le monde d'autant que ce dernier est bien meilleur pour ce qui touche par exemple au wifi ou aux VPNs. Ensuite je note souvent des comportements pouvant dérouter les débutants, par exemple cette manie du gestionnaire de paquet de vous demander de choisir parmi plusieurs dépendances disponibles lorsque vous souhaitez installer un paquet. Je rajoute qu'à chaque fois que j'ai testé cette distribution dans Virtualbox, après la première mise à jour il devient impossible de booter ce qui est quand même problématique.
Le centre de contrôle, je garde le meilleur pour la fin. Sur papier, c'est l'équivalent du Panneau de configuration de Windows, en pratique c'est totalement obsolète. La configuration du matériel n'est plus nécessaire car automatique (par exemple le pilote vidéo), la configuration des imprimantes fait doublon avec cups ou les interfaces proposées par KDE/Gnome, etc. Au final à part le gestionnaire de paquets il n'y a rien de pertinent en 2017. Pourquoi vouloir tripatouiller un centre de contrôle alors qu'à côté un simple Live CD de ubuntu fonctionne out-the-box ?
Si j'étais utilisateur de Mandriva, à sa mort j'aurai plutôt migré sur debian, opensuse ou fedora qui sont des distributions vivantes, actives avec beaucoup de moyens. Mageia me semble plus proche de l'acharnement thérapeutique, une volonté de conserver des outils et modes fonctionnements qui sont là pour rassurer les utilisateurs sans vraiment avoir une utilité ou une pertinence réelle. Les retards à répétition et l'absence de communication pour la 6e version ont d'ailleurs bien failli confirmer mes dires.
Note : c'est mon avis, il ne constitue pas une vérité absolue mais je l'assume. Vous pouvez m'insulter dans les commentaires si vous le souhaitez.
Juste un petit billet pour indiquer que le blog tourne à nouveau sous Docker. Cette fois-ci je n'utilise plus un unique container apache, mais 3 containers orchestrés par docker-compose :
Et il y a toujours un nginx "en dur" en frontal qui fait reverse proxy et centralise les logs.
Le serveur est désormais un Scaleway VC1S aux pays-bas sur lequel tourne une distribution Debian Stretch. Pour les containers j'ai choisi d'utiliser au maximum des images alpine en raison de leur légèreté et de la simplicité du système. Et pour le moment, ça marche plutôt bien.
J'ai essayé d'utiliser un serveur ARM Scaleway, mais outre le fait qu'il est compliqué d'installer Docker (il faut utiliser Ubuntu-server ou alors compiler) les images du Dockerhub ne semblent pas disponibles pour cette architecture. Je me suis donc rabattu sur un VC1S qui n'est rien d'autre qu'une machine virtuelle x86_64.
Si vous êtes familier avec l'écosystème des distributions Linux, vous avez probablement levé un sourcil (comme Teal'c) en lisant ce titre car vous les connaissez toutes, vous avez touché à tous les gestionnaires de paquet, vous avez utilisé debian et gentoo, en bref vous avez fait le tour et plus rien ne nous surprend.
Et pourtant, bien que NixOS soit une distribution assez ancienne (2003) elle dispose de nombreux atouts inédits passés plutôt inaperçus jusqu'à présent.
La configuration déclarative centralisée
Ce que je trouve le plus intéressant dans NixOS, c'est la configuration centralisée dans un unique fichier. En effet si vous avez déjà travaillé sur des routeurs ou diverses appliances, vous avez remarqué que l'on peut souvent importer et exporter la configuration sous forme de texte assez facilement, cela rend la maintenance très facile. Sous NixOS c'est le même principe, mais en plus puissant puisqu'on peut rollback voire booter sur une ancienne configuration depuis grub. Exemple de configuration d'un serveur MariaDB :
/etc/nixos/configuration.nix
{ config, pkgs, ... }:
{
imports =
[ # Include the results of the hardware scan.
./hardware-configuration.nix
];
# Use the systemd-boot EFI boot loader.
boot.loader.systemd-boot.enable = true;
boot.loader.efi.canTouchEfiVariables = true;
networking = {
hostName = "mariadb";
nameservers = [ "192.168.0.31" ];
defaultGateway = "192.168.0.254";
interfaces.enp0s3.ip4 = [
{
address = "192.168.0.41";
prefixLength = 24;
}
];
};
# Select internationalisation properties.
i18n = {
consoleFont = "Lat2-Terminus16";
consoleKeyMap = "fr";
defaultLocale = "fr_FR.UTF-8";
};
# Set your time zone.
time.timeZone = "Europe/Paris";
# List packages installed in system profile. To search by name, run:
# $ nix-env -qaP | grep wget
environment.systemPackages = with pkgs; [
git
htop
sudo
tree
vim
];
# Services
services = {
openssh = {
enable = true;
permitRootLogin = "yes";
};
mysql = {
enable = true;
package = pkgs.mysql;
extraOptions = ''bind-address=0.0.0.0'';
};
};
# Open ports in the firewall.
networking.firewall.allowedTCPPorts = [ 22 3306 ];
# networking.firewall.allowedUDPPorts = [ ... ];
# Define a user account. Don't forget to set a password with ‘passwd’.
users.extraUsers = {
utux = {
isNormalUser = true;
extraGroups = [ "wheel" ];
};
};
# The NixOS release to be compatible with for stateful data such as databases.
system.stateVersion = "17.03";
}
/etc/nixos/hardware-configuration.nix
# Do not modify this file! It was generated by ‘nixos-generate-config’
# and may be overwritten by future invocations. Please make changes
# to /etc/nixos/configuration.nix instead.
{ config, lib, pkgs, ... }:
{
imports = [ ];
boot.initrd.availableKernelModules = [ "virtio_pci" "ahci" "xhci_pci" "sr_mod" "virtio_blk" ];
boot.kernelModules = [ ];
boot.extraModulePackages = [ ];
fileSystems."/" =
{ device = "/dev/disk/by-uuid/78634ba0-11d1-4f91-85ae-ac2ee247c387";
fsType = "xfs";
};
fileSystems."/boot" =
{ device = "/dev/disk/by-uuid/019A-1A05";
fsType = "vfat";
};
swapDevices =
[ { device = "/dev/disk/by-uuid/075a27eb-5656-4b57-b186-73a6d86e5e5c"; }
];
nix.maxJobs = lib.mkDefault 1;
}
Comme vous le voyez, le fichier configuration.nix contient toute la configuration, incluant les services tiers tels que mariadb dans notre cas. Cela va donc encore plus loin que le /etc/rc.conf sur FreeBSD/NetBSD/OpenBSD qui centralise déjà pas mal de choses. Le fichier hardware-configuration.nix lui est généré automatiquement il n'y a pas besoin d'y toucher et il est plus ou moins unique par serveur.
Pour générer et appliquer la configuration :
nixos-rebuild switch
Pour mettre à jour le système :
nixos-rebuild switch --upgrade
Puis un petit mysql_secure_installation la première fois pour préparer notre SGBD.
Ce qu'il reste à faire en dehors du configuration.nix, c'est la définition des mots de passe, avec passwd et bien sûr la gestion des données persistantes (les bases de données pour mariadb par exemple).
Nix, gestionnaire de paquets fonctionnel
Je vais être un peu plus prudent sur ce point, car étant encore en phase de découverte de NixOS, je ne connais pas encore très bien le gestionnaire de paquets Nix. Cependant, à la différence des gestionnaires classiques tels que apt, yum ou pacman, il ne se contente pas d'aller chercher des paquets pour les décompresser. Chaque version de chaque paquet est installé dans une arborescence /nix/store/{identifiant unique}, du coup plusieurs versions peuvent cohabiter ensemble et les mises à jour n'écrasent rien. Il est possible également pour les utilisateurs d'installer des paquets pour leur environnement (non-root) uniquement.
Mon avis
J'ai mis un serveur NixOS en test et il est trop tôt pour en tirer des conclusions. Mais j'aime l'idée de configuration centralisée déclarative, car la configuration classique des systèmes Linux n'est pas toujours simple à maintenir : Docker, Ansible, NixOS : le savoir (re)faire.
Si je dois citer deux inconvénients à NixOS : elle prend de la place (1,6GB à l'installation avec MariaDB) et elle nécessite au moins 1GB de RAM pour s'installer sous peine de voir oomkiller tuer nixos-install... elle peut cependant tourner avec 256MB par la suite.
NixOS nous montre qu'une distribution Linux ce n'est pas seulement un éinième fork de Ubuntu avec un wallpaper personalisé, ou encore une guerre de gestionnaire de paquets (dnf/apt), il existe encore de l'innovation et rien que pour cela elle mérite le coup d’œil.
Fil RSS des articles de cette catégorie