Rockhound schrieb:
Schwafel-oh-schwafel. Plex kann mit einem single-core zufrieden laufen oder einen Mehrkerner mit hohem Takt benötigen oder irgendwas dazwischen. Das allerwichtigste Kriterium verschweigst du nämlich: Transkoding ja oder nein und über welche Auflösungen & Bitraten und wie viele transcodings parallel reden wir denn? Das Thema der "notwendigen" CPU für Plex wird in jedem aber auch wirklich jedem Forum dieser Welt was sich irgendwie mit Computern & Technik beschäftigt im Schnitt einmal pro Monat durchgekaut. Eigenrecherche ist dein Freund.
Rockhound schrieb:
Web-Server (Apache, mySQL, PHP usw..)
Aha und eher simple Queries auf die DB oder komplexe Abfragen? Wie groß sind die zu erwartenden Datenbanken? Ein paar hundert MB oder dutzende GB? Kommen da noch irgendwelche serverseitigen Aufgaben hinzu die irgendeinen nicht optimierten Javascript-Müll ausführen sollen? Wie viele User/Clients sollen da so parallel zugreifen? 1? 10? 50? 100? 1000?
Rockhound schrieb:
VMs zu Testzwecken (Windows Server, Linux) eher Spielerei & Hobby
Auch hier gilt: Ein aktueller Windows Server 2016 oder neuer braucht wenig. Selbst als Domain Controller kann man den mit 1-2 vCPUs und 2-4 GB Ram komplett betreiben und merkt es nicht. Relevant sind die Aufgaben und Programme die darauf laufen sollen.
Hier läuft mit einem Pentium G4600 (2C4T, 3,6GHz) ein DIY-NAS mit ZFS sowie 3 VMs (eine kleine mariadb für diverses), ein Webserver für Monitoring der restlichen "IT" sowie diverse Automatismen und Scripte sowie mehrere TSDBs zur Visualisierung verschiedenster Messdaten und dann noch eine VM mit einem Standard Ubuntu von der ein thin-client per VNC zugreift zum browsen, mailen, etc.
Die durchschnittliche Auslastung liegt bei 20% im normalen Betrieb.
Zum Stromverbrauch: Kommt immer auf die Anzahl der Disks an und ob das sparsame NAS Laufwerke sind, ggf. inklusive Helium oder eher nicht und sich die HDDs schlafen legen können sprich in den spindown gehen können und ob irgendwelche anderen Dienste noch laufen.
Zum Thema WOL: Siehe beliebigen passenden Wiki-Artikel, RFC oder vergleichbares: Wake on LAN funktioniert nur im gleichen Subnetz. Wenn du das von 'außerhalb' machen willst bleibt dir entweder nur ein VPN oder du brauchst einen passenden Service/Dienst der auf Anfragen von außerhalb lauscht und dann das eigentliche WOL Paket sendet oder per Port-Forwarding. Wichtig: Wenn du das ohne Authentisierung bastelst kann es jeder, nicht nur du aber als Fachinformatiker brauche ich dir das ja hoffentlich nicht sagen
Zur Videobearbeitung: Ob du da wirklich 10G und so hohe Bandbreiten benötigst ist das eine. Was du aber auf jeden Fall benötigst eine niedrige Latenz und hohe IOPS. Beides haben HDDs eher nicht, sprich wir reden über SSDs oder zumindest ein Speichersystem aus HDDs und SSDs (btrfs oder zfs bietet sich da an) oder vergleichbares das SSDs als Cache verwenden kann (bcache oder lvmcache) und je nach Benchmark oder Anwendungsfall ist mal das eine und mal das andere flott dabei.
10G NICs, zumindest welche mit Kupfer, sind jetzt auch nicht sonderlich energiesparsam. Bevor du also Geld aus dem Fenster wirfst solltest ggf. klären ob du die Bandbreite benötigst oder ob du eher ein Latenz- & IOPS-Problem hast. Falls Bandbreite ist 10G natürlich eine Option, alternativ eine dual- oder quadport 1G Karte und du verwendest
SMB Multichannel (funktioniert mit jedem zeitgemäßen Windows, Linux und *BSD). Ist in der Anschaffung eventuell etwas günstiger und vermutlich auch geringerer Stromverbrauch (reine Vermutung/Annahme). Nachteil sind die höhere Anzahl an Kabeln und es werden natürlich mehr Switchports benötigt.
Sollte Bandbreite nicht der Flaschenhals sein sind wir also wieder bei Latenz und IOPS und helfen nur SSDs only oder HDDs + SSDs als Cache.
Apropos Cache: Die allermeisten machen falsche Annahmen was dieses Thema angeht und denken dabei an vorauseilendes lesen von Daten oder ähnlichem aber so ziemlich alle Cache-Lösungen arbeiten blockbasiert und beschleunigen die zuletzt gelesenen bzw. am häufigsten gelesenen Blöcke, zumindest was die Read-Caches angeht. Beim schreiben hast halt die Gefahr der Datenkorruption bei plötzlichem Ausfall des Cache-Devices (daher spiegeln), Stromausfall, Netzteilschaden etc. sofern nicht entsprechende Vorkehrungen getroffen werden.
Wenn du also über längere Zeit immer am gleichen Video etwas änderst UND dein Cache größer ist als das Video dann kann dies etwas bringen. Bedenke bitte nur: Read- und Write-Caches sind in der Regel getrennt.
Ursprüngliches Video wird erstmalig geladen > Blöcke werden (zusätzlich) im Read-Cache nach erstem lesen abgelegt. Änderungen gehen aber in den Write-Cache und dann auf die HDDs und werden von dort wieder gelesen wenn benötigt und landen dann im Read-Cache und so weiter und so fort...
Des Weiteren kommt noch hinzu, dass solche Caches je nach Umsetzung nicht persistent sind und somit keinen Reboot 'überleben'.
Deutlich deutlich sinnvoller wäre dann z.B. einmal die HDDs und zusätzliche eine (oder falls notwendig mehrere) SSDs auf denen die VMs liegen sowie eine Arbeitskopie des oder der Videos, die du gerade bearbeiten willst. Dann können die HDDs z.B. in den spindown gehen wenn sie nicht benötigt werden wobei ich das auch nicht zu aggressiv einstellen würde denn auch das geht nicht unendlich oft.
