Wann sollte Plex einen separaten Speicher- oder Datenbankserver verwenden?

Verwenden Sie einen separaten Host, wenn Speicherkapazität, Wartung oder Fehlerisolierung unabhängig von der Plex-Rechenleistung skaliert werden müssen. Verlagern Sie die Datenbank nicht nur der Ordnung halber.

Mediendaten lassen sich naturgemäß gut auslagern, da sie Kapazität und sequenziellen Durchsatz benötigen, während die Plex-Datenbank und Metadaten latenzempfindliche Statusdaten sind. Ein zweiter Host bringt zudem Abhängigkeiten bei der Netzwerkerreichbarkeit, den Berechtigungen und der Wiederherstellungsreihenfolge mit sich. Diese Architektur ist dann gerechtfertigt, wenn die zusätzlichen Abhängigkeiten eine messbare Einschränkung beheben, die sich nicht ohne Weiteres auf einem einzigen Server lösen lässt.

Massendaten vor latenzempfindlichen Statusdaten trennen

Mediendateien können auf einem NAS-Speicher liegen, während die Plex-Rechenleistung anderswo bereitgestellt wird, sofern der Netzwerkpfad ausreichend dauerhaften Durchsatz und zuverlässige Einbindungen bietet. Diese Aufteilung birgt weniger Risiken als externe App-Daten.

Die Speicherwahl sollte sich nach workloadspezifischen Anforderungen richten. Das spricht dafür, Medien mit hoher Kapazität und sequenziellem Zugriff von Statusdaten zu trennen, die auf latentezarmen Direktzugriff angewiesen sind.

Messen Sie den Mediendurchsatz während der Spitzenwiedergabe und einer großen Übertragung. Bleibt der vernetzte Medienpfad mit ausreichender Reserve stabil, hat sich die zusätzliche Komplexität der Aufteilung gelohnt.

Die Plex-Datenbank standardmäßig in Rechnernähe halten

Externe Datenbank- oder Metadatenspeicher erhöhen bei jedem Zugriff auf den Status die Netzwerklatenz und schaffen einen weiteren Ausfallpunkt. Das kann ein schlechter Kompromiss sein, wenn die lokale SSD nicht der Engpass ist.

Die Datenbanklatenz kann sich je nach Empfindlichkeit gegenüber der Speicherlatenz ändern. Deshalb sollte der Statuspfad einem Benchmark unterzogen werden, bevor er über ein Netzwerkdateisystem läuft.

Speichern Sie App-Daten lokal auf dem Plex-Compute-Host, sofern kein nachgewiesener Bedarf die Kosten für Latenz und Wiederherstellung überwiegt. Die NAS-Mediencenter-Topologie kann weiterhin große Mediendaten zentralisieren, ohne jede Zustandsdatei zentral abzulegen.

Verwenden Sie einen separaten Host, wenn unterschiedliche Fehlerdomänen erforderlich sind

Ein Speicherhost kann unabhängig gewartet oder erweitert werden, und ein Compute-Host kann ersetzt werden, ohne den Medienpool zu verschieben. Diese Trennung ist wertvoll, wenn für jede Rolle ein klares Wiederherstellungsverfahren festgelegt ist.

Die Aufgabentrennung ist nur dann hilfreich, wenn Dienstabhängigkeiten ausdrücklich festgelegt sind, sodass ein Host neu gestartet oder ersetzt werden kann, ohne dass über das Netzwerk hinweg versteckte Zuständigkeiten für den Zustand entstehen.

Dokumentieren Sie die Startreihenfolge, die Mount-Abhängigkeiten und das Verhalten der lokalen Wiedergabe, wenn der Speicherhost nicht verfügbar ist. Wenn die Wiederherstellung manuelle Pfadanpassungen erfordert, vereinfachen Sie die Trennung.

Featured

ZimaCube 2 persönliche Cloud-NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verwechseln Sie einen separaten Host nicht mit einem Backup

Das Verschieben von Medien auf ein NAS erstellt keine zweite Kopie. Der entfernte Speicher kann weiterhin die einzige Kopie sein und somit einen einzelnen Datenverlustpunkt darstellen.

Das Backup-Design sollte Speicher für Sicherungskopien vom primären Speicher trennen. Planen Sie daher zusätzlich zur Trennung der Topologie eine externe oder unabhängige Wiederherstellungskopie ein.

Testen Sie die Wiederherstellung des Plex-Zustands und mindestens eines repräsentativen Medienpfads, ohne auf den aktiven Speicherhost angewiesen zu sein. Die Architektur ist nur dann ausfallsicher, wenn die Trennung des Speichers und die Sicherung ausdrücklich vorgesehen sind.