Alt ut for Altinn

[Shruggie]

Det er fremdeles ingen grunn til at alle i Norge skal trenge å logge seg på samme side samtidig. Selv om de tyvstartet ved å åpne ved midnatt i stedet for 08.00, så er hele konseptet så fantastisk dumt at det får alle seriøse systemarkitekter til å facepalme.

 

Send ut en kort SMS til registrert telefonnummer, eller en kjapp epost uten kritisk info. Bare skriv at du får igjen X.

 

Plutselig er det nesten ingen som trenger å logge inn til Altinn, og problemet er unngått.

[del_diablo]

Fordi som vi tidligere har prøvd å forklare deg: caching er elementært i

all systemutvikling, uavhengig av leverandør.

Men fyren du hiver ildtunger etter er jo enig med deg i dette. Poenget hans er at det allerede er en cache løsning i databasen, og at å legge på et lag til virker mer som å forsøke å drive symptombehandling i stede for sykdomsbehandling.

 

Det er ikke vanlig å snakke om HMS i forbindelse med informasjonssikkerhet og systemutvikling. Igjen formulerer du deg på en måte som skaper usikkerhet om hvorvidt du forstår hva det faktisk dreier seg om.

Det ER veldig vanlig å prate om HMS, spesielt den lille S, i systemutvikling. Vis man håndterer sensetiv informasjon så skal man prioritete den S enda mer.

 

Det har jeg aldri påstått. Jeg hevdet det var en feil i firmware, og så vidt jeg kan se har jeg rett. Det finnes ingen grunn til å tro at dette er software som kjører på Altinn sine servere.

Og her overser du den logiske aksinomen:

Firmware = Code, Firmware feil = Codefeil. Firmware er bare kode som vanligvis er noe tett til metallet, et moteord for å lage en praktisk definisjon på f.eks et skjermkorts egne kode for å fungere, og thats it.

Faktum er at vi VET at det krasket i fjord, og det krasjet i år. I år så kjøpte de noe for å unngå å fikse de grunnlegende probleme de hadde, og det feilet så katastrofalt at det er latterlig.

Hvorfor forsvarer du Altinn?

[The Red Devil]

Har lest over rapporten fra F5, og feilen ligger på altinn softwaret imo. pga at problemet er forutsaket pga reglene dei har satt opp på cache modulen av load balanceren.

 

Ut av forklaringen på rapporten, kan det se ut som om problemet her var at nokon var inne og oppdaterte reglene på eit live system, rett før problemet skjedde. Pga at feilen inntreffer når cache systemet hadde blitt startet, og brukeren deretter blei forwarded til ein annen side (som dog ikkje skulle ha blitt cached).

 

Hadde denne feilen vært i regel settet fra starten, skulle det ha blitt oppdaget under utvikling, og ikkje minst me skulle ha sett problemet tidligere i systemet vist det gjekk live med feilen. Den eineste muligheten for at dette var i systemet, er vist Altinn systemet inneholder "countless" redirects som skjer etter du logger inn, og at denne personen klarte å trigger ein av redirectene som ingen andre har brukt, dog sjansen for det er vel minimal.

 

 

Uansett kven sin feil problemet var, så er det ingen utvikler som kan sei at Altinn er eit bra eksempel på eit software system. Til den prisen det har kostet å utvikle dette systemet, så er det ein katastrofe. Ser ut som gutteklubben grei har gitt oppdraget til nokon i vennekretsen som igjen har fakturert med gaffel. For det er klart at både utvikler og drifter har tatt seg vann over hodet her.

 

-jeg stiller spørsmålstegn ved hvorfor en cache modul var nødvendig i første omgang, kanskje systemet er for komplekst (ref. bruk av mammutløsning fra microsoft)

Når du har ein viss trafikk mengde til eit system så må/bør du implementere caching på fleire ledd, gjør du ikkje dette så må server parken økest drastisk. Med det sagt, bruk av cache skal skje under sikre omstendigheter, og du skal være sikker på at vist informasjonen er personlig så blir den ikkje vist til andre personer.

 

Det har jeg aldri påstått. Jeg hevdet det var en feil i firmware, og så vidt jeg kan se har jeg rett. Det finnes ingen grunn til å tro at dette er software som kjører på Altinn sine servere.

Ein hardware load balancer kjører sin egen server, så dog var det jo ein av Altinn sine server

 

Joke aside, problemet var på regelsettet dei har satt til cache modulen, så feilen var software basert og ikkje hardware basert. Om feilen ligger hos dei som drifter serverene eller hos dei som programmerer Altinn, vet me ikkje. Det kommer ann på kven som hadde ansvaret for å sette opp regelsettet.

 

Eg vil tru dette er "testet" og satt opp av dei som programmerer Altinn, men me veit ikkje om feilen er relatert til forandringer gjort av dei som drifter, eller at dei for eksempel gjorde ein feil når dei la inn reglene på ein eller fleire av load balanserene.

 

Men fyren du hiver ildtunger etter er jo enig med deg i dette. Poenget hans er at det allerede er en cache løsning i databasen, og at å legge på et lag til virker mer som å forsøke å drive symptombehandling i stede for sykdomsbehandling.

Du kan ikkje basere systemet ditt på cache systemet som ligger i SQL systemet, pga at denne cachen vil/kan bli satt som invalid alt etter kva kommandoer du sender til systemet, eller flushet vist systemet må frigjøre minne.

[del_diablo]

Du kan ikkje basere systemet ditt på cache systemet som ligger i SQL systemet, pga at denne cachen vil/kan bli satt som invalid alt etter kva kommandoer du sender til systemet, eller flushet vist systemet må frigjøre minne.

 

Ergo: Vis SQL ikke kan brukes som høy yteksedatabase, og man har blitt påhivd 2 milliarder kroner, hvorfor bruker man fortsatt SQL vis ytelsen ikke er god nok?

[Terrasque]

Ergo: Vis SQL ikke kan brukes som høy yteksedatabase, og man har blitt påhivd 2 milliarder kroner, hvorfor bruker man fortsatt SQL vis ytelsen ikke er god nok?

 

Fordi at det er veldig få egnede, veltestede alternativer. Mange alternativer dropper ACID, er ganske nytt på markedet og derfor ikke nok testet til å basere et slikt prosjekt på, eller har mye værre ytelse enn SQL databasen.

 

Når det er sagt, så kan man santnok skalere en SQL database, men det er noe som må være gjort igjennom hele designen fra begynnelsen av. Og, med intelligent caching kan man gi en i praksis ytelsesforbedring på 10x-100x med lite ekstra maskinvare. Og det er noe man faktisk kan legge inn på et senere tidspunkt.

Endret 1. april 2012 av Terrasque

[JohndoeMAKT]

Og når du har et så lite datasett at du kan pregenerere alle subset som noen gang kommer til å blir etterspurt er det også veldig lett å få stabil og predictable ytelse på den delen av systemet.

[The Red Devil]

Ergo: Vis SQL ikke kan brukes som høy yteksedatabase, og man har blitt påhivd 2 milliarder kroner, hvorfor bruker man fortsatt SQL vis ytelsen ikke er god nok?

Du bør nok lese opp litt meir angående korleis SQL fungerer, og kva limitasjoner dei forskjellige database systemene har, og ikkje har, (eg. Oracle, SQL Server, MySQL etc.)

 

Det er ingen som seier at SQL ikkje fungerer, eller at det ikkje kan levere på ytelse til eit vist punkt. Så framt du lager database modellen korrekt så kan SQL skalere bra opp til eit punkt.

 

Problemet er når du når det punktet så er det som regel MYE billigere å legge til cache systemer enn å hive hardware på problemet.

 

Dette kan være vist du har ein dyr join query, eller vist for eksempel det er mye data (record set) i tablet.

 

Det er ein grunn til at man har sharding... Du bruker ikkje sharding fordi du "liker" det, siden det bryter med alle prinsipper med normalization og kan være eit helsiken å jobbe med, men pga at det fungerer når du har mye data. I.e. low cost solution.

 

Du kommer bare så langt med master-master sammen med read only slaves systemer. Tilslutt så må du starte og dele opp databasen over fleire systemer slik som dette (i.e. master-master + read only slaves), og i fleste tilfeller så må du og starte og sharde opp dei største "table" slik at du kjører eit "table" over fleire slike systemer.

 

Det er noko heilt forskjelligt å drive utvikling for eit system som skal kjøre på 1 server, kontra eit som skal kjøre på eit par servere, til eit system som skal kunne scalere mellom 50-500 server instances alt etter load. Når du kost effektivt kan spare opp til eit par millioner i server kostnad i måneden på å bruke caching systemer så er det ein "no brainer" for eigerene av selskapet.

[del_diablo]

Jeg ser en masse bla bla bla fordi dere NEKTER å innse problemet: Hva om accenture har dreti på draget, og databasen de har valgt ikke skalerer pga platformsens mangel på f.eks minnehåndteringsvalg?

[Del]

Det er mulig å bevise at en algoritme er uten feil i alle tilfeller, helt klart at du ikke kan teorien din. Gödel sier heller ikke at det er umulig, men derimot umulig under noen omstendigheter, men mulig under andre. Vi gjør dette hele tiden når vi lager parallelle programmer. Modellen vår (algoritmen om du vil) vil være helt feil fri noe som lett kan bevises.

 

edit: kilde: http://en.wikipedia....al_verification

Hm, er du sikker på at du forstår hva det vil si om det aksiomatiske systemet du baserer beviset på ikke er konsistent? Uansett, det blir av filosofisk art. For alle praktiske formål vil du aldri komme unna menneskelig feil. Uansett hvor sikker du er på at algoritmen gjør det den skal kan du aldri være sikker. Dette bør være relativt lett for deg å forstå.

-jeg stiller spørsmålstegn ved hvorfor en cache modul var nødvendig i første omgang, kanskje systemet er for komplekst (ref. bruk av mammutløsning fra microsoft)

Når du har ein viss trafikk mengde til eit system så må/bør du implementere caching på fleire ledd, gjør du ikkje dette så må server parken økest drastisk. Med det sagt, bruk av cache skal skje under sikre omstendigheter, og du skal være sikker på at vist informasjonen er personlig så blir den ikkje vist til andre personer.

Tror vi er enige her, men kan tilføye at jeg setter et stort spørsmålstegn ved hvorfor løsningen trenger to rack-skap. Hvis folk skal sjekke selvangivelsen, hvor store datamengder trenger det å være hvis man implementerer dette på en effektiv måte. Jeg vil tro du kan holde alt i minne på en x86 node hvis du gjør dette smart. Distribuering burde også være meget enkelt, du kan nærmest trivielt dele opp i landsdeler, og isolerer systemene fra hverandre. Når jeg sier at jeg stiller spørsmålstegn ved behovet for cachemodulen fra F5, så er dette en kraftig understatement. Å gå inn på hvordan man kunne implementert mer effektivt blir en lang diskusjon, men jeg kan nøye meg med en enkel observasjon. De fleste var kun interessert i å se på selvangivelsen/skatteoppgjøret, det trenger man ingen fet web-interface eller store datamengder for.