Dieses Whitepaper dient nur als historische Referenz. Einige Inhalte sind möglicherweise veraltet und einige Links sind möglicherweise nicht verfügbar.
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.
# Architektur für Sicherheit und Leistung
Ganz gleich, ob Sie Oracle Database auf Amazon RDS oder Amazon ausführen EC2, die Optimierung aller Komponenten der Infrastruktur verbessert die Sicherheit, Leistung und Zuverlässigkeit. In den folgenden Abschnitten werden die bewährten Methoden zur Optimierung der Netzwerkkonfiguration, des Instance-Typs und des Datenbankspeichers in einer Oracle Database-Implementierung auf AWS beschrieben.
**Topics**
+ [Netzwerkkonfiguration](network-configuration.md)
+ [EC2 Amazon-Instanztyp](amazon-ec2-instance-type.md)
+ [Datenbankspeicher](database-storage.md)
# Netzwerkkonfiguration
Mit Amazon Virtual Private Cloud (Amazon VPC) können Sie einen logisch isolierten Bereich bereitstellen AWS Cloud , der Ihrem Konto gewidmet ist. Sie haben die vollständige Kontrolle über Ihre virtuelle Netzwerkumgebung, einschließlich der Auswahl Ihres eigenen IP-Adressbereichs, der Erstellung von Subnetzen, Sicherheitseinstellungen und der Konfiguration von Routentabellen und Netzwerk-Gateways.
Ein *Subnetz* ist ein Bereich von IP-Adressen in Ihrer Amazon VPC. Sie können AWS-Ressourcen in einem von Ihnen ausgewählten Subnetz starten. Verwenden Sie öffentliche Subnetze für Ressourcen, die mit dem Internet verbunden sein müssen, und private Subnetze für Ressourcen, die nicht mit dem Internet verbunden sein werden.
Um die AWS Ressourcen in jedem Subnetz zu schützen, können Sie mehrere Sicherheitsebenen verwenden, darunter Sicherheitsgruppen und Netzwerkzugriffskontrolllisten ()ACLs.
In der folgenden Tabelle werden die grundlegenden Unterschiede zwischen Sicherheitsgruppen und Netzwerken ACLs beschrieben.
| **Sicherheitsgruppe** | **Netzwerk-ACL** |
| --- | --- |
| Arbeitet auf Instance-Ebene (erste Verteidigungsebene) | Arbeitet auf Subnetzebene (zweite Verteidigungsebene) |
| Unterstützt nur Zulassungsregeln | Unterstützt Regeln zum Zulassen und Verweigern von Regeln |
| Stateful: Rückverkehr ist unabhängig von Regeln automatisch zulässig | Zustandslos: Rückfließender Datenverkehr muss ausdrücklich durch Regeln zugelassen werden |
| Alle Regeln werden vor dem Erlauben von Datenverkehr ausgewertet. | Alle Regeln werden in festgelegter Reihenfolge vor dem Erlauben von Datenverkehr verarbeitet. |
| Gilt für eine Instance nur dann, wenn beim Starten der Instance oder später eine Sicherheitsgruppe festgelegt wird. | Wird automatisch auf alle Instances in den zugeordneten Subnetzen angewendet (Sicherungs-Verteidigungsebene, damit nicht unbedingt eine Sicherheitsgruppe festgelegt werden muss). |
Amazon VPC bietet Isolierung, zusätzliche Sicherheit und die Möglichkeit, EC2 Amazon-Instances in Subnetze zu unterteilen, und ermöglicht die Verwendung von privaten IP-Adressen. All dies ist wichtig für die Datenbankimplementierung.
Stellen Sie die Oracle Database-Instance in einem privaten Subnetz bereit und erlauben Sie nur Anwendungsservern innerhalb der Amazon VPC oder einem Bastion-Host innerhalb der Amazon VPC den Zugriff auf die Datenbank-Instance.
Erstellen Sie geeignete Sicherheitsgruppen, die nur den Zugriff auf bestimmte IP-Adressen über die angegebenen Ports ermöglichen. Diese Empfehlungen gelten für Oracle Database, unabhängig davon, ob Sie Amazon RDS oder Amazon verwenden EC2.
![\[Oracle-Datenbank im privaten Subnetz einer Amazon VPC\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/oracle-database-aws-best-practices/images/oracle-db-private-subnet.png)
Oracle-Datenbank im privaten Subnetz einer Amazon VPC
# EC2 Amazon-Instanztyp
AWS bietet eine große Anzahl von EC2 Amazon-Instance-Typen, sodass Sie den Instance-Typ auswählen können, der am besten zu Ihrer Arbeitslast passt. Allerdings eignen sich nicht alle verfügbaren Instance-Typen am besten für die Ausführung von Oracle Database.
Wenn Sie Amazon RDS für Ihre Oracle-Datenbank verwenden, AWS filtert es einige Instance-Typen auf der Grundlage von Best Practices heraus und bietet Ihnen die verschiedenen Optionen in T-, M- und R-Class-Instances. AWS empfiehlt, dass Sie für alle Datenbank-Workloads Ihres Unternehmens db.m-basierte oder r-basierte Amazon RDS-Instances wählen. R5-Instances eignen sich gut für speicherintensive Anwendungen wie Hochleistungsdatenbanken.
Aktuelle Informationen zu RDS-Instances finden Sie unter [Amazon RDS for Oracle Database Pricing](https://aws.amazon.com/rds/oracle/pricing/). Ihre Wahl des Amazon RDS-Instance-Typs sollte auf der Datenbank-Arbeitslast und den verfügbaren Oracle-Datenbank-Lizenzen basieren.
Wenn Sie Ihre selbstverwaltete Datenbank auf Amazon ausführen EC2, stehen Ihnen viele weitere Optionen für den EC2 Amazon-Instance-Typ zur Verfügung. Dies ist häufig einer der Gründe, warum sich Benutzer dafür entscheiden, Oracle Database auf Amazon auszuführen, EC2 anstatt Amazon RDS zu verwenden.
Sehr kleine Instance-Typen sind nicht geeignet, da Oracle Database in Bezug auf die CPU-Auslastung ressourcenintensiv ist. Instanzen mit einem größeren Speicherbedarf tragen zur Verbesserung der Datenbankleistung bei, indem sie ein besseres Caching und einen größeren System Global Area (SGA) bieten. AWS empfiehlt, dass Sie Instances wählen, die ein ausgewogenes Verhältnis von Arbeitsspeicher und CPU aufweisen.
Wählen Sie den Instance-Typ, der den Oracle Database-Lizenzen, die Sie verwenden möchten, und der Architektur, die Sie implementieren möchten, entspricht. Informationen zu Architekturen, die für Ihre Geschäftsanforderungen am besten geeignet sind, finden Sie im Whitepaper [Advanced Architectures for Oracle Database on Amazon](https://d1.awsstatic.com/whitepapers/aws-advanced-architectures-for-oracle-db-on-ec2.pdf). EC2
Oracle Database verwendet Festplattenspeicher in hohem Maße für read/write Operationen. Daher wird AWS dringend empfohlen, nur für Amazon Elastic Block Store (Amazon EBS) optimierte Instances zu verwenden. Für Amazon EBS optimierte Instances bieten dedizierten Durchsatz zwischen Amazon EC2 und Amazon EBS. Bandbreite und Durchsatz für das Speichersubsystem sind entscheidend für eine gute Datenbankleistung. Wählen Sie Instances mit höherer Netzwerkleistung für eine bessere Datenbankleistung.
Die folgenden Instance-Familien eignen sich am besten für die Ausführung von Oracle Database auf Amazon EC2.
| **Instance-Familie** | **Funktionen** |
| --- | --- |
| Meine Familie | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| X-Familie | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| R-Familie | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| In der Familie | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
| Z1d-Familie | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/whitepapers/latest/oracle-database-aws-best-practices/amazon-ec2-instance-type.html) |
# Datenbankspeicher
Die meisten Benutzer verwenden in der Regel Amazon EBS als Datenbankspeicher. Für einige sehr leistungsstarke Architekturen können Sie Instance-Speicher verwenden SSDs, diese sollten jedoch für eine zuverlässige Persistenz um Amazon EBS-Speicher erweitert werden.
Für eine hohe und konsistente IOPS- und Datenbankleistung empfiehlt AWS dringend, General Purpose (GP2) -Volumes oder Provisioned IOPS (PIOPS) -Volumes zu verwenden. GP2 und PIOPS-Volumen sind sowohl für Amazon als auch für Amazon EC2 RDS verfügbar. Die neuesten IOPS-Grenzwerte pro Volume für beide GP2 und PIOPS-Volumetypen finden Sie unter [Amazon RDS-DB-Instance-Speicher](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html). GP2 Volumes bieten ein hervorragendes Preis-Leistungs-Verhältnis für die meisten Datenbankanforderungen. Wenn Ihre Datenbank höhere IOPS benötigt, als sie bieten GP2 kann, sind PIOPS-Volumes die richtige Wahl.
Für PIOPS-Volumes geben Sie bei der Erstellung des Volumes eine IOPS-Rate an, und Amazon EBS liefert innerhalb eines bestimmten Jahres in 99,9% der Fälle innerhalb von 10% der bereitgestellten IOPS-Leistung. Das Verhältnis der bereitgestellten IOPS zur angeforderten Volume-Größe kann maximal 30 betragen. Um beispielsweise 3.000 IOPS zu erhalten, sollte Ihr Volume mindestens 100 GB groß sein.
Ähnlich wie PIOPS-Volumes basieren auch GP2 Volumes auf SSDs, aber die IOPS, die Sie von GP2 Volumes erhalten, können von Basis-IOPS bis hin zu maximal 3.000 IOPS pro Volume im Burst-Modus variieren. Dies funktioniert bei den meisten Datenbank-Workloads sehr gut, da die von der Datenbank benötigte IOPS-Leistung je nach Ladegröße und Anzahl der ausgeführten Abfragen innerhalb eines bestimmten Zeitraums um ein Vielfaches schwankt.
Die Leistung eines SSD-Volumes (General Purpose) hängt von der Größe des Volumes ab. Diese bestimmt das grundlegende Leistungsniveau des Volumes und die Geschwindigkeit, mit der Credits angesammelt werden. I/O Größere Volumes haben ein höheres Basisleistungsniveau und können schneller I/O Credits akkumulieren.
I/O Credits stellen die verfügbare Bandbreite dar, die Ihr Allzweckvolume (SSD) nutzen kann, um große Mengen zu nutzen, I/O wenn mehr als die Basisleistung benötigt wird. Je mehr Credits Ihrem Volume für I/O zur Verfügung stehen, desto mehr Zeit kann es über sein Basisleistungsniveau hinaus beanspruchen und desto besser ist die Leistung, wenn mehr Leistung benötigt wird.
Throughput Optimized HDD Volumes (st1) bietet kostengünstiges Festplattenvolumen, das für intensive Workloads konzipiert ist, die weniger IOPS, aber einen hohen Durchsatz erfordern. Oracle-Datenbanken, die für Data Warehouses und Datenanalysezwecke verwendet werden, können ST1-Volumes nutzen.
Alle Bereiche der Protokollverarbeitung oder Datenbereitstellung wie externe Oracle-Tabellen oder externer BLOB-Speicher, die einen hohen Durchsatz erfordern, können st1-Volumes nutzen. Durchsatzoptimierte (st1) Volumes können maximal 500 IOPS pro Volume verarbeiten.
Cold HDD-Volumes (sc1) eignen sich für den Umgang mit älteren Systemen, die gelegentlich zu Referenz- oder Archivierungszwecken aufbewahrt werden. Auf diese Systeme wird seltener zugegriffen, und es werden einige Scans pro Tag auf dem Volume durchgeführt.
Ein guter Ansatz besteht darin, abzuschätzen, wie viele IOPS regelmäßig für Ihre Datenbank benötigt werden, und genügend GP2 Speicherplatz zuzuweisen, um diese Anzahl IOPS zu erhalten. Alle zusätzlichen IOPS, die für periodische Spitzenwerte erforderlich sind, sollten durch die Burst-Leistung auf der Grundlage der verfügbaren Credits gedeckt werden.
Informationen zu Schätzmethoden, mit denen Sie die IOPS-Anforderungen Ihrer Oracle-Datenbank ermitteln können, finden Sie im Whitepaper Determinating [the IOPS Needs for Oracle Database on AWS](https://docs.aws.amazon.com/whitepapers/latest/determining-iops-needs-oracle-db-on-aws/determining-iops-needs-oracle-db-on-aws.html).
Die Burst-Dauer eines Volume hängt von der Größe des Volumes, der benötigten IOPS-Spitzenleistung und dem I/O-Guthaben zum Zeitpunkt der Leistungssteigerung ab. Wenn Sie feststellen, dass Ihre Volumenleistung häufig auf die Basisebene beschränkt ist (aufgrund eines leeren I/O Guthabens), sollten Sie die Verwendung eines größeren General Purpose (SSD) -Volumes (mit einem höheren Basisleistungsniveau) oder die Umstellung auf ein Provisioned IOPS (SSD) -Volume für Workloads in Betracht ziehen, die eine dauerhafte IOPS-Leistung von mehr als 10.000 IOPS erfordern. Weitere Informationen zu GP2 Volumes finden Sie unter [Amazon EBS-Volumetypen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html).
Für Amazon RDS bietet Allzweckspeicher (SSD) einen konsistenten Basiswert von 3 IOPS pro bereitgestelltem GB und die Fähigkeit, bis zu 3.000 IOPS zu beschleunigen. Wenn Sie bereits Magnetspeicher für Amazon RDS verwenden, können Sie auf Allzweckspeicher (SSD) umstellen, allerdings wird es dabei zu einer kurzen Beeinträchtigung der Verfügbarkeit kommen. Mit Provisioned IOPS können Sie bis zum aktuellen maximalen Speicherlimit und den maximalen IOPS pro Datenbank-Instance bereitstellen.
Ihre tatsächlich realisierten IOPS können je nach Datenbank-Workload, Instance-Typ und Datenbank-Engine von der Menge abweichen, die Sie bereitgestellt haben. Weitere Informationen finden Sie unter [Faktoren, die sich auf die realisierten IOPS-Raten auswirken im *Amazon RDS-Benutzerhandbuch*](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html).
Für Oracle Database on Amazon sollten Sie mehrere Volumes zusammenlegen EC2, um mehr IOPS und eine größere Kapazität zu erzielen. Sie können mehrere Amazon EBS-Volumes einzeln für verschiedene Datendateien verwenden, aber wenn Sie sie zusammenfügen, können Sie sie besser ausbalancieren und skalieren.
Oracle Automatic Storage Management (ASM) kann für das Striping verwendet werden. Speichern Sie Datendateien, Protokolldateien und Binärdateien auf separaten Amazon EBS-Volumes und erstellen Sie regelmäßig Schnappschüsse von Protokolldatei-Volumes. Wenn Sie einen Instance-Typ mit lokalem SSD-Speicher wählen, können Sie die Datenbankleistung steigern, indem Sie Smart Flash Cache (wenn das Betriebssystem Oracle Linux ist) und lokalen Speicher für temporäre Dateien und Tabellenbereiche verwenden.
Für Oracle Database on VMware Cloud on AWS stellt vSAN den erforderlichen virtualisierten Speicher bereit, der über die Bare-Metal-Hosts verteilt ist. Die virtualisierte vSAN-Speicherfunktion kann in Oracle RAC für gemeinsam genutzten Hochleistungsspeicher verwendet werden.
Die für Oracle RAC erstellten VMDK-Dateien (Virtual Machine Disk) müssen für Eager Zero Thick bereitgestellt werden und das Multi-Writer-Flag muss aktiviert sein. VMware hat eine [detaillierte Leistungsstudie](https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/solutions/oracle/vmw-oracle-performance-on-the-vmware-cloud-on-aws.pdf) für Oracle-Datenbanken auf VMware Cloud on AWS veröffentlicht.