Le Homelab réseau serveur de Lazer

[jojo]

22 To, petit en effet 

[Lazer]

C'est surtout que si on met un disque de 22 To dans une grappe de disques 24 To, alors tous les disques sont limités à 22 To, donc ça fait pas mal de place perdue (2 To x le nombre de disques de 24 To), et donc autant argent perdu.

 

Les contraintes du RAID.... c'est une des nombreuses raisons pour lesquelles je n'avais jamais fait de RAID jusqu'à présent dans mes serveurs à domicile, c'est beaucoup de contraintes pour un bénéfice faible voir inexistant pour un usage domestique.

Rappel : le RAID n'est pas une sauvegarde. A se répéter en boucle.

 

[jojo]

nos 2 messages s'étaient croisés (le tiens avec les disques de 24 To, n'était pas encore publié quand j'écrivais ma bêtise)

[mprinfo]

@Lazer pourrais tu me donner la ref de ta carte mère stp
Tu es parti sur du LGA1700 ?

As-tu déjà commencé l'assemblage de ton serveur ?
Si oui connais tu la consommation CPU + Ram + Carte mère a "vide" ?
Merci d'avance pour ta réponse


J'ai trouvé cette ref EC266D4-4L qui et au format atx mais pas de 10gb pour le réseau

J'ai toujours préféré le format atx au format micro atx

Envoyé de mon Pixel 8 Pro en utilisant Tapatalk

[Lazer]

Désolé j'ai pris du retard dans mon descriptif, oui j'ai déjà quasiment tout commandé et reçu, il me manque juste le dernier processeur Xeon que je suis censé recevoir avant-hier hier aujourd'hui si UPS se décide à travailler....
Le plus gros Xeon, celui qui doit aller dans mon nœud principal qui aura tous les disques durs et la VM TrueNAS.
 

Les 2 autres (petits) nœuds sont déjà montés, installés et opérationnels.... mais pas utilisables, car un cluster haute-disponibilité de 3 nœuds avec seulement 2 nœuds, c'est pas prêt à entrer en production.

 

Mais déjà, oui c'est bien du LGA1700, et coté carte mère j'utilise ça :

• Mini-ITX : 1 x ASRock Rack EC266D2I
• Micro-ATX : 2 x ASRock Rack EC266D4U

La EC266D4-4L c'était mon premier choix pour le nœud NAS grâce à son nombre de slots PCIe qui m'aurait permis d'ajouter des cartes plus tard (notamment un GPU si jamais j'avais l'intention de faire de l'IA locale plus tard par exemple), sauf qu'elle était totalement indisponible en Europe entière tout l'hiver... et là elle est de nouveau en stock. Pas de chance.

Si ton boitier te permet de monter une carte mère au format ATX, c'est clairement le meilleur choix, car plus évolutif coté entrées/sorties.

 

Pour le 10 GbE, c'est ce que je voulais initialement intégré à la carte mère, mais comme je l'ai rapidement expliqué j'ai changé d'avis et c'est un grand NON maintenant, car le 10 GbE sur port RJ45 cuivre c'est une plaie sans nom : consommation (et chauffe) très importante, plusieurs Watts perdus (jusqu'à 5W par port) en continu, qu'il y ait de la communication réseau ou non.
C'est pour ça que je ne vais utiliser que du 10 G avec câbles DAC, d'une part c'est moins couteux, et d'autre part la consommation est plus faible (compter 0.5 W par port, c'est imbattable), et en prime la latence est plus faible (et ça c'est important pour mon réseau de réplication CEPH)

Donc 1G RJ45 sur la carte mère pour l'administration de Proxmox, et carte PCIe Intel X710-DA2 ou DA4 pour les connexions 10G DAC.

Ce modèle de carte Intel en particulier est celui qui propose la plus faible consommation.

J'ai trouvé des clones à pas cher sur Aliexpress pendant le Black Friday (chipset Intel original, juste le PCB qui est un design chinois générique). Idem pour la carte SAS Broadcom d'ailleurs, qui va gérer les disques durs.

 

La consommation à vide pour l'instant oscille entre 25 et 40W par nœud, mais ça ne t'avance pas beaucoup car je n'ai pas encore décrit la configuration matérielle détaillée, et je n'ai pas encore appliqué toutes les optimisations permettant de réduire la conso (BIOS, ASPM, C-States, vitesse des liens PCIe, paramétrages noyaux Linux, etc).

Je détaillerai ça plus tard de façon détaillée, quand j'aurai joué avec.

Et cette consommation n'est pas tout à fait "à vide", car sur chacun de ces 2 nœuds il y a aussi :

• la carte réseau Intel X710-DA2 10G
• un SSD NVMe de gamme pro de chez Kinston sur le slot M.2
• un SSD NVMe de gamme pro de chez Micron au format U.3 (raccordé sur un port Oculink PCIe x4 de la carte mère) qui consomme déjà 5W rien qu'à lui tout seul en idle, sans activité.... c'est un monstre de puissance. Forcément, ce luxe que je me suis imposé a un cout énergétique certain.
• des ventilateurs (ventirad+boitier), même si en ne prenant que des Noctua, la consommation est très faible, surtout piloté en PWM à rotation lente

Je précise que les SSD sont tous de gamme professionnelle, j'en parlerai de façon plus détaillée plus tard, mais ça a son importance sur la consommation : dans le monde pro, on se moque de la consommation, on cherche fiabilité + performance.
Rien à voir avec les SSD Crucial, Samsung, et compagnie qu'on installe dans nos PC classiques, dont la faible consommation est le critère n°1.

En terme de consommation, il y a un rapport 1 à 10, voire 1 à 100 selon l'activité I/O entre les gamme grand public et pro.

 

Je l'avais dit ton mon cahier des charges, je privilégie la fiabilité, et la performance, bien avant la consommation. C'est pour mon projet, ce n'est pas ce que je te recommande, c'est pour ça que je prend le temps de décrire mes chois et les conséquences.

[mprinfo]

Super merci pour ces informations
Voilà les prix que je trouve

EC266d4u
https://meta-preisvergleich.de/index.cgi?q=ec266d4u&c=kategorie&id=ec266d4u__kategorie&offset=&neu=1&qq=

ec266d4-4l


https://meta-preisvergleich.de/index.cgi?q=ec266d4-4l&c=kategorie&id=ec266d4-4l__kategorie&offset=&qq=

Environ 150 euros de différence

Je démarre de zéro

Donc pour le boîtier il faudra faire attention à la profondeur si je pars sur du rackable
Si tu as une marque à me conseiller je suis preneur

Pour l'alimentation je pense partir sur du 250w

Le plus gros problème c'est la RAM car pour le moment c'est vraiment trop chère.

En CPU je vais regarder pour un xeon en basse consommation

J'ai commencé a jouer avec proxmox c'est perturbant cela change de ESXi au niveau graphique

Je pense faire comme toi passer sous truenas pour le stockage pour moi c'est un retour aux sources j'ai commencé avec freenas avant de passer sous xpenology.

Pour les caméras je vais utiliser xpenology DVA1622 qui a l'avantage d'avoir 8 licences gratuites.

Pour le reste haproxy et mon serveur WEB ce sera VM debian




Envoyé de mon Pixel 8 Pro en utilisant Tapatalk

[Lazer]

En boitiers, Silverstone c'est le top qualité, avec un choix incroyable de modèles rackable ou tour, certains sont même montables dans les 2 configurations.

 

Comme tu dis, le vrai problème c'est la RAM, regarde l'évolution du prix des barrettes que j'utilise, sachant que j'en ai 4 des comme ça; j'ai mis le curseur au moment où je les ai acheté :

 

 

 

Fait attention, il faut vérifier, mais j'ai peur que partir sur du Xeon risque de t'imposer de la RAM ECC, et avec les prix actuels, ce n'est plus possible.

 

A ta place, je choisirais en premier la RAM, et en fonction de ce que tu trouves, tu montes le serveur autour.
Donc après la RAM, tu choisi la carte mère, processeur, etc... peut être qu'au final ça ne sera pas de Xeon mais du Core quelque chose, avec un socket différent de LGA1700.

En plus, si la consommation est importante pour toi, un Core descendra plus bas qu'un Xeon (gamme pro, optimisé pour la perf...)

 

Attention aux SSD aussi qui ont déjà méchamment augmenté, c'est pour ça que j'avais fait un peu de stock avec mes 20 To de SSD.....

Il t'en faut au moins un pour le disque de boot et le datastore des VM.

 

Pour Surveillance Station, après des mois de réflexion j'ai trouvé comment je vais faire :

- dans un 1er temps, monter une VM Xpenology dédiée exclusivement à Surveillance Station (équivalent à ce que j'ai actuellement sur mon HP Gen8 en fait)

- dans un second temps (l'année prochaine ?) : tout basculer en Unifi, ce qui implique d'acheter un NVR de la marque (surement le modèle UNVR), mais aussi leurs caméras (la gamme G6 est top)
De toute façon aujourd'hui, Synology s'est endormi sur ses lauriers. Plus d'évolution de Surveillance Station, tandis que Unifi avance à une vitesse folle, quand tu vois l'interface et les capacités d'IA, ça dépasse déjà Syno. Mais l’investissent financier initial est assez important.

 

Avec la pénurie des composants, c'est pas le bon moment pour se monter une nouvelle machine, tu t'y prends au mauvais moment (mais ça sera encore pire dans quelques mois....)

 

Sinon, j'ai reçu mon Xeon, je peux commencer à monter le nœud principal ce week-end

 

[mprinfo]

Merci pour toutes ces informations. 

Punaise je viens d'acheter 2 hikvision j'ai pas voulu partir sur du unifi car je trouve le prix des caméras trop élevé par rapport a hikvision. Tu arrives à avoir des G3 à moins de 200 euros. Je viens d'installer une G2 panoramique une tuerie de nuit. Pourtant j'ai un udm donc je pouvais installer protect sans coût supplémentaire.

 

Pour le serveur il n'y a pas d'urgence mes 2 gen8 fonctionnent bien mais je commence à être limite côté RAM

 

[Lazer]

En fait, si tu compares ce qui est comparable (hors piratage) :

• des caméras Hikvision de qualité + un NAS Synology + les licences Surveillance Station
• des caméras Unifi G6 + un NVR Unifi + aucune licence

Tu verras que Unifi n'est plus plus cher, et même moins cher, mais avec une interface bien plus évoluée, une intégration IA native (alors que Hikvision + Surveillance Station c'est bancale comme tout....).

 

Attention je parle bien des caméras UniFi G6, la qualité d'image est excellente, la reconnaissance IA assez fiable, rien à voir avec les générations précédentes.
Du coté de chez Hikvision, il faut commencer à mettre assez cher pour avoir l'équivalent.... presque aussi cher en fait.

 

Je vais me faire démonter par notre fanboy Synology du forum, mais si tu fais le tour des autres forums, chaines YouTube, groupes Facebook (bon OK pas très crédible celui-là), tu verras que Synology est complètement à la dérive, ils ne tiennent plus la comparaison.

 

Reste que Syno a une solution NAS tout intégrée, fonctionnelle et ergonomique, c'est probablement tout ce qu'ils leur reste.

Mais bon là encore, quand tu vois la vitesse d'évolution des NAS Unifi, ce discours ne tiendra peut être même plus d'ici 1 an.

[mprinfo]

Perso je préfère ne pas m'enfermer dans une marque

 

Tu vas me dire oui mais tu es full UNIFI pour la partie réseau, 

 

Je viens de jouer un peu avec UNIFI PROTECT pour voir 

 

On peut installé de caméra autres que Ubiquiti 

 

[Lazer]

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.

 

Modifié le 8 mars par Lazer

[Lazer]

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.

 

 

[Nico]

Top. Juste un point que je ne comprends pas trop, tout est protégé, sauf un truc, tout est dans la maison à 3m de distance ?

Pourquoi ne pas mettre une des 3 dans le garage ? Moi c'est la première chose que j'ai fait, avoir un secours dans le Poolhouse, pour être résilient versus le risque incendie de la maison ? Bien sûr, si la maison brûle on peut se dire il y a d'autres priorités, mais bon, cela évite de tout perdre non...

[Lazer]

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)

[Nico]

Yop, donc tu ne protèges pas notre fofo à 100% quoi... :):)

Moi j'aurai mis de la fibre, franchement ça coute plus grand chose, le plus chère c'est la soudure au bout au final, sauf si tu connais qqun qui te le fait. Pour passer aucun soucis, tu accroches au Grade 3 et tu tires, de toute façon plus besoin

 

Comme de disais, si la maison complète brûle, ce point est un détail. Si par contre ton armoire brûle avec l'autre juste 2m au dessus, cela peut impacter. Bref, je pinaille. En tout cas hâte de voir la suite.

 

[Lazer]

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.

 

Modifié vendredi à 19:33 par Lazer

[Nico]

Pourquoi connexion unique ? Moi je tire toujours de la fibre multi-brin pour relier nos baies au boulot, et comme ça cela permet de mettre sur 2 équipements actifs de chaque côté. Bien sur tu peux casser la fibre, mais elle va pas casser en même temps que le reste

Après pour la connexion internet, rien ne t'empêche de mettre le secours 4G également avec, et encore sur 2 brins à part si tu veux les faire rentrer directement dans le routeur comme s'il était à côté.

 

Soyons extrémiste jusqu'au bout  Je pense qu'il faut y réfléchir.

[Lazer]

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 

 

 

[Nico]

Yes, ce feu de la Saint Jean était même pas trop loin de chez moi

[jojo]

Il y a 14 heures, Lazer a dit :

si le feu

si pas le feu, une inondation suffirait à mettre la pagaille.

[jojo]

Il y a 13 heures, Lazer a dit :

Si on pousse la logique

mon idée serait encore plus simple : pourquoi ne pas avoir ta maison en double dans le village d'à côté  ?

Certes, cela présente  un LEGER (pour toi ) surcout, mais la sécurité n'a pas (pour toi ) de prix !

[Lazer]

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 !

 

Modifié samedi à 11:21 par Lazer

[Nico]

Après aucun secours 4G, moi je trouve cela vitale. Ca m'a déjà servi plus d'une fois (Plantage box, problème sur le réseau fibre), je ne pourrai m'en passer, cela reste un backup qui fonctionne dans 99% des cas.

[Lazer]

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é.

[Nico]

Après c'est différent partout, ici des coupures on a déjà eu, pour diverses raisons (Coup de pelleteuse, crétin de technicien d'une autre marque qui a débranché la mauvaise fibre, etc). Aujourd'hui la 4G/5G de backup me va bien.