Två applikationsservrar kan ha samma orsak till avbrott
En andra applikationsserver hjälper vid vissa fel. En gemensam databas eller en enda åtkomstväg kan fortfarande blockera hela förloppet.
En andra applikationsserver kan ta över efter en havererad process. Om kunden kan fortsätta arbeta beror också på de gemensamma komponenterna. Nästa investering bör därför täcka ett konkret fel i stället för att bara öka antalet servrar.
Microsoft rekommenderar att granska redundans för beräkning, data och nätverk längs kritiska förlopp. Ett fördubblat applikationslager besvarar ännu inte frågan om hela förloppet.
Gör den gemensamma vägen synlig
I det fiktiva exemplet öppnar kunder en projektlista. Två applikationsinstanser på separata virtuella maskiner läser samma databas. Framför dem finns en enda lastbalanserare som teamet driver självt. Den fördelar begäranden; här avses ingen förvaltad åtkomsttjänst med intern redundans. Sessionsdata som behövs för att fortsätta lagras inte enbart på en applikationsinstans.
Identifierarna i tabellen hör bara till detta exempel. Inledningsvis finns ingen ersättare för databasen eller lastbalanseraren. Tabellen beskriver förväntade effekter, ingen uppmätt tillgänglighet.
Vilket fel den andra instansen kan täcka
Fel i exemplet | Förväntad effekt | Kvarvarande villkor |
|---|---|---|
Applikationsprocessen |
| Det kräver upptäckt, omdirigering, tillräcklig kapacitet och fungerande gemensamma tjänster. |
Den gemensamma databasen | Ingen applikationsinstans kan läsa in projektlistan. | En extra applikationsinstans ersätter inte databasen. |
Den enda lastbalanseraren | Nya begäranden når inte instanserna via denna väg. | Åtkomstvägen behöver en lämplig lösning vid fel. |
Även det första fallet är en förväntan att testa. Om den återstående maskinen överbelastas eller omdirigeringen inte fungerar räcker inte dess existens. Två VM:ar kan också dela plats, strömförsörjning eller annan infrastruktur; de verkliga feldomänerna måste passa kravet.
Hantera det gemensamma datalagret särskilt
Ska projektlistan vara tillgänglig även vid databasfel behöver datalagret en lämplig lösning för tillgänglighet och övertagande. Tillåten dataförlust, konsistens och beteendet hos pågående skrivningar måste klargöras. En andra databasprocess bevisar inte heller ensam säker fortsatt drift.
Microsoft skiljer på körande repliker och säkerhetskopior från en viss tidpunkt. En säkerhetskopia används för återställning; den är inte automatiskt en körande ersättningsdatabas som är omedelbart tillgänglig. Replikering ersätter inte testad återställning efter en oavsiktlig dataändring. Vilka åtgärder som behövs beror på verksamhetsmålet.
Besluta utifrån det berörda användarförloppet
Microsofts felanalys följer varje kritiskt förlopp och dess interna och externa beroenden. I vårt exempel bör tabellens tre fall testas var för sig i en godkänd testmiljö. Dokumentera upptäckt, beteendet när projektlistan läses in, återstart och ansvarig roll.
Om en överenskommen återställningsväg täcker ett databasavbrott tillräckligt kan den extra applikationsinstansen ändå vara användbar vid processfel eller underhåll. Kräver verksamheten fortsatt drift vid databas- eller åtkomstfel är just dessa luckor kvar. En tillgänglighetsprocent kan inte härledas ur antalet maskiner.
Källor
Läs vidare
Alla artiklar
Cloud & drift med ASES
Hosting, driftsättning, underhåll och support