Bei einem Single Instance Oracle System in der Standard Edition, das hohen Verfügbarkeitsanforderungen genügen muss, bietet sich die Verwendung einer Replikationslösung mittels Dbvisit Standby an. Problem sind die initial hohen Kosten für die neue Hardware und für die Lizenzen von Oracle und Dbvisit Standby. Je nach System kann das ein Betrag im mittleren fünfstelligen Euro Bereich sein.

Betreibt man aber das Standby System in der Cloud, beispielsweise bei Amazon oder Oracle, ergeben sich je nach Systemgröße Kosten von einigen Hundert Euro monatlich. Dies auch inclusive des hohen Kostenanteils für die Oracle Lizenzen!

Kosten können zudem eingespart werden, indem eine geringe CPU-Leistung für den Normalbetrieb im Standby Modus definiert wird, da lediglich die Ü„nderungen der Primärdatenbank eingearbeitet werden müssen. Nur im Fall eines Switch- oder Failover kann die CPU-Leistung entsprechend des Bedarfs für den Betrieb als Primärdatenbank angepasst werden.

Welche Unterschiede bringt die Cloud-Lösung mit sich und was ist besonders zu beachten?

Der Betrieb der Standby Lösung in der Cloud unterscheidet sich in keiner Weise von dem einer lokalen Lösung. Lediglich beim Setup sind ein paar Dinge zu beachten, die im Folgenden noch für die technisch interessierten Leser beschrieben werden.

Was sich für den Administrator ändert, ist vor allem, dass ein tieferes Verständnis in den Bereichen Netzwerk und Sicherheit vorhanden sein sollte. Beispielsweise empfiehlt es sich, den kompletten SQL Netzwerkverkehr zu verschlüsseln. Der Aufwand ist nur gering und es fallen schon seit längerem keine zusätzlichen Lizenzkosten dafür an. Dbvisit Standby verschlüsselt den systemeigenen Netzwerkverkehr per Default. Natürlich müssen die unten genannten Ports in der firmeneigenen Firewall freigeschaltet werden. Ist dies nicht möglich, ist eine Replikation in die Cloud leider keine Alternative.

Ein nicht zu unterschätzender Aspekt ist auch die Netzwerkanbindung vom lokalen Standort in die Cloud. Die Hauptfrage ist hier, ob die Verbindung den Anforderungen gewachsen ist. Der notwendige Durchsatz der Anbindung hängt von der verwendeten Applikation ab. Eine Messung des Durchsatzes der Netzwerkkarte des lokalen Datenbankservers liefert hier eine erste valide Orientierung.

Was ist nun technisch zu beachten?

  • Für den Betrieb der Remotedatenbank muss zunächst ein sogenannter Key Pair definiert werden.
  • Die Firewalls müssen für die benötigten Ports freigeschaltet werden (Default sind hier 1521 für den Oracle Listener und 4433, 7890 und 7891 für die Dbvisit Funktionalitäten). Ob dies der Fall ist, kann durch den Befehl telnet überprüft werden.
  • In den Dateien

$DBV_HOME/dbvagent/conf/dbvagent.conf

und

$DBV_HOME/dbvnet/conf/dbvnetd.conf

muss der Eintrag listener_address= von auf 0.0.0.0 gesetzt werden.

  • Wichtig ist auch, die IP-Adresse des Primärsystems im öffentlichen Netzwerk zu kennen (Ermittlung z. B. mittels https://ipleak.net).

Fazit

Eine Internetanbindung, die nicht leistungsfähig genug ist, stellt aber ebenso ein Hindernis für diesen Lösungsansatz dar, wie sehr sensible Informationen, z. B. Patientendaten.

Für viele andere Anwendungen aber ist eine solch hybride Architektur, der Betrieb sowohl lokal, als auch in der Cloud, eine kostengünstige und wenig aufwändige Lösung.

 

PS: Hier noch ein Screenshot einer Konsole eines so definierten virtuellen Cloud Standby Systems:

xx

Alle Beiträge von Rainier Kaczmarczyk

Seit 35 Jahren mit Oracle zu Gange... Ich startete damals mit Version 5.0 Nun: Immer noch mit Oracle beschäftigt. Zudem: Dbvisit (Hochverfügbarkeit). Ein Dbvisit Evangelist.

Schreibe einen Kommentar