Der große Seagate Barracuda Testbericht – 2018

Aus gegebenem Anlass nehmen wir die aktuellen Topmodellen der Seagate Guardian-Reihe genauer unter die Lupe und unterziehen sie einem ausführlichen Test. Hierbei interessieren uns insbesondere die Benchmark bzw. Performanceergebnisse der einzelnen Festplatten. Größer, besser, schneller lautet hier die Devise. So bietet Seagate in der Barracuda-Pro Reihe mittlerweile auch für den Desktop-Einsatz Speichergrößen bis zu 12TB (ST12000DM0007), welche bei anderen Herstellern nur Enterprise-Kunden vorbehalten sind. Dank einer Helium-Füllung hat es Seagate geschafft bei gleicher Performance die Leistungsaufnahme gegenüber älteren Modellen deutlich zu senken.

Seagate Barracuda

Wer nach einer neuen Festplatte für Zuhause sucht, der stößt früher oder später auf die Seagate Barracuda, welche mit bis zu 4TB Speicherplatz angeboten wird. Die Preise für das kleinste Modell (1TB) starten bei ca. 45€ und liegen damit ungefähr auf dem gleichen Niveau wie das Äquivalent von Western-Digital (WD Blue 1TB). Etwas verwirrt hat uns bei der Recherche, dass Seagate nur die Pro-Variante ausdrücklich mit 7200rpm bewirbt. Ein Blick in das englischsprachige Benutzerhandbuch verrät aber, dass auch die normalen Barracudas mit 7200 Umdrehungen pro Minute laufen. Wir vermuten, dass das von Seagate marketingtechnisch bewusst etwas unklar dargestellt wird, um Kaufanreize für das höherpreisige Pro-Modell zu schaffen.

Seagate bewirbt die Festplatte für Desktop-Computer und Homeserver. Gibt allerdings als maximale Belastung 2.400 Betriebsstunden im Jahr an. Offensichtlich geht Seagate davon aus, dass Homeserver in der Regel nicht 24/7 laufen.

Technische Daten (ST2000DM006):

Cache 64MB
Bytes pro Sektor 4.096
Schnittstelle SATA mit 6 Gbit/s
Maximale Datenübertragungsrate 210 MB/s
Stromverbrauch im Betrieb 5,4 W
Betrieb in Stunden pro Jahr 2400
Garantie 2 Jahre

 

Benchmark (ST2000DM006):

Die Benchmarkergebnisse der günstigen 2-TB-Festplatte können sich durchaus sehen lassen. Der vom Hersteller angegebene maximale Datendurchsatz von 210 MB/s konnte im Test erreicht werden. Beim Lesen und Schreiben von kleinen Random-Files macht die Platte ebenfalls eine gute Figur. Hier kann sie jedoch nicht mit den Werten der fast doppelt so teuren Western-Digital Black (WD1003FBYZ-010FB0) mithalten. Aufgrund des enormen Preisunterschiedes ist dies jedoch zu verschmerzen.

Seagate Barracuda-Pro

Die Festplatten aus der Barracuda-Pro Reihe sind mit bis zu 12TB Speicherplatz zu haben und starten preislich bei ca. 125€ für das kleinste (2TB) Modell. Damit kosten sie fast doppelt so viel, wie die Einstiegsmodelle. In unserem Test möchten wir unter anderem herausfinden, ob dieser Preis gerechtfertigt ist. Im Gegensatz zu den einfachen Barracudas, wird hier von Seagate ausdrücklich mit 7200 U/min geworben. Die Festplatten sind außerdem für den Dauerbetrieb ausgewiesen und haben eine beschränkte Herstellergarantie von fünf Jahren.

Technische Daten (ST4000DM006):

Cache 128MB
Bytes pro Sektor 512
Schnittstelle SATA mit 6 Gbit/s
Maximale Datenübertragungsrate 220 MB/s
Stromverbrauch im Betrieb 6,7 W
Betrieb in Stunden pro Jahr 8760
Garantie 5 Jahre

 

Benchmark (ST4000DM006):

Getestet haben wir die 4-TB große ST4000DM006. Die Testergebnisse waren durchweg überzeugend. Mit einer vom Hersteller angegebenen maximalen Datenübertragungsrate von 220MB/s liegt die Barracuda-Pro-Festplatte nur unwesentlich über dem Wert des günstigeren Pendants aus der Standardreihe. Deutlich überlegen ist sie allerdings beim zufälligen Lesen und Schreiben von vielen kleinen Dateien.  Hier sind die Ergebnisse beinahe doppelt so gut, wie bei der vorher getesteten Einsteigerplatte. Gerade bei Datenbankanwendungen lohnt es sich also den Preisaufschlag in Kauf zu nehmen. Außerdem unterliegen die Geräte der Pro-Reihe laut Seagate deutlich strengeren Qualitätskontrollen. Das wird insbesondere für Anwender interessant sein, welche auf eine besonders hohe Zuverlässigkeit angewiesen sind. Sollte es innerhalb der ersten zwei Jahre zu Datenverlust kommen, kann man die „Seagate Rescue Data Recovery“-Option in Anspruch nehmen und die Festplatte bei Seagate einschicken. Dort versucht man dann eine Datenwiederherstellung im Labor. Diesen Service mussten wir glücklicherweise noch nicht in Anspruch nehmen.

 

Benchmarkergebnisse:

 

Fazit:

Beide getesteten Seagate-Festplatten bieten eine ordentliche Leistung und schonen dabei den Geldbeutel. Insbesondere die Pro-Variante überraschte uns mit außergewöhnlich guten Benchmarkergebnissen gegenüber der preislich vergleichbaren Western-Digital Black. In der Vergangenheit ist Seagate allerdings mit einer deutlich höheren Ausfallrate gegenüber anderen Herstellern aufgefallen. Es bleibt abzuwarten, ob dieses Problem mittlerweile der Vergangenheit angehört oder immer noch Verbesserungsbedarf besteht. Wir werden unsere Test-Platten in den kommenden Monaten rund um die Uhr arbeiten lassen und diesen Testbericht zu gegebener Zeit aktualisieren.


Zabbix OpenVPN Client Graphs

Verwundert habe ich festgestellt, dass es noch gar kein brauchbares Zabbix Template für die grafische Darstellung der verbundenen OpenVPN Clients gibt. Jedenfalls keines, was meinen Vorstellungen entspricht.

Ich habe mir deshalb ein Template erstellt:
Download Zabbix Template
Download userparameter_openvpn.conf (ggf. den Pfad zu OpenVPN anpassen)

Das Template einfach in Zabbix importieren und die userparameter Datei im Agentverzeichnis speichern (z.b. unter /etc/zabbix/zabbix_agentd.d/).
Anschließend den Zabbix Agent neu starten, dem Host das gerade importierte Template zuweisen und nach spätestens 20 Minuten werden die Graphs erstellt. Wer nicht warten möchte, kann den „Update interval“-Wert in der discovery Regel herabsetzen, wodurch die OpenVPN Server schneller erkannt werden.

Ergebnis:


Hochverfügbares WordPress-Cluster erstellen mit Jelastic

Der Schaden eines Komplettausfalls ist für jede Webseite immens. Einbrechende Besucherzahlen und Abstrafungen durch Suchmaschinenbetreiber sind die unmittelbaren Folgen. Deshalb sind Hochverfügbare-Dienste heute nicht mehr nur für große Unternehmen relevant.

Die sichere und stabile Konfiguration einer solchen Hochverfügbarkeitslösung ist jedoch nicht selten mit hohem Aufwand und erheblichen Kosten verbunden. Deshalb möchte ich in dieser kurzen Anleitung zeigen, wie sich ein hochverfügbares WordPress-Cluster in nur zwei Minuten mit Jelastic erstellen lässt.

 

WordPress-Cluster als fertigen Installer

Über den Marketplace im Jelastic Dashboard lässt sich das Paket WordPress-Cluster installieren.

Jelastic-Marketplace

Automatische-Installation

Die automatische Konfiguration der erforderlichen Instanzen dauert in der Regel 1-2 Minuten. Anschließend erhält man direkt den erforderlichen Admin-Zugang zu der WordPress-Installation.

Das hochverfügbare WordPress-Cluster besteht nun aus den folgenden Instanzen:

 

Nginx Load-Balancer

Die Lastverteilung erfolgt über zwei Nginx Load-Balancer, welche den Besuchertraffic immer optimal auf die Web- und Datenbankserver aufteilen. Sollte eine der Instanzen ausfallen, wird der Traffic automatisch umgeleitet, sodass es für die Webseitenbesucher zu keiner Beeinträchtigung kommt.

Nginx Webserver mit PHP

Zwei perfekt aufeinander abgestimmte Nginx-Instanzen dienen als Webserver mit PHP. Die Konfiguration der beiden Webserver ist bereits bestmöglich auf den Einsatz mit WordPress ausgerichtet.

MySQL-Datenbankserver

Natürlich sind auch die Datenbankserver redundant aufgebaut und von Jelastic vorkonfiguriert.

 

Fertig!

Nach nur wenigen Minuten steht eine hochverfügbare WordPress-Installation bereit für dessen Einrichtung und Konfigurations normaleweise Stunden erforderlich gewesen wären.

 

Falls Sie sich selber von dem Funktionsumfang überzeugen möchten, können Sie Jelastic unverbindlich 14-Tage kostenlos testen. Dazu benötigen Sie lediglich eine Email-Adresse, um sich im Dashboard zu registrieren.


Varnish unter Plesk samt SSL-Unterstützung

Ein Kunde von uns wollte Varnish in Verbindung mit Plesk betreiben. Er hat sich dafür an die diversen Anleitungen im Internet gehalten, aber die Einrichtung scheiterte. Die meisten Anleitungen basieren darauf, dass man den Frontend-Webserver auf einen alternativen Port setzt und Varnish auf Port 80 platziert. Derartige Vorgehensweisen haben jedoch diverse Nachteile und die SSL-Unterstützung fehlt.

Was ist Varnish und was bringt es?

Varnish kann dynamische und statische Inhalte cachen und verbessert die Webseitenperformance enorm. Varnish wird ausschließlich als Reverse-Proxy betrieben. Man muss also zusätzlich einen Backend-Webserver wie Apache verwenden.
Den Cache lagert Varnish standardmäßig im Arbeitsspeicher aus. Falls dem System wenig Arbeitsspeicher zur Verfügung steht, kann man über die Konfigurationsdatei den Cache in einer Datei auslagern. Allerdings ist der Arbeitsspeicher deutlich schneller und man erreicht damit in der Regel eine bessere Performance.

Zum Vergleich habe ich eine Wordpress-Testinstallation aufgesetzt:

WordPress Ladezeit – ohne Varnish Cache WordPress Ladezeit – mit Varnish Cache
:~$ time curl -s https://wp4.linevast.de/ > /dev/null
real 0m0.942s
user 0m0.044s
sys 0m0.008s
:~$ time curl -s https://wp4.linevast.de/ > /dev/null
real 0m0.330s
user 0m0.040s
sys 0m0.012s
In der linken Spalte wurde die Seite mit geleertem Cache aufgerufen. In der rechten Spalte das Ergebnis mit Cache. Die Ladezeit hat sich durch den Varnish-Cache mehr als halbiert. Für den Test wurde WordPress mit verschiedenen Plugins installiert um realistische Ergebnisse zu erhalten.

Plesk mit Varnish: Vorgehensweise

Diese Anleitung bezieht sich auf ein gewöhnliches Plesk-Setup – sprich Nginx als Frontend und Apache als Backend-Webserver.
Falls das Setup nicht wie gewünscht funktioniert oder man es erst mal nur testen möchte, kann man das gesamte Setup mit wenigen Befehlen rückgängig machen (siehe weiter unten).

Damit SSL-Verbindungen ebenfalls cached werden und es auch keine negativen Auswirkungen in Plesk gibt, platzieren wir Varnish nicht auf dem HTTP Port 80, sondern belassen die standardmäßigen Ports wie sie sind. Stattdessen leiten wir die Verbindungen von nginx auf Varnish um.
Der Verbindungsablauf sieht dann wie folgt aus:

 

1. Installation von Varnish

Varnish ist für diverse Linux-Distributionen verfügbar. In meiner Anleitung verwende ich CentOS 7. Über das EPEL-Repository kann Varnish installiert werden.

Hinweis: Varnish auf anderen Distributionen installieren
Varnish kann auf fast allen Distributionen installiert werden. Hier eine Anleitung für Debian. Die sonstigen Informationen dieses Eintrags gelten für alle Distributionen.

2. Konfiguration von Varnish

  1. Damit Varnish weiß, ob es sich um eine HTTP- oder HTTPS-Anfrage handelt, wird Varnish auf zwei Ports gestartet. Ich habe dazu 6081 und 6080 ausgewählt.
    Dazu öffnet man die Datei /etc/varnish/varnish.params und ersetzt die Zeile VARNISH_LISTEN_PORT=6081 mit VARNISH_LISTEN_PORT=6081,:6080

  2. Damit Varnish die Anfragen richtig bearbeitet, muss man Regeln definieren. Man findet im Internet diverse fertige Regeln, beispielsweise diese hier für WordPress.
    Die Regeln müssen in der Datei /etc/varnish/default.vcl festgelegt werden. Damit alles ordnungsgemäß in Verbindung mit Plesk funktioniert, wird ganz oben in der Datei immer folgendes definiert:

Wichtig: 'SERVERIP' ersetzen
Auch hier wieder darauf achten, dass die „SERVERIP“ mit der öffentlichen IP des Servers ersetzt wird. Würde man localhost oder 127.0.0.1 konfigurieren, funktioniert es aufgrund der Vhost-Konfiguration seitens Plesk nicht.
Hinweis: default.vcl Beispiel
Eine angepasste VCL gibt es hier – diese VCL gilt nur als Beispiel und basiert auf dem oben genannten GitHub-Template. In meinem Test funktioniert WordPress und das Caching damit. Ich würde jedoch empfehlen, sich in die Varnish-Konfiguration einzulesen und die VCL selbst zu erstellen (oder zu überarbeiten).

Nachdem die beiden Konfigurationen angepasst wurden, aktivieren wir den automatischen Start von Varnish und starten den Server:

Falls Varnish nicht startet, kann man sich per journalctl -xe das Problem ansehen.

3. Erstellen eines neuen Nginx-Vhosts & SSL-Termination

Nun erstellen wir einen neuen Nginx-Vhost, welcher die Verbindungen von Varnish an Apache weiterleiten wird. Prinzipiell könnte man auf diesen Vhost verzichten und die Verbindungen von Varnish direkt an Apache übergeben. Das hätte allerdings den Nachteil, dass Apache HTTPS Verbindungen nicht mehr erkennen würde. Der Webserver würde alle Anfragen als HTTP verarbeiten. Beispielsweise würden dadurch Umleitungen von HTTP auf HTTPS in einer Endlosschleife enden, sofern per .htaccess oder PHP (wenn PHP als Apachemodul ausgeführt wird) realisiert.

Um den neuen vhost anzulegen, wird folgendes ausgeführt:

Wer möchte, kann die Proxy-Parameter seinen Bedürfnissen entsprechend erweitern. Ein relevanter Parameter wäre beispielsweise client_max_body_size.

Wichtig: proxy_pass Parameter anpassen
Beim Parameter proxy_pass muss die IP des Servers angegeben werden. Sofern mehrere IPs genutzt werden, muss für jede IP ein Vhost angelegt werden.

4. Anpassen des Plesk vhost Templates

Das vhost Template von Plesk werden wir so umkonfigurieren, dass die Anfagen von Nginx an Varnish weitergeleitet werden. Varnish wird die Anfragen anschließend wieder zurück zum zuvor erstellten Nginx-Vhost leiten, welcher wiederum die Anfragen an Apache weiterleitet. Es klingt komplizierter als es ist.

Hinweis: Änderungen im Plesk-Template nachlesen
Die geänderten Stellen wurden kommentiert, sodass man sich in den Dateien ansehen kann, was verändert wurde.

5. Webserverkonfiguration neu erstellen

Damit die Konfigurationsänderungen auf allen bestehenden Domains übernommen werden, lassen wir diese neu erstellen.

Plesk sollte den Webserver automatisch neu starten und somit die neue Webserverkonfiguration übernehmen. Sollte das nicht passieren, kann man die Webserver manuell neu starten:

6. Varnish-Cache testen & leeren

Die Konfiguration ist hiermit abgeschlossen. Ruft jetzt eine Webseite auf und beobachtet die Ausgabe von varnishstat. Relevant sind die Werte MAIN.cache_hit und MAIN.cache_miss. Nach dem ersten Aufruf befindet sich die Seite im Cache. Weitere Aufrufe sollten den Wert von MAIN.cache_hit erhöhen. Dieser Wert gibt an, wie viele Anfragen aus dem Cache geladen wurden. MAIN.cache_miss hingegen gibt an, wie viele Anfragen durch den Backend-Webserver verarbeitet wurden.

Änderungen rückgängig machen – Varnish deaktivieren

Um die Änderungen rückgängig zu machen, reichen einige wenige Befehle: