Hace unos días en un cliente de produjo un reinicio abrupto de un nodo en un clúster Grid Infrastructure 12.1.0.2 por problemas hardware relacionados con el acceso a la SAN a través de una red 10GbE. El problema se repición en el otro nodo de madrugada al comenzar el volcado programado Data Pump de las bases de datos. Sin conocer el detalle del problema, estaba relacionado con la saturación de un puerto en un chasis de blades que, a través de algún mecanismo, forzaba el cierre del puerto y el consecuente corte de conectividad y reinicio del servidor.

Debido a la coincidencia del inicio de los exports, los administradores de sistemas analizaron el acceso a la cabina, viendo que la saturación era dabida, en el segundo de los reinicios, a la actividad sobre el filesystem ACFS que ya en ocasiones anteriores habíamos observado. Esta actividad era generada por el proceso automático de resilvering de ACFS.

¿Que es resilvering?

Se trata de un concepto asociado a la reconstrucción de un mirror de disco. La palabra es muy apropiada ya que resilver deriva de la acción de volver a tratar con plata las zonas deterioradas de un espejo (mirror) real de cristal. Esta capa de plata (o otro material como el aluminio), es la que convierte al cristan en un espejo, y la que, a medida que se deteriora, hace que aparezcan los «errores» y transparencias en el mismo.

Cuando se produce un problema en un raid, como la pérdida de uno de los discos que lo componen, el proceso de resilvering es el que, una vez incorporado el nuevo disco, reestablece la sincronización de los datos con la nueva configuración. Es más habitual encontrar este concepto como rebuild o resync, pero el concepto resilver es empleado también por ZFS, concepto similar al de ACFS desde el punto de vista de que se trata de una combinación de filesystem y volume manager. ZFS fue desarrollado por Sun Microsystems antes de su adquisición por Oracle. Entre las propiedades de ZFS, podemos ver:

The features of ZFS include protection against data corruption, support for high storage capacities, efficient data compression, integration of the concepts of filesystem and volume management, snapshots and copy-on-write clones, continuous integrity checking and automatic repair, RAID-Z and native NFSv4 ACLs.

Algunas son características que encontramos también en ACFS.

¿Por qué se hace resilvering?

En este caso, el proceso de resilvering se está realizando sobre un filesystem ACFS de casi 2 TiBs de tamaño. El diskgroup ASM sobre el que se creo el volumen ADVM y el filesystem ACFS están creados sobre LUNs que a nivel de cabina tienen establecidas una política bastante restrictiva a nivel de QoS, lo que estaba provocando que este proceso necesitase más de 10hpara completarse en algunas ocasiones.

En ASM / ACFS / ADVM, no es mucha la información oficial que pude encontrar sobre este procedimiento. La mayor parte de la información en MOS está relacionada con bugs, como por ejemplo el comentado en la nota 2071755.1 en la que se describe un problema de alto consumo de CPU po la actividad del proceso asmResilver1. Existe más información sobre el proceso de resilver relacionado con los sistemas Exadata u ODA, aunque no acaba de ser un proceso muy específico en cuanto a su implementación general a nivel de ACFS. En este punto, recomiendo la lectura de esta entrada y de esta otra del blog de Erman Arslan.

Resulta muy ilustrante la definición de los roles de los procesos asmResilver1 y asmResilver2 que actúan bajo condicionantes diferentes. Según esta información, asmResilver1 entra en juego ante escenarios de crash como la caída y recuperación de una instancia ASM, y verifica si es necesaria la recuperación de algún bloque en el mirror, encargándose de hacerlo en caso de ser así. asmResilver2 actúa cuando se produce una reconfiguración de clúster, por ejemplo tras el reinicio de un servidor del RAC. Este proceso verifica si el volumen ADVM necesita alguna operación de recuperación.

El proceso de resilvering es propio de ADVM y es diferente al proceso de rebalanceo de ASM que podemos ver en cualquier diskgroup ante cambios de almacenamiento, incluídos aquellos que contienen volúmenes ADVM. En sistemas Linux, podemos ver reflejada su actividad en el fichero /var/log/messages, donde el driver ADVM vuelca su salida.

ADVMK-0010: Mirror recovery for volume VOLACFS in diskgroup ACFS started

ADVM indicará cuándo se procuce una reconfiguración de clúster que fuerza al resilver de un volumen. En el escenario analizado, en el messages aparecen las siguientes entradas, al inicio de la reconfiguración, y el evento de fin de recuperación que recibe de cada uno de los nodos.

ADVMK-0013: Cluster reconfiguration started.
ADVMK-0014: Cluster reconfiguration completed.
ADVMK-0014: Cluster reconfiguration completed.

Procesos involucrados en el resilvering

En nuestro ejemplo, vemos que tras la caída forzada de un nodo, encontramos también dos procesos, aunque denominados asmResilver y asmResilver2, que son ejecutados como usuario root. El primero en esta ocasión es el responsable de validar los datos, mientras que el segundo lo hace con los metadatos DRL. Los proceso se ejecutan en el nodo responsable del resilver en curso, no detectando ningún proceso de este tipo en el otro nodo, ni siquiera cuando se recupera y se reincorpora al clúster. A nivel de ASM, non llegué a encontrar ninguna operación dentro de gv$asm_operation, pese a que esta vista contempla la opción de mostrar la tarea de resilvering, pero se trata de una casuística específica de Exadata cuando se habilita WriteBack FlashCache:

  • RESILVER – This value appears in Oracle Exadata environments when WriteBack FlashCache is enabled

Tampoco identifiqué en ninguno de los casos ningún fichero de traza específico asociado al proceso de resilvering. Sí parece tener relación el número de procesos ADVM en ejecución, muy superior en el nodo en donde se está haciendo el resilvering.

[root@nodo1 ~]# ps -ef | grep ADVM
root     11786     2  0 12:11 ?        00:00:00 [ADVM]
root     11787     2  0 12:11 ?        00:00:00 [ADVM]
root     25444     2  0 Apr26 ?        00:00:02 [ADVM]
root     29858     2  0 12:19 ?        00:00:00 [ADVM]

[oracle@nodo2 ~]$ ps -ef | grep ADVM
root     12347     2  3 12:45 ?        00:00:46 [ADVM]
root     23453     2  2 12:47 ?        00:00:35 [ADVM]
root     23454     2  3 12:47 ?        00:00:44 [ADVM]
root     23470     2  2 12:47 ?        00:00:39 [ADVM]
root     23472     2  3 12:47 ?        00:00:44 [ADVM]
root     23473     2  2 12:47 ?        00:00:29 [ADVM]
root     23485     2  2 12:47 ?        00:00:36 [ADVM]
root     23486     2  1 12:47 ?        00:00:27 [ADVM]
root     23487     2  1 12:47 ?        00:00:27 [ADVM]
root     23505     2  2 12:47 ?        00:00:33 [ADVM]
root     23506     2  2 12:47 ?        00:00:33 [ADVM]
root     23508     2  3 12:47 ?        00:00:44 [ADVM]
root     23509     2  2 12:47 ?        00:00:42 [ADVM]
root     23511     2  2 12:47 ?        00:00:38 [ADVM]

Según la información de los logs, estos procesos ADVM son aparentemente los procesos identificados como UsmMonitor.

Donde encontrar información sobre el proceso de resilvering

En este punto, si acudimos a la nota MOS , podemos ver la manera de mostrar el log correspondiente a ADVM, bien a través de la línea de comandos, bien a través del fichero /proc/oks/log. Este fichero es la traza en memoria del driver OKS (Oracle Kernel Service), uno de los 3 drivers kernel que componen ACFS, junto con ACFS y ADVM, y que Oracle agrupa en lo que se denomina USM kernel drivers. Podemos ver los tres drivers en un el directorio usm dentro de los módulos del kernel.

[root@nodo acfs]# ls -la /lib/modules/3.10.0-229.1.2.el7.x86_64/extra/usm/
total 65132
drwxr-xr-x 2 root root     4096 May  4  2016 .
drwxr-xr-x 3 root root     4096 May  4  2016 ..
-rw-r--r-- 1 root root 45106765 May  4  2016 oracleacfs.ko
-rw-r--r-- 1 root root 12644673 May  4  2016 oracleadvm.ko
-rw-r--r-- 1 root root  8926957 May  4  2016 oracleoks.ko

Desde la versión 11.2.0.3, este log también está disponible en disco, pudiendo acceder a él a través de $GRID_BASE/crsdata/<hostname>/acfs en 12c o de $GRID_HOME/log/<hostname>/acfs/kernel en 11gR2. Aquí podemos encontrar información del proceso de Resilver:

V 4294808.419/170427124724 asmResilver[23471] Asm_resilverVolume: EXPORT.volexpdp-440: resilver start
V 4294808.419 asmResilver[23471] Asm_startResilveringOps: EXPORT.volexpdp-440: initial broadcast recovProg=zero
K 4294825.656/170427124741 UsmMonitor[12350] Ks_reapZombies/ADVM free cb 0xffff880b0351a200/asmResilver ncbs=1 nops=1 runTm=17.651170 completions=0 completions Tm=0.000000
V 4298071.340 asmResilver[23471] Asm_waitResilveringDone: EXPORT.volexpdp-440: setting valb 0x18446744073709551614
V 4298071.340/170427134147 asmResilver[23471] Asm_freeResilverInfo: EXPORT.volexpdp-440: 2596096 regions 166150144 I/Os, 3263 secs

Adiciponalmente a la información de inicio y fin que podemos obtener en /var/log/messages, aquí podemos ver el resumen de la información en cuanto a tiempo de ejecución y número de IOs generadas en el proceso. Revisando este interesante log, podemos obtener más información sobre qué está ocurriendo y por qué este proceso está en marcha.

Por otro lado, la versión 12.1.0.2 de la Grid Infrastructure introduce la funcionalidad de binary logging para los drivers USM. En la misma ruta donde se generan los logs oks, tenemos logs binarios no editables en texto que pueden ser útiles en la apertura de casos con soporte. También aparece un fichero de eventos específico, donde también se registran, además de muchos otros, los eventos de resilvering que vemos en el messages. De hecho, es un fichero donce consultar de manera simple el histórico (al menos reciente) de eventos de resilvering.

[root@nodo2 acfs]# grep -i resilver event.log 
2016-05-18 10:17:53.446: asmResilver2[9027] Volume EXPORTORA.volexpdp-226: Mirror recovery start
2016-05-18 10:17:53.743: asmResilver2[9027] Volume EXPORTORA.volexpdp-226: Mirror recovery done
2016-06-01 14:41:55.352: asmResilver2[11555] Volume EXPORTORA.volexpdp-226: Mirror recovery start
2016-06-01 14:41:55.412: asmResilver2[11555] Volume EXPORTORA.volexpdp-226: Mirror recovery done
2016-06-02 15:27:39.535: asmResilver[6687] Volume ACFS.volacfscws-300: Mirror recovery start
2016-06-02 15:27:39.543: asmResilver[6687] Volume ACFS.volacfscws-300: Mirror recovery done
2016-06-02 15:27:39.778: asmResilver[8226] Volume EXPORTORA.volexpdp-226: Mirror recovery start
2016-06-02 15:27:39.844: asmResilver[8226] Volume EXPORTORA.volexpdp-226: Mirror recovery done
2016-06-03 19:25:47.052: asmResilver2[1940] Volume ACFS.volacfscws-300: Mirror recovery start
2016-06-03 19:25:47.055: asmResilver2[1940] Volume ACFS.volacfscws-300: Mirror recovery done
2016-06-03 19:25:47.232: asmResilver2[6660] Volume EXPORTORA.volexpdp-226: Mirror recovery start
2016-06-03 19:25:47.333: asmResilver2[6660] Volume EXPORTORA.volexpdp-226: Mirror recovery done
2016-06-07 11:33:32.637: asmResilver2[5345] Volume ACFS.volacfscws-300: Mirror recovery start
2016-06-07 11:33:32.640: asmResilver2[5345] Volume ACFS.volacfscws-300: Mirror recovery done
2016-06-07 11:33:32.857: asmResilver2[6660] Volume EXPORTORA.volexpdp-226: Mirror recovery start
2016-06-07 11:33:32.961: asmResilver2[6660] Volume EXPORTORA.volexpdp-226: Mirror recovery done
2016-06-07 16:50:33.263: asmResilver2[11470] Volume ACFS.volacfscws-300: Mirror recovery start
2016-06-07 16:50:33.267: asmResilver2[11470] Volume ACFS.volacfscws-300: Mirror recovery done
2016-06-07 16:50:33.671: asmResilver2[9805] Volume EXPORTORA.volexpdp-226: Mirror recovery start
2016-06-07 16:50:33.777: asmResilver2[9805] Volume EXPORTORA.volexpdp-226: Mirror recovery done
2016-06-07 20:22:10.277: asmResilver2[9843] Volume ACFS.volacfscws-300: Mirror recovery start
2016-06-07 20:22:10.281: asmResilver2[9843] Volume ACFS.volacfscws-300: Mirror recovery done
2016-06-07 20:22:10.410: asmResilver2[9842] Volume EXPORTORA.volexpdp-226: Mirror recovery start
2016-06-07 20:22:10.478: asmResilver2[9842] Volume EXPORTORA.volexpdp-226: Mirror recovery done
2016-09-03 18:48:29.779: asmResilver2[4253] Volume ACFS.volacfscws-300: Mirror recovery start
2016-09-03 18:48:30.173: asmResilver2[4252] Volume EXPORTORA.volexpdp-226: Mirror recovery start
2016-09-03 18:49:10.761: asmResilver2[4253] Volume ACFS.volacfscws-300: Mirror recovery done
2016-09-03 18:53:19.050: asmResilver2[4252] Volume EXPORTORA.volexpdp-226: Mirror recovery done
2016-09-03 18:53:19.242: asmResilver2[24255] Volume EXPORTORA.volexpdp-226: Mirror recovery start
2016-09-03 20:54:09.219: asmResilver2[24255] Volume EXPORTORA.volexpdp-226: Mirror recovery done
2017-04-11 10:11:23.334: asmResilver2[30137] Volume ACFS.volacfscws-300: Mirror recovery start
2017-04-11 10:11:23.989: asmResilver2[612] Volume EXPORT.volexpdp-440: Mirror recovery start
2017-04-11 10:11:48.686: asmResilver2[30137] Volume ACFS.volacfscws-300: Mirror recovery done
2017-04-11 10:16:51.762: asmResilver2[612] Volume EXPORT.volexpdp-440: Mirror recovery done
2017-04-11 10:16:51.966: asmResilver2[612] Volume EXPORT.volexpdp-440: Mirror recovery start
2017-04-12 12:40:15.534: asmResilver[24516] Volume EXPORT.volexpdp-440: Mirror recovery start
2017-04-12 12:46:31.157: asmResilver[24516] Volume EXPORT.volexpdp-440: Mirror recovery done
2017-04-12 15:16:12.374: asmResilver[24573] Volume EXPORT.volexpdp-440: Mirror recovery start
2017-04-12 16:49:11.462: asmResilver[24573] Volume EXPORT.volexpdp-440: Mirror recovery done
2017-04-27 12:47:24.115: asmResilver[23453] Volume ACFS.volacfscws-300: Mirror recovery start
2017-04-27 12:47:24.530: asmResilver[23471] Volume EXPORT.volexpdp-440: Mirror recovery start
2017-04-27 12:47:41.767: asmResilver[23453] Volume ACFS.volacfscws-300: Mirror recovery done
2017-04-27 13:41:47.451: asmResilver[23471] Volume EXPORT.volexpdp-440: Mirror recovery done

DRL

El proceso de resilvering es un proceso de reconstrucción de mirror basado en DRL (Dirty Region Logging), de empleo común en otros sistemas (por ejemplo Veritas Volume Manager) y que aplica un principio similar al journaling habitual en sistemas de ficheros como por ejemplo ext4. En el propio log de ADVM vemos que se referencia este concepto tanto en la nomenclatura como en la funcionalidad. Así, cuando arranca el volumen, vemos que se hace una verificación de los dirty bits, y además identificamos que los 1,8TiBs de datos están representados en un butmap de 17MiBs y un total de 7.167.232 bits.

V 4294808.039 multipathd[720] AsmVolStateOpen: EXPORT.volexpdp-440: checking for recovery, DRL segment: 0, DRL size: 17M
V 4294808.419 multipathd[720] Asm_logBits: EXPORT.volexpdp-440: Asm_buildRecovMap: recovProg -1, dirty bits = 2596096/7167232 36%

Regions

En el enlace de Veritas vemos una funcionalidad en la que se emplea un mapa de bits para representar el almacenamiento del volumen e identificar las regiones que están marcadas a nivel de mirror como «dirty». Un bit del mapa representa una región, en el caso de Veritas, 1024 sectores. En el caso de ADVM encontramos en el mismo log que el tamaño de cada región es de 512 bloques.

V 4294808.039 multipathd[720] Asm_drlVolAttach: <strong>512 blks/region</strong>, 219 pgs, -625344512 blks/vol, 7167231 voldEndB 128 pgNrpcr

Monitorizar un proceso de resilvering

Con una operación de cat o tail sobre /proc/oks/log o sobre acfs.log.0 a partir de 12.1.0.2, podemos identificar el procentaje de regiones dirty pendientes de procesar por parte del proceso asmResilver. Filtrando por la cadena ASM_logBits y por el volumen que nos interesa, podemos ver la evolución:

[root@nodo2 ~]# grep Asm_logBits /proc/oks/log | grep volexpdp-440
V 4294808.419 multipathd[720] Asm_logBits: EXPORT.volexpdp-440: Asm_buildRecovMap: recovProg -1, dirty bits = 2596096/7167232 36%
V 4295108.276 UsmRslvrUpd:PRO[23454] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 344814079, dirty bits = 2365134/7167232 32%
V 4295408.286 UsmRslvrUpd:PRO[23485] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 664690175, dirty bits = 2120532/7167232 29%
V 4295708.312 UsmRslvrUpd:PRO[23509] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 1003418111, dirty bits = 1892618/7167232 26%
V 4296008.304 UsmRslvrUpd:PRO[23473] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 1299421183, dirty bits = 1664439/7167232 23%
V 4296308.250 UsmRslvrUpd:PRO[23453] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 1622847999, dirty bits = 1420604/7167232 19%
V 4296608.332 UsmRslvrUpd:PRO[23511] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 1976684031, dirty bits = 1181212/7167232 16%
V 4296908.305 UsmRslvrUpd:PRO[23506] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 2339923967, dirty bits = 931023/7167232 12%
V 4297208.364 UsmRslvrUpd:PRO[23505] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 2677802495, dirty bits = 684544/7167232 9%
V 4297508.303 UsmRslvrUpd:PRO[23453] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 3034652671, dirty bits = 441843/7167232 6%
V 4297808.358 UsmRslvrUpd:PRO[23511] Asm_logBits: EXPORT.volexpdp-440: Asm_writeRecovMap: recovProg 3349218815, dirty bits = 217472/7167232 3%

Una vez completado este proceso, se lanzar el proceso asmResilver2, empleando un proceso por cada volumen ACFS montado por lo que indica el fichero de log. Este proceso, mucho más rápido que el resilver de datos, hace una verificación y corrección de problemas en los metadatos DRL para el almacenamiento del mirror. Podemos ver su actividad en el mismo log:

V 4298172.073 asmResilver2[23505] Asm_acqRecovery: EXPORT.volexpdp-440: rsid1=1b80101 rsid2=0
V 4298172.073 asmResilver2[23505] Asm_acqRecovery: EXPORT.volexpdp-440: value block INVALID
V 4298172.073 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 1
V 4298172.073 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: odlm_lock returned 36
V 4298172.073 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 2
V 4298172.082 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 2 is clean
V 4298172.082 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 3
V 4298172.086 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 3 is clean
V 4298172.086 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 4
V 4298172.090 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 4 is clean
V 4298172.090 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 5
V 4298172.094 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 5 is clean
V 4298172.094 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 6
V 4298172.104 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 6 is clean
V 4298172.104 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 7
V 4298172.111 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 7 is clean
V 4298172.111 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 8
V 4298172.118 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 8 is clean
V 4298172.118 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 9
V 4298172.122 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 9 is clean
V 4298172.122 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 10
V 4298172.128 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 10 is clean
V 4298172.128 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 11
V 4298172.132 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 11 is clean
V 4298172.132 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 12
V 4298172.141 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 12 is clean
V 4298172.141 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 13
V 4298172.150 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 13 is clean
V 4298172.150 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 14
V 4298172.156 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 14 is clean
V 4298172.156 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 15
V 4298172.160 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 15 is clean
V 4298172.160 asmResilver2[23505] Asm_acqSegment: EXPORT.volexpdp-440: called for SEG 16
V 4298172.165 asmResilver2[23505] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 16 is clean
V 4298172.213 asmResilver2[23505] Asm_startRecovery: EXPORT.volexpdp-440: is clean, no rcvy needed
V 4298172.215 asmResilver2[23505] Asm_startRecovery: EXPORT.volexpdp-440: mirror recovery thread exiting

¿Afecta una operación de resilver a todo el volumen ACFS?

Para mí, una de las principales dudas sobre este proceso era saber si cada vez que se producía una caída abrupta se hacía una reconstrucción completa del mirror, algo que no parecía tener sentido. Tras la revisión de estos logs, queda claro que no, que depende de la cantidad de regiones marcadas como dirty cuando comienza el proceso. Revisando el histórico de pruebas y caídas en este nodo, vemos que es bastante dispar, generando diferentes cargas de IO (¡puede que el grep que empleo no sea del todo exhaustivo!):

[root@nodo1 acfs]# grep Asm_logBits acfs.log.0 | grep multipathd
V 4294772.311 multipathd[689] Asm_logBits: EXPORTORA.volexpdp-226: Asm_buildRecovMap: recovProg -1, dirty bits = 134144/7167232 1%
V 4294777.747 multipathd[691] Asm_logBits: EXPORTORA.volexpdp-226: Asm_buildRecovMap: recovProg -1, dirty bits = 0/7167232 0%


[root@nodo2 acfs]# grep Asm_logBits acfs.log.0 | grep multipathd
V 4302370.602 multipathd[694] Asm_logBits: EXPORTORA.volexpdp-226: Asm_buildRecovMap: recovProg -1, dirty bits = 0/7167232 0%
V 4294799.421 multipathd[703] Asm_logBits: EXPORT.volexpdp-440: Asm_buildRecovMap: recovProg -1, dirty bits = 5164001/7167232 72%
V 4294808.419 multipathd[720] Asm_logBits: EXPORT.volexpdp-440: Asm_buildRecovMap: recovProg -1, dirty bits = 2596096/7167232 36%

Por lo tanto, una caída de un volumen ACFS no siempre generará la misma actividad de IO durante su proceso de resilvering, dependiendo de la cantidad de regiones dirty que encuentr el proceso de DRL.

V 4294808.039 multipathd[720] AsmVolStateOpen: EXPORT.volexpdp-440: checking for recovery, DRL segment: 0, DRL size: 17M
V 4294808.050 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 1 is clean
<strong>V 4294808.057 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 2 is dirty</strong>
V 4294808.109 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 3 is clean
V 4294808.115 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 4 is clean
V 4294808.121 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 5 is clean
V 4294808.130 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 6 is clean
V 4294808.138 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 7 is clean
V 4294808.143 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 8 is clean
V 4294808.150 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 9 is clean
V 4294808.154 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 10 is clean
V 4294808.162 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 11 is clean
V 4294808.167 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 12 is clean
V 4294808.170 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 13 is clean
V 4294808.170 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 14 is clean
V 4294808.184 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 15 is clean
V 4294808.192 multipathd[720] Asm_buildRecovMap: EXPORT.volexpdp-440: DRL segment 16 is clean

Maridaje

Hablando de mirrors, lo primero que viene a la cabeza es a ese Tommy que crece traumatizado mirando siempre a un espejo, y a esa madre gritando «Go to the mirror!«. Look at him in the mirror dreaming, what is happening in his head?

Image result for the who tommy

%d bloggers like this: