Maximierung des S3 File Gateway-Durchsatzes

In den folgenden Abschnitten werden bewährte Methoden zur Maximierung des Durchsatzes zwischen Ihren NFS- und SMB-Clients, S3 File Gateway und Amazon S3 beschrieben. Die in den einzelnen Abschnitten enthaltenen Anleitungen tragen schrittweise zur Verbesserung des Gesamtdurchsatzes bei. Obwohl keine dieser Empfehlungen erforderlich ist und sie nicht voneinander abhängig sind, wurden sie auf logische Weise ausgewählt und angeordnet, sodass sie zum Testen und Optimieren von S3 File Gateway-Implementierungen Support verwendet werden. Denken Sie beim Implementieren und Testen dieser Vorschläge daran, dass jede S3 File Gateway-Bereitstellung einzigartig ist, sodass Ihre Ergebnisse variieren können.

S3 File Gateway bietet eine Dateischnittstelle zum Speichern und Abrufen von Amazon S3 S3-Objekten mithilfe der branchenüblichen NFS- oder SMB-Dateiprotokolle mit einer systemeigenen 1:1 -Zuordnung zwischen Datei und Objekt. Sie stellen S3 File Gateway als virtuelle Maschine entweder lokal in Ihrer VMware Microsoft Hyper-V- oder Linux-KVM-Umgebung oder in der AWS Cloud als Amazon-Instanz bereit. EC2 S3 File Gateway ist nicht als vollständiger NAS-Ersatz für Unternehmen konzipiert. S3 File Gateway emuliert ein Dateisystem, aber es ist kein Dateisystem. Die Verwendung von Amazon S3 als dauerhaftem Back-End-Speicher erzeugt zusätzlichen Overhead bei jedem I/O Vorgang, sodass die Bewertung der Leistung von S3 File Gateway mit einem vorhandenen NAS oder Dateiserver kein gleichwertiger Vergleich ist.

Stellen Sie Ihr Gateway am selben Standort wie Ihre Kunden bereit

Wir empfehlen, Ihre virtuelle S3 File Gateway-Appliance an einem physischen Standort mit möglichst geringer Netzwerklatenz zwischen ihr und Ihren NFS- oder SMB-Clients bereitzustellen. Beachten Sie bei der Auswahl eines Standorts für Ihr Gateway Folgendes:

• Eine geringere Netzwerklatenz bis zum Gateway kann dazu beitragen, die Leistung von NFS- oder SMB-Clients zu verbessern.

• S3 File Gateway ist so konzipiert, dass es eine höhere Netzwerklatenz zwischen dem Gateway und Amazon S3 toleriert als zwischen dem Gateway und den Clients.

• Für in Amazon bereitgestellte S3 File Gateway-Instances empfehlen wir EC2, das Gateway und die NFS- oder SMB-Clients in derselben Platzierungsgruppe zu belassen. Weitere Informationen finden Sie unter Platzierungsgruppen für Ihre EC2 Amazon-Instances im Amazon Elastic Compute Cloud-Benutzerhandbuch.

Reduzieren Sie Engpässe, die durch langsame Festplatten verursacht werden

Wir empfehlen, die IoWaitPercent CloudWatch Metrik zu überwachen, um Leistungsengpässe zu identifizieren, die auf langsame Speicherfestplatten auf Ihrem S3 File Gateway zurückzuführen sein können. Wenn Sie versuchen, festplattenbedingte Leistungsprobleme zu optimieren, sollten Sie Folgendes berücksichtigen:

• IoWaitPercentgibt an, wie lange die CPU in Prozent auf eine Antwort von den Root- oder Cache-Festplatten wartet.

• Wenn der Wert höher als 5-10% IoWaitPercent ist, deutet dies normalerweise auf einen Gateway-Leistungsengpass hin, der durch Festplatten mit schlechter Leistung verursacht wird. Diese Metrik sollte so nahe wie möglich bei 0% liegen — was bedeutet, dass das Gateway nie auf die Festplatte wartet —, was zur Optimierung der CPU-Ressourcen beiträgt.

• Sie können dies IoWaitPercent auf der Registerkarte Überwachung der Storage Gateway Gateway-Konsole überprüfen oder empfohlene CloudWatch Alarme so konfigurieren, dass Sie automatisch benachrichtigt werden, wenn die Metrik einen bestimmten Schwellenwert überschreitet. Weitere Informationen finden Sie unter Empfohlene CloudWatch Alarme für Ihr Gateway erstellen.

• Zur Minimierung empfehlen wir, für die Root- und Cache-Festplatten Ihres Gateways entweder eine SSD NVMe oder eine SSD zu verwendenIoWaitPercent.

Passen Sie die Ressourcenzuweisung der virtuellen Maschine für CPU-, RAM- und Cache-Festplatten an

Wenn Sie versuchen, den Durchsatz für Ihr S3 File Gateway zu optimieren, ist es wichtig, der Gateway-VM ausreichend Ressourcen zuzuweisen, einschließlich CPU-, RAM- und Cache-Festplatten. Die Mindestanforderungen an virtuelle Ressourcen von 4 CPUs, 16 GB RAM und 150 GB Cache-Speicher sind in der Regel nur für kleinere Workloads geeignet. Bei der Zuweisung virtueller Ressourcen für größere Workloads empfehlen wir Folgendes:

• Erhöhen Sie die zugewiesene Anzahl auf 16 CPUs bis 48, abhängig von der typischen CPU-Auslastung, die von Ihrem S3 File Gateway generiert wird. Sie können die CPU-Auslastung mithilfe der UserCpuPercent Metrik überwachen. Weitere Informationen finden Sie unter Grundlegendes zu Gateway-Metriken.

• Erhöhen Sie den zugewiesenen Arbeitsspeicher auf 32 bis 64 GB.

  Anmerkung

  S3 File Gateway kann nicht mehr als 64 GB RAM verwenden.

• Verwenden Sie NVMe oder SSD für Root-Festplatten und Cache-Festplatten, und passen Sie die Größe Ihrer Cache-Festplatten so an, dass sie dem Datenbestand entsprechen, den Sie in das Gateway schreiben möchten. Weitere Informationen finden Sie unter Best Practices zur Cache-Dimensionierung von S3 File Gateway auf dem offiziellen Amazon Web Services YouTube Services-Kanal.

• Fügen Sie dem Gateway mindestens 4 virtuelle Cache-Festplatten hinzu, anstatt eine einzige große Festplatte zu verwenden. Mehrere virtuelle Laufwerke können die Leistung verbessern, selbst wenn sie dieselbe zugrunde liegende physische Festplatte verwenden. Die Verbesserungen sind jedoch in der Regel größer, wenn sich die virtuellen Laufwerke auf verschiedenen zugrunde liegenden physischen Festplatten befinden.

  Wenn Sie beispielsweise 12 TB Cache bereitstellen möchten, können Sie eine der folgenden Konfigurationen verwenden:

  • 4 x 3 TB Cache-Festplatten

  • 8 x 1,5 TB Cache-Festplatten

  • 12 x 1-TB-Cache-Festplatten

  Zusätzlich zur Leistung ermöglicht dies im Laufe der Zeit eine effizientere Verwaltung der virtuellen Maschine. Wenn sich Ihre Arbeitslast ändert, können Sie die Anzahl der Cache-Festplatten und Ihre gesamte Cachekapazität schrittweise erhöhen und gleichzeitig die ursprüngliche Größe jedes einzelnen virtuellen Laufwerks beibehalten, um die Gateway-Integrität zu wahren.

  Weitere Informationen finden Sie unter Festlegung der Größe des lokalen Festplattenspeichers.

Beachten Sie bei der Bereitstellung von S3 File Gateway als EC2 Amazon-Instance Folgendes:

• Der von Ihnen gewählte Instance-Typ kann sich erheblich auf die Gateway-Leistung auswirken. Amazon EC2 bietet umfassende Flexibilität bei der Anpassung der Ressourcenzuweisung für Ihre S3 File Gateway-Instance.

• Die empfohlenen EC2 Amazon-Instance-Typen für S3 File Gateway finden Sie unter Anforderungen für EC2 Amazon-Instance-Typen.

• Sie können den EC2 Amazon-Instance-Typ ändern, der ein aktives S3 File Gateway hostet. Auf diese Weise können Sie die EC2 Amazon-Hardwaregeneration und die Ressourcenzuweisung einfach anpassen, um ein ideales price-to-performance Verhältnis zu finden. Gehen Sie in der EC2 Amazon-Konsole wie folgt vor, um den Instance-Typ zu ändern:

  1. Stoppen Sie die EC2 Amazon-Instance.

  2. Ändern Sie den EC2 Amazon-Instance-Typ.

  3. Schalten Sie die EC2 Amazon-Instance ein.

  Anmerkung

  Durch das Stoppen einer Instance, die ein S3 File Gateway hostet, wird der Dateifreigabezugriff vorübergehend unterbrochen. Stellen Sie sicher, dass Sie bei Bedarf ein Wartungsfenster einplanen.

• Das price-to-performance Verhältnis einer EC2 Amazon-Instance bezieht sich darauf, wie viel Rechenleistung Sie für den Preis erhalten, den Sie zahlen. In der Regel bieten EC2 Amazon-Instances der neueren Generation das beste price-to-performance Verhältnis mit neuerer Hardware und verbesserter Leistung zu relativ geringeren Kosten im Vergleich zu älteren Generationen. Faktoren wie Instance-Typ, Region und Nutzungsmuster wirken sich auf dieses Verhältnis aus. Daher ist es wichtig, die richtige Instance für Ihren spezifischen Workload auszuwählen, um die Kosteneffizienz zu optimieren.

Passen Sie die SMB-Sicherheitsstufe an

Das SMBv3 Protokoll ermöglicht sowohl SMB-Signaturen als auch SMB-Verschlüsselung, was einige Kompromisse in Bezug auf Leistung und Sicherheit mit sich bringt. Um den Durchsatz zu optimieren, können Sie die SMB-Sicherheitsstufe Ihres Gateways anpassen, um festzulegen, welche dieser Sicherheitsfunktionen für Client-Verbindungen durchgesetzt werden. Weitere Informationen finden Sie unter Einstellen einer Sicherheitsstufe für Ihr Gateway.

Beachten Sie bei der Anpassung der SMB-Sicherheitsstufe Folgendes:

• Die Standardsicherheitsstufe für S3 File Gateway ist Enforce encryption. Diese Einstellung erzwingt sowohl Verschlüsselung als auch Signierung für SMB-Clientverbindungen zu Gateway-Dateifreigaben, was bedeutet, dass der gesamte Datenverkehr vom Client zum Gateway verschlüsselt wird. Diese Einstellung wirkt sich nicht auf den Datenverkehr vom Gateway zum aus AWS, der immer verschlüsselt ist.

  Das Gateway begrenzt jede verschlüsselte Client-Verbindung auf eine einzelne vCPU. Wenn Sie beispielsweise nur einen verschlüsselten Client haben, ist dieser Client auf nur 1 vCPU beschränkt, auch wenn dem Gateway 4 oder mehr v zugewiesen CPUs sind. Aus diesem Grund liegt der Durchsatz für verschlüsselte Verbindungen von einem einzelnen Client zum S3 File Gateway in der Regel zwischen 40 und 60 MB/s.

• Wenn Ihre Sicherheitsanforderungen eine entspanntere Haltung zulassen, können Sie die Sicherheitsstufe auf „Vom Kunden ausgehandelt“ ändern. Dadurch wird die SMB-Verschlüsselung deaktiviert und nur die SMB-Signatur erzwungen. Mit dieser Einstellung können Client-Verbindungen zum Gateway mehrere V verwendenCPUs, was in der Regel zu einer erhöhten Durchsatzleistung führt.

  Anmerkung

  Nachdem Sie die SMB-Sicherheitsstufe für Ihr S3 File Gateway geändert haben, müssen Sie warten, bis der Dateifreigabestatus in der Storage Gateway Gateway-Konsole von Aktuell auf Verfügbar wechselt, und dann Ihre SMB-Clients trennen und erneut verbinden, damit die neue Einstellung wirksam wird.

Verwenden Sie mehrere Threads und Clients, um Schreibvorgänge zu parallelisieren

Es ist schwierig, mit einem S3 File Gateway, das jeweils nur einen NFS- oder SMB-Client verwendet, um jeweils eine Datei zu schreiben, eine maximale Durchsatzleistung zu erreichen, da sequentielles Schreiben von einem einzelnen Client aus ein Single-Thread-Vorgang ist. Stattdessen empfehlen wir, mehrere Threads von jedem NFS- oder SMB-Client zu verwenden, um mehrere Dateien parallel zu schreiben, und mehrere NFS- oder SMB-Clients gleichzeitig auf Ihrem S3 File Gateway zu verwenden, um den Gateway-Durchsatz zu maximieren.

Die Verwendung mehrerer Threads kann die Leistung erheblich verbessern. Die Verwendung von mehr Threads erfordert jedoch mehr Systemressourcen, was sich negativ auf die Leistung auswirken kann, wenn das Gateway nicht so dimensioniert ist, dass es der erhöhten Last gerecht wird. In einer typischen Bereitstellung können Sie mit einer besseren Durchsatzleistung rechnen, wenn Sie mehr Threads und Clients hinzufügen, bis Sie die maximalen Hardware- und Bandbreitenbeschränkungen für Ihr Gateway erreicht haben. Wir empfehlen, mit verschiedenen Thread-Zahlen zu experimentieren, um das optimale Gleichgewicht zwischen Geschwindigkeit und Systemressourcennutzung für Ihre spezifische Hardware- und Netzwerkkonfiguration zu finden.

Beachten Sie die folgenden Informationen zu gängigen Tools, mit denen Sie Ihre Thread- und Client-Konfiguration testen können:

• Sie können die Schreibleistung mehrerer Threads testen, indem Sie Tools wie Robocopy verwenden, um eine Reihe von Dateien auf eine Dateifreigabe auf Ihrem Gateway zu kopieren. Standardmäßig verwendet Robocopy beim Kopieren von Dateien 8 Threads, Sie können jedoch bis zu 128 Threads angeben.

  Um mehrere Threads mit Robocopy zu verwenden, fügen Sie Ihrem Befehl den /MT:n Schalter hinzu, der die Anzahl der Threads angibt, die Sie verwenden möchten. n Zum Beispiel:

  robocopy C:\source D:\destination /MT:64

  Dieser Befehl verwendet 64 Threads für den Kopiervorgang.

  Anmerkung

  Es wird nicht empfohlen, Windows Explorer zum Ziehen und Ablegen von Dateien zu verwenden, wenn Sie den maximalen Durchsatz testen, da diese Methode auf einen einzelnen Thread beschränkt ist und die Dateien sequentiell kopiert.

  Weitere Informationen finden Sie unter Robocopy auf der Microsoft Learn-Website.

• Sie können Tests auch mit gängigen Speicher-Benchmarking-Tools wie DISKSPD oder FIO durchführen. Diese Tools bieten Optionen, mit denen Sie die Anzahl der Threads, die I/O-Tiefe und andere Parameter an Ihre spezifischen Workload-Anforderungen anpassen können.

  DiskSpd ermöglicht es Ihnen, die Anzahl der Threads mithilfe des -t Parameters zu steuern. Zum Beispiel:

  diskspd -c10G -d300 -r -w50 -t64 -o32 -b1M -h -L C:\testfile.dat

  Dieser Beispielbefehl macht Folgendes:

  • Erzeugt eine 10-GB-Testdatei () -c1G

  • Läuft 300 Sekunden lang () -d300

  • Führt einen I/O Zufallstest mit 50% Lesevorgängen und 50% Schreibvorgängen durch (-r -w50)

  • Verwendet 64 Threads (-t64)

  • Setzt die Warteschlangentiefe auf 32 pro Thread (-o32)

  • Verwendet eine Blockgröße von 1 MB () -b1M

  • Deaktiviert das Hardware- und Software-Caching () -h -L

  Weitere Informationen finden Sie unter Verwenden von DISKSPD zum Testen der Workload-Speicherleistung auf der Microsoft Learn-Website.

• FIO verwendet den numjobs Parameter, um die Anzahl der parallel Threads zu steuern. Zum Beispiel:

  fio --name=mixed_test --rw=randrw --rwmixread=70 --bs=1M -- iodepth=64 --size=10G --runtime=300 --numjobs=64 --ioengine=libaio --direct=1 --group_reporting

  Dieser Beispielbefehl macht Folgendes:

  • Führt einen I/O Zufallstest durch (--rw=randrw)

  • Führt 70% Lese- und 30% Schreibvorgänge durch (--rwmixread=70)

  • Verwendet eine Blockgröße von 1 MB () --bs=1M

  • Setzt die I/O Tiefe auf 64 () --iodepth=64

  • Testet mit einer 10-GB-Datei (--size=10G)

  • Läuft 5 Minuten (--runtime=300)

  • Erzeugt 64 parallel Jobs (Threads) (--numjobs=64)

  • Verwendet eine asynchrone I/O Engine () --ioengine=libaio

  • Gruppiert Ergebnisse zur einfacheren Analyse () --group_reporting

  Weitere Informationen finden Sie in der Manpage fio Linux.

Schalten Sie die automatische Cache-Aktualisierung aus

Die automatische Cache-Aktualisierungsfunktion ermöglicht es Ihrem S3 File Gateway, seine Metadaten automatisch zu aktualisieren. Dies kann dazu beitragen, alle Änderungen zu erfassen, die Benutzer oder Anwendungen an Ihrem Dateisatz vornehmen, indem sie direkt in den Amazon S3 S3-Bucket schreiben und nicht über das Gateway. Weitere Informationen finden Sie unter Aktualisieren des Amazon S3 S3-Bucket-Objekt-Caches.

Um den Gateway-Durchsatz zu optimieren, empfehlen wir, diese Funktion in Bereitstellungen zu deaktivieren, in denen alle Lese- und Schreibvorgänge in den Amazon S3 S3-Bucket über Ihr S3 File Gateway ausgeführt werden.

Beachten Sie bei der Konfiguration der automatischen Cache-Aktualisierung Folgendes:

• Wenn Sie die automatische Cache-Aktualisierung verwenden müssen, weil Benutzer oder Anwendungen in Ihrer Bereitstellung gelegentlich direkt in Amazon S3 schreiben, empfehlen wir, das längstmögliche Zeitintervall zwischen den Aktualisierungen zu konfigurieren, das für Ihre Geschäftsanforderungen immer noch praktikabel ist. Ein längeres Cache-Aktualisierungsintervall trägt dazu bei, die Anzahl der Metadatenoperationen zu reduzieren, die das Gateway beim Durchsuchen von Verzeichnissen oder beim Ändern von Dateien ausführen muss.

  Beispiel: Stellen Sie die automatische Cache-Aktualisierung auf 24 Stunden statt auf 5 Minuten ein, wenn dies für Ihre Arbeitslast tolerierbar ist.

• Das Mindestzeitintervall beträgt 5 Minuten. Das maximale Intervall beträgt 30 Tage.

• Wenn Sie sich dafür entscheiden, ein sehr kurzes Cache-Aktualisierungsintervall festzulegen, empfehlen wir, das Durchsuchen von Verzeichnissen für Ihre NFS- und SMB-Clients zu testen. Die Zeit, die zum Aktualisieren des Gateway-Cache benötigt wird, kann je nach Anzahl der Dateien und Unterverzeichnisse in Ihrem Amazon S3-Bucket erheblich länger dauern.

Erhöhen Sie die Anzahl der Amazon S3 S3-Uploader-Threads

Standardmäßig öffnet S3 File Gateway 8 Threads für den Amazon S3 S3-Datenupload, was ausreichend Upload-Kapazität für die meisten typischen Bereitstellungen bietet. Es ist jedoch möglich, dass ein Gateway Daten von NFS- und SMB-Clients mit einer höheren Geschwindigkeit empfängt, als es mit der standardmäßigen 8-Thread-Kapazität auf Amazon S3 hochladen kann, was dazu führen kann, dass der lokale Cache sein Speicherlimit erreicht.

Unter bestimmten Umständen Support kann die Anzahl der Amazon S3 S3-Upload-Thread-Pools für Ihr Gateway von 8 auf 40 erhöht werden, sodass mehr Daten parallel hochgeladen werden können. Abhängig von der Bandbreite und anderen Faktoren, die für Ihre Bereitstellung spezifisch sind, kann dies die Upload-Leistung erheblich steigern und dazu beitragen, den zur Unterstützung Ihrer Arbeitslast benötigten Cache-Speicher zu reduzieren.

Wir empfehlen, die CachePercentDirty CloudWatch Metrik zu verwenden, um die Menge der auf den lokalen Gateway-Cache-Festplatten gespeicherten Daten zu überwachen, die noch nicht auf Amazon S3 hochgeladen wurden, und Kontakt aufzunehmen, Support um festzustellen, ob eine Erhöhung der Anzahl der Upload-Thread-Pools den Durchsatz für Ihr S3 File Gateway verbessern könnte. Weitere Informationen finden Sie unter Grundlegendes zu Gateway-Metriken.

Anmerkung

Diese Einstellung verbraucht zusätzliche Gateway-CPU-Ressourcen. Wir empfehlen, die CPU-Auslastung des Gateways zu überwachen und die zugewiesenen CPU-Ressourcen bei Bedarf zu erhöhen.

Erhöhen Sie die SMB-Timeout-Einstellungen

Wenn S3 File Gateway große Dateien auf eine SMB-Dateifreigabe kopiert, kann es nach einem längeren Zeitraum zu einem Timeout bei der SMB-Clientverbindung kommen.

Wir empfehlen, die Einstellung für das SMB-Sitzungs-Timeout für Ihre SMB-Clients auf 20 Minuten oder mehr zu verlängern, abhängig von der Größe der Dateien und der Schreibgeschwindigkeit Ihres Gateways. Die Standardeinstellung ist 300 Sekunden oder 5 Minuten. Weitere Informationen finden Sie unter Ihr Gateway-Backup-Job schlägt fehl oder es treten Fehler beim Schreiben auf Ihr Gateway auf.

Aktivieren Sie das opportunistische Sperren für kompatible Anwendungen

Opportunistisches Sperren oder „Oplocks“ ist standardmäßig für jedes neue S3 File Gateway aktiviert. Wenn Oplocks mit kompatiblen Anwendungen verwendet werden, fasst der Client mehrere kleinere Operationen zu größeren zusammen, was für den Client, das Gateway und das Netzwerk effizienter ist. Wir empfehlen, die opportunistische Sperre aktiviert zu lassen, wenn Sie Anwendungen verwenden, die clientseitiges lokales Caching nutzen, wie Microsoft Office, Adobe Suite und viele andere, da dies die Leistung erheblich verbessern kann.

Wenn Sie das opportunistische Sperren deaktivieren, öffnen Anwendungen, die Oplocks unterstützen, große Dateien (50 MB oder größer) in der Regel viel langsamer. Diese Verzögerung tritt auf, weil das Gateway Daten in Teilen von 4 KB sendet, was zu einem hohen I/O und niedrigen Durchsatz führt.

Passen Sie die Gateway-Kapazität an die Größe des Arbeitsdateisatzes an

Der Gateway-Kapazitätsparameter gibt die maximale Anzahl von Dateien an, für die Ihr Gateway Metadaten in seinem lokalen Cache speichert. Standardmäßig ist die Gateway-Kapazität auf Klein eingestellt, was bedeutet, dass das Gateway Metadaten für bis zu 5 Millionen Dateien speichert. Die Standardeinstellung funktioniert für die meisten Workloads gut, auch wenn es Hunderte von Millionen oder sogar Milliarden von Objekten in Amazon S3 gibt, da in einer typischen Bereitstellung nur auf eine kleine Teilmenge von Dateien zu einem bestimmten Zeitpunkt aktiv zugegriffen wird. Diese Gruppe von Dateien wird als „Working Set“ bezeichnet.

Wenn Ihr Workload regelmäßig auf eine Gruppe von Dateien mit mehr als 5 Millionen zugreift, muss Ihr Gateway häufig Cache-Räumungen durchführen. Dabei handelt es sich um kleine I/O-Operationen, die im RAM gespeichert und auf der Root-Festplatte dauerhaft gespeichert werden. Dies kann sich negativ auf die Gateway-Leistung auswirken, da das Gateway neue Daten von Amazon S3 abruft.

Sie können die IndexEvictions Metrik überwachen, um die Anzahl der Dateien zu ermitteln, deren Metadaten aus dem Cache entfernt wurden, um Platz für neue Einträge zu schaffen. Weitere Informationen finden Sie unter Grundlegendes zu Gateway-Metriken.

Wir empfehlen, die UpdateGatewayInformation API-Aktion zu verwenden, um die Gateway-Kapazität so zu erhöhen, dass sie der Anzahl der Dateien in Ihrem typischen Arbeitssatz entspricht. Weitere Informationen finden Sie unter UpdateGatewayInformation.

Anmerkung

Die Erhöhung der Gateway-Kapazität erfordert zusätzliche RAM- und Root-Festplattenkapazität.

• Für kleine Dateien (5 Millionen Dateien) sind mindestens 16 GB RAM und 80 GB Root-Festplatte erforderlich.

• Medium (10 Millionen Dateien) erfordert mindestens 32 GB RAM und 160 GB Root-Festplatte.

• Groß (20 Millionen Dateien) erfordert 64 GB RAM und 240 GB Root-Festplatte.

Wichtig

Die Gateway-Kapazität kann nicht verringert werden.

Stellen Sie mehrere Gateways für größere Workloads bereit

Wir empfehlen, Ihre Arbeitslast nach Möglichkeit auf mehrere Gateways aufzuteilen, anstatt viele Dateifreigaben auf einem einzigen großen Gateway zu konsolidieren. Sie könnten beispielsweise eine häufig genutzte Dateifreigabe auf einem Gateway isolieren und die weniger häufig verwendeten Dateifreigaben auf einem anderen Gateway gruppieren.

Beachten Sie bei der Planung einer Bereitstellung mit mehreren Gateways und Dateifreigaben Folgendes:

• Die maximale Anzahl von Dateifreigaben auf einem einzelnen Gateway beträgt 50, aber die Anzahl der von einem Gateway verwalteten Dateifreigaben kann sich auf die Leistung des Gateways auswirken. Weitere Informationen finden Sie unter Leistungsanleitung für Gateways mit mehreren Dateifreigaben.

• Die Ressourcen auf jedem S3 File Gateway werden ohne Partitionierung von allen Dateifreigaben gemeinsam genutzt.

• Eine einzelne Dateifreigabe mit hoher Auslastung kann sich auf die Leistung anderer Dateifreigaben auf dem Gateway auswirken.

Anmerkung

Es wird nicht empfohlen, mehrere Dateifreigaben, die demselben Amazon S3 S3-Standort zugeordnet sind, von mehreren Gateways aus zu erstellen, es sei denn, mindestens eines davon ist schreibgeschützt.

Gleichzeitige Schreibvorgänge von mehreren Gateways in dieselbe Datei gelten als Szenario mit mehreren Schreibern, was zu Problemen mit der Datenintegrität führen kann.