Ich habe eine Website, die durchschnittlich 50 Millionen Zugriffe pro Tag hat und in den nächsten 3 Monaten über 100 Millionen Zugriffe pro Tag haben sollte. Wir versuchen, GlusterFS v 3.0.0 zu verwenden (mit den neuesten Patches vom 17.01.2010).
Derzeit haben wir gerade auf eine Load Balancer-Umgebung aktualisiert, die über 3 physische Hosts mit 6 Xen-Server 5.5u1 VMs (2 auf jedem Host) verfügt, um den Webseitenverkehr abzuwickeln. Jede Maschine verfügt über 6 lokale Raid-6-Speicherlaufwerke (7200RPM-SATA). Die alte Maschine, von der wir kamen, hatte 1 gespiegeltes SAS 10k-Laufwerk.
Wir haben derzeit auch GlusterFS mit 3 Bricks eingerichtet, einen auf jedem Host, und es bedient die 6 VMs als Clients. Beim Testen schien alles in Ordnung zu sein. Als wir jedoch in die Produktion gingen, schien es, als stünden einfach nicht genügend I/Os zur Verfügung, um den Datenverkehr selbst bei über 15 Millionen Zugriffen zu bewältigen. Wochen zuvor konnte unser alter Server maximal 20 Millionen Datenverkehr bewältigen.
Gibt es empfohlene Konfigurationen für eine solche Anwendung oder Dinge, die man beachten sollte, die aus der Dokumentation unter gluster.org für eine Site unserer Größe nicht hervorgehen?
Antwort1
RAID-6 mit 6x7,2krpm-Laufwerken ohne Schreibcache (?) hatschrecklichSchreibleistung, so schrecklich, dass es die Festplatten wahrscheinlich so sehr belastet, dass auch die Leseleistung wirklich beeinträchtigt wird, wenn Ihre App eine gesunde Mischung hat. Ich meine, realistisch gesehen sehen Sie sich etwa 250 zufällige IOPS bei einer 80/20-Aufteilung von Lesen/Schreiben aus diesem Array an. Wenn Sie mehrere hundert HTTP-Anfragen pro Sekunde stellen, wird etwas so Triviales wie das Apache-Zugriffsprotokoll das wie ein DoS-Angriff belasten.
Wenn möglich, wiederholen Sie diese als RAID 10. Das kostet zwar etwas Rohspeicher, hat aber enorme Auswirkungen auf die E/A-Leistung. Und wenn Sie einen batteriegestützten Schreibcache auf den RAID-Karten bekommen, macht das einen großen Unterschied.
Ich bin nicht besonders vertraut mit Glusterfs, aber alle verteilten Dateisysteme haben tendenziell das gleiche Grundproblem: Netzwerklatenz + komplexe Sperren = schlechte Leistung, insbesondere bei kleinen Dateien und insbesondere bei großen Schreiblasten.
Langsamer Festplatten-E/A und ein langsames Dateisystem – dieses Cluster-Design ist einfach nicht für die Arbeitslast geeignet. Ist es zu spät, die Server oder zumindest die Festplattensubsysteme zurückzugeben? Wenn dies die primäre Plattform eines Unternehmens mit hohem Umsatz ist, sollten Sie wirklich einen Fachmann hinzuziehen.
Antwort2
Über welches Medium leiten Sie Ihren GlusterFS-Verkehr? Wenn es Ethernet ist, wird Ihre Konfiguration aufgrund der TCP/IP-Overheads stark eingeschränkt. GlusterFS ist dort nicht das effizienteste. Wo es wirklich glänzt, ist über RDMA. Sie können dies entweder mit Infiniband oder 10GigE erreichen.
Mir ist auch nicht ganz klar, warum Sie sich entschieden haben, auf jedem physischen Host zwei virtuelle Hosts zu platzieren, wenn sie doch alle die gleichen Aufgaben erfüllen. Warum lassen Sie sie nicht einfach auf dem Bare Metal laufen und vermeiden den Overhead?
Antwort3
Welche Version von GlusterFs verwenden Sie? GlusterFS 3.0.0 ist eine Hauptversion und bietet viele Verbesserungen, darunter eine verbesserte Leistung bei kleinen Dateien.
Es gibt viele Leistungsübersetzer in GlusterFS, die für verschiedene Arbeitslasten optimiert werden können. Zur Verbesserung der Leseleistung haben wir beispielsweise einen Read-Ahead-Übersetzer und zur Verbesserung der Schreibleistung einen Write-Behind-Übersetzer. io-cache ist ein weiterer Leistungsübersetzer, der zum Zwischenspeichern verwendet werden kann.
Welche Art von Setup verwenden Sie? Verwenden Sie Replikation oder Verteilung oder beides? Was ist Ihr Netzwerk-Backend? Haben Sie die Netzwerk-/Festplatten-E/A zwischen den alten und den neuen Servern getestet, um Engpässe zu vermeiden?
Wenn Sie Ihre Volume-Dateien mit uns teilen können, können wir Ihnen helfen, Ihre Konfigurationsdateien für eine optimale Leistung Ihrer Workloads zu optimieren.
Nur zur Information: Wir bieten ein 30-tägiges kostenloses Test-Support-Abonnement[1] an, bei dem Sie schnell und umfassend Antworten auf Ihre Fragen erhalten.
Grüße, Sachi
Antwort4
Ohne weitere Einblicke in Ihr Setup (ist Ihre Website beispielsweise statisch oder dynamisch? Finden Datenbanktransaktionen auf den Servern unter Verwendung desselben Speichersubsystems statt?), ist RAID 6 im Allgemeinen eine schlechte Wahl für die Schreibleistung, ganz zu schweigen davon, wenn Sie durch Gluster noch mehr Komplexität einführen. Möglicherweise laufen zwei Sätze von Schreibstreifenübersetzungen ab, einer auf Gluster-Ebene und einer auf Controller-Ebene. Dann haben Sie zwei Paritätsberechnungen, die die Dinge verlangsamen und zu E/A-Blockierungen führen, es sei denn, Sie haben einen großen Schreibcache und Zeiträume mit geringer E/A-Aktivität.
Ich würde Ihnen empfehlen, auf RAID 10 umzusteigen und dies entweder mit Fibre Channel oder mehreren verbundenen GigE-Links zu unterstützen.