Gå til innhold

Her er årsaken til at Vipps ble slått ut i helgen


Gjest Marius B. Jørgenrud

Anbefalte innlegg

Videoannonse
Annonse

Jeg virkelig gleder meg til dette skjer igjen den 23., 24., 25., 26. eller 31. desember  :dribble:

Nå unnvek de altså black friday med en dag.

 

</sarkasme>

 

Her er forresten en annen variant black friday som skjedde for 29 år siden:

 

 

tornado.jpg

 

 

 

Er det snart "belly up" for DNB, Evry og Telenor?

 

Jeg lurer også på om Telenor igjen klarer det kunststykke å ikke ha tilstrekkelig båndbredde for å ta unna noen skarve tekstmeldinger på nyttårsaften ??? Vi er i 2016 og snart 2017 tross alt. Og tekst tar svært lite plass. Forsøk f.eks. bare å komprimere en Notepad-tekstfil i ZIP-formatet. Tekst tar veldig lite plass nå med så moderne IT-infrastruktur. Det tok jo relativt liten plass selv på 80-/90-tallet.

 

</sarkasme2>

Endret av G
Lenke til kommentar

Normalt vil en ruter gjøre en reload når det ikke er mer minne igjen. Da vil man feile over. Vanlig ruting vil ikke feile over av en slik softvare bug når alt er normalt på controll planet men forwarding ikke fungerer. Da må det legges ekstra probing for sjekke kvalitet og ende til ende rekkevidde feks ip sla probing eller Pfr. Noe som ikke er vanlig.

  • Liker 1
Lenke til kommentar

Kan noen forklare hvordan en router kunne være en single point of failure?

 

Er ikke tilgjengelighet relativt viktig for et betalingssystem som dette? Hvis man har 12.000 kr på konto og 3-veis redundans (minimum for distribuert konsensus), så kan man jo la hver node prosessere transaksjoner for 4000 uten NOEN global konsensus.

 

Man får da også global konsensus i et slikt system selv om den ene noden er nede (pga routerproblem).

 

I et slikt oppsett, noe enhver idiot kan sette opp med en vanlig raft-implementasjon så KAN ikke en router ta ned systemet.

 

Kan noen vennligst forklare? Forklaringen som presenteres gir absolutt ingen mening.

  • Liker 1
Lenke til kommentar

Kjedelig sak å feilsøke uansett.

Sekundær vpn og samband slår nok ikke inn, før primære failer 100%.

Siden primære hadde minne feil. Så går noen transaksjoner igjen hele tiden. Derfor vill ikke vilkårene for belastning og 100% failure på primære være tilstede. Resultatet er mange feil på transaksjoner og at vilkårene for at redundanse skal slå inn, ikke er tilstede.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...