Vraag 100% uptime voor een webapplicatie


We hebben vandaag een interessante "vereiste" ontvangen van een klant.

Ze willen 100% uptime met off-site failover op een webapplicatie. Vanuit het oogpunt van onze webapplicatie is dit geen probleem. Het is ontworpen om te kunnen schalen over meerdere databaseservers, enz.

Nochtans, van een netwerkkwestie kan ik enkel niet schijnen te vinden hoe te om het te laten werken.

In een notendop, de applicatie zal leven op servers binnen het netwerk van de klant. Het is toegankelijk voor zowel interne als externe mensen. Ze willen dat we een off-site exemplaar van het systeem bewaren dat in het geval van een ernstige storing in hun gebouwen het onmiddellijk zou overnemen en overnemen.

Nu weten we dat er absoluut geen manier is om het op te lossen voor interne mensen (postduif?), Maar ze willen dat de externe gebruikers het niet eens merken.

Eerlijk gezegd heb ik niet het flauwste idee hoe dit mogelijk zou kunnen zijn. Het lijkt erop dat als ze de internetverbinding verliezen, we een DNS-wijziging moeten doorvoeren om verkeer naar de externe machines door te sturen ... Dat kost natuurlijk tijd.

Ideeën?

BIJWERKEN

Ik had vandaag een gesprek met de klant en zij hebben dit probleem opgehelderd.

Ze blijven steken op het 100% -getal en zeggen dat de applicatie actief moet blijven, zelfs in het geval van een overstroming. Die vereiste treedt echter alleen in werking als we deze voor hen hosten. Ze zeiden dat ze de uptime-eis zouden behandelen als de applicatie volledig op hun servers zou leven. Je kunt mijn antwoord raden.


310
2017-09-29 00:31


oorsprong


Onderschat de enorme downtime veroorzaakt door hacking niet, kijk naar Sony en het PlayStation-netwerk. u kunt garanderen dat ze hetzelfde% 100 uptime-idee en het geld / hardware hebben om een ​​back-up te maken. maak met de klant duidelijk dat 100% uptime een onhaalbare verwachting is, zelfs google-techneuten zouden aarzelen om "100% uptime" te mompelen. een hint btw is om te kijken naar het gebruik van dynamische DNS, ze cachen slechts 60 seconden, dit zou OS en lokale DNS-servers moeten omvatten. - Silverfire
Ik zou het persoonlijk doen RENNEN van deze klant zo snel mogelijk. Ik vermoed dat dit niet het laatste gekke idee is dat ze hebben (vanuit technologisch oogpunt). - GregD
Ik wou dat ik je klant kon downvote. - joeqwerty
Als je 100% uptime weet, laat het me weten. Ik maak er een bedrijf mee en verkoop het aan google. Het is onmogelijk om 100% te garanderen. Zelfs bedrijven als Microsoft, Amazon of Google zullen niet zo hoog gaan omdat ze weten dat het onmogelijk is. De beste die ik heb gezien is 99,999% en zelfs dat is een stuk (5 minuten per jaar). Het beste wat u waarschijnlijk zou kunnen doen, is betrouwbaar 99,99%. - Matt
Maak gewoon een waanzinnig hoog prijskaartje om hun gekke verzoek in te dienen. Dat zal hen waarschijnlijk weer in hun zintuigen brengen. Ofwel, of het stuurt ze op zoek naar iemand die bereid is om tegen ze te liegen. - Nate C-K


antwoorden:


Hier is Wikipedia's handige grafiek van het nastreven van negens:

enter image description here

Interessant, alleen 3 van de top 20 websites waren in staat om de mythische 5 negens of 99,999% uptime in 2007 te bereiken. Het waren Yahoo, AOL en Comcast. In de eerste 4 maanden van 2008, enkele van de meesten populaire sociale netwerken, kwam daar niet eens dichtbij.

Uit de grafiek moet duidelijk blijken hoe belachelijk het nastreven van 100% uptime is ...


363
2017-09-29 01:03



Pingdom controleert ook niet elke seconde. Daar komt nog bij dat degene die vijf negens tegenkwam waarschijnlijk nog steeds lokale verstoringen had die Pingdom misschien niet had ontdekt, of glitches waardoor sommige services niet meer beschikbaar waren terwijl ze nog steeds reageerden op pings. - ceejayoz
Wat op zichzelf de vijf negens twijfelachtig maakt ... - GregD
Precies. En ze hebben $ miljarden om mee te werken! - ceejayoz
Het spijt me dat ik de chat heb laten verstoren, maar de vraag van het OP was hoe het moet gaan om te streven naar het doel van 100% uptime op een technisch niveau, niet conceptueel, ik weet zeker dat hij weet dat het niet altijd mogelijk is vanwege natuurlijke gebeurtenissen die met hardware gebeuren en het milieu. Kunnen we hem daarmee helpen? - David d C e Freitas
Aan het OP: ik heb SLA's gezien die de uptime garandeerden in de context van "buiten normaal onderhoud". Het normale onderhoud is natuurlijk dat de downtime per maand wordt gepland voor updates, patches, enz., Die meestal op de minst drukke dag van de maand plaatsvinden tijdens de minste drukke tijden van de maand (meestal in het holst van de nacht). Ze moeten een bepaald soort statistieken hebben voor hun bedrijf met betrekking tot zaken. U kon bieden betere uptime (4 negens) voor hen enkel en alleen in die tijd. - GregD


Vraag hen om 100% te definiëren en hoe het zal worden gemeten gedurende welke tijdsperiode. Ze bedoelen waarschijnlijk bijna 100% als ze zich kunnen veroorloven. Geef ze de kosten.

Uitbreiden. Ik heb in de loop der jaren met klanten gesproken met zogenaamd belachelijke eisen. In alle gevallen gebruikten ze eigenlijk gewoon niet-nauwkeurig genoeg taal.

Heel vaak framen ze dingen op een manier die absoluut lijkt - zoals 100%, maar in feite zijn ze bij diepgaander onderzoek redelijk genoeg om de kosten / batenanalyses te doen die vereist zijn wanneer ze worden gepresenteerd met de kosten voor risicobeperkende gegevens. Hen vragen hoe zij de beschikbaarheid zullen meten is een cruciale vraag. Als zij dit niet weten, kunt u hun voorstellen dat dit eerst moet worden gedefinieerd.

Ik zou de klant vragen te definiëren wat er zou gebeuren in termen van impact / kosten van het bedrijf als de site zou worden onderbroken in de volgende omstandigheden:

  • Op de drukste uren voor x uur
  • Op zijn minst drukke uren voor x uur

En ook hoe ze dit zullen meten.

Op deze manier kunt u met hen werken om het juiste niveau van '100%' te bepalen. Ik vermoed dat door dit soort vragen te stellen, ze in staat zullen zijn om de prioriteiten van hun andere vereisten beter te bepalen. Ze willen bijvoorbeeld bepaalde niveaus van SLA betalen en andere functionaliteit compromitteren om dit te bereiken.


186
2017-09-29 09:45



Akkoord. Ze kunnen gewoon "zeer hoge" uptime (upper 90s?) Betekenen met een mooie solide failover-strategie. Zo niet, dan zou een verklaring van de betreffende kostenschaal hen hopelijk overtuigen ... - Martin Dow
+1 om niet naar conclusies te springen, en in plaats daarvan gewoon de cliënt vragen om uit te leggen wat ze in gedachten hebben. - sleske
Ik sluit me aan bij de uitspraak "niet naar conclusies springen" ... als de klant 100% uptime (minus gepland onderhoud) betekent dan is het mei een meer redelijke eis zijn. - Tim Reddy
Wat betreft de impact van het bedrijf, kennen en begrijpen we hun bedrijf volledig en zijn de kosten voor het omlaag gaan van de site niet financieel. Meer in de trant van de inboorlingen die opduiken met hooivorken, mogelijke ophangingen, enz;) Stel je eens voor dat 40.000 mensen voor de deur komen schreeuwen. Dat is wat ze willen vermijden met een passie. - NotMe
@ChrisLively Reden te meer om volwassen inzicht in risico te hebben. Het dominante paradigma voor veiligheidstechniek is probabilistische risicobeoordeling. Er zijn systemen die duizenden mensen kunnen doden (niet alleen ergeren) en ze hebben nog steeds een lage, hopelijk goed begrepen, maar niet-nul faalkans. - poolie


Je klanten zijn gek. 100% uptime is onmogelijk ongeacht hoeveel geld je eraan uitgeeft. Eenvoudig en duidelijk - onmogelijk. Kijk naar Google, Amazon, etc. Ze hebben bijna eindeloze hoeveelheden geld om naar hun infrastructuur te gooien en toch hebben ze nog steeds downtime. Je moet die boodschap aan hen overbrengen en als ze blijven aandringen dat ze redelijke eisen stellen. Als ze dat niet herkennen sommige hoeveelheid downtime is onvermijdelijk, en gooi ze dan weg.

Dat gezegd hebbende, lijkt u de mechanica te hebben om de applicatie zelf te schalen / distribueren. Het netwerkgedeelte moet redundante uplinks naar verschillende ISP's omvatten, een ASN- en IP-toewijzing krijgen en hals over kop in BGP en echte routeringsapparatuur komen zodat IP-adresruimte indien nodig tussen ISP's kan worden verplaatst.

Dit is overduidelijk een heel kort antwoord. U hebt geen ervaring met applicaties die deze mate van uptime vereisen, dus u moet echt een professional inschakelen als u de mythische 100% uptime wilt bereiken.


141
2017-09-29 00:39



Akkoord. Totally. Gek. - jdw
vroeger? - Sirex
@Sirex Verwijzend naar het recente experiment @ CERN waar neutrino's zijn gevonden om sneller te reizen dan licht. De resultaten moeten nog worden bevestigd door onafhankelijke wetenschappers. - TC1
@ TC1 Ik wed dat je $ 200 dat komt niet uit. - dpatchery
@ErikA Een verzoek om 100% uptime wijst op onwetendheid over technische kenmerken van systemen. Dat is goed, want het werk van de klant doet wat ze doen. Jouw taak is om IT-systemen te engineeren. Moeilijke klanten zoals deze kunnen nachtmerries zijn, maar ze kunnen ook je beste klanten worden. - duffbeer703


Wel, dat is absoluut een interessante. Ik weet niet zeker of ik mezelf contractueel verplicht zou willen maken tot 100% uptime, maar als het moest, zou ik denken dat het er ongeveer zo uitziet:

Begin met het publieke IP op een load balancer volledig uit het netwerk en bouw er ten minste twee op zodat de een aan de ander kan overlaten. Een programma zoals Heatbeart kan helpen met de automatische failover daarvan.

Varnish is vooral bekend als een caching-oplossing, maar het doet ook een zeer degelijke load-balancing. Misschien zou dat een goede keuze zijn om de load-balancing aan te pakken. Het kan ingesteld worden om 1 tot n backendes te hebben die optioneel gegroepeerd zijn in regisseurs die willekeurig of round-robin balans laden. Vernis kan slim genoeg worden gemaakt om de gezondheid van elke back-end te controleren en ongezonde back-ends uit de lus te halen totdat deze weer online komt. De backends hoeven niet op hetzelfde netwerk te staan.

Ik ben tegenwoordig een beetje verliefd op de Elastische IP's in Amazon EC2, dus ik zou mijn loadbalancers waarschijnlijk in EC2 in verschillende regio's of op zijn minst in verschillende beschikbaarheidszones in dezelfde regio bouwen. Dat zou je de mogelijkheid geven om handmatig (god verhoede) een nieuwe load-balancer op te draaien als je de bestaande A-record-IP naar de nieuwe box zou moeten verplaatsen en verplaatsen.

Varnish kan SSL echter niet beëindigen, dus als dat een zorgpunt is, zou je in plaats daarvan naar iets als Nginx kunnen kijken.

U zou de meeste van uw backends in uw klantennetwerk en één of meer buiten hun netwerk kunnen hebben. Ik ben van mening, maar ben niet 100% zeker, dat je de backends kunt prioriteren, zodat de machines van je klanten voorrang krijgen totdat ze allemaal ongezond zijn geworden.

Dat is waar ik zou beginnen als ik deze taak zou hebben en het ongetwijfeld zou verfijnen als ik meega.

Echter, zoals @ErikA aangeeft, het is internet en er zullen altijd delen van het netwerk zijn die buiten uw macht liggen. U moet ervoor zorgen dat uw wettelijke status u alleen maar verbindt met dingen die onder uw controle zijn.


54
2017-09-29 00:47



Een tijdje dacht ik aan Amazon en MS voor een cloud-implementatie, maar ze hebben beiden de afgelopen maanden grote uitval gehad. SSL is van cruciaal belang. - NotMe
Als u Amazon zou gaan gebruiken, zou u zeker uw machines willen spreiden over de 5 beschikbaarheidszones. Het is vrij onwaarschijnlijk dat al hun zones tegelijkertijd zouden uitgaan. - jdw
+1 voor het daadwerkelijk behandelen van de hoofdvraag van het OP. - Phil
je hebt altijd een punt van falen, jdw, zolang er een niet-gedistribueerd ding in de keten zit (in jouw geval heartbeat, tenzij je natuurlijk meerdere instanties hebt die draaien op externe machines die elkaar en je servers, die een van hen al dan niet kan zien vanwege netwerkproblemen langs de routering). Dat brengt ons bij "downtime". De servers zijn mogelijk in gebruik en nog steeds niet beschikbaar voor de client zonder dat de Heartbeat deze ooit detecteert als de storing zich niet in het routeringspad bevindt. - jwenting
Akkoord. Zoals IEDEREEN heeft opgemerkt, is er niet zoiets als 100% uptime. Het enige wat je kunt doen is proberen en wat ik beschreef, is hoe ik het zou gaan proberen. - jdw


Geen probleem - enigszins gewijzigde contractformulering:

... een uptime van 100% garanderen (afgerond tot op nul decimalen).


29
2017-09-29 10:13



+1 voor het noteren, dat 100% niet 100,0% of 100.000% is enz. De decimale cijfers zijn van belang, zij geven de nauwkeurigheid aan;) - Danubian Sailor
Volgens sommige conventies heeft "100%" slechts één significant cijfer, zodanig dat alle getallen tussen de helft en één afgerond zouden zijn op "100%"; 50% zou rond zijn tot 100%. - Thomas Levine
Afhankelijk van de standaard voor tellen zullen sommigen zeggen dat 50% twee treffelijke cijfers heeft, waarbij 100% drie treffend getal heeft. 50,5 en 100 zijn daarom net zo nauwkeurig. Anderen tellen cijfers achter de komma. Dan zijn 50,5 en 100,4 net zo nauwkeurig. Als niets anders vermeld zou ik veronderstellen dat 100% 99,5% en hoger is. 100,0% is 99,95% en hoger, etc. - Tillebeck


Toevoegen oconnore's antwoord van Hacker News

Ik begrijp niet wat het probleem is. De klant wil dat je plannen maakt voor een ramp en ze zijn niet wiskundig georiënteerd, dus het vragen om 100% kans klinkt redelijk. De ingenieur, zoals ingenieurs geneigd zijn te doen, herinnerde zich zijn eerste dag van prob & stat 101, zonder te bedenken dat de klant dat misschien niet zou doen. Wanneer ze dit zeggen, denken ze niet aan de nucleaire winter, ze denken erover dat Fred zijn koffie op de kantoorserver dumpt, een schijf vastloopt of een ISP naar beneden gaat. Bovendien kunt u dit bereiken. Met geografisch gescheiden, onafhankelijke servers voor zelfcontrole, heeft u in principe geen downtime. Met 3 servers die werken op een onafhankelijke (1) drie 9-betrouwbaarheid, met goede failover-modi, is uw verwachte downtime minder dan een seconde per jaar (2). Zelfs als dit allemaal tegelijk gebeurt, bevindt u zich nog steeds binnen een redelijke SLA voor webverbindingen en daarom bestaat de downtime praktisch niet. De cliënt moet nog steeds omgaan met doemscenario's, maar Godzilla uitgesloten, hij zal een dienst hebben die "altijd" is.

(1) Een server in LA is redelijk onafhankelijk van de server in Boston, maar ja, ik begrijp dat er een kruising is met nucleaire oorlog, Chinese hackers die het elektriciteitsnet verpletteren, enz. Ik denk niet dat je klant van streek zal zijn door deze.

(2) DNS-failover kan een paar seconden toevoegen. U bevindt zich nog steeds in een scenario waarin de klant één keer per jaar een verzoek opnieuw moet indienen, wat opnieuw binnen een redelijke SLA valt en niet in het algemeen in dezelfde geest wordt beschouwd als "downtime". Met een toepassing die automatisch wordt omgeleid naar een beschikbaar knooppunt bij een storing, kan dit onmerkbaar zijn.


25
2017-09-30 15:49



Het probleem is dat ze het op contractbasis zeggen. Wat betekent dat als een ramp doet optreden en u hebt meer dan tien seconden nodig om de site online terug te nemen via back-ups die ze zouden moeten aanklagen. - Shadur
@Shadur: Als ze werkelijk wil het, dan moet je werkelijk laad ze op. Verspreid de servers geografisch ver en wijd, hopelijk zal er overal geen ramp zijn. - Jungle Hunter
Ik heb een site gezien met 100% uptime-garanties of uw geld terug. De kunst was dat ze een bootlading laadden en in maanden verdeelden. Dus sommige maanden gaan onbetaald en je plant alles daarrond en dekt het verlies af met de maanden die goed verlopen. - jldugger


Als Facebook en Amazon dit niet kunnen, dan kan dat niet. Zo simpel is het.


25
2017-09-29 01:10



hij zou slimmer kunnen zijn dan al hun mensen bij elkaar, wie weet: p - Matt
100% uptime hoeft niet zo letterlijk te zijn - het betekent: 100% beschikbaar tijdens de tijd dat het nodig is. Banksystemen zouden bijvoorbeeld altijd beschikbaar moeten zijn, en ze doen het vrij goed. Alleen al omdat ze één keer per jaar 1 seconde per jaar onderhoud plegen, betekent nog niet dat ze hun 100% uptime-doel niet hebben gehaald. - David d C e Freitas
@DavidFreitas - Ik denk dat het in contracten meestal vrij letterlijk is ... - UpTheCreek
@Matt alleen omdat Facebook / Amazon dit niet kunnen doen betekent niet dat een kleinere site het niet kan doen. Veel grote websites hebben te maken met veel moeilijkere problemen dan een kleinere site. - Xorlev
dus wat je zegt is dat je geen 100% uptime had, omdat je een aantal clients had met fouten .. plus dns is geen directe switch omdat je ISP's hebt die korte TTL's negeren - Mike


Er wordt om iets onmogelijks gevraagd.

Bekijk de andere antwoorden hier, ga met uw klant zitten en leg uit WAAROM het is onmogelijk en meet hun reactie.

Als ze nog steeds op 100% uptime aandringen, laat hen weten dat dit niet kan en laat het contract varen. Je zult nooit aan hun vraag voldoen, en als het contract niet helemaal zogt, krijg je skewered met straffen.


17
2017-09-29 03:41



100% moet worden gedefinieerd, d.w.z. 100% beschikbaar, behalve bij onderhoud of upgrades en die tijd zal maximaal enkele uren per maand tot stille uren worden beperkt. Het alles ligt eraan over wat het doel en gebruik van de web-app in dit geval is ... - David d C e Freitas
en definieer "downtime". Ik kan zelfs niet in theorie garanderen dat ze vanuit hun kantoor in Fairbanks toegang kunnen krijgen tot een server in Omaha, tenzij je het hele netwerk daartussen bestuurt (hoewel je er zeker van kunt zijn dat de server in gebruik is). - jwenting
De definities zijn, IMHO, niet relevant als ze vragen om "100% uptime": zelfs als u onderhandelt over gepland onderhoud en N + N redundantie inbouwt als een lichte storing een ongeplande herstart of service doet knipperen, hebt u uw SLA verbroken. DEFINITIEF relevant als je echter een 3, 4 of 5 negens SLA onderhandelt. - voretaq7
Hangt echter af van de voorwaarden van de SLA? Als u $ 100K per maand krijgt en elke minuut downtime een boete van $ 1K met zich meebrengt, is dat misschien volledig te doen (als u andere contracten heeft om de kosten van 24/7 on-site sysadmins af te schrijven). - Michael Borgwardt
@MichaelBorgwardt er zijn absoluut manieren om het "te laten werken" vanuit het oogpunt van pure getallen, maar ik zou nog steeds weigeren vanwege het potentieel voor slechte PR ($ _CLIENT gaat op Twitter en vertelt de wereld dat we down zijn omdat $ _PROVIDER incompetent is en kunnen hun SLA niet halen! '). Persoonlijk heb ik liever dat 10 kleinere, redelijkere klanten me $ 10k per maand betalen :-) - voretaq7