mboost-dp1
PBS A/S
Problemerne opstod sandsynligvis i forbindelse med den planlagte nedetid, idet der aldrig kom en klarmelding på NemID's driftstatusside, sådan som de normalt gør.Er det et journalistisk gæt eller et kvalificeret gæt?
Jeg var fint på Netbank med NemID inden nedbruddet igår.
Magten (2) skrev:Er det et journalistisk gæt eller et kvalificeret gæt?
En vurdering ud fra deres historik på deres driftsstatusside. Kigger du ned i listen, så er der en klarmelding i forbindelse med næsten alle planlagte nedetider, men ikke for den i går.
Fra lidt over kl. 14 i går ser det ud til de første meldinger dukker op om problemer: http://www.pokernet.dk/forum/problemer-med-nemidja...
Jeg synes generelt at det er et problem at udmeldinger om driftstatus ikke fungerer optimalt. Det gælder ikke kun nem-id, men f.eks. også hos bankerne og Skat.
Jeg ved godt der sidder nogle og knokler med at få det til at virke, men som bruger er det frustrerende at sidde i uvished.
De skal blot skrive:
1. Om det virker eller ej.
2. Hvis ikke det virker: Hvornår forventes det at virke, og hvis ikke tidspunktet kan estimeres: Hvornår kommer der en ny opdatering af status.
Jeg ved godt der sidder nogle og knokler med at få det til at virke, men som bruger er det frustrerende at sidde i uvished.
De skal blot skrive:
1. Om det virker eller ej.
2. Hvis ikke det virker: Hvornår forventes det at virke, og hvis ikke tidspunktet kan estimeres: Hvornår kommer der en ny opdatering af status.
og så skulle jeg lige til at skrive at det var gået ned igen.. men inden jeg fik skrevet færdig var det oppe igen..
Det var dog samme fejl som i går
Det var dog samme fejl som i går
java consol skrev:dk.pbs.applet.bootstrap.bootapplet
https://www.nemid.nu/dk-da/om_nemid/aktuelt/driftsstatus/ skrev:25. mar.
13:53 Al drift er OK
NemID kører uden driftsproblemer.
25. mar.
13:38 Log-in med NemID er ude af drift
Det er i øjeblikket ikke muligt at bruge NemID til log-in. Vi arbejder på at løse problemet.
Da jeg indsendte nyheden igår aftes var der ikke nogen nyhedskilder der havde skrevet noget.
Men DanID har nu udtalt til Version2 der kan være tale om et DDOS-angreb:
http://www.version2.dk/artikel/frygt-ddos-angreb-n...
http://www.version2.dk/artikel/nyt-nemid-nedbrud-s...
Men DanID har nu udtalt til Version2 der kan være tale om et DDOS-angreb:
http://www.version2.dk/artikel/frygt-ddos-angreb-n...
http://www.version2.dk/artikel/nyt-nemid-nedbrud-s...
kasperd (7) skrev:Med systemer i den størrelse kan man sagtens have valgt at fordele brugerne på separate servere.
For så vigtigt et system kører de forhåbentligt N+1 redundancy.
kasperd (7) skrev:For to brugere på hver deres server vil det ikke være overraskende, hvis fejl i systemet kun påvirker den ene.
Det kan ske, men det passer bare ikke godt med at problemet tog lang tid at løse.
Hvis man har 1 ud af N+1 servere med et problem, så tager man den ene ud - for load balanceren til ikke at forwarde til den - mens man troubelshooter.
Dengang jeg arbejdede ved Google var N+1 forbeholdt systemer som ikke var vigtige. Men N+1, N+2 og N+3 opsætninger er beregnet til systemer hvor brugere frit kan flyttes rundt. Det nytter ikke noget, hvis der er data hørende til hver bruger.arne_v (12) skrev:For så vigtigt et system kører de forhåbentligt N+1 redundancy.
Så er det man skal over i 2N løsninger. Men så får du et problem med opdatering af data. Hvis du vil have en garanti for at der stadigvæk kan udføres konsistente opdateringer af data med fejl på t replika, så skal du have minimum 3t+1 replika. Og algoritmerne til at bevare konsistensen er indviklede.
Den slags skal jo gerne ske af sig selv.arne_v (12) skrev:Hvis man har 1 ud af N+1 servere med et problem, så tager man den ene ud - for load balanceren til ikke at forwarde til den - mens man troubelshooter.
kasperd (13) skrev:Dengang jeg arbejdede ved Google var N+1 forbeholdt systemer som ikke var vigtige.
Det er også muligt at NemID er på N+2. Men jeg ville ikke blive overrasket over hvis det kun var N+1.
kasperd (13) skrev:Men N+1, N+2 og N+3 opsætninger er beregnet til systemer hvor brugere frit kan flyttes rundt. Det nytter ikke noget, hvis der er data hørende til hver bruger.
N+1 er helt almindeligt også i forbindelse med data.
kasperd (13) skrev:Så er det man skal over i 2N løsninger. Men så får du et problem med opdatering af data. Hvis du vil have en garanti for at der stadigvæk kan udføres konsistente opdateringer af data med fejl på t replika, så skal du have minimum 3t+1 replika. Og algoritmerne til at bevare konsistensen er indviklede.
Det er kun et problem med data som er så store at de er nødt til at være distriberede.
Det er helt standard med N+1 redundancy og N>=1 i web/app tier og N=1 i database tier.
Supporteret out of the box af standard software.
Nej. Det er et problem i alle systemer, hvor du ønsker redundans og garanti for at opdatering af data er konsistent. Hvis du vil have garanti for konsistent opdatering af data i tilfælde af t fejl er du nødt til at have 3t+1 replika, og det gælder om så dine data kun fylder en bit.arne_v (14) skrev:Det er kun et problem med data som er så store at de er nødt til at være distriberede.
kasperd (13) skrev:Den slags skal jo gerne ske af sig selv.arne_v (12) skrev:Hvis man har 1 ud af N+1 servere med et problem, så tager man den ene ud - for load balanceren til ikke at forwarde til den - mens man troubelshooter.
Det sker automatisk hvis serveren er helt nede (nede som at probe page ikke kan hentes).
Problemet er hvis den ikke er helt nede, men alligevel ikke fungerer.
Ja, det er altid der problemerne begynder.arne_v (16) skrev:Problemet er hvis den ikke er helt nede, men alligevel ikke fungerer.
Der er mange ting som kan gå galt i sådan et setup.arne_v (17) skrev:Alle app nodes taler med samme active database node som replikerer til passive database node.
Første dilemma er om ændringer skal replikeres til sekundær før man bekræfter opdatering til appen, eller om man godt må bekræfte til appen før sekundær har modtaget opdateringen.
Bekræfter man til appen før ændringen er replikeret, så har man inkonsistens hvis primær går ned uden at ændringen er blevet replikeret til sekundær.
Venter man med at bekræfte til appen indtil ændringen er replikeret, så er det sekundære replika et single-point-of-failure.
Og hvis kommunikationen mellem primær og sekundær fejler risikerer man at de begge er aktive samtidigt og laver ændringer på deres egen kopi af data som konflikter med ændringer på det andet replika.
kasperd (18) skrev:Venter man med at bekræfte til appen indtil ændringen er replikeret, så er det sekundære replika et single-point-of-failure.
Hvis sekundær eller forbindelsen til sekundær fejler, så er sekundær nede og primær kører videre uden den. Det er så uden redundans, men med N+1 så betyder en nede jo ingen redundans.
Database softwaren syncher selv sekundær op, når den kommer op eller får forbindelse igen.
kasperd (18) skrev:Og hvis kommunikationen mellem primær og sekundær fejler risikerer man at de begge er aktive samtidigt og laver ændringer på deres egen kopi af data som konflikter med ændringer på det andet replika.
Det er et potentielt problem. Men det er et kendt problem, hvor alle de store database leverandører har funktionalitet og anbefalinger til konfiguration for at undgå.
Årsagen til at kommunikationen fejler kan sagtens være en fejl på den primære. Hvis fejlen på den primære efterfølgende udvikler sig til et totalt nedbrud er ændringer som endnu ikke er replikeret til sekundær gået tabt.arne_v (19) skrev:Hvis sekundær eller forbindelsen til sekundær fejler, så er sekundær nede og primær kører videre uden den.
Kravet om 3t+1 replika for at håndtere t fejl er formelt bevist. Alle som laver løsninger med færre end 3t+1 replika har gjort det ved at lave antagelser om måden fejl opfører sig på. Hvis et eneste replika fejler på en måde som afviger fra de antagelser kan det betyde at systemet bryder sammen.
Ja, det betyder at alle løsninger med 2 eller 3 replika er i farezonen.
kasperd (20) skrev:Årsagen til at kommunikationen fejler kan sagtens være en fejl på den primære. Hvis fejlen på den primære efterfølgende udvikler sig til et totalt nedbrud er ændringer som endnu ikke er replikeret til sekundær gået tabt.
Hvis man i et 2 node setup mister sekundær uanset årsag og primær bliver ramt af noget der går ud over disk systemet, så kan man miste data.
kasperd (20) skrev:Kravet om 3t+1 replika for at håndtere t fejl er formelt bevist. Alle som laver løsninger med færre end 3t+1 replika har gjort det ved at lave antagelser om måden fejl opfører sig på. Hvis et eneste replika fejler på en måde som afviger fra de antagelser kan det betyde at systemet bryder sammen.
Meget interessant hvis man interesserer sig for den slags.
Det er imidlertid ikke noget som almindeligt bruges ved design af løsninger med databaser.
Og din pointe er?arne_v (21) skrev:Hvis man i et 2 node setup mister sekundær uanset årsag og primær bliver ramt af noget der går ud over disk systemet, så kan man miste data.
De må så betyde at enten synes designerne ikke at data på systemet er vigtige nok til at deres integritet skal være garanteret i tilfælde en enkelt maskine fejler. Eller også ved designerne ikke hvad de laver og foretager nogle implicite antagelser, uden selv at være klar over, hvad de er.arne_v (21) skrev:Det er imidlertid ikke noget som almindeligt bruges ved design af løsninger med databaser.
Hvis du skulle købe et system der replikerer dine data over to computere, ville du så ikke gerne vide hvilke antagelser producenten har gjort for at kunne designe en løsning som kun bruger to computere? Og vil du ikke gerne vide, hvad der sker med dine data, den dag det viser sig at antagelserne ikke holder?
Så det du siger er, at hvis alle replika fejler, så har man et problem? Det er de fleste personer jo i stand til at sige sig selv. Hvad der er lidt mindre intuitivt er, at man har et problem længe før alle replika fejler.arne_v (23) skrev:2 noder + 2 fejl = problem
Hvis man replikerede til 10 noder og man mistede forbindelsen til alle 10, fortsatte og disken røg, så havde man også et problem.
11 noder + 11 fejl = problem
Så snart en tredjedel er fejlet er det ikke længere muligt at opdatere data, hvis man vil garantere integriteten af data.
kasperd (24) skrev:Så det du siger er, at hvis alle replika fejler, så har man et problem? Det er de fleste personer jo i stand til at sige sig selv.
Det var det eksempel du kom med i #20.
kasperd (24) skrev:
Hvad der er lidt mindre intuitivt er, at man har et problem længe før alle replika fejler.
Så snart en tredjedel er fejlet er det ikke længere muligt at opdatere data, hvis man vil garantere integriteten af data.
Det kan jeg forstå.
Men det er tilsyneladende noget som stort set alle ignorerer.
Så jeg vil antage at den praktiske betydning er minimal.
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