Berkeley Approach to Systems • Find an important problem crossing HW/ SW Computers f or the Post- PC Era I nterf ace, with HW/ SW prototype at end • Assemble a band of 3- 6 f aculty, 12- 20 grad Aaron Brown, J im Beck, Rich Martin, students, 1- 3 staf f to tackle it over 4 years David Oppenheimer, K athy Yelick, and • Meet twice a year f or 3- day retreats with David Patterson invited outsiders – Builds team spirit http://iram.cs.berkeley.edu/istore – Get advice on direction, and change course – Of f ers milestones f or project stages – Grad students give 6 to 8 talks ⇒ Great Speakers 1999 Grad Visit Day • Write papers, go to conf erences, get PhDs, jobs • End of project party, reshuf f le f aculty, go to 1 Slide 1 Slide 2 For Example, Projects I Have Worked On Symbolic Processing Using RI SCs: ‘85- ’89 • RI SC I , I I • Bef ore Commercial RI SC chips – Sequin, Ousterhout (CAD) • Built Workstation Multiprocessor and • SOAR (Smalltalk On A RI SC) Ousterhout (CAD) Operating System f rom scratch(!) • SPUR (Symbolic Processing Using RI SCs) • Sprite Operating System – Fateman, Hilf inger, Hodges, K atz, Ousterhout • 3 chips: Processor, Cache Controller, FPU • RAI D I , I I (Redundant Array of I nexp. Disks) – Coined term “snopping cache protocol” – K atz, Ousterhout, Stonebraker – 3C’s cache miss: compulsory, capacity, conf lict • NOW I , I I (Network of Workstations), (TD) – Culler, Anderson • I RAM I (I ntelligent RAM) – Yelick, K ubiatowicz, Wawrzynek • I STORE I , I I (I ntelligent Storage) – Yelick, K ubiatowicz Slide 3 Slide 4 SPUR 10 Year Reunion, J anuary ‘99 Group Photo (in souvenir jackets) • Everyone f rom North America came! • 19 PhDs: 9 to Academia – 8/ 9 got tenure, 2 f ull prof essors (already) – 2 Romme f ellows (3rd, 4th at Wisconsin) – 3 NSF Presidential Young I nvestigator Winners – 2 ACM Dissertation Awards – They in turn have produced 30 PhDs (so f ar) • 10 to I ndustry – Founders of 4 startups, (1 f ailed) – 2 Department heads (AT& T Bell Labs, Microsof t) • Very successf ul group; SPUR Project “gave them a taste of success, lif elong f riends”, • See www. cs. berkeley. edu/ Projects/ ARC to learn more about Berkeley Systems Slide 5 Slide 6 Page 1
Outline Perspective on Post- PC Era • Background: Berkeley Approach to • PostPC Era will be driven by two technologies: Systems 1) Mobile Consumer Electronic Devices • PostPC Motivation – e. g. , successor to PDA, Cell phone, wearable computers • PostPC Microprocessor: I RAM 2) I nf rastructure to Support such Devices • PostPC I nf rastructure Motivation – e. g. , successor to Big Fat Web Servers, • PostPC I nf rastructure: I STORE Database Servers • Hardware Architecture • Sof tware Architecture • Conclusions and Feedback Slide 7 Slide 8 I ntelligent PDA ( 2003?) V- I RAM1: 0. 18 µm, Fast Logic, 200 MHz Pilot PDA 1. 6 GFLOPS(64b)/ 6. 4 GOPS(16b)/ 32MB + gameboy, cell phone, + 4 x 64 or radio, timer, camera, x 8 x 32 2-way Vector or TV remote, am/ f m Superscalar Instruction ÷ Processor 16 x 16 Queue radio, garage door I/O Load/Store I/O opener, . . . 16K I cache16K D cache Vector Registers + Wireless data (WWW) 4 x 64 4 x 64 Serial Memory Crossbar Switch + Speech, vision recog. Speech control I/O M M M M M M M M M M +Vision to see, + Voice output f or … M M M M M M M M M M scan documents, 4 x 64 4 x 64 4 x 64 conversations 4 x 64 4 x 64 I/O I/O … … … … … … … … … … M M M M M M M M M M read bar code, . . . Slide 9 Slide 10 I RAM Vision Statement Outline Microprocessor & DRAM • PostPC I nf rastructure Motivation and Proc L $ $ on a single chip: o f Background: Berkeley’s Past L2 $ I / O I / O – 10X capacity vs. DRAM g a Bus • PostPC Motivation Bus – on- chip memory latency i b 5- 10X, c • PostPC Device Microprocessor: I RAM D R A M bandwidth 50- 100X • PostPC I nf rastructure Motivation – improve energy ef f iciency I / O I / O 2X- 4X (no of f - chip bus) • I STORE Goals Proc D – serial I / O 5- 10X v. buses f Bus • Hardware Architecture R – smaller board area/ volume a A – adjustable memory • Sof tware Architecture b M D R A M size/ width • Conclusions and Feedback Slide 11 Slide 12 Page 2
Tertiary Disk HW Failure Experience Background: Tertiary Disk (part of NOW) • Tertiary Disk Reliability of hardware components (20 months) (1997) 7 I BM SCSI disk f ailures (out of 364, or 2% ) 6 I DE (internal) disk f ailures (out of 20, or 30% ) – cluster of 20 PCs 1 SCSI controller f ailure (out of 44, or 2% ) hosting 364 3. 5” 1 SCSI Cable (out of 39, or 3% ) I BM disks (8. 4 GB) 1 Ethernet card f ailure (out of 20, or 5% ) in 7 19”x 33” x 84” 1 Ethernet switch (out of 2, or 50% ) racks, or 3 TB. 3 enclosure power supplies (out of 92, or 3% ) The 200MHz, 96 1 short power outage (covered by UPS) MB P6 PCs run Did not match expectations: FreeBSD and a – Hosts world’s largest art switched 100Mb/ s SCSI disks more reliable than SCSI cables! database:72, 000 images in Ethernet connects cooperation with San Francisco Dif f erence between simulation and prototypes the hosts. Also 4 Fine Arts Museum: UPS units. Try www. thinker. org Slide 13 Slide 14 SCSI Time Outs Saw 2 Error Messages per Day + Hardware Failures (m11) • SCSI Error Messages: Disk Hardware Failures – Time Outs : Response: a BUS RESET command SCSI Bus 0 SCSI Time Outs SCSI Time Outs 10 – Parity: Cause of an aborted request 10 SCSI Bus 0 Disks 9 8 SCSI Bus 0 Disks • Data Disk Error Messages: 8 7 6 – Hardware Error : The command unsuccessf ully 6 4 5 terminated due to a non- recoverable HW f ailure. 4 2 3 – Medium Error : The operation was unsuccessf ul due 2 0 to a f law in the medium (try reassigning sectors) 1 8/17/98 8/19/98 8/21/98 8/23/98 8/25/98 8/27/98 0 – Recovered Error: The last command completed with 8/15/98 0:00 8/17/98 8/19/98 0:00 8/21/98 0:00 8/23/98 8/25/98 0:00 8/27/98 0:00 8/29/98 8/31/98 0:00 the help of some error recovery at the target 0:00 0:00 0:00 0:00 0:00 0:00 0:00 0:00 0:00 – Not Ready: The drive cannot be accessed Slide 15 Slide 16 Can we predict a disk f ailure? SCSI Bus 2 Parity Errors (m2) • Yes, look f or Hardware Error messages SCSI Bus 2 SCSI Parity Errors – These messages lasted f or 8 days between: SCSI Bus 2 Disks » 8- 17- 98 and 8- 25- 98 15 – On disk 9 there were: 10 » 1763 Hardware Error Messages, and 5 » 297 SCSI Timed Out Messages 0 • On 8- 28- 98: Disk 9 on SCSI Bus 0 of 9/2/98 9/12/98 9/22/98 10/2/98 10/12/9 10/22/9 m11 was “f ired”, i. e. appeared it was 0:00 0:00 0:00 0:00 8 0:00 8 0:00 about to f ail, so it was swapped Slide 17 Slide 18 Page 3
Lessons f rom Tertiary Disk Project Can We Predict Other K inds of Failures? • Yes, the f lurry of parity errors on m2 • Maintenance is hard on current systems occurred between: – Hard to know what is going on, who is to blame • Everything can break – 1- 1- 98 and 2- 3- 98, as well as – I ts not what you expect in advance – 9- 3- 98 and 10- 12- 98 – Follow rule of no single point of f ailure • On 11- 24- 98 • Nothing f ails f ast – m2 had a bad enclosure ⇒ cables or connections def ective – Eventually behaves bad enough that operator “f ires” poor perf ormer, but it doesn’t “quit” – The enclosure was then replaced • Most f ailures may be predicted Slide 19 Slide 20 Outline Storage Priorities: Research v. Users • Background: Berkeley Approach to Current Research I STORE Systems Priorities Priorities • PostPC Motivation 1) Perf ormance 1) Maintainability } easy • PostPC Microprocessor: I RAM to 1’) Cost 2) Availability • PostPC I nf rastructure Motivation measure 3) Scalability 3) Scalability • PostPC I nf rastructure: I STORE 4) Availability 4) Perf ormance • Hardware Architecture 10) Maintainability 4’) Cost • Sof tware Architecture • Conclusions and Feedback Slide 21 Slide 22 I ntelligent Storage Project Goals Self - maintenance • Failure management – devices must f ail f ast without interrupting service • I STORE: a hardware/ sof tware – predict f ailures and initiate replacement architecture f or building scaleable, – f ailures ⇒ immediate human intervention self - maintaining storage • System upgrades and scaling – An int rospect ive system: it monitors itself and acts on its observations – new hardware automatically incorporated without interruption • Self - maintenance: does not rely on – new devices immediately improve perf ormance or administrators to conf igure, monitor, or repair f ailures tune system • Perf ormance management – system must adapt to changes in workload or access patterns Slide 23 Slide 24 Page 4
Recommend
More recommend
