Toward exascale tool infrastructure (or what weve been up - - PowerPoint PPT Presentation

toward exascale tool infrastructure or what we ve been up
SMART_READER_LITE
LIVE PREVIEW

Toward exascale tool infrastructure (or what weve been up - - PowerPoint PPT Presentation

Department of Computer Science Toward exascale tool infrastructure (or what weve been up to this past year) Dorian Arnold / University of New Mexico


slide-1
SLIDE 1

Department of Computer Science

Toward ¡exascale ¡tool ¡infrastructure ¡ (or ¡what ¡we’ve ¡been ¡up ¡to ¡this ¡past ¡year) ¡

Dorian ¡Arnold ¡/ ¡University ¡of ¡New ¡Mexico ¡ ¡ ¡ With ¡Taylor ¡Groves ¡and ¡Whit ¡Schonbein/ ¡University ¡of ¡New ¡Mexico ¡ ¡ ¡ ¡

slide-2
SLIDE 2

Where ¡we ¡were ¡last ¡year ¡

} LIBI ¡for ¡normal ¡MRNet ¡startup ¡

  • OpCmal ¡bulk ¡process ¡launch ¡
  • Efficient ¡propagaCon ¡of ¡iniCalizaCon ¡

informaCon ¡

} What ¡we ¡desired ¡

  • Handling ¡MRNet’s ¡“disconected ¡

startup” ¡modes ¡

  • Reducing ¡topology ¡specificaCon ¡

burden ¡

Large ¡Scale ¡Distributed ¡SoOware ¡ Job ¡Launchers ¡ CommunicaCon ¡ Services ¡ LIBI ¡

rsh/ssh SLURM OpenRTE ALPS

LaunchMON ¡

Debuggers System Monitors Applications Performance Analyzers Overlay Networks COBO MPI

slide-3
SLIDE 3

Scalable Systems Lab

Updates ¡of ¡our ¡tool ¡startup ¡work: ¡ ¡

1.

Status ¡of ¡the ¡MRNet/LIBI ¡integraCon ¡

2.

Improving ¡startup ¡using ¡scalable ¡informaCon ¡services ¡

3.

An ¡API ¡for ¡reduced ¡tool ¡topology ¡specificaCon ¡

Today’s ¡adventures ¡

slide-4
SLIDE 4

Scalable Systems Lab

} New ¡LIBINetwork ¡class ¡

  • Previous ¡network ¡classes: ¡RshNetwork ¡and ¡XTNetwork ¡
  • Network ¡class ¡specifies ¡MRNet’s ¡launching ¡protocol ¡

} Can ¡use ¡SLURM ¡or ¡rsh ¡for ¡process ¡launch ¡

  • ./configure --with-startup [libi-slurm|libi-ssh]
  • Can ¡sCll ¡use ¡old ¡non-­‑LIBI ¡startup ¡modes ¡(but ¡why? ¡J ¡) ¡

} Tested ¡against ¡MRNet ¡4.0 ¡(no ¡regressions) ¡ } Merged ¡into ¡MRNet ¡master ¡branch ¡as ¡of ¡April ¡2014 ¡

MRNet/LIBI ¡IntegraCon ¡Status ¡

slide-5
SLIDE 5

Scalable Systems Lab

} Parent ¡creates ¡children ¡

  • E.g. ¡MRNet ¡default ¡
  • Local: ¡fork()/exec() ¡
  • Remote: ¡rsh/ssh ¡

} ConfiguraCon ¡informaCon ¡

passed ¡via ¡command ¡line ¡

} Requires ¡starCng ¡all ¡

processes ¡

MoCvaCng ¡scalable ¡info. ¡diss.: ¡ Tree-­‑based ¡startup ¡

slide-6
SLIDE 6

Scalable Systems Lab

} Root ¡creates ¡all ¡processes ¡

  • E.g. ¡MRNet-­‑LIBI ¡

} ConfiguraCon ¡informaCon ¡

passed ¡via ¡custom ¡ mechanism ¡

  • PMGR ¡collecCves ¡

} Root ¡gathers ¡then ¡scabers ¡ } Requires ¡starCng ¡all ¡

processes ¡

MoCvaCng ¡scalable ¡info. ¡diss.: ¡ Tree-­‑based ¡startup ¡

slide-7
SLIDE 7

Scalable Systems Lab

} Tool ¡infrastructure ¡does ¡not ¡start ¡all ¡processes ¡

  • E.g. ¡MRNet’s ¡“no ¡back-­‑end ¡instanCaCon” ¡& ¡“lightweight ¡back-­‑

end” ¡modes ¡

} How ¡do ¡back-­‑ends ¡learn ¡and ¡connect ¡to ¡parents? ¡

  • Current ¡soluCon: ¡use ¡the ¡filesystem ¡L ¡

} Why ¡not ¡leverage ¡scalable ¡informaCon ¡services ¡(IS)? ¡

What ¡about ¡disconnected ¡startup? ¡

slide-8
SLIDE 8

Scalable Systems Lab

} General ¡MRNet ¡extension ¡for ¡start-­‑up ¡data ¡distribuCon

¡

} IniCal ¡implementaCon ¡uses ¡MongoDB ¡

  • A ¡false ¡start ¡tried ¡ZFS ¡

} Prototype ¡available ¡in ¡KVS ¡branch ¡of ¡MRNet ¡repository ¡

Key-­‑value ¡stores ¡to ¡the ¡rescue ¡

slide-9
SLIDE 9

MRNet ¡KVS ¡Extension ¡

} Root ¡creates ¡internal ¡nodes ¡ } Gathers ¡configuraCon ¡

informaCon ¡

} Publishes ¡in ¡KVS ¡ } Third ¡party ¡creates ¡leaves ¡ } Leaves ¡retrieve ¡configuraCon ¡

informaCon ¡from ¡KVS ¡

} Leaves ¡connect ¡to ¡internal ¡

nodes ¡

slide-10
SLIDE 10

Scalable Systems Lab

} Generalized ¡mechanism ¡for ¡

  • IniCalizing ¡processes ¡with ¡target ¡IS ¡
  • Parents ¡publishing ¡startup ¡informaCon ¡into ¡IS ¡
  • Orphans ¡retrieving ¡startup ¡informaCon ¡from ¡IS ¡

} Parent ¡and ¡orphan ¡interfaces ¡

New ¡Node ¡Discovery ¡Engine ¡(NDE) ¡

slide-11
SLIDE 11

NDE: ¡Node ¡InformaCon ¡Object ¡

} Hostname ¡ } Port ¡ } Rank ¡ } Parent ¡hostname ¡ } Parent ¡port ¡ } Parent ¡rank ¡ } Session ¡id ¡ ¡ ¡ ¡ ¡//currently ¡unused ¡

slide-12
SLIDE 12

Scalable Systems Lab

Mongo-­‑DB ¡

  • Open-­‑source ¡NoSQL ¡database ¡
  • Wriben ¡in ¡C++ ¡

MongoDB-­‑based ¡Prototype ¡

slide-13
SLIDE 13

NDE: ¡Example ¡Front-­‑end ¡

… //instantiate MRNet internal nodes as per usual … For all leaf internal nodes: nodeinfo.iRank = (int)leaves[curr_leaf]->get_Rank(); nodeinfo.iport = (int)leaves[curr_leaf]->get_Port(); nodeinfo.ihostname = leaves[curr_leaf]->get_HostName(); //MongoParent is derived from NDEParent MongoParent* parent = new MongoParent(info); parent->set_DBHost(db); parent->connect_toDB(); parent->send_MyNodeInfo();

slide-14
SLIDE 14

NDE: ¡Example ¡Back-­‑end ¡

… //MongoOrphan is derived from NDEOrphan MongoOrphan orphan; set_DBHost(&orphan, argv[1]); connect_toDB(&orphan); init_NDEO(&orphan, NULL, NULL); discover_Parent(&orphan); sprintf(parHostname, “%s”, orphan.base.myInfo.phostname); sprintf(parPort, "%d", orphan.base.myInfo.pport); sprintf(parRank, "%d", orphan.base.myInfo.pRank); sprintf(myHostname, “%s”, orphan.base.myInfo.ihostname); sprintf(myRank, "%d", orphan.base.myInfo.iRank); //instantiate MRNet back-end node as per usual …

slide-15
SLIDE 15

Scalable Systems Lab

} Instead ¡of ¡“root ¡gather”, ¡parents ¡publish ¡own ¡data ¡ } Comprehensive ¡funcConality ¡tesCng ¡ } Test ¡performance ¡to ¡determine ¡scalability ¡ } AutomaCc ¡peer/session ¡discovery: ¡invesCgate ¡ways ¡to ¡

avoid ¡a ¡priori ¡known ¡informaCon, ¡e.g. ¡DB ¡session ¡IDs. ¡

  • Persistent ¡KVS ¡services ¡will ¡help ¡

NDE ¡to ¡do ¡list ¡

slide-16
SLIDE 16

A ¡vision ¡for ¡autonomous ¡TBŌN ¡infrastructure ¡

TBŌN ¡Autonomy ¡aka ¡the ¡self-­‑* ¡properCes: ¡

} Self-­‑configuring ¡

  • AutomaCc ¡TBŌN ¡topology ¡configuraCon ¡

} Self-­‑monitoring ¡

  • TBŌN ¡health ¡and ¡performance ¡

} Self-­‑healing ¡

  • TBŌN ¡Fault ¡tolerance ¡and ¡failure ¡recovery ¡

} Self-­‑opCmizing ¡

  • Dynamic ¡TBŌN ¡reconfiguraCon ¡to ¡improve ¡performance ¡

¡

Monitoring( Detec,ng( Deciding( Ac,ng( Sensors( Effectors(

Events( Symptoms( Decisions( Ac,ons(

slide-17
SLIDE 17

1.

Collect ¡metrics ¡relevant ¡to ¡overlay ¡performance ¡

2.

Performance ¡models ¡diagnose ¡performance ¡failures ¡

3.

Performance ¡failure? ¡ HeurisCcs ¡for ¡topology ¡reconfiguraCon ¡

4.

Find ¡reconfiguraCon ¡cost ¡(overhead)/benefit ¡(speedup) ¡

5.

Reconfigure ¡overlay ¡when ¡benefits ¡outweigh ¡costs ¡

6.

Go ¡to ¡step ¡1 ¡ ¡

Overall ¡autonomous ¡operaCon ¡

slide-18
SLIDE 18

Autonomous ¡operaCon: ¡ DetecCng ¡performance ¡failures ¡

Generally, ¡a ¡sub-­‑opCmal ¡overlay ¡network ¡topology ¡

  • Resource ¡oversubscripCon: ¡insufficient ¡resources ¡for ¡offered ¡workload ¡
  • Resource ¡undersubscripCon: ¡insufficient ¡work ¡for ¡allocated ¡resources ¡
  • SubopCmal ¡configuraCon: ¡resources ¡not ¡being ¡effecCvely ¡uClized ¡

} Develop ¡performance ¡models ¡

  • Coarse-­‑grained ¡approach ¡

– Consider ¡processors ¡and ¡networks ¡influence ¡on ¡topology ¡performance ¡

  • Must ¡be ¡accurate ¡yet ¡tractable ¡to ¡execute ¡(potenCally ¡mulCple ¡Cmes) ¡

} Build ¡sensors ¡to ¡collect ¡data ¡to ¡parameterize ¡models ¡ } Compare ¡current ¡observed ¡performance ¡to ¡other ¡configuraCons ¡

slide-19
SLIDE 19

Dynamic(Resource(Management( Job(Scheduler(

…( …(

Tool( Sessions( User( Jobs( Layer(2:( Management(Layer( Layer(1:( Service(Layer( Autonomous(Resource(Provisioning( Layer(0:( Tools(and(Apps( Tool( Infrastructure(

A ¡new ¡dynamic ¡ecosystem ¡

slide-20
SLIDE 20

Scalable Systems Lab

} Currently ¡MRNet ¡user ¡specifies ¡complete ¡topology ¡

  • Mapping ¡of ¡all ¡processes ¡to ¡nodes ¡
  • InterconnecCvity ¡amongst ¡all ¡processes ¡

} Ideal: ¡User ¡specifies ¡nothing ¡about ¡the ¡topology ¡

  • At ¡least ¡nothing ¡about ¡the ¡internal ¡tree ¡topology ¡
  • Front-­‑end ¡and ¡back-­‑end ¡may ¡be ¡fixed ¡based ¡on ¡usage ¡

} Intermediate ¡point: ¡user ¡gives ¡generic ¡topology ¡

informaCon; ¡we ¡auto-­‑configure ¡the ¡specifics ¡

Reducing ¡Topology ¡SpecificaCon: ¡ A ¡step ¡to ¡auto-­‑topology ¡management ¡

slide-21
SLIDE 21

Scalable Systems Lab

} Physical ¡(internal) ¡nodes ¡

  • User ¡specifies ¡
  • Eventual ¡goal: ¡MRNet ¡requests ¡from ¡resource ¡manager ¡

} Process ¡placement ¡& ¡inter-­‑process ¡connecCvity ¡

  • StaCc ¡
  • Coarse ¡policy ¡and ¡heurisCc-­‑based ¡mappings ¡
  • Eventual ¡goals: ¡dynamic, ¡performance ¡opCmizaCons ¡based ¡on ¡

workload ¡and ¡physical ¡network ¡

Auto-­‑topology ¡specificaCon ¡

slide-22
SLIDE 22

Scalable Systems Lab

} createTopologySpecification(): ¡

  • Inputs: ¡

– Front-­‑end ¡host ¡ – List ¡of ¡internal ¡node ¡hosts ¡ – List ¡of ¡back-­‑end ¡hosts ¡ – Topology ¡specificaCon ¡policy: ¡

– Dictates ¡the ¡constraints ¡to ¡use ¡for ¡tree ¡topology ¡

  • Outputs: ¡MRNet ¡topology ¡file ¡or ¡topology ¡buffer ¡

} Standard ¡MRNet ¡calls ¡to ¡use ¡created ¡topology ¡

Auto-­‑topology ¡specificaCon ¡methods ¡

slide-23
SLIDE 23

Topology ¡policy ¡class ¡members ¡

} Number ¡of ¡internal ¡processes ¡per ¡node ¡

  • Default: ¡1 ¡

} Collocate ¡internal ¡processes ¡with ¡front-­‑end ¡

  • Default: ¡Off ¡

} Collocate ¡internal ¡processes ¡with ¡back-­‑end ¡

  • Default: ¡Off ¡

} Max ¡fan ¡out ¡

  • Default: ¡128 ¡

} Min ¡fan ¡out ¡

  • Default: ¡16 ¡

} Tree ¡type: ¡balanced, ¡perfect, ¡binomial, ¡graded ¡

  • Default: ¡balanced ¡

} Modes: ¡“maximize ¡fan ¡out”, ¡“maximize ¡depth”, ¡“fit ¡to ¡

internal ¡nodes” ¡

slide-24
SLIDE 24

Scalable Systems Lab

} Performance ¡tesCng ¡of ¡various ¡topology ¡types ¡with ¡

representaCve ¡tool ¡workloads ¡

  • SystemaCcally ¡chosen ¡default ¡policies ¡
  • Inform ¡use-­‑case ¡dependent ¡policy ¡customizaCons ¡

} More ¡robust ¡tesCng ¡and ¡integraCon ¡into ¡mainline ¡

MRNet ¡

Auto-­‑topology ¡to ¡do ¡list ¡

slide-25
SLIDE 25

Scalable Systems Lab

} “External” ¡add-­‑on ¡if ¡possible ¡

  • Minimize ¡MRNet ¡interface ¡modificaCons ¡
  • Minimize ¡changes ¡to ¡MRNet ¡base ¡code ¡
  • Can ¡sCll ¡package ¡with ¡MRNet ¡

} Reduces ¡barrier ¡to ¡acceptance ¡ } Eases ¡“blame ¡abribuCon” ¡

General ¡approach ¡for ¡MRNet ¡extensions ¡

slide-26
SLIDE 26

Scalable Systems Lab

} Autonomous ¡tool ¡operaCon ¡in ¡general ¡ } Exascale ¡tool ¡readiness ¡

  • Step ¡1: ¡Change ¡workshop ¡name ¡J ¡
  • Will ¡tool ¡overhead ¡increase ¡with ¡scale ¡(like ¡resilience)? ¡

} How ¡relevant ¡are ¡faults ¡and ¡failures ¡for ¡tools? ¡

  • Maintain ¡operaCon ¡without ¡recovering ¡data? ¡
  • Simple ¡detecCon ¡and ¡restart? ¡
  • More ¡complex ¡data ¡recovery? ¡

¡

PotenCal ¡Working ¡Group ¡Topics ¡

slide-27
SLIDE 27

QuesCons ¡