Proxy für einen lokalen Spiegel von S3-Verzeichnissen

Wir haben ein Büro, in dem die Nachfrage nach Zugriff auf große Dateien aus unseren eigenen Amazon S3-Verzeichnissen steigt. Der schnelle Zugriff darauf ist für unser Unternehmen wichtig. Wir sind daher der Meinung, dass es an der Zeit ist, Kopien der Dateien vor Ort aufzubewahren. Dies ist nicht mein Fachgebiet, daher hoffe ich auf einen Rat.

Ein "normaler" Cache allein reicht für uns nicht aus, da wir bereits die erste Anforderung für eine bestimmte Datei beschleunigen möchten. Die AWS-CLI bietet die Möglichkeit, ein lokales Verzeichnis mit S3 synchron zu halten. Daher besteht eine Idee darin, dieses Verzeichnis in Zeiten mit geringem Datenverkehr nach einem Zeitplan auszuführen und dann einen Proxy zu konfigurieren, der dieses Verzeichnis als Cache behandelt, sofern dies möglich ist.

Eine andere Idee besteht darin, Abrufanforderungen von einem Skript an einen Caching-Proxy zu senden, um den Cache nach einem ähnlichen Zeitplan warm zu halten.

Eine Einschränkung ist, dass die S3-Assets privat sind. Daher signieren wir ihre URLs, bevor wir jede Anfrage stellen. Dies bedeutet, dass der Proxy in der Lage sein muss, die lokale Kopie basierend auf der URL ohne Abfrageparameter bereitzustellen. Beispielsweise sollten beide URLs in dieselbe zwischengespeicherte / gespiegelte Datei aufgelöst werden:

• https://example.com/asset1.txt?signature=1
• https://example.com/asset1.txt?signature=2

Die Größe des Caches liegt im einstelligen Terabyte und verarbeitet den Datenverkehr für etwa 300 aktive Benutzer.

Also endlich meine Fragen:

• Klingt einer dieser Ansätze vernünftig?
• Kann jemand Proxy-Software empfehlen, die so konfiguriert werden kann, wie wir es brauchen?
• Gibt es Ressourcen, die ich konsultieren kann, um die Hardwareanforderungen für diese Last zu ermitteln?
• Irgendwelche anderen Gedanken / Vorschläge?

Wenn Sie nur Ihr lokales Repository mit dem Cloud-basierten Objektspeicher synchronisieren müssen, würde ich mir Rclone oder CloudBerry ansehen. Rclone verfügt über eine Befehlszeilenschnittstelle zum Synchronisieren von Verzeichnissen und Dateien zwischen den Clouds. Es funktioniert für die gängigsten Cloud-Speicher wie Azure, AWS (sowohl S3 als auch Glacier) usw. https://rclone.org/

Wenn Sie alle Daten in der Cloud sichern möchten, besteht auch die Möglichkeit, Sicherungen der virtuellen Bandbibliothek mit einem zusätzlichen Offload in die Cloud durchzuführen. Wenn Sie also Ihre vorhandene Infrastruktur sichern müssen, können Sie Ransomware-sichere Sicherungen mit automatischem Offload in die Cloud durchführen. Es hat Deduplizierung und Komprimierung, aber soweit ich weiß, gibt Starwind es derzeit kostenlos. https://www.starwindsoftware.com/starwind-virtual-tape-library

Beide Lösungen sind ausgereift und zuverlässig. Sie müssen nur die erforderliche Option auswählen. Hoffe es war hilfreich.

Abhängig von Ihren Anforderungen bietet Ihnen AWS Storage Gateway möglicherweise das, was Sie benötigen. Storage Gateway ist ein AWS-Angebot, das als virtuelle Maschine in Ihrer lokalen Umgebung bereitgestellt wird.

Es gibt zwei Arten von Storage Gateway, die sofort als potenziell geeignet in den Sinn kommen:

• File Gateway präsentiert einen S3-Bucket als NFS-Mount und enthält transparentes lokales Caching.

• Volume Gateway - Zwischengespeicherte Volumes werden als iSCSI-Ziel dargestellt und umfassen auch das lokale Caching von Daten, auf die häufig zugegriffen wird.

Storage Gateway hat einige Nachteile:

• Es ist NICHT für die Unterstützung von Multi-Master-Szenarien ausgelegt , daher sind Sperrmechanismen auf das Storage Gateway (und nicht auf den zugrunde liegenden S3-Bucket) beschränkt. Von beiden ist ein Multi-Master-Szenario mit File Gateway besser geeignet, da es einen RefreshCache- API- Aufruf unterstützt, der die Metadaten in Ihrer lokalen VM mit Objekten aktualisiert, die seit dem letzten Auflisten des Gateways hinzugefügt / entfernt / ersetzt wurden den Inhalt des Eimers.

• Volume Gateway bietet keinen Zugriff auf den zugrunde liegenden S3-Bucket . Während File Gateway von einem vom Kunden gesteuerten S3-Bucket unterstützt wird, wird Volume Gateway von einem AWS-gesteuerten S3-Bucket unterstützt. Dies bedeutet, dass für Volume Gateway der S3-Bucket in Ihrem Konto nicht angezeigt wird und Sie nicht als normales S3-Objekt auf die darin enthaltenen Daten zugreifen können. (Ich kann keine Dokumentation finden, die dies bestätigt, aber ich bin zu 95% sicher, dass dies korrekt ist.)

Es gibt andere Arten von Storage Gateway, und Sie können nachlesen, wie AWS Storage Gateway funktioniert .

Wenn Sie Direct Connect noch nicht verwenden , sollten Sie es für einen Zugriff auf AWS-Services mit hoher Bandbreite und geringer Latenz in Betracht ziehen. (Ich vermute, Sie verwenden es bereits angesichts der von Ihnen genannten Datenmenge.)

Bearbeiten 2018-05-21: Storage Gateway-Preise Mit Storage Gateway werden Ihnen der zugrunde liegende Speicher (Datengröße + Anforderungen) und die Datenübertragung in Rechnung gestellt. Das ist es. Jede andere Lösung, die S3 als Speicher verwendet, kostet Sie dasselbe.