DR-testaus ilman vaikutuksia
Suorita testiä varten vikasietoinen siirto eristettyyn verkkoon palautussuunnitelman päästä päähän -validointia varten, mittaa todellinen RTO ja dokumentoi korjausta vaativat puutteet
DR-testaus ilman vaikutuksia on ilmainen Cloud & IT Cert Prep-oppitunti CoddyKitissä. Tämä on oppitunti 3/4. Voit lukea koko oppitunnin alta ilmaiseksi ja harjoitella sen jälkeen käytännössä selaimessa sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla. Oppitunti kuuluu Cloud & IT Cert Prep-oppimispolkuun, ja edistymisesi synkronoituu verkon ja CoddyKit-sovelluksen välillä. Cloud & IT Cert Prep-kurssilla on yhteensä 4 oppituntia.
Miksi DR-testaus on välttämätöntä
Katastrofipalautumissuunnitelma, jota ei ole koskaan testattu, on vain hypoteesi. Käytännön kokemukset osoittavat, että DR-suunnitelmista paljastuu usein puutteita — kuten kokoonpanon ajautumista, puuttuvaa automaatiota, vanhentuneita runbookeja tai odotettua pidempiä käynnistysaikoja — jotka tulevat esiin vain testiolosuhteissa. Säännöllinen DR-testaus on ainoa tapa varmistua siitä, että suunnitelma toimii silloin, kun sitä eniten tarvitaan.
Testifailover-ominaisuus
Test Failover on Azure Site Recoveryn sisäänrakennettu ominaisuus, jonka avulla voitte simuloida failoverin toissijaiseen alueeseen keskeyttämättä tuotantoa. Testifailoverin aikana ASR luo replikoiduista VM:istä kopiot eristettyyn virtuaaliverkkoon toissijaisella alueella. Tuotannon VM:t jatkavat normaalia toimintaansa ensisijaisella alueella, joten tästä ei aiheudu riskiä tuotannon käyttäjille.
# Trigger a test failover for a recovery plan:
az site-recovery recovery-plan test-failover \
--resource-group myRG \
--vault-name myRecoveryVault \
--name myRecoveryPlan \
--failover-direction PrimaryToRecovery \
--network-id '/subscriptions/.../virtualNetworks/testFailoverVNet'Testiympäristön eristäminen
Eristetyllä testivNetillä ei saa olla yhteyttä tuotantojärjestelmiin. Näin estetään testikäytössä olevia VM:iä kirjoittamasta vahingossa tuotantotietokantaan, lähettämästä sähköposteja oikeille asiakkaille tai käynnistämästä maksutapahtumia. Luokaa erillinen testifailover-VNet, jolla ei ole peering-yhteyttä tuotannon VNet-verkkoihin eikä internet-yhteyttä, ja käyttäkää sitä yksinomaan DR-harjoituksiin.
# Create an isolated test VNet for DR drills:
az network vnet create \
--resource-group drRG \
--name testFailoverVNet \
--address-prefix 10.99.0.0/16 \
--subnet-name testSubnet \
--subnet-prefix 10.99.1.0/24
# NOTE: Do NOT peer this VNet to any production VNetMitä DR-testin aikana on validoitava
DR-testissä on validoitava tietyt kriteerit:
- Käynnistysaika — käynnistyvätkö kaikki VM:t odotetun aikaikkunan kuluessa?
- Sovelluksen käynnistyminen — alustautuuko sovellus oikein, kun se yhdistetään palautettuun tietokantaan?
- Tietojen eheys — ovatko palautuspisteen tiedot yhdenmukaiset ja täydelliset?
- Todellinen RTO — mitatkaa failoverin käynnistämisestä siihen, kun sovellus alkaa palvella pyyntöjä, kulunut kokonaisaika
- Runbookin suoritus — suoritettiinko kaikki automaation komentosarjat onnistuneesti?
Todellisen RTO:n mittaaminen
Käynnistäkää testin aikana ajastin heti, kun käynnistätte testifailoverin. Pysäyttäkää ajastin, kun sovelluksen on todettu olevan kunnossa (kuormantasaajan kuntotarkistus palauttaa arvon 200 OK). Tämä on todellinen RTO. Verratkaa sitä tavoite-RTO:hon. Jos todellinen RTO ylittää tavoitteen, tunnistakaa pullonkaulat — hidas VM:n käynnistyminen, tietokannan pitkä alustusaika tai DNS:n päivittymisen viive — ja korjatkaa ne.
# During DR test, record timestamps:
# T0: Test failover triggered
# T1: All VMs in group 1 (database) running
# T2: All VMs in group 2 (app tier) running
# T3: All VMs in group 3 (web tier) running
# T4: Health probe returns 200 OK on all instances
# Actual RTO = T4 - T0
# Compare to target RTO, document any gapsPalautuspisteen tietojen tarkistaminen
Kun testifailover on valmis, muodostakaa yhteys palautettuun tietokantaan ja tarkistakaa tiedot. Varmistakaa, että ennen replikoinnin katkaisukohtaa vahvistetut tapahtumat ovat mukana ja että osittain vahvistetut tapahtumat käsitellään oikein (perutaan tai viimeistellään). Jos tietokanta tukee point-in-time restorea (PITR), testatkaa palauttamista tiettyyn aikaleimaan ja varmistakaa tietojen odotettu tila.
# Example data verification after test failover:
# 1. Connect to recovered database
# 2. Run: SELECT COUNT(*) FROM orders WHERE created_at > DATEADD(hour, -1, GETUTCDATE())
# 3. Compare count to production database count for the same window
# 4. Check for any orphaned records or constraint violationsSiivous testifailoverin jälkeen
Kun testi on valmis, teidän on poistettava testifailoverin resurssit — toissijaisen alueen testikäytössä olevat VM:t, niiden levyt ja verkkoliitännät. Azure Site Recovery tarjoaa portaalissa toiminnon ’Cleanup test failover’, joka poistaa kaikki testiresurssit automaattisesti. Siivouksen unohtaminen aiheuttaa kustannuksia ja täyttää toissijaisen alueen vanhentuneilla resursseilla.
# Trigger cleanup after test failover:
az site-recovery recovery-plan test-failover-cleanup \
--resource-group myRG \
--vault-name myRecoveryVault \
--name myRecoveryPlan \
--notes 'Test completed. RTO = 22 minutes. All checks passed.'DR-testitulosten dokumentointi
Kirjoittakaa jokaisen DR-testin jälkeen testiraportti, joka sisältää testin päivämäärän ja laajuuden, saavutetut todelliset RTO- ja RPO-arvot, validointikohteiden tarkistuslistan läpäisytiloineen, havaitut puutteet tai virheet sekä suunnitellut korjaavat toimet. Raportista on hyötyä vaatimustenmukaisuuden auditoinneissa (ISO 27001, SOC 2, HIPAA) ja DR-kyvykkyyden kehittymisen seurannassa ajan mittaan.
DR-testauksen tiheys
Alan parhaat käytännöt ja vaatimustenmukaisuuskehykset edellyttävät yleensä DR-testausta vähintään vuosittain, mutta monet organisaatiot testaavat Tier 1 -kuormituksia neljännesvuosittain tai jopa kuukausittain. Tiheämpi testaus havaitsee kokoonpanon ajautumisen aikaisemmin ja vahvistaa tiimin luottamusta sekä rutiinia. Automatisoikaa testauksen valmistelusta ja varmennuksesta mahdollisimman suuri osa, jotta tiheä testaus vaatii vähemmän työtä.
Azure Chaos Studio resiliency-testaukseen
Azure Chaos Studio on hallittu kaaostekniikan palvelu, jonka avulla voitte lisätä hallittuja vikatilanteita Azure-resursseihin sovelluksen vikasietoisuuden testaamiseksi. Voitte sammuttaa VM:iä, aiheuttaa vyöhykkeiden vikaantumisia, rajoittaa suorittimen käyttöä tai lisätä verkon viivettä ja tarkkailla sovelluksen toimintaa. Tavallisesta DR-harjoituksesta poiketen kaaostekniikalla testataan, heikkeneekö sovelluksen toiminta hallitusti osittaisissa vikatilanteissa.
# Chaos Studio experiment: shut down a VM zone
# 1. Create a chaos experiment in the portal
# 2. Select fault: 'VM Shutdown'
# 3. Target: VMs in Zone 1
# 4. Duration: 10 minutes
# 5. Observe: Does Traffic Manager reroute to Zone 2?
# 6. Check: Application health during and after the faultJatkuvan DR-kehityksen sykli
DR-testauksesta on eniten hyötyä osana jatkuvan kehityksen sykliä: Suunnittele → Suorita → Mittaa → Korjaa → Toista. Korjatkaa jokaisen testin jälkeen havaitut puutteet, päivittäkää runbookit ja dokumentaatio ja testatkaa sitten uudelleen. Ajan mittaan ilmoitettujen RTO/RPO-tavoitteiden ja todellisten saavutettujen arvojen välisen eron pitäisi pienentyä, kunnes läpäisette jokaisen testin johdonmukaisesti sallituissa rajoissa.
Pikatesti
Testatkaa tässä oppitunnissa käsiteltyjen Microsoft Azure Fundamentals (AZ-900) -aiheiden ymmärrystänne.
Oppitunnin yhteenveto
Tässä oppitunnissa opitte, että testifailoverin avulla voidaan simuloida DR-tapahtuma keskeyttämättä tuotantoa luomalla VM:istä kopiot eristettyyn VNet-verkkoon; testin aikana on mitattava todellinen RTO ja varmistettava tietojen eheys; ja jokaisen harjoituksen jälkeen on poistettava testiresurssit ja dokumentoitava tulokset. Seuraavaksi tutustumme nimenomaan PaaS-palveluiden, kuten Azure SQL Databasen, katastrofipalautukseen.
Opi Cloud & IT Cert Prep tekoälytuutorin avulla — ilmaiseksi
Kirjoita ja suorita oikeaa koodia selaimessa, saa välitöntä apua tekoälytuutorilta ympäri vuorokauden ja jatka siitä, mihin jäit, verkossa tai sovelluksessa.
- Kurssit
- 150
- Oppitunnit
- 600
Usein kysytyt kysymykset
Onko oppitunti ”DR-testaus ilman vaikutuksia” ilmainen?
Kyllä – oppitunnin ”DR-testaus ilman vaikutuksia” koko tekstin voi lukea täällä verkossa ilmaiseksi. Jos haluat harjoitella interaktiivisesti sisäänrakennetulla koodieditorilla ja ympäri vuorokauden käytettävissä olevan tekoälytuutorin avulla sekä avata koko Cloud & IT Cert Prep-kurssin, päivitä CoddyKit PROhon. Cloud & IT Cert Prep-kurssilla on yhteensä 4 oppituntia.
Mitä opin oppitunnilla ”DR-testaus ilman vaikutuksia”?
Suorita testiä varten vikasietoinen siirto eristettyyn verkkoon palautussuunnitelman päästä päähän -validointia varten, mittaa todellinen RTO ja dokumentoi korjausta vaativat puutteet Harjoittelet Cloud & IT Cert Prep-aihetta koodilla, jonka suoritat suoraan selaimessa. Ympäri vuorokauden käytettävissä oleva tekoälytuutori vastaa kysymyksiisi oppitunnin aikana.
Tarvitsenko kokemusta aloittaakseni Cloud & IT Cert Prep-opiskelun?
Aiempi kokemus ei ole tarpeen. CoddyKitin Cloud & IT Cert Prep-oppimispolku sopii vasta-alkajista edistyneisiin, joten voit aloittaa tästä tai alusta ja edetä omaan tahtiisi. Tämä on oppitunti 3/4.
Kuinka kauan ”DR-testaus ilman vaikutuksia”-oppitunnin suorittaminen kestää?
Useimmat CoddyKitin oppitunnit kestävät noin 5–10 minuuttia. Jokainen oppitunti on lyhyt ja interaktiivinen, joten edistyt tasaisesti ja voit jatkaa siitä, mihin jäit – sekä verkossa että sovelluksessa.
Voinko kirjoittaa ja suorittaa koodia tällä Cloud & IT Cert Prep-oppitunnilla?
Kyllä. Jokainen Cloud & IT Cert Prep-oppitunti sisältää sisäänrakennetun koodieditorin, joten voit kirjoittaa ja suorittaa oikeaa koodia suoraan selaimessa ja saada välitöntä palautetta tekoälyltä – paikallista asennusta ei tarvita.
Kaikki tämän kurssin oppitunnit
- RTO:n, RPO:n ja palautustasojen määrittäminen
- Palautussuunnitelmat ja automaattinen vikasietoisuus
- DR-testaus ilman vaikutuksia
- PaaS-palveluiden DR