Lazer

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

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.

Firmware 5.202.54 BETA Hotfix 11/03/2026 Thank you for using our gateway! Be sure to update to the latest version to enjoy new features and improvements. Important notice: Version 5.202.54 is a hotfix for version 5.202.51. The update resolves: Fixed problem of the system hanging on Starting Services in rare cases when Thermostat Linked Device is used. Fixed problem that migration may fail when device model does not contain information about security level when devices were added in legacy versions. Main features: Migration of Z-Wave engine from 2.0 to 3.0 version (BETA) In this version of the software, it is possible to migrate the Z-Wave engine to version 3.0. Migration will allow you to take advantage of all the features of the new Z-Wave engine, including using Smart Start, better generic support for Z-Wave Plus devices and the availability of Security S2, which can be considered the first fully secure communication method for the Smart Home. Smart Start From now on, you can use the Smart Start function using QR Scanner in Yubii App. This function will allow you to add devices to the system even faster using binding process.*** What's new: Devices Added thermostatOperatingState interface for Linked thermostats. Added direct access to KNX communication (both sending and recieving packets) from the API. Gateway connection Enabling Support Access and Remote Access on the Master hub also enables access on slave hubs. Nice* Added the option to disable the sun impact (setting the value to 0 lux in parameter 10) for the Domi WSC device v3.9.0. The default values of parameters 1, 3, and 10 have been changed for all versions of DOMI WSC devices. Other Verification of the checksum when downloading the update file at the beginning of the process instead of at the end. Bug Fixes: Climate Fixed an issue where an added temperature sensor was removed from the climate panel when editing other settings in that panel. Fixes an error occurs after deleting a device in the climate schedule. Devices Fixed a problem with KNX device configuration caused by the lack of support for diacritical marks in device names. Fixed an issue with function settings for Z-Wave devices with an empty template during the binding process in the mobile application. Fixed incorrect KNX Bridge connection status after IP change. Restored missing temperature graphs on FGT device version 4.10. Fixed the appearance of the dialog in the user interface for BiDi-Awning and AV Controller. Elero Fixed color component values for the Elero Lighting RGBW device. Fixed the appearance and behavior of the Elero Lighting RGBW device icon in the user interface. Fixed invalid settings for temperature color in profiles for the Elero Lighting RGBW device. Gateway connection Fixed errors and incorrect display of options in association settings. Fixed IP address validation in the Gateway Connection tab. Nice* Fixed keep-alive support for Domi WSR/WS device, which caused the device to be shown as disconnected in the system. Other Fixed handling of events from the NICE camera plugin when devices are added via NVR. Fixed icons for Sonos and XBMC plugins. Fixed errors displayed in the Z-wave tab of the Master hub when using the interface via Remote Access. Fixed the input validator for variables. Fixed non-functioning group actions in profiles. Quick Apps Added support for climate zone control functions in QuickApps. Fixed restarting the Quick App process when editing it. Fixed Heat Activator which stopped working in rare cases. Fixed an issue with saving the Quick Apps view to a file when encrypting (applies to QA exported from version 5.191 or later). Scenes Fixed refreshing of the scene activity switch in the interface when calling activation/deactivation action from the scene level. Fixed inactive color temperature slider for device Elero Lighting TW in scenarios created in the mobile app. Known issues: Z-Wave Engine 2.0 to 3.0 migation Device updates from both the server and the file are not working, reconfiguration of the device resolves the issue. * - Does not apply to HC3L (Home Center 3 Lite). ** - Applies only to Z-Wave 3.0 engine. *** - Fully supported in the upcoming Yubii v2.5.3 application

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.

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.

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

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.

Après la mise à jour, on a une nouvelle notification qui nous conseille de préparer la migration vers le moteur Z-Wave v3 car le moteur v2 ne sera bientôt plus mis à jour : Quand on clique sur le bouton on arrive au panneau Z-Wave qui nous propose de lancer la migration : Mais, comme le rappelle @jojo, c'est pas comme si le moteur v3 était vraiment stable, comme le mentionne encore le Changelog : Du coup.... faire la migration pour passer d'un moteur non maintenu à un moteur non finalisé. C'est jouer aux équilibristes ! Bon, le message sur la box nous dit qu'on peut toujours revenir à une sauvegarde précédente, c'est un peu rassurant... en effet, la configuration des différents modules dans le réseau Z-Wave ne devrait théoriquement pas être affectée par cette mise à jour coté box / contrôleur. J'ai 2 modules Z-Wave sur ma box de test, j'attends la sortie de la version Stable du firmware puis je tenterai alors la migration Z-Wave. Pour ma box de prod, rendez-vous dans.... euh..... bah..... on verra

J'avoue que.... tout pareil Mais quand même, je suis impressionné par les dernières mises à jour Fibaro / Nice : ajout du KNX, enfin la tant attendue migration Z-Wave v2 vers v3, on se demande quelle sera la prochaine étape. Allez rêvons un peu, un support amélioré du Zigbee, ou même du Bluetooth Low Energy comme annoncé initialement