Schijven uitsluiten van herstel na noodherstel

In dit artikel wordt beschreven hoe u schijven uitsluit van replicatie tijdens noodherstel van on-premises naar Azure met Azure Site Recovery. U kunt schijven om een aantal redenen uitsluiten van replicatie:

  • Zodat niet-belangrijk gegevensverloop op de uitgesloten schijf niet wordt gerepliceerd.
  • Verbruikte replicatiebandbreedte of resources aan de doelzijde optimaliseren.
  • Opslag- en netwerkresources 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

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 ERE basic of dynamisch is in de gast-VM. Als niet alle afhankelijke dynamische volumeschijven 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 een schijf die wordt repliceren niet uitsluiten.

Schakel replicatie voor de VM uit en schakel deze opnieuw in.
U kunt een schijf die wordt repliceren niet uitsluiten. U kunt een schijf die wordt repliceren niet uitsluiten.
Mobility-service (VMware) Niet relevant U kunt schijven alleen uitsluiten op VM's met de Mobility-service geïnstalleerd.

Dit betekent dat u de virtuele Mobility-service handmatig moet installeren op de VM's waarvoor u schijven wilt uitsluiten. U kunt het push-installatiemechanisme niet gebruiken, omdat het apparaat pas wordt geïnstalleerd Mobility-service replicatie is ingeschakeld.
Niet relevant.
Toevoegen/verwijderen U kunt beheerde schijven toevoegen aan Azure-VM's met replicatie ingeschakeld met beheerde schijven. U kunt schijven op Azure-VM's met replicatie niet verwijderen. U kunt geen schijven toevoegen of verwijderen nadat replicatie is ingeschakeld. Schakel replicatie uit en 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 de schijf ook 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 na een failover handmatig in Azure.
On-premises failbackschijven handmatig gemaakt Niet relevant Windows-VM's: voor schijven die handmatig in Azure zijn gemaakt, wordt geen back-back uitgevoerd. Als u bijvoorbeeld een fail over drie schijven hebt uitgevoerd en twee schijven rechtstreeks op een azure-VM maakt, wordt alleen een failback uitgevoerd voor de drie schijven met een failback.

Linux-VM's: voor schijven die handmatig in Azure zijn gemaakt, wordt een back-back uitgevoerd. Als u bijvoorbeeld een fail over drie schijven hebt uitgevoerd en twee schijven op een virtuele Azure-VM maakt, wordt voor alle vijf een failback uitgevoerd. U kunt geen schijven die handmatig zijn gemaakt, uitsluiten van failback.
Voor schijven die handmatig zijn gemaakt in Azure, wordt geen back-back uitgevoerd. Als u bijvoorbeeld een fail over drie schijven hebt uitgevoerd en twee schijven rechtstreeks op een virtuele Azure-VM maakt, wordt er slechts een failback uitgevoerd voor drie schijven met een failback.
Niet-uitgesloten schijven voor on-premises failback Niet relevant Als u een failback naar de oorspronkelijke machine maakt, bevat de failback-VM-schijfconfiguratie 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 schijfconfiguratie van de failback-VM hetzelfde als die van de oorspronkelijke bron-VM-schijf. Schijven die zijn uitgesloten van replicatie van Hyper-V-site naar Azure zijn beschikbaar op de failback-VM.

Typische scenario's

Voorbeelden van gegevensverloop die goede kandidaten zijn voor uitsluiting, zijn onder andere schrijf schrijf naar een pagineringsbestand (pagefile.sys) en schrijf schrijft naar het tempdb-bestand van Microsoft SQL Server. Afhankelijk van de werkbelasting en het opslagsubsysteem kunnen de wisselbestanden en tempdb-bestanden een aanzienlijke hoeveelheid verloop registreren. Het repliceren van dit type gegevens naar Azure is resource-intensief.

  • Als u replicatie wilt optimaliseren voor een virtuele machine 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 Microsoft SQL Server tempdb-bestand als het systeemdatabasebestand 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 kunt afhandelen voor een bron-SQL Server Windows-VM - SalesDB, waarvoor we tempdb willen uitsluiten.

Schijven uitsluiten van replicatie

We hebben deze schijven op de Bron-SalesDB voor Windows-VM's.

Schijfnaam Gast-besturingssysteemschijf Stationsletter Schijfgegevenstype
DB-Disk0-OS Disk0 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. Replicatie wordt ingeschakeld voor de SalesDB-VM.
  2. Disk2 en Disk3 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 is gemaakt na een failover wanneer u een failover naar Azure hebt uitgevoerd. De Azure-VM bevat de schijven die in deze tabel worden samengevat.

Gast-besturingssysteemschijf Stationsletter Schijfgegevenstype
Disk0 C:\ Besturingssysteemschijf.
Disk1 E:\ Tijdelijke opslag

Azure voegt deze schijf toe. Omdat Disk2 en Disk3 zijn uitgesloten van replicatie, is E: de eerste letter van de lijst met beschikbare schijven. Azure wijst E: toe aan het tijdelijke opslagvolume. Andere station letters voor gerepliceerde schijven blijven hetzelfde.
Disk2 D:\ SQL-systeemdatabase en gebruikersdatabase 1
Disk3 G:\ Gebruikersdatabase2

In ons voorbeeld is Disk3, de SQL-tempdb-schijf, uitgesloten van replicatie en is deze niet beschikbaar op de virtuele Azure-computer, heeft de SQL-service de status Gestopt en is het pad F:\MSSQL\Data nodig. U kunt dit pad op verschillende manieren maken:

  • Voeg een nieuwe schijf toe na een failover en wijs tempdb-mappad 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-Azure-VM. De schijf moet dezelfde grootte (of groter) hebben als de tempdb-bronschijf van SQL (Disk3).
  3. Meld u aan bij de azure-VM.
  4. Initialiseer en formatteer de nieuw toegevoegde schijf via de schijfbeheerconsole (diskmgmt.msc).
  5. Wijs dezelfde stationletter 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 oorspronkelijke locatie

Laten we nu eens kijken hoe u schijven op VMware-VM's kunt verwerken wanneer u een failback naar uw oorspronkelijke on-premises locatie maakt.

  • Schijven die in Azure zijn gemaakt: omdat in ons voorbeeld een virtuele Windows-computer wordt gebruikt, worden schijven die u handmatig in Azure maakt, niet terug naar uw site gerepliceerd wanneer u een failback hebt uitgevoerd of een VM opnieuw beveiligt.
  • Tijdelijke opslagschijf in Azure: de tijdelijke opslagschijf wordt niet gerepliceerd naar on-premises hosts.
  • Uitgesloten schijven: schijven die zijn uitgesloten van replicatie van VMware naar Azure zijn na failback niet beschikbaar op de on-premises VM.

Voordat u een failback van de VMware-VM's naar de oorspronkelijke locatie maakt, zijn de instellingen voor de Azure-VM-schijf als volgt.

Gast-besturingssysteemschijf Stationsletter Schijfgegevenstype
Disk0 C:\ Besturingssysteemschijf.
Disk1 E:\ Tijdelijke opslag.
Disk2 D:\ SQL-systeemdatabase en gebruikersdatabase1.
Disk3 G:\ Gebruikersdatabase2.

Na de failback bevat de VMware-VM op de oorspronkelijke locatie de schijven samengevat in de tabel.

Gast-besturingssysteemschijf Stationsletter Schijfgegevenstype
Disk0 C:\ Besturingssysteemschijf.
Disk1 D:\ SQL-systeemdatabase en gebruikersdatabase1.
Disk2 G:\ Gebruikersdatabase2.

Hyper-V-VM's: schijven tijdens failback naar oorspronkelijke locatie

Laten we nu eens kijken hoe u schijven op Hyper-V-VM's verwerkt wanneer u een failback naar uw oorspronkelijke on-premises locatie hebt.

  • Schijven die in Azure zijn gemaakt: schijven die u handmatig in Azure maakt, worden niet terug naar uw site gerepliceerd wanneer u een failback maakt of een VM opnieuw beveiligt.
  • Tijdelijke opslagschijf in Azure: de tijdelijke opslagschijf wordt niet gerepliceerd naar on-premises hosts.
  • Uitgesloten schijven: na een 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 van de Hyper-V-VM's naar de oorspronkelijke locatie gaat uitvoeren, zijn de schijfinstellingen voor azure-VM's als volgt.

Gast-besturingssysteemschijf Stationsletter Gegevenstype schijf
Disk0 C:\ Besturingssysteemschijf.
Disk1 E:\ Tijdelijke opslag.
Disk2 D:\ SQL-systeemdatabase en gebruikersdatabase1.
Disk3 G:\ Gebruikersdatabase2.

Na de geplande failover (failback) van Azure naar on-premises Hyper-V, worden de schijven in de tabel samengevat op de Hyper-V-VM op de oorspronkelijke locatie.

Schijfnaam Gastbesturingssysteem schijf# Stationsletter Gegevenstype schijf
DB-Disk0-OS Disk0 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 wisselbestandsschijf uitsluiten

Laten we eens kijken hoe u schijfuitsluiting, failover en failover voor een bron-Windows-VM kunt afhandelen 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 Gast-besturingssysteemschijf Stationsletter Gegevenstype schijf
DB-Disk0-OS Disk0 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 voor het wisselbestand op de bron-VM zijn als volgt:

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

  1. Replicatie voor de VM wordt ingeschakeld.
  2. We sluiten DB-Disk1 uit van replicatie.

Schijven na failover

Na een failover bevat de Azure-VM de schijven samengevat in de tabel.

Schijfnaam Gastbesturingssysteemschijf# Stationsletter Gegevenstype op de schijf
DB-Disk0-OS Disk0 C:\ Besturingssysteemschijf
DB-Disk1 Disk1 D:\ Tijdelijke opslag/pagefile.sys

Omdat DB-Disk1 (D:) is uitgesloten, D: is de eerste letter van de beschikbare lijst.

Azure wijst D: toe aan het tijdelijke opslagvolume.

Omdat D: beschikbaar is, blijft de instelling voor het VM-wisselbestand hetzelfde).
DB-Disk2 Disk2 E:\ Gebruikersgegevens 1
DB-Disk3 Disk3 F:\ Gebruikersgegevens 2

De instellingen voor het wisselbestand op de azure-VM 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.

We hebben deze schijven op de bron-VM.

Schijfnaam Gast-besturingssysteemschijf Stationsletter Schijfgegevenstype
DB-Disk0-OS Disk0 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 voor het wisselbestand op de on-premises VM zijn als volgt:

Instellingen voor het wisselbestand op de on-premises virtuele machine

  1. Replicatie voor de VM wordt ingeschakeld.
  2. We sluiten DB-Disk1 uit van replicatie.

Schijven na failover

Na een failover worden de schijven in de tabel samengevat op de Azure-VM.

Schijfnaam Gastbesturingssysteem schijf# Stationsletter Gegevenstype schijf
DB-Disk0-OS Disk0 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 station C: voor het wisselbestand.
DB-Disk2 Disk2 E:\ Gebruikersgegevens 1
DB-Disk3 Disk3 F:\ Gebruikersgegevens 2

De instellingen voor het wisselbestand op de azure-VM zijn als volgt:

Schermopname van het dialoogvenster Virtueel geheugen met de regel C: Station gemarkeerd met de instelling Bestandsgrootte paginering van 'Door het 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 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.