Ich muss 25 Millionen Fotos in 4 Größen speichern = insgesamt 100 Millionen Dateien. Die Dateigröße variiert zwischen 3 KB und 200 KB pro Datei und der genutzte Speicherplatz beträgt zu Beginn etwa 14–15 TB.
Unser Ziel ist es, die Daten auf 2–4 Servern verfügbar zu haben und sie über einen lokalen, schnellen Webserver (nginx oder lighthttpd) bereitzustellen. Wir müssen so viele Anforderungen/Sekunde wie möglich bereitstellen.
Mein Plan ist, ein 2U-Servergehäuse von Intel mit 12 x 2 TB (WD RE4) mit Raid 6 (oder FS mit Redundanz??) für die Daten und 2 x 60 GB SSD für das Betriebssystem zu verwenden. Ist das eine gute Lösung? Jetzt: Ich habe den Adaptec 5805ZQ gefunden, der SSD-SLC-Laufwerke für den Cache der am häufigsten verwendeten Dateien verwenden kann. Irgendwelche Vorschläge dafür?
Welche Lesecachegröße muss ich wählen?
Was ist die beste Methode zur Gewährleistung von Redunanz und Lastverteilung, wenn ich 2–4 solcher Server plane?
Was sind die Vor- und Nachteile von Cluster- und verteiltem FS im Hinblick auf unser Ziel?
Antwort1
Wenn es sich um eine Neuentwicklung handelt, dannIch würde hierfür unbedingt die Cloud nutzen100 Millionen Dateien sind eine Menge Daten. Es wäre eine erhebliche Verbesserung, die redundante Speicherung dieser Daten beispielsweise auf Amazon S3 auszulagern.
Da wir von 100 Millionen Dateien sprechen, können wir wohl davon ausgehen, dass einige Teile des Datensatzes „heiß“ (häufig angefordert) und die meisten Teile kalt sein werden. Aus diesem Grund ist Caching wirklich wichtig.
Eine Übersicht, wie dies auf Amazon Web Services erfolgen könnte:
- Erste Schicht:Von Amazon verwaltetes Elastic Load Balancing und Amazon CloudWatch-Überwachung für einige kleine EC2-Instanzen mit nginx oder Apache. Diese Server sind nur einfache Load Balancer mit statischen Konfigurationsdateien, sodass Cloudwatch sie für uns überwachen und automatisch neue Instanzen starten kann, wenn eine davon abstürzt.
- Aus der ersten Schicht:Konsistentes Hasting basierend auf der Anforderungs-URL (Dateiname)zu einer Schicht von Cache-Servern. Sie möchten Hashing basierend auf Dateinamen, um sicherzustellen, dass jede Datei nicht viele Male zwischengespeichert wird (was Ihre Cache-Trefferquote verringert), sondern dass bei N Cache-Servern jeder Server 1/N des Adressraums verarbeitet.
- Zweite Schicht:Cache-Server. Ihre Cache-Server sind EC2-Instanzen mit mehr Speicher und Squid oder Varnish oderApache Traffic ServerCache installiert.
- Aus der zweiten Ebene: Einfaches altes HTTP zum Amazon S3-Dateispeicher.
Da dieses Setup lose gekoppelt ist,die horizontale Skalierung ist einfach(was Skalierungsprobleme angeht).
Wie schnell es ist, hängt stark vom Verhältnis zwischen heißen und kalten Daten ab. Wenn Ihre Arbeitslast hauptsächlich aus heißen Daten besteht, wäre ich nicht überrascht, wenn Sie mit nur zwei kleinen EC2s mit Lastausgleich und zwei EC2-Instanzen mit großem Arbeitsspeicher-Cache deutlich über 10.000 Anfragen/s erreichen würden.
Antwort2
SSDs für das Betriebssystem selbst sind übertrieben, es sei denn, Sie möchten wirklich 30 Sekunden schneller booten. Besorgen Sie sich einfach ein paar kleine SAS-Laufwerke, das sollte mehr als genug sein.
In Bezug auf den Cache hängt die Nützlichkeit des Caches vom Arbeitssatz ab. Sollen die Anfragen für die Bilder also gleichmäßig auf alle Bilder verteilt werden oder erwarten Sie, dass die meisten Anfragen für eine kleine Teilmenge gelten? Im letzteren Fall könnte ein Cache nützlich sein, im ersteren nicht so sehr. Beachten Sie, dass der Cache auf dem Festplattencontroller hauptsächlich zum Zwischenspeichern von Schreibvorgängen nützlich ist (wenn der Cache nichtflüchtig ist), was für fsync()-intensive Anwendungen wie Datenbanken hilfreich ist. Beim Bereitstellen von Bildern vermute ich, dass der Nutzen nicht so groß sein wird.
Ein Problem bei Cluster- und verteilten FS besteht darin, dass sie komplizierter einzurichten sind und insbesondere verteilte FS weniger ausgereift sind als „normale“ Single-Node-FS. Ein Cluster-FS bedeutet in der Regel gemeinsam genutzten Speicher, was ein relativ teures SAN bedeutet, wenn Sie einzelne Ausfallpunkte vermeiden möchten.
Eine Alternative wäre, einen Cluster einzurichten, auf dem eine Art Amazon S3-ähnliches System läuft, das einen über HTTP zugänglichen verteilten und replizierten Schlüssel-Wert-Speicher bereitstellt. Beispiel:OpenStack-Speicher.
Antwort3
Viel hängt davon ab, wie häufig diese Elemente verwendet werden. Wenn Sie davon ausgehen können, dass ein kleiner Prozentsatz davon gleichzeitig sehr aktiv ist, sollten Sie Varnish für die Frontend-Verarbeitung in Betracht ziehen, wobei die Lastverteilung auf Ihre nginx/lighttpd-Backends erfolgt. Da häufig verwendete Bilder zwischengespeichert werden, ist die Festplattengeschwindigkeit etwas weniger wichtig.
Wenn die Bilder jedoch nicht wiederholt angefordert werden und Caching keine große Verbesserung bringen würde, würden nginx/lighttpd auf einem oder zwei Servern ausreichen. Sie müssen auch die Bandbreite berücksichtigen, die Sie bereitstellen werden. 800 MB/s einer kleinen Teilmenge Ihres Datensatzes könnten problemlos vom Betriebssystem zwischengespeichert werden. 800 MB/s einer riesigen Teilmenge Ihres Datensatzes führen wahrscheinlich zu einem IO-Engpass, da Sie die Daten nicht schnell genug von der Festplatte holen können, um sie bereitzustellen. In diesem Fall müssen Sie Ihr System in genügend Teile aufteilen, um über die IO-Bandbreite zu verfügen.
Auch wenn Sie RAID 6 verwenden, ist dies kein Ersatz für Backups. Planen Sie daher eine ähnliche Maschine für Backups oder ggf. als Failover-Speicherserver ein.
Antwort4
Ich würde einen benutzerdefinierten Cluster anstelle eines verteilten FS wählen, da dieser einfacher zu verstehen und zu beheben ist und trotzdem funktioniert. Die Zuverlässigkeitseinbußen bei Ihrem eigenen Cluster liegen auf der Hand, während es eine Aufgabe für sich ist, herauszufinden, wie ein verteiltes FS auf einen ausgefallenen Server oder einen ausgefallenen Switch reagiert.
Eine mögliche Lösung für Ihr Problem besteht darin, das gesamte Fotoarchiv in Teile (sagen wir 2 Teile) aufzuteilen und die Teil-ID in der URL explizit anzugeben (z. B. indem Sie daraus eine Subdomain oder einen GET-Parameter machen, der sich mit regulären Ausdrücken leicht extrahieren lässt). Dann haben Sie 4 Speicherserver mit Fotos (2 Server für jeden Teil). Verwenden Sie den fünften Server als Reverse-Proxy, der die Last verteilt und ausgleicht. Alle fünf Server können lighttpd ausführen. Ich schlage also eine sehr dumme, aber funktionierende Lösung vor (für die Firma, in der ich gearbeitet habe – mit einer Gesamtlast von ~5000 Anfragen pro Sekunde, Dateien mit einer Größe von 3-10 KB, insgesamt 8 TB eindeutigen Dateien, Servern aus 24 Backends, die jedoch einen benutzerdefinierten HTTP-Daemon anstelle von lighttpd ausführen).
Was die Festplatten und den RAM betrifft: Wir haben auf jedem Server ein Software-RAID-0 aus vier schnellen, aber billigen SATA-Festplatten verwendet (wenn eine Festplatte ausfällt, können alle Daten trotzdem von einer Replik auf einem anderen Server kopiert werden) sowie eine benutzerdefinierte Lösung, um den gesamten Server nach einem einzigen Lesefehler offline zu schalten. RAID-5 und RAID-6 sind geschwindigkeitsmäßig sehr schlecht, selbst wenn eine Festplatte ausfällt, verwenden Sie sie bitte nicht. Auf den Inhaltsservern ist viel RAM (als Festplattencache) unerlässlich, suchen Sie nach 24 GB oder mehr. Stellen Sie sich selbst dann auf eine Aufwärmzeit von 30 Minuten ein. Wenn Sie auf dem Reverse-Proxy lighttpd verwenden, berücksichtigen Sie bitte, dass es die gesamte Upstream-Antwort so schnell wie möglich in den RAM puffert und viel Zeit damit verbringen kann, das zwischengespeicherte Foto an jemanden per DFÜ oder GPRS zu senden (und während dieser Zeit diesen Puffer im RAM benötigt). Wir haben auch 24 GB genommen, nur um identische Konfigurationen zu haben, aber ich bin mir nicht sicher, ob das übertrieben ist. Ein speicherbasierter HTTP-Cache auf dem Reverse-Proxy ist nicht unbedingt erforderlich (auch wenn Hot Images vorhanden sind!), da der vom Betriebssystem bereitgestellte Festplattencache auf den Backends genauso gut funktioniert.
So stellen Sie sicher, dass alle Backends, die denselben Teil Ihres Archivs bedienen, dieselben Daten haben: Das ist ganz einfach. Wenn Sie Fotos veröffentlichen, kopieren Sie sie einfach auf alle Server. Verwenden Sie dann rsync für alte Teile des Archivs, um etwaige Abweichungen zu korrigieren, und machen Sie so eine Kopie zur Masterkopie.