Hai uns días, nun cliente produciuse un reinicio abrupto dun clúster GI 12.1.0.2 por problemas hardware relacionados co acceso á SAN a través dunha rede 10GbE. O problema repetiuse no outro nodo de madrugada ó comezar o volcado programado Data Pump das bases de datos. Sen coñecer o detalle do problema, estaba relacionado coa saturación dun porto nun chasis de blades que, a través de algún mecanismo forzaba o peche do porto e o consecuente corte de conectividade e reinicio do servidor. Debido á coincidencia do inicio dos exports, os administradores de sistemas analizaron o acceso a cabina, vendo que a saturación era debida, no segundo dos reinicios, a actividade sobre o filesystem ACFS que xa en ocasións anteriores tiveramos observado. Esta actividade era xerada polo proceso automático de resilvering de ACFS.

Que é resilvering?

Trátase dun concepto asociado á reconstrución dun mirror de disco. A palabra é moi propia xa que resilver deriva da acción de volver a tratar con prata as zonas deterioradas dun espello (ou mirror) real de cristal. Esta capa de prata (ou outro material como o aluminio) é a que converte o cristal nun espello, e a que, á medida que se deteriora, fai que aparezan “erros” e transparencias no mesmo.

Cando se produce un problema nun raid, como a perda dun dos discos que o compoñen, o proceso de resilvering é o que, unha vez incorporado o novo disco, restablece a sincronización de datos coa nova configuración. É mais habitual atopar este concepto como rebuild ou resync, pero resilver é empregado tamén por ZFS, concepto similar ó de ACFS dende o punto de vista de que se trata dunha combinación de filesystem e volume manager. ZFS foi desenvolto por Sun Microsystems antes da súa adquisición por Oracle. Entre as 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.

Algunhas son características que atopamos tamén en ACFS.

Por que se fai resilvering?

Neste caso, o proceso de resilvering estase a producir sobre un filesystem de case 2TiBs de tamaño. O diskgroup sobre o que se creou o volume ADVM e o filesystem ACFS está creado sobre LUNs que na cabina teñen unha política bastante restritiva a nivel de QoS, o que estaba a provocar que este proceso precisase mais de 10h para completarse.

En ASM / ACFS / ADVM, non é moita a información que puiden atopar sobre este procedemento. A maior parte da información en MOS está relacionada con bugs, como por exemplo o comentado na nota 2071755.1 na que se describe un problema de alto consumo de CPU pola actividade do proceso asmResilver1. Existe mais información sobre o proceso de resilver relacionado cos sistemas Exadata ou ODA, aínda que non acaba de ser un proceso moi específico en canto á súa implementación xeral a nivel de ACFS. Neste punto, recomendo a lectura de esta entrada e esta outra do blog de Erman Arslan.

Moi ilustrativa a definición dos roles dos procesos asmresilver1 e asmresilver2 que actúan baixo condicionantes diferentes. Segundo esta información, asmResilver1 entra en xogo ante escenarios de crash como a caída e recuperación dunha instancia ASM, e verifica se é precisa a recuperación dalgún bloque no mirror, encargándose de facelo en caso de ser asi. asmResilver2 entra en xogo cando se produce unha reconfiguración de clúster, por exemplo tras o reinicio dun servidor do RAC. Este proceso verifica se o volume precisa algunha operación de recuperación.

O proceso de resilvering é propio de ADVM e é diferente do proceso de rebalanceo propio de ASM que podemos ver en calquera diskgroup, incluídos aqueles que conteñen volumes ADVM. En sistemas Linux, podemos ver reflectida a súa actividade no ficheiro var/log/messages, onde o driver ADVM envorca a súa saída:

ADVM indicará cando se produce unha reconfiguración de clúster que forza o resilver do volume. Do escenario tratado, no messages aparecen as seguintes entradas, o inicio da reconfiguración, e o evento de fin de reconfiguración que recibe de cada un dos nodos.

Procesos involucrados no resilvering

No noso exemplo, vemos que tras a caída forzada dun nodo, atopamos tamén dous procesos, aínda que denominados asmResilver e asmResilver2 que son executado como usuario root. O primeiro é nesta ocasión o responsable da validación dos datos, e o segundo dos metadatos DRL para a xestión da redundancia. Os procesos execútanse no nodo responsable do resilver en curso, non existindo ningún proceso deste tipo no outro nodo nin sequera cando se recupera e reincorpora ó clúster. A nivel de ASM, non cheguei a atopar ningunha operación dentro de gv$asm_operation, pese a que contempla a opción de amosar tarefa de resilvering, pero é unha casuística específica de Exadata cando se habilita WriteBack FlashCache:

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

Tampouco identifiquei en ningún dos casos ningún ficheiro de traza específico asociado ó proceso de resilvering. Si parece ter relación o número de procesos ADVM en execución, moi superior no nodo que está facendo o resilvering:

Como veremos mais adiante, estes procesos ADVM son aparentemente procesos denominados UsmMonitor.

Onde atopar información sobre o proceso de resilvering

Neste punto, se acudimos á nota MOS , podemos ver o xeito de amosar o log correspondente a AVM, ben a través da liña de comandos, ben a través do ficheiro /proc/oks/log. Este ficheiro é a traza en memoria do driver OKS (Oracle Kernel Service), un dos 3 drivers kernel que compoñen ACFS, xunto con ACFS e ADVM, e que Oracle agrupa no que se denomina USM kernel drivers. Podemos ver os tres drivers no directorio usm dentro dos módulos do kernel.

Dende a versión 11.2.0.3, este log está tamén dispoñible en disco, podendo acceder a el a través de $GRID_BASE/crsdata/<hostname>/acfs en 12c ou $GRID_HOME/log/<hostname>/acfs/kernel en 11gR2. Aquí si podemos atopar información do proceso de Resilver:

Adicionalmente á información de inicio e fin que podemos obter en /var/log/messages, aquí podemos ver o resumo de información en canto a tempo e número de IOs xeradas no proceso. Revisando este interesante log, podemos obter mais información sobre que está acontecendo e por que este proceso está en marcha.

Por outro lado, a versión 12.1.0.2 da Grid Infrastructure introduce a funcionalidade de binary logging para os drivers USM. Na mesma ruta onde se xeran os logs oks, temos logs binarios non editables en texto que poden ser útiles na apertura de casos con soporte. Tamén aparece un ficheiro de eventos específico, onde tamén se rexistran, ademais de moitos outros, os eventos de resilvering que vemos no messages. De feito, é un ficheiro onde consultar de xeito doado o histórico (cando menos recente) de eventos de resilvering que estamos buscando.

DRL

O proceso de resilvering é un proceso de reconstrución de mirror baseada en DRL (Dirty Region Logging), de emprego común en outros sistemas (por exemplo Veritas Volume Manager) e que aplica un principio similar ó journaling habitual en sistemas de ficheiros como por exemplo ext4. No propio log de ADVM vemos que se referencia este concepto tanto na nomenclatura como na funcionalidade. Así, cando arrinca o volume, vemos que se fai unha verificación dos dirty bits, e ademais identificamos que os 1,8TiBs de datos están representados nun bitmap de 17MiBs e un total de 7.167.232 bits.

Regions

No enlace de Veritas vemos unha funcionalidade na que se emprega un mapa de bits para reprensentar o almacenamento do volume e identificar as rexións que están marcadas a nivel de mirror como “dirty”. Un bit do mapa representa unha rexión, no caso de Veritas, 1024 sectores. No caso de ADVM atopamos no mesmo log que o tamaño de cada rexión é de 512 bloques.

Monitorizar un proceso de resilvering

Con unha operación de cat ou tail sobre /proc/oks/log ou sobre o acfs.log.0 a partires de 12.1.0.2, podemos identificar a porcentaxe de rexións dirty pendentes de procesar por parte do proceso asmResilver1. Filtrando pola cadea Asm_logBits e polo volume que nos interesa, podemos ver a súa evolución:

Unha vez completado este proceso, é lanzado asmResilver2, empregando un proceso por cada volume ACFS montado. Este proceso, moito mais rápido que o resilver de datos, fai unha verificación e corrección de problemas nos metadatos DRL para o mantemento do mirror. Podemos ver a súa actividade no mesmo log:

Afecta unha operación de resilver a todo o volume ACFS?

Para mín, unha das principais dúbidas sobre este proceso era saber se cada vez que se produción unha caída abrupta se facía unha reconstrucción completa do mirror, algo que non parecía ter sentido. Tras a revisións destes logs, queda claro que non, que depende da cantidade de rexións marcadas como dirty cando comeza o proceso. Revisando o histórico de probas e caídas neste nodo, vemos que é bastante dispar, xerando diferentes cargas de IO (pode que o grep empregado non sexa exhaustivo!):

Polo tanto, unha caída dun volume ACFS non sempre xerará a mesma actividade de IO durante o seu proceso de resilvering, dependendo da cantidade de rexións dirty que atope o proceso de DRL.

Maridaxe

Se falamos de mirrors, o primeiro que ven á cabeza é a ese Tommy que medra traumatizado mirando sempre a un espello, e a súa nai berrando ese “Go to the mirror!“. Look at him in the mirror dreaming, what is happening in his head?

Image result for the who tommy

 

A %d blogueros les gusta esto: