0
I papiret Grå Fiasko: Den akilleshæl Cloud-Skala Systemer dataloger Peng Huang, Chuanxiong Guo, Lidong Zhou, og Jacob R. Lorch, Microsoft Research, og Yingnong Dang, Murali Chintalapati, og Randolph Yao, Microsoft Azure, sluttet sig sammen for at udforske den grå manglende problem.
Ulempen ved hyperscale
De definerer grå fejl, som
. . . komponent fejl, hvis manifestationer er temmelig subtil og dermed trodse hurtig og endelig opdagelse.
Disse subtile fejl kan føre til dårlige resultater, mistet pakker, defekt I/O, hukommelse prygl, og ikke-fatal undtagelser.
Naturligvis, da antallet af infrastruktur komponenter stiger, så gør antallet af grå fejl. Dette er hyperscale mørke side.
Mens lejlighedsvis langsommere ydeevne, kan virke som en lille pris at betale for fordelene ved cloud-tjenester, faren for grå fejl er langt større. Som grå fejl ophobes, stress på en sund systemer vokser, og det kan føre til en brusende, aviserne massive strømsvigt.
Grå manglende ‘ s dybe rødder
Fejltolerante systemer hvile på tre søjler: afskedigelse, manglende opdagelse, og manglende tilbagebetaling. Redundans er givet i cloud infrastruktur. De problemer, der kommer i fiasko detection and recovery.
Kodere, der skriver software lag er sjældent ekspert i den hardware, der gør op med infrastruktur. Ofte gør de forsimplede antagelser om, hvordan det går, og hvad der mangler at blive opdaget.
Men som enhver hardware ingeniør kan fortælle dig at der er mange steder hardware kan gå galt, uden at crashe eller ryger. Intermittant hardware fejl, memory leaks, buffer overflows, og baggrunden job, kan alle føre til en reduceret ydelse eller intermitterende grå fiasko uden en overt-symptom, der fører til en genstart af systemet, eller hardware udskiftning.
Differential observability
Det vigtigste symptom på en grå fiasko er, hvad forfatterne kalder differentieret observability. Hvis en server er aftaget til en gennemgang, men dens hjerteslag er regelmæssig, et meddelende system vil ikke se et problem, men en kunde, vil systemet. Der er differentieret observability.
Der får forfattere til at gøre en række anbefalinger til bedre at opdage og korrigere grå fejl.
Stol ikke på en enkelt indikator, såsom hjerteslag, for systemet sundhed. Prøv at tage en ansøgning synspunkt, snarere end en hardware opfattelse, at opdage grå fejl. Gearing skala til registrering. For svært grå svigt, som du muligvis er nødt til at indsamle observationer fra tusindvis af servere og brug af statistiske slutninger for at finde den grå-ikke-komponenter. Tidsmæssig analyse. Tracking væsentlige fejl tilbage i tiden for at forstå de små fejl, der førte til nedbrud hjælper med at stramme op på registreringen.
Opbevaring Bits tage
Grå fejl er en forlængelse af en klasse af fejl, som den afdøde, store, Jim Grå kaldet “Heisenbugs”, forbigående fejl, der forsvinder, når du prøver at observere dem på grund af subtile forskelle i de oprindelige betingelser. På grund af deres midlertidige karakter, at ingen enkelt værktøj eller metrisk vil fange dem.
Dette betyder, at cloud-infrastrukturer, der er dømt til at mislykkes under vægten af deres voksende størrelse og kompleksitet? Nej. Men det betyder, at de værktøjer, der anvendes til at styre dem skal blevet mere sofistikerede.
Og infrastruktur arkitekter skal være opmærksomme på nuancerne i grå manglende interaktion med systemet design, som diskuteres i papir. For eksempel counter-intuitive at finde, at en større redundans kan føre til lavere ledighed.
Høflige bemærkninger velkommen, selvfølgelig. Bravo til Microsoft Research og det Azurblå folk for offentliggørelsen af dette papir. Det er rart at vide, at MS har nogle meget intelligente mennesker, der passede butikken.
0