On Fri, 2011-06-10 at 10:27 +0200, sylvain letuffe wrote:
> Le vendredi 10 juin 2011 09:33:22, Vincent Caron a écrit :
> > La gestion du hotplug est encore et toujours une calamité (le support Linux
> > des divers backplanes est assez aléatoire)
>
> De quel hotplug tu parles ? du soft sous linux remplacé depuis par udev ? ou
> de la faculté de brancher et débrancher des disques à chaud ?
Le hotplug SATA. Il y a effectivement plusieurs volets :
- Niveau électrique: il faut en principe une connectique particulière
pour assurer un hotplug dans des bonnes conditions, ce qu'assurent ces
"backplanes"; il s'agit d'un peu d'électronique et de mécanique pour que
quand on insère ou retire un disque dans son chariot, tout se passe de
manière stable et prévisible. Je me souviens avoir lu vers LKML ou pas
loin des rappels sur ce sujet, le hotplug d'un disque c'est pas juste
brancher/débrancher le cordon SATA.
- Niveau soft: il faut gérer pas mal de détails, dans quel mode
d'erreur se met un disque supprimé, comment est détecté et nommé le
disque rajouté, puis bien adresser les éléments du RAID par
'enclosure' (emplacement) et non par device, etc. Mes derniers essais
(qui datent, Etch/2.6.18) me donnaient régulièrement un blockdevice
fantôme par disque hot-dépluggé, un "scan iscsi" ne changeant rien à
l'affaire.
Il y a aussi une partie driver qui compte, pas tous les drivers
peuvent détecter et émettre les signaux "disque débranché", "disque
branché"; et ne pas confondre ça avec une panne de câble ou autre.
> Si 2) mon expérience est la suivante :
> - le hot-unplug marche grossomodo sur toutes les config SATA que j'ai testé (en
> gros, on peut enlever le disque et la machine/le kernel ne partent pas en
> vrille)
Même ça je ne l'ai pas eu sur un serveur où le backplane était conçu
pour (chariots avec le bouzin qui va bien pour alimenter et connecter
les disques de façon "safe"). Un à base de Tyan 2865.
> - ça marche rarement en hot-plug : sur les serveurs DELL entrée-moyenne gamme
> (je peux retrouver les chipsets si besoin) ça ne plante pas, mais le disque
> n'est pas rendu accessible pour autant (mes tests datent de 1->2 ans)
Je n'ai aucun pb depuis près de 4 ans avec des Perc5, Perc6 et Areca
12xx.
> > et on ne peut pas lutter en perfs
> > contre un cache RAM backupé par un accu.
Jérémy t'a fait un topo complet :).
Et hélas en général quand on prend un de ces contreurs avec "memory
backed up RAM", si on passe en JBOD/passthru pour faire du raid soft, on
perd les features qui permettent d'en profiter (dans mon cas le FUA
[Forced Unit Access aka fsync-low-level]: dispo et intercepté par le
contrôleur en RAID hard, inexistant en JBOD).
> Le meilleure cache RAM à mon avis reste celui de la mémoire centrale de la
> machine, et c'est tant mieux, c'est la qu'il y en a le plus ! Cela ne
> permettant pas par contre de faire des écritures avec délais.
Je soupçonne que Linux pourrait faire mieux avec sa propre RAM _si
elle pouvait survivre à un crash ou une coupure de courant, car il a une
vue d'ensemble plus large des I/O que le contrôleur, et peut sûrement en
faire meilleur usage.
> Seul point positif que j'y est trouvé (pas possible à ma connaissance avec les
> contrôleur sata classiques), la baie disque dispose de petites diodes rouge ou
> verte pour indiquer simplement à l'opérateur le disque à changer
Ah oui, cette feature aussi... Mine de rien elle peut être vitale.
Quand tes serveurs sont à un DC où tu ne va pas, tu veux que ton presta
change de disque sans faille et sans se poser de question. J'en ai vu
pas trouver le bouton reset ou se tromper de machine alors qu'elles
étaient toutes bien étiquetées en ECRITURE LISIBLE. Exploser des RAID de
10T en éjectant le mauvais disque, c'est pas le même problème que
rebooter la mauvaise machine, pas mal de gens sont prêt à allonger qq
milliers d'euros pour ne pas tenter le diable :)
Et de manière générale, en RAID soft le hotplug est mal assisté et on
peut facilement se planter. Est-ce qu'il est possible de configurer
mdadm ou un démon tiers pour ce simple comportement :
- Erreur fatale sur un disque : mise en faute du disque, dégradation
du mode RAID (mdadm: OK)
- Hot-deplug du disque
- Hot-plug du disque: configuration et insertion du disque à
l'identique de son prédécesseur
Ca sous-entend que md désigne des bus (ou enclosures) plutôt que des
blockdevices, donc des /dev/disk/by-path/. Et l'énumération des devices,
donc ces chemins, tend à changer suivant le kernel, l'initrd, etc. Sauf
éventuellement si on joue avec udev, où on fera une conf spécifique à
chaque matos (CM + contrôleur). Ca implique aussi que mdadm sait
distinguer deux disques détecté en tant que même blockdevice (pour
savoir si c'est juste une panne temporaire ou si un opérateur a
physiquement changé le disque).
Bref il y a AMHA un sacré travail d'intégration et je suis pas sûr que
ça existe... Vous avez déjà vu qqchose s'approchant d'un NetApp en
libre ? Je ne vois pas grand chose du côté d'OpenFiler par ex.
