To applikasjonsservere kan ha samme feilårsak

En ekstra applikasjonsserver kan overta etter en prosess som har sviktet. Om kunden kan fortsette å arbeide, avhenger også av de felles komponentene. Den neste investeringen bør derfor dekke en konkret feil, ikke bare øke antallet servere.

Microsoft anbefaler å vurdere redundans for datakraft, data og nettverk langs kritiske forløp. Et doblet applikasjonslag besvarer ikke spørsmålet om hele forløpet.

Gjør den felles veien synlig

I det fiktive eksemplet åpner kunder en prosjektliste. To applikasjonsinstanser på separate virtuelle maskiner leser samme database. Foran dem står én lastbalanserer som teamet selv drifter. Den fordeler forespørsler; her menes ikke en forvaltet tilgangstjeneste med intern redundans. Sesjonsdata som trengs for å fortsette, lagres ikke bare på én applikasjonsinstans.

Identifikatorene i tabellen gjelder bare dette eksemplet. I utgangspunktet finnes ingen erstatning for databasen eller lastbalansereren. Tabellen beskriver forventede virkninger, ikke målt tilgjengelighet.

Hvilken feil den andre instansen kan dekke

Selv det første tilfellet er en forventning som må testes. Hvis den gjenværende maskinen overbelastes eller omdirigeringen ikke virker, er dens eksistens ikke nok. To VM-er kan også dele sted, strømforsyning eller annen infrastruktur; de faktiske feildomenene må passe kravet.

Håndter det felles datalaget særskilt

Skal prosjektlisten være tilgjengelig også ved databasefeil, trenger datalaget en egnet løsning for tilgjengelighet og overtakelse. Akseptabelt datatap, konsistens og oppførselen til pågående skrivinger må avklares. En ekstra databaseprosess beviser heller ikke alene trygg videre drift.

Microsoft skiller mellom kjørende replikaer og sikkerhetskopier fra et bestemt tidspunkt. En sikkerhetskopi brukes til gjenoppretting; den er ikke automatisk en kjørende erstatningsdatabase som straks er tilgjengelig. Replikering erstatter ikke testet gjenoppretting etter en utilsiktet dataendring. Nødvendige tiltak avhenger av virksomhetens mål.

Beslutt ut fra det berørte brukerforløpet

Microsofts feilanalyse følger hvert kritisk forløp og dets interne og eksterne avhengigheter. I eksemplet vårt bør de tre tilfellene i tabellen testes hver for seg i et godkjent testmiljø. Dokumenter oppdagelse, oppførsel ved lasting av prosjektlisten, gjenopptakelse og ansvarlig rolle.

Hvis en avtalt gjenopprettingsvei dekker et databaseavbrudd godt nok, kan den ekstra applikasjonsinstansen fortsatt være nyttig ved prosessfeil eller vedlikehold. Krever virksomheten videre drift ved database- eller tilgangsfeil, står nettopp disse hullene åpne. En tilgjengelighetsprosent kan ikke utledes fra antallet maskiner.

Kilder

• Microsoft — Architecture strategies for designing for redundancy

• Microsoft — Architecture strategies for performing failure mode analysis

• Microsoft — Redundancy, replication, and backup