To applikationsservere kan dele samme årsag til nedbrud

En ekstra applikationsserver kan overtage efter en proces, der er gået ned. Om kunden kan arbejde videre, afhænger også af de fælles komponenter. Den næste investering bør derfor dække en konkret fejl frem for blot at øge antallet af servere.

Microsoft anbefaler at se på redundans for beregning, data og netværk langs kritiske forløb. Et fordoblet applikationslag besvarer ikke spørgsmålet om hele forløbet.

Gør den fælles vej synlig

I det fiktive eksempel åbner kunder en projektliste. To applikationsinstanser på separate virtuelle maskiner læser samme database. Foran dem står én loadbalancer, som teamet selv driver. Den fordeler forespørgsler; her menes ikke en administreret adgangstjeneste med intern redundans. Sessionsdata, der er nødvendige for at fortsætte, gemmes ikke kun på én applikationsinstans.

Identifikatorerne i tabellen gælder kun dette eksempel. I udgangspunktet er der ingen erstatning for databasen eller loadbalanceren. Tabellen beskriver forventede virkninger, ikke målt tilgængelighed.

Hvilken fejl den anden instans kan dække

Selv det første tilfælde er en forventning, der skal testes. Hvis den resterende maskine overbelastes, eller omdirigeringen ikke virker, er dens tilstedeværelse ikke nok. To VM’er kan også dele placering, strøm eller anden infrastruktur; de faktiske fejldomæner skal passe til kravet.

Behandl det fælles datalag særskilt

Skal projektlisten også være tilgængelig ved databasefejl, kræver datalaget en passende løsning for tilgængelighed og overtagelse. Acceptabelt datatab, konsistens og igangværende skrivninger skal afklares. En ekstra databaseproces beviser heller ikke i sig selv sikker fortsættelse.

Microsoft skelner mellem kørende replikaer og sikkerhedskopier fra et bestemt tidspunkt. En sikkerhedskopi bruges til gendannelse; den er ikke automatisk en kørende erstatningsdatabase, der straks er tilgængelig. Replikering erstatter ikke testet gendannelse efter en utilsigtet dataændring. De nødvendige tiltag afhænger af forretningsmålet.

Beslut ud fra det berørte brugerforløb

Microsofts fejlanalyse følger hvert kritisk forløb og dets interne og eksterne afhængigheder. I vores eksempel bør tabellens tre tilfælde testes enkeltvis i et godkendt testmiljø. Registrér opdagelse, adfærd ved indlæsning af projektlisten, genoptagelse og ansvarlig rolle.

Hvis en aftalt gendannelsesvej dækker en databaseafbrydelse tilstrækkeligt, kan den ekstra applikationsinstans stadig være nyttig ved procesfejl eller vedligeholdelse. Kræver virksomheden fortsat drift ved database- eller adgangsfejl, står netop de huller åbne. En tilgængelighedsprocent kan ikke udledes af antallet af maskiner.

Kilder

• Microsoft — Architecture strategies for designing for redundancy

• Microsoft — Architecture strategies for performing failure mode analysis

• Microsoft — Redundancy, replication, and backup