Delen via


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:

    1. Splits de virtuele schijf in twee virtuele schijven. De ene virtuele schijf bevat het besturingssysteem en de andere het wisselbestand.
    2. 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:

    1. Zet het systeemdatabasebestand en het tempdb-bestand op twee verschillende schijven.
    2. 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
  1. We schakelen replicatie in voor de SalesDB-VM.
  2. 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

  1. Noteer de paden van SQL-tempdb.mdf en tempdb.ldf voordat de failover wordt uitgevoerd.
  2. 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).
  3. Meld u aan bij de Virtuele Azure-machine.
  4. Initialiseer en formatteer de nieuw toegevoegde schijf via de schijfbeheerconsole (diskmgmt.msc).
  5. Wijs dezelfde stationsletter toe die is gebruikt door de SQL tempdb-schijf (F:)
  6. Maak een tempdb-map op de F:-schijf (F:\MSSQL\Data).
  7. Start de SQL-service via de serviceconsole.

Een bestaande tijdelijke opslagschijf gebruiken

  1. Open een opdrachtprompt.

  2. Voer SQL Server in de herstelmodus uit via de opdrachtprompt.

    Net start MSSQLSERVER /f / T3608
    
  3. 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
    
  4. Stop de Microsoft SQL Server-service.

    Net stop MSSQLSERVER
    
  5. 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:

Schermopname van het dialoogvenster Virtueel geheugen met de regel D: Station [Pagefile volume] gemarkeerd met een wisselbestandsgrootte (MB) van 3000-7000.

  1. We schakelen replicatie in voor de VIRTUELE machine.
  2. 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:

Instellingen voor het wisselbestand op de virtuele Azure-machine

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:

Instellingen voor het wisselbestand op de on-premises virtuele machine

  1. We schakelen replicatie in voor de VIRTUELE machine.
  2. 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:

Schermopname van het dialoogvenster Virtueel geheugen met de lijn C: Station gemarkeerd met de instelling Voor wisselbestandsgrootte van 'Door systeem beheerd'.

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.