Überlegungen zu SAS on AWS - AWS Präskriptive Leitlinien

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Überlegungen zu SAS on AWS

SAS-Hintergrund

  • Permanenter SAS-Datendateispeicher (SASDATA)

    • Speichert persistente Daten für die SAS-Nutzung und die daraus resultierenden SAS-Ausgabedateien

    • Umfangreich gelesen, aber weniger umfangreich wieder herausgeschrieben

  • SAS-Speicherplatz für Arbeitsdatendateien (SASWORK)

    • Scratch-Arbeitsbereich für SAS-Jobs

    • Wird verwendet, um die Arbeitsspeicheraktivität von Single-Thread-SAS-Prozeduren auszuführen

  • Dateispeicher für SAS-Dienstprogramme (UTILLOC)

    • Derselbe Speichertyp wie SASWORK für SAS-Verfahren mit mehreren Threads

    • Standardmäßig als Unterverzeichnis unter SASWORK platziert

  • Der Speicher bleibt bei einem Neustart oder Neustart interner Solid-State-Geräte (SSD), die in einer RAID 0-Konfiguration zusammengefasst sind, nicht erhalten. Wir empfehlen die Verwendung von Instances mit kurzlebigen nichtflüchtigen Memory Express (NVMe) -Geräten mit hoher Bandbreite, geringer Latenz und sequentieller I/O. Diese Instances eignen sich ideal für temporäre SAS-Daten (SASWORK und UTILLOC).

Gemeinsames SAS-Dateisystem (erforderlich für SAS Grid)

  • AWS richtet Lustre-Dateisysteme mit den Optionen rwseclabel, und lazystatfs Mount ein. Dies sind nicht die empfohlenen Einhängeoptionen für SAS Grid, daher müssen Sie sie FSx für Lustre-Dateisysteme unmounten und sie mit dem Parameter erneut mounten. flock

  • Sie können die Größe Ihres Lustre-Dateisystems nicht erweitern. Um die Größe zu ändern, erstellen Sie ein größeres Lustre-Dateisystem und kopieren Sie Daten vom alten System auf das neue.

  • FSx Denn bei persistenten Lustre-Dateisystemen werden Daten innerhalb einer einzigen Availability Zone repliziert, um die Haltbarkeit zu erhöhen. Sie werden nicht zwischen AWS Availability Zones repliziert.

  • Wir empfehlen Ihnen, die Amazon S3 S3-Speicheroption für die Verwendung mit SAS Grid und FSx für Lustre zu verwenden. Weitere Informationen finden Sie in der Dokumentation unter Using Data Repositories with FSx for Lustre. AWS

  • In der AWS Regionstabelle finden Sie Informationen zur Verfügbarkeit von Diensten in allen AWS Regionen und Availability Zones. Informieren Sie sich auch unter Amazon S3 Same-Region Replication (SRR) oder Cross-Region Replication (CRR) über die Auswirkungen der Datenreplikationsanforderungen für hohe Verfügbarkeit.

Instance-Typen der SAS Grid-Serverebene

SAS Grid-Server benötigen schnelle CPUs Daten. Wir empfehlen:

  • Mindestens 8 GB physischer RAM pro physischem Kern und robuster I/O-Durchsatz (insbesondere für SASWORK und SAS UTILLOC).

  • I3-Instances — Amazon EC2 I3-Instances sind speicheroptimiert für Workloads mit hohen Transaktionen und niedriger Latenz. Zu diesen Instances gehören NVMe SSD-basierte Instances, die für eine hohe zufällige I/O-Leistung, einen hohen sequentiellen Lesedurchsatz und hohe IOPS speicheroptimiert sind. Aufgrund der hohen internen I/O-Bandbreite von gestreiften NVMe SSD-Laufwerken für SASWORK und SAS UTILLOC sollten Sie Ihre Umgebung so konfigurieren, dass explizit lokale SSD-Laufwerke anstelle von Amazon EBS-Volumes verwendet werden. NVMe

  • i3EN-Instances — Diese Familie bietet auf Amazon speicheroptimierte NVMe SSD-Instances EC2 mit erweiterter Vernetzung über ENA, um eine Netzwerkbandbreite von bis zu 100 Gbit/s zu erreichen.

  • M5n-Instances — Die M5-Familie bietet ein ausgewogenes Verhältnis von Rechenleistung, Arbeitsspeicher und Netzwerk. M5n-Instances eignen sich ideal für Anwendungen, die einen verbesserten Netzwerkdurchsatz und eine verbesserte Leistung bei der Paketrate erfordern.

  • SAS-Workloads lassen sich als überwiegend große, sequentielle I/O-Anfragen mit großen Datenmengen charakterisieren. Wir empfehlen, dass Sie Ihre SAS-Nutzungsmuster im Voraus festlegen. Auf dieser Grundlage werden die optimale Architektur und Einrichtung der einzelnen zugrunde liegenden Dateisysteme und deren jeweilige physische I/O-Bereitstellung festgelegt.

    • Abfragen, Berichte und einfache statistische Aufgaben funktionieren normalerweise gut mit einer I/O-Rate von 100 MiB pro Sekunde pro physischem CPU-Kern.

    • Fortgeschrittene Analysen und umfangreiche statistische Aufgaben können bis zu 150 MiB pro Sekunde pro physischem CPU-Kern erfordern.

    • Insgesamt empfehlen wir eine minimale I/O-Durchsatzrate von 100-125 MiB pro Sekunde pro physischem CPU-Kern.

Instance-Typen der mittleren Stufe von SAS Grid und der Serverebene für Metadaten

Diese Server benötigen keine rechenintensiven Ressourcen oder einen robusten I/O-Durchsatz. Sie benötigen Zugriff auf mehr Arbeitsspeicher als die SAS-Rechenstufen. Wir empfehlen:

  • Mindestens 24 GB physischer RAM oder 8 GB physischer RAM pro physischem Kern, je nachdem, welcher Wert größer ist.

  • R5- oder R5d-Instances — Diese Instances eignen sich für speicherintensive Anwendungen wie In-Memory-Caches, mittelgroße In-Memory-Datenbanken und Big-Data-Analysen in Echtzeit.

Hohe Verfügbarkeit und Notfallwiederherstellung für SAS Grid

Die Planung der Notfallwiederherstellung ist für jedes kritische Geschäftssystem wichtig, einschließlich Produktionssysteme, auf denen die SAS Intelligence Platform und die SAS-Lösungen ausgeführt werden.

Disaster Recovery ist nicht dasselbe wie Hochverfügbarkeit. Obwohl beide Konzepte mit Geschäftskontinuität zu tun haben, geht es bei Hochverfügbarkeit darum, eine unterbrechungsfreie Betriebskontinuität zu gewährleisten. Im Gegensatz dazu ist die Notfallwiederherstellung mit einer gewissen Anzahl von Ausfallzeiten verbunden, die in der Regel in Stunden oder Tagen gemessen werden.