DataDomain: Oppgraderingsveiledning for operativsystemet for systemer med høy tilgjengelighet (HA)
摘要: Prosessoversikt for oppgraderinger av Data Domain Operation System (DDOS) på Data Domain "Highly Available" (DDHA)-apparater.
说明
For å redusere planlagt nedetid for vedlikehold, er den rullerende oppgraderingen av systemet inkludert i HA-arkitekturen. En rullerende oppgradering kan oppgradere ventemodusnoden først, og deretter bruke en forventet HA-failover til å flytte tjenestene fra aktiv node til standby-node. Til slutt vil tidligere aktive noder bli oppgradert og bli med i HA-klyngen som standbynode. Alle prosessene gjøres i en kommando.
En alternativ manuell oppgraderingsmetode er "lokal oppgradering". Oppgrader først ventemodusnoden manuelt, og oppgrader deretter den aktive noden manuelt. Endelig ville standby-noden bli med i HA-klyngen igjen. Lokal oppgradering kan utføres enten for vanlig oppgradering eller for å løse problemer.
Alle systemoppgraderingsoperasjoner på aktiv node som krever datakonvertering, starter kanskje ikke før begge systemene er oppgradert til samme nivå og HA-tilstanden er fullstendig gjenopprettet.
DDOS 5.7 og nyere støtter to typer oppgraderingsmetoder for HA-systemer:
-
Rullerende oppgradering - oppgrader automatisk begge HA-noder med en kommando. Tjenesten flyttes til den andre noden etter oppgraderingen.
-
Lokal oppgradering – oppgrader HA-noder manuelt, én etter én. Tjenesten beholdes på samme node etter oppgraderingen.
Klargjør systemet for oppgradering:
-
Kontroller at HA-systemstatusen er "høyt tilgjengelig".
Logg inn GUI à Home à Dashboard
- DDOS RPM-filen bør plasseres på en aktiv node, og oppgraderingen skal starte fra denne noden.
Logg inn GUI à Home à Dashboard
- Last opp RPM-fil til aktiv node
Etter opplasting vil RPM-filen bli oppført.
- Kjør forhåndssjekk på aktiv node. Oppgraderingen bør avbrytes hvis det oppstår feil.
Avslutt også GC, dataflytting og replikering før du starter oppgraderingen (trinn #6), slik at disse jobbene ikke fører til lengre DDFS-avslutningstid under oppgraderingen. Kortere DDFS-avslutningstid bidrar til å minimere innvirkningen på klientene. Disse workloadene påvirker ikke sikkerhetskopiering/gjenoppretting for klient.
Basert på behov kan disse tjenestene gjenopptas etter at oppgraderingen er fullført ved hjelp av de tilsvarende aktiveringskommandoene. Se administrasjonsveiledningen hvis du vil ha mer informasjon.
Det er noen andre manuelle kontroller og kommandoer som er beskrevet i administrasjonsveiledningen som ikke er strengt nødvendige for et HA-system. Forhåndsomstart er for øyeblikket foreslått som en test for systemer med én node. Det er ikke nødvendig for HA-systemer, fordi #5 "ha failover" nedenfor allerede inkluderer en automatisk omstart under failover-prosessen.
- Valgfri. Før du kjører en rullerende oppgradering, anbefales det å utføre HA-failover to ganger manuelt på aktiv node. Hensikten er å teste failover-funksjonalitet. Operasjonen vil gjøre aktiv node startet på nytt, vær oppmerksom på det.
Forbered deg på failover ved å slå av GC, dataflytting og replikering. Se administrasjonsveiledningen for å finne ut hvordan du gjør det via GUI. Disse tjenestene påvirker ikke workloader for sikkerhetskopiering/gjenoppretting for klienten. Deretter fortsetter du med "ha failover".

(Når HA-systemstatus blir «svært tilgjengelig» igjen, må du gjennomføre den andre «ha-failoveren» og vente til begge nodene kobler seg til internett)
Etter HA-failoveren kan de stoppede tjenestene gjenopptas ved hjelp av de tilsvarende aktiveringskommandoene. Se administrasjonsveiledningen hvis du vil ha mer informasjon.
Testene av failover ovenfor er valgfrie og må ikke utføres rett før oppgraderingen. Failover-testene kan utføres før oppgraderingen, for eksempel to uker, slik at et mindre vedlikeholdsvindu kan brukes til den senere oppgraderingen. DDFS-tjenestens nedetid for hver failover er rundt 10 minutter (mindre eller mer avhengig av DDOS-versjoner og andre faktorer). DDOS-versjoner 7.4 og nyere vil ha mindre nedetid ved utgivelse på grunn av kontinuerlige DDOS SW-forbedringer.
- Hvis forhåndskontrollen er fullført uten problemer, fortsett rullerende oppgradering på aktiv node.
- Vent til rullerende oppgraderingsfinish. Før dette må du ikke utløse noen HA-failover-operasjoner.
DDFS-tilgjengelighet under kommandoen ovenfor:
-
Den vil oppgradere standby-noden først og starte den på nytt til den nye versjonen. Det tar omtrent 20 minutter til 30 minutter, avhengig av ulike faktorer. DDFS-tjenesten er oppe og kjører på den aktive noden i denne perioden uten redusert ytelse.
-
Etter at den nye DDOS er tatt i bruk, vil systemet deretter failover DDFS-tjenesten til den oppgraderte ventenoden. Det tar omtrent 10 minutter (mindre eller mer avhengig av ulike faktorer).
-
En viktig faktor er DAE FW-oppgradering. Det kan introdusere ~20mins mer nedetid, avhengig av hvor mange DAE-er som er konfigurert. Se KB "Data Domain: HA Rolling upgrade may fail for external enclosure firmware upgraded", for å avgjøre om en DAE FW-oppgradering er nødvendig. Merk at fra og med DDOS 7.5 er det en forbedring for å aktivere online oppgradering av DAE FW, noe som eliminerer denne bekymringen.
-
Dell kundestøtte kan kontaktes for å diskutere faktorer som kan påvirke oppgraderingstider. Avhengig av klientens operativsystem, program og protokollen mellom klient og HA-system, kan det hende at brukeren må gjenoppta klientworkloader manuelt rett etter failover. Hvis for eksempel med DDBoost-klienter og failover-tiden er over 10 minutter, må klientens tidsavbrudd og brukeren gjenoppta workloader manuelt. Men det er vanligvis ikke tilgjengelig på klienter for å angi tidsavbruddsverdier og prøve på nytt.
-
Vær oppmerksom på at DDFS-tjenesten er nede under failover-perioden. Ved å se på utdata fra "filesys status"-kommandoen på den oppgraderte noden, vil man vite om DDFS-tjenesten gjenopptas eller ikke. DDOS-versjoner på 7.4 og nyere forventes å ha mindre og mindre nedetid på grunn av forbedringer i DDOS-koden.
Etter failoveren blir den tidligere aktive noden oppgradert. Når oppgraderingen er gjennomført, startes den på nytt til den nye versjonen, og blir deretter med i HA-klyngen som ventemodusnode igjen. DDFS-tjenesten påvirkes ikke under denne prosessen, siden den allerede ble gjenopptatt i #II ovenfor.
Verifisering:
- Etter rullende oppgradering ferdig, trenger pålogging GUI via IP-adressen til pre-standby-noden, i dette tilfellet er det node1.
- Kontroller om det kommer uventede varsler.
- På dette tidspunktet er den rullerende oppgraderingen fullført.
Rullerende oppgradering via CLI:
Klargjør systemet for oppgradering:
- Kontroller at HA-systemstatusen er "høyt tilgjengelig".
#ha status
HA System name: HA-system
HA System status: highly available ç
Node Name Node id Role HA State
----------------------------- ------- ------- --------
Node0 0 active online
Node1 1 standby online
----------------------------- ------- ------- --------
- DDOS RPM-filen bør plasseres på en aktiv node, og oppgraderingen skal starte fra denne noden.
#ha status
HA System name: HA-system
HA System status: highly available
Node Name Node id Role HA State
----------------------------- ------- ------- --------
Node0 0 active online ß Node0 is active node
Node1 1 standby online
----------------------------- ------- ------- --------
- Last opp RPM-fil til aktiv node
Client-server # scp <rpm file> sysadmin@HA-system.active_node:/ddr/var/releases/
Password: (customer defined it.)
(From client server, target path is “/ddr/var/releases”)
Aktiv-node # system package list
File Size (KiB) Type Class Name Version ------------------ ---------- ------ ---------- ----- ------- x.x.x.x-12345.rpm 2927007.3 System Production DD OS x.x.x.x ------------------ ---------- ------ ---------- ----- -------
- Kjør forhåndssjekk på aktiv node. Oppgraderingen bør avbrytes hvis det oppstår feil.
Active-node # system upgrade precheck <rpm file>
Upgrade precheck in progress:
Node 0: phase 1/1 (Precheck 100%) , Node 1: phase 1/1 (Precheck 100%)
Upgrade precheck found no issues.
Avslutt også GC, dataflytting og replikering før du starter oppgraderingen (trinn #6), slik at disse jobbene ikke fører til lengre DDFS-avslutningstid under oppgraderingen. Kortere DDFS-avslutningstid bidrar til å minimere innvirkningen på klientene. Disse workloadene påvirker ikke sikkerhetskopiering/gjenoppretting for klient. Basert på behov kan disse tjenestene gjenopptas etter at oppgraderingen er fullført, ved hjelp av de tilsvarende aktiveringskommandoene. Se administrasjonsveiledningen hvis du vil ha mer informasjon.
Active-node # filesys clean stop
Active-node # cloud clean stop
Active-node # data-movement suspend
Active-node # data-movement stop to-tier active
Active-node # replication disable all
Merk at det er noen "se" -kommandoer for å sjekke om operasjonene ovenfor er utført.
Active-node # filesys clean watch
Active-node # cloud clean watch
Active-node # data-movement watch
Det er noen andre manuelle kontroller og kommandoer som er beskrevet i administrasjonsveiledningen som ikke er strengt nødvendige for et HA-system. Forhåndsomstart er for øyeblikket foreslått som en test for systemer med én node. Det er ikke nødvendig for HA-systemer, fordi #5 "ha failover" nedenfor allerede inkluderer en automatisk omstart under failover-prosessen.
- Valgfri. Før du kjører en rullerende oppgradering, anbefales det å utføre HA-failover to ganger manuelt på aktiv node. Hensikten er å teste failover-funksjonalitet. Operasjonen vil gjøre aktiv node startet på nytt, vær oppmerksom på det.
Forbered deg først på failover ved å deaktivere GC, dataflytting og replikering. Disse tjenestene påvirker ikke workloader for sikkerhetskopiering/gjenoppretting for klienten. Deretter kjører du "ha failover".
Kommandoene for å gjøre dette er som følger:
Active-node # filesys clean stop
Active-node # cloud clean stop
Active-node # data-movement suspend
Active-node # data-movement stop to-tier active
Active-node # replication disable all
Merk at det er noen "se" -kommandoer for å sjekke om operasjonene ovenfor er utført.
Active-node # filesys clean watch
Active-node # cloud clean watch
Active-node # data-movement watch
Kjør deretter failover-kommandoen:
Active-node # ha failoverDenne operasjonen starter en failover fra denne noden. Den lokale noden starter på nytt.
Vil du fortsette? (ja|nei) [nei]: ja
Failover-operasjonen er startet. Kjør 'ha status' for å overvåke statusen
(Når HA-systemstatus blir «svært tilgjengelig» igjen, må du gjennomføre den andre «ha-failoveren» og vente til begge nodene kobler seg til internett)
Etter HA-failoveren kan de stoppede tjenestene gjenopptas ved hjelp av de tilsvarende aktiveringskommandoene. Se administrasjonsveiledningen hvis du vil ha mer informasjon.
Testene av failover ovenfor er valgfrie og må ikke utføres rett før oppgraderingen. Failover-testene kan utføres før oppgraderingen, for eksempel to uker, slik at et mindre vedlikeholdsvindu kan brukes til den senere oppgraderingen. DDFS-tjenestens nedetid for hver failover er ca. 10 minutter (mindre eller mer, avhengig av DDOS-versjonene og andre faktorer). DDOS-versjon 7.4 og nyere vil ha mindre utgivelse av nedetid ved utgivelse på grunn av kontinuerlige DDOS SW-forbedringer.
- Hvis forhåndskontrollen er fullført uten problemer, fortsett rullerende oppgradering på aktiv node.
Active-node # system upgrade start <rpm file> Kommandoen 'system upgrade' oppgraderer Data Domain OS. Tilgang til
filer blir avbrutt under oppgraderingen. Systemet starter automatisk
på nytt etter oppgraderingen.
Are you sure? (yes|no) [no]: yes ok, proceeding. Upgrade in progress: Node Severity Issue Solution ---- -------- ------------------------------ -------- 0 WARNING 1 component precheck script(s) failed to complete 0 INFO Upgrade time est: 60 mins 1 WARNING 1 component precheck script(s) failed to complete 1 INFO Upgrade time est: 80 mins ---- -------- ------------------------------ -------- Node 0: phase 2/4 (Install 0%) , Node 1: phase 1/4 (Precheck 100%) Upgrade phase status legend: DU : Data Upgrade FO : Failover .. PC : Peer Confirmation VA : Volume Assembly Node 0: phase 3/4 (Reboot 0%) , Node 1: phase 4/4 (Finalize 5%) FO Upgrade has started. System will reboot.
DDFS-tilgjengelighet under kommandoen ovenfor:
-
Den vil oppgradere standby-noden først og starte den på nytt til den nye versjonen. Det tar omtrent 20 minutter til 30 minutter, avhengig av ulike faktorer. DDFS-tjenesten er oppe og kjører på den aktive noden i denne perioden uten redusert ytelse.
-
Etter at den nye DDOS er tatt i bruk, vil systemet deretter failover DDFS-tjenesten til den oppgraderte ventenoden. Det tar omtrent 10 minutter (mindre eller mer avhengig av ulike faktorer).
-
En viktig faktor er DAE FW-oppgradering. Det kan introdusere ~20mins mer nedetid, avhengig av hvor mange DAE-er som er konfigurert. Se KB "Data Domain: HA Rolling upgrade may fail for external enclosure firmware upgraded", for å avgjøre om en DAE FW-oppgradering er nødvendig. Merk at fra og med DDOS 7.5 er det en forbedring for å aktivere online oppgradering av DAE FW, noe som eliminerer denne bekymringen.
-
Dell kundestøtte kan kontaktes for å diskutere faktorer som kan påvirke oppgraderingstider. Avhengig av klientens operativsystem, program og protokollen mellom klient og HA-system, kan det hende at brukeren må gjenoppta klientworkloader manuelt rett etter failover. Hvis for eksempel med DDBoost-klienter og failover-tiden er over 10 minutter, må klientens tidsavbrudd og brukeren gjenoppta workloader manuelt. Men det er vanligvis tunables tilgjengelig på klienter for å angi tidsavbruddsverdier og prøve på nytt.
-
-
Etter failoveren blir den tidligere aktive noden oppgradert. Når oppgraderingen er gjennomført, startes den på nytt til den nye versjonen, og blir deretter med i HA-klyngen som ventemodusnode igjen. DDFS-tjenesten påvirkes ikke under denne prosessen, siden den allerede ble gjenopptatt i #II ovenfor.
- Etter at standby-noden (node1) har startet på nytt og blir tilgjengelig, er det mulig å logge på standby-noden for å overvåke oppgraderingsstatus/-fremgang.
Node1 # system upgrade status
Current Upgrade Status: DD OS upgrade In Progress
Node 0: phase 3/4 (Reboot 0%)
Node 1: phase 4/4 (Finalize 100%) waiting for peer confirmation
- Vent til rullerende oppgraderingsfinish. Før dette må du ikke utløse noen HA-failover-operasjoner.
Node1 # system upgrade status
Current Upgrade Status: DD OS upgrade Succeeded
End time: 20xx.xx.xx:xx:xx
- Kontroller HA-statusen, begge nodene er pålogget, HA-systemstatus er "svært tilgjengelig".
Node1 # ha status detailed
HA System name: HA-system
HA System Status: highly available
Interconnect Status: ok
Primary Heartbeat Status: ok
External LAN Heartbeat Status: ok
Hardware compatibility check: ok
Software Version Check: ok
Node Node1:
Role: active
HA State: online
Node Health: ok
Node Node0:
Role: standby
HA State: online
Node Health: ok
Mirroring Status:
Component Name Status
-------------- ------
nvram ok
registry ok
sms ok
ddboost ok
cifs ok
-------------- ------
Verifisering:
- Kontroller at begge nodene har samme DDOS-versjon.
Node1 # system show version
Data Domain OS x.x.x.x-12345
Node0 # system show version
Data Domain OS x.x.x.x-12345
- Kontroller om det kommer uventede varsler.
Node1 # alert show current
Node0 # alert show current
- På dette tidspunktet er den rullerende oppgraderingen fullført.
Merk: Hvis du får problemer med oppgraderingen, kan du kontakte Data Domain-støtten for ytterligere instruksjoner og støtte.
LOKAL OPPGRADERING for DDHA Pair:
En lokal oppgradering fungerer stort sett som følger:
Klargjør systemet for oppgradering:
- Sjekk HA-systemstatus. Selv statusen er degradert, kan lokal oppgradering fungere på denne situasjonen.
#ha status HA System name: HA-system HA System status: highly available <- Node Name Node id Role HA State ----------------------------- ------- ------- -------- Node0 0 active online Node1 1 standby online ----------------------------- ------- ------- --------
- DDOS RPM-filen skal plasseres på begge noder, og oppgraderingen skal starte fra ventemodusnoden.
#ha status
HA System name: HA-system
HA System status: highly available
Node Name Node id Role HA State
----------------------------- ------- ------- --------
Node0 0 active online
Node1 1 standby online <- Node1 is standby node
----------------------------- ------- ------- --------
- Last opp RPM-filen til begge nodene.
Client-server # scp <rpm file> sysadmin@HA- system.active_node:/ddr/var/releases/
Client-server # scp <rpm file> sysadmin@HA-system.standby_node:/ddr/var/releases/
Password: (customer defined it.)
(From client server, target path is “/ddr/var/releases”)
Active-node # system package list File Size (KiB) Type Class Name Version ------------------ ---------- ------ ---------- ----- ------- x.x.x.x-12345.rpm 2927007.3 System Production DD OS x.x.x.x ------------------ ---------- ------ ---------- ----- ------ Standby-node # system package list File Size (KiB) Type Class Name Version ------------------ ---------- ------ ---------- ----- ------- x.x.x.x-12345.rpm 2927007.3 System Production DD OS x.x.x.x ------------------ ---------- ------ ---------- ----- ------
- Kjør forhåndssjekk på aktiv node hvis HA-statusen er «høyt tilgjengelig». Oppgraderingen bør avbrytes hvis det oppstår feil.
Active-node # system upgrade precheck <rpm file>
Upgrade precheck in progress: Node 0: phase 1/1 (Precheck 100%) , Node 1: phase 1/1 (Precheck 100%) Upgrade precheck found no issues.
Hvis HA-statusen er "degradert", trenger du en forhåndssjekk på begge nodene.
Active-node # system upgrade precheck <rpm file> local
Upgrade precheck in progress:
Node 0: phase 1/1 (Precheck 100%)
Upgrade precheck found no issues.
Standby-node # system upgrade precheck <rpm file> local
Upgrade precheck in progress:
Node 1: phase 1/1 (Precheck 100%)
Upgrade precheck found no issues.
- Ta standby-noden frakoblet.
Standby-node # ha offline
This operation will cause the ha system to no longer be highly available.
Do you want to proceed? (yes|no) [no]: yes
Standby node is now offline.
(MERK: Hvis frakoblet operasjon mislyktes eller ha-status er degradert, fortsett den lokale oppgraderingen fordi senere trinn kan håndtere feil.)
- Kontroller at status for ventemodusnode er frakoblet.
Standby-node # ha status
HA System name: HA-system
HA System status: degraded
Node Name Node id Role HA State
----------------------------- ------- ------- --------
Node1 1 standby offline
Node0 0 active degraded
----------------------------- ------- ------- --------
- Utfør oppgraderingen på ventemodusnoden. Denne operasjonen starter omstart av ventemodusnode.
Kommandoen 'system upgrade' oppgraderer Data Domain OS. Tilgang til
filer blir avbrutt under oppgraderingen. Systemet starter automatisk
på nytt etter oppgraderingen.
Er du sikker? (ja|nei) [nei]: ja
ok, fortsetter.
Det "lokale" flagget er svært forstyrrende for HA-systemer og bør bare brukes som en reparasjonsoperasjon.
Er du sikker? (ja|nei) [nei]: ja
ok, fortsetter.
Oppgradering pågår:
Node 1: fase 3/4 (omstart 0%)
Oppgraderingen har startet. Systemet starter på nytt.
- Ventemodusnoden starter på nytt i den nye versjonen av DDOS, men forblir frakoblet.
- Kontroller statusen for systemoppgraderingen. Det kan ta mer enn 30 minutter å fullføre oppgraderingen av operativsystemet.
Standby-node # system upgrade status
Current Upgrade Status: DD OS upgrade Succeeded
End time: 20xx.xx.xx:xx:xx
- Kontroller at HA-systemstatus, standby-node (i dette tilfellet er det node1) er frakoblet, HA-status er 'degradert'.
Standby-node # ha status
HA System name: HA-system
HA System status: degraded
Node Name Node id Role HA State
----------------------------- ------- ------- --------
Node1 1 standby offline
Node0 0 active degraded
----------------------------- ------- ------- --------
- Utfør den lokale oppgraderingen på den aktive noden. Denne operasjonen starter aktiv node på nytt.
Active-node # system upgrade start <rpm file> local
The 'system upgrade' command upgrades the Data Domain OS. File access
is interrupted during the upgrade. The system reboots automatically
after the upgrade.
Are you sure? (yes|no) [no]: yes
ok, proceeding.
The 'local' flag is highly disruptive to HA systems and should be used only as a repair operation.
Are you sure? (yes|no) [no]: yes
ok, proceeding.
Upgrade in progress:
Node Severity Issue Solution
---- -------- ------------------------------ --------
0 WARNING 1 component precheck
script(s) failed to complete
0 INFO Upgrade time est: 60 mins
---- -------- ------------------------------ --------
Node 0: phase 3/4 (Reboot 0%)
Upgrade has started. System will reboot.
- Kontroller statusen for systemoppgraderingen. Det kan ta mer enn 30 minutter å fullføre oppgraderingen av operativsystemet.
Active-node # system upgrade status
Current Upgrade Status: DD OS upgrade Succeeded
End time: 20xx.xx.xx:xx:xx
- Når oppgraderingen av den aktive noden er fullført, er HA-systemstatusen fortsatt degradert. Utfør følgende kommando for å gjøre ventemodusnoden online, den vil starte standby-noden på nytt.
Standby-node # ha online The operation will reboot this node. Do you want to proceed? (yes|no) [no]: yes Broadcast message from root (Wed Oct 14 22:38:53 2020): The system is going down for reboot NOW! **** Error communicating with management service.(MERK: Hvis "ha offline" ikke ble kjørt på foregående trinn, kan du ignorere dette trinnet)
- Ventemodusnoden starter på nytt og blir med i klyngen igjen. Etter dette vil HA-status bli «svært tilgjengelig» igjen.
Active-node # ha status detailed
HA System name: Ha-system
HA System Status: highly available
Interconnect Status: ok
Primary Heartbeat Status: ok
External LAN Heartbeat Status: ok
Hardware compatibility check: ok
Software Version Check: ok
Node node0:
Role: active
HA State: online
Node Health: ok
Node node1:
Role: standby
HA State: online
Node Health: ok
Mirroring Status:
Component Name Status
-------------- ------
nvram ok
registry ok
sms ok
ddboost ok
cifs ok
-------------- ------
Verifisering:
- Kontroller at begge nodene har samme DDOS-versjon.
Node1 # system show version
Data Domain OS x.x.x.x-12345
Node0 # system show version
Data Domain OS x.x.x.x-12345
- Kontroller om det kommer uventede varsler.
Node1 # alert show current
Node0 # alert show current
- På dette tidspunktet er den rullerende oppgraderingen fullført.
其他信息
Rullerende oppgradering:
-
Vær oppmerksom på at én enkelt failover utføres under oppgraderingen, slik at rollene byttes
-
Oppgraderingsinformasjon oppbevares fortsatt i infra.log men det kan være ytterligere informasjon i ha.log
-
Oppgraderingsfremdriften kan overvåkes via overvåking av systemoppgradering
Oppgradering av lokal node:
-
En lokal nodeoppgradering utfører ikke HA-failover
-
Som et resultat vil det være en lengre periode med nedetid mens den aktive noden oppgraderer/starter på nytt / utfører oppgraderingsaktiviteter etter omstart, noe som sannsynligvis vil føre til at sikkerhetskopieringer/gjenopprettinger blir tidsavbrutt og mislykkes. Krev tildeling av et tidsvindu for vedlikehold for lokal oppgradering.
-
Selv om HA-systemstatusen er «degradert», kan man oppgradere lokalt.
-
Av en eller annen grunn kan rullerende oppgradering mislykkes uventet. Lokal oppgradering kan betraktes som en reparasjonsmetode i denne situasjonen.