Oracle RAC 10g unter Linux Eine kostengünstige Hochverfügbarkeitslösung?

Transkript

1 Donnerstag, 10. November h00, Mozartsaal Oracle RAC 10g unter Linux Eine kostengünstige Hochverfügbarkeitslösung? Guido Saxler ORDIX AG, Köln Schlüsselworte: Oracle, RAC 10g, Real Application Cluster (RAC), Hochverfügbarkeit, Cluster, Linux, ASM, Cluster Ready Service (CRS), Standard Edition, Erfahrungsbericht Einleitung Hochverfügbarkeit ist ein Thema das auch in konjunkturschwächeren Zeiten oft gefragt beziehungsweise nachgefragt wird. Mit dem neuesten Oracle Release 10g soll dieses Interesse auch bei kleineren und mittelständischen Unternehmen geweckt werden. Mit der Einführung des Release 10g ist nun bereits in der Standard Edition eine RAC Lizenz enthalten, die auf maximal 4 CPUs limitiert ist (siehe Abbildung 1). Was jedoch kaum jemand hinterfragt, sind die technischen Anforderungen und Skills, die bei dem Einsatz des Real Application Clusters anfallen. Der folgende Artikel zeigt die technischen Details und fasst die Anforderungen an den Datenbankadministrator zusammen. Abb. 1: Lizenz-/Wartungspreise Oracle Real Application Cluster Architektur Der Oracle Real Application Cluster ist eine parallele Cluster Datenbank. Im Gegensatz zur Single Instanz Architektur besteht RAC aus mehreren Instanzen, die auf eine geshared-te Datenbank zugreifen (siehe Abbildung 2). Neben den softwaretechnischen müssen ebenfalls bestimmte hardwaretechnische Voraussetzungen erfüllt sein. Ein Shared Storage sowie ein Cluster Interconnect (privates Netzwerk) müssen zur Verfügung gestellt werden.

2 18. Deutsche ORACLE-Anwenderkonferenz DB-Entwicklung Abb. 2: RAC Architektur Die Kernkomponente der Oracle RAC Architektur bildet die Cache Fusion Technologie. Diese wurde bereits mit Oracle 9i eingeführt und in 10g weiterentwickelt. Cache Fusion verschmelzt vom Ansatz her alle Datenbankinstanzen miteinander. Kernkomponenten der Cache Fusion Technologie sind der Global Cache Service (GCS) und der Global Enqueue Service (GES). Über den Private Interconnect werden die Informationen zwischen den beteiligten Cluster Nodes/Instanzen ausgetauscht. Wenn ein Datenbankblock benötigt wird, der bereits im Cache einer anderen Instanz vorhanden ist, wird dieser über den Interconnect in den Cache der anfordernden Instanz übertragen (Block Shipping). Die Komponenten Storage Der Oracle Real Application Cluster benötigt einen Shared Storage. Das bedeutet, dass alle beteiligten Cluster Nodes (beziehungsweise Instanzen) uneingeschränkten Zugriff auf den zentralen Festplattenbereich haben müssen. Die folgenden Datenbankdateien müssen von allen Instanzen aus zugreifbar sein. Files Online Redo Log Files Control Files Offline/Archived Redo Log Files Des Weiteren kann bei Verwendung eines spfiles (Parameterfile) dieses ebenso auf den Shared Storage für alle Instanzen bereitgestellt werden. In bestimmten Fällen kann sogar das ORACLE_HOME Verzeichnis geshared werden. Für den Cluster Ready Service (CRS), die neue Clusterware von Oracle, werden die folgenden beiden Devices auf dem Shared Storage benötigt: Oracle Cluster Registry (OCR) Disk Voting Disk (früher quorum File) Die folgenden Storage Varianten stehen uns für den Einsatz von Oracle RAC zur Verfügung: RAW Devices RAW Devices sind einfache, nicht formatierte Festplatten Partitionen. Mit Ausnahme der Archived Redo Logs können RAW Devices für alle anderen Dateitypen verwendet werden. Auch für den Einsatz des Cluster Ready Services, also OCR und Voting Disk, sind RAW Devices geeignet. Cluster Filesysteme (z. B. Oracle Cluster Filesystem oder 3rd Party Hersteller) Hier handelt es sich um Filesysteme, die von allen Nodes aus gelesen und geschrieben werden können. Oracle selbst stellt ein freies (GPL) Cluster Filesystem auf Linux (RedHat) und Windows zur Verfügung: Das Oracle Cluster Filesystem (OCFS). Weitere Informationen dazu finden Sie unter Des Weiteren stehen andere zertifizierte Systeme zur Verfügung. Network attached Storage (NAS) NAS stellt Festplattenkapazität über das Netzwerk zur Verfügung, sozusagen ein modifiziertes NFS. Durch das ISCSI Protokoll können sogar RAW Partitionen bereitgestellt werden. Die Server werden auch als Filer bezeichnet.

3 Oracle Automatic Storage Management (ASM) ASM wurde mit dem Release 10g eingeführt. Hierbei handelt es sich um einen im Oracle Kernel integrierten Volume Manager. Beim Einsatz der RAC Option mit der Standard Edition muss ASM aus lizenztechnischen Gründen verwendet werden. Alle Oracle Dateitypen inklusive der Archived Redo Log Files können mittels ASM verwaltet werden. Auch die Parameterdatei (spfile) kann in ASM gespeichert werden. Die OCR Disk und die Voting Disk hingegen können nicht mittels ASM verwaltet werden. Abb. 3: ASM Architektur In Abbildung 3 ist die ASM Architektur dargestellt. Die Verwaltung beziehungsweise Bereitstellung des Festplattenplatzes stellt die ASM Instanz zur Verfügung. Wie eine normale Oracle Instanz besteht auch eine ASM Instanz aus einer SGA und mehreren Hintergrundprozessen. Der Speicherplatz wird in Form von Diskgroups verwaltet. ASM arbeitet nach dem SAME-Prinzip (stipe and mirror everything). Eine Diskgroup kann aus bis zu drei Failgroups bestehen. Eine Failgroup besteht in der Regel aus mehreren Disks (RAW Devices). Die Daten werden von ASM automatisch über die Failgroups hinweg gespiegelt. Innerhalb der Failgroup werden die Daten gestriped. Somit gewährleistet ASM ein optimales I/O-Verhalten. Netzwerk/Interconnect Eine sehr wichtige Rolle in einem Cluster spielt das privates Netzwerk. Das private Netzwerk wird auch als Cluster Interconnect bezeichnet. Der Cluster Interconnect dient als Basis Kommunikation für die Cluster-Dienste. Des Weiteren ist er die Grundlage für die Cache Fusion Architektur (GCS/GES). Eine kostengünstige Variante des Interconnects ist GB Ethernet. Hierbei handelt es sich um ein GB Ethernet Interface, welches direkt beziehungsweise über einen Ethernet Switch mit den anderen Cluster Nodes verbunden ist. Von größter Bedeutung ist auch hier die redundante Auslegung der einzelnen Hardware- Komponenten. Neben dem privaten Netzwerk steht mit Oracle RAC 10g auch ein weiteres, virtuelles Netzwerk zur Verfügung. Jeder beteiligte Node verfügt über eine virtuelle IP-Adresse beziehungsweise einen virtuellen Hostnamen. Die IP-Adresse wird im Failover Fall auf einen anderen Cluster Node übernommen. Auch diese Funktionalität übernimmt der Cluster Ready Service. Die virtuelle IP-Adresse bildet somit die logische Adresse des gesamten Clusters. Oracle Cluster Ready Service (CRS) Der Cluster Ready Service wurde ebenfalls erst in der Version 10g eingeführt und steht für alle Plattformen zur Verfügung. Der aus dem Release 9i bekannte Cluster Manager war nur für Linux und Windows verfügbar. Der Cluster Ready Service übernimmt alle grundlegenden Cluster-Funktionalitäten und besteht aus den folgenden drei Komponenten: Cluster Ready Service (CRS) Event Manager (EVM) Cluster Synchronisation Service (CSS)

4 18. Deutsche ORACLE-Anwenderkonferenz Die Cluster Ready Konfiguration wird in der OCR Disk abgespeichert. Hierfür muss ein circa 100 MB großes Device zur Verfügung stehen. Ein weiteres Device ist die Voting Disk. Damit stellt der Cluster Ready Service das Eigentümerrecht des Clusters bei Ausfall des Interconnects sicher. Nur der Cluster Node, der den exklusiven Zugriff auf die Voting Disk hat, bleibt aktiv. Alle anderen werden durch den CRS heruntergefahren (Vermeidung des Split-Brain Phänomens). DB-Entwicklung Cluster Datenbank Die Unterschiede einer Cluster Datenbank zu einer Single Instance Datenbank sind recht gering. So besitzt jede Instanz ihr eigenes UNDO Tablespace und ihre eigenen Redo Log Files (siehe Abbildung 4). Abb. 4: Oracle Cluster /Konfiguration Failover und Load-Balancing In diesem Abschnitt geht es u. a. auch um die zentrale Frage: Warum eigentlich RAC? Hier gibt es zwei Hauptgründe: Performance (speedup/scaleup) und Hochverfügbarkeit. Jedoch sollte vor dem Einsatz von RAC eine detaillierte Beratung und Analyse der Performance- und der Hochverfügbarkeitsanforderungen erfolgen. Oracle RAC unterscheidet zwei Arten von Failover Szenarien: Das Connect Time Failover und das Transparent Application Failover. Die Einstellungen werden auf dem Client in der tnsnames.ora vorgenommen. Connect Time Failover Der Client wird einfach bei einem fehlerhaften Connect-Versuch mit einem anderen Listener (auf einem anderen Node) erneut verbunden. Auf welcher Instanz die Verbindung entsteht, wird in der tnsnames.ora innerhalb der DESCRIPTION Sektion mittels der ADDRESS LIST und dem Parameter FAILOVER=ON gesetzt. Transparent Application Failover (TAF) Der Unterschied zum Connect Time Failover ist, dass zusätzlich bestehende Connections auf eine andere Instanz übernommen werden. Hier unterscheidet man ebenfalls zwei Typen: Session Failover Alle laufenden SQLs werden abgebrochen und die Session wird auf eine andere Instanz übernommen. SQLs müssen neu gestartet werden. Select Failover Die Einstellung SELECT bedeutet, dass laufende SQL Statements mit übernommen werden. DML Befehle werden abgebrochen. Für die Übernahme der SELECT Statements ist die Einstellung PRECONNECT in der CONNECT_DATA Sektion notwendig. Damit wird beim Connect automatisch eine zweite Connection zu einer Backup-Instanz eröffnet. Select Statements werden somit bei einem Failover übernommen, neu gestartet und die Ausgabe beginnt an der aktuellen Cursor-Position von neuem. Für diesen Typ muss die Anwendung jedoch mittels des Oracle Call Interfaces (OCI) implementiert worden sein.

5 In Abbildung 5 sind die entsprechenden tnsnames.ora Einstellungen dargestellt. Abb. 5: tnsnames.ora Beispiel TAF/Load-Balancing Load-Balancing Die folgenden Arten des Load-Balancings werden vom Oracle Real Application Cluster unterstützt. Clientseitiges Load-Balancing Das clientseitige Load-Balancing wird wie beim Failover in der tnsnames.ora innerhalb der DESCRIP- TION Sektion angegeben (LOAD_BALANCE=ON). Hier wird die Verbindung einfach mittels eines Round- Robin-Verfahrens auf die entsprechenden Nodes (siehe ADDRESS LIST-Sektion) verteilt. Diese Methode eignet sich besonders beim Zugriff von Application Servern, die über ein eigenes Connection-Pooling verfügen. Serverseitiges Load-Balancing Beim serverseitigen Load-Balancing hingegen tauschen alle beteiligten Listener Informationen über den Workload der entsprechenden Instanzen und Nodes aus. Die Verbindung wird zu der Instanz beziehungsweise zu dem Node mit dem geringsten Workload hergestellt. Voraussetzung hierfür ist die Konfiguration von local_listener und remote_listener. Erfahrungsbericht Der Entscheidung für den Einsatz von RAC sollte eine gute Beratung vorausgehen. Die Erfahrung zeigt, dass es immer einer genauen Analyse der geforderten Hochverfügbarkeitsanforderungen bedarf, um die passende Lösung zu finden, die u. a. auch Data Guard heißen kann. Technische Probleme beim Einsatz des Real Application Clusters bezogen sich in erster Linie auf das erste Release und auf diverse Installations- und Laufzeitprobleme unter 64Bit-Betriebssystemen. Ein weiteres Defizit ist nach wie vor die fehlende Dokumentation des Oracle Cluster Ready Services. ASM zeichnet sich durch eine einfache Administration und hohe Stabilität aus. Fazit Die technischen Einzelheiten und Details zeigen die doch recht hohen Anforderungen an den Datenbankadministrator. Immer mehr Arbeiten fallen in seinen Aufgabenbereich: Von der Administration des Clusters (CRS) bis hin zur Verwaltung der ASM Diskgruppen. Ein weiterer, wichtiger Punkt sind die zum Teil doch stark limitierten Features, die beim Einsatz der Standard Edition zur Verfügung stehen. Der günstige Preis der Standard Edition geht zu Lasten der Funktionalität. Somit sind z. B. die Nutzung von Bitmap Indizes oder Data-Pump nicht möglich beziehungsweise lizensiert. In Abbildung 6 sind einige der nicht unterstützten Features aufgelistet.

6 18. Deutsche ORACLE-Anwenderkonferenz DB-Entwicklung Abb. 6: Nicht unterstützte Features der Standard Edition/SE One Um die eingangs gestellte Frage zu beantworten, müssen also nicht nur die direkten Kosten betrachtet werden, sondern auch die Anforderungen an das Personal beziehungsweise die eventuell anfallenden Kosten für externe Dienstleistung und Weiterbildung. Kontaktadresse: Guido Saxler ORDIX AG Wikingerstraße D Köln Telefon: +49 (0) 2 21 / Fax: +49 (0) 1 80 / info@ordix.de Internet: