Zurück

High Availability Kozepte

Ziele und Abgrenzungen

Von High Availability (HA) spricht man wenn ein System nach einem Ausfall automatisch auf einem anderen (Ausfall-System) weiterlaufen soll. Es stehen verschiedene Möglichkeiten, je nach Anforderung zur Verfügung. Bewusst wird in der folgenden Zusammenstellung nicht auf die Ausfallsicherheit von Platten (Disk-Arrays) mit den entsprechenden RAID-Levels eingegangen.

Grundsätzlich stehen folgende Möglichkeiten zur Verfügung

  • Backup Tape Shipping
  • Standby Databases
  • Oracle Parallel Server
  • Proprietäre Systeme (zB HP-Service-Guard, VERITAS-AXXiON)
  • Oracle Multimaster Replication
  • Geo-Mirroring

Backup Tape Shipping

Tape wird auf einem Ausfallsystem nach einem Ausfall des produktiven System eingelesen. Das Failover-System muss gleich vorkonfiguriert sein wie das Produktivsystem.

backup_tape_shipping.gif (4665 Byte)

Vorteile

  • Kostengünstige Möglichkeit
  • Failover-Site als Testumgebung nutzen

Nachteile

  • System fällt längere Zeit aus
  • Fehleranfällig (geschultes Personal nötig
  • Failover-Maschine muss kompatibel zu Primary sein
  • Datenverlust möglich

Standby Database

Eine Standby Database wird mit den offline Redologs laufend oder bei Bedarf aktuell gehalten. Die offline Redolog-Files werden via Tape oder über NFS zur Failover Datenbank geschickt.

stand_by.gif (4234 Byte)

Vorteile

  • Relativ einfach zu implementieren
  • Via NFS kann Failover-DB nahezu aktuell gehalten werden
  • Auch als Geo-Mirroring Variante tauglich (Standortwechsel

Nachteile

  • System fällt längere Zeit aus
  • Standby-DB kann nicht parallel zu Primary-DB genutzt werden
  • Erst nach dem letzten applizierten Redologfile kann die Standby-DB geöffnet werden
  • Korrupte DB-Strukturen der Primary DB werden auf die Standby-DB übertragen

  • Failover-Maschine muss kompatibel zu Primary-Maschine sein

Proprietäre Systeme

Proprietäre Systemen wie HP-Service-Guard oder VERITAS-AXXiON ist gemeinsam, dass die Failover-Datenbank auf den Secondary-Host «gezügelt» werden. Es erfolgt also in jedem Fall ein Shutdown der Datenbank.

axxion.gif (5751 Byte)

Vorteile

  • Nur kurzer Unterbruch der DB und Applikationen.
  • Failover-System kann für andere Zwecke benutzt werden.
  • Relativ bewährte Technologie, gutes Know-How vorhanden.
  • Auch Applikationen können auf diese Weise überwacht werden.

Nachteile

  • SHUTDOWN ABORT kann zu korrupter DB führen.
  • Sehr viel Memory-Bedarf um alle Instanzen auf einem Host zu betreiben

Proprietäre Systeme eignen sich hervorragend für Application-Failover‘s, aber weniger für echte DB-Failover, da in jedem Fall die Datenbank auf dem Secondary Host neu gestartet werden muss.

Weitere Informationen: http://www.veritas.com

Oracle Parallel Server

Oracle Parallel Server und Multimaster Replication stellen eine gleichzeitig verfügbare gespiegelte DB-Instanz zur Verfügung, sie bieten also die grösste Ausfallsicherheit an. Das Ziel des Oracle Parallel Servers ist nebst der HA-Komponente die parallele Verarbeitung von Daten. Dies kann jedoch nur bei gut parallisierten Applikationen genutzt werden, ansonsten kann die Performance sogar schlechter werden. Dies inbesondere dann, wenn mehrere DB-Instanzen die gleichen DB-Blocks verändern müssen. Oracle Parallel Server zeichnet sich durch folgende Merkmale aus:

oracle_parallel_server.gif (5216 Byte)

Vorteile

  • Gespiegelte Instanzen (parallele Verarbeitung), in der Skizze sind die Instanzen Instance-1 und Instance-1‘ parallele Instanzen. Die Instanz-2 ist eine ganz normale DB-Instanz.
  • Jede Instanz hat seine eigenen Redolog-Files.
  • Ein Recovery kann an jeder Instanz eingespielt werden, die anderen Instanzen werden automatisch nachgefahren.
  • Query-transparenter Failover, das heisst es erfolgt kein DB-Shutdown.
  • Offene Transaktionen werden bei einem Failover mit einem Rollback rückgängig gemacht.
  • Nur kurze «Black-Out Phase» bei einem Failover.
  • SQL*NET Client‘s werden automatisch auf Failoversystem geroutet, es erfolgt aber ein Connect und Reconnect.
  • Connect Load Balancing (automatische Lastverteilung) der Clients.
  • OPS ist OLTP fähig unter Oracle-8, durch fine grain Locking.
  • Oracle Enterprise Manager unterstützt OPS.
  • Integrierter DLM (Distributed Lock Manager) unter Oracle-8

Nachteile

  • Ein Applikationsfailover kann mit OPS nicht durchgeführt werden, OPS richtet sich ausschliesslich an die Oracle-Datenbank.
  • Für die Shared Disks ist zwingend ein RAW-Device erforderlich.
  • Teuer, ca SFR 750.-- pro connected User.
  • Relativ anspruchsvoll im Betrieb, ein gut ausgebildetes Betreiberteam ist notwendig.

Multimaster Replikation

Multimaster Replikationen sichern auch ein Site-Failure ab (Feuer, Wasser, Zerstörung, etc). Alle DB-Änderungen werden asynchron auf die andere Master-Site transferiert. UPDATES sind auf allen Knoten möglich.

multi_master_snapshot.gif (4510 Byte)

Vorteile

  • Site Failure abgedeckt.
  • Keine «Black-Out» Phase nach Failover.
  • Nodes können von unterschiedlichen Herstellern sein

Nachteile

  • Komplexe Konfiguration, anspruchsvoll im Betrieb, ein gut ausgebildetes Betreiberteam ist notwendig.
  • Conflict resolution kann anspruchsvoll werden
  • Datenverlust ist möglich da eine asynchrone Replikation erfolgt.