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.
Architekturkomponenten
In diesem Abschnitt werden die Spezifikationen der folgenden wichtigen funktionalen Architekturkomponenten beschrieben:
SAS-Server — Dieser Server ist die zentrale Rechenkomponente für die Verarbeitung von Analysen und umfasst Local Direct Attached Storage (DAS).
SAS-Subversion-Server — Dieser Server fungiert als zentrales Versionskontrollsystem für SAS.
Amazon FSx for Windows File Server — Dies ist ein SMB-Dateiserver für die gemeinsame Nutzung von Speicher zwischen dem SAS-Server und den Terminalservern. Endbenutzer speichern und archivieren ihre vor- und nachverarbeiteten Datendateien auf dem FSx Windows-Dateiserver.
Microsoft Remote Desktop Services (RDS), auch bekannt als Terminal Services — RDS, ermöglicht Endbenutzern den Zugriff auf SAS-Server mithilfe eines SAS-Clients.
Automatisierung der Infrastruktur — Sie können das AWS Cloud Development Kit (AWS CDK) mit AWS CodePipeline und AWS verwenden CodeCommit , um Ihre Infrastruktur zu automatisieren. CodePipeline kann Ihnen bei der Bereitstellung Ihrer Infrastrukturkomponenten helfen. CodePipeline ist ein Continuous-Delivery-Dienst zur Modellierung, Visualisierung und Automatisierung der Schritte, die zur Veröffentlichung von Code erforderlich sind. Darüber hinaus CodePipeline bietet er eine gemeinsame zentrale Umgebung und ermöglicht ein Infrastrukturmanagement, das unabhängig von lokalen Computern ist. CodeCommit ist ein sicherer, hoch skalierbarer, vollständig verwalteter Quellcodeverwaltungsdienst, der private Git-Repositorys hostet. Sie können CodeCommit zum Speichern von Automatisierungscode und Parametern für die AWS-CDK-Infrastruktur verwenden.
Anmerkung
AWS CodeCommit ist für Neukunden nicht mehr verfügbar. Bestandskunden von AWS CodeCommit können den Service weiterhin wie gewohnt nutzen. Weitere Informationen
Trennung der Umgebung
Das folgende Diagramm zeigt eine Architektur zur Trennung einer SAS-Integrations- und einer SAS-Produktionsumgebung.
Komponenten der Infrastruktur
Dieser Abschnitt bietet einen Überblick über die Infrastrukturkomponenten, die für die in diesem Handbuch empfohlene Architektur erforderlich sind.
Produktionsumgebung
Wir empfehlen, dass Sie die folgenden Infrastrukturkomponenten für Ihre Produktionsumgebung verwenden.
Typ | Instance-Typ | Ressourcen |
1 SAS-Server | m6i.4xlarge | 16 V CPUs (8 Kerne) 64 GB RAM |
2 Citrix Terminalserver | m6i.4xlarge | 16 V CPUs (8 Kerne) 64 GB RAM (z. B. 1—2 GB pro Benutzersitzung für Microsoft Office und Adobe Suite und durchschnittlich 500—1024 MB pro SAS-Client) Mehr als 25 Benutzer Potenzial zur Skalierung mit mehr Terminalservern in der future |
1 SAS-Subversion-Server | m6i.2xlarge | 8 V CPUs 4 Kerne 32 GB RAM |
Integrationsumgebung
Wir empfehlen Ihnen, die folgenden Infrastrukturkomponenten für Ihre Integrationsumgebung zu verwenden.
Typ | Instance-Typ | Ressourcen |
1 SAS-Server | m6i.2xlarge | 8 V CPUs (4 Kerne) 32 GB RAM |
2 Terminalserver | m6i.2xlarge
| 8 V CPUs (4 Kerne) 32 GB RAM |
1 SAS-Subversion-Server | m6i.xlarge | 4 v CPUs (2 Kerne) 16 GB RAM |
Lokaler Speicher für SAS-Server
Die empfohlene Architektur verwendet M6i-Instances, die auf den neuesten skalierbaren Intel Xeon Prozessoren basieren, und verwendet den Nitro Hypervisor aus dem AWS Nitro System.
herstellen | Typ | Kapazität | Produktion | Testen |
SAS-Server | Speichertyp | AWS-Ressource/-Service und EBS-Typ | Anforderung in Folge IO (lesen/schreiben) | Wie in der Produktion |
SAS-Server | Betriebssystem starten und austauschen | EBS 200 GB (GP3) | Aufgrund der geringen Anforderungen nicht relevant für die Dimensionierung | Wie bei der Produktion |
SAS-Server | SASWORK | EBS 2 x 512 GB (GP3/jeweils 5.000 IOPS) im RAID 0 | 8* 150 Mbit/s, 1200 Mbit/s oder ~ 11,5 Gbit/s Unterstützung für M6i-Instanzen 12,5 Gbit/s EBS-Speicherbandbreite mit GP3-EBS-Volumes | 1 x 1024 GB Volumen gp3 5.000 IOPS |
SAS-Server | SAS Software Depot und weitere Zusatzspeicher (zusätzlich zur SAS-Installation) | EBS 125 GB (GP3) | Aufgrund der geringen Anforderungen nicht relevant für die Dimensionierung | Wie bei der Produktion |
SAS-Terminalserver | Betriebssystem starten und austauschen | EBS 100 GB (GP3) | Aufgrund der geringen Anforderungen nicht relevant für die Dimensionierung | Wie bei der Produktion |
SAS-SVN-Server | Betriebssystem starten und austauschen | EBS 100 GB (GP3) | Aufgrund der geringen Anforderungen nicht relevant für die Dimensionierung | 100 GB |
SAS-SVN-Server | Subversion-Repositorien | EBS 1000 GB (GP3) | Standard | 400 GB zusätzlich zum Ops-Laufwerk |
Gemeinsam genutzte Speicherinfrastruktur
Wir empfehlen FSx die Verwendung von Windows File Server als gemeinsam genutzte Speicherlösung für Ihren SAS-Server und die Citrix-Terminalserver. Sie müssen S3-Buckets nicht für zusätzlichen Dateispeicher verwenden, es sei denn, Sie benötigen den Bucket für die Verwaltung von Systeminformationen oder Automatisierungsskripts.
Sie können die Subversion-Checkout-/Arbeitskopie des Projektcodes auch auf dem FSx Windows-Dateiserver speichern. Der SAS-Subversion-Server speichert die Repositorys lokal. Der Subversion-Server fungiert als zentrales Versionskontrollsystem.
Wir empfehlen, dass Sie FSx Windows File Server verwenden, um Windows-Benutzerprofile auf Ihren Citrix Terminalservern zu speichern. Dadurch wird ein nahtloser Lastenausgleich auf beiden Servern ermöglicht.
Produktionsumgebung
Die Architektur in diesem Handbuch wurde so konzipiert, dass sie die folgenden Anforderungen für die Produktionsumgebung erfüllt:
Speichertyp — FSx für Windows File Server
Typ — Mehrere Verfügbarkeitszonen
Ressource/Durchsatz — 1024 MB
Speicher — 1,2 TB SSD
Integrations- und Testumgebung
Die Architektur in diesem Handbuch wurde entwickelt, um die folgenden Anforderungen an die Integrationsumgebung zu erfüllen:
Speichertyp — FSx für Windows File Server
Typ — Mehrere Verfügbarkeitszonen
Ressource/Durchsatz — 512 MB
Speicher — 512 GB SSD
Leistung
Der I/O-Durchsatz FSx für Windows File Server lässt sich leicht anpassen, und Sie können Dashboards für den I/O-Durchsatz erstellen, die Ihren Überwachungsanforderungen entsprechen. Sie können es dem Betriebsteam auch ermöglichen, den Durchsatz an die Bedürfnisse der Endbenutzer anzupassen.
Sicherung und Wiederherstellung von Dateien
Alle SAS-Daten befinden sich auf einem FSx für Windows separaten Dateiserver als persistenter Speicher. Für die in FSx Windows File Server gespeicherten Daten sind zwei Sicherungsebenen implementiert:
Tägliche Backups, die 30 Tage lang aufbewahrt werden — Diese Backups werden in einem S3-Bucket aufbewahrt. Sie können dieses Snapshot-basierte Backup für die Wiederherstellung verwenden, falls ein FSx Amazon-Volume beschädigt ist oder verloren gegangen ist.
Backups, die mit dem Microsoft Volume Shadow Copy Service (VSS) aufbewahrt werden — Dateien auf dem FSx Windows-Dateiserver werden zweimal täglich für die Sicherung auf einer speziellen Speicherpartition auf dem FSx für Windows File Server gespeicherten Snapshots erstellt und auf unbestimmte Zeit aufbewahrt. Die Sicherung basiert auf dem verfügbaren Speicherplatz der VSS-Partition auf dem FSx Windows-Dateiserver (bis zu 10 Prozent des gesamten Speicherplatzes). Wenn Endbenutzer eine Datei auf dem FSx Windows-Dateiserver beschädigen oder verlieren, können sie ihre eigene Wiederherstellung direkt über den Windows-Datei-Explorer auf den SAS-Terminalservern starten.
Notfallwiederherstellung
Die Entkopplungsarchitektur in diesem Handbuch wurde im Hinblick auf die Notfallwiederherstellung entwickelt. Amazon FSx wird in zwei AWS-Availability Zones eingesetzt. Wenn die Availability Zone, in der sich der FSx für Windows aktive Dateiserver befindet, nicht mehr verfügbar ist, führt der Service automatisch ein Failover durch und stellt die Filesharing-Dienste aus der zweiten Availability Zone bereit.
