Rendimiento y monitorización · Monitorización de aplicaciones Estado de las ejecuciones...
21
-Operations Department -Barcelona Supercomputing Center RED ESPAÑOLA DE SUPERCOMPUTACIÓN Rendimiento y monitorizaci Rendimiento y monitorizaci ó ó n n
Transcript of Rendimiento y monitorización · Monitorización de aplicaciones Estado de las ejecuciones...
-Operations Department-Barcelona Supercomputing CenterRED ESPAÑOLA DE
SUPERCOMPUTACIÓN
Rendimiento y monitorizaciRendimiento y monitorizacióónn
2
Foreword
All Information contained in this document refers to BSC´s & RES´s internal proceedings/scripts/developments. This information is
confidential and should not be published nor distributed.
3
Index
● Introduction● RES node architecture ● RES node policies ● Monitorización
4
Introduction
● Resource Manager● Handles any allocatable resource (check, start application,
stop application, ...)● Scheduler
● Decides which job to run at every moment in base of priorities and policies defined
● IBM´s LoadLeveler was our de-facto (Resource Manager + Scheduler solution)
● Since June 2007 MareNostrum production tools are:●Slurm as Resource Manager (OpenSource)●Moab as Scheduler (from ClusterResources)
5
Index
● Introduction● RES Node Architecture● RES Node Policies ● Monitorización
6
RES Node Architecture
Servers
Bla
de C
ente
rs
Head node
Login nodes
GPFS
Cluster Management
Users` job control commands
SYSTEM ARCHITECTURE
7
RES Node Architecture
Servers
Bla
de C
ente
rs
Head node
Login nodes
GPFS
Cluster Management
User’s job control commands
slurmd
slurmd slurmd
slurmdslurmd
slurmd slurmd
slurmd
slurmd slurmd slurmd
Moab
SlurmCtld
COMPONENTS DEPLOYED
8
Index
● Introduction● RES Node Architecture ● RES Node Policies● Monitorización
9
RES Node Policies
● MareNostrum´s CPU time is divided and prioritized ensuring access for:● Access Committee assigned projects (70%)● Site own projects (20%)● Other (10%)
● Scheduling policies should guarantee this consumption at the end of every period and year
INTRODUCTION
10
RES Node PoliciesACCESS COMMITTEE
● For every project, Scientific Committee provides:● # Number of hours –in thousands-● Class of hours:
● A - maximum priority, should be executed before the rest
● B - if there are no A jobs, or filling the gaps
● To accomplish this BSC:● Defines internal ‘Class C’
● for those users that wasted all their A and/or B time● only run if there are no suitable A or B jobs on queue
● Establishes manual Priority Management Rules: ● «One ‘A+B’ project that wastes A, is moved to B»● «One only ‘A’ or ‘B’ project that wastes all its time, is moved to C»
11
RES Node PoliciesJOB PRIORITY MODEL
● To evaluate priority weights from components:CREDENTIAL + FAIR-SHARING + SERVICE
12
RES Node PoliciesCREDENTIALS - JOB PRIORITY MODEL
● To evaluate priority weights from components:CREDENTIAL + FAIR-SHARING + SERVICE
This sets priority depending on the:* Group* User* Quality of Service
CREDWEIGHT 1QOSWEIGHT 1000
GROUPWEIGHT 10USERWEIGHT 1
13
RES Node PoliciesFAIR-SHARE - JOB PRIORITY MODEL
● To evaluate priority weights from components:CREDENTIAL + FAIR-SHARING + SERVICE
FSINTERVAL 07:00:00:00FSDEPTH 16FSDECAY 0.95FSPOLICY DEDICATEDPESFSTREEISPROPORTIONAL TRUE
FSWEIGHT 100FSUSERWEIGHT 1FSGROUPWEIGHT 10
14
RES Node Policies
FAIR-SHARE TREE - COMMITTEE BRANCH
Root
otherbscprojects
class_cclass_bclass_a
70 20 10
1000 100 2
Initial Group Share == # thousand hours from Access Committee
15
RES Node PoliciesSERVICE - JOB PRIORITY MODEL
● To evaluate priority weights from components:CREDENTIAL + FAIR-SHARING + SERVICE
This sets priority depending on the time the job has spent in the queue
SERVICEWEIGHT 1QUEUETIMEWEIGHT 100
16
Index
● Introduction● RES Node Architecture ● RES Node Policies ● Monitorización
17Centro Nacional de Supercomputación
Necesidades básicas - Monitorización
● Monitorización de sistema● Diagnósticos (detección de anomalías)
● Monitorización de aplicaciones● Estado de las ejecuciones (rendimiento)● Contabilidad
● Fuentes● Software específico (Ganglia)● Sistema de colas● Software propio
● Frecuencia● Elevada, pero sin excesos● Minimización de interferencias con la ejecución● Inicio y final de las ejecuciones
18Centro Nacional de Supercomputación
Herramientas – Monitorización de sistema
● Ganglia● Monitorización de sistema
● Carga cpu● Uso de memoria/swap● Uso de red● …
● Posibilidad de envío de información adicional● Desde scripts
● Componentes● Gmond – daemon local● Gmetad – recolector remoto● Interfaz web
19Centro Nacional de Supercomputación
Herramientas – Monitorización de sistema
● Ganglia● Puntos fuertes
● Daemon local ligero● Fácilmente modificable (open source)
● Puntos débiles● Broadcast de información● Recolector no fácilmente escalable
● Modificaciones BSC-CNS● Modificación Gmond (métricas adicionales)● Generación automàtica de configuración● Limitación de broadcast a blade center● Desarrollo de un recolector escalable● Desarrollo de herramientas de consulta
20Centro Nacional de Supercomputación
Herramientas – entorno de ejecución
● Desarrollos en el BSC-CNS● Prólogo
● Verificación del estado del nodo● Drivers, red, sistemas de ficheros, hardware, …
● Cancelación automática del trabajo en caso de fallo● Extracción del nodo del sistema de colas en caso de fallo● Propagación de información al script inicial del usuario a través
de variables de entorno● Nodo master, lista de nodos
● Generación de información de contabilidad● Epílogo
● Localización y eliminación de procesos de usuario● Verificación del estado del nodo y reconfiguración en caso
necesario
21
Thank you !www.bsc.es
