Twee applicatieservers kunnen dezelfde uitvaloorzaak hebben
Een tweede applicatieserver helpt bij bepaalde storingen. Een gedeelde database of één toegangspunt kan de hele werkwijze nog steeds blokkeren.
Een tweede applicatieserver kan het werk van een uitgevallen proces overnemen. Of de klant kan doorwerken, hangt ook af van gedeelde onderdelen. De volgende investering moet daarom een concrete storing afdekken en niet alleen het aantal servers verhogen.
Microsoft raadt aan redundantie langs kritieke processen te bekijken voor rekenkracht, gegevens en netwerk. Een verdubbelde applicatielaag beantwoordt de vraag over de volledige werkwijze nog niet.
De gedeelde route zichtbaar maken
In het fictieve voorbeeld openen klanten een projectenlijst. Twee applicatie-instanties op afzonderlijke virtuele machines lezen daarvoor dezelfde database. Er staat één zelf beheerde loadbalancer voor. Die verdeelt aanvragen; hier wordt geen beheerde toegangsdienst met interne redundantie bedoeld. Sessiegegevens die nodig zijn om door te werken, worden niet alleen op één applicatie-instantie opgeslagen.
De identificaties in de tabel horen uitsluitend bij dit voorbeeld. Er is aanvankelijk geen vervanging voor de database of loadbalancer. De tabel beschrijft verwachte gevolgen, geen gemeten beschikbaarheid.
Welke storing de tweede instantie kan opvangen
Storing in het voorbeeld | Verwacht gevolg | Resterende voorwaarde |
|---|---|---|
Applicatieproces |
| Detectie, routering, voldoende capaciteit en werkende gedeelde diensten zijn nodig. |
Gedeelde database | Beide applicatie-instanties kunnen de projectenlijst niet laden. | Een extra applicatie-instantie vervangt de database niet. |
De enige loadbalancer | Nieuwe aanvragen bereiken de instanties niet via deze route. | De toegang heeft een passende uitvalroute nodig. |
Ook het eerste geval is een verwachting die moet worden getest. Raakt de resterende machine overbelast of werkt de routering niet, dan is haar bestaan niet voldoende. Twee VM’s kunnen ook locatie, stroomvoorziening of andere infrastructuur delen; de werkelijke storingsdomeinen moeten bij de eis passen.
De gedeelde gegevenslaag gericht behandelen
Moet de projectenlijst ook bij database-uitval beschikbaar blijven, dan heeft de gegevenslaag een passende aanpak voor beschikbaarheid en failover nodig. Toegestaan gegevensverlies, consistentie en het gedrag van lopende schrijfbewerkingen moeten duidelijk zijn. Ook een tweede databaseproces bewijst op zichzelf geen veilige voortzetting.
Microsoft onderscheidt werkende replica’s van back-upkopieën van een bepaald tijdstip. Een back-up dient voor herstel en is niet automatisch een direct beschikbare, draaiende vervangende database. Replicatie vervangt geen getest herstel na een onbedoelde gegevenswijziging. De benodigde maatregelen hangen af van het bedrijfsdoel.
Beslissen vanuit de getroffen gebruikershandeling
Microsofts storingsanalyse volgt ieder kritiek proces en zijn interne en externe afhankelijkheden. Voor ons voorbeeld moeten de drie tabelgevallen afzonderlijk in een goedgekeurde testomgeving worden getest. Leg detectie, gedrag bij het laden van de projectenlijst, herstel en de verantwoordelijke rol vast.
Als een afgesproken herstelroute een databaseonderbreking voldoende afdekt, kan de extra applicatie-instantie nog steeds nuttig zijn voor processtoringen of onderhoud. Vereist het bedrijf doorwerken bij database- of toegangsuitval, dan blijven die gaten open. Uit het aantal machines volgt geen beschikbaarheidspercentage.
Bronnen
Verder lezen
Alle artikelen
Cloud & beheer met ASES
Hosting, deployment, onderhoud en support