Differences

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

--- gpfs [2025/07/10 16:28] – joaquintorres
+++ gpfs [2025/09/23 16:39] (current) – joaquintorres
@@ Line 1: / Line 1: @@
 ====== GPFS ======
+===== Documentación (GPFS v5.18) =====
+{{ :wiki:scale_adm.pdf |}}
+{{ :wiki:scale_ins.pdf |}}
+{{ :wiki:scale_pdg.pdf |}}
 ===== Estructura del cluster GPFS =====
@@ Line 7: / Line 13: @@
   * Quorum nodes: sdmgt01-ib0 y sdmgt02-ib0. Nodos seleccionables para Cluster Manager.
   * File system manager. Hace las reparaciones, agregado de discos, redimensionamiento de espacio, maneja las quotas (reserva bloques en el fs para quienes están escribiendo, etc.). Hay un quota manager para administrar esto.
+  * Metanode: uno por archivo/directorio abierto, mantiene la integridad de la metadata. La metadata se almacena en el inodo correspondiente.
+  * AFM gateway node: Cada "cache fileset" se vale de un servidor que se designa como gateway. Cada nodoe en el cache cluster puede funcionar como gateway.
 La info del cluster manager se obtiene de correr:
 <code>
-mmlsmgr -c
+$ mmlsmgr
+file system      manager node
+---------------- ------------------
+data_fs          172.27.253.32 (sdmgt02-ib0)
+home_fs          172.27.253.32 (sdmgt02-ib0)
 Cluster manager node: 172.27.253.31 (sdmgt01-ib0)
 </code>
+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 27: / Line 43: @@
 data_fs    USR         3663216          0          0          0     none |    36899       0        0        0     none
 home_fs    USR        20519320          0          0          0     none |   151819       0        0        0     none
+mmlsfs all -Q
+File system attributes for /dev/data_fs:
+========================================
+flag                value                    description
+------------------- ------------------------ -----------------------------------
+ -Q                 user;group;fileset       Quotas accounting enabled
+                    user;group;fileset       Quotas enforced
+                    none                     Default quotas enabled
+File system attributes for /dev/home_fs:
+========================================
+flag                value                    description
+------------------- ------------------------ -----------------------------------
+ -Q                 user;group;fileset       Quotas accounting enabled
+                    user;group;fileset       Quotas enforced
+                    none                     Default quotas enabled
+</code>
+Asumiendo que la integración con df es correcta, la cantidad de inodos para /data son 128 millones y para /home 47 millones:
+<code>
+data_fs                 128M   89K  128M    1% /data
+home_fs                  47M  1.7M   45M    4% /home
 </code>
@@ Line 34: / 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 149: / 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>