Differences

This shows you the differences between two versions of the page.

--- gpfs [2025/07/10 20:56] – joaquintorres
+++ gpfs [2025/09/23 16:39] (current) – joaquintorres
@@ Line 28: / Line 28: @@
 La data se almacena directamente en el inodo si no hay niveles de indirección, y se almacena en bloques indirectos como en UNIX en el caso contrario. El primer inodo contiene la //inode file// (lista de todos los registros de tamaño fijo representando los archivos y directorios), y hay otro pequeño grupo de inodos que contienen el resto de la información del file system. Esos inodos son el directorio root del fs, el //block allocation map// (representa la disponibilidad de bloques de espacio en disco; el tamaño de bloque, subbloque y subbloques/bloque se configuran en la creación del fs y no se pueden cambiar) y el //inode allocation map// (que mapea la disponibilidad de inodos). La información de las quotas se almacena en //quota files//, y se backupea con mmbackupconfig y mmrestoreconfig. Contiene los block limits, file limits, uso actual y período de gracia para users, grupos y filesets.
 ===== Directorios compartidos =====
@@ Line 73: / Line 74: @@
 /data/contrib: directorio abierto a todos, de escritura por todos pero permisos de borrado solo para el owner/sudo (sticky bit, chmod 1777)
+===== Monitoreo de salud =====
+Se puede ver un snapshot de la salud del cluster GPFS con
+<code>
+$ sudo /usr/lpp/mmfs/bin/mmhealth cluster show
+Component            Total         Failed       Degraded        Healthy          Other
+--------------------------------------------------------------------------------------
+NODE                    87              1              1             82              3
+GPFS                    87              0              1             83              3
+NETWORK                 87              0              0             87              0
+FILESYSTEM               2              0              0              2              0
+DISK                     4              0              0              4              0
+FILESYSMGR               1              0              0              1              0
+NATIVE_RAID              2              0              2              0              0
+</code>
+En cada nodo se puede correr un comando más específico:
+<code>
+# /usr/lpp/mmfs/bin/mmhealth node show -N cn013-ib0
+Node name:      cn013-ib0
+Node status:    HEALTHY
+Status Change:  114 days ago
+Component      Status        Status Change     Reasons & Notices
+-------------------------------------------------------------------------------
+GPFS           HEALTHY       114 days ago      -
+NETWORK        HEALTHY       114 days ago      -
+FILESYSTEM     HEALTHY       114 days ago      -
+</code>
+Para todos los nodos sería mmhealth node show -N all
+Y se puede obtener un histórico con
+<code>
+# /usr/lpp/mmfs/bin/mmhealth node eventlog
+Node name:	mmgt01-ib0
+Timestamp                         Event Name                             Severity             Details
+-10-21 14:13:14.706824 -03    cluster_connections_bad                WARNING Connection to cluster node 172.27.0.7 has 1 bad connection(s). (Maximum 2).
+-10-21 14:13:21.499309 -03    cluster_connections_ok                 INFO    All connections are good for target ip 172.27.0.7.
+-10-21 14:13:21.509307 -03    local_fs_normal                        INFO    The local file system with the mount point / used for /tmp/mmfs reached a normal level with more than 1000 MB free space.
+</code>
+Los eventos que aparecen **pueden hacer de trigger para algún script en caso de falla**. Eso estaría bueno implementarlo.
+==== Logs ====
+Los logs se encuentran disponibles en los nodos, en /var/adm/ras/mmfs.log.latest, /var/adm/ras/mmfs.log.<fecha> y /var/adm/ras/mmsysmonitor.<nodo>.log-<fecha>.gz (legible con less).
 ===== Rebuild de los módulos del kernel =====
@@ Line 188: / Line 240: @@
 mmcesminfuncs                         mmchpool                  mmimgbackup         mmremotecluster   sysmon.snap.py                  tskafkaauth
 </code>
+===== Restart =====
+Si el nodo se encuentra colgado por problema con los fs, y si estamos seguros de que está colgado por este motivo, se puede ejecutar:
+<code>
+mmshutdown; mmstartup
+</code>
+Que intenta desarmar el stack de gpfs (fs, driver, modulos) y volver a cargarlos, vuelve tambien a montar los fs, pero interrumpe todo proceso que de estos dependa.
+Si se desea hacer un restart de cero de todo el cluster, se ejecuta:
+<code>
+mmstartup -a # levanta
+mmgetstate -a #verifica
+mmlsfs all #lista fs
+mmlsmount all -L #verifica lo montado
+</code>