DB2 Versión 9.7 para Linux, UNIX y Windows
DB2 Versión 9.7 para Linux, UNIX y Windows
El archivo db2nodes.cfg se utiliza para definir los servidores de partición de base de datos que participan en una instancia de DB2. El archivo db2nodes.cfg también se utiliza para especificar la dirección IP o el nombre de sistema principal de una interconexión de alta velocidad, si desea utilizar una interconexión de alta velocidad para la comunicación entre servidores de partición de base de datos.
El formato del archivo db2nodes.cfg en los sistemas operativos Linux y UNIX es el siguiente:
númparticiónbd nombresistprincipal puertológico nombred nombconjrecursosnúmparticiónbd
, nombresistprincipal, puertológico, nombrered y nombreconjuntorecursos se definen en el apartado siguiente.
El formato del archivo db2nodes.cfg en el sistema operativo Windows es el siguiente:
númparticiónbd nombresistprincipal nombresistema puertológico nombrered nombreconjuntorecursos
En los sistemas operativos Windows, estas entradas en el archivo db2nodes.cfg se añaden mediante los mandatos db2ncrt o START DBM ADD DBPARTITIONNUM. El mandato db2nchg también puede modificar las entradas. No debería añadir estas líneas directamente o editar este archivo.
Para escalar el sistema de bases de datos particionadas, añada una entrada para cada servidor de partición de base de datos al archivo db2nodes.cfg. El valor de númparticiónbd que seleccione para los servidores de partición de base de datos adicionales debe estar en orden ascendente; no obstante, pueden existir huecos en esta secuencia. Puede elegir dejar un hueco entre los valores de númparticiónbd si piensa añadir servidores de partición lógica y desea conservar los nodos agrupados de forma lógica en este archivo.
Esta entrada es obligatoria.
Si en el archivo db2nodes.cfg se proporcionan nombres de sistema principal en lugar de direcciones IP el gestor de base de datos intentará resolver dinámicamente los nombres de sistema principal. La resolución puede ser local o a través de búsqueda en los Servidores de nombres del dominio (DNS), según determinen los valores del sistema operativo en la máquina.
A partir de DB2 Versión 9.1, se admiten los protocolos TCP/IPv4 y TCP/IPv6. El método para resolver los nombres de sistema principal ha cambiado.
Mientras el método utilizado en los releases anteriores a la Versión 9.1 resuelve la serie tal como se ha definido en el archivo db2nodes.cfg, el método de la Versión 9.1 o de versiones posteriores intenta resolver Nombres de dominio calificados al completo (FQDN) cuando los nombres cortos están definidos en el archivo db2nodes.cfg. La especificación de nombres cortos configurados para nombres de sistema principal calificados al completo, puede conducir a retrasos innecesarios en procesos que resuelven nombres de sistema principal.
Para evitar cualquier retraso en mandatos DB2 que requieran resolución de nombre de sistema principal, utilice cualquiera de los siguientes métodos alternativos:
db2 catalog tcpip4 node db2tcp2 remote 192.0.32.67 server db2inst1 with "Look up IPv4 address from 192.0.32.67"
db2 catalog tcpip6 node db2tcp3 1080:0:0:0:8:800:200C:417A server 50000 with "Look up IPv6 address from 1080:0:0:0:8:800:200C:417A"
DB2 reserva un rango de puertos (por ejemplo, 60000 - 60003) en el archivo /etc/services para las comunicaciones entre particiones en el momento de la instalación. Este campo puertológico en db2nodes.cfg especifica qué puerto del rango desea asignar a un servidor de partición lógica específico.
Si no hay ninguna entrada para este campo, el valor por omisión es 0. Sin embargo, si añade una entrada para el campo nombrered, debe entrar un número para el campo puertológico.
Si utiliza particiones lógicas de base de datos, el valor de puertológico que especifique debe comenzar en 0 y continuar en orden ascendente (por ejemplo, 0,1,2).
Además, si especifica una entrada de puertológico para un servidor de partición de base de datos, debe especificar un puertológico para cada uno de los servidores de partición de base de datos listados en el archivo db2nodes.cfg.
Este campo sólo es opcional si no se utilizan particiones lógicas de base de datos ni una interconexión de alta velocidad.
Si en este campo hay una entrada especificada, todas las comunicaciones entre servidores de partición de base de datos (excepto las comunicaciones como resultado de los mandatos db2start, db2stop y db2_all) se manejarán mediante la interconexión de alta velocidad.
Este parámetro sólo es necesario si utiliza una interconexión de alta velocidad para las comunicaciones de particiones de bases de datos.
Este parámetro sólo está soportado en AIX, HP-UX y el Entorno Operativo Solaris.
En AIX, este concepto se conoce como "conjuntos de recursos" y en el Entorno Operativo Solaris se denomina "proyectos". Para obtener más información sobre la gestión de recursos, consulte la documentación para su sistema operativo.
En HP-UX, el parámetro nombconjrecursos es el nombre de un grupo PRM. Para obtener más información, consulte la documentación "HP-UX Process Resource Manager. User Guide. (B8733-90007)" de HP.
En los sistemas operativos Windows, la afinidad de procesos para un nodo lógico se puede definir mediante la variable de registro DB2PROCESSORS.
En los sistemas operativos Linux, la columna nombconjrecursos define un número que corresponde a un nodo NUMA (acceso de memoria no uniforme) del sistema. El programa de utilidad del sistema numactl debe estar disponible, así como un kernel 2.6 con soporte a la política NUMA.
El parámetro nombrered debe especificarse si se utiliza el parámetro nombconjrecursos.
Utilice las configuraciones de ejemplo siguientes para determinar la configuración adecuada para su entorno.
0 ServidorA 0 1 ServidorA 1 2 ServidorA 2 3 ServidorA 3
0 ServidorA 0 1 ServidorB 0
4 ServidorA 0 6 ServidorA 1 8 ServidorA 2 9 ServidorB 0
0 ServidorA 0 switch1 1 ServidorB 0 switch2 2 ServidorB 1 switch2
Estas restricciones se aplican a los ejemplos siguientes:
A continuación, se muestra un ejemplo de cómo configurar el conjunto de recursos para sistemas operativos AIX.
En este ejemplo, hay un nodo físico con 32 procesadores y 8 particiones lógicas de bases de datos (MLN). Este ejemplo muestra cómo proporcionar la afinidad de procesos para cada MLN.
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.00031vmo -p -o memory_affinity=1
chuser capabilities=
CAP_BYPASS_RAC_VMM,CAP_PROPAGATE,CAP_NUMA_ATTACH db2inst11 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
Este ejemplo muestra cómo utilizar grupos PRM para comparticiones de CPU en una máquina con 4 CPU y 4 MLN y 24% de compartimiento de CPU por cada MLN, dejando el 4% para otras aplicaciones. El nombre de instancia de DB2 es 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
La configuración de PRM (pasos 1-3) se puede realizar utilizando la herramienta de la GUI interactiva xprm.
En los sistemas operativos Linux, la columna nombconjrecursos define un número que corresponde a un nodo NUMA (acceso de memoria no uniforme) del sistema. Debe estar disponible el programa de utilidad del sistema numactl así como un kernel 2.6 con soporte a la política NUMA. Consulte la página man para numact1 para obtener más información sobre el soporte a NUMA en los sistemas operativos Linux.
Este ejemplo muestra cómo configurar un sistema NUMA de cuatro nodos con cada uno de los nodos lógicos asociado con un nodo NUMA.
$ numactl --hardwareSe visualizará una salida similar a la siguiente:
disponibles: 4 nodos (0-3) tamaño de nodo 0: 1901 MB nodo 0 libre: 1457 MB tamaño de nodo 1: 1910 MB nodo 1 libre: 1841 MB tamaño de nodo 2: 1910 MB nodo 2 libre: 1851 MB tamaño de nodo 3: 1905 MB nodo 3 libre: 1796 MB
0 hostname 0 hostname 0 1 hostname 1 hostname 1 2 hostname 2 hostname 2 3 hostname 3 hostname 3
A continuación, se muestra un ejemplo de cómo configurar el proyecto para Solaris Versión 9.
En este ejemplo, hay 1 nodo físico con 8 procesadores: una CPU se utilizará para el proyecto por omisión, tres (3) CPU las utilizará el Servidor de aplicaciones y cuatro (4) CPU las utilizará DB2. El nombre de instancia es 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