Schijven uitsluiten van herstel na noodgevallen
In dit artikel wordt beschreven hoe u schijven kunt uitsluiten van replicatie tijdens herstel na noodgevallen van on-premises naar Azure met Azure Site Recovery. U kunt schijven om een aantal redenen uitsluiten van replicatie:
- Zodat niet-belangrijke gegevensverloop op de uitgesloten schijf niet worden gerepliceerd.
- Om de verbruikte replicatiebandbreedte of resources aan de doelzijde te optimaliseren.
- Als u opslag- en netwerkresources wilt opslaan door geen gegevens te repliceren die u niet nodig hebt.
- Azure-VM's hebben site recovery-replicatielimieten bereikt.
Ondersteunde scenario's
U kunt schijven uitsluiten van replicatie zoals samengevat in de tabel.
Azure naar Azure | VMware naar Azure | Hyper-V naar Azure | Fysieke server naar Azure |
---|---|---|---|
Ja | Ja | Ja | Ja (alleen in klassieke architectuur) |
Beperkingen uitsluiten
Beperking | Azure VM's | VMware-VM's | Virtuele Hyper-V-machines |
---|---|---|---|
Schijftypen | U kunt basisschijven uitsluiten van replicatie. U kunt besturingssysteemschijven of dynamische schijven niet uitsluiten. Tijdelijke schijven worden standaard uitgesloten. |
U kunt basisschijven uitsluiten van replicatie. U kunt besturingssysteemschijven of dynamische schijven niet uitsluiten. |
U kunt basisschijven uitsluiten van replicatie. Besturingssysteemschijven kunt u niet uitsluiten. We raden u aan geen dynamische schijven uit te sluiten. Site Recovery kan niet identificeren welke VHS basic of dynamisch is in de gast-VM. Als alle afhankelijke dynamische volumeschijven niet worden uitgesloten, wordt de beveiligde dynamische schijf een mislukte schijf op een failover-VM en zijn de gegevens op die schijf niet toegankelijk. |
Schijf repliceren | U kunt geen schijf uitsluiten die repliceert. Schakel replicatie voor de VIRTUELE machine uit en herstel deze opnieuw in. |
U kunt geen schijf uitsluiten die repliceert. | U kunt geen schijf uitsluiten die repliceert. |
Mobility-service (VMware) | Niet relevant | U kunt schijven alleen uitsluiten op VM's waarop de Mobility-service is geïnstalleerd. Dit betekent dat u de Mobility-service handmatig moet installeren op de VM's waarvoor u schijven wilt uitsluiten. U kunt het pushinstallatiemechanisme niet gebruiken omdat het de Mobility-service alleen installeert nadat replicatie is ingeschakeld. |
Niet relevant. |
Toevoegen/verwijderen | U kunt beheerde schijven toevoegen op azure-VM's met replicatie met beheerde schijven. U kunt geen schijven verwijderen op azure-VM's met replicatie. | U kunt geen schijven toevoegen of verwijderen nadat replicatie is ingeschakeld. Schakel replicatie uit en schakel deze vervolgens opnieuw in om een schijf toe te voegen. | U kunt geen schijven toevoegen of verwijderen nadat replicatie is ingeschakeld. Schakel replicatie uit en schakel deze vervolgens opnieuw in. |
Failover | Als een app een schijf nodig heeft die u hebt uitgesloten, moet u na een failover de schijf handmatig maken, zodat de gerepliceerde app kan worden uitgevoerd. U kunt ook de schijf maken tijdens een VM-failover door Azure Automation te integreren in een herstelplan. |
Als u een schijf uitsluit die een app nodig heeft, maakt u deze handmatig in Azure na een failover. | Als u een schijf uitsluit die een app nodig heeft, maakt u deze handmatig in Azure na een failover. |
On-premises failback-schijven die handmatig zijn gemaakt | Niet relevant | Windows-VM's: schijven die handmatig zijn gemaakt in Azure, worden niet teruggefaald. Als u bijvoorbeeld een failover van drie schijven uitvoert en twee schijven rechtstreeks op een Virtuele Azure-machine maakt, worden alleen de drie schijven waarvoor een failover is uitgevoerd, uitgevoerd, een failback uitgevoerd. Linux-VM's: schijven die handmatig in Azure zijn gemaakt, worden teruggefaald. Als u bijvoorbeeld een failover uitvoert van drie schijven en twee schijven maakt op een Virtuele Azure-machine, worden alle vijf de schijven teruggefaald. U kunt geen schijven die handmatig zijn gemaakt, uitsluiten van failback. |
Schijven die handmatig in Azure zijn gemaakt, worden niet teruggefaald. Als u bijvoorbeeld een failover van drie schijven uitvoert en twee schijven rechtstreeks op een Virtuele Azure-machine maakt, wordt er een failover uitgevoerd op slechts drie schijven waarvoor een failover is uitgevoerd. |
On-premises failback-uitgesloten schijven | Niet relevant | Als u een failback naar de oorspronkelijke computer uitvoert, bevat de configuratie van de failback-VM-schijf niet de uitgesloten schijven. Schijven die zijn uitgesloten van replicatie van VMware naar Azure, zijn niet beschikbaar op de failback-VM. | Wanneer failback naar de oorspronkelijke Hyper-V-locatie is, blijft de configuratie van de failback-VM-schijf hetzelfde als die van de oorspronkelijke bron-VM-schijf. Schijven die zijn uitgesloten van Hyper-V-site naar Azure-replicatie, zijn beschikbaar op de failback-VM. |
Typische scenario's
Voorbeelden van gegevensverloop die goede kandidaten voor uitsluiting zijn, zijn schrijfbewerkingen naar een wisselbestand (pagefile.sys) en schrijfbewerkingen naar het tempdb-bestand van Microsoft SQL Server. Afhankelijk van de werkbelasting en het opslagsubsysteem kunnen de paginerings- en tempdb-bestanden een aanzienlijke hoeveelheid verloop registreren. Het repliceren van dit type gegevens naar Azure is resource-intensief.
Als u de replicatie voor een virtuele machine wilt optimaliseren met één virtuele schijf die zowel het besturingssysteem als het wisselbestand bevat, kunt u het volgende doen:
- Splits de virtuele schijf in twee virtuele schijven. De ene virtuele schijf bevat het besturingssysteem en de andere het wisselbestand.
- Sluit de wisselbestandschijf uit van replicatie.
Als u de replicatie wilt optimaliseren voor een schijf die zowel het Tempdb-bestand van Microsoft SQL Server als het databasebestand van het systeem bevat, kunt u het volgende doen:
- Zet het systeemdatabasebestand en het tempdb-bestand op twee verschillende schijven.
- Sluit de tempdb-schijf uit van replicatie.
Voorbeeld 1: de tempdb-schijf in SQL Server uitsluiten
Laten we eens kijken hoe u schijfuitsluiting, failover en failover voor een bron-SQL Server Windows-VM - SalesDB* kunt verwerken, waarvoor we tempdb willen uitsluiten.
Schijven uitsluiten van replicatie
We hebben deze schijven op de Windows VM SalesDB van de bron.
Schijfnaam | Schijf van gastbesturingssystemen | Stationsletter | Schijfgegevenstype |
---|---|---|---|
DB-Disk0-OS | Schijf0 | C:\ | Besturingssysteemschijf. |
DB-Disk1 | Disk1 | D:\ | SQL-systeemdatabase en gebruikersdatabase1. |
DB-Disk2 (de schijf is uitgesloten van beveiliging) | Disk2 | E:\ | Tijdelijke bestanden. |
DB-Disk3 (de schijf is uitgesloten van beveiliging) | Disk3 | F:\ | SQL tempdb-database. Mappad - F:\MSSQL\Data. Noteer het mappad vóór de failover. |
DB-Disk4 | Disk4 | G:\ | Gebruikersdatabase2 |
- We schakelen replicatie in voor de SalesDB-VM.
- Schijf2 en Schijf3 worden uitgesloten van replicatie omdat het gegevensverloop op deze schijven tijdelijk is.
Schijven verwerken tijdens failover
Omdat schijven niet worden gerepliceerd, zijn deze schijven niet aanwezig op de Azure-VM die na een failover is gemaakt wanneer u een failover naar Azure uitvoert. De Azure-VM bevat de schijven die in deze tabel zijn samengevat.
Schijf van gastbesturingssystemen | Stationsletter | Schijfgegevenstype |
---|---|---|
Schijf0 | C:\ | Besturingssysteemschijf. |
Disk1 | E:\ | Tijdelijke opslag Azure voegt deze schijf toe. Omdat Disk2 en Disk3 zijn uitgesloten van replicatie, is E: de eerste stationsletter uit de beschikbare lijst. Azure wijst E: toe aan het tijdelijke opslagvolume. Andere stationsletters voor gerepliceerde schijven blijven hetzelfde. |
Disk2 | D:\ | SQL-systeemdatabase en gebruikersdatabase1 |
Disk3 | G:\ | Gebruikersdatabase2 |
Omdat Disk3, de SQL tempdb-schijf, is uitgesloten van replicatie en niet beschikbaar is op de Azure-VM, heeft de SQL-service een gestopte status en heeft het pad F:\MSSQL\Data nodig. U kunt dit pad op een aantal manieren maken:
- Voeg een nieuwe schijf toe na een failover en wijs het pad naar de tempdb-map toe.
- Gebruik een bestaande tijdelijke opslagschijf voor het tempdb-mappad.
Een nieuwe schijf toevoegen na een failover
- Noteer de paden van SQL-tempdb.mdf en tempdb.ldf voordat de failover wordt uitgevoerd.
- Voeg vanuit Azure Portal een nieuwe schijf toe aan de failover-VM van Azure. De schijf moet dezelfde grootte (of groter) hebben als de SQL tempdb-bronschijf (Disk3).
- Meld u aan bij de Virtuele Azure-machine.
- Initialiseer en formatteer de nieuw toegevoegde schijf via de schijfbeheerconsole (diskmgmt.msc).
- Wijs dezelfde stationsletter toe die is gebruikt door de SQL tempdb-schijf (F:)
- Maak een tempdb-map op de F:-schijf (F:\MSSQL\Data).
- Start de SQL-service via de serviceconsole.
Een bestaande tijdelijke opslagschijf gebruiken
Open een opdrachtprompt.
Voer SQL Server in de herstelmodus uit via de opdrachtprompt.
Net start MSSQLSERVER /f / T3608
Voer de volgende sqlcmd uit om het tempdb-pad in een nieuw pad te wijzigen.
sqlcmd -A -S SalesDB **Use your SQL DBname** USE master; GO ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, FILENAME = 'E:\MSSQL\tempdata\tempdb.mdf'); GO ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = 'E:\MSSQL\tempdata\templog.ldf'); GO
Stop de Microsoft SQL Server-service.
Net stop MSSQLSERVER
Start de Microsoft SQL Server-service.
Net start MSSQLSERVER
VMware-VM's: schijven tijdens failback naar de oorspronkelijke locatie
Laten we nu eens kijken hoe u schijven op VMware-VM's kunt verwerken wanneer u een failback uitvoert naar uw oorspronkelijke on-premises locatie.
- Schijven die zijn gemaakt in Azure: Omdat in ons voorbeeld een Virtuele Windows-machine wordt gebruikt, worden schijven die u handmatig in Azure maakt, niet naar uw site gerepliceerd wanneer u een failback uitvoert of een VIRTUELE machine opnieuw beveiligt.
- Tijdelijke opslagschijf in Azure: de tijdelijke opslagschijf wordt niet terug gerepliceerd naar on-premises hosts.
- Uitgesloten schijven: schijven die zijn uitgesloten van VMware-naar-Azure-replicatie zijn niet beschikbaar op de on-premises VM na failback.
Voordat u een failback uitvoert van de VMware-VM's naar de oorspronkelijke locatie, zijn de schijfinstellingen van azure-VM's als volgt.
Schijf van gastbesturingssystemen | Stationsletter | Schijfgegevenstype |
---|---|---|
Schijf0 | C:\ | Besturingssysteemschijf. |
Disk1 | E:\ | Tijdelijke opslag. |
Disk2 | D:\ | SQL-systeemdatabase en gebruikersdatabase1. |
Disk3 | G:\ | Gebruikersdatabase2. |
Na failback heeft de VMware-VM op de oorspronkelijke locatie de schijven samengevat in de tabel.
Schijf van gastbesturingssystemen | Stationsletter | Schijfgegevenstype |
---|---|---|
Schijf0 | C:\ | Besturingssysteemschijf. |
Disk1 | D:\ | SQL-systeemdatabase en gebruikersdatabase1. |
Disk2 | G:\ | Gebruikersdatabase2. |
Virtuele Hyper-V-machines: schijven tijdens failback naar de oorspronkelijke locatie
Laten we nu eens kijken hoe u schijven op Hyper-V-VM's kunt verwerken wanneer u een failback uitvoert naar de oorspronkelijke on-premises locatie.
- Schijven die zijn gemaakt in Azure: schijven die u handmatig in Azure maakt, worden niet teruggezet naar uw site wanneer u een failback uitvoert of een VIRTUELE machine opnieuw beveiligt.
- Tijdelijke opslagschijf in Azure: de tijdelijke opslagschijf wordt niet terug gerepliceerd naar on-premises hosts.
- Uitgesloten schijven: na failback is de configuratie van de VM-schijf hetzelfde als de oorspronkelijke VM-schijfconfiguratie. Schijven die zijn uitgesloten van replicatie van Hyper-V naar Azure, zijn beschikbaar op de failback-VM.
Voordat u een failback uitvoert van de Hyper-V-VM's naar de oorspronkelijke locatie, zijn de schijfinstellingen van azure-VM's als volgt.
Schijf van gastbesturingssystemen | Stationsletter | Schijfgegevenstype |
---|---|---|
Schijf0 | C:\ | Besturingssysteemschijf. |
Disk1 | E:\ | Tijdelijke opslag. |
Disk2 | D:\ | SQL-systeemdatabase en gebruikersdatabase1. |
Disk3 | G:\ | Gebruikersdatabase2. |
Na geplande failover (failback) van Azure naar on-premises Hyper-V heeft de Hyper-V-VM op de oorspronkelijke locatie de schijven samengevat in de tabel.
Schijfnaam | Gastbesturingssysteem schijf# | Stationsletter | Schijfgegevenstype |
---|---|---|---|
DB-Disk0-OS | Schijf0 | C:\ | Besturingssysteemschijf. |
DB-Disk1 | Disk1 | D:\ | SQL-systeemdatabase en gebruikersdatabase1. |
DB-Disk2 (uitgesloten schijf) | Disk2 | E:\ | Tijdelijke bestanden. |
DB-Disk3 (uitgesloten schijf) | Disk3 | F:\ | SQL tempdb-database Mappad (F:\MSSQL\Data). |
DB-Disk4 | Disk4 | G:\ | Gebruikersdatabase2 |
Voorbeeld 2: de schijf van het wisselbestand uitsluiten
Laten we eens kijken naar het afhandelen van schijfuitsluiting, failover en failover voor een windows-bron-VM, waarvoor we de pagefile.sys bestandsschijf op zowel het D-station als een alternatief station willen uitsluiten.
Wisselbestand op het D-station
We hebben deze schijven op de bron-VM.
Schijfnaam | Schijf van gastbesturingssystemen | Stationsletter | Schijfgegevenstype |
---|---|---|---|
DB-Disk0-OS | Schijf0 | C:\ | Besturingssysteemschijf |
DB-Disk1 (uitsluiten van replicatie) | Disk1 | D:\ | pagefile.sys |
DB-Disk2 | Disk2 | E:\ | Gebruikersgegevens 1 |
DB-Disk3 | Disk3 | F:\ | Gebruikersgegevens 2 |
De instellingen van het wisselbestand op de bron-VM zijn als volgt:
- We schakelen replicatie in voor de VIRTUELE machine.
- We sluiten DB-Disk1 uit van replicatie.
Schijven na failover
Na een failover heeft de Virtuele Azure-machine de schijven samengevat in de tabel.
Schijfnaam | Gastbesturingssysteemschijf# | Stationsletter | Gegevenstype op de schijf |
---|---|---|---|
DB-Disk0-OS | Schijf0 | C:\ | Besturingssysteemschijf |
DB-Disk1 | Disk1 | D:\ | Tijdelijke opslag/pagefile.sys Omdat DB-Disk1 (D:) is uitgesloten, is D: de eerste stationsletter uit de beschikbare lijst. Azure wijst D: toe aan het tijdelijke opslagvolume. Omdat D: beschikbaar is, blijft de instelling voor het wisselbestand van de VM hetzelfde). |
DB-Disk2 | Disk2 | E:\ | Gebruikersgegevens 1 |
DB-Disk3 | Disk3 | F:\ | Gebruikersgegevens 2 |
De instellingen van het wisselbestand op de Virtuele Azure-machine zijn als volgt:
Wisselbestand op een ander station (niet D:)
Laten we eens kijken naar een voorbeeld waarin het wisselbestand zich niet op het D-station bevindt.
We hebben deze schijven op de bron-VM.
Schijfnaam | Schijf van gastbesturingssystemen | Stationsletter | Schijfgegevenstype |
---|---|---|---|
DB-Disk0-OS | Schijf0 | C:\ | Besturingssysteemschijf |
DB-Disk1 (uitsluiten van replicatie) | Disk1 | G:\ | pagefile.sys |
DB-Disk2 | Disk2 | E:\ | Gebruikersgegevens 1 |
DB-Disk3 | Disk3 | F:\ | Gebruikersgegevens 2 |
De instellingen van het wisselbestand op de on-premises VM zijn als volgt:
- We schakelen replicatie in voor de VIRTUELE machine.
- We sluiten DB-Disk1 uit van replicatie.
Schijven na failover
Na een failover heeft de Virtuele Azure-machine de schijven samengevat in de tabel.
Schijfnaam | Gastbesturingssysteem schijf# | Stationsletter | Schijfgegevenstype |
---|---|---|---|
DB-Disk0-OS | Schijf0 | C:\ | Besturingssysteemschijf |
DB-Disk1 | Disk1 | D:\ | Tijdelijke opslag Aangezien D: de eerste letter in de lijst is, wijst Azure de letter D: toe aan het tijdelijke opslagvolume. De stationsletter is voor alle gerepliceerde schijven hetzelfde. Omdat de G: schijf niet beschikbaar is, gebruikt het systeem het C:-station voor het wisselbestand. |
DB-Disk2 | Disk2 | E:\ | Gebruikersgegevens 1 |
DB-Disk3 | Disk3 | F:\ | Gebruikersgegevens 2 |
De instellingen van het wisselbestand op de Virtuele Azure-machine zijn als volgt:
Volgende stappen
- Meer informatie over richtlijnen voor de tijdelijke opslagschijf:
- Meer informatie over het gebruik van SSD's in Azure-VM's voor het opslaan van SQL Server TempDB en buffergroepextensies
- Bekijk de best practices voor prestaties voor SQL Server in Azure-VM's.
- Wanneer uw implementatie actief is, kunt u hier meer lezen over de verschillende soorten failovers.