Amazon RDS Custom Architektur - Amazon Relational Database Service

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.

Amazon RDS Custom Architektur

Die Amazon RDS Custom Architecture basiert auf Amazon RDS mit wichtigen Unterschieden. Das folgende Diagramm zeigt die Hauptkomponenten der RDS-Custom-Architektur.

Komponenten der RDS-Custom-Architektur

VPC

Wie bei Amazon RDS befindet sich Ihre RDS-Custom-DB-Instance in einer Virtual Private Cloud (VPC).

Komponenten der RDS-Custom-DB-Instance

Die RDS-Custom-DB-Instance besteht aus den folgenden Komponenten:

  • Amazon EC2-Instance

  • Instance-Endpunkt

  • Auf der Amazon EC2-Instance installiertes Betriebssystem

  • Amazon EBS-Speicher, der zusätzliche Dateisysteme enthält

RDS Kundenspezifische Automatisierung und Überwachung

RDS Custom verfügt über Automatisierungssoftware, die außerhalb der DB-Instance läuft. Diese Software kommuniziert mit Agenten auf der DB-Instance und mit anderen Komponenten innerhalb der gesamten RDS Custom Umgebung.

Die RDS Custom Überwachungs- und Wiederherstellungsfunktionen bieten ähnliche Funktionen wie Amazon RDS. Standardmäßig befindet sich RDS Custom im Vollautomatisierungsmodus. Die Automatisierungssoftware hat folgende Hauptaufgaben:

  • Sammeln Sie Metriken und senden Sie Benachrichtigungen

  • Automatische Instance-Wiederherstellung

Eine wichtige Verantwortung der RDS Custom Automation besteht darin, auf Probleme mit Ihrer Amazon EC2-Instance zu reagieren. Aus verschiedenen Gründen kann der Gastgeber beeinträchtigt oder nicht erreichbar werden. RDS Custom behebt diese Probleme durch einen Neustart oder Ersetzen der Amazon EC2-Instance.

Hostersatz in Amazon RDS Custom

Wenn der Amazon EC2-Host beeinträchtigt wird, versucht RDS Custom, ihn neu zu starten. Wenn dieser Aufwand fehlschlägt, verwendet RDS Custom dieselbe Stopp- und Start-Funktion, die in Amazon EC2 enthalten ist. Die einzige vom Kunden sichtbare Änderung, wenn ein Host ersetzt wird, ist eine neue öffentliche IP-Adresse.

Stoppen und Starten des Clusters.

RDS Custom führt automatisch die folgenden Schritte aus, ohne dass ein Benutzereingriff erforderlich ist:

  1. Stoppt den Amazon EC2-Host.

    Die EC2-Instance führt einen normalen Prozess zum Herunterfahren aus und stoppt dann. Amazon EBS-Volumes bleiben der Instance angefügt und die Daten bleiben bestehen. Alle Daten, die in den Instance-Speicher-Volumes gespeichert sind (nicht auf RDS Custom unterstützt) oder im RAM des Hostcomputers, sind verschwunden.

    Weitere Informationen finden Sie unter Grundlagen zur automatischen Platzierung und Affinität im Amazon EC2 Benutzerhandbuch für Linux-Instances.

  2. Startet den Amazon EC2-Host.

    Die EC2-Instanz migriert auf eine neue zugrunde liegende Host-Hardware. In einigen Fällen bleibt die RDS Custom DB-Instanz auf dem ursprünglichen Host.

Auswirkungen des Host-Ersatzes

In RDS Custom haben Sie die volle Kontrolle über das Root-Gerätevolume und Amazon EBS-Speicher-Volumes. Das Root-Volume kann wichtige Daten und Konfigurationen enthalten, die Sie nicht verlieren möchten.

RDS Custom for Oracle behält alle Datenbank- und Kundendaten nach dem Vorgang bei, einschließlich Root-Volume-Daten. Es ist kein Benutzereingriff erforderlich. Auf RDS Custom for SQL Server werden Datenbankdaten gespeichert, aber alle Daten auf dem Laufwerk C:, einschließlich Betriebssystem- und Kundendaten, gehen verloren.

Nach dem Austauschvorgang verfügt der Amazon EC2-Host über eine neue öffentliche IP-Adresse. Der Host behält Folgendes bei:

  • Instance-ID

  • Private IP-Adressen

  • Elastic-IP-Adressen

  • Instance-Metadaten

  • Daten zum Datenspeichervolumen

  • Root-Volume-Daten (auf RDS Custom for Oracle)

Bewährte Methoden für Amazon EC2

Die Funktion zum Austausch von Amazon EC2 Hosts deckt die meisten Amazon-EC2-Wertminderungsszenarien ab. Wir empfehlen Ihnen, die ACM bewährte Methode für zu befolgen.

  • Bevor Sie Ihre Konfiguration oder das Betriebssystem ändern, sichern Sie Ihre Daten. Wenn das Root-Volume oder Betriebssystem beschädigt wird, kann der Host-Ersatz es nicht reparieren. Ihre einzigen Optionen sind die Wiederherstellung von einem DB-Snapshot oder einer zeitpunktbezogenen Wiederherstellung.

  • Beenden oder beenden Sie den physischen Amazon EC2-Host nicht manuell. Beide Aktionen führen dazu, dass die Instanz außerhalb des RDS Custom Supportumfangs platziert wird.

  • (RDS Custom for SQL Server) Wenn Sie zusätzliche Volumes an den Amazon EC2-Host anfügen, konfigurieren Sie diese so, dass sie beim Neustart neu gestartet werden. Wenn der Host beeinträchtigt ist, stoppt RDS Custom möglicherweise und startet den Host automatisch.

Support-Perimeter in RDS Custom

RDS Custom bietet zusätzliche Überwachungsfunktionen, die Support Perimeter genannt werden. Diese zusätzliche Überwachung stellt sicher, dass Ihre RDS-Custom-DB-Instance eine AWS-Infrastruktur, ein Betriebssystem und eine Datenbank verwenden, die unterstützt werden.

Der Support-Perimeter überprüft, ob Ihre DB-Instance die unter Fehlerbehebung bei nicht unterstützten Konfigurationen in RDS Custom für Oracle und Korrigieren von nicht unterstützten Konfigurationen in RDS Custom for SQL Server aufgeführten Anforderungen erfüllt. Wenn eine dieser Anforderungen nicht erfüllt wird, betrachtet RDS Custom die DB-Instance als außerhalb des Support-Umfangs liegend.

Nicht unterstützte Konfigurationen in RDS Custom

Wenn sich Ihre DB-Instance außerhalb des Support-Perimeters befindet, ändert RDS Custom den Status der DB-Instance in unsupported-configuration und sendet Ereignisbenachrichtigungen. Nachdem Sie die Konfigurationsprobleme behoben haben, ändert RDS Custom den Status der DB-Instance wieder in available.

Während die DB-Instance den Status unsupported-configuration aufweist, ist Folgendes der Fall:

  • Ihre Datenbank ist erreichbar. Eine Ausnahme besteht, wenn die DB-Instance den Status unsupported-configuration aufweist, weil die Datenbank unerwartet heruntergefahren wird.

  • Sie können Ihre DB-Instance nicht ändern.

  • Sie können keine DB-Snapshots machen.

  • Es werden keine automatischen Backups erstellt.

  • Bei DB-Instances von RDS Custom für SQL Server ersetzt RDS Custom die zugrunde liegende Amazon-EC2-Instance nicht, wenn sie beeinträchtigt wird. Weitere Informationen zum Hostersatz finden Sie unter Hostersatz in Amazon RDS Custom.

  • Sie können Ihre DB-Instance löschen, die meisten anderen API-Operationen von RDS Custom sind jedoch nicht verfügbar.

  • RDS Custom unterstützt weiterhin die zeitpunktbezogene Wiederherstellung (PITR), indem Redo-Protokolldateien archiviert und in Amazon S3 hochgeladen werden. PITR im Status unsupported-configuration unterscheidet sich in folgenden Punkten:

    • Es kann lange dauern, bis PITR das Zurücksetzen auf eine neue RDS-Custom-DB-Instance vollständig abgeschlossen hat. Dies liegt daran, dass Sie weder automatisierte noch manuelle Snapshots erstellen können, während die Instance den Status unsupported-configuration aufweist.

    • PITR muss weitere Redo-Logs wiedergeben, beginnend mit dem letzten Snapshot, der erstellt wurde, bevor die Instanz in den Zustand unsupported-configuration geht.

    • In einigen Fällen weist die DB-Instance den Status unsupported-configuration auf, weil Sie eine Änderung vorgenommen haben, die das Hochladen archivierter Redo-Protokolldateien verhindert hat. Beispiele hierfür sind das Beenden der EC2-Instance, das Beenden des RDS-Custom-Agent und das Trennen von EBS-Volumes. In diesen Fällen kann PITR die DB-Instance nicht auf die neueste wiederherstellbare Zeit zurücksetzen.

Fehlerbehebung bei nicht unterstützten Konfigurationen

RDS Custom bietet Anleitungen zur Fehlerbehebung für den Status unsupported-configuration. Auch wenn einige Anleitungen sowohl für RDS Custom für Oracle als auch für RDS Custom für SQL Server gelten, hängen andere Anleitungen von Ihrer DB-Engine ab. Engine-spezifische Informationen finden Sie in den folgenden Themen:

Amazon S3

Wenn Sie RDS Custom for Oracle verwenden, laden Sie Installationsmedien in einen vom Benutzer erstellten Amazon-S3-Bucket hoch. RDS Custom for Oracle verwendet die Medien in diesem Bucket, um eine benutzerdefinierte Engine-Version (CEV) zu erstellen. Ein CEV ist ein binärer Volume-Snapshot einer Datenbankversion und Amazon Machine Image (AMI). Aus der CEV können Sie eine RDS-Custom-DB-Instance erstellen. Weitere Informationen finden Sie unter Arbeiten mit benutzerdefinierten Engine-Versionen für Amazon RDS Custom für Oracle.

Sowohl für RDS Custom for Oracle als auch für RDS Custom for SQL Server erstellt RDS Custom automatisch einen Amazon-S3-Bucket, dem die Zeichenfolge do-not-delete-rds-custom- vorangestellt wird. RDS Custom verwendet den do-not-delete-rds-custom--S3-Bucket zum Speichern der folgenden Dateitypen:

  • AWS CloudTrail-Protokolle für den von RDS Custom erstellten Trail

  • Unterstützung von Perimeter-Artefakten (siehe Support-Perimeter in RDS Custom)

  • Datenbank-Redo-Protokolldateien (nur RDS Custom for Oracle)

  • Transaktionsprotokolle (nur RDS Custom for SQL Server)

  • Benutzerdefinierte Engine-Versionsartefakte (nur RDS Custom for Oracle)

RDS Custom erstellt den do-not-delete-rds-custom--S3-Bucket beim Erstellen einer der folgenden Ressourcen:

  • Ihre erste CEV für RDS Custom for Oracle

  • Ihre erste DB-Instance für RDS Custom for SQL Server

RDS Custom erstellt einen Bucket für jede Kombination der folgenden Optionen:

  • AWS-Konto ID

  • Engine-Typ (entweder RDS Custom for Oracle oder RDS Custom for SQL Server)

  • AWS-Region

Wenn Sie z. B. RDS Custom for Oracle CEVs in einer einzigen AWS-Region erstellen, ist ein do-not-delete-rds-custom--Bucket vorhanden. Wenn Sie mehrere RDS-Custom-for-SQL-Server-Instances erstellen und sich diese in verschiedenen AWS-Regionen befinden, ist ein do-not-delete-rds-custom--Bucket in jeder AWS-Region vorhanden. Wenn Sie eine RDS-Custom-for-Oracle-Instance und zwei RDS-Custom-for-SQL-Server-Instances in einer einzigen AWS-Region erstellen, sind zwei do-not-delete-rds-custom--Buckets vorhanden.

AWS CloudTrail

RDS Custom erstellt automatisch einen AWS CloudTrail-Trail, dessen Name mit do-not-delete-rds-custom- beginnt. Der RDS-Custom-Support-Perimeter basiert auf den Ereignissen von CloudTrail, um festzustellen, ob sich Ihre Aktionen auf die RDS-Custom-Automatisierung auswirken. Weitere Informationen finden Sie unter Fehlerbehebung bei nicht unterstützten Konfigurationen.

RDS Custom erstellt den Trail, wenn Sie Ihre erste DB-Instance erstellen. RDS Custom erstellt einen Trail für jede Kombination der folgenden Optionen:

  • AWS-Konto ID

  • Engine-Typ (entweder RDS Custom for Oracle oder RDS Custom for SQL Server)

  • AWS-Region

Wenn Sie eine DB-Instance von RDS Custom löschen, wird der CloudTrail für diese Instance nicht automatisch entfernt. In diesem Fall wird Ihrem AWS-Konto der nicht gelöschte CloudTrail weiterhin in Rechnung gestellt. RDS Custom ist nicht verantwortlich für das Löschen dieser Ressource. Informationen zum manuellen Entfernen von CloudTrail finden Sie unter Löschen eines Trails im AWS CloudTrail-Benutzerhandbuch.