Architecture du calculateur

[homer@vision ~]# cpumap
mer. oct. 21 15:00:39 CEST 2020
vision

This is an SGI UV
model name           : Intel(R) Xeon(R) Gold 6252 CPU @ 2.10GHz
Architecture         : x86_64
cpu MHz              : 2391.339
cache size           : 36608 KB (Last Level)

Total Number of Sockets                 : 8
Total Number of Cores                   : 192    (24 per socket)
Hyperthreading                          : OFF

UV Information
 HUB Version:                  UVHub  5.1
 Number of Hubs:              8
 Number of connected Hubs:          8
 Number of connected NUMAlink ports:      64
=============================================================================

VISION n'est pas une machine de type SMP (Symmetric multiprocessing) où l'accès des coeurs de calcul à la mémoire commune serait uniforme pour tous les coeurs.

Le calculateur est physiquement constitué de multiples lames de calcul, chaque lame ayant sa propre quantité de mémoire (192 Go). C'est grâce à la technologie d'interconnection des lames (NUMAlink) et aux outils SGI que cet ensemble de mémoires physiquement distribuées devient accessible et partagé entre tous les coeurs de calculs et au sein d'un seul système d'opération (un seul système Linux suffit à gérer l’ensemble des ressources processeurs et mémoire).

VISION ressemble donc du point de vue matériel à un cluster de calcul (= machine à mémoire distribuée), mais il a les fonctionnalités d'une machine à mémoire partagée (un seul système, adressage à tout l'espace mémoire).

Ainsi, pour un processeur donné, les temps d'accès à une zone mémoire diffèrent suivant la zone mémoire accédée, d'où le nom de machine NUMA (pour Non Uniform Memory Access ou Non Uniform Memory Architecture).

Bien qu'on bénéficie d'un réseau NUMAlink performant et de lames ultra-denses à hautes performances, l'utilisateur ne doit pas oublier/ignorer qu'il travaille sur une architecture NUMA et pour qu'il obtienne de bonnes performances et une reproductibilité des temps CPU, il doit utiliser certaines commandes spécifiques (outils HPE : perfboost, librairie MPT, dplace, omplace).

Cpuset

Le sous-système cpuset assigne les CPU individuels et les noeuds de mémoire à des groupes de contrôle. Chaque cpuset peut être spécifié en fonction des paramètres suivants, chacun dans un pseudo-fichier différent du système de fichiers virtuel du groupe de contrôle.

Sur VISION, le mécanisme de cpuset permet de limiter l’exécution des processus d'un job aux seuls cœurs demandés/alloués afin d'isoler les processus appartenants à différents utilisateurs d'une part, et de séparer la machine entre une partie connection (les noeuds 0 et 1) d'autre part. La soumission des jobs se fait en utilisant cette fonctionnalité pour limiter les ressources demandés via PBS. Chaque calcul disposera uniquement des ressources spécifiées au moment de la soumission dans PBS par les cpuset.

GPU

Sur chaque socket de la machine, est attaché une carte graphique Tesla Volta de dernière génération :

[homer@vision codes]$ nvidia-smi -L
GPU 0: Tesla V100-PCIE-32GB (UUID: GPU-a0abb4e1-c0f6-5af8-ca79-ac3367145946)
GPU 1: Tesla V100-PCIE-32GB (UUID: GPU-386c0e92-c257-bf48-dac3-78353aa0dddf)
GPU 2: Tesla V100-PCIE-32GB (UUID: GPU-3d51d2ac-79f0-1b79-bdf7-4d3a551d480e)
GPU 3: Tesla V100-PCIE-32GB (UUID: GPU-3b7d5525-0bba-f365-77d9-a4d2ba00c8be)
GPU 4: Tesla V100-PCIE-32GB (UUID: GPU-7ea51ae9-9331-4225-fcee-2cec1a325660)
GPU 5: Tesla V100-PCIE-32GB (UUID: GPU-27c6b793-c9fc-3895-1581-887521f9d9f6)
GPU 6: Tesla V100-PCIE-32GB (UUID: GPU-3a989092-3a27-ea1b-5851-a0f2af1d1665)
GPU 7: Tesla V100-PCIE-32GB (UUID: GPU-e703dbd5-246c-f7e0-35ea-193116c60fd9)

Ces cartes servent pour le pré/post-traitement des données et le calcul GPU en fonction des besoins et de l'utilisation des files de calcul "visuq, gpuq". Actuellement, 4 cartes sont réservées pour le traitement graphique et 4 cartes sont réservées pour le calcul.

Partition

Les lames de calcul que compose VISION sont rattachés au gestionnaire de calcul PBS par le concept de vnodes (virtual nodes) ; les vnodes permettent de gérer les ressources associées aux lames de calcul (mémoire, GPU, ...) et déterminent l'usage des lames ; chaque lame peut ainsi avoir un usage différent déterminés par le type de partition défini dans PBS.

La commande pbsn permet de visualiser les ressources et le type de partition attribué :

[root@vision ~]# pbsn

 VNODES          STATE        MEM       CPUS   Gpu-Visu        PARTITION              JOB
                    ============================================================

 vision           free         0b          0          0
 vision[0]    job-busy   189320mb         24          4             visu  20905.vision/0,
 vision[1]    job-busy   190386mb         24          4             visu  20905.vision/0,
 vision[2]        free   190386mb         24          4       visu,inter
 vision[3]    job-busy   190386mb         24          4       visu,inter  20966.vision/0,
 vision[4]        free   190386mb         24          0        gpu,inter   20966.vision/0
 vision[5]        free   190386mb         24          0        gpu,inter   20966.vision/0
 vision[6]    job-busy   190386mb         24          0 gpu,inter,compute  20906.vision/0,
 vision[7]    job-busy   190386mb         24          0 gpu,inter,compute  20906.vision/0,
 vision[8]    job-busy   190386mb         24          0    compute,inter  20933.vision/0,
 vision[9]    job-busy   190386mb         24          0    compute,inter  20933.vision/0,
 vision[10]   job-busy   190386mb         24          0    compute,inter  20933.vision/0,
 vision[11]   job-busy   190386mb         24          0    compute,inter  20933.vision/0,
 vision[12]   job-busy   190386mb         24          0          compute  20933.vision/0,
 vision[13]       free   190386mb         24          0          compute  20933.vision/0,
 vision[14]   job-busy   190386mb         24          0          compute  20967.vision/0,
 vision[15]       free   190386mb         24          0          compute

File system

Le système de fichier disponible sur VISION est ZFS. Ce type de système de fichiers dispose de fonctionnalités :

  • Structure en arbre de hash :
  • Chaque objet (fichier, répertoire, lien …) est découpé en blocs ;
  • A chaque bloc est associé un bloc de hash pour vérifier l’intégrité des blocs
  • Copy-on-Write : modification uniquement blocs nécessaires
  • Pool
  • « Block devices » aggrégés au sein d’un pool ZFS
  • Datasets
  • Un pool peut être découpé en datasets
  • Tous les datasets d’un pool ont accès à tous l’espace du pool
  • Quotas pour limiter l’espace occupé par un dataset
  • Des snapshots indépendants
[homer@vision ~]# zfs list
NAME               USED  AVAIL     REFER  MOUNTPOINT
zfs-pool           178G  56.0T      116K  /zfs
zfs-pool/home     47.3G  7.95T     47.3G  /zfs/home
zfs-pool/scratch  26.4G  56.0T     26.4G  /zfs/scratch
zfs-pool/softs     104G  95.9G      104G  /zfs/softs

[homer@vision ~]# zfs list -o name,quota,used,avail
NAME              QUOTA   USED  AVAIL
zfs-pool           none   714G  55.5T
zfs-pool/home        8T  60.0G  7.94T
zfs-pool/scratch   none   539G  55.5T
zfs-pool/softs     200G   114G  85.8G

[homer@vision ~]$ zfs list -t snapshot
NAME                        USED  AVAIL     REFER  MOUNTPOINT
zfs-pool/home@2020-10-20   49.8M      -     59.9G  -
zfs-pool/home@2020-10-21    288M      -     60.4G  -
zfs-pool/home@2020-10-22    724K      -     65.9G  -
zfs-pool/softs@2020-10-06  95.7M      -     95.9G  -
zfs-pool/softs@2020-10-10  16.5M      -      104G  -
zfs-pool/softs@2020-10-17  9.33M      -      114G  -

Un espace de 8To est disponible sur /home, et 55To sur /scratch.
Des snapshots sont mis en place sur /home quotidiennement sur 3 jours.