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