Vikasietovaihdon testaaminen ja suorittaminen

Katastrofipalautussuunnitelma, jota ei ole koskaan testattu, on vain oletus. Test failover -toiminnolla voit varmistaa, että virtuaalikoneet käynnistyvät oikein, sovellukset käynnistyvät ja verkkoyhteydet toimivat kohdealueella ilman, että lähdeympäristöön tai käynnissä olevaan replikointiin aiheutuu häiriöitä. Monet organisaatiot havaitsevat katastrofipalautussuunnitelmiensa puutteet vasta todellisen katastrofin aikana, juuri silloin kun toimimaton suunnitelma aiheuttaa eniten vahinkoa. Säännölliset test failover -suoritukset ovat useimpien sääntelykehysten edellyttämiä.

ASR tukee kolmea failover-toimintotyyppiä. Test failover luo failover-tilanteessa olevista virtuaalikoneista kopiot eristettyyn verkkoon (määrität kohde-VNetin) vaikuttamatta replikointiin tai lähdeympäristöön. Planned failover -toimintoa käytetään ajoitettuihin siirtoihin tai huoltoon: se synkronoi ensin jäljellä olevat muutokset ja sammuttaa sitten lähteen ennen failoveria. Unplanned failover -toiminto, jota käytetään todellisen katastrofin aikana, suorittaa failoverin välittömästi viimeisimmästä palautuspisteestä odottamatta viimeistä synkronointia.

Suorita test failover portaalissa seuraavasti: valitse suojattu kohde, napsauta Test Failover, valitse palautuspiste (viimeisin kaatumisenmukainen, viimeisin sovelluksenmukainen tai tietty ajankohta) ja valitse kohdevirtuaaliverkko (yleensä erillinen eristetty testikäyttöön tarkoitettu VNet). ASR käynnistää virtuaalikoneen kohdealueella replikoitujen levyjen avulla. Testivirtuaalikone näkyy replikan rinnalla, mutta se on täysin itsenäinen, joten tuotantoympäristöön ei vaikuteta. Testauksen jälkeen poista testivirtuaalikoneet napsauttamalla Cleanup test failover.

Failoverin aikana valitset palautuspisteen ASR:n säilytysikkunasta. Vaihtoehdot ovat seuraavat: Latest (lowest RPO) – ajantasaisin kaatumisenmukainen palautuspiste, joka minimoi tietojen menetyksen. Latest processed – viimeksi käsitelty piste, joka voi olla muutaman minuutin jäljessä. Latest app-consistent – viimeisin sovelluksenmukainen palautuspiste, joka voi olla vanhempi mutta takaa sovelluksen siistin palautumisen. Custom – tietty vanhempi palautuspiste, jonka avulla voidaan palauttaa ympäristö tunnetusti toimivaan tilaan ennen tapahtumaa.

Palautussuunnitelma ryhmittelee useita suojattuja virtuaalikoneita ja määrittää niiden failoverin järjestyksen ja ajoituksen. Voit määrittää, mitkä virtuaalikoneet käynnistetään ensin (esimerkiksi tietokantapalvelimet ennen sovelluspalvelimia), lisätä manuaalisia hyväksymisvaiheita failoverin keskeyttämiseksi ihmisen tekemää tarkistusta varten ja lisätä Azure Automation -runbookeja ennen failoveria ja sen jälkeen suoritettaville komentosarjoille (esimerkiksi DNS-tietueiden päivittämiseen, kuormantasaajien määrittämiseen tai ilmoitusten lähettämiseen). Palautussuunnitelmat voidaan testata erikseen test failover -toiminnolla.

Test failover tarjoaa mahdollisuuden mitata todellisen RTO:n (Recovery Time Objective). Käynnistä ajanotto, kun aloitat failoverin, ja pysäytä se, kun sovellus toimii täysin ja on käyttäjien käytettävissä. Azure-alueiden välinen failover valmistuu yleensä 15–30 minuutissa yksittäisen virtuaalikoneen tapauksessa, mutta riippuvuuksia sisältävien monitasoisten sovellusten suorittaminen voi kestää kauemmin. Kirjaa kaikki odottamatonta aikaa vievät vaiheet, kuten DNS:n päivittyminen ja sovelluksen lämmitys, ja korjaa ne ennen seuraavaa testiä.

Planned failover -toiminnon jälkeen, esimerkiksi uudelle alueelle siirryttäessä, suorita Commit viimeistelläksesi failoverin. Commit-toiminto lopettaa replikoinnin lähteestä takaisin ja merkitsee kohteen virtuaalikoneet uusiksi ensisijaisiksi virtuaalikoneiksi. Kun toiminto on vahvistettu, voit ottaa käyttöön re-protection-toiminnon replikointisuunnan kääntämiseksi, jolloin alkuperäisestä lähdealueesta tulee uusi katastrofipalautuksen kohde. Näin voit suorittaa failbackin alkuperäiselle alueelle tapahtuman ratkaisemisen jälkeen.

Failback tarkoittaa työkuormien palauttamista alkuperäiselle alueelle katastrofin tai suunnitellun siirron jälkeen. Vaiheet ovat seuraavat: suojaa failoverin kohteena olleet virtuaalikoneet uudelleen (käännä replikointisuunta niin, että replikointi tapahtuu uudesta ensisijaisesta ympäristöstä alkuperäiselle alueelle), odota alustavan synkronoinnin valmistumista ja suorita sitten planned failover takaisin alkuperäiselle alueelle. Failback edellyttää, että alkuperäinen lähdeinfrastruktuuri on edelleen ehjä. Jos se on tuhoutunut, landing zone on ehkä rakennettava uudelleen ennen failbackin suorittamista.

Test failoverin jälkeen sinun on suoritettava portaalissa Cleanup test failover testivirtuaalikoneiden ja niihin liittyvien levyjen poistamiseksi. Ilman puhdistusta testivirtuaalikoneet jatkavat toimintaansa ja aiheuttavat laskentakustannuksia. Puhdistusvaihe myös palauttaa suojatun kohteen test failover -tilan, joten voit suorittaa uuden testin myöhemmin. Puhdistuksen automatisointi, esimerkiksi ajoittamalla se tunnin päähän testin alkamisesta Automation-runbookin avulla, estää unohdettuja testivirtuaalikoneita toimimasta päiväkausia.

Jokaisesta katastrofipalautustestistä tulee laatia katastrofipalautusharjoituksen raportti, joka sisältää testin päivämäärän ja skenaarion, käytetyt palautuspisteet, saavutetut RTO- ja RPO-arvot, havaitut ongelmat sekä tehdyt korjaavat toimet. Tämä dokumentaatio täyttää ISO 27001:n ja SOC 2:n kaltaisten viitekehysten tarkastusvaatimukset, joissa edellytetään säännöllistä katastrofipalautuksen testaamista. Säilytä harjoitusraportit suojatussa sijainnissa, joka on sekä IT-tiimien että liiketoiminnan jatkuvuudesta vastaavien tiimien käytettävissä.

Azure Site Recoveryn hinnoittelu perustuu suojattuun instanssiin kuukaudessa. Maksu kattaa sekä replikointipalvelun että orkestroinnin. Lisäksi maksat kohdealueen replikoitujen hallinnoitujen levyjen käyttämästä tallennustilasta sekä replikoinnin aikana käytettävästä välimuistitallennustilistä. Azure-alueiden välisestä replikoidun liikenteen ulosmenevästä tiedonsiirrosta veloitetaan normaalien ulosmenevän liikenteen hintojen mukaisesti (toisin kuin Azure Backupissa, jossa yhdistettyjen alueiden välinen ulosmenevä liikenne on maksutonta). Paikallisesta ympäristöstä Azureen tapahtuvassa replikoinnissa Azure-virtuaalikoneiden Windows Server -lisensseihin voidaan soveltaa Azure Hybrid Benefit -etua kustannusten pienentämiseksi.

Tässä oppitunnissa opit, että test failover vahvistaa katastrofipalautussuunnitelmasi eristetyssä verkossa vaikuttamatta tuotantoympäristöön, palautussuunnitelmat määrittävät usean virtuaalikoneen failover-järjestyksen manuaalisine hyväksymisvaiheineen ja Automation-runbook-vaiheineen ja failback palauttaa työkuormat alkuperäiselle alueelle kääntämällä replikointisuunnan katastrofin jälkeen. Seuraavaksi tutustumme Azure CDN:ään maailmanlaajuisen sisällönjakelun nopeuttamiseksi.