Mit dem Trend, immer mehr Datenbanken auf einem Server zu konsolidieren stellt sich die Frage, ob bzw. wie es möglich ist, die einzelnen Datenbanken voneinander abzugrenzen und den Ressourcenverbrauch einzelner Datenbanken zu „deckeln“. Beim Hauptspeicher ist dies noch relativ simpel, da ja der Hauptverbraucher die SGA bzw. PGA sind und dem entsprechend parametriert werden können. Aber was ist mit der CPU? Standardmäßig werden alle Prozesse aller Instanzen einfach auf die verfügbaren CPUs verteilt. Doch seit einiger Zeit gibt es neue Methoden, die an dieser Stelle besprochen werden sollen.
Instance Caging
Instance Caging gibt es seit Version 11.2 und benutzt den Parameter cpu_count, um die Anzahl der für eine Instanz zur Verfügung stehenden CPUs zu begrenzen. Allerdings ist hierfür der Resource Manager eine Voraussetzung, so dass der Einsatz auf die Enterprise Edition beschränkt ist. Die Konfiguration ist sehr einfach, da es ausschließlich erforderlich ist, einen Resource Manager Plan (z.B. den DEFAULT Plan) zu aktivieren, der nicht weiter konfiguriert werden muss. Aber natürlich ist es möglich, eigene Resource Pläne zu erstellen und zu nutzen.
Beispiel
SQL> ALTER SYSTEM SET cpu_count=4; SQL> ALTER SYSETM SET RESOURCE_MANAGER_PLAN='DEFAULT';
Da der Parameter dynamisch geändert werden kann, ist es jederzeit möglich, einer Instanz mehr oder weniger CPUs zuzuordnen (z.B. für einen Batchlauf oder den obligatorischen Monatsabschluss).
Welche CPUs für diese Instanz genutzt werden, bleibt aber weiterhin dem Betriebssystem überlassen.
PROCESSOR_GROUP_NAME
PROCESSOR_GROUP_NAME ist ein Parameter, der mit der Version 12c eingeführt wurde und jetzt auch mit der Version 11.2.0.4 verfügbar ist. Hintergrund ist, dass es für bestimmte Betriebssysteme die Möglichkeit gibt, ganz dediziert Ressourcen, wie Memory, CPU, IO, Network, etc. zu gruppieren und Anwendungen zuzuteilen. Bei Linux nennt sich diese Funktion „control groups“ (kurz cgroups) und ist ab Kernel 2.6.32 verfügbar und bei Solaris gibt es seit der Version 11 SRU 4 die „resource pools“.
Das folgende Beispiel wurde mit Oracle Enterprise Linux 6U4 erstellt.
Um die Funktion nutzen zu können, muss zuerst einmal sichergestellt werden, dass die notwendige Prozesse gestartet wurden bzw. beim Booten automatisch gestartet werden.
# service cgconfig start # chkconfig cgconfig on
Der Service „cgconfig“ liest hierbei die Datei „/etc/cgconfdig.conf“ aus, die wir im Folgenden auf unsere Bedürfnisse anpassen. Dabei erstellen wir zunächst eine eigene Konfigurationsumgebung mit dem Namen „jocpuset“, weil wir ausschließlich die CPUs zuweisen und keine weitere Konfigurationsänderung (z.B. Memory) vornehmen wollen.
# cat /etc/cgconfig.conf
mount {
cpuset = /cgroup/jocpuset;
}
Als nächstes erstellen wir eine Gruppe und vergeben Rechte an den Benutzer Oracle und die DBA Gruppe, damit diese die Gruppe nutzen und administrieren können. Es ist also möglich, dass der Oracle DBA selbständig die Gruppen entsprechend der Notwendigkeit für die Datenbanken anpasst, ohne auf den OS-Administrator zurückgreifen zu müssen. Die Gruppe bekommt den Namen „grp-JOHANN“, d.h. aus dem Gruppennamen geht der Name der Datenbank hervor. Das ist sicherlich nicht die schlechteste Idee, wir wollen ja letztendlich mehreren Datenbanken ganz dediziert Ressourcen zuordnen.
group grp-JOHANN {
perm {
admin {
uid = oracle;
gid = dba;
}
task {
uid = oracle;
gid = dba;
}
}
cpuset {
cpuset.cpus="1,3";
}
Der alles entscheidende Punkt ist hier der Wert für cpuset.cpus. Es werden tatsächlich vorhandene CPUs bzw. Cores zugeordnet. In diesem Fall, bei einem Rechner mit einem Quadcore Prozessor also genau die Cores 1 und 3. Das ist der wichtigste Unterschied zum Instance Caging. Es werden dedizierte CPUs zugewiesen, so dass jede Instanz seine eigenen CPUs bekommt.
Wenn dies nicht gewünscht ist, können statt expliziter CPUs auch die bereits aus der Virtualisierung bekannten Shares genutzt werden. Wie bereits erwähnt ist die Ressourcenbegrenzung nicht auf CPUs beschränkt sondern kann auf andere Bereiche ausgedehnt werden.
Falls es zu einer fehlerhaften Zuordnung kommt oder man die Zuordnung einfach aufheben möchte, kann man mit dem folgenden Befehl die Konfiguration wieder löschen:
cgclear # löscht die gesamte Konfiguration oder cgclear grp-JOHANN # löscht die Gruppe grp-JOHANN
Was jetzt noch fehlt ist die Zuweisung der Control Group an die Datenbank. Im Gegensatz zum Parameter cpu_count ist der Parameter PROCESSOR_GROUP_NAME allerdings nicht dynamisch sondern kann nur durch einen Restart der Instanz aktiviert werden.
SQL> ALTER SYSTEM SET processor_group_name = 'grp_JOHANN' SCOPE=spfile;
Es sollte aber beachtet werden, dass die Instanz nicht mehr startet, wenn die Betriebssystemgruppe nicht mehr aktiv ist oder einen Fehler aufweist (z.B. weil sich die Anzahl CPUs für den Server geändert hat). In diesem Fall liefert die Fehlermeldung glücklicherweise ausreichend Informationen:
SQL> startup ORA-56729: Failed to bind the database instance to processor group grp-JOHANN; Additional Information: cpuset not found in /proc/mounts at skgsnmvpgs:3
Zusammenfassung
Meines Erachtens ist diese Funktion sehr hilfreich bei der Konsolidierung von Datenbanken. Auch wenn die in diesem Beispiel gewählte harten Zuweisung auf bestimmte CPUs vielleicht nicht ganz Ihren Vorstellungen entspricht, bedenken Sie, dass es auch die Linux Control Groups noch viel mehr Parameter zur Verfügung stellt und mit den Shares sicherlich auch eine interessante Alternative zu Instance Caging bietet.
Nicht vergessen sollte man außerdem, dass diese Funktion auch mit der Standard Edition bzw. Standard Edition One eingesetzt werden kann. Bleibt zu hoffen, dass dies vielleicht auch ein erster Schritt in die Änderung der Oracle Lizenzpolitik für virtuelle Umgebungen ist.
Wie immer würde ich mich über Anregungen bzw. eigene Erfahrungen als Kommentare sehr freuen.