Käyttökokemukseen liittyvät järjestelmäpalautuksen ohjeet

Tämä artikkeli tarjoaa kokemuskohtaisia ohjeita Fabric-tietojesi palauttamiseen alueellisen katastrofin sattuessa.

Näyteskenaario

Monissa tämän artikkelin ohjeosioissa käytetään seuraavaa esimerkkiskenaariota selityksenä ja havainnollistuksena. Palaa tähän skenaarioon tarpeen mukaan.

Oletetaan, että sinulla on kapasiteetti C1 alueella A, jossa on työtila W1. Jos olet kytkenyt katastrofipalautuksen käyttöön C1-kapasiteetilla, OneLake-data replikoidaan varmuuskopioon alueella B. Jos alue A kohtaa häiriöitä, Fabric-palvelu C1:ssä siirtyy alueelle B.

Seuraava kuva havainnollistaa tätä skenaariota. Vasemmalla oleva laatikko näyttää häiriintyneen alueen. Keskellä oleva ruutu edustaa tietojen jatkuvaa käytettävyyttä vikasietoisuuden jälkeen ja oikealla olevassa ruudussa näkyy täysin käsitelty tilanne sen jälkeen, kun asiakas on palauttanut palvelunsa täyteen toimintaan.

Tässä on yleinen palautussuunnitelma:

1. Luo uusi Fabric-kapasiteetti C2 uudella alueella.

2. Luo uusi W2-työtila C2:ssa, mukaan lukien sitä vastaavat kohteet, joilla on samat nimet kuin C1:llä. W1.

3. Kopioi tiedot häirinnästä C1:stä. W1–C2. W2.

4. Palauta kohteet täyteen toimintoonsa noudattamalla kunkin komponentin erillisiä ohjeita.

Tämä elvytyssuunnitelma olettaa, että vuokralaisen kotialue pysyy toiminnassa. Jos vuokralaisen kotialueella ilmenee katko, tässä artikkelissa esitetyt toimenpiteet riippuvat sen palauttamisesta, joka on ensin käynnistettävä ja suoritettava Microsoft:n toimesta.

Käyttökokemuskohtaiset palautussuunnitelmat

Seuraavat osiot tarjoavat vaiheittaiset oppaat jokaiselle Fabric-kokemukselle, jotka auttavat sinua toipumisprosessin läpi.

Tietotekniikka

Tässä oppaassa käydään läpi tietotekniikkakokemuksen palautusmenettelyt. Se kattaa järvenrakennukset, muistikirjat, Spark-tehtävämäärittelyt, käyttäjätietotoiminnot ja GraphQL-rajapinnat.

Lakehouse

Lakehouset alkuperäiseltä alueelta eivät ole saatavilla asiakkaille. Lakehousen palauttamiseksi asiakkaat voivat luoda sen uudelleen työtilassa C2. W2. Suosittelemme kahta lähestymistapaa lakehousen toipumiseen:

Menetelmä 1: Lakehouse Delta -taulukoiden ja -tiedostojen kopioiminen mukautetun komentosarjan avulla

Asiakkaat voivat luoda lakehouse-taloja uudelleen käyttämällä mukautettua Scala-komentosarjaa.

1. Luo Lakehouse (esimerkiksi LH1) juuri luodussa työtilassa C2. W2.

2. Luo uusi muistikirja työtilaan C2. W2.

3. Alkuperäisen järvenrakennuksen taulukoiden ja tiedostojen palauttamiseksi katso OneLake-polkujen dataa, kuten abfss (katso Connecting to Microsoft OneLake). Voit käyttää seuraavaa koodiesimerkkiä (katso Johdatus Microsoft Spark Utilitiesiin) muistikirjassa saadaksesi ABFS-polut tiedostoista ja taulukoista alkuperäisestä lakehousesta. (Korvaa C1.W1 varsinaisella työtilan nimellä)

   notebookutils.fs.ls('abfs[s]://<C1.W1>@onelake.dfs.fabric.microsoft.com/<item>.<itemtype>/<Tables>/<fileName>')
   

4. Käytä seuraavaa koodiesimerkkiä taulukoiden ja tiedostojen kopioimiseen juuri luotuun Lakehouse-järjestelmään.

   1. Delta-taulukoiden tapauksessa sinun on kopioitava taulukko yksi kerrallaan, jotta voit palauttaa sen uudessa Lakehousessa. Lakehouse-tiedostojen tapauksessa voit kopioida koko tiedostorakenteen ja kaikki pohjana olevat kansiot yhdellä suorituksella.

   2. Ota yhteyttä tukitiimiin komentosarjassa vaaditun vikasietoisuuden aikaleiman osalta.

   %%spark
   val source="abfs path to original Lakehouse file or table directory"
   val destination="abfs path to new Lakehouse file or table directory"
   val timestamp= //timestamp provided by Support
   
   notebookutils.fs.cp(source, destination, true)
   
   val filesToDelete = notebookutils.fs.ls(s"$source/_delta_log")
       .filter{sf => sf.isFile && sf.modifyTime > timestamp}
   
   for(fileToDelete <- filesToDelete) {
       val destFileToDelete = s"$destination/_delta_log/${fileToDelete.name}"
       println(s"Deleting file $destFileToDelete")
       notebookutils.fs.rm(destFileToDelete, false)
   }
   
   notebookutils.fs.write(s"$destination/_delta_log/_last_checkpoint", "", true)
   

5. Kun olet suorittanut komentosarjan, taulukot tulevat näkyviin uuteen lakehouseen.

Lähestymistapa 2: Käytä Azure Storage Explorer tiedostojen ja taulukoiden kopioimiseen

Jos haluat palauttaa vain tietyt Lakehouse-tiedostot tai -taulukot alkuperäisestä Lakehousesta, käytä Azure Storage Explorer -ohjelmaa. Katso Integrate OneLake with Azure Storage Explorer yksityiskohtia varten. Jos tietokoko on suuri, käytä menetelmää 1.

Restoring Fabric materialisoituja järvinäkymiä

Failoverin jälkeen et pääse käsiksi alkuperäisen alueen materialisoituihin järvinäkymiin. Failover-prosessi ei toista päivitysaikatauluja tai suoritushistoriaa toissijaiselle alueelle. Näiden esineiden palauttamiseksi suorita seuraavat vaiheet Lakehouse-tietojen palauttamisen jälkeen:

• Palauta Lakehouse-taulukot käyttämällä aiemmin tässä artikkelissa kuvattua lähestymistapaa 1 tai lähestymistapa 2 . Kopioi vain lähdetaulukot.
• Palauta muistikirjat, jotka sisältävät MLV-määritelmäsi. Toipumisvaiheet löytyvät Notebook-osiosta .
• Suorita palautetut muistikirjat luodaksesi MLV:t uudelleen uudessa Lakehousessa. Lisätietoja MLV:iden luomisesta löytyy kohdasta Create a Materialized Lake View. Jos kopioit MLV:t aiemmassa vaiheessa, suorita CREATE OR REPLACE kun luot ne uudelleen.
• Luo MLV:n päivitysaikataulut manuaalisesti uudessa työtilassa. Et voi palauttaa aikatauluhistoriaa tai suoritusmittareita.
• Jos MLV:si syöttävät semanttisia malleja tai raportteja, varmista ja päivitä Lakehouse-tunnuksen ja datasetin ID-viittaukset tarpeen mukaan. Yhdistä raportit päivitettyyn semanttiseen malliin ja varmista datan tuoreus.

Muistikirja

Pääalueen muistikirjat pysyvät asiakkaiden käytettävissä, eikä muistikirjojen koodi replikoitu toissijaiselle alueelle. Palauttaaksesi muistikirjan koodin uudelle alueelle, käytä jotakin seuraavista tavoista.

Lähestymistapa 1: Käyttäjän hallitsema redundanssi Git-integroinnin avulla (julkisessa esikatselussa)

Käytä Fabric Git -integraatiota synkronoidaksesi muistikirjasi Azure DevOps (ADO) -reposi kanssa. Kun palvelu siirtyy toiselle alueelle, käytä repositoa rakentaaksesi muistikirjan uudelleen uudessa luomassasi työtilassa.

1. Määritä työtilan Git-integrointi ja valitse Yhdistä ja synkronoi ADO-säilön kanssa.

   

   Seuraavassa kuvassa näkyy synkronoitu muistikirja.

   

2. Palauta muistikirja ADO-säilöstä.

   1. Yhdistä uudelleen Azure ADO -repositioon uudessa työtilassa.

      

   2. Valitse Lähde-ohjausobjektin painike. Valitse sitten säilön asianmukainen haara. Valitse sitten Päivitä kaikki. Alkuperäinen muistikirja tulee näkyviin.

      

      

   3. Jos alkuperäisessä muistikirjassa on oletusjärvimajoitus, katso Lakehouse-osiosta saadaksesi järvimajan takaisin ja yhdistä sitten juuri palautettu järvitalo juuri palautettuun muistikirjaan.

      

   4. Git-integrointi ei tue muistikirjan resurssienhallinnan tiedostojen, kansioiden tai muistikirjojen tilannevedosten synkronointia.

      1. Jos alkuperäisessä muistikirjassa on tiedostoja muistikirjan resurssienhallinnassa:

         1. Tallenna tiedostoja tai kansioita paikalliselle levylle tai toiseen paikkaan.

         2. Lataa tiedosto uudelleen paikalliselta levykkeeltä tai pilviasemista palautettuun muistikirjaan.

      2. Jos alkuperäisessä muistikirjassa on muistikirjasta tilannevedos, tallenna muistikirjatilannevedos myös omaan versiontarkistusjärjestelmääsi tai paikalliseen levyyn.

         

         

Lisätietoja Git-integroinnista on artikkelissa Johdanto Git-integrointiin.

Lähestymistapa 2: Koodisisällön varmuuskopiointi manuaalinen lähestymistapa

Jos et käytä Git-integraatiomenetelmää, tallenna uusin koodiversio, tiedostot resurssienhallintaan ja muistikirjan snapshotin versionhallintajärjestelmään, kuten Gitiin. Palauta muistikirjan sisältö manuaalisesti katastrofin jälkeen:

1. Käytä Tuo muistikirja -toimintoa tuodaksesi muistikirjan koodin, jonka haluat palauttaa.

   

2. Tuonnin jälkeen siirry haluamaasi työtilaan (esimerkiksi "C2. W2") siihen pääsemiseksi.

3. Jos alkuperäisessä muistikirjassa on oletus lakehouse, katso Lakehouse-osaa. Yhdistä sitten äskettäin löydetty lakehouse (jolla on sama sisältö kuin alkuperäisellä oletusjärvitalolla) äskettäin palautettuun muistikirjaan.

4. Jos alkuperäisessä muistikirjassa on tiedostoja tai kansioita resurssienhallinnassa, lataa käyttäjän versionhallintajärjestelmään tallennetut tiedostot tai kansiot uudelleen.

Spark-työn määritys

Spark-työn määrittelyt (SJD) ensisijaiselta alueelta ovat edelleen käytettävissä, ja OneLake replikoi päämäärittelytiedoston ja viitetiedoston muistikirjassa toissijaiselle alueelle. Jos haluat palauttaa SJD:n uudella alueella, seuraa tässä osiossa kuvattuja manuaalisia vaiheita. SJD:n historiallisia juoksuja ei löydetä.

Voit palauttaa SJD-kohteet kopioimalla koodin alkuperäiseltä alueelta käyttämällä Azure Storage Explorer -ohjelmaa ja yhdistämällä Lakehouse-viitteet manuaalisesti uudelleen katastrofin jälkeen.

1. Luo uusi SJD-alkio (esimerkiksi SJD1) uuteen työtilaan C2. W2, samoilla asetuksilla ja kokoonpanoilla kuin alkuperäisessä SJD-alkiossa (esim. kieli, ympäristö jne.).

2. Käytä Azure Storage Explorer -ohjelmaa kopioimaan Libs, Mains ja Snapshots alkuperäisestä SJD-alkiosta uuteen SJD-kohteeseen.

   

3. Koodisisältö näkyy uudessa SJD:ssä. Sinun täytyy lisätä manuaalisesti juuri palautettu Lakehouse-viittaus työhön (katso Lakehousen palautusvaiheet). Käyttäjien täytyy syöttää alkuperäiset komentoriviargumentit manuaalisesti uudelleen.

   

Nyt voit ajaa tai ajoittaa äskettäin toipuneet SJD: si.

Lisätietoja Azure Storage Explorer:sta löytyy kohdasta Integrate OneLake with Azure Storage Explorer.

Käyttäjätietojen toiminnot

Palauttaaksesi käyttäjätietosi toiminnot terveellä alueella, käytä jotakin seuraavista tavoista.

Lähestymistapa 1: Git-integraatiolla (suositeltava)

Suosituin palautusmekanismi on Fabric Git -integraatio. Synkronoimalla käyttäjätietofunktioprojektit Azure DevOps- tai GitHub-repositorion kanssa voit nopeasti rekonstruoida ne uudessa työtilassa failoverin jälkeen.

Valmistaudu ennen katastrofia

1. Määritä Fabric Git -integraatio työtilalle, jossa käyttäjätietotoiminto toimii.
2. Yhdistä työtila Azure DevOps- tai GitHub-repositorioon.
3. Sitou kaikki käyttäjätietotoiminnot repositorioon ja synkronoi muutokset säännöllisesti.
4. Tallenna ympäristökohtaiset asetukset erikseen muuttuviin kirjastoihin tarvittaessa.

Toipumisvaiheet

Alueellisen katastrofin jälkeen:

1. Luo uusi Fabric-kapasiteetti terveellä alueella, kuten C2.
2. Luo uusi työtila, kuten W2, uudessa kapasiteetissa.
3. Yhdistä työtila samaan Azure DevOps- tai GitHub-repositorioon.
4. Avaa lähdekoodin hallinta ja synkronoi tietovaraston sisältö työtilaan.
5. Luo tai palauta kaikki riippuvaiset Fabric-resurssit, kuten järvenrakennukset, SQL-tietokannat Fabric:ssa, varastot ja liiketoimintatapahtumat.
6. Palauta käyttäjätietofunktiot.
7. Validoi funktioiden suoritus ja riippuvuusyhteydet.
8. Päivitä alavirran sovelluksia, dataputkia tai muita integroituja, jotka viittaavat palautettuihin toimintoihin.
9. Täydellinen kaikkien skenaarioiden täydellinen validointi.

Tärkeitä huomioon otettavia seikkoja

• Git-integraatio palauttaa vain lähdekoodin ja projektin resurssit.
• Historiallisia teloituslokkeja ei löydetä.
• Alavirran järjestelmät saattavat vaatia päätepisteiden uudelleensitomista.

Lisätietoja löytyy käyttäjätietofunktioiden lähdekoodin hallinnasta ja käyttöönotosta.

Lähestymistapa 2: Manuaalinen palautus

Jos Git-integraatiota ei ole konfiguroitu ennen katastrofia, voit manuaalisesti rekonstruoida käyttäjädatan toiminnot lähdekoodin varmuuskopioista.

Valmistaudu ennen katastrofia

Suorita säännöllisesti seuraavat tehtävät ja tallenna kohteet ulkoiseen lähdekoodin hallintavarastoon tai varmuuskopiointipaikkaan:

• Vie funktion lähdekoodi GitHub-repositorioon.
• Dokumentoi ja säilytä riippuvuustiedot.
• Dokumentointiympäristön asetukset.

Toipumisvaiheet

Alueellisen katastrofin jälkeen:

1. Luo uusi Fabric-kapasiteetti terveellä alueella, kuten C2.
2. Luo uusi työtila, kuten W2.
3. Palauta kaikki toiminnon vaatimat resurssit, mukaan lukien järvirakennukset, SQL-tietokannat Fabric-ohjelmassa, varastot, tapahtumapaikat ja ulkoiset palvelut.
4. Luo uusi käyttäjätietofunktioprojekti.
5. Tuo tai luo uudelleen funktion lähdekoodi.
6. Aseta ajonaikaiset konfiguraatioasetukset uudelleen.
7. Asenna kaikki funktio-riippuvuudet uudelleen.
8. Ota toiminto uudelleen käyttöön.
9. Uudelleenmääritä tunnistautuminen ja valtuutus.
10. Recreate Business Event -julkaisijat tai kuluttajat, jos niitä käytetään.
11. Suorita kokonaisvaltainen validointitestaus skenaarioillesi ja integraatioillesi.

GraphQL

GraphQL:n kohteet ensisijaiselta alueelta eivät ole saatavilla alueellisen katastrofin jälkeen, eikä GraphQL:n määritelmiä ja konfiguraatioita replikoidu toissijaiselle alueelle. GraphQL:n palauttamiseksi uudella alueella käytä jotakin seuraavista menetelmistä.

Lähestymistapa 1: Käyttäjän hallinnoima redundanssi Git-integraation avulla

Paras tapa tehdä tästä prosessista helppo ja nopea on käyttää Fabric Git -integraatiota ja synkronoida GraphQL ADO-reposi kanssa. Kun palvelu siirtyy toiselle alueelle, voit käyttää repositoa rakentaaksesi GraphQL:n uudelleen uudessa työtilassa, jonka luot.

1. Luo uusi työtila tavoitekapasiteetille ja alueelle.

2. Palauta kaikki riippuvaiset tietolähteet, kuten Lakehouse-, Warehouse- tai SQL-tietokannat, noudattamalla niiden palautusvaiheita.

3. Päivitä GraphQL:n määritelmä osoittamaan juuri palautettuihin resursseihin muokkaamalla ympäristökohtaisia viittauksia, kuten lähdetyötilan ID:itä, lähdekohteiden tunnisteita ja yhteystietoja. Tämä vaihe varmistaa oikean sitomisen käyttöönoton yhteydessä.

4. Palauta GraphQL-kohteet Git-varastosta uuteen työtilaan. Tämä vaihe luo API-rakenteen ja konfiguroinnin uudelleen käyttämällä päivitettyjä määritelmiä.

5. Ota uudelleen käyttöön tehtäväasetukset, mukaan lukien roolit, käyttöoikeudet ja todennusasetukset.

6. Käytä päätepisteviittauksia uudelleen päivittämällä sovellukset tai integraatiot käyttämään juuri luotua GraphQL-päätelaitetta.

7. Päivitä kaikki olemassa olevat käyttöönottoputket, jotka osoittivat vanhaan työtilaan, viittaamaan uuteen työtilaan.

8. Validoi API:n päästä päähän -toiminnallisuus.

Lähestymistapa 2: Manuaalinen lähestymistapa

Jos et käytä Git-integraatiomenetelmää, voit käyttää seuraavaa manuaalista lähestymistapaa GraphQL:n palauttamiseen.

1. Luo uusi työtila tavoitekapasiteetille ja alueelle.

2. Palauta kaikki riippuvaiset tietolähteet, kuten Lakehouse-, Warehouse- tai SQL-tietokannat.

3. Luo GraphQL API manuaalisesti uudessa työtilassa, mukaan lukien skeemamäärittelyt, tietolähteiden yhteydet ja suhteet.

4. Ota uudelleen käyttöön tehtäväasetukset, mukaan lukien roolit, käyttöoikeudet ja todennusasetukset.

5. Käytä päätepisteviittauksia uudelleen päivittämällä sovellukset tai integraatiot käyttämään juuri luotua GraphQL-päätelaitetta.

6. Päivitä kaikki olemassa olevat käyttöönottoputket, jotka osoittivat vanhaan työtilaan, viittaamaan uuteen työtilaan.

7. Validoi API:n päästä päähän -toiminnallisuus.

Tärkeitä huomioon otettavia seikkoja

1. GraphQL perustuu ulkoisiin riippuvuuksiin (kuten Lakehouse, Warehouse ja SQL), jotka täytyy palauttaa ennen GraphQL:n käyttöönottoa.

2. GraphQL API -määritelmät sisältävät ympäristökohtaisia viittauksia (kuten sourceWorkspaceId ja sourceItemId). Toipuessa uudella alueella nämä viittaukset voivat menettää merkityksensä. Päivitä ne osoittamaan juuri varattuja resursseja.

3. Tietolähteiden automaattinen uudelleensitominen ei ole taattua katastrofipalautustilanteissa, erityisesti tallennettujen tunnuksia tai työtilan välisiä yhteyksiä käytettäessä.

4. Muut esineasetukset, kuten valvonta, valtuutus, RBAC, itsetutkiskelu ja muut, eivät siirry varayhteyden jälkeen. Sinun täytyy palauttaa nämä asetukset uudessa alueessa.

Viitteet

• Yleiskatsaus Fabric Git -integraatioon - Microsoft Fabric | Microsoft Learn

• Lähdekoodin hallinta ja käyttöönottoputket API:ssa GraphQL:lle - Microsoft Fabric | Microsoft Learn 

Sovellus

Järjestelmä ei kopioi Fabric-sovelluksia, mukaan lukien niiden koodi, kokoonpano ja metatiedot, toissijaisille alueille. Jos pääalue epäonnistuu, sovellus pysyy poissa käytöstä. Palautusta varten tallenna sovelluksen lähdekoodi järjestelmän ulkopuolelle GitHub:iin, Azure DevOps:iin tai muuhun ohjelmistonhallintajärjestelmään. Palauta sovellustiedot erikseen noudattamalla katastrofipalautusohjeita jokaiselle taustalla olevalle Fabric-datavarastolle.

Manuaalinen lähestymistapa

Voit manuaalisesti palauttaa Fabric-sovelluksen alueellisen katastrofin jälkeen käyttämällä sovelluksen lähdekoodia ja Rayfin CLI:tä. 

Edellytykset 

Ennen kuin katastrofi tapahtuu:

• Tallenna Fabric App -lähdekoodi GitHub:iin, Azure DevOps:iin tai muuhun lähdekoodin hallintavarastoon. 

• Dokumentoi toipumisprosessi.  

Toipumisvaiheet 

1. Luo uusi työtila tavoitekapasiteetille ja alueelle. 

2. Palauta riippuvaiset resurssit ennen sovelluksen uudelleenkäyttöönottoa.  

3. Hae uusin Fabric App -lähdekoodi ohjelmistosi tai paikallisesta varmuuskopiosta. 

4. Sovelluksen lähdehakemistosta Fabric-sovellus otetaan käyttöön palautustyötilassa käyttämällä Rayfin CLI:tä. Suorita rayfin up --workspace <new workspace>. 

5. Palauta sovelluksen lapsikohde (SQL-tietokanta Fabric-muodossa) noudattamalla sen vastaavia palautusmenettelyjä.  

6. Lisää esinetasoasetukset, mukaan lukien roolit ja käyttöoikeudet, tarpeen mukaan.  

7. Varmista sovelluksen toiminnallisuus ja varmista, että käyttäjillä on oikeat oikeudet.  

Tärkeää 

• Pidä Fabric App -lähdekoodi Fabric-alueen ulkopuolella palautuksen mahdollistamiseksi.  

• Sovellustietoja tietokannasta ei palauteta osana Fabric App -käyttöönottoprosessia, vaan ne on palautettava erikseen.  Voit manuaalisesti palauttaa Fabric-sovelluksen alueellisen katastrofin jälkeen käyttämällä sovelluksen lähdekoodia ja Rayfin CLI:tä. 

Azure Databricks Storage

Azure Databricks Storage tallentaa dataa OneLake-tiedostoon. Suojataksesi tietosi alueelliselta katkosilta, ota käyttöön katastrofipalautusasetus Fabric-kapasiteetissa, joka sisältää Azure Databricks Storage -kohteen. Kun otat tämän asetuksen käyttöön, OneLake replikoi datan asynkronisesti Azure-yhdistetylle alueelle.

Jos OneLake käynnistää alueellisen failoverin, sovellukset voivat jatkaa replikoidun datan käyttöä OneLaken globaalin päätepisteen kautta failoverin päätyttyä. Jatkuva pääsy OneLake-julkisten API-rajapintojen kautta ei vaadi uuden Azure Databricks Storage -kohteen luomista tai datan kopioimista toiseen työtilaan.

Tutustu OneLake Disaster Recovery and Data Protection -ohjelmaan sovellettua käyttäytymistä, huomioitavia seikkoja ja rajoituksia.

Azure Databricks -kohtaiseen katastrofipalautussuunnitteluun katso Disaster recovery - Azure Databricks.

Datatiede

Tässä oppaassa käydään läpi tietojenkäsittelykokemuksen palautusmenettelyt. Se kattaa koneoppimismallit ja -kokeet.

ML-malli ja koe

Data-analytiikan kohteet ensisijaiselta alueelta eivät ole asiakkaiden saatavilla, eikä koneoppimismallien ja kokeiden sisältö ja metatiedot toistu toissijaiselle alueelle. Jos haluat palauttaa ne täysin uudella alueella, tallenna koodisisältö versiontarkistusjärjestelmään (kuten Git) ja suorita koodisisältö manuaalisesti uudelleen katastrofin jälkeen.

1. Palauta muistikirja. Katso muistikirjan palautusvaiheet.

2. Konfiguraatio, perinteiset suoritetut mittarit ja metatiedot eivät replikoidu paritetun alueen mukaan. Sinun täytyy ajaa jokainen data-analytiikkakoodisi versio uudelleen, jotta koneoppimismallit ja kokeet palautuvat täysin katastrofin jälkeen.

tietovarasto

Tämä opas käy läpi Fabric tietovarasto työkuorman palautusprosessit. Se kattaa varaston tavarat.

Varasto

Et pääse varastoihin alkuperäiseltä alueelta. Jos haluat palauttaa varastoja, suorita seuraavat kaksi vaihetta.

1. Luo uusi väliaikainen järvirakennus työtilassa C2. W2 alkuperäisestä varastosta kopioimasi datan vuoksi.

2. Täytä varaston Delta-taulukot käyttämällä varaston Explorer- ja T-SQL-ominaisuuksia (katso Taulukot Fabric tietovarasto).

Tietojen käsittely Lakehousen ja T-SQL-koodin kautta

Juuri luodussa työtilassa C2. W2:

1. Luo väliaikainen lakehouse "LH2" C2:ssa. W2.

2. Palauta väliaikaisessa lakehouse-varastossa olevat Delta-taulukot alkuperäisestä varastosta Lakehousen palautusvaiheiden mukaisesti.

3. Luo uusi varasto "WH2" C2:ssa. W2.

4. Yhdistä väliaikainen lakehouse varastosi hallinnassa.

5. Riippuen siitä, miten taulukkomäärittelyt otetaan käyttöön ennen datan tuontia, todellinen T-SQL voi vaihdella tuontiin. Varastotaulukoiden palauttamiseksi järvitaloista voit käyttää INSERT INTO, SELECT INTO, tai CREATE TABLE AS SELECT lähestymistapaa. Seuraavassa esimerkissä käytämme INSERT INTO. Jos käytät seuraavaa koodia, korvaa näytteet varsinaisilla taulukoiden ja sarakkeiden nimillä.

   USE WH1
   
   INSERT INTO [dbo].[aggregate_sale_by_date_city]([Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit])
   
   SELECT [Date],[City],[StateProvince],[SalesTerritory],[SumOfTotalExcludingTax],[SumOfTaxAmount],[SumOfTotalIncludingTax], [SumOfProfit]
   FROM  [LH11].[dbo].[aggregate_sale_by_date_city] 
   GO
   

6. Vaihda yhteysmerkkijono sovelluksissa, jotka käyttävät Fabric-varastoasi.

Peilattu tietokanta

Asiakkaat eivät pääse käsiksi peilattuihin tietokantoihin ensisijaiselta alueelta, eikä asetukset toistu toissijaiselle alueelle. Peilatun tietokannan palauttamiseksi alueellisen vian jälkeen sinun täytyy luoda se uudelleen toiseen työtilaan eri alueelta.

Data Factory

Asiakkaat eivät pääse käsiksi Data Factory -kohteisiin ensisijaiselta alueelta, eikä putkien tai Dataflow Gen2 -yksiköiden asetukset ja konfiguraatiot replikoidu toissijaiselle alueelle. Näiden kohteiden palauttamiseksi alueellisen vian jälkeen sinun täytyy luoda Data Integration -elementit uudelleen toiseen työtilaan eri alueelta. Seuraavissa osissa on esitelty yksityiskohtaiset tiedot.

Tietovuot Gen2

Dataflow Gen2 -alkion palauttamiseksi uudella alueella viedään .pqt tiedosto versionhallintajärjestelmään, kuten Git, ja palauta Dataflow Gen2 -sisältö manuaalisesti katastrofin jälkeen.

1. Valitse Dataflow Gen2 -tuotteestasi Power Query -editorin Home-välilehdeltä.

   

2. Vientimallin valintaikkunassa syötä nimi (pakollinen) ja kuvaus (valinnainen) tälle mallille. Kun olet valmis, valitse OK.

   

3. Luo katastrofin jälkeen uusi Tietovuo Gen2 -kohde uuteen työtilaan "C2. W2".

4. Power Query-editorin nykyisestä näkymäpaneelista valitse Tuo Power Query-pohjasta.

   

5. Avaa-ikkunassa selaa oletuslatauskansioosi ja valitse tiedosto.pqt, jonka olet tallentanut aiemmissa vaiheissa. Valitse sitten Avaa.

6. Malli tuodaan sitten uuteen Tietovuo Gen2 -kohteeseesi.

Tallenna Dataflowsin ominaisuus ei ole tuettu katastrofipalautuksen yhteydessä.

Pipelines

Asiakkaat eivät voi käyttää putkia alueellisen katastrofin sattuessa, eikä määrityksiä replikoida pariksi liitetylle alueelle. Rakenna kriittiset putkesi useisiin työtiloihin eri alueilla.

Kopioi työ

CopyJob-käyttäjien on ryhdyttävä ennakoiviin toimiin alueelliselta katastrofilta suojautumiseksi. Seuraava lähestymistapa varmistaa, että alueellisen katastrofin jälkeen käyttäjän CopyJobs on edelleen käytettävissä.

Käyttäjän hallitsema redundanssi Git-integroinnin avulla (julkisessa esikatselussa)

Paras tapa tehdä tästä prosessista helppo ja nopea on käyttää Fabric Git -integraatiota ja synkronoida CopyJob Azure DevOps -reposi kanssa. Kun palvelu ei siirry toiselle alueelle, voit säilön avulla luoda uuden työtilan CopyJob-objektin uudelleen.

1. Määritä työtilasi Git-integraatio ja valitse yhdistä ja synkronoi Azure DevOps -repoon.

   

   Seuraavassa kuvassa näkyy synkronoitu CopyJob.

   

2. Palauta CopyJob Azure DevOps repo-tiedostosta.

   1. Uudessa työtilassa yhdistä ja synkronoi uudelleen Azure DevOps -repositioosi. Kaikki tämän arkiston Fabric-kohteet ladataan automaattisesti uuteen työtilaasi.

      

   2. Jos alkuperäinen CopyJob käyttää Lakehousea, käyttäjät voivat viitata Lakehouse -osaan, lakehousen palauttamiseksi, ja sitten yhdistää äskettäin parantuneet CopyJob-tiedot äskettäin löydettyun Lakehouseen.

Lisätietoja Git-integroinnista on artikkelissa Johdanto Git-integrointiin.

Apache Airflow -työ

Sinun on ryhdyttävä ennakoiviin toimiin suojellaksesi Apache Airflow -työpaikkoja Fabric-alueella alueelliselta katastrofilta.

Hallitse redundanssia käyttämällä Fabric Git -integraatiota. Ensinnäkin, synkronoi Airflow-työsi ADO-repon kanssa. Jos palvelu siirtyy toiselle alueelle, voit käyttää varastoa Airflow-työn uudelleenrakentamiseen uudessa luomassasi työtilassa.

Noudata näitä vaiheita saavuttaaksesi tämän tavoitteen:

1. Määritä työtilasi Git-integraatio ja valitse Yhdistä ja synkronoi ADO-repoon.

2. Sen jälkeen näet Airflow-työsi synkronoiduna ADO-repoon.

3. Jos sinun täytyy palauttaa Airflow-työ ADO-reposita, luo uusi työtila, yhdistä ja synkronoi uudelleen Azure ADO -repositioosi. Kaikki Fabric-tuotteet, mukaan lukien Airflow, latautuvat automaattisesti uuteen työtilaasi.

Reaaliaikainen tieto

Tässä oppaassa käydään läpi reaaliaikaisten tiedustelutietojen palautusmenettelyt. Se kattaa KQL-tietokannat, kyselyjoukot ja tapahtumavirran kohteet.

Activator

Ensisijaisen alueen aktivaattorituotteet pysyvät asiakkaiden käytettävissä, eikä aktivaattorin trigger-määritelmiä replikoidu toissijaiselle alueelle. Aktivaattorin käyttäjien on ryhdyttävä ennakoiviin toimiin valmistautuakseen alueelliseen katastrofipalautukseen.

Varmistaaksesi, että voit palauttaa Activator-esineet alueellisen katastrofin sattuessa, aseta Fabric Git -integraatio varmuuskopioimaan laukaisumäärittelyt ja palauttamaan ne työtilassa toisella alueella.

1. Konfiguroi Fabric Git -integraatio työtilalle, jossa Activator-esineesi on, ja synkronoi trigger-määrittelyt Git-repositoriosi kanssa.
2. Pidä aktivaattorin laukaisumääritelmät sitoutuneina ja synkronoituna säännöllisesti.
3. Palautuksen aikana luo uusi työtila kohdealueelle (C2. W2), yhdistä se samaan repositorioon ja synkronoi laukaisumääritelmien palauttamiseksi.
4. Uudelleenkonfiguroi ja validoi kaikki Activatorin tietolähteet ja riippuvuudet uudessa työtilassa.

Lisätietoja Git-integroinnista on artikkelissa Johdanto Git-integrointiin.

Graafimalli/kyselyjoukko

Asiakkaat eivät pääse käsiksi Graph-mallin ja Graph-kyselysetin kohteisiin ensisijaiselta alueelta, eikä Fabric replikoi näitä kohteita toissijaiselle alueelle. Palautusta varten luo tai käytä kapasiteettia eri alueella ja luo siellä uudelleen Graph-malli ja Graph-kyselyjoukkojen kohteet.

1. Luo tai käytä olemassa olevaa Fabric-kapasiteettia toisella alueella, johon katastrofi ei vaikuta.

2. Luo uusi työtila tai käytä olemassa olevaa työtilaa siinä tilassa.

3. Luo Graph-mallin alkio uudelleen toissijaiseen työtilaan (viitattu vaiheessa 2). Muokkaa mallin määrittely, mukaan lukien solmut, reunat ja muut, vastaamaan alkuperäistä Graph-mallia.

4. Jos alkuperäinen järvitalo on rappeutuvalla alueella, palauta se ensin seuraamalla Lakehouse-osuutta.

5. Yhdistä järvitalo OneLake-tietolähteeksi juuri luodulle Graph-mallin kohteelle. Käytä palautettua järvitaloa, jos se oli rappeutuvalla alueella, tai yhdistä uudelleen olemassa olevaan järvimajaan, jos se on edelleen käytettävissä.

6. Määritä uudelleen kaikki datan latausaikataulut tai yhteydet Graph-mallille uudessa työtilassa.

7. Luo Graph-kyselyjoukko uudelleen toissijaisessa työtilassa. Syötä kyselyt ja tallennetut kyselyasetukset manuaalisesti uudelleen alkuperäisestä Graph-kyselyjoukosta.

KQL-tietokanta/kyselyjoukko

KQL-tietokannan ja kyselysetin käyttäjien on ryhdyttävä ennakoiviin toimiin alueellisen katastrofin estämiseksi. Seuraava lähestymistapa varmistaa, että alueellisen katastrofin sattuessa KQL-tietokantojesi ja kyselyjoukkojesi tiedot pysyvät turvassa ja saatavilla.

Seuraavien vaiheiden avulla voit taata KQL-tietokantojen ja kyselyjoukkojen tehokkaan järjestelmäpalautusratkaisun.

1. Perusta itsenäiset KQL-tietokannat: Määritä kaksi tai useampi itsenäinen KQL-tietokanta ja kyselysarjat omistetuille Fabric-kapasiteeteille. Aseta nämä tietokannat kahdelle eri Azure-alueelle (mieluiten Azure-paritettuihin alueisiin) maksimoidaksesi kestävyyden.

2. Toista hallintatoiminnot: Peilaa kaikki hallintatoimet, joita teet toisessa KQL-tietokannassa. Tämä lähestymistapa pitää molemmat tietokannat synkassa. Keskeisiä replikoitavia toimintoja ovat:

   • Taulukot: Varmista, että taulurakenteet ja skeemamäärittelyt ovat yhdenmukaisia tietokantojen välillä.

   • Yhdistämismääritys: Monista kaikki vaaditut yhdistämismääritykset. Varmista, että tietolähteet ja kohteet ovat oikein linjassa.

   • Käytännöt: Varmista, että molemmilla tietokannoilla on samankaltainen tietojen säilytys, pääsy ja muut asiaankuuluvat käytännöt.

3. Hallinnoi tunnistautumista ja valtuuttamista: Aseta tarvittavat oikeudet jokaiselle replikalle. Varmista, että asetat asianmukaiset valtuutustasot, jotta saat pääsyn vaadittuun henkilöstöön samalla kun turvallisuusstandardit säilyvät.

4. Rinnakkaisten tietojen käsittely: Jotta tiedot pysyvät johdonmukaisena ja valmiina useilla alueilla, lataa sama tietojoukko kuhunkin KQL-tietokantaan samaan aikaan kuin käytät niitä.

Tapahtumavirta

Eventstream on keskitetty paikka Fabric-alustalla, jossa reaaliaikaisia tapahtumia voidaan tallentaa, muuntaa ja reitittää eri kohteisiin (esimerkiksi lakehouset, KQL-tietokannat/kyselysetit) no-code-kokemuksella. Kunhan kohteet tukevat katastrofipalautusta, tapahtumavirrat eivät menetä dataa. Siksi hyödynnä näiden kohdejärjestelmien katastrofipalautuskykyjä datan saatavuuden varmistamiseksi.

Voit myös saavuttaa georedundanssia ottamalla käyttöön identtisiä eventstream-työkuormia useissa Azure-alueissa osana monipaikkaista aktiivista ja aktiivista strategiaa. Monipaikkaisella aktiivisella ja aktiivisella lähestymistavalla voit käyttää työkuormaasi missä tahansa käytössä olevista alueista. Tämä lähestymistapa on järjestelmäpalautuksen monimutkaisin ja kalliin tapa, mutta useimmissa tilanteissa se voi lyhentää palautusajan lähelle nollaa. Täysin georedundantiksi:

1. Luo kopioita tietolähteistäsi eri alueilla.

2. Luo tapahtumavirran alemmat vastaaville alueille.

3. Yhdistä nämä uudet kohteet identtisiin tietolähteisiin.

4. Lisää identtiset kohteet kullekin eri alueilla olevan tapahtumavirran kohdalla.

Liiketoimintatapahtumat, Fabric-tapahtumat ja Azure-tapahtumat

Vaikka Business Events, Fabric Events ja Azure Events jakavat saman Real-Time-solmuinfrastruktuurin Microsoft Fabric, niillä on erilaiset alkuperät, käyttäytymismallit ja palautusvaatimukset. Ymmärrä nämä erot ennen kuin suunnittelet katastrofipalautusta:

• Fabric-tapahtumat ovat tapahtumatilauksia, jotka reagoivat Fabric-resurssien tuottamiin aktiviteetteihin. Näihin tapahtumiin kuuluvat työtilan esineiden elinkaaren muutokset (kuten järvenrakennusten, muistikirjojen tai varastojen luominen, päivittäminen tai poistaminen), tehtävien suoritukset (kuten putkiston tai muistikirjan suoritukset) sekä OneLake-tiedostojen ja kansioiden toiminnot. Nämä tilaukset ovat push-pohjaisia ja lyhytaikaisia. Tilaukset eivät ole toissijaisella alueella.

• Azure Events ovat tapahtumatilauksia Azure Blob Storage -tilien tuottamille toiminnoille. Nämä Azure-resurssit ovat olemassa itsenäisesti mistään Fabric-kapasiteetista tai alueesta. Vaikka Azure Blob Storage resurssi itsessään saattaa pysyä käytettävissä Fabric alueellisen häiriön aikana, Real-Time hubissa konfiguroituja tilauksia ei replikoita toissijaiselle alueelle ja ne täytyy luoda uudelleen.

• Liiketoimintatapahtumat ovat erillinen ominaisuus Fabric Real-Time Intelligencessa, jonka avulla tiimit voivat määritellä, julkaista ja toimia merkityksellisten liiketoimintasignaalien mukaisesti. Liiketoimintatapahtumat luodaan Fabric sisältä Activatorin, Spark-muistikirjojen tai User Data Functionsin kautta, ja julkaistaan sitten Real-Time hubissa, jossa alavirran kuluttajat kuten Activator, Eventhouse tai Power Automate voivat reagoida niihin. Tapahtumaskeemat ohjataan keskitetysti Schema-rekisterin kautta. Eventhouse tallentaa automaattisesti jokaisen julkaistun liiketoimintatapahtuman, joten sen palauttaminen vaikuttaa suoraan liiketoimintatapahtumahistorian saatavuuteen. Yhtään julkaisija- tai kuluttajakonfiguraatiota, skeemamäärittelyä tai tilauksia ei replikoidu toissijaiselle alueelle.

Käytä seuraavia vaiheita palauttaaksesi Business Eventsin, Fabric Eventsin ja Azure Eventsin uudessa työtilassa palautusalueella.

Liiketoimintatapahtumia varten:

1. Luo uudelleen julkaisijoiden ja kuluttajien käyttämä liiketoimintatapahtuma seuraamalla artikkelia Luo liiketoimintatapahtumia Fabric Real-Time Hubissa. Liiketoimintatapahtuman luomisen yhteydessä luot Event Schema Set -resurssin. Eventhouse-resurssi on vapaaehtoinen riippuen tilanteesta. Jos varmuuskopioit tapahtumaskeeman Git-integraatiolla, palauta se ensin seuraamalla Tapahtumaskeemajoukko-osiota ja osoita sitten liiketoimintatapahtuma palautettuun skeemajoukkoon.

2. Luo uudelleen kaikki publisher-kohteet, jotka tuottavat liiketoimintatapahtumia, kuten Spark-muistikirjat tai User Data -toiminnot, uudessa työtilassa seuraamalla publisher-artikkeleita: Käytä User Data -toimintoa Business Events Publisher'na, Käytä Activatoria Business Events Publisher'na, Käytä Notebookia liiketoimintatapahtumina Publisher, ja käytä Eventstreamia Business Events Publisher.

3. Luo uudelleen kuluttajatilaukset Real-Time hubissa (esimerkiksi Aktivaattorin säännöt, muistikirjan laukaisimet tai Power Automate-virrat), jotka alun perin reagoivat liiketoimintatapahtumiin kyseisellä alueella, seuraamalla Activatorinartikkeleita Eventhouse ja Real-Time Dashboard Integration with Business Events sekä Consume Business Events.

4. Varmista, että tapahtumat etenevät kokonaisvaltaisesti varmistamalla, että tilaukset ovat aktiivisia ja että data saapuu odotettuihin kohteisiin palautusalueella.

Fabric-tapahtumista:

1. Luo tilaukset uudelleen Real-Time hubissa, joka osoittaa työtilan kohteisiin, töihin tai OneLake-polkuihin, jotka palautit palautusalueella, seuraamalla artikkelia Explore Fabric events in Fabric Real-Time hub.

2. Varmista, että tapahtumat etenevät kokonaisvaltaisesti varmistamalla, että tilaukset ovat aktiivisia ja että data saapuu odotettuihin kohteisiin palautusalueella.

Azure-tapahtumille:

1. Azure Blob Storage -tileihin ei vaikuta Fabric-alueellinen katko. Luo tapahtumatilaukset uudelleen Real-Time hubissa, joka osoittaa samoihin Azure Blob Storage-tileihin seuraamalla artikkelia Aseta hälytykset Azure Blob Storage tapahtumista Real-Time hubissa.

2. Varmista, että tapahtumat etenevät kokonaisvaltaisesti varmistamalla, että tilaukset ovat aktiivisia ja että data saapuu odotettuihin kohteisiin palautusalueella.

Tapahtumarakenteen joukko

Tapahtumaskeemajoukko on Fabric kohde, joka sisältää tapahtumatyypin ja skeeman määritelmät Real-Time älykkyydessä. Muut ominaisuudet rakentuvat sen päälle: julkaisijat kirjoittavat tapahtumia, jotka noudattavat sen skeemoja, ja kuluttajat lukevat samoja määritelmiä vastaan.

Ensisijaisen alueen tapahtumaskeemajoukot pysyvät asiakkaiden käytettävissä, eikä niitä replikoita toissijaiselle alueelle. Koska tapahtumaskeemajoukko on kestävä tekijämääritelmä eikä lyhytaikainen tilaus, voit varmuuskopioida sen etukäteen ja palauttaa sen käsin uudelleenkirjoittamisen sijaan.

Suositellaan: varmuuskopioi Fabric Git -integraatiolla

Alueellisen katastrofin jälkeen tapahtumaskeeman palauttamiseksi aseta Fabric Git -integraatio ennen katastrofia ja synkronoi tapahtumaskeemaset sisältävä työtila Git-varastosi kanssa.

1. Konfiguroi Fabric Git -integraatio työtilalle, joka sisältää tapahtumaskeemasarjasi, ja synkronoi se Git-repositoriosi kanssa.

2. Pidä tapahtumaskeemajoukko sitoutuneena ja synkronoituna säännöllisesti, erityisesti tapahtumatyyppien lisäämisen tai uusien skeemaversioiden julkaisemisen jälkeen.

3. Palautuksen aikana luo uusi työtila kohdealueelle (C2. W2), yhdistää se samaan varastoon ja synkronoi tapahtumaskeeman palauttamiseksi. Koska uusi työtila on tyhjä, Git Sync tuo sisällön arkistosta työtilaan.

4. Luo uudelleen kaikki julkaisijat ja kuluttajat, jotka käyttävät skeemasarjaa, noudattaen näiden tuotetyyppien ohjeita.

5. Varmista, että julkaisijat voivat julkaista palautettuja tapahtumatyyppejä vastaan ja että kuluttajat saavat tapahtumat odotetusti.

Synkronoitu määritelmä sisältää skeemajoukon tapahtumatyypit, skeemat ja skeemaversiot. Se ei sisällä julkaisijoiden rekisteröitymisiä, kuluttajatilauksia tai tapahtumahistoriaa. Palauta ne erikseen, noudattaen ohjeita skeemajoukkoa käyttäville kohdetyypeille.

Vaihtoehto: luo uudelleen manuaalisesti

Jos et konfiguroinut Git-integraatiota ennen katastrofia, luo tapahtumaskeema uudelleen palautusalueella seuraamalla Luo ja hallitse tapahtumaskeemaset, ja lisää sitten alkuperäisen skeeman sisältämät tapahtumatyypit ja skeemat seuraamalla Luo ja hallitse tapahtumaskeemoja skeemasarjoissa.

Kartta

Pääalueen karttaesineet pysyvät asiakkaiden käytettävissä, eikä karttaesineitä replikoita toissijaiselle alueelle.

Jos haluat palauttaa karttakohteen katastrofin sattuessa, aseta Fabric Git-integraatio ja synchronize karttaesineesi Git-repon kanssa.

Palautuksen aikana, kun uusi alue/kapasiteetti Fabric:ssa on asetettu, voit käyttää repositoa rakentaaksesi kartta-alimon uudelleen uudessa työtilassa, jonka loit. Koska uusi työtila on tyhjä, Git sync siirtää sisällön repositosta tyhjään työtilaan. Tämä vaihe herättää kartta-esineen takaisin eloon.

Ontologia

Ontologian käyttäjien on ryhdyttävä ennakoiviin toimiin valmistautuakseen alueelliseen katastrofipalautukseen. Alla kuvattu lähestymistapa varmistaa, että alueellisen katastrofin jälkeen ontologiasi pysyy palautettavissa ja voidaan palauttaa nopeasti.

Yksinkertaisin ja nopein tapa ottaa palautus käyttöön on käyttää Fabric Git -integraatiota ja synkronoida Ontologiasi Azure DevOps (ADO) -varaston kanssa. Jos palvelu siirtyy toiselle alueelle, voit käyttää tätä tietovarastoa rakentaaksesi Ontologian uudelleen uudessa työtilassa.

Ontologian kohteet ensisijaisella alueella eivät ole asiakkaiden saatavilla alueellisen katastrofin jälkeen, eikä ontologian tuotteita siirretä toissijaiselle alueelle.

Ontology-alkion palauttamiseksi katastrofin aikana konfiguroi Fabric Git-integraatio ja synchronize Ontology-kohde ADO-tietovarastosi kanssa etukäteen.

Palautuksen aikana, kun uusi alue ja kapasiteetti Fabric:ssa on asetettu, voit käyttää varastoa rakentaaksesi Ontologian kohteen uudelleen uudessa työtilassa. Koska uusi työtila on tyhjä, Git sync vetää sisällön varastosta työtilaan, palauttaen käytännössä Ontologian kohteen.

Ontologian agentti

Ontology Agentin käyttäjien on ryhdyttävä ennakoiviin toimiin valmistautuakseen alueelliseen katastrofipalautukseen. Tässä osiossa kuvattu lähestymistapa varmistaa, että alueellisen katastrofin jälkeen Ontologian agenttikokemuksesi voidaan palauttaa uudessa työtilassa.

Ontologian agentti riippuu ontologian kohteesta ja kaikista tietolähteistä, jotka liittyvät ontologiaan, kuten järvimajoihin. Asiakkaat eivät pääse käsiksi Ontology Agent -istuntoihin ensisijaisella alueella alueellisen katastrofin jälkeen, eikä Ontology Agent -istuntoja siirretä toissijaiselle alueelle. Aktiivisia keskustelusessioita, keskeneräisiä toimintoja ja keskusteluhistoriaa kyseiseltä alueelta ei voi jatkaa.

Palauttaaksesi Ontology Agent -kokemuksen katastrofin aikana, konfiguroi Fabric Git -integraatio ja synkronoi Ontology-kohde etukäteen Azure DevOps (ADO) -tietovarastosi kanssa.

Toipumisen aikana, kun Fabric:n uusi alue ja kapasiteetti on vakiintunut, suorita seuraavat vaiheet:

1. Luo uusi työtila uudessa kapasiteetissa.
2. Yhdistä uusi työtila samaan ADO-repositorioon, joka sisältää Ontologian kohteen.
3. Käytä Git Synciä palauttaaksesi Ontologian kohteen uuteen työtilaan.
4. Palauta kaikki riippuvaiset tietokohteet, kuten järvitalot, noudattamalla ohjeistusta kyseisille tuotetyypeille.
5. Varmista, että palautetut tiedot ovat saatavilla paritetulla alueella. OneLake-tukemassa datassa oletetaan, että data replikoidaan paritettuun alueeseen, mutta älä oleta replikoidun datan järjestystä palautuksen aikana.
6. Yhdistä juuri palautettu ontologiakohde palautettuihin tietolähteisiin.
7. Aloita uusi Ontologia-agentti-istunto ja varmista, että agentti voi yhdistää palautettuun Ontologia-alttiin ja tietolähteisiin.

Suunnittelu

Tässä artikkelissa kuvataan IQ:n suunnittelukokemuksen toipumismenettelyt. Se määrittelee vaiheet, jotka vaaditaan keskeisten komponenttien palauttamiseksi, mukaan lukien suunnittelulomakkeet, PowerTable-lomakkeet, tiedustelulomakkeet, InfoBridge ja niihin liittyvät tietoresurssit.

Git-integraatio suunnitelman kohteiden palauttamiseksi

Suositeltu lähestymistapa on synkronoida kaikki suunnitelman kohteet Azure DevOps (ADO) tai GitHub -tietovaraston kanssa käyttämällä Fabric Git -integraatiota. Failoverin jälkeen käytä varastoa palauttamaan kohteet uuteen työtilaan.

Predisaster (ennakoivat toimenpiteet):

1. Workspace W1:ssä mene Workspace Settings -kohtaan ja määritä Git-integraatio .

2. Valitse Yhdistä ja synkronoi ADO- tai GitHub-repositoriosi kanssa.

3. Valitse suunnitelman kohteet, jotka voit ladata repositoryyn, ja valitse Commit.

   

4. Varmista, että suunnitelman kohteiden Git-tila on synkronoitu.

5. Luo sitoutumiskurinalaisuus – sitoudu jokaisen merkittävän muutoksen jälkeen suunnitelmamääritelmään niin, että arkisto heijastaa aina viimeisintä tilaa.

Toipumisvaiheet:

1. Luo uusi työtila W2 kapasiteettiin C2 terveelle alueelle.

2. Workspace W2:ssa mene Workspace Settings -kohtaan ja yhdistä uudelleen samaan ADO/GitHub-repositorioon.

3. Valitse Lähdeohjausobjekti. Valitse asianmukainen repositorion haara ja valitse Päivitä kaikki. Kaikki suunnitelman tuotteet ladataan W2:een.

Seuraavat komponentit palautuvat toipumisen jälkeen:

• PowerTable-lomakkeet: Lähdetaulun asetukset, sarakkeen konfiguraatio, rivien käyttö, visuaaliset ominaisuudet (asettelu, muodot ja muuta), rivien tunnistus, kommenttiasetukset, hitaasti muuttuvat mitat (SCD), hyväksynnät, automaatio ja lomakkeet.
• Suunnittelulomakkeet: Taulukon ominaisuudet (muotoilu, ehdollinen muotoilu ja muuta), kommenttiasetukset, takaisinkirjoitusasetukset, tiedonsyöttösarakkeet, syöterivit, skenaariot ja kirjanmerkit.
• InfoBridge: InfoBridge-lähteet, InfoBridge-kyselyt, muunnosvaiheet, takaisinkirjoituskohteet, takaisinkirjoitusasetukset, linkitetyt kyselykartoitukset, kyselyryhmät, visuaaliset ominaisuudet (sekoitus). Näitä kohteita ei voi palauttaa: tiedostopohjaiset lähteet (CSV, Excel), monikäyttöiset työtehtävälomakkeet, jotka käyttävät tiedostopohjaisia lähteitä.
• Älykkyys: Kaikki kaaviot ja matriisit.

Fabric SQL Restore suunnitteluun

Suunnittelutaulukoihin, PowerTablessa käytettyihin taulukoihin ja takaisinkirjoitusdataan syötetyt tiedot tallennetaan SQL-tietokantoihin ja ne on otettava huomioon osana katastrofipalautusstrategiaasi. SQL-tietokantojen palauttamiseksi katso SQL-tietokanta-osio .

• Suunnitelman palautusmetatiedot: Jokainen suunnitelman kohde liittyy __fabric_plan_sys tietokantaan, joka tallentaa suunnitteluominaisuuksien metatiedot, mukaan lukien kommentit, skenaariot, tiedonsyötteet ja takaisinkirjoitusasetukset. __fabric_plan_sys tietokantaa ei palauteta automaattisesti, vaan se täytyy nimenomaisesti palauttaa.

• Palauta takaisinkirjoitustietokannat: Jos suunnitelmasi käyttää SQL-kirjoituskohteita, sinun täytyy myös palauttaa niihin liittyvät tietokannat manuaalisesti. Konfiguroidut SQL-kirjoituskohteet eivät palautu automaattisesti.

• PowerTablessa käytettävät taulukot palautetaan: Kaikki PowerTablella luodut taulut tallennetaan SQL-tietokantaan Fabric-ohjelmassa. Sinun täytyy myös palauttaa nämä taulukot DR:n aikana.

Operatiiviset agentit

Operaatioagenttien käyttäjien tulisi ryhtyä ennakoiviin toimiin valmistautuakseen alueelliseen katastrofipalautukseen. Tässä osiossa kuvatun lähestymistavan noudattaminen auttaa varmistamaan, että agenttisi voidaan palauttaa nopeasti alueellisen sähkökatkon jälkeen.

Käytä Fabric Git -integraatiota synkronoidaksesi työtilasi repositorion kanssa. Tämä lähestymistapa mahdollistaa agenttiasetusten rekonstruoinnin uudessa työtilassa, jos palvelu siirtyy toiselle alueelle.

Operatiivisia agentteja ensisijaisella alueella ei ole saatavilla alueellisen katastrofin aikana. Agentin konfiguraatiot, käyttäytymismallit ja aktiivisuuslokit eivät replikoidu toissijaiselle alueelle. Keskeneräiset toiminnot, aktiiviset chat-sessiot ja aiemmin katastrofin aikaan vastaanotetut tapahtumat katoavat.

Valmistautuaksesi palautukseen, konfiguroi Fabric Git -integraatio ja synkronoi agenttielementit ADO-varastosi kanssa ennen katastrofia.

Kun palautat, aseta uusi alueesi ja kapasiteetti Fabric-ohjelmaan, ja käytä synkronoitua varastoa agenttikonfiguraatioiden palauttamiseen uuteen työtilaan. Git Sync vetää tallennetut sisällöt varastosta tyhjään työtilaan, luoden agenttielementit uudelleen.

Kun konfiguraatiot on palautettu, varmista, että kaikki viitatut Eventhouse (KQL) -tietokannat tai aluekohtaiset tietolähteet ovat saatavilla uudella alueella. Päivitä päätepisteviitteet agenttikonfiguraatioissa tarpeen mukaan. Lopuksi, käynnistä agentit uudelleen ja anna käyttäjien aloittaa uudet keskustelusessiot. Aiempia keskusteluja ei voi jatkaa.

Databases

Tämä opas kuvaa tietokantojen kokemuksen palautusmenettelyt.

SQL-tietokanta

Suojautuakseen alueelliselta virheeltä SQL-tietokantojen käyttäjät voivat ryhtyä ennakoiviin toimenpiteisiin ja viedä tietonsa säännöllisesti ja käyttää vietyjä tietoja tietokannan luomiseen uudelleen uudessa työtilassa tarvittaessa.

Käytä SqlPackage CLI -työkalua, joka tarjoaa tietokannan siirrettävyyden ja helpottaa tietokannan käyttöönottoa.

1. SqlPackage-työkalun avulla voit viedä tietokannan tiedostoon .bacpac . Katso lisätietoja kohdasta Tietokannan vieminen SqlPackagen avulla .
2. Tallenna .bacpac tiedosto turvalliseen paikkaan, joka on eri alueella kuin tietokanta. Esimerkkejä ovat tiedoston tallentaminen .bacpac Lakehouseen, joka sijaitsee eri alueella, käyttää georedundanttia Azure-tallennus -tiliä tai käyttää toista turvallista tallennusvälinettä eri alueella.
3. Jos SQL-tietokanta ja -alue eivät ole käytettävissä, voit käyttää SqlPackage-tiedostoa .bacpac luodaksesi tietokannan uudelleen työtilassa uudella alueella – työtilassa C2. W2 alueella B yllä olevan skenaarion mukaisesti. Luo tietokanta uudelleen tiedoston kanssa noudattamalla kohdassa .bacpac annettuja ohjeita.

Uudelleen luotu tietokanta on alkuperäisestä tietokannasta riippumaton tietokanta ja heijastaa tietojen tilaa vientitapahtuman aikana.

Vikasietoisuuden huomioon ottamista

Uudelleen luotu tietokanta on itsenäinen tietokanta. Uudelleenluotuun tietokantaan lisätty data ei näkynyt alkuperäisessä tietokannassa. Jos aiot palata alkuperäiseen tietokantaan, kun kotialue tulee saataville, sinun tulee harkita tietojen manuaalista sovittamista uudelleenluodusta tietokannasta alkuperäiseen tietokantaan.

Ympäristö

Alusta viittaa taustalla oleviin jaettuihin palveluihin ja arkkitehtuuriin, jotka koskevat kaikkia työkuormia. Tässä osiossa kuvataan palautusmenettelyt jaetuille Fabric-ominaisuuksille.

Työtilan seuranta

Työtilan seuranta kerää lokkeja toiminnasta siinä työtilassa, jossa sen otat käyttöön. Kun palautat työtilasi C2-muodossa. W2, ota työtilan valvonta käyttöön W2:ssa. Se alkaa kerätä seurantatietoja palautetun työtilan osalta.

Datan valvonta alkuperäisestä työtilasta (C1. W1) ei siirry mukanaan, koska valvonta heijastaa sen työtilan toimintaa, jolla se toimii.

Muuttujakirjasto

Microsoft Fabric Variable -kirjastot mahdollistavat kehittäjille tehtäväkonfiguraatioiden mukauttamisen ja jakamisen työtilassa, mikä virtaviivaistaa sisällön elinkaaren hallintaa. Katastrofipalautuksen näkökulmasta muuttujakirjastojen käyttäjien on suojauduttava ennakoivasti alueelliselta katastrofilta. Tämä suojaus voidaan toteuttaa Fabric Git -integraation avulla, joka varmistaa, että alueellisen katastrofin jälkeen käyttäjän Variable-kirjasto pysyy käytettävissä. Muuttujakirjaston palauttamiseksi noudata seuraavia vaiheita:

• Käytä Fabric Git -integraatiota synkronoidaksesi Variable-kirjastosi ADO-reposi kanssa. Katastrofin sattuessa voit käyttää arkistoa muuttujakirjaston rakentamiseen uudelleen luomassasi uudessa työtilassa. Toimi seuraavasti:

  1. Yhdistä työtilasi Git-säilöön tässä kuvatulla tavalla.
  2. Varmista, että WS ja säilö on synkronoitu toimituksen ja päivityksen kanssa.
  3. Palautus – Katastrofin sattuessa voit rakentaa muuttujakirjaston uudelleen uudessa työtilassa säilön avulla:

• Uudessa työtilassa yhdistä ja synkronoi uudelleen Azure ADO -repositioosi.

• Kaikki tämän arkiston Fabric-kohteet ladataan automaattisesti uuteen työtilaasi.

• Kun olet synkronoinut kohteet Gitistä, avaa muuttujakirjastot uudessa työtilassa ja valitse manuaalisesti haluamasi aktiivinen arvojoukko.

Sijoitussuunnitelma

Käyttöönottosuunnitelma on osa Fabric-työpisteessä. Se ryhmittelee esineitä ja asettaa järjestyksen niiden käyttöönotolle. Se voi suorittaa toimintoja ennen tai jälkeen jokaisen esineen käyttöönoton. Kohteen määrittely tallentaa nämä asetukset, syötteet ja esineviittaukset. Suunnitelmassa ei ole erillistä tallennusta arvoille, joita käytetään ajonaikaisesti.

Valmistaudu palautukseen käyttämällä Fabric Git -integraatiota:

1. Yhdistä suunnitelman sisältävä työtila Azure DevOps- tai GitHub-repositorioon.
2. Sitoutuu suunnitelmaan ja kaikkiin työtilan esineisiin, joita se käyttää.
3. Sitoutuu jokaiseen muutokseen, jotta Gitillä on uusimmat määritelmät.

Alueellisen katastrofin jälkeen:

1. Luo työtila terveelle alueelle.
2. Yhdistä työtila samaan arkistoon ja haaraan.
3. Päivitä työtila Gitistä. Tämä vaihe palauttaa suunnitelman ja sen tuotteet.

Git palauttaa koko suunnitelman määritelmän. Se ei palauta dataa tai suorita tilaa linkitetyille kohteille. Käytä tämän artikkelin osioita palauttaaksesi nämä esineet.

Asiakkaan hallinnoimat avaimet Fabric-työtiloille

Voit käyttää asiakkaan hallinnoimia avaimia (CMK), jotka on tallennettu Azure Key Vault -sovellukseen, lisätäksesi ylimääräisen salauskerroksen Microsoftin hallinnoimien avainten päälle lepotilassa oleville datalle. Jos Fabric muuttuu alueella saavuttamattomaksi tai toimimattomaksi, sen komponentit siirtyvät varmuuskopioinstanssiin. Vikasietoisuuden aikana CMK-ominaisuus tukee vain luku -toimintoja. Niin kauan kuin Azure Key Vault -palvelu pysyy kunnossa ja holvin käyttöoikeudet ovat tallella, Fabric jatkaa yhteyden muodostamista avaimesi ja antaa sinun lukea dataa normaalisti. Tämä tarkoittaa sitä, että seuraavia toimintoja ei tueta vikasietoisuuden aikana: työtilan CMK-asetuksen ottaminen käyttöön ja poistaminen käytöstä sekä avaimen päivittäminen.

Fabric Migration Assistant SQL-tietokannalle Fabric

Fabric Migration Assistant voi siirtää SQL Server tietokannan SQL-tietokantaan Fabric kolmessa vaiheessa: migraatio-ohjaaja luo kohdetietokannan ja käynnistää migraation, migraatiovalvonta seuraa edistymistä samalla kun skeema otetaan käyttöön DACPACista, Migration Assistant auttaa sinua tarkistamaan ja korjaamaan skriptivirheitä, valmistelemaan tietokantaa, kopioimaan dataa kopiointityöllä ja viimeistelemään kopion.

Migraation etenemistä ei toisteta toiselle alueelle, eikä keskeyttynyttä käyttöönottoa voi jatkaa. Nämä viat eivät vaikuta lähdekoodiin SQL Server tietokantaan, joten migraatio-avustajan voi ajaa uudelleen. Jos alkuperäinen alue ei ole käytettävissä, seuraa ensin tämän artikkelin yleistä palautussuunnitelmaa luodaksesi kapasiteetti C2 ja työtila W2 paritetun alueen sisällä, ja suorita sitten siirto W2:ssa. Jos alkuperäinen alue palautuu, voit yrittää migraatiota uudelleen alkuperäisessä työtilassa.

Alueellinen häiriö voi aiheuttaa muuttoliikkeen epäonnistumisen kolmella tavalla:

• Kohdetietokantaa ei luoda

  Jos Fabric ei pysty luomaan kohdetietokantaa, migraatio-ohjaaja näyttää virheen eikä migraatio käynnisty. Valitse Aloita migraatio yrittääksesi uudelleen, tai yritä myöhemmin uudelleen.

  Velho yrittää poistaa keskeneräisen tietokannan, mutta siivous voi epäonnistua häiriön aikana. Ennen kuin yrität uudelleen, tarkista työtilasta tietokanta, jossa on kohdenimi. Varmista, että kyseessä on epäonnistuneen yrityksen epätäydellinen tietokanta ennen kuin poistat sen.

• Käyttöönotto epäonnistuu

  Jos käyttöönotto keskeytyy, migraatiomonitori lopettaa edistymisen raportoinnin, avaa kohdetietokannan ja näyttää dialogin, joka ilmoittaa käyttöönoton epäonnistumisesta. Et voi jatkaa epäonnistunutta käyttöönottoa, ja yrityksen luoma tietokanta pysyy työtilassa.

  Toipumiseen:

  1. Varmista, että Fabric on saatavilla ja että sinulla on DACPAC käytössä alkuperäiseen migraatioon.
  2. Tunnista epäonnistuneen yrityksen seurauksena luotu tietokanta. Poista se, jos siinä ei ole mitään säilytettävää. Muussa tapauksessa pidä se ja käytä uutta tietokantaa eri nimellä.
  3. Suorita uusi migraatio lähdekoodista DACPAC. Migraatio luo uuden tietokannan.

  Data kopioidaan Data Factoryn kopiointityöllä. Jos synkronoit kopiointityön Gitin kanssa ennen häiriötä, katso Kopiointityö Data Factoryn ohjeistuksesta. Muussa tapauksessa luo uusi kopiotyö osana uutta siirtoa.

• Migraatiohistoria ei lataudu

  Jos Migration Assistant ei pysty hakemaan migraatiohistoriaa, se raportoi, että migraatiotiedot eivät ole enää saatavilla. Nykyiseen selaimeen tallennettu edistys säilyy, eikä kohdetietokanta kärsi. Päivitä sivu ladataksesi migraatiohistorian uudelleen.

OneLake

Tämä osio opastaa sinua OneLake-ominaisuuksien palautusmenettelyissä. Lisätietoja OneLake-datan katastrofipalautuksesta löytyy kohdasta OneLake disaster recovery.

Elinkaaren hallintakäytännöt

Jos Fabric ei pääse käyttöön tai toimi jollain alueella, voit silti lukea ja päivittää OneLake-elinkaaren politiikkaasi varayhteyden aikana. Kaikki viileälle tai kylmälle tasolle siirretty data pysyy siinä kerroksessa. Soveltaaksesi nykyistä käytäntöäsi uuteen palautustyötilaasi, noudata näitä vaiheita:

1. Soita vientipolitiikkaan alkuperäisellä työtilallasi ja tallenna koko elinkaaripolitiikka.
2. Soita Import-politiikkaan palautetulla työtilallasi, ja vienti elinkaaripolitiikka toimii pyyntökappaleena.

Resurssi-instanssisäännöt

Resurssiinstanssisäännöt auttavat sinua turvallisesti hallitsemaan pääsyä OneLakessa luotettavien Azure-resurssien identiteettien avulla. Alueellisen vikasion aikana järjestelmä jatkaa olemassa olevien lukuoikeuksien sääntöjen noudattamista. Kuitenkaan et voi luoda, päivittää tai poistaa resurssiinstanssisääntöjä ennen kuin työtila palaa kirjoitettavaan tilaan.

Liittyvät tiedot

• Microsoft Fabric katastrofipalautusopas