Lazer

Choix des composants

 

 

Processeur CPU

 

Dès le début de mes réflexions j'ai voulu partir sur l'architecture Zen 5 de chez AMD, et tout particulièrement les processeurs AMD EPYC 4005 Grado.

Leur force, c'est que pour le même prix que chez Intel, on a environ 2 fois plus de cœurs (utile pour la virtualisation, car plusieurs VM tournent en parallèle), et globalement 2 fois plus de performance.

Cependant j'ai abandonné cette idée, à cause de la consommation en idle de ces processeurs.
En effet, le point faible d'AMD à l'heure actuelle, c'est la consommation au repose, les processeurs ne sont pas capables de descendre aussi bas que les Xeon chez chez Intel.

Et sur un homelab, les serveurs sont la plupart du temps inactif, donc ça aurait pas une consommation élevée inutilement.

Je me suis donc tourné vers l'architecture Intel Xeon 6 sur socket LGA1700.

Et plus particulièrement sur la série Intel Xeon 6300 de la famille Raptor Lake-S Refresh.

Initialement je voulais prendre 3 processeurs identiques, mais je me suis dit que ce n'étais pas pertinent car j'ai 1 gros nœud (le NAS), et 2 nœuds secondaires, donc j'ai fait le choix d'équipe le 1er nœud d'un gros processeur, et les 2 autres d'un plus petit modèle, ce qui permet d'optimiser le cout mais aussi la consommation électrique :

• Nœud 1 NAS : Intel Xeon 6357P : 8 cœurs @ 3 GHz avec Hyperthreading - TDP 80W
• Nœuds 2 et 3 : Intel Xeon 6315P : 4 cœurs @ 2.8 GHz - TDP 55W

Point important à prendre en considération, pour mon cluster il faut prendre 3 processeurs de la même architecture, c'est à dire partageant le même jeu d'instructions.
Cela permet de déplacer une VM dynamiquement, à chaud, d'un nœud du cluster à un autre, sans arrêt/reboot de la VM.

Dans le cas présent, la seule différence entre les nœuds sera le nombre de cœurs (et leur vitesse) qui diffère, donc aucun problème de compatibilité.

 

Ces 3 processeurs ont été difficiles à trouver sur le marché, car ils sont normalement prévus pour les constructeurs OEM (tels que Supermicro, Lenovo, etc) qui les intègrent directement dans des configurations serveurs complètes.

J'ai finalement pu trouver sur une boutique en Pologne, et l'autre en Angleterre en passant par les Pays-Bas.

 

Comparé au processeur Intel Xeon E3-1265L V2 de mon micro-serveur HP Gen8 actuel, le gain de performance est significatif, pour ne pas dire énorme, que ce soit en multi comme en mono-thread, d'autant plus que j'aurai 3 machines prêtes à travailler simultanément dans le cluster :

 

 

 

 

 

Mémoire RAM

 

Pour le file-system ZFS qui sera utilisé dans TrueNAS, il faut de la RAM, beaucoup de RAM, car c'est sa capacité qui sert de cache disque, et donc augmente les performances.

Comme pour les CPU, il est inutile de mettre la même quantité de RAM sur les 3 noeuds, j'ai donc choisi d'optimiser comme suit ;

• Nœud 1 NAS : 2 barrettes de 32 Go = 64 Go
• Nœuds 2 et 3 : 1 barrette de 32 Go = 32 Go

Soit un total de 4 barrettes pour 128 Go de RAM, ce qui est plus que largement suffisant pour commencer, et je pourrai toujours doubler la capacité dans le futur si le besoin s'en fait sentir.
A ce propos, j'ai choix la plus grosse taille de barrette disponible pour cette architecture de processeur, à savoir 32 Go, justement pour laisser des slots DIMM disponibles pour une extension future. Ainsi fini la frustration des 16 Go max du vénérable HP Gen8.

 

La technologie imposée par Intel pour ces Xeon 6 est de la DDR5 à 4800 MHz au format Unbuffered UDIMM avec correction d'erreur ECC.

Plusieurs fabricants proposent (enfin... proposaient... c'était dans le monde d'avant, en 2025, avant le délire de l'IA et de sa pénurie mondiale de composants...), j'ai retenu la référence Micron MTC20C2085S1EC48BR.

 

 

Carte mère

 

Impératif pour mon projet, la présence d'un port réseau dédié au management à distance du serveur (Power ON, OFF, remote control, montage d'ISO virtuel, etc). Concrètement, c'est la présence d'une puce ASPEED AST2600 avec IPMI, qui est l'équivalent de l'ILO sur les serveurs HPE.

Ce qui élimine de facto toutes les cartes mères grand public, pour ne laisser que les gamme pro des fabricants, à destination des serveurs ou de certaines workstations.

Après avoir comparé différentes marques et modèles (Supermicro, MSI, Gigabyte, ...) j'ai finalement retenu ASRock Rack (c'est la gamme pro de ASRock) car les modèles proposés convenaient à mes besoins et étaient disponibles sur le marché européen.

Le choix du format a été dicté par le boitier (discuté ultérieurement) :

• Nœuds 1 NAS et 2 : ASRock Rack EC266D4U au format Micro-ATX
• Nœud 3 : ASRock Rack EC266D2I au format Mini-ITX

Je ne voulais pas de réseau 10 GbE intégré sur la carte mère, car c'est systématiquement au format cuivre RJ45, et comme expliqué précédemment sur l'architecture réseau, la consommation électrique, et la chauffe, sont trop importantes.

J'ai donc choisi des modèles avec uniquement des ports RJ45 1 GbE classiques, qui serviront pour l'administration, et pour les VM à faible traffic réseau sur les nœuds 2 et 3 (en dehors du NAS donc)

 

Avantage de la carte Mini-ITX, elle dispose d'une entrée DC-IN 12V permettant de l'alimenter directement en courant continu 12V depuis ma batterie, sans passer par une alimentation ATX.

 

Les autres critères de choix ont été le nombre et les vitesse des ports PCI-Express pour les cartes d'extension, M.2 pour le SSD NVMe de boot, et OCuLink pour le SSD de datastore et autres extensions futures.

 

Boitier

 

J'ai cherché des boitiers à monter en rack 19", on trouve quelques fabricants sur le marché, certains Américains ou Chinois qui sont plus ou moins difficiles à trouver en Europe, et c'est finalement sur SilverStone Technology que j'ai arrêté mon choix, car ils proposent un catalogue très large de modèles répondant à tous les besoins en terme de hauteur (U), de profondeur, mais aussi de disposition interne (plutôt orienté Stockage, GPU, Calcul, etc... selon les besoins)

 

J'avais un impératif de limiter la profondeur à 50 cm pour rester sur un rack faible profondeur de 60 cm, et éviter de devoir utiliser un rack serveur pleine profondeur de plus de 1m comme on trouve dans les datacenters.

Au final j'ai fait le choix suivant :

• Nœud 1 NAS : SilverStone RM41-H08 d'une hauteur de 4U qui accepte des cartes mères jusqu'au format ATX.
  • Fourni de base avec une cage hot-swap pour 5 disques durs, et complété avec une cage SilverStone FS305-12G pour ajouter 5 disques durs supplémentaires, soit un total de 10 disques durs 3.5" hot-swap.
• Nœud 2 : SilverStone RM23-502-MINI d'une hauteur de 2U qui accepte des cartes mères jusqu'au format Micro-ATX.

Et pour le 3ème nœud, celui qui sera déporté dans la maison, j'ai trouvé, non sans mal, un boitier parfait pour cet usage, ultra compact, dont le volume est 2 à 3 fois inférieur au micro-server HP Gen8 :

• Nœud 3 : Jonsbo NV10 Black au format Mini-ITX

 

Ventirad

 

J'ai choisi les ventirads en fonction de l'espace disponible dans chaque boitier pour optimiser le flux d'air et donc le refroidissement, avec une forte préférence pour les ventilateurs Noctua pour leur silence, leur durabilité, et leur faible consommation (même si ça ne se joue qu'à 1 Watt près)

• Boitier SilverStone 4U : Noctua NH-U9S
• Boitier SilverStone 2U : Silverstone AR09-1700
  • Ventilateur SilverStone d'origine remplacé par un Noctua NF-A6x25 PWM pour le silence
• Boitier Jonsbo Mini-ITX : Noctua NH-L9i-17xx chromax.black

 

Ventilateur

 

J'ai remplacé les ventilateurs d'origine des boitiers SilverStone car trop bruyant, même à faible vitesse.

Et j'ai ajouté des ventilateurs dans les emplacements disponibles.
La logique dans les boitiers serveurs est la même que dans tous les PC que j'ai monté depuis des années : plus il y a de ventilateurs, qui tournent à faible vitesse, mieux c'est pour le flux d'air et donc le refroidissement, mais aussi pour le bruit plus faible.

J'ai choisi exclusivement la marque Noctua :

• Boitiers SilverStone 2U et 4U :
  • Noctua NF-A8 PWM chromax.black.swap
  • Noctua NF-A8 PWM
• Cages disques hotswap :
  • Noctua NF-R8 redux-1200
• Boitier Jonsbo Mini-ITX :
  • Noctua NF-A4x10 PWM

 

 

SSD

 

Impératif pour mon projet, à cause de l'utilisation de CEPH qui réalise des écritures permanente sur les disques même sans activité, il me faut des SSD de classe enterprise, car disposant de la fonctionnalité PLP (Power Loss Protection). Cela élimine tous les SSD grand public, et donc logiquement ceux qui ont la mention "pro" dans leur désignation commerciale, coucou Samsung 

 

J'ai étudié différentes marques, Kingston, Micron, Solidigm (ex-Intel), Kioxia (ex-Toshiba), Sandisk, Seagate, Samsung (oui oui ils ont bien une gamme enterprise, donc non-professionnelle  ), sachant qu'il me faut au minimum 2 SSD par serveur :

• 1 SSD NVMe au format M.2 à installer directement sur la carte mère pour le boot et l’installation de Promox.
• 1 SSD NMVe au format 2.5" à installer dans le boitier pour l'OSD de CEPH qui servira de datastore répliqué pour les VM.

J'ai éliminé les SSD utilisant le protocole SATA (pourtant ça existe dans les gamme Enterprise avec PLP), car je cherche avant tout la performance et surtout la très faible latence, et seul le protocole NVMe, directement sur bus PCIe, permet cela.

Au final, un peu comme pour la RAM, c'est la disponibilité des composants en fin d'année 2025 et les tarifs qui commençaient tout juste à s'envoler qui a dicté mon choix, notamment j'ai eu les 2 derniers Kingston disponible, donc j'ai ajouté un Micro pour compléter les 3 disques de boot :

• Boot Nœud 1 : Micron 7450 Pro MTFDKBA480TFR-1BC1ZABYY de 480 Go au format M.2 sur bus PCIe 4.0 x4
  • Complété par un dissipateur be quiet ! MC1 Pro

• Boot Nœuds 2 et 3 : Kingston DC2000B SEDC2000BM8/480G de 480 Go au format M.2 sur bus PCIe 4.0 x

  • Avec dissipateur intégré

     

Pour les 3 disques OSD pour CEPH, j'ai trouvé le même modèle :

• OSD CEPH pour les 3 nœuds : Micron 7500 Pro MTFDKCC1T9TGP-1BK1DABYY de 1.92 To au format U.3 sur bus PCIe 4.0 x4

Celui-là, c'est un monstre de performance et de fiabilité : garantie 5 ans, DWPD = 1 soit un TBW de 3504 To, dit autrement on peut écrire la totalité de sa capacité (1.92 To) chaque jour dessus pendant les 5 ans de garantie.

La consommation électrique en revanche fait mal, 5W en idle, et 12.6W en pointe.

L'imposant radiateur qui lui sert de carcasse annonce la couleur 

 

J'ai également ajouté des SSD SATA dans le nœud 1 NAS comme je l'avais expliqué précédemment :

• 3 x Samsung SSD 870 EVO SATA 2,5'' 4 To
  • Pool local Proxmox
  • VM TrueNAS : System Dataset
  • VM Synology : Surveillance Station

Pour connecter les SSD Micron au format U.3 sur les ports OCuLink de chaque carte mère, j'ai utilisé des câbles adaptateurs Oculink SFF-8611 U.2 SFF-8639 trouvés sur Aliexpress, qui se repiquent sur une alimentation SATA pour alimenter le SSD U.3 de la même façon qu'on alimenterait un SSD SATA 2.5" traditionnel :

 

Carte réseau Ethernet

 

Je l'ai expliqué précédemment, je veux des cartes réseau 10Gbit/s avec slot SFP+ pour y brancher des câbles DAC, évitant ainsi les ports RJ45.

La plupart des forums recommandent les cartes Mellanox pour leur faible coût, mais j'ai préféré éviter à cause de leur consommation électrique importante, en effet ce sont de vieilles technologies.

 

J'ai retenu les cartes Intel X710, ce n'est pas la toute dernière génération, mais c'est celle qui présente la consommation électrique la plus faible.

• Nœud 1 NAS : Intel X710-DA4 avec 4 ports SFP+ PCIe 3.0 x8
• Nœuds 2 et 3 : Intel X710-DA2 avec 2 ports SFP+ PCIe 3.0 x8

Je n'ai pas acheté les Intel originales car le coût est trop important pour une valeur ajoutée que j'ai estimé nulle.
Sur Aliexpress on trouve des clones pour une fraction du prix, surtout avec les promos du Black Friday.

C'est le chipset X710 original de chez Intel, avec un clone du PCB, d'apparence, et fonctionnellement, elles sont identiques aux originales.

 

 

 

  

Carte HBA SAS

 

Elle est nécessaire pour connecter tous les disques durs à la VM TrueNAS sur le nœud 1 NAS.

Ce n'est pas une carte contrôleur RAID, c'est uniquement une HBA (Host Bus Adapter), c'est à dire qu'elle présente les disques durs (ou SSD) tels quels au serveur.

Elle supporte le hot-plug, ce qui s'accorde parfaitement avec les cages hot-plug à l'avant du boitier SilverStone.

Sur bus PCI-Express, elle peut-être affectée en Passtrough PCI à la VM TrueNAS, ce qui est nécessaire pour les performances, mais aussi pour que ZFS puisse accéder directement aux données SMART de chaque disque.

Note : ce n'est pas comme le mapping RDM de VMware, là c'est du vrai PCI Passtrough, c'est à dire que la VM à un accès direct à la carte et donc aux disques, et l'hyperviseur (Promox ici, comme le serait ESXi) ne voit pas du tout les disques durs.

 

J'ai choisi le modèle suivant car c'est celui proposant la plus petite consommation électrique, notamment elle supporte l'ASPM ce qui permet de mettre le bus PCIe en veille et au processeur de descendre les C-States.

• Broadcom 9500-8i avec 8 ports SATA/SAS internes avec chip SAS3808 sur bus PCIe 4.0 x8

On constate qu'il n'y a que 8 ports alors que j'ai 10 emplacements disques, car le modèle 9500-16i était introuvable à prix descend, j'ai donc fait le choix du partir sur le modèle 8i car ça me suffit pour l'instant, on verra dans le futur pour la remplacer quand je trouverai la 16i à prix correct.

Cela dit, comme pour les carte réseaux Intel, je n'ai pas pris la carte Broadcom originale qui est hors de prix, j'ai chois un clone (même chipset, clone du PCB) sur Aliexpress.

 

Le site de Broadcom liste les câbles internes à utiliser selon ce qu'on veut brancher sur la carte, pour mon besoin j'ai utilisé un câble SlimSAS SFF-8654 to 8x SATA également trouvé sur Aliexpress pour une bouchée de pain.

 

Alimentation

 

Comme expliqué précédemment, les 2 nœuds en boitier SilverStone pour rack 19" sont alimentés par le secteur 230V, il faut donc utiliser une alimentation ATX standard.
Mon objectif ici est de trouver l'alimentation avec le meilleur rendement possible, afin de minimiser les pertes de conversion, et donc d'énergie perdue.

 

Je me suis d'abord intéressé au document suivant :

• PSU Low Idle Efficiency Database by Wolfgang's Channel

Cependant, les meilleurs alimentations, les Seasonic Prime Titanium sont devenues introuvables (ou alors à des tarifs délirants), et la Corsair RM550x n'est plus fabriquée depuis longtemps.

 

J'ai ensuite cherché sur le site de Cybenetics qui teste toutes les alimentations, et en particulier le tableau suivant :

• Cybenetics PSU Performance Database

Qu'il faut classer par la colonne : Average Efficiency (20-80W) [%]

Car c'est dans cette plage de puissance que les serveurs se situeront l'immense majorité du temps.

 

J'ai donc choisi l'alimentation suivante pour chacun des 2 boitiers rackables :

• Cooler Master MWE Gold 750 V3 ATX 3.1

Contre toute attente, car c'est une alimentation certifiée seulement Gold, alors qu'on pourrait penser qu'il faut impérativement choisir des alimentation Titanium au minimum.

Mais le truc, c'est que les serveurs vont travailler dans une plage de puissance très faible, c'est donc là tout l'intérêt du tableau cité au-dessus, de pouvoir filtrer sur la plage 20-80W.

Le rapport Cybernetics complet pour cette alimentation confirme d'ailleurs les rendements dans les puissances les plus faibles, dans la section Light Load Tests :

 

 

En plus cette alimentation a le bon goût d'être certifiée ATX 3.1, et même si ça ne m'est d'aucune utilité pour mes serveurs (pas de grosse carte graphique qui risque de prendre feu), c'est toujours bon à prendre.

 

En ce qui concerne l'alimentation à courant continu 12V DC du boitier Jonsbo Mini-ITX, je ferai un post dédié plus loin.

 

Non, plus de détection du tout, on a des horaires/présence beaucoup moins variables qu'avant, il y a quasiment toujours quelqu'un à la maison.

Et de toute façon depuis que j'ai 2xPAC+PV+Batterie je me suis rendu compte que ça ne servait à rien de trop optimiser les scénarios chauffage, je suis maintenant sur une gestion beaucoup plus continue, les PAC ont un meilleur rendement en fonctionnement continu, et la consommation a baissé.

Euh..... bonne question 

Je suis désolé mais je n'utilise plus du tout la détection de présence Unifi, donc je ne sais pas si ça fonctionne encore....

Soit je n'ai pas bien compris ce que tu cherches, soit.... c'est tout simple

 

Il faut rechercher les devices de type com.fibaro.multiPositionSwitch :

 

/api/devices?type=com.fibaro.multiPositionSwitch

 

Et donc vérifier le type du module dans son JSON :

 

 

 

 

C'est pareil

 

Apparemment il y aurait une rétrocompatibilité, les nouveaux modules en 800 MHz seraient également capables de fonctionner sur le réseau 2.4 GHz, ce qui garde la compatibilité avec les contrôleurs existants mais aussi les modules existant en cas d'association directe (binding).

Donc pour les utilisateurs existants, il faudrait juste changer l'antenne / le contrôleur de la box domotique pour pouvoir profiter des nouveaux modules sur le réseau 800 MHz.

Et ainsi conserver ses anciens modules 2.4 GHz.

La couche logicielle reste la même quand même, donc pour les constructeurs de box, logiciel domotique et modules, le passage à la nouvelle puce est transparent. Pas de nouveaux cours de développement.

 

Le seul vrai problème, c'est pour l'utilisateur existant.

Après la domotique reste un domaine encore assez confidentiel, si demain le grand public se lance enfin dans la domotique, cette fois-ci Zigbee pourra répondre à la demande sur des installations neuves de façon plus fiable qu'avant (je ne vois pas Madame Michu configurer manuellement ses canaux Wi-Fi pour ne pas interférer avec Zigbee 2.4 GHz).

C'est à peu près sûr maintenant

 

Non effectivement rétro-compatibilité impossible, pas de mise à jour logicielle, il faut du nouveau hardware (puce, antenne adaptée à la longueur d'onde)

C'est presque un nouveau protocole en fait.

Alors celle-là, je ne l'avais pas vu venir, et c'est plutôt une bonne nouvelle, qui devrait enfin permettre au Zigbee de fonctionner correctement :

 

[Domo-blog] Zigbee 4.0 : La fin de la bande 2,4 GHz et le futur de la domotique

 

Citation

Le protocole Zigbee entame sa plus grande révolution. Avec l’arrivée de la version Zigbee 4.0, la Connectivity Standards Alliance (CSA) s’attaque au plus gros point faible de la maison connectée : l’encombrement de la bande de fréquences 2,4 GHz sur laquelle le protocole Zigbee dialogue, lui aussi. Mais un changement s’amorce avec la quatrième génération du Zigbee. Voici pourquoi Zigbee 4.0 pourrait bien gagner la “guerre des protocoles” ou du moins très bien se positionner pour l’avenir de la domotique.

 

...

 

Welcome to the forum

 

Ici ça ne sera pas que pour secourir mon accès Internet (pour lequel de la 5G suffit en dépannage), mais aussi pour un serveur Web.... pour le coup c'est limite et les performances risque d'être dégradées dans ce cas... après ça dépend aussi du trafic, donc à tester.

 

Je me souviens de ma 1ère connexion itinérante en plein milieu de la brousse en Afrique du Sud, j'avais une connexion GPRS (c'était de la 2G, avant le EDGE) sur mon téléphone, que j'avais connecté à mon PC portable par une liaison infrarouge, donc il ne fallait surtout pas bouger le téléphone, et j'arrivais tout juste à me connecter à ma messagerie pour envoyer quelques emails. C'était épique. Et pas du tout nickel !

La technologie a bien évolué

 

Oui, le moment parfait pour envoyer du jour rouge

 

Voilà, c'est bien ça le problème, 25-30 ms c'est énorme, ce n'est pas du tout "nickel".

En comparaison, la fibre optique, ça tourne entre 1 et 2 ms, il n'y a pas un rapport x10 comme je le disais, mais encore plus 

 

Après peut être que ça suffit pour tes besoins, et c'est tant mieux, mais si 35-30 ms est dans la moyenne d'une connexion 5G, dans l'absolu ça reste simplement mauvais.

 

Chez moi je mesure :

• Fibre Bouygues : entre 1 et 2 ms
• 5G Bouygues : entre 33 et 51 ms... la moyenne est à 41,5 ms.

Mon antenne est mal positionnés, il faudrait que je la déporte au grenier, ça améliorerai le signal, et donc le débit et peut être aussi la latence. Il faudrait que je fasse le test à l'occasion, mais ce qui m'embête c'est pour l'été, car ça chauffe fort sous les tuiles. En tout cas j'y avais déjà prévu l'arrivée d'un câble réseau depuis des années, qui ne sert à rien pour l'instant.

C'est pas tellement le réseau de l'opérateur le problème, c'est la technologie radio.
4G, 5G ou Wi-Fi, même combat, les latences restent dans tous les cas 10x supérieures à une connexion câblée (Ethernet, Fibre optique, peu importe finalement)

Tu ne peux juste pas dire "c'est nickel" sans le chiffrer

 

Après je dois parler chinois, car partout, sur les sites de presse en ligne (enfin, si on peut appeler ça de la presse...), les forums, etc, les gens ne comprennent que la bande passante.
La latence ça reste un truc encore largement incompris, et pourtant c'est crucial.
ça me rappelle beaucoup la course aux MHz / GHz des processeurs, dans l'ancien temps !

C'était avec l'ADSL que c'était catastrophique... Le moindre coup de vent sur les poteaux et ça coupait...

Mais oui la fibre n'est pas infaillible non plus, c'est pour ça que j'ai pris le backup 5G.

 

Mais pour le coup, il y a un nombre incroyable de déconnexions sur la 5G, ce n'est pas du tout la stabilité de la fibre.
Et la latence aussi, c'est tout pourri.

C'est vraiment du secours.

 

C'est super bien foutu l'écosystème UniFi, la configuration est ultra simple.

En plus alimenté directement en POE sur un port de la Gateway, donc ça supprimer un SPOF, pas besoin de switch/injecteur POE.

 

 

 

 

 

La 4G ? C'est dépassé, place à la 5G maintenant

 

Je n'ai déjà plus de box, j'en avais parlé dès la 1ère page en présentant mon architecture réseau, j'ai uniquement un ONT directement branché sur le routeur.

Depuis que je suis passé chez Bouygues Telecom, et c'est la bonne surprise à laquelle je ne m'attendais pas du tout, leur réseau est plus fiable que celui de Free, je n'ai jamais de déconnexion de la fibre, alors que ça arrivait de temps en temps avec la Freebox. Comme quoi, l'opérateur des geeks n'est pas toujours le plus fiable.

Après, c'est le routeur UniFi qui peut planter... ou simplement recevoir des mises à jour, ce qui arrive régulièrement.

 

Le truc, c'est que le seul moyen de vraiment sécuriser l'accès Internet, c'est de mettre en oeuvre l'usine à gaz dont j'ai partagé le schéma quelques posts plus haut.... dans mon cas, ce n'est pas là que se situent les pannes, c'est pour ça que j'ai accentué les efforts sur la mise en place d'un cluster, la réplication des données, le réseau interne, les alimentations électrique.

Après 13 ans de fonctionnement 24/7/365 de mes serveurs à la maison, je commence à avoir une petite expérience des problèmes les plus souvent rencontrés. C'est ce qu'il faut traiter en priorité.

Comme je dis souvent, le jour où je serai inondé, Montmartre aura des airs de Mt St Michel au milieu de la mer, donc j'ai de la marge

 

Et justement, ce "village" d'à coté est légèrement inaccessible niveaux prix

 

EDIT : en fait je viens de calculer, c'est encore pire que ça, Montmartre ne sera même plus une ile, seul le Sacré Coeur dépassera encore !

 

Oui passer plusieurs brins de fibres, et doubler tous les équipements réseaux, switchs, y compris le (enfin "les" du coup) routeurs.
Unifi permet de faire cela, mais le coût explose. C'est pas juste x2, car il faut en plus prendre les modèles compatibles VRRP.

Et ne parlons même pas de la consommation électrique...

 

[UniFi] Gateway High Availability & Failover
(Shadow Mode / VRRP)

 

Si on pousse la logique, même la connexion 5G de secours ce n'est pas viable, car l'antenne relai dépend de l'alimentation électrique du secteur. Et aussi du réseau backbone de l'opérateur français.
Non franchement ce n'est pas assez fiable, du coup il faut ajouter 2 antennes satellites, une sur SpaceX, et l'autre sur Amazon.

Et puis ce qui serait bien aussi, c'est de faire un géocluster avec bascule automatique sur un autre site situé à plusieurs kilomètres.

 

 

Franchement, si la maison brule, j'aurai d'autres priorités que 2 ou 3 sites Web.... comme je disais, dans ce cas totalement extrême, si les données sont sauvegardées hors-site, alors rien n'est perdu, je suis capable de les restaurer (mes documents, photos, etc).
Dans ce cas, le forum, il repartira en ligne chez OVH, c'est vite fait. Et puis bon, au final, l'histoire a montré que ça brule plus souvent chez OVH que chez moi 

 

 

Ben comme dit, même si je pouvais la passer (en remplacement du Grade 3s), la fibre optique ne résout pas le problème de la connexion unique, des équipements actifs aux extrémités, et de toute façon à la connexion Internet unique, qui passe par la maison.

La meilleure solution (ou la moins pire selon le point de vue), et de loin, ce sont les 3 serveurs du cluster dans la maison, comme je l'ai fait.

 

Et même si le feu n'était circonscrit qu'à la cave (par je ne sais quel miracle), la connexion Internet arrive aussi par là.
Et, et puis toute l'installation électrique aussi.... donc il faut vraiment prendre la vue d'ensemble pour identifier les SPOF, de mon coté je ne pinaille pas justement, j'estime avoir vraiment fait le max de ce qu'il est possible dans mon environnement domestique.

 

Ah pendant qu'on parle connexion Internet, j'ai entre temps acheté le routeur 5G Unifi, alors même si je peux le déporter au garage, son fonctionnement dépend du routeur (Unifi Cloud Gateway Fiber), qui est... dans la maison !

Retour à la case départ.

 

Voir le schéma de la page précédente, la sauvegarde sera dans le garage. C'est le PRA en fait (plan de reprise d'activité).

 

En fait, déporter un des 3 noeuds du cluster dans le garage est physiquement impossible, car je n'ai qu'un câble réseau Grade 3s entre les 2 bâtiments, que j'avais déjà eu un mal fou à passer dans la gaine en remplacement d'un vieux câble téléphonique.

Impossible dans ces conditions d'y passer les 2 câbles DAC nécessaires pour le réseau CEPH full-mesh.

Et si ça avait été possible, vue la distance, je n'aurais pas pu passer de câble DAC, il aurait fallu passer à la fibre optique, et là c'est plus tout à fait le même budget. Encore que, sur un projet pareil, ça serait presque un détail !

 

Et donc, pourquoi ne pas faire passer le réseau CEPH dans un VLAN isolé du câble Grade 3s existant ?
Techniquement, ça fonctionne, mais comme décrit longuement dans mon architecture, ça introduirait alors un goulot d'étranglement, et surtout plein de SPOF (single point of faillure) : le câble lui-même, chaque switchs aux extrémités (bug, mise à jour des firmware, alimentations uniques, etc), ah et aussi de la latence supplémentaire.
Bref, tout ce que je cherche justement à éviter, puisque mon objectif premier reste la résilience de cette infrastructure.

 

Si la maison brule, de toute façon, l'accès fibre optique aussi, donc je n'ai que faire d'un cluster qui survit tout seul au garage.

Après, si la maison brule, j'aurais d'autres priorité que de maintenir un site Web en ligne.... mais au moins, avec les sauvegardes, je n'aurais pas perdu les données, que je pourrai toujours retrouver le moment venu.

Et puis de toute façon, si 2 noeuds dans la maison brulent, alors le noeud du garage va s'arrêter proprement, donc c'est pas 2 bâtiments qu'il faut, mais 3 !

 

Ce dernier point est loin d'être un détail, j'ai la majorité de mes clients qui ont des beaux clusters, en mettant le 3ème nœud / quorum / témoin (witness) dans la salle, voire même le rack, de l'un des 2 noeuds principaux. Donc la résilience, elle est toute relative... bon heureusement ça brule rarement (mais ça arrive)

C'est un Hotfix de la précédente Beta, donc pas vraiment de nouveautés.

 

 

Architecture matérielle

 

 

Configuration des nœuds du cluster

 

Les 3 nœuds n'auront pas la même configuration matérielle, même si l'architecture sera la même afin de permettre une migration des VM et applications entre chacun des 3 nœuds.

A ce sujet, il est essentiel d'utiliser des processeurs de la même famille (= même jeu d'instructions) afin de permettre aux VM qui s'exécutent sur un noeud de pouvoir migrer à chaud d'un serveur à un autre. Sans cela, la migration à chaud est impossible et doit se faire à froid, afin qu'au redémarrage la VM découvre le jeu d'instruction du serveur cible et s'adapte en conséquence.

 

Comme mon cahier des charges est de monter une infrastructure la plus résiliente possible, j'ai fait le choix de m'orienter vers des composants "professionnels", à savoir pas des produits issus du monde grand public qu'on trouve dans les PC classiques.

Je sais que plein de personnes montent des serveurs avec des composants grands publics et que ça fonctionne très bien, mais quand on creuse le sujet (sur les forums spécialisés Reddit, etc) on s'aperçoit qu'il y a toujours un moment où c'est instable, ça plante, ou bien qu'il faut remplacer un composant de manière prématurée.

Je le disais, je cible au moins 15 ans de durée de vie pour ce système, pas question que ça lâche avant.

En réalité, dans le langage marketing moderne, ce n'est pas le terme "pro" que je devrais utiliser, mais "entreprise". Tant pis pour l'abus de langage.

 

Surtout, j'ai besoin de certaines caractéristiques des composants pro pour le bon fonctionnement de mon système.

En vrac :

• une interface IPMI sur la carte mère pour la gestion à distance (équivalent ILO, iDRAC, IMM2, etc)
• de la RAM ECC pour la correction d'erreur, particulièrement pour TrueNAS qui utilise massivement la RAM comme cache disque pour les performances
• des SSD avec PLP intégré (Power Loss Protection), totalement indispensable pour CEPH
• une connectivité réseau 10 Gb/s pour la réplication CEPH

J'ai longtemps voulu partir sur des processeurs AMD EPYC 4005 Grado (architecture Xen5), cependant j'ai renoncé à cause de la consommation élevée au repos (en idle) de ces processeurs.

Je suis donc revenu au classique choix Intel Xeon 6, qui permet des optimisations poussées pour descendre assez bas.

Il s'agit avant tout d'un homelab, qui aura une très faible activité la majeure partie du temps, donc j'ai privilégié le choix raisonnable de la consommation électrique réduite.
C'est dommage d'un point de vue performance, car pour le même prix on a quasiment 2 fois plus de performances chez AMD, de son coté Intel est clairement à la traine.

 

Le 1er nœud, qui portera la VM TrueNAS, sera le mieux équipé.
Les 2 autres nœuds seront moins richement dotés, ce qui permet de réduire la facture d'achat, et déjà plus que suffisant pour mes besoins actuels (et même surdimensionné...). Mais si le besoin s'en fait sentir plus tard, je pourrai toujours faire évoluer leur configuration (ajout de RAM, stockage, etc... voire remplacement du CPU).

• Nœud n°1 : NAS
  • Gros boitier rackable 19"
  • Gros CPU
  • RAM 32 Go
  • Carte SAS pour connecter tous les disques durs
• Nœud n°2
  • Petit boitier rackable 19"
  • Petit CPU
  • RAM 16 Go
• Nœud n°3
  • Boitier Mini-ITX
  • Petit CPU
  • RAM 16 Go

Comme on le constate, les 2 premiers nœuds seront en boiter rackables 19", destinés à être installés à la cave dans un futur rack à venir.

Tandis que le 3ème nœud dans un boitier compact au format Mini-ITX, l'objectif étant de le déporter au rez-de-chaussée, dans le placard qui héberge actuellement mon Micro-serveur Gen8. En effet, j'ai besoin d'y connecter une antenne EnOcean en USB car j'ai encore quelques modules utilisant ce protocole. Demain, si je déploie du Home Assistant, je pourrai également y connecter une antenne Z-Wave, Zigbee, Thread, Whatever... sauf si j'utilise une antenne déportée Ethernet POE, mais en tout cas je en serai pas embêté par la portée radio.

 

 

 

Réseau

 

 

 

Chaque carte mère dispose de 2 connexions 1 Gbit/s sur ports RJ45.

Je vais ajouter en plus une carte d’extension PCIe à 10 Gbit/s sur chaque nœud, avec slot SFP afin d'y brancher des câbles DAC.

J'ai déjà expliqué que j'évite le 10 Gb sur port RJ45 à cause de la consommation et donc de la chauffe très importante.

L'utilisation de câbles DAC est bien plus efficient d'un point de vue énergétique, mais aussi financier (si le câble DAC coute plus cher que le câble RJ45 Cat 6a, le gros gain se fait sur le coût des ports coté serveur et coté switch).

En plus, le câble DAC est la solution présentant la plus faible latence, et cet aspect est particulièrement important pour les performances de mon réseau de réplication CEPH, car chaque écriture d'une VM sur un nœud ne sera acquitté que lorsque l'ensemble des 3 nœuds auront validé l'écriture sur leur SSD local.

J'ai même pensé à utiliser du 25 Gbit/s, pas tant pour le débit, que pour la latence encore plus faible, mais d'une part je n'ai pas trouvé de prix intéressant, et d'autre part ça aurait augmenté la consommation électrique. On verra dans le futur si l'utilisation de 25G s'avère nécessaire, je pourrai toujours remplacer les cartes PCIe.

 

Pour économiser un peu, et puisque je n'ai pas besoin de 10G pour les VM des nœuds 2 et 3, celles-ci utiliseront le réseau 1G pour la connectivité externe.

Le nœud TrueNAS, lui, a besoin de connectivité rapide pour les échanges de gros fichiers, donc du 10G pour ne plus être bridé par ma connexion interne fibrée de 8 Gbit/s (même si je suis bridé à 5 Gbit/s réels par mon routeur avec IDS/IPS activité)

 

Donc pour chaque nœud, j'ajoute la carte 10G suivante :

• Nœud n°1 : 4 x 10 Gbit/s
• Nœud n°2 : 2 x 10 Gbit/s
• Nœud n°3 : 2 x 10 Gbit/s

 

Le réseau CEPH entre les 3 nœuds sera de type Full Mesh, c'est à dire que chaque nœud communique avec son voisin en connexion directe point à point, sans passer par les switchs.

Cette architecture est absolument critique pour la haute disponibilité du cluster dans mon projet, car sinon un reboot du switch (par exemple lors d'une mise à jour de firmware) ferait tomber l'ensemble du cluster en quelques secondes.

En outre, cette connexion point à point permet également de gagner de précieuses micro-secondes de latence, comme évoqué précédemment pour la réplication.

Enfin, cela permet d'économiser des ports coté switch, donc réduit très significativement la facture, et permet également de grappiller encore quelques watts de consommation électrique.

 

Sur le nœud hébergeant TrueNAS, les 2 ports 10 G seront agrégés en LACP, non pas que ça soit indispensable, mais puisque j'aurai 2 ports disponibles, autant les utiliser. En outre, cela apportera de la redondance entre les 2 liens, même si à l'extrémité ce sera connecté au même switch.

 

Le 1er port RJ45 de chaque nœud sera dédié au management du cluster, ainsi qu'au réseau Corosync, qui permet au cluster Proxmox de communiquer (détection des pannes entre nœuds du cluster). Comme il n'y aura pas de traffic VM sur cette interface, peu de chance de saturer le lien et donc de faire tomber ce lien Corrosync.
Le 2nd lien Corosync sera lui sur le même réseau Full-Mesh que CEPH, là encore pour s'affranchir d'une indisponibilité du switch qui ferait tomber le cluster Proxmox (il y a 2 clusters en fait dans mon infrastructure, celui de Proxmox, et celui de CEPH).

 

Selon le nœud, les 2 liens 10G LACP ou le 2nd lien 1G RJ45 seront utilisés pour le bridge portant le traffic des VM, avec les différents VLANs taggués (DMZ, etc)

 

Une dernière remarque sur les câbles DAC, on est limité à une distance maximal de 3m avec un câble passif (au delà il faut passer sur du câble actif, c'est à dire avec fibre optique et conversion/amplification aux extrémités, c'est couteux et consommateur).

Cela ne pose pas de souci, les 2 serveurs dans le rack seront connectés avec un câble DAC court de 50cm, tandis que le nœud 3 situé à l'étage juste au dessus sera interconnecté avec des câbles de 3m.

 

Note : la connexion d'administration IPMI 1G RJ45 dédié sur la carte mère n'est pas représentée sur le schéma car n'entrant pas dans le fonctionnement du cluster, il n'y a pas de transfert de données dessus.

 

 

 

Stockage

 

Je l'ai dit précédemment, les SSD seront de type pro (ou plutôt enterprise), c'est à dire qu'ils doivent disposer de la fonctionnalité PLP (= Power Loss Protection) qui sont des petits condensateurs embarqués dans le PCB, à coté du contrôleur et des puces de Flash, pour secourir la mémoire tampon en cas de panne d'alimentation, pour prévenir toute perte de données qui ne seraient pas encore physiquement écrites sur les puces Flash NAND, ce qui entraine inévitablement une corruption des données lors du redémarrage.

Ce point est essentiel pour CEPH, qui réalise toutes ses écritures en mode synchrone (flag O_SYNC) pour garantir la cohérence des données écrites (rappel : recherche de la fiabilité ultime).

 

Sans PLP, donc avec un SSD grand public (y compris les modèles commercialement estampillés "Pro" de Samsung  ), le SSD désactive son cache en écriture et il se passe alors 2 choses :

• Effondrement des performances : on parle potentiellement d'un rapport 10 à 100 selon le profil I/O.
• Usure prématurée : le wear-leveling étant désactivé par l'absence de cache en écriture, les cellules TLC ou QLC s'usent d'autant plus vite. Sur les forums, j'ai vu des gens dont les SSD grand publics utilisés avec CEPH sont morts en quelques semaines à quelques mois, 1 an tout au plus. Donc quand je vois des tutos sur des blogs ou chaines YouTube qui expliquent comment monter un cluster CEPH avec des SSD à pas cher, ça me fait doucement rigoler, ou ça m'attriste c'est selon, car ça démontre bien qu'au delà de la démonstration, ils n'ont pas dû l'utiliser bien longtemps leur cluster... A noter que même sans activité des VM, CEPH écrit en permanence des logs sur les SSD, ce qui les use même sans activité, simplement en restant allumés !

Donc chaque serveur disposera de 2 SSD entreprise avec PLP :

• NMVe M.2 de 480 Go sur carte mère : boot Proxmox et Monitor CEPH
• NVMe U.3 de 1.9 To sur port Oculink PCIe x4 : disque OSD pour CEPH et DB/WAL

En plus, le gros nœud 1 dédié au NAS disposera de 3 autres SSD SATA grand public classiques de 4 To chacun :

• Pool local Proxmox pour les VM qui n'ont pas besoin de la haute dispo apportée par CEPH
• System Dataset pour TrueNAS : permet à TrueNAS d'écrire ses logs sur ce SSD et ainsi de permettre aux disques durs mécaniques de rester en veille prolongée, ce qui réduira significativement la consommation électrique de ce serveur (compter 5W par disque en rotation sans activité, multiplié par les nombre de disques, ça fait vite pas mal...)
• VM Synology : pour Surveillance Station. Alors certes un SSD pour de l'enregistrement vidéo c'est luxueux, mais j'ai réussi à en avoir un pour pas trop cher et ça consommera beaucoup moins qu'un disque dur dédié à cet usage

 

la VM TrueNAS disposera d'une carte PCIe de type HBA (= Host Bus Adapter), c'est à dire sans fonctionnalités RAID intégrée, affectée en PCI Passtrough.

L'objectif étant que TrueNAS, et plus particulièrement ZFS, puisse disposer d'un accès direct aux disques durs (informations SMART, etc), pour gérer le RAID logiciel avec un Pool en RAIDZ2, c'est à dire protégeant contre la perte de 2 disques. C'est important, car avec 1 seule protection, le risque est grand de perdre un second disque pendant la reconstruction, surtout avec des disques capacitifs de 24 To.

 

 

 

Alimentation électrique

 

Il est inutile d'avoir un cluster haute-dispo à 3 nœuds si une simple panne d'alimentation électrique vient tout casser.
 

J'ai donc réfléchi à une solution pour apporter de la redondance électrique.

Bien sûr, il est possible de trouver des alimentions ATX redondantes, mais ce n'est pas l'approche que j'ai retenu car :

• Couteux
• Choix limité de modèles
• Double alimentation dans le même format standard ATX, donc ventilateurs plus petits et donc bruit important
• Pas de solution existante pour mon boitier Mini-ITX déjà ultra compact

 

Quand j'ai mis en place ma batterie de stockage solaire, j'avais anticipé la possibilité d'utiliser le réseau 48 V à courant continu, directement câblé sur la batterie elle-même.

J'ai déjà convertisseur DC-DC 48V vers 12V pour un détecteur de fumée, je vais donc ajouter un autre convertisseur Victron 12V pour alimenter l'un des nœuds.

Ce sera le nœud n°3, dans le boitier compact Mini-ITX.

Ce serveur n'aura donc pas d'alimentation AC classique, mais un connecteur DC 12V.

Je reviendrai en détail plus tard sur ce montage lors des discussions sur le choix des composants.

 

L'autre intérêt de l'alimentation direct en courant continu, c'est le rendement élevé.

En effet, on évite la double conversion DC-AC puis AC-DC, avec des pertes significatives à chaque étape.

 

Les 2 boitiers rackables auront une alimentation ATX standard, haut-rendement, afin de limiter les pertes. Là encore, je détaillerai ultérieurement le choix du modèle.
Chaque alimentation sera sur une source d'alimentation 230V AC différente.

 

Le nœud n°1, le principal qui est dédié au NAS, sera derrière mon vaillant onduleur Eaton 5P qui protège déjà mon informatique à domicile.

 

Bien sûr je ne mets pas 2 nœuds derrière le même onduleur Eaton, car une panne de celui-ci entrainerait la perte des 2 nœuds et donc du cluster entier.

 

Donc le nœud n°2 sera branché directement sur le secteur, enfin plus précisément sur la sortie secourue de l'onduleur Victron (comme toute la maison), ce qui le protège donc contre une coupure de courant EDF.

Ultérieurement, quand UniFi sortira sa gamme d'onduleurs "pro" (avec batterie Li-Ion), j'en prendrai un pour sécuriser encore plus ce serveur.

De façon générale, on constate qu'en cas de coupure secteur EDF, l'ensemble des 3 nœuds de mon cluster (ainsi que les switchs, routeur, etc) sont tous protégés.
Si la batterie est chargée et/ou qu'il y a suffisamment de soleil, je peux théoriquement tenir un temps infini.

 

 

Oui mais c'est ultra limité, compatibilité Onvif uniquement, pas de reconnaissance d'événements par IA.... Aucun intérêt en pratique, c'est juste de l'enregistrement bête et méchant, ça revient presque à la solution Synology Surveillance Station.

 

Ils proposent un module externe pour ajouter l'intelligence aux caméras lamdba, mais financière ça n'est pas vraiment intéressant, autant acheter directement les caméras Unifi.

 

Franchement, je ne te dis pas que tu dois t'enfermer dans une marque, mais regarde ce que propose vraiment l'offre Unifi Protect avec les caméras récentes G6, tu verras qu'ils ont carrément pris plusieurs années d'avance sur Sylonogy.

Et les interactions avec les portiers et contrôles d'accès de la même marque, c'est bien foutu.

 

Moi ça me fait réfléchir, et je pense qu'à l'avenir je basculerai sur cette solution. En attendant je n'achète plus de caméras Hikvision (j'en ai déjà assez de toute façon)

 

Et comme dit, mon nouveau serveur aura une VM Syno uniquement pour conserver Surveillance Station quelques temps, le temps de voir comment je fais évoluer ma vidéosurveillance.