SE515348C2 - Processorredundans i ett distribuerat system - Google Patents

Description

25 30 35 . . - - e» 5152 348 mellan reparation är önskvärt och medger att reparation kan ut- föras på arbetsdagar (måndag till fredag) och på arbetstid (fràn 08.00 till 17.00) samt medger schemalagt underhåll. Dessa krav leder till att telekommunikatíonssystemet måste kunna to- lerera att en processor går ned och att, innan den har repare- rats, även en andra processor tillåts att gå ned men att syste- met skall kunna tolerera detta och fortfarande vara I det värsta fallet, havererade processorerna har reparerats, driftsdugligt. och innan de första andra skall systemet kunna tolerera att även en tredje, fjärde och tillkommande processo- rer gàr ned, men att systemet fortfarande skall vara tillgäng- ligt trots de trasiga processorerna.

Amerikanska patentskriften 4 710 926 avser ett felåterhämt- ningsförfarande i ett distribuerat processorsystem enligt vil- ket förfarande reservprocessorer tar över trasiga processorers funktioner. En reservprocessor tjänstgör som ersättare för en eller flera aktiva processorer. När en reservprocessor tas i drift tjänstgör den inte längre såsom reservprocessor för någon annan processor i systemet. Vid felåterhämtning överförs alla funktioner som exekverar på den trasig processorn till reserv- processorn. Den gamla reservprocessorns funktion att vara re- servprocessor överförs till en andra reservprocessor i systemet.

Detta kända system kräver således två eller flera reservproces- sorer. När en reservprocessor är inaktiv utför den inte nägra jobb. När den aktiveras börjar den utföra jobb - förutsatt att den fungerar d v s inte uppvisar nägra fel. Det är nödvändigt att köra testprogram som verifierar att reservprocessorerna fungerar. Detta omnämns dock inte patentskriften.

Det amerikanska patentet 4 412 281 beskriver ett distribuerat, feltolerant, rekonfigurerbart signalbehandlingssystem som inne- fattar många identiska, med varandra förbundna sub-systemele- ment som delar på det stora behandlingsjobbet. Sub-system- elementen är redundant hopkopplade med varandra med dubbla bus- sar. Vissa sub-systemelement tjänstgör som reservsystemelement och är redo ta över de jobb som utförs pá ett trasigt sub- H. i. 10 15 20 25 30 35 - - . | | u 5135 348 systemelement. Ett reservsub-systemelement har även till upp- gift att utföra kontroll av alla de egna funktionerna för att verifiera att dessa fungerar. Genom att periodiskt rotera re- servsub-systemelement och aktiva sub-systemelement säkerställer ett distribuerat operativsystem att samtliga sub-systemelement utför den nämnda kontrollen av de egna funktionerna, varvid även mindre fel kan detekteras. Trasiga element i sub-systemet tas ur drift och ersätts med ett reservelement utan att syste- met går ned.

Signalbehandlingssystemet använder således reserv sub-system- element som inte deltar i de övergripande behandlingsuppgifter- na. Den metod som används för rekonfigurering när ett trasigt element detekteras och byts ut mot ett reservelement, utnyttjar distinkta kontaktdonadresser för varje element i systemet. En kontaktdonadress associeras med en virtuell adress, som ersät- ter kontaktdonadressen när ett feltillstånd detekteras.

SAMMANFATTNING AV UPPFINNINGEN Ett ändamål med uppfinningen är att tillhandahålla en metod för automatisk återhämtning från multipla permanenta fel i proces- sorer i ett distribuerat processorsystem använt i en applika- tionsmiljö i ett telekomsystem som har höga krav på tillgäng- lighet samtidigt som telekomsystemet skall medge systemunder- håll, vare sig detta är planlagt eller ej.

Ett annat ändamål med uppfinningen är att utnyttja tillgängliga processorresurser samtidigt som uppfinningen medger en hetero- gen processormiljö, till följd dels av införande av ny teknolo- gi i ett system som växer med tiden och dels av de enskilda krav som ställs av olika delar av en applikation som kör på prOCeSSOISyStemet . Ännu ett ändamål med uppfinningen är att tillhandahålla en me- tod för snabb återhämtning i händelse av att flera processorer går sönder i ett distribuerat processorsystem som används i en telekomsystemmiljö genom att tillhandahålla en initial konfigu- rering av samtliga processorer och genom att tillhandahålla, för varje processor i systemet, en katastrofplan som skall an- lO 15 20 25 30 35 . . . . f» H- ..= f f 515 348 4 vändas i händelse av att ifrågavarande processor går sönder. En katastrofplan är det organ med vars hjälp mjukvaruobjekt, som finns installerade på en trasig processor, distribueras till ett antal processorer i systemet så att lasten delas mellan prOCeSSOrErna . Ännu ett ändamål med uppfinningen är att tillhandahålla nya ka- tastrofplaner för systemet med fungerande processorer, av vilka några på sig kan ha installerade mjukvaruobjekt från en trasig processor, för att på så sätt förbereda systemet för snabb återhämtning i händelse av att ännu en processor i systemet går sönder. Ännu ett ändamål med uppfinningen är att tillhandahålla en me- tod av ovanstående slag vilken tar tillbaka systemet till dess ursprungliga konfigurering av processorer och mjukvaruobjekt när systemets trasiga processor eller trasiga processorer efter reparation eller utbyte sätts in i systemet igen. Ännu ett ändamål med uppfinningen är att tillhandahålla en mjukvarumodell som medger att mjukvaruobjekt kan flyttas från en trasig processor till en fungerande processor genom att mjukvaruobjekten omstartas på den fungerande processorn. En mjukvarumodell kan också döda ett mjukvaruobjekt som finns in- stallerat på en processor och kan omstarta mjukvaruobjektet på en reparerad, tidigare trasig, processor som har satts tillbaka i systemet. Det sistnämnda ändamålet inträffar i första hand när systemet återgår till sin initial konfigurering och det på de fungerande processorerna finns installerade objekt som skall lämnas tillbaka till de reparerade processorerna.

I enlighet med uppfinningen skapas en modell av telekommunika- tionssystemet, vilken modell innefattar en hårdvarumodell av de styrande processorerna och av den styrda hårdvarutrustningen samt även en mjukvarumodell som stöder och passar i hårdvarumo- dellen i telekommunikationssystemet.

I enlighet med uppfinningen används en första algoritm för att räkna ut katastrofplanerna för var och en av de fungerande pro- H. i- 10 15 20 25 30 35 ~ « A . m -515 348 S cessorerna antingen med ledning av den initiala konfigurationen eller med ledning av någon av de konfigurationer som förekommer efter det att ännu en processor har gått sönder.

I enlighet med uppfinningen används en andra algoritm som med ledning av en aktuell konfiguration beräknar en deltakonfigura- tion, som om den tillämpas på den aktuella konfigurationen, ger tillbaka den initiala konfigurationen av systemet.

I den mjukvarumodell som används för mjukvaruobjekten finns inga konfigurationsberoenden inkapslade i mjukvaruobjekten vil- ket gör att mjukvaruobjekten kan flyttas från en processor till en annan i vilken processorkonfiguration som helst.

KOÉT BESKRIVNING AV RITNINGARNA En belysande utföringsform av uppfinningen kommer att beskrivas nedan i anslutning till de bifogade ritningarna, i vilka Fig. 1 är ett blockschema som visar ett distribuerat pro- cessorsystem i en initial konfiguration, Fig. 2 är ett blockschema som visar processorsystemet i Fig. l i en aktuell konfiguration efter det att en av processorerna gått sönder, Fig. 3 är ett blockschema av processorsystemet i Fig.1 i en andra aktuell konfiguration efter det att två pro- cessorer gått sönder, Fig. 4 är ett flödesschema som visar metoden i enlighet med uppfinningen, Fig. 5 är ett blockschema av ett distribuerat processorsys- tem i vilket vissa av processorerna styr hârdvaruutrustning, Fig. 6A är en schematisk vy av ett modulariserat mjukvaruob- jekt, Ne e; lO 15 20 25 30 35 u UH 515 348 6 Fig. 6B-D är blockscheman av visande tre olika typer av mjuk- varuobjekt, Fig. 7 är ett blockschema som visar hur hàrdvaru- och mjuk- varumodellerna i enlighet med uppfinningen passar i hop i en enda modell av telekommunikationssystemet, och Fig. 8 är ett blockschema som visar hàrdvarumodellen i en- lighet med uppfinningen.

DETALJERAD BESKRIVNING AV UPPFINNINGEN P2, P3 Proces- I Fig. 1 visas ett antal distribuerade processorer P1, och P4 vilka kommunicerar med varandra över ett nät N1. sorerna bildar del av ett ej visat telekommunikationsnät. Nätet N1 kan bilda en del av det nämnda ej visade telekommunikations- nätet. Varje processor innehåller en processorenhet PE och min- ne M. Mjukvaruobjekt 1, 2, 3 18 är installerade på pro- cessorerna; objekten 1, 2, 3 pá processor Pl, objekten 4-7 på processor P2, objekten 8-12 på P3 och objekten 13-18 på P4.

Mjukvaran för en applikation som kör i telekommunikationsnätet innefattar mjukvaruobjekt (Fig. 6B-D), vilka ingår i mjukvaru- moduler (Fig. 6A). De modulariserade mjukvaruobjekten är allo- kationsoberoende objekt vilka kan förflyttas fritt mellan pro- cessorerna. Ett modulariserat mjukvaruobjekt år oberoende av övriga modulariserade mjukvaruobjekt. Ett mjukvarurobjekt inne- håller typiskt en process och persistent data. Persistent data är data som överlever en omstart av mjukvaruobjektet. Mjukva- ruobjekt kan kommunicera med varandra. Ett av en applikation begärt jobb involverar typiskt många mjukvaruobjekt på olika processorer och exekveras av vissa eller av alla processer. Ap- plikationen känner inte till hur mjukvaruobjektena är distri- buerade på de olika processorerna. Modulariserat persistent da- ta kan vara lagrat i en databas. På samma sätt som processor- systemet är distribuerat kan också databasen vara distribuerad över ett antal minnen M på många processorer, företrädesvis på P2, P3 och P4. Dessa data- DB3 och DB4 och innefattar minnena i samtliga processorer P1, baspartitioner betecknas DB1, DB2, . | » - n 10 15 20 25 30 35 . . . . ~ . 515 348 7 ett arbetsminne (RAM). Ur en applikations synpunkt är databa- sens distribuerade natur transparent. Persistent data måste kunna lagras på säker sätt. Detta kan åstadkommas genom konven- tionell backup-teknik, t ex genom att lagra datat på en skiva.

Ett nytt och föredraget alternativ är emellertid att lagra en spegelkopia av varje modulariserat mjukvaruobjekt i en databas- partition på en processor som är skild från den på vilken ob- jektet är installerat. Närmare bestämt lagras spegelkopian av varje modulariserat mjukvaruobjekt i databaspartitionen på den processor som utpekas i katastrofplanen för den processor på vilken det modulariserade mjukvaruobjektet, originalet, exekve- rar. På detta sätt kan kopior av det modulariserade persistenta datat lagras på säkert sätt på en annan processor i händelse av den processor på vilken originalet finns lagrat går sönder.

Det sätt på vilket objekten 1-18 är distribuerade på processo- rerna P1-P4 kallas den initiala konfigureringen av det distri- buerade processorsystemet och visas i bifogade Tabell 1, ur vilken framgår att objekten 1, 2 och 3 är installerade på pro- cessorn Pl.

Den initiala konfigureringen får inte försvinna om någon pro- cessor går sönder. Av denna anledning lagras den initiala konfigurationen och spegelkopian av denna på det ovan beskrivna sättet. I stället för att implementera den initiala konfigura- tionen i form av en tabell kan den implementeras i form av så (1,2), (1,3) den information som framgår ur den första raden i Tabell 1. kallade par. Exempelvis motsvarar paren (1,1), För att återhämtningstiden för processorsystemet, och därför även av telekommunikationssystemet, skall vara kort om en pro- cessor går sönder skall det finna en katastrofplan för varje processor som går sönder. Eftersom man inte kan förutse vilken processor som går sönder måste det finnas en katastrofplan för varje processor. En katastrofplan innehåller direktiv avseende de processorer till vilka mjukvaruobjekten på den trasiga pro- cessorn skall flyttas. En katastrofplan, visad i Fig. 2 utpekar de processorer till vilka de på processorn P1 installerade ob- jekten skall flyttas i händelse av att processorn P1 går sön- 10 15 20 25 30 35 1.- .H v n n» .H1 a. n . i t, ru | u a | n ia v . ». p»: e u a o »nu n. _ a. a f. f- n. i | -~ fi . æ Q æ 8 u . f > H i H n der. En annan katastrofplan innehåller information som talar om vart de pá processorn P2 installerade objekten skall flyttas om P2 går sönder. På likartat sätt finns en katastrofplan som skall följas om processor P3 går sönder. Denna katastrofplan visas i Tabell 4. Slutligen finns en katastrofplan, Tabell 5, som tar hand om det fall som inträffar i händelse av att pro- cessor P4 går sönder.

Processor P1 qår sönder Antag, att processor P1 går sönder. Processorsystemet måste återhämta sig snabbt från felet och därför skall de på proces- sorn P1 installerade mjukvaruobjekten 1, 2, 3 flyttas över till processorerna P2 och P4 i enlighet med katastrofplanen för P1.

Närmare bestämt skall mjukvaruobjekten 1 och 3 flyttas till processorn P2 och mjukvaruobjektet 2 skall flyttas till proces- sorn P4. Detta àstadkoms genom att mjukvaruobjekten 1-3 tas bort från processorn P1 och genom att man på processorn P2 ska- par och startar mjukvaruobjekten 1, 3 och på processorn P4 skapar och startar mjukvaruobjektet 2. Detta kräver givetvis att exekveringskapacitet finns tillgänglig på processorerna P2 och P4. Finns inte sådan kapacitet tillgänglig kan systemet in- te återhämta sig från processorfelet. I det följande antas att den nödvändiga processorkapaciteten finns tillgänglig och att systemet således återhämtar sig från felet. Systemet kommer nu att ha den kofiguration som visas i Fig. 2 och Tabell 6. Utgå- ende fràn denna konfiguration, vilken nu kallas den aktuella konfigurationen, måste nya katastrofplaner skapas för att sys- temet snabbt skall kunna återhämta sig om någon av de övriga processorerna går sönder. För detta ändamål framställs nya ka- tastrofplaner vilka ger direktiv om till vilka processorer de på en trasig processor installerade mjukvaruobjekten skall flyttas. Eftersom man inte kan förutsäga vilken av de tre driftsdugliga processorerna P2-P4 som kommer att gå sönder är det nödvändigt att skapa katastrofplaner för var och en av de driftsdugliga processorerna. Tabell 8 är den nya katastofplanen (CP-P2') (CP-P3') för processor P3 och Tabell 10 den nya katastrofplanen (CP-P4') för processor P2, Tabell 9 den nya katastrofplanen för processor P4. . v » - »- 10 15 20 25 30 35 »nn m, n n nn ...in -ß I n n' nn n n n n n nn n n» n n n n n n n n- h nn. =>= n. f n , nn cf-r-n n n n n = n n n n i n »n , U n På samma sätt som de ursprungliga katastrofplanerna lagras de nya katastrofplanerna och deras spegelkopior på det ovan be- skrivna sättet.

Det bör observeras att framställningen av nya katastrofplaner för den aktuella konfigurationen sparar minne jämfört med det följande teoretsikt tänkbara schema; antag att systemet består av fyra processorer och att systemet är så designat att det to- lererar att två processorer går sönder. Eftersom man inte kan förutse vilken processor som går sönder först och vilken pro- cessor går sönder som nummer två, måste man skapa lika många katastrofplaner som antalet olika sätt på vilket två element kan väljas ur en grupp av fyra element. Dessa katastrofplaner måste lagras i databasen. Således mäste tjugofyra katastrofpla- ner skapas och lagras. Denna lagring kräver mycket minnes- utrymme. Minnesutrymmet växer snabbare än exponentiellt med an- talet processor systemet kan tolerera gå sönder.

Under perioden från det att systemet återhämtat sig fram till dess att nya katastrofplaner utarbetats och lagrats i databasen är systemet sårbart. Under denna period får inga processorer gå sönder. Skulle en processor haverera under denna period kommer att systemet inte att vara tillgängligt.

När en processor Pl efter att ha tagits bort och reparerats åter installeras i systemet, skall systemet återgå till den initiala konfigurationen. Detta kan ske antingen genom att döda alla mjukvaruobjekt i den aktuella konfigurationen och genom att skapa och starta alla mjukvaruobjekt på processorerna i systemet. I den föreslagna utföringsformen av uppfinningen dö- das först endast de objekt som flyttats bort fràn den första processorn och som nu exekverar på andra processorer. Därefter äterskapas och startas dessa på processorn Pl. För att hitta dessa objekt skapas en deltakonfigurationstabell genom att sub- trahera den initiala konfigurationen från den aktuella konfi- gurationen med uteslutande av processorn Pl. Genom att subtra- hera Tabell 1 från Tabell 6 erhålls den i Fig. 7 visade delta- konfigurationen. Den rad som avser den trasiga processorn Pl .bn n: 10 15 20 25 30 35 u» x» u o I. m., i» . s .i .n n f n | n an v » v» nu: I n . 1 »vn :vs ~f » .- ;« :u- = . 1 n s. u f I f 1 . å. , .. ingår inte i subtraktionen. Deltakonfigurationen visar att ob- jekten 1 och 3 på processorn P2 och att objektet P2 på pro- cessorns P4 skall dödas på de respektive processorerna. Däref- ter skall de återskapas och startas på den reparerade pro- cessorn Pl. När objekten återskapats kommer systemet att köra på samma sätt som det gjorde i den initiala konfigurationen och systemets återhämtiningstid blir kort.

Processor Pl havererar och där efter havererar processor P2.

I det följande exemplet antas att processorn Pl går sönder och därefter att processorn P2 går sönder. Med anknytning till det föregående exemplet antas först att systemet är i drift med samma konfiguration som i Fig. 1, att katastrofplaner har ska- pats för var och en av processorerna Pl-P4, att processorn P1 havererar, att mjukvaruobjekten på processorn Pl flyttas över till de driftsdugliga processorerna i enlighet med katastro- fplanen i Tabell 2, att systemet återhämtar sig och är i drift, att nya katastrofplaner skapas för processorerna P2, P3 och P4, att processorn P1 tas bort och lämnas till reparation. Nu antas att processorn P2 havererar. Således skall den nya katastro- fplanen som hör ihop med processorn P2, d v s den nya kata- strofplanen i Tabell 8, följas. Enligt denna katastrofplan skall objekten 1, 3 och 4 flyttas till processorn P3 och objek- ten 5-7 skall flyttas till processorn P4. På samma sätt som tidigare tas mjukvaruobjekten på processorn 2 bort och flyttas över till processorerna P3 och P4. Systemet kommer nu att vara i funktion och köra med den konfiguration som visas i Fig. 3 och Tabell ll. I enlighet med uppfinningen är det nu nödvändigt att utarbeta nya katastrofplaner för var och en av processorer- na P3 och P4.

Under perioden från processorns P2 haveri till det att nya ka- tastrofplaner för processorerna P3 och P4 har utarbetats och lagrats i systemet kommer systemet vara sårbart. Om således en- dera P3 eller P4 havererar kommer systemet att vara otillgäng- ligt. Nu antas att detta inte inträffar. Istället är systemet i drift med den konfiguration som visas i Fig. 3 och Tabell 11. nu .. 10 15 20 25 30 35 ff- 1 - n 1. -,.~ f- | ff z w» 1 s n . v f v nu r _ v 1 : v u I n v . u - I I - ,-V - - I » » 1 » - -~ v e = ; - | - s « s 1-1. u = .f a 1. n Q Nu tas processorn P2 bort från systemet och lämnas till repara- tion. Därefter antas att processorerna Pl och P2 blir repare- rade och att de sätts tillbaka in i systemet. Det kommer nu att bli nödvändigt att döda objekten 1-7 och processorerna P3 och P4 och att återskapa och starta dem på sina respektive usprung- liga processorer Pl och P2. Genom att använda en deltakon- figuration, som erhålls genom att subtrahera den initiala kon- figurationen från den aktuella konfigurationen i Fig. 1, med undantagande av de trasiga processorerna Pl och P2 denna gång, kommer de objekt som måste dödas identifieras; i detta fall 1- 7. Närmare bestämt skall objekten 1, 3, 4 på processor P3 och objekten 2, 5, 6, 7 på processorn P4 flyttas över. Det sätt på vilket dessa objekt skall distribueras på processorerna Pl och P2 ges av den initiala konfigurationstabellen. Således skapas och startas objekten 1, 2, 3 på processorn P1 och objekten 4-7 skapas och startas på processorn P2. Systemet har nu återhämtat sig från inkopplingen av de två reparerade processorerna och antas nu vara i drift.

I de ovanstående exemplen har ett processorsystem med fyra pro- cessorer beskrivits. Uppfinningen är lika väl tillämpbar på processor system som innehåller två, tre, fem eller flera pro- cessorer. I det sista exemplet beskrevs ett processor system som tolererade två processorhaverier. Uppfinnings förfarandet är lika väl tillämpbart på processorsystem som tolererar tre eller flera processorhaverier. Varje gång en processor havere- rar flyttas dess mjukvaruobjekt till andra funktionsdugliga processorer i systemet och nya katastrofplaner för de funk- tionsdugliga processorerna skapas. Det sista exemplet illust- rerar att ett av fyra processorer bestående processorsystem kan vara i drift med 50% av processorerna havererade. Applikationen kommer fortfarande att exekvera ehuru med ett nedsatt kapaci- tet. Om processorsystemet är en väljare i en telefonstation kommer telefontrafiken fortfarande att vara i gång och spärr kommer att inträffa vid låg trafikvolym. Detta är ett nytt och unikt särdrag som inte finns i någon av de ovan nämnda ameri- kanska patenten och, såvitt sökanden är bekant, har ingen tidigare kunnat åstadkomma detta. .un- 10 15 20 25 30 35 | u : | n 515 348 12 En första algoritm används till att skapa katastrofplaner fràn den initiala konfigurationen i det fall att en första processor havererar eller från den aktuella konfigurationen i det fall att en tillkommande processor havererar. Den första algoritmen innehåller parametrar som avser kapaciteten för en processor, parametrar som avser storleken av minnet av en processor, para- metrar som avser hur mycket processorkapacitet (maskincykler per process som skall exekvera) och minne de enskilda flyttade objekten erfordrar, samt parametrar avseende tjänstens kvalité.

En andra algoritm används för att återföra systemet till dess initiala konfiguration. Denna andra algoritm har redan beskri- vits ovan och kallades för delta konfiguration.

Olika metoder kan användas för att detektera en trasig proces- sor, t ex "hjärtslagsmetoden" i enlighet med den ovan nämnda amerikanska patentskriften 4 710 926. En föredragen metod i ett typiskt telekomnät är emellertid att övervaka de länkar som kopplar ihop processorerna med varandra i nätet Nl. I samband med de tvâ ovan beskrivna exemplen beskrevs att mjukvaruobjekt som fanns installerade på en havererad processor överflyttades till två processorer. Naturligtvis kan den havererade proces- sorns objekt även distribueras pà tre eller flera processorer i systemet. I undantagsfall kan samtliga mjukvaruobjekt flyttas över till en enda processor i det fall att systemet består av två driftsdugliga processorer och den ena av dessa havererar.

När systemet är i drift är alla processorerna är driftsdugliga och har mer kapacitet och mer minne än vad som erfordras för att de skall utföra sina jobb med beräknad kapacitet, d V s de skall ha kapacitet och minne över för att ta över objekt från en eller flera processorer och för att ta över applikationsjobb som är under exekvering. På så sätt säkerställs att samtliga processorer är driftsdugliga och inget testprogram behöver kö- ras för att verifiera detta. Vidare kommer systemets kapacitet att överskrida den beräknade kapaciteten, vilket betyder att systemet kommer att ha "reservkapacitet" som kan användas för att ta hand om ytterligare applikationsjobb; det finns ingen 10 15 20 25 30 35 =a -H- 515 348 13 död "reserv"-kapacitet. För applikationen kommer en havererad processor endast medföra att systemet kapacitet nedsätts; have- riet kommer inte att döda systemet.

Såsom ett alternativ till att dimensionera systemet med en ak- tiv "reserv"-kapacitet som kan användas för att ta hand om tillkommande applikationsjobb, kan systemet designas med ingen aktiv "reserv"-kapacitet och med samtliga processorer arbetande med dimensionerad kapacitet. När en processor havererar kommer systemet att arbeta med nedsatt kapacitet.

Fig. 4 är ett flödesschema som visar de metodsteg som utförs i enlighet med uppfinningen. Det finns alltid en initial konfigu- ration i vilken samtliga modulariserade Mjukvaruobjekt är mappade på enskilda processorer. Den initiala konfigurationen skapas av systemsäljaren eller systemoperatören och lagras i systemet. Detta anges i ruta 20. Därefter skall katastrofplaner skapas i enlighet med den första algoritmen. Det skall finnas lika många katastrofplaner som processorer i systemet. Vidare skall spegelkopior av persistenta databasobjekt skapas. Detta anges i ruta 21. I en föredragen utföringsform skapar varje processor sin egen katastrofplan, d v s den katastrofplan som systemet skall använda i händelse av processorn havererar. Åt- gärden säkerställer att arbetet med att skapa katastrofplanerna blir fullständigt distribuerat. Därefter havererar en proces- sor, ruta 22. Mjukvaruobjekten på den havererade processorn skall flyttas över till driftsdugliga processorer med utnytt- jande av katastrofplanen för den havererade processorn. Med uttrycket "flytta över" objekt avses att nya kopior av mjukva- ruobjekten på den havererade processorn skapas och startas på de processorer till vilka de skall flyttas över i enlighet med katastrofplanen. Detta anges i ruta 23. Ruta 23 representerar således systemets återhämtning från den havererade processorn.

Systemet är nu i drift och en ny konfiguration, benämnd den ak- tuella konfigurationen, uppstår. Den aktuella konfigurationen lagras också i ett minne av en distribuerad processor. Medan systemet är i drift skapas nya katastrofplaner för de funk- tionsdugliga processorerna, ruta 24. Nu har systemet ätervunnit sin förmåga att motstå ett nytt processorhaveri. Även spegelko- . . : . H 10 15 20 25 30 35 515 348 14 pior av de ny katastrofplanerna lagras i databasen. Om en ny processor havererar sker återgång till operation 22, visat av pilen 25. Därefter repareras den eller de havererade processo- rerna ruta 26, och sätts tillbaka i systemet, ruta 26. Om två eller flera processorer har havererat antas att de repareras och sätts tillbaka i systemet samtidigt. Teoretiskt sett är det och åt naturligtvis möjligt att reparera havererade processorer en en åt gängen och att de sätts tillbaka i systemet en och en gången. Ur praktisk synpunkt är detta emellertid en omväg. Det sista steget i processen, ruta 27, är att ta tillbaka systemet till dess initiala konfiguration med användande av den andra algoritmen.

I de ovan beskrivna exemplen har antagits att mjukvaruobjekten l-18 inte styr någon hårdvaruutrustning. Exempel pä hårdvaruut- rustning som styrs av mjukvarumoduler är I/O-anordningar, gränssnitt mot abonnentlinje, processorer mot abonnentlinjer, tonavkodare, talbeskedsutrustningar, konferensutrustning. Hård- varuberoenden av detta slag skapar restriktioner på mjukvaru- modulerna. En mjukvarumodul som är involverad i styrning av en hárdvaruutrustning som är ansluten till en eller flera proces- sorer kan inte flyttas över till en godtycklig processor i sys- temet utan måste flyttas över till en processor som har access till denna härdvaruutrustning. Katastrofplaner måste skapas med detta i åtanke.

Ett telekomsystem kan vanligen fortsätta sin drift trots för- lust av vissa organ men de tjänster telekomsystemet tillhanda- häller kan hämmas.

Till den grad det är möjligt måste således en katastrofplan al- lokera organstyrande mjukvaruobjekt till processorer som har access till de styrda organen. Om detta inte är möjligt måste de modulariserade mjukvaruobjekten som styr organen uteslutas ur katastrofplanen. Ett uteslutet mjukvaruobjekt är alltid av den typ som visas i Fig. 6C.

Fig. 6B illustrerar ett mjukvaruobjekt som innehåller en funk- tionsdel (exekveringsdel) och en del med persistent data , . < | m 10 15 20 25 30 35 f | 1 , . , 515 348 15 (persistentdata-del). Mjukvaruobjektet i Fig. 6C innehàller funktionsdelen av mjukvaruobjektet i Fig. 6B och mjukvaruobjek- tet i Fig. 6D innehåller persistentdata-delen av samma mjuk- varuobjekt som visas i Fig. 6B. Mjukvaruobjekten i Fig. 6C och 6D bildar tillsammans ett par och de har samma nyckel. Nyckeln är det i Fig. 6B visade mjukvaruobjektets logiska adress till databasen och nyckeln kommer därför även att vara den logiska adressen till de två mjukvaruobjekten i Fig. 6C och 6D i data- basen. Det är mjukvaruobjektet i Fig. 6C som styr en anordning.

Det är i detta mjukvaruobjekt som det finns ett hárdvaruberoen- de.

Ett exkluderat mjukvaruobjekt i en aktuell konfiguration måste blockeras, d v s andra mjukvaruobjekt skall inte kunna kommuni- cera med det. I en föredragen utföringsform ástadkoms blocke- ring genom att sätta persistentdata-delen av mjukvaruobjektet i Fig. 6D i blockerat tillstànd. Ett blockerat tillstànd markeras genom att ställa en flagga i mjukvaruobjektet. Det bör observe- ras att det inte är det organstyrande mjukvaruobjektet 6C som blockeras utan dess persistenta tvilling-mjukvaruobjekt i Fig. 6D. Genom att undersöka tillståndet av ett mjukvaruobjekt innan applikationen börjar kommunicera med mjukvaruobjektet kan ap- plikationen hantera blockerade organ pá ett ordnat sätt.

Såsom ett alternativ till att blockera mjukvaruobjekt med ställd flagga i databasrepresentationen av mjukvaruobjektet kan mjukvaruobjektet blockeras i de adresstabeller som finns i de respektive processorernas operativsystem. Operativsystemet av en processor har en adresstabell till sina egna mjukvaruobjekt.

Adresstabellerna används när meddelanden skickas till operativ- systemets mjukvaruobjekt.

I begreppet kvalité av en tjänst inkluderas det faktum att pro- cessorerna i ett processorsystem kan vara av tvâ slag, feltole- ranta processorer (FTP-processorer) och icke-FTP-processorer.

En FTP processor, som vanligen innefattar dubbla processorer, fortsätter att exekvera sina jobb även om det uppstår ett en- kelt hârdvarufel i den hårdvara som FTP-processorn styr. När felet uppstår triggas ett alarm men programmet havererar inte. 10 15 20 25 30 35 . Q 1 « v u 515 348 16 Med hjälp av organ, vilka inte beskrivs i föreliggande uppfin- ning eftersom de inte bildar någon del av denna uppfinning, är det möjligt att ta en FTP-processor ur tjänst, så att de kan repareras, på ett kontrollerat sätt med användande av katastro- fplanerna. De tjänster applikationen tillhandahåller kommer inte att avbrytas. Såsom ett exempel kan nämnas att i ett tele- komsystem kommer inga trafikstörningar att inträffa; pågående koppel ej att brytas. Systemåterhämtning till följd av borttag- ning av en FTP-processor kommer således inte att bryta levere- rade tjänster. Genom att kombinera den föreliggande uppfinning- en med de ovan beskrivna FTP-processorerna, är det möjligt att åstadkomma mycket hög systemtillgänglighet samt mycket hög tjänstetillförlitlighet när hårdvarufel inträffar. Kort samman- fattat är syftet med parametern tjänstekvalité att stödja FTP- processorer för programvara som kräver mycket hög tjänstetill- förlitlighet. En FTP-processor kommer således att maskera ett internt hårdvarufel men FTP-processorn måste repareras innan nya interna hårdvarufel uppstår.

I Fig. 5 visas ett processor system likartat det i Fig. 1, var- vid det förekommer ett nät N1 till vilket processorer Pl-P4 har access och kan kommunicera med varandra. Ehuru ej visat i Fig. 5 antas att mjukvaruobjekten 1-18 är distribuerade på processo- rerna P1-P4 på samma sätt som visas i Fig. 1. Vidare visas ett organ Dl vara ansluten till processorn P1. Det finns också ett andra nät N2 till vilket processorer P2 och P4 har access. En organprocessor D6 är en anordning som används för att ansluta organ D2 och D3 till nätet N2. Organprocessorn D6 styr således anordningarna D2 och D3. En annan organprocessor D7 ansluter anordningar D4 och D5 till nätet N2 och styr således dessa. Det finns mjukvaruobjekt som ansluter anordningarna D1, D2, D3 D7 till processorsystemet. Såsom ett exempel antas mjukvaruob- jektet 1 styra organet D1. Om P1 kan ingen av processorerna P2- P4 styra organet D1. Således kan objektet 1 inte flyttas över till någon av processorerna P2-P4. Vad beträffar organen D2-D7 gäller emellertid att mjukvaruobjekt som styr något eller några av dessa organ måste vara installerade på en processor som kan kommunicera med dessa organ. Organen D2-D5 kan styras via nätet N2 och således kan mjukvaruobjekt som styr något eller några av § I ¿ - ~ . 10 15 20 25 30 35 u h., 515 348 17 dessa organ installeras på någon av processorerna P2 och P4.

Processorerna P1 och P3 kan däremot inte komma i fråga. Samman- fattningsvis gäller således att ett mjukvaruobjekt som ansluter hårdvara till systemet måste installeras på en processor som har access till denna hårdvara.

Typiska exempel på ett organ av slaget D1 är processorn P1 själv. Ett annat exempel är en hårdvaruanordning, t ex en UART- anordning. Om processorn P1 havererar eller om den hårdvaru- anordning som processorn P1 styr havererar kan inte det mjuk- varuobjekt som representerar processorn P1 eller ett mjukva- ruobjekt som representerar den havererade hårdvaran flyttas över till någon av processørerna P2-P4 eftersom de sistnämnda inte kan få kontroll över den havererade hårdvaran eller över processorn P1. Likväl måste processorsystemet tolerera att P1 havererar om systemet skall vara redundant. Om det mjukvaruob- jekt som representerar processorn P1 havererar måste det mjuk- varuobjekt som representerar processorn P1 blockeras och att det inte kan accessas av något annat mjukvaruobjekt.

Betrakta Fig. 1. Varje processor P1-P4 har varsitt objekt som beskriver processorn. Närmare bestämt representerar objekt 1 processorn P1, objekt 4 processorn P2, objekt 8 processorn P3 och objekt 13 processorn P4. Alla dessa hårdvaruberoenden be- skrivs exakt av den hårdvarumodell på vilken mjukvarumodellen i Fig. 7 är installerad. Således visar modellen att inget av des- sa objekt 1, 4, 8 och 13 kan flyttas över till någon annan processor i systemet. Den första algoritmen arbetar på hårdva- rumodellen med installerad mjukvara och kommer således att ta hänsyn till alla hårdvaruberoenden när den skapar nya katastro- fplaner. Processorns 1 katastrofplan, visad i Tabell 1, kommer därför att förbli densamma med undantag för att objektet 1 för- (Tabell 3) objektet 4 att försvinna och katastrofplanen för processorn 3 svinner. I katastrofplanen för processor 2 kommer kommer objektet 8 att försvinna. I katastrofplanen för proces- sorn P4 kommer objektet 13 att försvinna. Ett färre antal objekt än vad som beskrivits tidigare kommer således att finnas kvar på de respektive processorerna när en processor havererar. m, l0 15 20 25 30 35 1 a 515 348 18 Om t ex processorn P1 havererar måste objektet 1 blockeras mot access från andra mjukvaruobjekt. Detta betyder att inga andra mjukvaruobjekt tilläts kommunicera med mjukvaruobjektet 1.

Modellen enligt uppfinningen kommer alltid att låtsas att sys- temet är i drift även om hárdvaruutrustning gär sönder och inte kan kontrolleras av sitt eller sina mjukvaruobjekt. Om emeller- tid det på den högre nivå i systemet visar sig att systemet inte är i drift, inte ens kan leverera tjänster med nedsatt kvalité, då är orsaken till detta att finna i bristande redun- dans och modellen kan inte ändra på detta faktum.

I Fig. 6A visas mjukvarumodellen av det modulariserade mjukva- ruobjektet. Mjukvarumodellen består av en klass benämnd configObj som har operationerna construct() och destruct().

Construct() och destruct() används för att skapa respektive dö- da ett enskilt modulärt mjukvaruobjekt. Det modulära mjuk- varuobjektet har beskrivits ovan i samband med Fig. 6B-6D.

Det i Fig. 1 visade systemets härdvarumodell beskrivs med hän- visning till Fig. 8. Härdvarumodellen 30 beskriver de fysiska organen och deras platser i systemet. Hårdvarumodellen 30 inne- fattar en klass Processor 31 vilken alstrar objekt som repre- senterar processorerna P1-P4, en klass CPPool 32 vilken genere- rar objekt som representerar nätet N1, en klass DevX 33 som genererar objekt vilka representerar nätet N2 och en klass Con- figObj 34 som genererar objekt vilka representerar mjuk- varuobjekten, visade i Fig. 6B, av de ovan nämnda organen; in- klusive organprocessorerna. Klassen ConfigObj 35 alstrar objekt som representerar mjukvaruobjekten av det modulariserade mjuk- varuobjektet i Fig.6A men bildar inte någon del av hårdvarumodellen.

Modellen visar att processorerna är anslutna till N1 och till N2. Modellen visar också att mjukvara som inte har några organ kan installeras pà alla processorer som kan anslutas till N1, medan mjukvara som styr organ mäste installeras på processorer som kan anslutas till N2. Modellen definierar restriktionerna 515 348 19 för varje hàrdvaruberoende mjukvaruobjekt. Genom att ansluta ConfigObj till OrgX inkluderas inte bara hârdvaruanordningarna i hàrdvarumodellen utan samtidigt installeras de organstyrande mjukvaruobjekten i modellen.

Ma =a a n , , , , _, , , » «= av a -a a c . aa _ a :a »aa v y , , _ . =, ,' __ < = a a a a o a a m a 20 Tabell 1 INITIAL KONFTGURATON PROCESSOR-ID OBJEKT-ID l 1, 2, 3 2 4, 5, 6, 7 3 8, 9, 10, 11, 12 4 13, 14, 15, 16, 17, 18 Tabell 2 KATASTROFPLAN för processor 1 (KP-P1) OBJEKT-ID PROCESSOR-ID 1 2 2 4 3 2 Tabell 3 KATASTROFPLAN för processor 2 (KP-P2) OBJEKT-ID PROCESSOR-ID 4 1 5 3 6 3 7 4 :fa E» 5151348 21 Tabell 4 - . . . ,, KATASTROFPLAN för processor 3 (KP-P3) OBJEKT-ID PROCESSOR-ID 8 1 9 1 10 2 11 4 12 4 Tabell 5 KATASTROFPLAN för processor 4 (KP-P4) OBJEKT-ID PROCESSOR-ID 13 2 14 1 15 2 16 1 17 2 18 1 ~ - e » m e-a u. . . . . « . f. n -u »u v Q . . , V 1 o. . u . . , , w- -,. .- r . . . 1 v . »a , , 22 I - p r m , Tabell 6 AKTUELL KONFIGURATIONSTABELL när processor l är trasig PROCESSOR-ID OBJEKT-ID 2 1, 3, 4, 5, 6, 7 3 8, 9, 10, 11 12 4 2, 13, 14, 15, 16, 17, 18 Tabell 7 DELTAKONFIGURATION för processor 1 PROCESSOR-ID OBJEKT-ID 2 1, 3, 3 _ 515 548 23 Tabell 8 ~ . . . , , NY KATASTROFPLAN för processor 2 (KP-P2') OBJEKT-ID PROCESSOR-ID l 3 3 3 4 3 5 4 6 4 7 4 Tabell 9 NY KATASTROFPLAN för processor 3 (KP-P3') OBJEKT-ID PROCESSOR-ID 8 2 9 2 10 4 ll 4 12 4 2515 548 Tabell 10 NY KATASTROFPLAN för processor 4 (KP-4') OBJEKT-ID PROCESSOR-ID 2 2 13 2 14 2 15 2 16 3 17 3 18 3 Tabell 11 NY AKTUELL KONFIGURATIONSTABELL när processor 2 är trasig PROCESSOR-ID OBJEKT-ID 3 1, 3, 4, 8, 9, 10, 11, 12 4 2, 5, 6, 7, 13, 14, 15, 16, 17, 18

Claims (11)

10 15 20 25 30 35 . ~ » . 1. 515 348 15 PATENTKRAVSALTERNATIV A » | » . i 1 P.ans. 9504396-4

1. Förfarande för automatisk återhämtning från multipla, permanenta processorhaverier i ett distribuerat processorsystem av ett mjukvarudrivet telekommunikationssystem kännetecknat av - (a) skapande av en initial konfiguration som beskriver varje processor och mjukvaruobjekt som exekverar på dessa -(b) skall följas om processorn havererar, vilken katastrofplan skapande av, för varje processor, en katastrofplan som innehåller information om hur de mjukvaruobjekt som exekverar på den havererade processorn skall omfördelas på funktionsdugliga processorer i processorsystemet, -(c) omfördelning av en havererad processors mjukvaruobjekt på driftsdugliga processorer i enlighet med den havererade processorns katastrofplan, -(d) körning av de omfördelade mjukvaruobjekten på sina respektive processorer varigenom processorsystemet återhämtar sig från den havererade processorn, -(e) skapande, för varje nu driftsduglig processor i systemets nu aktuella konfiguration, av nya katastrofplaner som skall följas om någon av de nu driftsdugliga processorerna havererar, varigenom processorsystemet återvinner sin förmåga att motstå ett nytt processorhaveri, -(f) upprepning av stegen (c )-(e) för varje processor som havererar, -(h) reparering av de havererade processorerna och återinsättning av dessa i processorsystemet, -(i) återgång till den initiala kofigurationen genom att nämnda omfördelade mjukvaruobjekt fördelas tillbaka på sina respektive PIOCESSOIGI' .

2. Förfarande för automatisk återhämtning från multipla permanenta processorhaverier i enlighet med patentkrav 1, kännetecknat av att den initiala konfigurationen skapas genom att mjukvaruobjekt, som exekverar på enskild processor, mappas på nämnda enskilda processor och att nämnda mappning upprepas för var och en av processorerna i processorsystmet. 10 15 20 25 . » v f *- 515 -348 1G,

3. Förfarande för automatisk återhämtning från multipla . | = . q . P.ans. 9504396-4 permanenta processorhaverier i enlighet med patentkrav 2 kännetecknat av att omfördelningssteget innefattar skapande och start av de i enlighet med katastrofplanen för den havererade processorn omfördelade mjukvaruobjekten.

4. Förfarande för automatisk återhämtning från multipla permanenta processorhaverier i enlighet med patentkrav 3, kännetecknat av att först omfördelas mjukvaruobjekt som styr hårdvaruutrustning, vilken den havererade processorn styr, och att därefter mjukvaruobjekt som inte styr hårdvaruutrustning omfördelas.

5. Förfarande enligt patentkrav 4, kännetecknat av blockering av mjukvaruobjekt som uppvisar ett hàrdvaruberoende och som exekverar på en havererad processor mot access från mjukvaruobjekt som exekverar på övriga driftsdugliga prOCeSSOr&r i PIOCGSSOISYSCEMGC.

6. Förfarande enligt patentkrav 5 kännetecknat av att en processor som har ett härdvaruberoende representeras av ett mjukvaruobjekt.

7. Förfarande för automatisk återhämtning frän multipla permanenta processorhaverier i enlighet med patentkrav 1, kännetecknat av lagring av nämnda initiala katastrofplaner i en databas som är distribuerad i arbetsminnen vilka hör ihop med de enskilda processorerna i det distribuerade prOCESSOrSyStemet. 10 15 20 25 30 515 348 å?

8. Förfarande för automatisk återhämtning från multipla in .Ü . . I Hz: f: P.ans. 9504396-4 permanenta processorhaverier i enlighet med patentkrav l, kännetecknat av att steget att återgå till den initiala konfigurationen innefattar - framtagning av information avseende vilka mjukvaruobjekt som skall flyttas tillbaka till den reparerade och installerade processorn, - dödande av mjukvaruobjekt som skall flyttas tillbaka samt - alstring och start av de dödade mjukvaruobjekten på den reparerade, installerade processorn.

9. Förfarande för automatisk återhämtning från multipla permanenta processorhaverier i enlighet med patentkrav 2 och 8, kännetecknat av att nämnda framtagning sker genom subtrahering av den initiala konfigurerationen frán den aktuella konfigurationen med uteslutande av den eller de havererade pIOCeSSOreIna .

10. Förfarande för automatisk återhämtning från multipla permanenta processorhaverier i enlighet med patentkrav 1, kännetecknat av att den katastrofplan som skall följas i händelse av att en processor havererar skapas av ifrågavarande pIOCeSSOI .

11. Förfarande för automatisk återhämtning från multipla permanenta processorhaverier i enlighet med patentkrav 8, kännetecknat av att varje mjukvarumodul uppvisar åtminstone två funktioner, en som skapar mjukvaruobjektet och en som dödar det.