mboost-dp1
Amazon
Ifølge analytikere kan nedbruddet skabe mistillid til skyen, da hosting i skyen netop sælges på at det er mere pålideligt end almindelig hosting på en dedikeret maskine.
Og med god grund. Cloud hosting er smart, men nogle folk får gjort det til den ultimate løsning til alle situationer.
Og med god grund. Cloud hosting er smart, men nogle folk får gjort det til den ultimate løsning til alle situationer.
Ifølge analytikere kan nedbruddet skabe mistillid til skyen, da hosting i skyen netop sælges på, at det er mere pålideligt end almindelig hosting på en dedikeret maskine.Den slags systemer kan sagtens gøres mere sikre overfor hardware fejl end et system hostet på en enkelt server. Men, samtidigt vil de systemer være mere sårbare overfor software fejl.
Og det vil altid være sådan, at der vil være usædvanlige situationer, hvor softwarens håndtering er dårligere testet. Langt de fleste software bugs jeg ser er i fejlhåndtering, hvoraf de fleste fejl der er problemer med at håndtere er hardware fejl.
En klasse af fejl jeg har set flere gange er kode der glemte at aflæse fejlregistre fra hardwaren.
Vi har altså en situation, hvor cloud systemer kan designes så de er robuste overfor hardware fejl, men sårbare overfor software fejl. Samtidigt vil disse software fejl ofte vise sig, når der er hardware fejl. Resultatet er et design, som er robust overfor hardware fejl, men en faktisk implementation, som er sårbar overfor hardware fej, end det gamle system.
Et helt andet problem er, at man tit går på kompromis i sit design med hensyn til hvor robust man laver systemet overfor hardware fejl.
En central komponent i distribuerede og redundante systemer, er en agreement algoritme, som skal være tolerant overfor fejl.
Der er to delvist uafhængige aspekter, man skal tage stilling til i sådan et design. Det ene er valget mellem synkron og asynkron kommunikation, og det andet er valget mellem en byzantine eller en stop-dead fejl model.
Synkron kommunikation er simplere, men har det problem, at der gøres antagelser om hvor lang tid det kan tage at sende en pakke fra en node til en anden. Performance vil blive begrænset af, at man altid er nødt til at vente denne maksimum tid, og selv når netværket kan levere pakkerne hurtigere, vil systemet i helhed gå langsommere. På den anden side, hvis pakkerne bliver leveret langsommere end man har antaget, vil hele systemet bryde sammen og enten gøre forkerte ting, eller låse totalt.
Asynkron kommunikation er mere indviklet at designe (men kan være nemmere at implementere). Asynkron kommunikation vil gøre at systemet kører så hurtigt som netværket tillader. Men, det er umuligt at lave sådan et system deterministisk. Hvis samtlige komponenter er lavet deterministiske kan det bevises, at der kan opstå situationer hvor systemet enten gør noget forkert eller blot sender pakker i det uendelige uden nogensinde at nå et resultat. Dette kan løses med probabilistiske algoritmer. Hvis man stoler på kryptografiske konstruktioner, som f.eks. RSA, kan systemet implementeres med pseudotilfældige tal. (De fleste vil nok stole på, at en defekt i hardwaren ikke pludselig laver en computer om til et device der kan bryde RSA kryptering). De probabilistiske algoritmer kan i teorien kører i det uendelige, men sandsynligheden for at det sker er nul. Og det gennemsnitlige antal roundtrips kan gøres konstant.
Det andet spørgsmål er fejlmodellen. En stop-dead fejl model betyder, at man antager hver computer enten fungerer korrekt eller helt holder op med at sende data. En byzantine model antager at fejlbehæftede computere kan opføre sig arbitrært. Med andre ord, man antager at de fejlbehæftede computere er kontrolleret af en adversary, som udelukkende er interesseret i at introducere fejl af den ene eller anden art i systemet.
I en stop-dead model kan man håndtere op til (men ikke inklusiv) 50% fejl. Hvis man f.eks. har 6 computere i systemet, kan man håndtere 2 fejl. Hvis 3 computere er fejlbehæftet vil systemet bryde sammen, fordi 3 ud af 6 er 50%. Hvis man har 7 computere i systemet kan man håndtere 3 fejl, fordi 3 ud af 7 er mindre end 50%.
I en byzantine model kan man kun håndtere 1/3 fejl (ikke inklusiv). Hvis man f.eks. har 6 computere i systemet kan man håndtere 1 fejl. 2 fejlbehæftede ville udgøre 1/3, hvilket ville være for meget. Hvis man har 7 kan man håndtere 2 fejl, fordi 2 ud af 7 er mindre end 1/3.
Det kunne lyde som om en stop-dead model er bedre, men hvis man implementerer sit system udfra dette vil det kunne bryde sammen hvis en computer fejler på en måde, som ikke stemmer overens med stop-dead modellen. Et enkelt bitflip i en af maskinerne vil være i strid med den model man har antaget, og kan altså betyde at systemet bryder sammen.
Personligt mener jeg at man bør holde sig til en asynkron byzantine model, og så have nok maskiner i systemet til at 1/3 fejl er usandsynligt.
Der er mange, som bruger en stop-dead model, synkron kommunikation, eller på anden måde prøver at lave noget, som er bedre end en asynkron model med byzantine fejl. Problemet er, at uanset hvordan man forbedrer systemets håndtering af nogle fejlsituationer, vil resultatet være dårligere håndtering af andre fejlsituationer. Hvis et system kan foretage sig en eneste transaktion med mindre 2/3 af maskinerne i live, så vil der være en anden situation hvor mindre end 1/3 fejlbehæftede maskiner resulter i et sammenbrud.
Er det fornuftigt at lade valget af hvordan fejlmodellen skal se ud blive valgt af det firma, der kører den fysiske infrastruktur? Jeg ville foretrække et system, hvor hvilken software stak man anvender til sit system kan vælges uafhængigt af valget af infrastruktur. Og faktisk burde man kunne sprede sit system over flere udbydere af infrastruktur.
Hvis man spreder sit system over fire forskellige udbydere vil man kunne lave et system, som kan køre videre hvis en af de fire leverandører har et totalt sammenbrud. Hvis man samtidigt kræver at hver udbyder garanterer at man har maskiner i fire forskellige geografiske regioner, så er man sikret at en naturkatastrofe ikke rammer for mange af ens maskiner spredt over flere leverandører.
Men, der er dog risikoen for at en naturkatastrofe kombineret med en leverandør som ikke lever op til sine løfter ville være et problem. Det setup jeg beskrev ville involver 16 maskiner i alt, så man kan håndtere 5 fejl. Hvis en naturkatastrofe resulterer i at samtlige 4 maskiner hos en udbyder bliver ramt, samtidig med at en maskine hos hver af de andre 3 udbydere bliver ramt, så har man 7 fejl, hvilket er for mange. Det kunne man så undgå ved at kræve at hver udbyder har 10 forskellige lokaliteter.
Man skal selvfølgelig ikke designe et system hvor alt data skal igennem et byzantine agreement system. Hvis man har et robust byzantine agreement system så kan man lave et hierarkisk system af komponenter, som udelukkende bruger ovenstående som en metode til at afgøre rækkefølgen på transaktioner.
Spørgsmålet er hvor mange kunder der kunne finde på at leje 40 forskellige VMs hos forskellige udbydere blot for at køre et byzantine agreement system. Er der basis for byzantine agreement service distribueret over forskellige cloud udbydere? Og ville kunderne stole mere på sådan et system end på cloud udbyderens tilbud?
LordMike (9) skrev:Ctrl Alt Delete er også nede :P
http://www.cad-comic.com/
Sjovt de var oppe tidligere i dag... efter at Amazon EC2 kom op. Jeg kan godt se deres host bruger Amazon, så memindre det er fordi de er i gang med at rykke siden tilbage til EC2, så giver det ikke rigtigt mening.
EC2's SLA er her:
http://aws.amazon.com/ec2-sla/
Nydelig optids garanti på 99.95% over 365 dag (det er ca. 4 timer nedtid om året).
Men jammerlig kompensation: 10% rabat på næste månds regning.
http://aws.amazon.com/ec2-sla/
Nydelig optids garanti på 99.95% over 365 dag (det er ca. 4 timer nedtid om året).
Men jammerlig kompensation: 10% rabat på næste månds regning.
Hvis nu nedetiden strækker sig over flere dage, kan man så sende et nyt krav om kompensation hver fjerde time, og efter 22 dages nedetid have optjent et helt års service?arne_v (13) skrev:Nydelig optids garanti på 99.95% over 365 dag (det er ca. 4 timer nedtid om året).
Men jammerlig kompensation: 10% rabat på næste månds regning.
Så længe man kan opnå 100% kompensation før availability er faldet til 67%, så kan man nok konstruere noget stabilt ved at køre det over flere udbydere.
Men jeg er fuldstændigt enig i, at 10% kompensation er at holde kunderne for nar. Hvis en udbyder ønsker at deres availability garanti bliver taget seriøst, så burde der være 100% kompensation allerede ved 99% og 200% kompensation ved 95%
kasperd (14) skrev:Hvis nu nedetiden strækker sig over flere dage, kan man så sende et nyt krav om kompensation hver fjerde time, og efter 22 dages nedetid have optjent et helt års service?
Nope.
The “Eligible Credit Period” is a single month, and refers to the monthly billing cycle in which the most recent Region Unavailable event included in the SLA claim occurred.
Det grupperes per måned.
Any downtime occurring prior to a successful Service Credit claim cannot be used for future claims.
Den samme nedtid kan kun bruges en gang.
kasperd (14) skrev:Men jeg er fuldstændigt enig i, at 10% kompensation er at holde kunderne for nar. Hvis en udbyder ønsker at deres availability garanti bliver taget seriøst, så burde der være 100% kompensation allerede ved 99% og 200% kompensation ved 95%
200% kompensation ved 95% ? Okay, 95% i sig selv er ekstrem uacceptabelt, men hverken 100% eller 200% kompensation er tilnærmelsesvis menneskeligt.
Amazon har næppe økonomi til at leve videre, såfremt de skal kompensere så de mister omkring 8% af deres årsomsætning på EC2. (8% = cirka en måned på et år).
Kompensationen for et nedbrud er heller ikke vigtig for særligt mange virksomheder. For hvis der er for meget nedetid, hvad hjælper 100.000kr så i erstatning, hvis du har tabt ordrer for 5mio kr? Så er løsningen snarrere at leverandøren udskiftes...
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund