Bonjour les gens,
Le contexte
déçu du service de mon hébergeur, j'ai pris la décision cet été de louer ma propre baie et d'y mettre un petit cluster Ceph. Celui-ci étant complètement distribué et redondé, j'ai choisi de partir sur du matériel relativement basique («commodity hardware»), de marque ASRock Rack. Yep, moi non plus je ne savais pas qu'ils osaient faire des serveurs.
Il faut dire que la bête est alléchante : pour 800€, CPU compris, on a un boitier 1U pouvant accueillir 12 disques SATA 3.5", accompagné d'un CPU Intel Avoton (8 coeurs, 20W) plutôt adapté à mon besoin.
Me voilà donc parti à remplir ces bestioles chacune de 12 disques de 4To, là encore pris dans les gammes grand public (ou presque, j'opte pour un disque 5400tr/min estampillé «NAS»).
La carte mère ASRock C2750D4I
Pour gérer ces 12 disques SATA, la carte mère intègre plusieurs contrôleurs :
- le SoC Intel fourni 2 ports SATA III et 4 ports SATA II
- auquel s'ajoute un contrôleur Marvell 88SE9172 (2 ports SATA III)
- ainsi qu'un contrôleur Marvell PCIe 88SE9230 (4 ports SATA III)
Ça fait un peu bricolage, mais après tout on est sur une gamme low-cost.
Le problème
Assez rapidement je constate des erreurs disque sur les 4 derniers ports, ceux du Marvell 88SE9230, qui force le système à exclure les disques en question. Un simple reboot suffit à corriger le problème, mais ce n'est guère pratique.
L'erreur la plus fréquente est la suivante :
Aug 11 07:32:34 stor4 kernel: [36935.018725] ata12.00: exception Emask 0x0 SAct 0x10 SErr 0x0 action 0x6 frozen
Aug 11 07:32:34 stor4 kernel: [36935.018795] ata12.00: failed command: READ FPDMA QUEUED
Aug 11 07:32:34 stor4 kernel: [36935.018847] ata12.00: cmd 60/08:20:28:a7:88/00:00:0f:00:00/40 tag 4 ncq 4096 in
Aug 11 07:32:34 stor4 kernel: [36935.018847] res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Aug 11 07:32:34 stor4 kernel: [36935.018972] ata12.00: status: { DRDY }
Aug 11 07:32:34 stor4 kernel: [36935.019010] ata12: hard resetting link
Aug 11 07:32:34 stor4 kernel: [36935.350848] ata12: SATA link up 6.0 Gbps (SStatus 133 SControl 320)
Aug 11 07:32:34 stor4 kernel: [36935.352234] ata12.00: configured for UDMA/133
Aug 11 07:32:34 stor4 kernel: [36935.352256] ata12.00: device reported invalid CHS sector 0
Aug 11 07:32:34 stor4 kernel: [36935.352268] ata12: EH complete
Une solution ?
Après de nombreuses recherches et hypothèses, des tests plus ou moins judicieux et même une mise à jour du BIOS, j'ai fini par identifier le problème : le contrôleur en question semble ne pas gérer correctement le NCQ, est submergé par le SATA III, et ne gère pas non plus correctement S.M.A.R.T.
Il suffit donc de désactiver tout ça pour que la carte mère devienne à nouveau stable.
Ce qui veut dire que dans les paramètres de mon noyau (dans /etc/default/grub sous Debian), pour forcer le SATA II et désactiver le NCQ, j'ai dû ajouter :
libata.force=9:noncq,3.0G,10:noncq,3.0G,11:noncq,3.0G,12:noncq,3.0G
Tandis que pour SMART, j'ai désactivé le DEVICESCAN de smartd, afin d'activer manuellement S.M.A.R.T seulement sur les 8 premiers disques.
À noter que pour le moment j'ai également ajouté irqpoll dans les paramètres du noyau, suite à des messages occasionnels dans les logs :
Aug 14 00:44:58 stor5 kernel: [ 65.818217] irq 9: nobody cared (try booting with the "irqpoll" option)
Bref ça fonctionne, j'ai perdu beaucoup de temps (ce qui me fait relativiser la perspicacité de mon choix), et j'espère que mon journal aura au moins le mérite d'épargner un peu de cheveux et de temps à la prochaine personne souhaitant utiliser ce joli joujou.
# Détails, et rapports de bogue
Posté par Cyril Brulebois (site web personnel) . Évalué à 8.
Je t'invite à donner un peu plus d'infos, notamment le numéro de version précis de ton noyau. Des fois, cela peut inciter des lecteurs désœuvrés à aller regarder s'il n'y a pas un correctif ou un contournement qui aurait été intégré entre temps, qu'il suffirait de backporter en le signalant sur la liste ou le bugtracker qui va bien. Dans tous les cas, un rapport de bogue dans ta distribution est (à ma connaissance) toujours une bonne idée.
Debian Consultant @ DEBAMAX
[^] # Re: Détails, et rapports de bogue
Posté par Kioob (site web personnel) . Évalué à 2. Dernière modification le 20 août 2014 à 13:48.
Effectivement je n'ai pas précisé. Je testé uniquement des noyaux 3.14.*, à la fois celui proposé par Debian en backports et un «vanilla» compilé moi-même.
Je testerai peut-être un 3.16.* à l'occasion, voir si le problème a été corrigé depuis.
alf.life
[^] # Re: Détails, et rapports de bogue
Posté par Cyril Brulebois (site web personnel) . Évalué à 5.
OK, merci. [Même si la bonne réponse était 3.14.12-1~bpo70+1, cf. /proc/version ;)]
Probablement pas corrigé depuis (au moins au niveau de drivers/ata/pata_marvell.c) puisque les deux commits entre v3.14 et master ne sont que du clean-up (1bc18086231c130895b87ec049be8ddcdab552b8) et de l'ajustement concernant des options de compilation pour la gestion de l'énergie (58eb8cd565af4a104395e3c10443951c1f73dafe).
Debian Consultant @ DEBAMAX
[^] # Re: Détails, et rapports de bogue
Posté par Cyril Brulebois (site web personnel) . Évalué à 6.
Un dernier commentaire sur ton problème : il y a déjà eu au moins un rapport de bogue concernant le support NCQ. S'il est compliqué de diagnostiquer le problème ou s'il s'avère que le matériel est bogué, cela peut finir par la désactivation de cette fonctionnalité pour ce matériel, afin que les utilisateurs suivants n'aient pas à jouer avec leur ligne de commande de noyau.
Le commit qui introduit la « blacklist NCQ » :
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=67809f85d31eac600f6b28defa5386c9d2a13b1d
Bugzilla me semble être le point de passage incontournable, notamment si tu as envie que des gens qui s'y connaissent en NCQ, SATA II vs. III, etc. puissent jeter un coup d'œil.
Debian Consultant @ DEBAMAX
[^] # Re: Détails, et rapports de bogue
Posté par Kioob (site web personnel) . Évalué à 3.
Yep, j'avais vu un rapport de ce genre concernant des SSD de marque Corsair. Le problème venait du SSD, mais la solution était similaire : un patch noyau était fourni pour désactiver le NCQ pour ce matos, et en attendant ils donnaient les paramètres libata pour contourner le problème.
Demain je vais prendre le temps de faire le rapport de bug en question.
alf.life
# Ton besoin
Posté par MTux . Évalué à 6.
Salut, je suis curieux de connaître ton besoin.
Louer une baie et un boitier super cher pour au final investir dans du matériel low cost ??? Je m'y perds un peu.
Sinon en effet connaitre la version du kernel peut être intéressant, Debian ayant toujours des versions de la préhistoire, peut-être que les bugs n'existent plus depuis.
[^] # Re: Ton besoin
Posté par NeoX . Évalué à 5.
comme MTux
j'ai souvenir que louer une baie, demie baie ou quart de baie dans un datacenter, avec electricité et connexion internet, etait bien plus cher que louer un serveur dédié d'un hebergeur.
du coup, comme c'est quand meme une solution qui peut quand meme m'interesser, je serais curieux de connaitre l'hebergeur que tu as choisis, et ses tarifs
[^] # Re: Ton besoin
Posté par stopspam . Évalué à 7. Dernière modification le 20 août 2014 à 11:15.
Acheter du matos low cost : c'est bien.
Acheter du matos low cost, très répandu et éprouvé : c'est mieux.
[^] # Re: Ton besoin
Posté par Raphael Berlamont (site web personnel) . Évalué à 5.
Oui, mais généralement, les «pros» restent discret sur leurs choix technologiques.
Comment savoir, hors discours commerciaux de fabricants, le matos qui est «très répandu et éprouvé» ? Tu as des sources d'infos ? Je suis intéressé.
[^] # Re: Ton besoin
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 10.
Disclaimer :
Je ne suis ni commercial, ni fabricant. Mais j'utilise du stockage "HPC" professionnellement tous les jours.
TL;DR : On choisit LSI, comme les autres.
Solution du "Pro riche" (platinuim overlazzyness) :
Panasas, ddn, isilon, netapp, etc…
hors des firmwares et de certaines cartes controleurs en plaqué platine, c'est trés souvent du LSI recarrossé.
Solution "Pro aveugle" (ou lazzy) :
Dell/Compellent, HP, Nexenta, … Le choix va dépendre de l'OS et de la confiance que tu t'autorise sur les controleurs RAID.
(et c'est aussi souvent du supermicro, ou du LSI recarrossé)
Solution "Pro intelligent" (nous tous) :
Bare metal (ldlc, dell, on s'en fout), mais controleurs SAS LSI, baies SAS LSI, SuperMicro, Xtore, dataon, whatever mais SAS et JBOD !.
Tout va dépendre des perfs attendues et de la soluce logicielle (btrfs, zfs, etc).
Recette du ~pro :
J'ai des machines avec des baies de disques 2"1/2 (24 slots, sur base supermicro), avec mix mecanique et SSD, pour de la perf, et j'ai aussi du bon gros dell r720xd, avec deux expander 240To au cul (controleurs SAS et expandeurs LSI recarrossés), pour du stockage massif (et étonnement performant).
Expérience :
On est passé de ZFS/Solaris à ZFS/Debian, en gardant un oeil sur btrfs. L'expérience nous a appris à éviter HP comme la peste (JBOD, connaissent pas, Debian? Caca!).
Elle nous a aussi appris que le SATA pour du multidisques > 3, faut oublier. En dehors de SAS, point de Port-Salut.
Backblaze avait écrit un excellent article sur leurs choix techno (même si je n'approuve pas tout) :
https://www.backblaze.com/blog/petabytes-on-a-budget-how-to-build-cheap-cloud-storage-2/
Nous nous en somme inspiré quand nous avons du remplacer nos Sun X4500 Thumper.
Je sais que ce n'est pas du tout dans le même budget :o) mais vous vouliez un avis de "pro".
(j'ai placé ZFS ?)
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: Ton besoin
Posté par Kioob (site web personnel) . Évalué à 1.
Assez d'accord avec tout ça, en prod j'ai essentiellement du LSI (cartes Intel), dans du Supermicro.
Quant à mon infra backup, j'avais effectivement beaucoup lorgné du coté de Backblaze, pour la partie hard en tous cas.
alf.life
[^] # Re: Ton besoin
Posté par Raphael Berlamont (site web personnel) . Évalué à 2.
Merci pour ce retour.
Tu n'approuves pas parce qu'ils utilisent du SATA au lieu du SAS que tu sembles préférer ?
[^] # Re: Ton besoin
Posté par Kioob (site web personnel) . Évalué à 3.
Je pense surtout à leur JFS over RAID, au lieu de ZFS ou autre système de stockage «moderne».
alf.life
[^] # Re: Ton besoin
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 2.
Les deux : le SATA, qui plafonne vite en perf (et en nb de disques gérés). mdadm qui limite les raid softs à 27 dev. Et JFS en fs principal (qui force à gérér des tranches de 16To max).
J'ajoute qu'ici, on joue avec du multipath(d) et ça SATA, il sait pas faire.
Proverbe Alien : Sauvez la terre ? Mangez des humains !
[^] # Re: Ton besoin
Posté par Kioob (site web personnel) . Évalué à 10.
mmm au départ plusieurs besoins :
J'ai en production un cluster Ceph (qui fonctionne très bien). J'y stocke des images de VM, et j'en fais régulièrement des snapshots. Ces snapshots finissent par consommer beaucoup de place, et tant qu'ils seront stockés au même endroit il y aura toujours un risque de perdre des données (piratage du cluster, conflit avec le fournisseur, fausse manip, bug logiciel, etc). Je veux donc pouvoir sauvegarder ce cluster, chez un autre prestataire que la production, et le moyen le plus efficace est «rbd export-diff/import-diff» (similaire à zfs send/receive) ce qui implique donc d'avoir un second cluster Ceph.
J'ai également besoin d'un espace de stockage en dehors de ma production pour y stocker des sauvegardes plus classiques (via rsync), et utiliser des VM stockées sur un cluster Ceph est très pratique, le stockage de chaque VM étant ainsi virtuellement illimité.
Je n'ai pas de cluster Ceph de test, et c'est un vrai manque. Avoir un second cluster, moins critique, sur lequel je pourrais déployer les nouvelles versions avant la prod, ce serait un gros plus.
L'ASRock Rack en question me permet donc d'ajouter des noeuds de 48To (43.6 Tio en pratique) à 3k€ chacun, disques compris. Plus simplement, à 800€ le boitier, avec alimentation, carte mère et CPU inclus, je n'ai clairement pas trouvé d'équivalent, même en 2U. Asus a bien un modèle similaire (à ce que je sache c'est le même groupe qu'ASRock), mais je ne suis pas certain qu'on y gagne beaucoup.
Partir sur des boitiers 4U gavés de disques serait également une alternative, mais peu adaptée pour Ceph (resynchroniser 72*4To par le réseau, faut pas être pressé).
Au final avec 3 boitiers de ce type ainsi que 3 supermicro très basiques et un switch, pour un total de 48 disques de 4To, je ne consomme «que» 2.5A sur 7U. Ce qui devrait me permettre de remplir progressivement la baie, sans que je ne dépasse les 16A de quota.
Pour ce qui est du choix du fournisseur, j'ai simplement opté pour le datacenter le plus près de chez moi (5 minutes à pieds), c'est clairement ce qui m'a décidé à franchir le pas.
alf.life
[^] # Re: Ton besoin
Posté par Prosper . Évalué à 4.
était le même groupe http://fr.wikipedia.org/wiki/ASRock#Historique
[^] # Re: Ton besoin
Posté par Arthur Accroc . Évalué à 3.
A-t-il aussi un contrôleur Marvell ?
S’il a un contrôleur mieux supporté avec le NCQ qui fonctionne correctement, ça vaut le coup d’acheter plutôt l’Asus.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Ton besoin
Posté par Kioob (site web personnel) . Évalué à 1.
Effectivement, ce qui me gênait c'est qu'ils n'avaient que du Xeon classique, pas d'Avoton, mais leur carte mère a le gros avantage de proposer 6 ports SATA Intel + 8 ports LSI (LSI 2308 8-Port SAS Controller). Un autre aspect intéressant de ce modèle Asus, ce sont les ports dual 10Gbps.
Cf : http://www.asus.com/Commercial_Servers_Workstations/RS300H8PS12/specifications/
Mais ce mélange SAS/SATA m'intrigue.
En dehors de ça, on trouve le boitier à 1100$ sur le net, sans le CPU. C'est plus cher que l'ASRock, mais c'est probablement justifié.
alf.life
# Changer de distrib...
Posté par Christophe Merlet (site web personnel) . Évalué à 0.
Je ne connaissais pas l'Atom Avoton… sacré rapport performance/consommation !
Je note que la carte-mère est censé fonctionner avec les distributions Linux suivantes. As tu essayé avec l'une d'entre elles au lieu de persister avec Debian ?
Linux
- RedHat Enterprise Linux Server 5.5/6.4 (x32 and x64)
- CentOS 5.5 / 6.4 (x32 and x64)
- SUSE Enterprise Linux Server 11 SP1 (x32 and x64)
- FreeBSD 9.1 (x32/x64)
- Fedora core 18 (x64)
- UBuntu 12.04/12.10 (x64)
[^] # Re: Changer de distrib...
Posté par Kioob (site web personnel) . Évalué à 2.
Absolument pas. À vrai dire, je ne vois pas vraiment ce qu'apporterait une distribution différente ici : les problèmes sont rencontrés & remontés par le noyau, pas par un quelconque composant spécifique à la distrib.
De plus j'ai fait la plupart de mes tests depuis un noyau Vanilla 3.14.16, les noyaux Debian m'ont seulement servi à vérifier que le problème y était également présent.
Non ?
alf.life
[^] # Re: Changer de distrib...
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
Tout simplement parce que les distribs intègrent des patchs ou des drivers qui ne sont pas forcément upstream ou qui modifient sensiblement le comportement du noyau.
Que la Debian a une fâcheuse tendance a supprimer du support matériel sous prétexte de firmware non libre et autre joyeuseté.
Tu as testé avec un noyau vanilla ? C'est bien, mais sur du matos serveur, J'aurais quand même testé avec une Centos ou une Ubuntu LTS.
[^] # Re: Changer de distrib...
Posté par Zylabon . Évalué à 4. Dernière modification le 21 août 2014 à 01:54.
L'x32 c'est basiquement l'x86_64 (ou amd64, nom plus honnête historiquement) avec les adresses sur 32 bits, ce n'est pas l'IA-32 (x86, mais 32 bits).
Très cool, et très expérimental toujours.
https://en.wikipedia.org/wiki/X32_ABI
Please do not feed the trolls
[^] # Re: Changer de distrib...
Posté par Hugues Max . Évalué à -1.
Bonjour
intéressant ce serveur low cost. as tu une idée des perf ? est ce que les débits ne s'écroulent pas dès qu'il y a plusieurs utilisateurs ?
Hugues.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.