Le ProLiant Microserver Gen10 Plus de HPE est sans doute l'une des meilleures machines lorsque l'on veut se monter un NAS maison, presque sans concurrence sur son segment. On peut bien entendu y installer un système comme TrueNAS ou Unraid, mais nous avons tenté notre chance avec QuTS cloud.
Il y a quelques mois, nous vous présentions le nouveau ProLiant Microserver Gen10 Plus de HPE, une machine compacte avec 4 ports RJ45 à 1 Gb/s que l'on trouve entre 460 et 670 euros selon les modèles, processeur et mémoire inclus. Il faut simplement y ajouter du stockage, quatre emplacements 3,5" étant présents en façade.
Nous l'avions même modifié à l'époque pour y utiliser un Core i7-9700T et plus de mémoire. De quoi permettre de monter un NAS maison à moindres frais, avec en plus des fonctionnalités appréciées des utilisateurs professionnels comme la gestion native du iSCSI, la possibilité de rajouter une carte de gestion distante, etc.
Puis il y a quelques mois, QNAP permettait de se payer une licence pour son interface QuTScloud, cette dernière ayant récemment évolué. Cela nous a donné une première idée (d'autres suivront) : et si nous transformions le MicroServer HPE en NAS QNAP, avec une gestion distante pour y accéder en cas de problème ?
Ajout d'un SSD NVMe et détail de la configuration
Le ProLiant Microserver Gen10 Plus de HPE a un défaut : il ne propose pas de port M.2 natif. Heureusement, il dispose de deux ports PCIe 3.0. Dans le premier, nous avons donc placé une carte permettant d'ajouter un SSD M.2 NVMe qui accueillera le système d'exploitation, on en trouve aux alentours de 16 euros.
Nous avons opté pour VMWare ESXi, ce qui nous permettra d'installer différentes machines virtuelles, dont une avec QuTScloud, qui accèdera aux HDD. Pour le reste, nous avons gardé la machine telle que nous l'avions configurée avec le Core i7-9700T et 2x 32 Go de DDR4. Le second port PCIe 3.0 peut accueillir le kit iLO (integrated Lights Out) 5 avec une puce spécifique et un port réseau, pour la gestion distante. Il est vendu dans les 40 euros.
Configuration d'iLO 5
Une fois la machine allumée et ce port relié au réseau, on peut accéder à l'interface en ligne. Elle nécessite un mot de passe qui est par défaut indiqué sous le Microserver. Pour des questions de sécurité, pensez à le changer.
L'interface est plutôt complète, permettant d'accéder aux fonctionnalités principales comme le fait de (re)démarrer la machine, voir son statut et celui de ses composants, accéder à son écran (HTML5, Java, .Net), y attacher une image ISO à distance, etc. Certaines nécessitent une licence spécifique, comme la gestion en flotte, la connexion unifiée, etc.
Autre possibilité appréciable de cette mécanique de gestion distante : la possibilité de mettre à jour le BIOS/UEFI ou le firmware iLO sans accès physique à la machine. Tous les fichiers se trouvent par ici. On apprécierait néanmoins de pouvoir trouver de nouvelles versions plus facilement, en étant notifié directement dans l'interface par exemple.
Car il faudra penser à vérifier régulièrement la publication de mises à jour iLO 5, qui peuvent être publiées pour ajouter des fonctionnalités ou pour des raisons de sécurité. Lors de test, nous sommes ainsi passé à la 2.41 du 26 mars. Petit regret : seules deux dispositions de clavier sont gérées par la gestion distante : anglais et japonais.
Installation de VMWare ESXi 7.0b, licence QuTScloud
Pour l'installation d'ESXi dans sa version gratuite, nous avons donc téléchargé l'ISO sur le site de VMWare puis l'avons monté via l'outil de gestion distante HTML5 où l'on peut sélectionner une ISO locale (ou une URL). Une fois la machine démarrée, on presse la touche F11 pour accéder au menu de boot. L'installation est ensuite classique.
Pour rappel, une licence payante est nécessaire pour utiliser QuTScloud. Pour ce test nous avons opté pour 1 seul cœur (9 dollars par mois ou 90 dollars par an) suffisant pour quelques utilisateurs. La version gratuite d'ESXi permet d'aller jusqu'à 8 cœurs par VM, soit une licence de 40 dollars par mois ou 400 dollars par an.
Notez que cela fonctionnera avec d'autres hyperviseurs et systèmes comme Proxmox, qEMU/KVM, Unraid, etc. Vous pouvez également utiliser cette procédure chez un fournisseur de services cloud proposant d'attacher à une instance des périphériques de type Block Storage auxquels vous accéderez directement dans quTScloud.
ESXi installé sur le SSD, deux HDD restant disponibles. On accède à son interface via l'adresse IP donnée
Création de la machine virtuelle (VM)
Maintenant, il faut télécharger l'image correspondante et l'installer. Dans le cas de VMware il s'agit de l'ESXi Package, au format zip. Décompressez-le, il contient l'image elle-même (VMDK), mais des fichiers de configuration (OVF/MF).
On se rend ensuite dans l'interface de gestion d'ESXi, disponible à l'adresse IP communiquée à la fin de la procédure d'installation (voir ci-dessus). Une fois connecté, on crée une machine virtuelle dans la section dédiée. Ici, optez pour l'option « Déployer une machine virtuelle à partir de fichiers OVF et VMDK ». Donnez un nom à la machine virtuelle et sélectionnez les deux fichiers correspondants de l'archive décompressée.
Vous devrez ensuite sélectionner où elle sera stockée et ses paramètres, laissez tout par défaut. Vous pourrez demander à ce que la VM ne se lance pas par défaut. Elle doit être stoppée pour la suite de la procédure.
Configuration, ajout des HDD... sans passthrough
Vous disposez désormais d'une machine virtuelle configurée avec des paramètres de base et un unique périphérique de stockage où est installé QuTScloud. Il faut désormais l'adapter à vos besoins.
La première chose à faire est de lui attacher les différents HDD de la machine. Ici, n'espérez pas le faire de manière native, en passthrough, car si la méthode est supportée par la dernière version du système de QNAP, il est impossible de faire de même avec le contrôleur S-ATA du MicroServer HPE. Il faut donc le faire à l'ancienne.
Dans la section consacrée au stockage de l'interface d'ESXi, demandez à créer de nouveaux datastores. Il s'agit d'espaces où des disques durs virtuels peuvent être créés. Par défaut il en existe un là où ESXi est installé (le SSD dans notre cas). Mais on peut en ajouter d'autres. L'objectif étant d'utiliser nos HDD en RAID, on les formate via l'outil prévu à cet effet puis on y crée un datastore avec comme nom HDD1, HDD2, etc.
Retournez ensuite aux paramètres de la VM. Dans ses options, modifiez le nombre de cœurs avec celui correspondant à ce que permet votre licence QuTScloud (1 dans notre cas). Vous pouvez aussi revoir la quantité de mémoire attribuée, et ajouter des disques durs. Nous le faisons avec deux d'entre eux (500 Go chacun) en précisant dans les paramètres que le premier doit être placé dans le datastore HDD1, le second dans HDD2.
Configuration de QuTScloud
Démarrez la VM, une fois la procédure terminée, une adresse IP sera affichée. Il vous suffit ensuite de vous y rendre pour accéder à l'interface permettant la configuration. Il faudra alors indiquer votre numéro de licence (trouvable dans le Manager de QNAP) puis les paramètres habituels : nom du NAS, mot de passe, heure, etc.
Une fois la procédure terminée, QuTScloud agira comme l'interface de n'importe quel NAS de QNAP. Dans l'outil de gestion du stockage et des snapshots, on peut ainsi créer un pool et un volume avec nos deux HDD virtuels de 500 Go. On peut ensuite gérer tous les services de base et profiter des applications.
On peut ainsi mettre en place un partage de fichiers via Samba/CIFS, un VPN, des sauvegardes et synchronisations dans le cloud via les outils QNAP ou tiers, déployer des conteneurs (mais pas de VM forcément), etc. L'intérêt d'une telle solution virtualisée est que l'on peut faire fonctionner d'autres machines virtuelles dans ESXi en parallèle de QuTScloud, pour disposer d'un petit serveur Debian, d'un Windows que l'on utilise en bureau distant, etc.
LAN en passthrough : ok, ajout d'un port à 5 Gb/s en USB : raté
Le ProLiant Microserver Gen10 Plus de HPE est doté de quatre ports réseau. On peut décider d'en attribuer certains à la machine virtuelle QNAP en passthrough. Par curiosité, nous avons également tenté de lui ajouter un adaptateur USB avec un port RJ45 à 5 Gb/s, le QNA-UC5G1T de QNAP que nous avions testé en 2019.
Pour tenter de le rendre accessible à la machine virtuelle QuTScloud nous l'avons ajouté à ses paramètres. Une fois la VM redémarrée, il n'était néanmoins pas visible. Nous n'avons pour le moment pas trouvé de solution.
On ajoute trois ports réseau en passthrough, ils sont reconnus. L'adaptateur USB ne l'est pas.
Commentaires (25)
#1
Pour le passtrough USB, l’idéal est de tester avec un contrôleur USB2 dans le VM et non USB3, pour des raisons de pilotes. Attention, il faut un câble USB-C USB2 (comme un cable de manette de switch par exemple) pour pouvoir le monter, sinon, il sera détecté en USB3 par ESXi qui ne pourra pas le monter en USB2 (ça accepte mais ça ne fonctionne pas).
Aussi, attention: le passtrough sur ESXi 7.0, c’est de la merde en barre, que ce soit USB ou PCIe. Pour du passtrough PCI, le 6.7 est largement recommandé. Dans ce type de cas, on a même tendance à passer la carte USB3 en passtrough dans la VM, comme ça, elle a ses cochons
#2
Ici le passthrough USB n’était pas possible (et l’USB 3.x était plutôt nécessaire pour disposer du débit de 5 Gb/s).
#3
La question est pourquoi, surtout un gen 10 ? un vieux gens 6 ou 8ne serait pas suffisant ?
#4
Pour la frime
#5
Ba c’est ce qu’ils ont sous le coude surtout ^^
Et puis le super avantage de cette version c’est qu’il a des composants supportés pour du VMWare, Proxmox ou autre hyperviseur. T’ajoute à ça l’IPMI, du xeon, 4x1Gb… un vrai petit serveur super pro sans avoir a débourser pour une grosse tour ou du serveur rackable.
Par contre, je sais pas si on peu vraiment accrocher autre chose qu’une carte iLO sur le 2eme “PCIe”.
#6
Je ne comprends pas trop la question. On prend un appareil récent pour référence. Après si tu veux faire ça avec tout à fait autre chose, libre à toi.
Oui c’est un port pour iLO uniquement
#7
trop cher pour du perso…
une question que je me pose est: que deviennent tes données si jamais la licence périme?
#8
Pour le le QNA-UC5G1T de QNAP sur Esxi, il faut mettre à jour le firmware de l’adaptateur Usb et installé un driver specifique.
Lien
#9
+1
J’espère que ça coupe pas tout. Sinon ça ressemblerait a un crypto à compte à rebours. Je crois que datacore fonctionne comme ça en plus…
#10
https://software.qnap.com/qutscloud.html:
FAQ
1
What limitations apply when the QuTScloud license expires?
Every service of QuTScloud, excluding “License Center” and “myQNAPcloud” will be disabled when the license expires. Please note that licenses are automatically renewed by default.
2
Is my data affected when my QuTScloud license expires?
Your data will remain on the QuTScloud virtual hard drive. When you renew the license, you will be able to use your QuTScloud just like before.
#11
Dommage que ce HPE ProLiant Microserver ne soit pas disponible sans processeur et mémoire; parce que devoir en racheter pour en faire une machine performante, ça grève beaucoup le prix avec une revente hasardeuse des éléments d’origine.
#12
Je ne connais pas forcément QuTScloud, mais rien n’empêcherai de monter un accès à des répertoires déjà existants, et se servir de QuTScloud comme accès avec les interfaces et outils Qnap.
Comme ça, si pas de renouvellement de licence, les données sont toujours accessibles pour d’autres OS
#13
Je sais pas si c’est moi, mais je trouve ça un peu compliqué et cher comme solution…
D’abord côté matériel :
Où est l’intérêt d’acheter le microserver de base et l’upgrader ?
autant acheter direct le modèle avec les 16 Go de ram et le Xeon qui est quasi au niveau du i7-9700t, on économise direct ~200€.
Ensuite côté coût de la licence QuTS : je veux bien payer 90\( par an, mais à ce moment il faut de la robustesse et de la simplicité...
90\) par an ça fait 400€ en 5 ans, à ce prix ce n’est pas pour faire du stockage en surcouche par dessus du ESXi sur des datastores en VMFS….
Si on y rajoute le prix du matériel (~600€ TTC), à ce prix là on a direct un Syno DS1621+ en AMD 4 coeurs et 6 baies, supporté et fiable.
Et la fiabilité ? parce que ESXi ça se met pas à jour facilement… faut arrêter les VM, passer en mode maintenance, lancer l’upgrade à la main si on a pas de Vcenter.
Si on a une panne de courant prolongée, tout s’éteint correctement ?
Si on a une coupure inopinée, rien ne va se corrompre ? (ni l’ESXi ni la VM ni les datastores ?)
Si c’est pour bricoler, je préfère me monter un NAS en mini ITX, là je perds un peu de temps à trouver un boitier mini ITX et une alim qui survivront au moins 2 cartes mères et processeurs, je perds un peu de temps à installer OMV mais au moins mes données sont pas coincées sur deux formats propriétaires encapsulés…
elles sont nativement sur les HDD en EXT4 ou BTRFS sur du lvm que n’importe quel linux lit nativement…
#14
Si tu veux du simple et clé en main à usage unique, QNAP (ou d’autres) vend des NAS clé en main ;) Mais oui tu peux aussi tout faire à la main avec un autre OS si les fonctionnalités proposées par QTS ou DSM ne te sont pas utiles.
#15
Parce qu’ils avaient les pièces à disposition, tout simplement. L’installation montrée est juste une possibilité parmi tant d’autre, il faut cesser de voir ces articles comme “la méthode à appliquer”.
Ici on peut découvrir :
Chaque partie est intéressante séparément et c’est ça qui compte.
#16
#17
Alors oui, QNAP ou syno vendent des NAS clés en main, mais tu peux pas dire depuis quelques années qu’ils sont à usage unique : dans la gamme de prix du microserver + licence QuTS de l’article, on trouve des modèles qui encaissent des VM, des instances docker, du NVR avec encodage hardware, et on peut même backupper des VM ESXI “free” distantes en 2 clicks..
J’avoue que votre montage est sympa sur le papier, et un avantage est qu’on pourrait potentiellemt migrer la VM QuTS d’un appareil à l’autre, ok.
Mais ce que je me demande et j’insiste un peu, c’est si vous avez testé de tirer la prise de courant de votre montage ?
même avec un onduleur ?
Parce que l’échaffaudage est sympa, j’avoue, mais encore une fois ça me fait peur : est-ce qu’en cas de coupure de courant, sur onduleur, l’ESXi va bien donner l’ordre à la VM QuTS de s’éteindre ? j’en doute…
Je dis ça parce que j’ai vu beaucoup de NAS “maison” (comme ici) qui, à la moindre coupure (freenas en ZFS par ex), si on a pas un onduleur en bon état qui envoie proprement l’info de purger les caches et les ecritures en attente, se couper gentiment -> byebye les données…
ce qui est dommage pour un NAS.
#18
HyperV, qui est loin d’être une référence dans le genre, mets les VM en standby à l’extinction et les redémarre comme si de rien n’était après. Ça m’étonnerait qu’ESXI ne soit pas capable d’en faire autant.
Si tu perds tes données après une coupure sur un ZFS il y a un souci sur la machine. ZFS est pensé pour ne jamais supprimer la vieille version d’un fichier tant qu’il n’est pas sûr à 100% d’avoir écrit la nouvelle. Au pire tu perds la modification en cours.
#19
Oui, il existe de quoi utiliser directement un onduleur avec esxi (NUT). Sinon Eaton, par exemple, fourni des packages (IPM) qui s’installent sur Windows ou en appliance .ovf à déployer sur n’importe quel hyperviseur pour piloter un onduleur ou une flotte d’onduleur et donc plusieurs hyperviseurs.
Comme le dit Soraphirot, le ZFS est un système qui prévoit ce genre de chose, il écrit ses index au dernier moment pendant quelques ms. Donc pendant un transfert de fichier effectivement tu perdra ce que tu copie mais c’est tout.
#20
Je dis le contraire justement, ils peuvent tout faire ou presque. Mais si tu veux du NAS à usage unique parce que les 3⁄4 des fonctionnalités de ces OS ne te servent pas, tu peux aller vers des solutions plus simple focalisées sur le stockage/partage.
Pour le reste, une solution virtualisée aura d’autant plus de chance de survivre à des conditions problématiques qu’elle est facilement réplicable. Sinon de mémoire VMWare (et d’autres hyperviseurs) savent donner l’info d’arrêt aux VM (parce que bon, en datacenter c’est un peu un besoin critique par exemple), mais je n’ai pas testé ici.
Par contre si tu perds tes données dans une telle situation, sur la base d’un seul souci sur le NAS c’est que leur réplication n’est pas bonne (et si c’est un besoin important que de les préserver, il faut ne pas avoir à compter sur le bon fonctionnement de l’onduleur).
#21
Oui, côté ESXi c’est vrai.
Mais la complexité du montage ici fait qu’il faut que la VM QuTS cloud soit aussi “informée” de la perte de courant et qu’elle s’éteigne proprement avant que les batteries soient vides…
Est-ce que la VM QuTS contient bien les “additionnals tools” ESXi qui lui permettent d’être informée du fonctionnement sur batterie et qu’elle doit s’éteindre ?
c’est une vrai question, je ne connais pas la réponse.
Ben ça c’est la théorie mais d’une part si le système peut s’éteindre proprement et l’éviter, c’est quand même mieux non ?
et la théorie c’est une chose, mais même sans panne hardware, il y a des bugs. Je parle d’expérience, ça m’est déjà arrivé (sur des versions de Freenas qui ont qq années certes)..
Enfin, je peux me tromper mais je ne crois pas du tout que la valeur de commit de zfs soit de quelques milisecondes hein
#22
Ok j’avais pas compris la réponse comme ça, j’avoue…
Si j’en parle c’est bien parce que le sujet m’intéresse et que ici, c’est un critère pour moi : je ne vais pas confier mes données (ou celles de clients) à un NAS qui ne sait pas s’éteindre proprement en cas de coupure de jus.
Et là je dirais que non, la solution a peu de chance de survivre à des conditions problématiques si, pour commencer, elle ne sait pas s’éteindre proprement en cas de perte de jus.
Que celui qui a un NAS qui a 1500j d’uptime (même dans son garage) sans coupure de courant me jette la première pierre :)
L’autre critère aussi, même en entreprise, c’est de pouvoir mettre la machine en veille la nuit, voire l’éteindre (et la réveiller le matin ou sur paquet WOL).
L’air de rien, ça divise par jusqu’à 3 la consommation electrique et multiplie par 3 la durée de vie réelle des HDD !
Sur un NAS QNAP on peut.
Sur un NAS Synology on peut.
Sur un NAS maison avec OMV on peut (il faut rajouter les paquets OMV-extras et n’importe quel PC peut se réveiller). j’ai pas réussi avec Freenas.
Par contre ESXi pour programmer une extinction la nuit et réveil le matin, macache.
Je retourne un peu le problème. La question n’est pas SI on va avoir un problème hardware ou une perte de données un jour mais QUAND ça va arriver, et comment on s’y prépare (même si HP c’est de la qualité un microserver ça peut tomber en rade).
Et je ne dis bien sûr pas que je ne réplique pas les données, c’est juste que si il faut répliquer les données à la moindre coupure de courant, c’est un problème.
Alors oui, si on a un cluster de deux microservers, plus une troisième machine avec un vCenter, bon, là on peut avoir des VM répliquées, mais c’est un peu lourd, et surtout pas gratuit…
On peut aussi avoir des VM répliquées d’un ESXi sur l’autre, à la main ou avec des solutions tierces…(bof)
Mais si on a qu’une seule machine, ouahou…
Et perso, il y a une chose que je constate c’est que des données enregistrees sur un système de fichiers BTRFS ou EXT4 sur du raid5 logiciel mdadm, le disatster recovery plan c’est facile : on prend les disques, on les remet dans n’importe quel autre NAS / PC sous linux : bing, ça remonte sans autre forme de procès.
Par contre des données enregistrées via une VM QuTS cloud (donc format de fs propriétaire), sur un datastore VMFS, ça, c’est peut être un petit peu moins marrant en cas de pépin, ça rajoute des couches de complexité et de logiciel propriétaire.
ça m’aurait beaucoup intéressé que QNAP propose son OS en natif puisqu’il est plus complet et facile d’usage que d’autres solutions “opensource” (et un microserver avec une carte 10 Gbits, miam)
mais là : sans gestion de l’économie d’énergie (bonjour le retour aux années 90), avec la complexité et le coût de la licence…
#23
Après il faut aussi réfléchir à l’utilisation que l’on veut faire du système et comment on le met en fonction. Si l’on prend le montage tel que décrit dans l’article on est bien plus proche du homelab pour faire ses expériences personnelles qu’un outil en production sur lequel on doit compter.
Maintenant je pense que dans tout les cas les hyperviseurs sont assez avancés pour masquer aux VM qu’il y a eu un problème. Au taf notre serveur de fichiers est une VM WinServer sous HyperV et il arrive souvent que la machine soit brutalement mise en pause par manque d’espace disque (oui on a mal jaugé). Je fait de la place sur le disque puis relance la VM qui reprend comme si de rien n’était. Il y a relativement peu d’accès simultanés à ce serveur mais je n’ai pas remarqué jusqu’à maintenant de corruption dans les fichiers à cause de ses coupures (ni pour les autres machines coupés de la même façon, y compris les VM Linux dont je doute de l’installation des extra tools HyperV).
Tout à fait, le ZFS n’est qu’une première couche de sûreté contre les coupures inopinées, en rajouter sera toujours mieux. Et dans la pratique tout système aura une faille. La question est donc de savoir quel niveau de sécurité on vise et surtout si ça vaut le coup.
Alors notre 1er serveur de fichiers (au taf encore) a dû dépasser les 1000 jours si on enlève les coupures électriques prévues. Et pourtant il est fait un peu à l’arrache (l’ancien responsable info était électronicien avant tout et surtout n’avait aucune orga. le serveur tournait sous un vieux Suse, le système était installé sur un RAID 1 de 2x2To et les données étaient SUR LA PARTITION SYSTEME. La doc d’époque en cas de plantage : “tu réinstalles et tu mets la backup de la veille”…).
Je serais très curieux d’avoir des articles là-dessus. J’aimerais bien essayer ça au taf mais “malheureusement” on a des techniciens d’astreintes qui peuvent intervenir h24 donc la majorité de nos serveurs doivent être dispo à toute heure.
le raid logiciel c’est le feu. A part pour installer un système sur un raid sans avoir à devenir fou je ne vois plus d’intérêt au raid matériel. Et OpenZFS peut aussi récupérer des pools d’un autre système facilement.
C’est du mdadm et du lvm. Normalement rien d’insurmontable mais de ce que je lis c’est un poil retors quand même.
J’imagine qu’ils proposent uniquement sous forme d’appliance pour se faciliter grandement la tâche à l’optimisation et stabilisation du système.
#24
On a des modules d’interrogation réseau d’onduleur, ça permet de balancer l’ordre aux VMs.
Sinon, VMWare a la capacité de s’arrêter avant que l’onduleur chute. La VM devient donc en état enregistrée et la mise en veille prolongée est propre
#25
Alors dans le cas de coupure électrique, les VM sont pas informé de la coupure mais un process est déclenché par l’hôte. On a le choix justement dans les hyperviseurs. Généralement ils proposent une mise hors tension ou un arrêt invité ou encore une mise en pause. On peut aussi définir l’ordre d’allumage et d’extinction. On a besoin d’avoir la communication entre l’onduleur et l’hyperviseur c’est tout.
Il y a des points importants a ne pas oublier par contre comme le timing. En fonction de la charge, l’onduleur (qui a une certaine capacité lui aussi) aura une certaine autonomie et donc il faudra prévoir un délai précis entre le moment ou l’onduleur envoi l’info de la coupure et le moment ou ‘hyperviseur déclenche le process d’arrêt en prenant en compte aussi le temps qu’i faut pour tout stopper. Délai qui ne doit pas être immédiat non plus en cas de micro coupure a répétition, sinon à la moindre variation tout s’arrête. Et il faut faire attention aussi a pas tout redémarrer dès que le courant revient. Si il y a plein de coupure plus ou moins longue qui se reproduise, l’onduleur ne pourrait pas avoir assez d’autonomie pour encaisser une seconde salve et ça pourrait provoquer des arrêts brutaux derrière.
C’est la ou les appliances sont plus intéressante que les paramètres de base de chez Syno’ par exemple, on peu entrecouper plusieurs critères avec plusieurs onduleurs pour lancer les procédure. On peu affiner une algorithmie bien plus juste. Mais bon… faut voir à l’usage :)
Et dernier truc très bête, faut pas oublier les services d’intégration (VM Tools, HyperV daemons, etc…), sans ça pas d’arrêt propre possible ou mise en pause.
Personnellement j’essaie d’avoir 15 minutes de délai avant de tout arrêter. Ça encaisse les petites coupures et quand ça dépasse ce délai c’est qu’il doit vraiment y avoir un problème. Plombs qui saute ou coupure dans le quartier.
Après en ce moment j’habite dans un endroit ou le courant est fiable, j’ai pas d’onduleurs actuellement et j’ai pas connu de coupure en 2 ans. Contrairement ou avant, en pleine campagne il m’est arrivé d’avoir 9 coupures en moins de 4h et ce a durée variable. Heureusement que j’avais un onduleur a cet époque.
Et sinon comme le dit Patos ça peu passer par du réseau. Via SNMP je crois mais faut des cartes réseaux sur les onduleurs et ça coute super cher pour ce que c’est.