Mithilfe der Datei db2nodes.cfg werden die Datenbankpartitionsserver definiert, die einer DB2-Instanz angehören. Außerdem wird über die Datei 'db2nodes.cfg' die IP-Adresse bzw. der Hostname einer Hochgeschwindigkeitsverbindung angegeben, falls Sie für die Kommunikation zwischen den Datenbankpartitionsservern eine Hochgeschwindigkeitsverbindung verwenden wollen.
Die Datei db2nodes.cfg unter Linux- und UNIX-Betriebssystemen hat das folgende Format:
dbpartitionsnum hostname logischer_port netzname ressourcengruppenname
dbpartitionsnum, hostname, logischer_port, netzname und ressourcengruppenname sind im folgenden Abschnitt definiert.
Die Datei db2nodes.cfg unter Windows-Betriebssystemen hat das folgende Format:
dbpartitionsnum hostname computername logischer_port netzname ressourcengruppenname
Unter Windows-Betriebssystemen werden diese Einträge mit dem Befehl db2ncrt oder START DBM ADD DBPARTITIONNUM zur Datei 'db2nodes.cfg' hinzugefügt. Die Einträge können auch mit dem Befehl db2nchg geändert werden. Sie sollten diese Zeilen weder direkt hinzufügen noch diese Datei bearbeiten.
Wenn Sie das partitionierte Datenbanksystem skalieren möchten, fügen Sie der Datei db2nodes.cfg für jeden Datenbankpartitionsserver jeweils einen Eintrag hinzu. Die Werte für dbpartitionsnum, die Sie für weitere Datenbankpartitionsserver auswählen, müssen aufsteigend, aber nicht direkt aufeinanderfolgend sein. Sie können zwischen den Werten von dbpartitionnum beispielsweise eine Lücke lassen, wenn Sie später logische Partitionsserver hinzufügen und für die Knoten eine logische Gruppierung in dieser Datei beibehalten möchten.
Dieser Eintrag ist erforderlich.
Wenn in der Datei db2nodes.cfg Hostnamen anstelle von IP-Adressen enthalten sind, versucht der Datenbankmanager, die Hostnamen dynamisch aufzulösen. Die Auflösung kann entweder lokal oder durch die Suche auf registrierten Domänennamensservern (Domain Name Servers, DNS) erfolgen - abhängig von den Betriebssystemeinstellungen auf der Maschine.
Ab DB2 Version 9.1 wird sowohl das Protokoll TCP/IPv4 als auch das Protokoll TCP/IPv6 unterstützt. Seither hat sich das Verfahren zur Auflösung der Hostnamen geändert.
Während in den Releases vor Version 9.1 die in Datei db2nodes.cfg definierte Zeichenfolge aufgelöst wurde, wird bei dem Verfahren ab Version 9.1 versucht, die vollständig qualifizierten Domänennamen (Fully Qualified Domain Names, FQDN) aufzulösen, wenn in Datei db2nodes.cfg Kurznamen definiert sind. Werden anstelle der vollständig qualifizierten Hostnamen die in der Konfigurationsdatei definierten Kurznamen verwendet, kann dies zu unnötigen Verzögerungen bei Prozessen führen, bei denen Hostnamen aufgelöst werden.
Um Verzögerungen bei der Verarbeitung von DB2-Befehlen zu vermeiden, die die Auflösung von Hostnamen voraussetzen, verwenden Sie eines der folgenden Verfahren, um das Problem zu umgehen:
db2 catalog tcpip4 node db2tcp2 remote 192.0.32.67 server db2inst1 with "IPv4-Adresssuche - 192.0.32.67"
db2 catalog tcpip6 node db2tcp3 1080:0:0:0:8:800:200C:417A server 50000 with "IPv6-Adresssuche - 1080:0:0:0:8:800:200C:417A"
Zum Zeitpunkt der Installation reserviert DB2 einen Portbereich (z. B. 60000 - 60003) in der Datei '/etc/services' für die Kommunikation zwischen den Partitionen. Das Feld für den logischen Port (logischer_port) in der Datei 'db2nodes.cfg' gibt an, welcher Port im Bereich einem bestimmten logischen Partitionsserver zugeordnet werden soll.
Wenn dieses Feld keinen Eintrag enthält, ist die Standardeinstellung 0. Wenn Sie jedoch einen Eintrag für das Feld für den Netznamen (netzname) hinzufügen, müssen Sie eine Nummer für das Feld für den logischen Port (logischer_port) angeben.
Wenn Sie logische Datenbankpartitionen verwenden, muss der von Ihnen angegebene Wert für logischer_port bei 0 beginnen und in aufsteigender Reihenfolge fortgesetzt werden (zum Beispiel 0,1,2).
Weiterhin gilt: Wenn Sie für einen Datenbankpartitionsserver einen Eintrag für logischer_port angeben, müssen Sie für jeden Datenbankpartitionsserver, der in der Datei db2nodes.cfg aufgelistet ist, einen logischen_port angeben.
Dieses Feld ist nur dann optional, wenn Sie keine logischen Datenbankpartitionen oder Hochgeschwindigkeitsverbindung verwenden.
Ist für dieses Feld ein Eintrag vorhanden, erfolgt die gesamte Kommunikation zwischen den Datenbankpartitionsservern (mit Ausnahme der Kommunikation als Ergebnis der Befehle db2start, db2stop und db2_all) über die Hochgeschwindigkeitsverbindung.
Dieser Parameter ist nur dann erforderlich, wenn Sie für die Kommunikation zwischen Datenbankpartitionen eine Hochgeschwindigkeitsverbindung verwenden.
Dieser Parameter wird nur unter AIX-, HP-UX- und Solaris-Betriebssystemen unterstützt.
Unter AIX wird dieses Konzept als 'Ressourcengruppen' und im Solaris-Betriebssystem als 'Projekte' bezeichnet. Weitere Informationen zum Ressourcenmanagement enthält die Dokumentation zum betreffenden Betriebssystem.
Unter HP-UX ist der Parameter für den Ressourcengruppennamen (ressourcengruppenname) ein Name der PRM-Gruppe. Weitere Informationen finden Sie in der Dokumentation 'HP-UX Process Resource Manager.User Guide. (B8733-90007)' von HP.
Unter Windows-Betriebssystemen kann die Prozessaffinität für einen logischen Knoten über die Registrierdatenbankvariable DB2PROCESSORS definiert werden.
Unter Linux-Betriebssystemen definiert die Spalte für den Ressourcengruppennamen (ressourcengruppenname) eine Nummer, die einem NUMA-Knoten (Non-Uniform Memory Access, NUMA) im System entspricht. Das Systemdienstprogramm numactl muss zusätzlich zu einem Kernel Version 2.6 mit Unterstützung für NUMA-Richtlinien verfügbar sein.
Der Parameter für den Netznamen (netzname) muss angegeben werden, wenn der Parameter für den Ressourcengruppennamen (ressourcengruppenname) verwendet wird.
Anhand der folgenden Beispielkonfigurationen können Sie die geeignete Konfiguration für Ihre Umgebung ermitteln.
0 ServerA 0 1 ServerA 1 2 ServerA 2 3 ServerA 3
0 ServerA 0 1 ServerB 0
4 ServerA 0 6 ServerA 1 8 ServerA 2 9 ServerB 0
0 ServerA 0 switch1 1 ServerB 0 switch2 2 ServerB 1 switch2
Diese Einschränkungen gelten für folgende Beispiele:
Das folgende Beispiel zeigt, wie die Ressourcengruppe für AIX-Betriebssysteme eingerichtet wird.
In diesem Beispiel gibt es einen (1) physischen Knoten mit 32 Prozessoren und 8 logischen Datenbankpartitionen (MLNs). Es wird gezeigt, wie Prozessaffinität für jeden dieser MLNs zur Verfügung gestellt wird.
DB2/MLN1: owner = db2inst1 group = system perm = rwr-r- resources = sys/cpu.00000,sys/cpu.00001,sys/cpu.00002,sys/cpu.00003 DB2/MLN2: owner = db2inst1 group = system perm = rwr-r- resources = sys/cpu.00004,sys/cpu.00005,sys/cpu.00006,sys/cpu.00007 DB2/MLN3: owner = db2inst1 group = system perm = rwr-r- resources = sys/cpu.00008,sys/cpu.00009,sys/cpu.00010,sys/cpu.00011 DB2/MLN4: owner = db2inst1 group = system perm = rwr-r- resources = sys/cpu.00012,sys/cpu.00013,sys/cpu.00014,sys/cpu.00015 DB2/MLN5: owner = db2inst1 group = system perm = rwr-r- resources = sys/cpu.00016,sys/cpu.00017,sys/cpu.00018,sys/cpu.00019 DB2/MLN6: owner = db2inst1 group = system perm = rwr-r- resources = sys/cpu.00020,sys/cpu.00021,sys/cpu.00022,sys/cpu.00023 DB2/MLN7: owner = db2inst1 group = system perm = rwr-r- resources = sys/cpu.00024,sys/cpu.00025,sys/cpu.00026,sys/cpu.00027 DB2/MLN8: owner = db2inst1 group = system perm = rwr-r- resources = sys/cpu.00028,sys/cpu.00029,sys/cpu.00030,sys/cpu.00031
vmo -p -o memory_affinity=1
chuser capabilities= CAP_BYPASS_RAC_VMM,CAP_PROPAGATE,CAP_NUMA_ATTACH db2inst1
1 regatta 0 regatta DB2/MLN1 2 regatta 1 regatta DB2/MLN2 3 regatta 2 regatta DB2/MLN3 4 regatta 3 regatta DB2/MLN4 5 regatta 4 regatta DB2/MLN5 6 regatta 5 regatta DB2/MLN6 7 regatta 6 regatta DB2/MLN7 8 regatta 7 regatta DB2/MLN8
Das folgende Beispiel zeigt, wie PRM-Gruppen für gemeinsam genutzte CPU-Kapazitäten auf einer Maschine mit 4 CPUs und 4 MLNs verwendet werden, wobei für jeden MLN 24 % der gemeinsamen CPU-Kapazität eingestellt werden sollen, so dass 4 % für andere Anwendungen übrig bleiben. Der Name der DB2-Instanz lautet 'db2inst1'.
OTHERS:1:4:: db2prm1:50:24:: db2prm2:51:24:: db2prm3:52:24:: db2prm4:53:24::
db2inst1::::OTHERS,db2prm1,db2prm2,db2prm3,db2prm4
prmconfig -i prmconfig -e CPU
1 voyager 0 voyager db2prm1 2 voyager 1 voyager db2prm2 3 voyager 2 voyager db2prm3 4 voyager 3 voyager db2prm4
Die PRM-Konfiguration (Schritte 1-3) kann mithilfe des interaktiven GUI-Tools 'xprm' erfolgen.
Unter Linux-Betriebssystemen definiert die Spalte für den Ressourcengruppennamen (ressourcengruppenname) eine Nummer, die einem NUMA-Knoten (Non-Uniform Memory Access, NUMA) im System entspricht. Das Systemdienstprogramm 'numactl' muss zusätzlich zu einem Kernel Version 2.6 mit Unterstützung für NUMA-Richtlinien verfügbar sein. Weitere Informationen zur NUMA-Unterstützung unter Linux-Betriebssystemen finden Sie auf der Man-Page für 'numact1'.
In diesem Beispiel wird erläutert, wie ein NUMA-Computer mit vier Knoten konfiguriert wird, wobei jedem logischen Knoten ein NUMA-Knoten zugeordnet ist.
$ numactl --hardwareDie Ausgabe sieht etwa wie folgt aus:
available: 4 nodes (0-3) node 0 size: 1901 MB node 0 free: 1457 MB node 1 size: 1910 MB node 1 free: 1841 MB node 2 size: 1910 MB node 2 free: 1851 MB node 3 size: 1905 MB node 3 free: 1796 MB
0 hostname 0 hostname 0 1 hostname 1 hostname 1 2 hostname 2 hostname 2 3 hostname 3 hostname 3
Das folgende Beispiel zeigt, wie das Projekt für Solaris Version 9 eingerichtet wird.
In diesem Beispiel gibt es einen (1) physischen Knoten mit acht (8) Prozessoren: Eine CPU wird für das Standardprojekt verwendet, drei (3) CPUs werden vom Anwendungsserver verwendet und vier (4) CPUs werden für DB2 verwendet. Der Instanzname lautet 'db2inst1'.
create system hostname create pset pset_default (uint pset.min = 1) create pset db0_pset (uint pset.min = 1; uint pset.max = 1) create pset db1_pset (uint pset.min = 1; uint pset.max = 1) create pset db2_pset (uint pset.min = 1; uint pset.max = 1) create pset db3_pset (uint pset.min = 1; uint pset.max = 1) create pset appsrv_pset (uint pset.min = 3; uint pset.max = 3) create pool pool_default (string pool.scheduler="TS"; boolean pool.default = true) create pool db0_pool (string pool.scheduler="TS") create pool db1_pool (string pool.scheduler="TS") create pool db2_pool (string pool.scheduler="TS") create pool db3_pool (string pool.scheduler="TS") create pool appsrv_pool (string pool.scheduler="TS") associate pool pool_default (pset pset_default) associate pool db0_pool (pset db0_pset) associate pool db1_pool (pset db1_pset) associate pool db2_pool (pset db2_pset) associate pool db3_pool (pset db3_pset) associate pool appsrv_pool (pset appsrv_pset)
system:0:::: user.root:1:::: noproject:2:::: default:3:::: group.staff:10:::: appsrv:4000:App Serv project:root::project.pool=appsrv_pool db2proj0:5000:DB2 Node 0 project:db2inst1,root::project.pool=db0_pool db2proj1:5001:DB2 Node 1 project:db2inst1,root::project.pool=db1_pool db2proj2:5002:DB2 Node 2 project:db2inst1,root::project.pool=db2_pool db2proj3:5003:DB2 Node 3 project:db2inst1,root::project.pool=db3_pool
0 hostname 0 hostname db2proj0 1 hostname 1 hostname db2proj1 2 hostname 2 hostname db2proj2 3 hostname 3 hostname db2proj3