www.oracle-consulting.de

High Performance Oracle Consulting
Sicherheitskonzepte - TOC

Security: Beispiel für den Zugriff von Applikationsserver auf Datenbanken
Betrieb: Failover und Loadbalancing
Betrieb: Partitionsierungskonzepte
Betrieb: Notification Framework

Sicherheitskonzepte

Um ihre Daten und Anwendungen vor unbeabsichtigter oder beabsichtigter Manipulation und Verluß zu schützen ist ein modernes Sicherheitskonzept notwendig. Wir bereaten sie und implementieren gemeinsam mit ihnen:

  • Virtual Privat Databases
  • Replikation über Oracle Strems
  • View Layer Konzepte zur Separierung von Applikationsusern und Object-Ownern
  • RMAN backup und Recovery
  • Physical Standby Database

Beipiel: Zugriff von Application Servern

Ein typische Anwendungsfall ist der Zugriff vom Application-Server auf die Datenbank. Für optimale Nutzung der RAC-Features sowie zur Einhaltung der Sicherheitsrichtlinien muß die jdbc-Datasource korrekt konfiguriert sein. Der Zugriff erfolgt über ein Layer-Konzept. Hierbei wird das Datenschema gelocked, die notwendigen Rechte für die Objekte werden an den Applikationsuser über Views und Synonyme gegeben.

Somit hat der Applikationsuser keinen direkten Zugriff auf die Objekte und kann diese nicht verändern. Über das Viewkonzept wir ein zusätzlicher Apstraktionslayer eingefügt, so das Änderungen in Schema über die Views gekapselt sind. Damit können Datenbank- und Applikationsänderungen unabhängig voneinander ausgeführt werden.

     

Die jdbc-Datasource sollte über Service-Namen auf die Oracle-Instanz zugreifen, eine re-connect fähige Konfiguration kann wie folgt aussehen.

zurück...

Betriebskonzepte

Basierend auf langjährigen Erfahrungen und dank unsere standardisierten Betriebskonzeptes können wir den Betrieb ihrer Applikation sowie nowendie Wartungsarbeiten effizient ausführen. Sie profitieren von Experten, die wann immer notwendig für die Wartung und Problemlösung zur Verfügung stehen. Über ein 'shared-resource' Konzept haben sie jederzeit Zugriff auf das komplette Know-How und die komplette Erfahrung, ohne selber ein teures Expertenteam vor Ort halten zu müssen.

Über definierte SLA's sind die für ihre Datenbank wichtigen Verfügbarkeitskriterien abgesichert, ein automaitsches Monitoring und Alerting erlaubt es proaktiv auf sich abzeichnende Probleme zu reagieren.

Failover und Loadbalancing

Einer der wichtigesten Gründe für den Einsatz eines RAC-Systems besteht in der Möglichkeit von Failover und Load Balancing. Diese Funktionalitäten müssen auf den jeweiligen Anwendungsfall und die jeweils eingesetzte Appliaktionssoftware abgestimmt sein.


Load Balancing

Oracle unterscheided zwischen 2 Arten von Loadbalancing:

Client-side Load Balancing

Das Client-side Load Balancing ist kein echtes Loadbalancing und wird in der TNSNAMES.ORA des Clients mit dem Parameter LOAD_BALANCE=on eingestellt.
Der Client verbindet sich hierbei mit einer der in der Konfiguration angegebenen Instanz nach dem Zufallsprinzip. Dies führt zu einer fast gleichmäßigen Verteilung neuer Verbindungen auf die Clusterknoten, allerdings ohne Berücksichtigung des aktuellen Zustands bzw. der Last der Server
Die Konfiguration sollte ausschließlich auf Basis von Servicenamen (SERVICE_NAME) erfolgen und keine SID verwenden.

Durch die Verwendung von Service-Namen wird ebenfalls eine Reconnect-Möglichkeit bei Ausfall eines Clusterknotens geschaffen.

Beispielkonfiguration:

sample.world =(DESCRIPTION=
(LOAD_BALANCE=OFF)
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=viprac1)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=viprac2)(PORT=1521))
)
(CONNECT_DATA=(service_name=sample_service)))


Hier erfolgt die Verbindung zu den RAC-Instanzen immer in angegebenen Reichenfolge. Wird LOAD_BALANCE=ON gesetzt erfolgt die Wahl der Serverinstanz für die Verbindung zufällig.

Beispielkonfiguration:

sample.world =(DESCRIPTION=
(LOAD_BALANCE=ON)
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=viprac1)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=viprac2)(PORT=1521))
)
(CONNECT_DATA=(service_name=sample_service)))


Connection Load Balancing

Neben der Möglichkeit, das Load Balancing beim Client zu realisieren, kann das Load Balancing auch auf der Server-Seite konfiguriert werden. Der Verbindungsaubau läuft dann in folgender Reihenfolge ab:

* der am wenigsten belastete Knoten
* die am wenigsten belastete Instanz
* der am wenigsten belastete Dispatcher bei einer Sharde Server Installation


Hierfür muß für jede Instanz des Clusters der Parameter *.remote_listener='SAMPLE_REMOTE_LSNR' gesetzt sein. In der tnsnames.ora muß ein folgender Eintrag existieren:

SAMPLE_REMOTE_LSNR=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=viprac1)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=viprac2)(PORT=1521))
)

Wichtiger Hinweis für den Betrieb:
Bei einer Konfiguration des Loadbalancings auf mehrere Instanzen eines Rac-System muß immer die Arbeitsweise der Applikation berücksichtigt werden. Unter Umständen kann es zu einer hohen Belastung des Interconnect sowie zu einer Häufung von GC-Wait-Events kommen. Hierdurch kann die Gesamtperformance des Systems wesentich reduziert werden. Der Einsatz eines Loadbalancing sollte immer unter Berücksichtigung dieser Punkte erfolgen.


Failover:
Durch den Einsatz einer Failover-Konfiguration kann die Verfügbarkeit der Applikation auch bei Ausfall eines oder mehrerer RAC-Knoten sichergestellt werden. Hierbei werden 2 Failover-Szenarien unterschieden:

Connerct Time Failover

Dies ist relativ unkritisch und sollte bei der Konfiguration der Applikation bei Nutzung einer RAC-Datenbank eingesetzt werden. Hier versucht Oracle Net sich mit einer der in der Konfiguration angegebenen Instanz zu verbinden.

Beispielkonfiguration:

sample.world =(DESCRIPTION=
(FAILOVER=ON)
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=viprac1)(PORT=1521))
(ADDRESS=(PROTOCOL=tcp)(HOST=viprac2)(PORT=1521))
)
(CONNECT_DATA=(service_name=sample_service)))

Eine bei Ausfall einer Instanz mit dieser verbundenen Session wir im Failover Fall abgebrochen und muß eine neue Vervbindung aufbauen. Dies erfolgt aber nicht automatisch.

Transparant Application Failover

Bricht eine Instanz im laufenden Betrieb die Verbindung ab wird die Session auf eine verfügbare Instanz neu Verbunden.


Hierbei bestehen jedoch einige Einschränkungen, die von der Applikation adäquat behandelt werden müssen. Zum einen werden bestehende, noch nicht mittels commit bestätigte Transaktionen abgebrochen, zum anderen werden Einstellungen zur aktuellen Session (alter session ...) in der Datenbankinstanz gehalten und gehen bei dem Übergang verloren .

Beispielkonfiguration:

sample.world=(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = viprac1)(PORT = 1521))
(ADDRESS = (PROTOCOL = TCP)(HOST = viprac2)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = sample_service )
(FAILOVER_MODE = ( TYPE=SELECT)
( METHOD=BASIC)
( RETRIES=20)
( DELAY=30))))

TYPE

SESSION Aktuelle Abfragen werden abgebrochen.
SELECT Ein aktuell laufendes SELECT-Statement wird über die neue Verbindung noch einmal ausgeführt. Die Rückgabe des Resultsets des Statements wird an der richtigen Stelle fortgeführt.

METHOD

BASIC Bei dieser Standardmethode wird die Verbindung zur Failover-Instanz erst im Failover-Fall aufgenommen.
PRECONNECT Im Gegensatz zur BASIC-Methode werden die Verbindungen zu den anderen Knoten des Systems beim Connect erstellt und in Reserve gehalten. Dadurch wird bei einem Failover der Overhead der Verbindungaufnahme vermieden, sodass es zu einer schnelleren Weiterführung der Session kommt. Nachteilig ist natürlich der damit verbundene Overhead an Prozessen und der Hauptspeicherverbrauch.

BACKUP

NS_ALIAS Hier kann ein TNS-Alias einer Backup-Instanz angegeben werden. Bei einem Failover wird dann auf diese Instanz bzw. TNS-Alias-Definition gewechselt.

RETRIES

ANZAHL und
DELAY = SEKUNDEN Definition des zeitlichen Verhaltens bei erneuter Verbindungsaufnahme, also wie oft und mit welchem Abstand wird ein neuer Connect versucht.

zurück...

Beispiel - Partitionierungskonzept

Aktuelle Daten werden in Tagespartitionen gehalten, historische Daten in Monatspartitionen. Somit wird die Anzahl der Partitionen limitiert, durch regelmäßige Maintenancejobs können Historische Partitionen auf Tape ausgelagert werden und Partitione per truncate / drop entfernt werden. Dies spart resourcenintensive Delete-Statements.

Der automatische Partitionsjob erstellt tagesaktuell neue Partitionen und merged historische Partitionen monatsweise.

zurück...

Beipiel - Notification Framework

Eine einfache Möglichkeit für Benachrichtigungen bietet Oracle mit dem dbms_smtp Package. Mit Hilfe dieses Packages kann eine einfache Notifikation-Infrastruktur gebaut werden, über die in Abhängigkeit der Prioritäten auch SMS-Nachrichten verschickt werden.

In Konfigurationstabellen werden zum einen die Nachrichten, zum anderen die Empfänger pro Nachricht definiert. Das Senden der Nachrichten erfolgt über die Angabe der Nachrichtennummer, alle zugeordneten Empfänger werden dann informiert.

Der Package Body sieht wie folgt aus:

zurück...