waazaa

Salut, la première chose qui m'a sauté aux yeux c'est que tu utilises des SSD dans l'array. La doc a évoluée passant de "déconseillé" à "expérimental" sur cette question donc du moment que tu l'as fais en connaissance de causes ça va: Il y a deux "zones" de stockage dans unRAID: l'array et les pools L'array est donc la grappe de disques dont son existence est vouée au stockage à long terme. Cet array peut bénéficier d'une tolérance à la panne de un disk si tu y adjoins un disk de parité et de deux disks si tu en mets 2 en parité. En toute logique si tu mets en place une parité c'est que tu as un disk en spare disponible dans un tiroir dans l'éventualité où un des disks de l'array tombe en panne. Dans ce cas là le retour en fonctionnement, la durée de la panne, peut se réduire au changement de disk et la remise en place des données dans ce dernier grâce à la parité. La tolérance à la panne n'est pas une sauvegarde et ne doit pas être considérée comme telle, les sauvegardes du contenu important doivent tout de même être faites à coté. Ceci étant fixé il faut comprendre comment fonctionne la parité pour comprendre les contraintes liées. Pour chacun des disk présents dans l'array il est lu progressivement un secteur (une petite zone physique du disque) à la fois et il en est déduit un octet écrit au même endroit physique dans la parité. Le dernier octet lu est donc le dernier octet du disk le plus gros dans l'array et sa position doit pouvoir être écrite dans la parité. C'est pour cela que le disk de parité doit être au moins aussi gros que le plus gros des disques de l'array donc. Sur cette capture il faut donc que le disque de parité soit aussi gros que le Disk 1. Les secteurs de la parité sont déduit en prenant en compte le secteur au même endroit sur les autres disques. Et ça avance de secteur en secteur, à un moment il n'y a que dans le Disk 1 qu'il reste des secteurs donc au même endroit de la parité il en est déduit la même chose. La parité est terminé lorsque le dernier secteur du disk le plus grand a été traité. Donc si la parité fait le double du disk le plus gros de l'array et bien le disk de parité ne sera remplis qu'à moitié. Une autre contrainte liée à la parité est que pour chaque écriture dans un des disks de l'array il y à son interprétation déduite écrite dans la parité ce qui ralentis les débits. ------------------------------- Dans ton cas le disk que tu veux ajouter en parité, si tu en as bien un autre en spare pour réagir à la tolérance à la panne que cela apporte, doit être légèrement plus petits que le plus gros de l'array. Même pour quelques Mo de moins ça reste donc mathématiquement pas possible de le mettre en parité cf ce qui est indiqué juste avant. ------------------------------- Les pools sont quand à eux des espaces de stockage disponibles là où la "rapidité" est un critère important. Les pools sont initialement là où l'on mettait donc les SSD/NVME soit pour en faire une zone "tampon" (anciennement nommé cache) qui se vidait vers l'array à intervalles réguliers grâce au "mover", soit comme espace de stockage à long termes pour par exemple les SHARES appdata/, system/ et domains/ qui par défaut hébergent respectivement: - les dossiers persistants des containers docker - les images disques docker et libvirt - les vdisks des VM. Les sauvegardes de ton contenu le plus important ne doit pas être négligé ni même laissé à la parité cette tâche. Tu dois en mettre en place de toutes façons si tu veux sécuriser ton contenu le plus important.

Salut, règles l'heure dans ton bios.

lscpu peut te donner les specifications reconnues de ton CPU Pour voir avec un rafraichissement toutes les secondes: watch -n 1 lscpu -e=CPU,MHZ Sous la v7 beta on a du paramétrage possible dans SETTINGS > Power Mode, enfin je crois que c'est un apport de la v7: Cela place le gouverneur selon le mode de consommation. Si je place en "Best performance" j'obtiens des fréquences qui vont au taquet de la fréquence max du CPU et aussi bien au dessus de la fréquence nominale indiquée sur le Dashboard.. Du coup j'ai le choix entre 2 modes: - best power efficiency: ca veut dire que les processus mettront plus de temps à se terminer car le cpu cherchera à ne pas trop monter en fréquence. Si économie alors baisse de fréquence alors plus long à traiter les processus il me semble - best performance là il laisse monter les fréquences pour traiter les processus au plus vite

Oui l'un ou l'autre restant dans tes choix tu pars sur une configuration trés sympa vu le nombre de coeurs au total et le total en RAM que tu peux y adjoindre. Tu ne devrais pas être à l'étroit et ça devrait combler tes attentes même les futures.

Pour illustrer voici l'info que j'ai sur Dashboard: Alors que je vois sur un écran de contrôle que ca monte à > 3Ghz si besoin et jusqu'à 3.40Ghz en turbo donc comme d'aprés la fiche technique

Pour le mode turbo oui ils seront utilisés à la demande mais pas forcément visible sur la page Dashboard au niveau des stats. Tu pourras utiliser un utilitaire qui te permettra de voir la fréquence et les coeurs utilisés mais son nom m'échappe pour le moment.

Salut, je ne suis pas expert en la matière donc je ne vais donner qu'un avis utilisateur. Personnellement mon NAS sous unRAID tourne avec un N100 (4c/4t) et je fais tourner ce que tu listes avec 3 VM sous Alpine Linux. Je te dis cela en préambule pour ne pas que tu penses qu'il faille beaucoup de ressources pour arriver à ce résultat. Ce qui va consommer c'est l'intensité de l'accés à ces services. Les containers qui idle ne consomment pas de CPU mais de la RAM et comme tu n'es apparemment pas limité ce n'est pas un problème: Ceci étant dit le nombre de coeurs/threads donne plus de souplesse pour le multi-thread toutefois et tu pourrais envisager en "dédier" certains pour docker et d'autres pour VM. Ils sont tous les 3 compatibles VT-d et VT-x donc pas de soucis pour la virtualisation. D'habitude on peut se dire que qui peut le plus peut le moins mais en regardant les caractéristiques il y a un détail qui pourrait être un argument pour le Xeon E5 2650 v4 c'est son TDP plus faible que les deux autres tout en ayant une puissance intéressante. Du coup si tu te mets en tête de tenter de consommer le moins possible ce dernier semble être mieux placé sur papier. Si l'aspect consommation n'est pas un aspect crucial alors je te dirais bien de partir sur le Xeon E5 2690 v4 pour son nombre de cœurs. Pour ton usage Plex/Emby/Jellyfin/Frigate sache que aucun n'a de puce graphique il me semble donc tu vas devoir y adjoindre un GPU si tu veux soulager lors de transcodage. Envisage aussi une puce speciale pour Frigate. C'est là encore sur la question de la consommation des questions à se poser étroitement lié à la puissance de l'alimentation que tu as sur ces serveurs. Je ne t'ai pas beaucoup aidé et je suis peut-être fouillis du coup je vais lister ce qui pour moi est important de prendre en compte: - les containers ne consomment du CPU que si ils sont sollicités - les VM consomment plus de CPU que les containers docker - au plus tu as de coeurs au plus tu pourras les dispatcher pour des usages précis (os / docker / vm) - vois l'aspect consommation lié à l'alimentation fournie et le besoin d'y ajouter un GPU On arrive au Cyber Weekend patientes un peu pour avoir réduction sur la licence: https://unraid.net/pricing?via=4c3f80

Si tu mappes un dossier coté hôte tu peux le faire en read only si tu crains. Autrement si tu veux monter depuis le container un montage fuse il n'a pas forcément besoin de tourner en "privileged" tu peux aussi juste ajouter un "Extra parameter": --cap-add=SYS_ADMIN probablement nécessaire de donner /dev/fuse itoo soit en extra soit via le formulaire "+Add another..." --device=/dev/fuse

Bonsoir, pourquoi ne montes tu pas coté hôte et ensuite donnes le dossier monté en mappage vers ton container ?

Je plussoie Gunnm une fois le paramétrage passé et du temps à apprendre comment ça marche comme on apprend à parler ou à conduire une voiture unRAID fonctionne très bien. Il est vrai que si on ne veut pas apprendre il ne vaut mieux pas se lancer dans du selfhost. J'aimerais partir dans les airs mais le jour où je croise un hélicoptère j'irais pas le piloter direct... Ce que je veux dire c'est que c'est pas tout à fait honnête de remettre la faute sur l'outil quand on ne prend pas la peine de lire la notice. En notice il y en a une qui est d'ailleurs "à jour": https://docs.unraid.net Chaque image docker a son emplacement de "support" surtout pour les applications installées depuis le Community Application car le chamo "Support" est une obligation à remplir.

--réservé--

Salut, cela fait un moment donc il se peut que tu ais trouvé ta solution. Au cas où je pencherais pour un soucis d'attributions de réseau: unraid serait dans un réseau différent de ta Firestick TV. Par exemple ta Firestick connecté au wifi d'un routeur et ton unraid sur un autre;

Le terme "Grappe" s’emploie aussi dans un contexte proche qui est celui du RAID: Anglais https://www.ibm.com/docs/en/power8?topic=overview-disk-arrays Francisé https://www.ibm.com/docs/fr/power8?topic=overview-disk-arrays

Cronicle and Cronicle v2 (edge) for through ssh.

Salut. La marche à suivre semble correct. Au premier boot de ta nouvelle machine dans MAIN tu devras assigner les bons disques aux bons endroits. Je pense que ce sera la chose que tu devras faire manuellement du coup en effet c'est une bonne idée de savoir quel disque est où et donc la capture d'écran est utile.

Grappe autrement +1 pour laisser le terme original "array".

Nouveau projet - Nouveau template Si vous avez besoin d'utiliser un service dyndns vous pouvez utiliser les services gratuits et sans inscription de https://myaddr.tools Je vous propose ici un client en container docker dont sa tâche est de mettre à jour l'entrée DNS chez myaddr.tools si jamais votre ip change ou alors forcer cette mise à jour aprés x jours. Il permet aussi de le faire pour plusieurs sous domaines et pour ipv4 et/ou ipv6.

Si jamais tu n'as pas déja essayé je te propose de tester avec l'image de linuxserver pour voir. Tu l'installes mais tu indiques un autre dossier que celui que tu utilises pour la version plexinc dans /mnt/user/appdata et tu arrêtes le container plexinc

Ok alors c'est ok aussi de ce coté là avec de bonnes perfs d'ailleurs. Tu peux quitter les console.

Tu devrais avoir quelque chose du genre:

Pour la commande pacman en effet d'aprés ta dernière capture tu es sous image plexinc/pms-server qui est sur base Ubuntu et je croyais que tu étais sous la binhex qui est sous Arch. Dans la console unraid on lance un iperf3 en mode serveur et on laisse tourner: iperf3 -s Du coup pour ton container sous plexinc ce sera dans sa console on installe le nécessaire: # On passe sous bash bash # On installe iperf3 apt-get update && apt-get install -y iperf3 Dans la console Plex on lance un test client: iperf3 -c ip.de.ton.unraid

Connectivité Si tu lis depuis une machine linux tu pourrais utiliser iperf3 pour vérifier la vitesse de transfert entre ton container Plex et ta machine cliente. Tu peux vérifier déja entre le container Plex et ton unRAID: Coté unraid en console tu lances: iperf3 -s Tu laisses tourner. Dans la console de ton container Plex tu installes le paquet: pacman -S iperf3 Puis tu lances: iperf3 -c ip.de.ton.unraid Tu regardes quand la communication se fera entre les deux si tu obtiens bien des débits > au gigabit

Mode host Si ton container ne tourne pas en mode "host" essaye de le passer sur ce mode à la place de "bridge" ou de "br0".

Alors maintenant que tu es optimal pour environnement Docker avec system/ et appdata/ on peut chercher ailleurs. COTE CPU Tu peux essayer d'ouvrir une console unraid et dans cette console lancer la commande suivante: docker stats Ca va te lister tes containers actuellement en fonctionnement sur ton unraid et avec ses usages cpu et ram. Tout en laissant ouvert cette console pour avoir l'oeil dessus lances une lecture plex. Fais plusieurs tests sur plusieurs types de fichiers coté plex. Si tu peux aussi lances une lecture depuis des machines différentes pour voir si certaines sont plus fluides que d'autres. On cherche à savoir si ton container Plex coté console consomme beaucoup en lecture, proche du 100% cpu par exemple.

Oui le share system/ paramètres le pour mettre Cache uniquement en primaire et aucun secondaire, tout comme ton appdata/. Pour faire en sorte qu'il soit lui aussi en "exclusive access" et donc avec le triangle. Quand tu auras fais pour le share system/ et si tu vois bien le triangle indiquant "exclusive access" essaye de rebooter unraid et vérifier ton Plex. Une fois que ceci est fait tu seras optimal en transit fichier on pourra écarter un soucis IO d'accés fichiers et on se concentrera sur d'autres aspects.