M$ Redundans er ikke altid nok

at flere redundante udgaver burde have forhindret systemet i at gå ned.

Umiddelbart skulle man tro, at der med flere redundante systemer, menes flere uafhængige redundante systemer. Desvære ser det ud til, at ordet redundans ikke umiddelbart kræver uafhængighed. Det betyder, at to redundante systemer, også kan have redundante softwarefejl, fordi softwaren ganske enkelt er identisk.

Redundant, betyder hellerikke altid, at systemerne kører samtidigt, og tjekker hinanden. Det er ikke ualmindeligt, at der anvendes redundans, hvor der blot haves en "backup" der står klar til at overtage, når det ene system selv må erkende, at det er falit. Systemet tjekker altså sig selv (lader sig ikke tjekke af uafhængig program/eller kode), og lader så bare det hele swappe over til en anden computer, når der opdages uheld. Egentligt vil jeg hellere betragte et sådant system, som et automatisk backupsystem, der automatisk overtager. Imidlertid, er dette også, med samme kode, og kun når der opdages, at der er opstået fejl, og grund til at skifte til backupsystemet.

Redundans, betyder altså langtfra, at systemet er redundant i alle ender og kanter. Og det er ikke identisk med fejltollerant.

Skal redundans reelt fungere, er vigtigt at det er på flere uafhængige systemer - det betyder også, at de fysisk skal placeres forskellige steder, at de skal indeholde forskelligt hardware, og forskelligt operativsystem og kode. Softwaren, må have samme funktion, men ikke være skrevet af samme personer. Og der må ikke bruges ens moduler. Alle de steder, hvor noget gå igen, er det brud på uafhængig redundans princippet. I praksis, er systemer derfor ikke uafhængigt redundans, og normalt forstås med redundans blot, at man kopierer fejlene til flere afhængige systemer, der består af samme hardware og software. I nogle tilfælde, er de end ikke fysisk placeret bort fra hinanden, og på forskellige strømforsyninger.

De fleste større computere, har flere strømforsyninger, hvilket gør strømforsyningen redundant. Der er også flere tilslutninger, så de kan sættes eksempelvis på forskellige faser. Imidlertid, er ikke altid, at de er på forskellige faser, og hvis de er, er de ofte på samme sikring, og denne sikring er designet til at slå alle faser ud samtidigt. I princippet, bør de være på forskellige sikringsgrupper, og på forskellige HPFI afbrydere, således de er robuste, hvis en sikring går, eller hvis en HPFI afbryder slår fra. Skal det være meget sikkert, har mange dog en nødstrømforsyning, der fungerer her.

Moralen er, at redundans ikke er så meget værd. Det kan - i nogen grad - forhindre uheld, hvis en harddisk går, eller hvis noget hardware går i stykker. Men det forhindrer ikke softwarefejl, eller hardwarefejl, der skyldes design - eller fejltyper der på anden måde kan være kopieret mellem de redundante systemer. Eller, hvis at man fordi det var nemmest, har sat alt på samme gruppe.

En gang troede jeg, at redundans betød flere uafhængige systemer. Men jeg er blevet meget klogere. Der hvor der er flest fejl, er i software, og end ikke dette kræves udviklet uafhængigt af uafhængige programmører, når det er redundante systemer.

I stedet, betales gerne 50 gange mere for softwaren, uden de redundante dele er uafhængigt kodet. Oftest er det samme kode, på samme hardware, med samme operativsystem, oversat af samme compiler, brugt samme bibliotekssystemer, og kodet, sat op, og indstalleret, af samme personer, der har gjort de samme fejl.

De lever ikke op til kravet om uafhængig redundans.

Re: M$ Redundans er ikke altid nok

En gang troede jeg, at redundans betød flere uafhængige systemer.

Selv højt redundante systemer har det med at være afhængige af fælles ting - med vilje: Jeg har selv prøvet at skvatte over SSL-certifikater, der udløber, fordi "man" ikke lige har fået fornyet dem korrekt .... de løber typisk et år af gangen.

Ikke desto mindre havde nøjagtig det samme system ifølge CNN problemer også i 2008.

Hmmm.

Re: Re: M$ Redundans er ikke altid nok

Rumfærgen har fly-by-wire og er dybt afhængig af at kontrol systemet fungerede.
De første opsendelser benyttede 5 computere og et arbiterprincip, hvor de 4 af de 5 computere kontrollerede hinanden i et fail-safe/fail-operational princip. Hvs en kom frem til et forkert resultat, blev den stemt ude af de 3 andre. Hvis 2 samtidig fejlede, sørgede en tilfældighedsgenerator for at vælge de 2, som skulle styre. Hvis 3 i alt fejlede tog den 5 computer over. Den 5 (Backup Flight System) var forskellig fra de 4 andre mht. SW og programmeringssprog - ikke HW.
Se, det er et system, som ikke baserer sig på redundans alene.

Re: Re: Re: M$ Redundans er ikke altid nok

Rumfærgen har fly-by-wire og er dybt afhængig af at kontrol systemet fungerede.
De første opsendelser benyttede 5 computere og et arbiterprincip, hvor de 4 af de 5 computere kontrollerede hinanden i et fail-safe/fail-operational princip. Hvs en kom frem til et forkert resultat, blev den stemt ude af de 3 andre. Hvis 2 samtidig fejlede, sørgede en tilfældighedsgenerator for at vælge de 2, som skulle styre. Hvis 3 i alt fejlede tog den 5 computer over. Den 5 (Backup Flight System) var forskellig fra de 4 andre mht. SW og programmeringssprog - ikke HW.
Se, det er et system, som ikke baserer sig på redundans alene.

Det lyder som et mere gennemtænkt system, end de fleste andre redundante systemer. Alligevel, skal man passe meget på, for selvom computerne er med forskelligt hardware, og forskelligt software, så kan opstå fælles påvirkninger, specielt når de er placeret tæt på hinanden, som på en rumfærge.

Som eksempel, kan computere på jorden, der er anbragt samme sted, blive udsat samtidigt for elektromagnetiske påvirkninger, såsom lyn. I rummet, kan komme kosmisk stråling mv. der samtidigt kan sætte computere ud.

Det bedste er som regel, at deffinere en meget fast bestemt grænseflade for software, og så lade flere programmører følge eksakt samme specifikation til punkt og prikke. Dette giver ikke total uafhængighed, da specifikationen stadigt er ens. Men problemet reduceres til specifikation. Denne, kan bedre gennemskues og verificeres af flere uafhængige kilder, end den samlede software.

Hvis der er udviklet 3 uafhængige programmer af uafhængige programmører, der skal følge samme specifikation, og specifikationen er lavet så det er muligt at sammenligne resultaterne run-time, samt stemme en computer ude, så er muligt at opdage de fleste softwarefejl. Sker ens fejl, i flere computere, vil det oftest skyldes nogle ikke har fuldt reglerne, og stjålden kode samme sted fra, eller fra hinanden, og dermed ikke overholdt reglerne. Dette skal man naturligvis gardere sig imod, ved det dels er ulovligt, og søges umuligjort ved at programmørerne ikke fysisk må placeres sammen, eller kende hinanden, og de skal have forbud mod at anvende software fra 3. part, f.eks. downloaded fra nettet. Dertil kan man scanne programmernes dataflow strukturer, og opdage eventuelle algorithmer der ligner hinanden, for at tjekke, om der skulle ligge fejl et sådant sted. Dertil kan man have backup, i form af andre systemer, der kan løse samme opgaver, men måske er udviklet efter anden specifikation.

Idag gøres alt for lidt, for at opnå redundans i softwareudviklingen, på kritiske steder.

Re: Re: Re: Re: M$ Redundans er ikke altid nok

Den 5 (Backup Flight System) var forskellig fra de 4 andre mht. SW og programmeringssprog - ikke HW..

Her vil jeg jo nok også have valgt forskelligt HW. Hardware kan dog være ret dyrt til rumfærger, hvor der sættes langt større krav, end ved kommercielle systemer.

Ved kommercielle systemer, vil det være forholdsvis nemt at vælge en anden computer, med en anden processor og andet indstruktionssæt, samt andre fabrikater af komponenter, når der alligevel vælges anden operativsystem og compiler.

Endeligt kræves jo også redundans for de signaler der kommer ind, og for det som styres.

Der har været uheld med rumfærgen, fordi at noget af elektronikken var udskiftet, og gav et større antal data per sekund end tidligere. Denne del, har åbentbart været udskiftet for alle redundante dele, eller været placeret hvor der ikke var redundans. Typisk, kan det være data fra sensorer mv. og hvis der har været ekstra sensorer, har man måske skiftet alle, i stedet for at kun skifte nogle. Det kan så medføre, at det hele fejler, fordi fejlen gøres ens.

Re: Re: Re: Re: Re: M$ Redundans er ikke altid nok

Jeg forstår Jens Madsens forundring over brugen af begrebet redundans.
Det ser meget ud til, at der er en udbredt misforståelse omkring, hvornår der forefindes redundans I et system. Det er det Jens Madsen forklarer I sit indlæg, sådan som jeg ser det. Redundans er et centralt begreb indenfor udvikling af teknologi indenfor aviation (flyvning), idet man under flyvning ikke er I stand til at holde ind til siden, hvis man får et teknisk problem, men er nød til at fortsætte missionen, indtil den er tilendebragt eller afbrudt på en passende og sikker måde. Med andre ord, så betyder redundans indenfor aviation, at der til et givet system, der evt måtte svigte, forefindes en anden måde at udføre samme opgave. Denne alternative måde at udføre den samme opgave kan være et alternativt ens system eller et alternativt forskelligt system eller en helt anden procedure, der leder til samme mål.
Men hovedfilosofien I design af flyve teknologi er, at man ønsker at eliminere “single point of failure” så vidt dette er muligt. Dette betyder, at der ikke må forefindes et system I flyet som, hvis det svigter, vil gøre det umuligt at fortsætte med at løse opgaven. Dette er ægte redundans. Altså, at man fortsætter med at løse opgaven uanset hvilket system, der svigter. Dette mål har man næsten opnået I design af rumfærgens avionics, som Jens Madsen forklarer det I sit indlæg.
Desværre misbruges begrebet redundans I IT verden, hvor man ofte postulerer redundans uden at man, efter min mening, er I nærheden af ægte redundans. Se listen af eksempler I Jens Madsens indlæg, som jo slet ikke er en udtømmende liste. Det vil føre for vidt at gøre rede for hvor stort dette problem virkeligt er I dette korte indlæg.
Aviation er nok det område, hvor man historisk er kommet tættest på at opnå redundans indenfor en række områder, men jeg bemærker mig desværre også, at den noget ufuldstændige opfattelse af begrebet redundans, som hersker indenfor IT verden er på vej ind I aviation. Indførelse af mere og mere IT I flyvemaskiner har samtidigt introduceret "IT holdningerne" til redundans. Selvom der som udgangspunkt I flyvemaskiner ofte er 2-4 forskellige systemer, der kan gøre det samme, så kommunikerer disse systemer på det samme datanetværk, som nu bliver det svageste punkt I en flyvemaskine. Støj på dette datanetværk kan I princippet sætte de fleste systemer ud af drift på en gang.
Med hensyn til at forstå begrebet redundans er det vigtigt at gøre sig klart, at dette er forbundet med en klar definition af hvilke mål man har. Hvis jeg f.eks. Skal køre til købmanden 5 km væk og definerer mine mål således, at det er en forudsæting af dette kan gøres indenfor 20 minutter og jeg ønsker at udføre dette med min bil samtidigt med at have en redundant løsning for opgaven til en hver tid.
Har jeg redundans, hvis jeg har et reservehjul med?. Nej, det tager for lang tid at skifte hjulet I forhold til de definerede mål.
Har jeg redundans hvis jeg har en sammenklappelig cykel med I bagagerummet?
Ja, det har jeg muligvis, idet jeg formentligt ville kunne gennemføre missionen indenfor den definerede ramme selvom bilen bryder sammen.
I eksemplet med styring af flyveplanerne I USA har de tydeligvis ikke haft redundans, hvis målet har været, at kunne fortsætte driften af lufthavnene I tilfælde af systemsvigt.