Hablando de Oracle RAC: la arquitectura básica del software de gestión de clústeres GI
Hoy viernes, creo que puedo pasar el fin de semana y estoy de buen humor. Lo más favorito de la semana es el viernes por la noche, y el menos favorito es el domingo por la noche y el lunes Parece que no soy una persona que ama el trabajo. Aprovechando el buen humor ahora, siéntate y sigue escribiendo mi blog.
En el blog de ayer, presenté qué es Oracle RAC. Quienes no lo hayan visto pueden consultarlo. Decimos que Oracle RAC es una base de datos construida sobre la base de software de gestión de clústeres en términos de tecnología de implementación. Entonces, la base del estudio de Oracle RAC es comprender los principios del software de administración de clústeres.
En el blog de ayer, presentamos que Oracle ya no depende del software de administración de clústeres de terceros, sino que tiene su propio software de administración de clústeres estandarizado y potente: Grid Infrastructure (GI).
1. La estructura básica de la IG
Tomemos 19c como ejemplo para ver de qué componentes y recursos está hecha la IG.
Después de leer la imagen de arriba, muchos estudiantes pueden sorprenderse de que GI tenga demasiados componentes y recursos. De hecho, no necesita preocuparse por eso, pero algunas estructuras grandes deben estar claramente estructuradas. Mientras dominemos estas relaciones jerárquicas, esta imagen se vuelve simple.
Para abreviar la historia, primero extraigamos los componentes centrales de GI.
1.1 OHASD
OHASD es el demonio de inicio del clúster. En la figura anterior, podemos ver que OHASD inicia tres procesos que terminan en agente, que llamamos procesos de agente. Estos procesos de agente se utilizan en realidad para iniciar / detener / monitorear los componentes o recursos administrados. Es como si OHASD fuera un presidente, y se asignan tres gerentes para administrar los conceptos de diferentes departamentos.
Entre los muchos componentes y recursos administrados por el proceso de agente de OHASD, hay varios componentes centrales, a saber, CSSD y CRSD.
1.2 CSSD
Este componente es responsable de construir el clúster y mantener la consistencia del clúster. La razón por la que un clúster se denomina clúster debe ser para vincular diferentes computadoras a través de algún mecanismo. CSSD es el componente principal para mantener la coherencia del clúster.
Cada nodo tiene un demonio CSSD.Estos procesos se comunican a través de una red privada y envían periódicamente latidos de red a otros nodos para confirmar el estado de comunicación entre los diferentes nodos. Al mismo tiempo, el CSSD de cada nodo enviará periódicamente latidos del disco al disco compartido para garantizar que todos los nodos miembros puedan leer y escribir el disco común a través de IO.
1.3 CRSD
Este componente es principalmente responsable de administrar los recursos en el clúster.
Si miramos la imagen de arriba, CRSD también generará un proceso de proxy. Estos procesos de agentes administrarán muchos recursos comenzando con ora. Lo que debe enfatizarse aquí es que no todos los recursos comienzan con ora. En términos generales, los recursos que comienzan con ora son los recursos que vienen con Oracle. Los recursos definidos por el cliente no necesariamente comienzan con ora.
Echemos un vistazo más de cerca a los recursos administrados por CRSD y veamos si encontramos el nombre del recurso ora.DB.db. Así es, así es como aparece la instancia de Oracle RAC en el clúster. La instancia de la base de datos Oracle RAC es administrada por el componente CRSD en forma de recursos. La base de datos aquí es el nombre de la base de datos que creó.
Después de capturar los tres componentes principales anteriores, suavicemos el proceso del agente.
Son:
1.1 orarootagent, cssdagent y oraagent iniciado por OHASD.
1.2 El orarootagent y oraagent iniciado por CRSD.
De lo anterior se puede ver que el proceso de agente solo puede ser generado por OHASD y CRSD, y ningún otro componente generará procesos de agente.
Extraiga estos tres componentes importantes y luego siga los componentes o recursos del proceso del agente para comprender si esta imagen no es tan complicada.
Por supuesto, los componentes y recursos internos tienen sus propias funciones únicas, y encontraremos tiempo para expandirnos en el futuro.
2. Inicio de GI
A continuación, comencemos GI y luego veamos la secuencia de inicio.
El comando de inicio de GI es crsctl start crs. Agregué -esperar al final para imprimir la información de inicio en la pantalla. Si no se agrega -wait, no se emite información. La autoridad de ejecución de crsctl es el usuario root.
[root@node1 ~]#crsctl start crs -wait
CRS-4123: Starting Oracle High Availability Services-managed resources
CRS-2672: Attempting to start 'ora.mdnsd' on 'node1'
CRS-2672: Attempting to start 'ora.evmd' on 'node1'
CRS-2676: Start of 'ora.mdnsd' on 'node1' succeeded
CRS-2676: Start of 'ora.evmd' on 'node1' succeeded
CRS-2672: Attempting to start 'ora.gpnpd' on 'node1'
CRS-2676: Start of 'ora.gpnpd' on 'node1' succeeded
CRS-2672: Attempting to start 'ora.gipcd' on 'node1'
CRS-2676: Start of 'ora.gipcd' on 'node1' succeeded
CRS-2672: Attempting to start 'ora.crf' on 'node1'
CRS-2672: Attempting to start 'ora.cssdmonitor' on 'node1'
CRS-2676: Start of 'ora.cssdmonitor' on 'node1' succeeded
CRS-2672: Attempting to start 'ora.cssd' on 'node1'
CRS-2672: Attempting to start 'ora.diskmon' on 'node1'
CRS-2676: Start of 'ora.diskmon' on 'node1' succeeded
CRS-2676: Start of 'ora.crf' on 'node1' succeeded
CRS-2676: Start of 'ora.cssd' on 'node1' succeeded
CRS-2672: Attempting to start 'ora.cluster_interconnect.haip' on 'node1'
CRS-2672: Attempting to start 'ora.ctssd' on 'node1'
CRS-2676: Start of 'ora.ctssd' on 'node1' succeeded
CRS-2676: Start of 'ora.cluster_interconnect.haip' on 'node1' succeeded
CRS-2672: Attempting to start 'ora.asm' on 'node1'
CRS-2676: Start of 'ora.asm' on 'node1' succeeded
CRS-2672: Attempting to start 'ora.storage' on 'node1'
CRS-2676: Start of 'ora.storage' on 'node1' succeeded
CRS-2672: Attempting to start 'ora.crsd' on 'node1'
CRS-2676: Start of 'ora.crsd' on 'node1' succeeded
CRS-6023: Starting Oracle Cluster Ready Services-managed resources
CRS-6017: Processing resource auto-start for servers: node1
CRS-2672: Attempting to start 'ora.ons' on 'node1'
CRS-2672: Attempting to start 'ora.chad' on 'node1'
CRS-2676: Start of 'ora.chad' on 'node1' succeeded
CRS-2676: Start of 'ora.ons' on 'node1' succeeded
CRS-2672: Attempting to start 'ora.DATA.dg' on 'node1'
CRS-2676: Start of 'ora.DATA.dg' on 'node1' succeeded
CRS-2672: Attempting to start 'ora.orcl.db' on 'node1'
CRS-2676: Start of 'ora.orcl.db' on 'node1' succeeded
CRS-2672: Attempting to start 'ora.orcl.orcltest.svc' on 'node1'
CRS-2676: Start of 'ora.orcl.orcltest.svc' on 'node1' succeeded
CRS-6016: Resource auto-start has completed for server node1
CRS-6024: Completed start of Oracle Cluster Ready Services-managed resources
CRS-4123: Oracle High Availability Services has been started.
A partir de la información de salida anterior, vimos por primera vez CRS-4123.
CRS-4123: Starting Oracle High Availability Services-managed resources
A partir de este contenido, podemos ver que necesitamos poner en marcha los recursos gestionados por OHAS. Luego, genere la información de inicio de los componentes y recursos administrados por OHAS. Aquí podemos ver que CSSD y CRSD, que más nos importan, se han activado.
CRS-2676: Start of 'ora.cssd' on 'node1' succeeded
CRS-2676: Start of 'ora.crsd' on 'node1' succeeded
Luego vimos la salida de CRS-6023.
CRS-6023: Starting Oracle Cluster Ready Services-managed resources
Al observar el contenido de la información de CRS-6023, el siguiente paso es iniciar los recursos administrados por CRSD. Luego, se inician todos los recursos de la base de datos ora.orcl.db.
Cuando el inicio sea exitoso, se generará la siguiente información.
CRS-4123: Oracle High Availability Services has been started
A partir de la salida de información anterior, podemos ver que el inicio de GI se divide en dos módulos principales. Uno es el módulo de inicio de recursos administrado por OHASD y el otro es el módulo de inicio de recursos administrado por CRSD.
A través de la información de salida de inicio anterior y luego hacer coincidir el diagrama de estructura anterior, podemos comprender el marco básico de GI con mayor claridad.
3. Confirmación del proceso relacionado con la IG
Ya sea que estemos hablando de componentes o recursos anteriores, debe manifestarse en varios procesos en el sistema operativo.
A través del comando ps podemos ver el proceso principal de GI.
[root@node1 ~]# ps -ef | grep /u01/64bit/app/19.3.0/grid/bin/
root 24048 1 3 11:53 ? 00:00:48 /u01/64bit/app/19.3.0/grid/bin/ohasd.bin reboot _ORA_BLOCKING_STACK_LOCALE=AMERICAN_AMERICA.US7ASCII
root 24452 1 0 11:54 ? 00:00:12 /u01/64bit/app/19.3.0/grid/bin/orarootagent.bin
grid 24629 1 1 11:54 ? 00:00:13 /u01/64bit/app/19.3.0/grid/bin/oraagent.bin
grid 24674 1 0 11:54 ? 00:00:06 /u01/64bit/app/19.3.0/grid/bin/mdnsd.bin
grid 24676 1 1 11:54 ? 00:00:17 /u01/64bit/app/19.3.0/grid/bin/evmd.bin
grid 24755 1 0 11:54 ? 00:00:07 /u01/64bit/app/19.3.0/grid/bin/gpnpd.bin
grid 24832 24676 0 11:54 ? 00:00:06 /u01/64bit/app/19.3.0/grid/bin/evmlogger.bin -o /u01/64bit/app/19.3.0/grid/log/[HOSTNAME]/evmd/evmlogger.info -l /u01/64bit/app/19.3.0/grid/log/[HOSTNAME]/evmd/evmlogger.log
grid 24892 1 1 11:54 ? 00:00:16 /u01/64bit/app/19.3.0/grid/bin/gipcd.bin
root 25139 1 0 11:54 ? 00:00:07 /u01/64bit/app/19.3.0/grid/bin/cssdmonitor
root 25142 1 4 11:54 ? 00:01:00 /u01/64bit/app/19.3.0/grid/bin/osysmond.bin
root 25191 1 0 11:54 ? 00:00:07 /u01/64bit/app/19.3.0/grid/bin/cssdagent
grid 25249 1 3 11:54 ? 00:00:44 /u01/64bit/app/19.3.0/grid/bin/ocssd.bin
root 25839 1 1 11:54 ? 00:00:17 /u01/64bit/app/19.3.0/grid/bin/octssd.bin reboot
root 26294 1 2 11:54 ? 00:00:27 /u01/64bit/app/19.3.0/grid/bin/crsd.bin reboot
root 26857 1 1 11:55 ? 00:00:22 /u01/64bit/app/19.3.0/grid/bin/orarootagent.bin
grid 27514 1 2 11:55 ? 00:00:26 /u01/64bit/app/19.3.0/grid/bin/oraagent.bin
grid 27651 1 0 11:55 ? 00:00:00 /u01/64bit/app/19.3.0/grid/bin/tnslsnr LISTENER -no_crs_notify -inherit
grid 27757 1 0 11:55 ? 00:00:00 /u01/64bit/app/19.3.0/grid/bin/tnslsnr ASMNET1LSNR_ASM -no_crs_notify -inherit
oracle 28900 1 0 11:55 ? 00:00:08 /u01/64bit/app/19.3.0/grid/bin/oraagent.bin
root 29849 25142 0 11:56 ? 00:00:03 /u01/64bit/app/19.3.0/grid/perl/bin/perl /u01/64bit/app/19.3.0/grid/bin/diagsnap.pl start
De lo anterior, podemos ver que el usuario del proceso del agente o un agente con pid = 28900 es Oracle. Esto se debe a que cuando instalé este conjunto de Oracle RAC, el usuario de la cuadrícula instaló el software GI y el software DB lo instaló el usuario de Oracle. Entonces, para administrar la base de datos, el proceso de agente generado por CRSD pertenece a Oracle.
grid 24629 1 1 11:54 ? 00:00:13 /u01/64bit/app/19.3.0/grid/bin/oraagent.bin
grid 27514 1 2 11:55 ? 00:00:26 /u01/64bit/app/19.3.0/grid/bin/oraagent.bin
oracle 28900 1 0 11:55 ? 00:00:08 /u01/64bit/app/19.3.0/grid/bin/oraagent.bin
root 24452 1 0 11:54 ? 00:02:06 /u01/64bit/app/19.3.0/grid/bin/orarootagent.bin
root 26857 1 1 11:55 ? 00:04:38 /u01/64bit/app/19.3.0/grid/bin/orarootagent.bin
El usuario del proceso del agente o un agente con pid = 24629 y 27514 es la cuadrícula. Los usuarios del proceso de agente o agente de raíz con pid = 24452 y 26857 también son cuadrículas. ¿Cómo puede aparecer un proceso de agente con el mismo nombre? Cuando volvemos a la figura anterior, podemos ver que tanto OHASD como CRSD han generado procesos de agentes llamados oraagent y orarootagent.
En circunstancias normales, no es necesario distinguir los pids de estos procesos de agentes. Porque solo necesitamos mirar los registros de seguimiento de estos procesos de agentes cuando investigamos problemas. Los nombres de los archivos de registro de seguimiento de estos procesos de agentes tienen nombres previos. Es fácil distinguir el registro del proceso del agente que se va a ver.
/u01/64bit/app/grid/diag/crs/node1/crs/trace/crsd_oraagent_grid.trc
/u01/64bit/app/grid/diag/crs/node1/crs/trace/ohasd_oraagent_grid.trc
/u01/64bit/app/grid/diag/crs/node1/crs/trace/crsd_orarootagent_root.trc
/u01/64bit/app/grid/diag/crs/node1/crs/trace/ohasd_orarootagent_root.trc
Pero cuando necesita matar manualmente el proceso del agente, es necesario encontrar el objeto que se va a matar. En este momento, ¿cómo confirmamos cuál es el proceso agente de OHASD y cuál es el proceso agente de CRSD?
De hecho, podemos emitir un juicio basado en el registro de alarmas del clúster. El siguiente es un resumen de la salida del registro de alarmas cuando se inicia el clúster.
2021-03-19 11:54:04.297 [OHASD(24048)]CRS-1301: Oracle High Availability Service started on node node1.
...
2021-03-19 11:54:09.525 [ORAROOTAGENT(24452)]CRS-8500: Oracle Clusterware ORAROOTAGENT process is starting with operating system process ID 24452
2021-03-19 11:54:12.075 [ORAAGENT(24629)]CRS-8500: Oracle Clusterware ORAAGENT process is starting with operating system process ID 24629
...
2021-03-19 11:55:01.612 [CRSD(26294)]CRS-1201: CRSD started on node node1.
...
2021-03-19 11:55:04.324 [ORAROOTAGENT(26857)]CRS-8500: Oracle Clusterware ORAROOTAGENT process is starting with operating system process ID 26857
2021-03-19 11:55:19.113 [ORAAGENT(27514)]CRS-8500: Oracle Clusterware ORAAGENT process is starting with operating system process ID 27514
La salida detrás de CRS-1301 es el orarootagent con pid = 24452 y el proceso oraagent con pid = 24629. Entonces podemos determinar que es el proceso de agente iniciado por OHASD.
La salida detrás de CRS-1201 es el orarootagent con pid = 26857 y el proceso oraagent con pid = 27514. Entonces podemos determinar que este es un proceso de agente iniciado por CRSD.
Independientemente de si se trata de un inicio de GI o de procesos relacionados con GI mencionados anteriormente, en realidad están tratando de ayudar a todos a comprender la estructura básica de GI que inicialmente se descartó.
Siempre que tengamos una comprensión relativamente clara del diagrama de estructura básica de la IG anterior, será muy útil para nosotros estudiar las cuestiones de la IG en el futuro. Se puede decir que la imagen de arriba es la base para estudiar los problemas gastrointestinales.
4. Introducción al registro de GI
De repente mencionamos el registro de seguimiento del proceso del agente y el registro de alarmas de GI arriba. Parece un poco brusco. Como complemento, presentaré brevemente algunos sistemas de registro GI. Se puede decir que el estudio de las cuestiones GI, cualquier investigación y análisis fuera del registro es un deshonesto.
El sistema de registro de GI tiene un gran cambio en 12.2. Porque la versión anterior a la 18c ha superado el soporte Premier. Así que solo presento el sistema de registro después de la 12.2.
La mayoría de los registros de GI se almacenan en la siguiente ruta:
<Grid_Base>/diag/crs/<hostname>/crs/trace/
El registro de alarmas es un registro de salida completo de GI. Cualquier información importante en el componente GI se enviará a este registro. Su naturaleza es algo similar al registro de alarmas de la base de datos. Luego, los diversos componentes de GI y el proceso del agente también tienen sus propios registros de seguimiento.
Cuando investigamos problemas, a menudo necesitamos verificar cuidadosamente los registros de recursos o componentes y los registros de procesos de agentes relacionados. Debido a que estos componentes y procesos y recursos de agentes no existen de forma independiente, necesitamos rastrear la relación de acción interna a partir de ellos.
Además, estos troncos tienen su propio mecanismo de rotación. Si tengo tiempo en el futuro, escribiré un tema especial para presentar el sistema de registro de GI, y no continuaré expandiéndolo aquí.
La arquitectura GI es de hecho más complicada, y los estudiantes que recién están comenzando a menudo pueden estar perdidos. Intento ayudarte a entenderlo de forma resumida desde tu propia perspectiva, si tienes alguna duda puedes dejarme un mensaje.
Es demasiado tarde, así que escribamos aquí primero, ¡buenas noches!