Optimierung von S3 File Gateway für SQL Server-Datenbanksicherungen

Datenbank-Backups sind ein gängiger und empfohlener Anwendungsfall für S3 File Gateway, das eine kostengünstige kurz- und langfristige Aufbewahrung ermöglicht, indem Datenbank-Backups in Amazon S3 gespeichert werden, wobei der Lebenszyklus bei Bedarf auf kostengünstigere Speicherebenen umgestellt werden kann. Mit dieser Lösung können Sie mithilfe integrierter Tools wie SQL Server Management Studio und Oracle RMAN den Bedarf an Backup-Anwendungen für Unternehmen reduzieren.

In den folgenden Abschnitten werden bewährte Methoden zur Optimierung Ihrer S3 File Gateway-Bereitstellung für optimierte Leistung und kostengünstigen Support für Hunderte von Terabyte an SQL-Datenbank-Backups 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 SQL-Server bereit

Wir empfehlen, Ihre virtuelle S3 File Gateway-Appliance an einem physischen Standort mit möglichst geringer Netzwerklatenz zwischen ihr und Ihren SQL-Servern 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 SMB-Clients wie SQL-Servern 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 SQL-Server 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 für virtuelle Maschinen mit S3 File Gateway 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.

Verbessern Sie den Durchsatz von SMB-Clients, indem Sie die Sicherheitsstufe Ihres S3 File Gateways anpassen

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.

Verbessern Sie den SMB-Client-Durchsatz, indem Sie SQL-Backups in mehrere Dateien aufteilen

• Es ist schwierig, die maximale Durchsatzleistung mit einem S3 File Gateway zu erreichen, bei dem jeweils nur ein SQL-Server eine Datei schreibt, da sequentielles Schreiben von einem einzelnen SQL-Server aus ein Single-Thread-Vorgang ist. Stattdessen empfehlen wir, mehrere Threads von jedem SQL-Server zu verwenden, um mehrere Dateien parallel zu schreiben, und mehrere SQL-Server gleichzeitig für Ihr S3 File Gateway zu verwenden, um den Gateway-Durchsatz zu maximieren. Bei SQL-Backups ermöglicht das Aufteilen von Backups in mehrere Dateien, dass jede Datei einen separaten Thread verwendet, der mehrere Dateien gleichzeitig auf die S3 File Gateway-Dateifreigabe schreibt. Je mehr Threads Sie haben, desto mehr Durchsatz können Sie bis zu den Grenzen des Gateways erreichen.

• SQL Server unterstützt das gleichzeitige Schreiben in mehrere Dateien während eines einzelnen Sicherungsvorgangs. Sie können beispielsweise mehrere Dateiziele mithilfe von T-SQL-Befehlen oder SQL Server Management Studio (SSMS) angeben. Jede Datei verwendet einen separaten Thread, um Daten vom SQL-Server an die Gateway-Dateifreigabe zu senden. Dieser Ansatz ermöglicht einen besseren I/O Durchsatz, wodurch die Geschwindigkeit und Effizienz von Backups erheblich verbessert werden können.

Beachten Sie bei der Konfiguration Ihrer SQL Server-Backups Folgendes:

• Durch die Aufteilung von Backups in mehrere Dateien können SQL Server-Administratoren die Sicherungszeiten optimieren und große Datenbanksicherungen effektiver verwalten.

• Die Anzahl der verwendeten Dateien hängt von der Speicherkonfiguration und den Leistungsanforderungen des Servers ab. Für große Datenbanken empfehlen wir, Backups in mehrere kleinere Dateien zwischen jeweils 10 GB und 20 GB aufzuteilen.

• Es gibt keine strikte Beschränkung für die Anzahl der Dateien, in die SQL Server während einer Sicherung schreiben kann, aber praktische Überlegungen wie Speicherarchitektur und Netzwerkbandbreite sollten sich bei dieser Auswahl leiten lassen.

Weitere Informationen finden Sie unter:

• Sichern Sie SQL Server 43-67% schneller, indem Sie in mehrere Dateien schreiben

• Speichern Sie Ihre SQL Server-Backups mit File Gateway ganz einfach in Amazon S3

Vermeiden Sie Fehler beim Kopieren großer Dateien, indem Sie die SMB-Timeout-Einstellungen erhöhen

Wenn S3 File Gateway große SQL-Backupdateien 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-Sitzungstimeout für Ihre SQL Server-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.

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 SQL-Servern mit einer höheren Geschwindigkeit empfängt, als es mit der Standardkapazität von 8 Threads 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.

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 auf Ihren SQL-Servern 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.

Stellen Sie mehrere Gateways bereit, um die Arbeitslast zu unterstützen

Storage Gateway kann SQL-Backups für große Umgebungen mit Hunderten von SQL-Datenbanken, mehreren SQL-Servern und Hunderten von Terabyte an Backup-Daten unterstützen, indem die Arbeitslast auf mehrere Gateways aufgeteilt wird.

Beachten Sie bei der Planung einer Bereitstellung mit mehreren Gateways und SQL-Servern Folgendes:

• Ein einzelnes Gateway kann bei ausreichender Hardwareressourcen und Bandbreite in der Regel bis zu 20 TB pro Tag hochladen. Sie können dieses Limit auf bis zu 40 TB pro Tag erhöhen, indem Sie die Anzahl der Amazon S3 S3-Uploader-Threads erhöhen.

• Wir empfehlen, einen proof-of-concept Test durchzuführen, um die Leistung zu messen und alle Variablen in Ihrer Bereitstellung zu berücksichtigen. Nachdem Sie den Spitzendurchsatz Ihres SQL-Backup-Workloads ermittelt haben, können Sie die Anzahl der Gateways Ihren Anforderungen entsprechend skalieren.

• Wir empfehlen, Ihre Lösung mit Blick auf das Wachstum zu entwickeln, da die Anzahl der Datenbanken und die Größe der Datenbanken im Laufe der Zeit zunehmen können. Um die steigende Arbeitslast weiterhin zu skalieren und zu unterstützen, können Sie bei Bedarf zusätzliche Gateways bereitstellen.

Zusätzliche Ressourcen für Datenbank-Backup-Workloads

• Speichern Sie SQL Server-Backups in Amazon S3 mit AWS Storage Gateway

• Speichern Sie Ihre SQL Server-Backups mit File Gateway ganz einfach in Amazon S3

• Wird AWS Storage Gateway zum Speichern von Oracle-Datenbank-Backups in Amazon S3 verwendet

• Oracle-Datenbanken in großem Umfang auf Amazon S3 sichern

• Integrieren Sie eine SAP ASE-Datenbank in Amazon S3 mit AWS Storage Gateway

• Wie One AWS Hero AWS Storage Gateway für In-Cloud-Backups verwendet

• Bewährte Methoden zur Cache-Dimensionierung von S3 File Gateway