Share via

Inzicht in periodieke back-upconfiguratie in Azure Service Fabric

  • Artikel

Het configureren van periodieke back-ups van betrouwbare stateful services of Reliable Actors bestaat uit de volgende stappen:

  1. Back-upbeleid maken: in deze stap worden een of meer back-upbeleidsregels gemaakt, afhankelijk van de vereisten.

  2. Back-up inschakelen: in deze stap koppelt u back-upbeleidsregels dat u in stap 1 hebt gemaakt aan de vereiste entiteiten, toepassing, service of een partitie.

Back-upbeleid maken

Een back-upbeleid bestaat uit de volgende configuraties:

  • Automatisch herstellen bij gegevensverlies: hiermee geeft u op of herstel automatisch moet worden geactiveerd met behulp van de meest recente beschikbare back-up voor het geval de partitie een gebeurtenis voor gegevensverlies ondervindt.

Notitie

Het wordt aanbevolen om Automatisch herstellen niet in te stellen in productieclusters

  • Maximum aantal incrementele back-ups: definieert het maximum aantal incrementele back-ups dat moet worden gemaakt tussen twee volledige back-ups. Maximum aantal incrementele back-ups geeft de bovengrens op. Een volledige back-up kan worden gemaakt voordat het opgegeven aantal incrementele back-ups wordt voltooid in een van de volgende voorwaarden

    1. De replica heeft nooit een volledige back-up gemaakt omdat deze primair is geworden.

    2. Sommige logboekrecords sinds de laatste back-up zijn afgekapt.

    3. De replica heeft de limiet maxAccumulatedBackupLogSizeInMB doorstaan.

  • Back-upschema: de tijd of frequentie waarop periodieke back-ups moeten worden uitgevoerd. U kunt plannen dat back-ups terugkeren op een bepaald interval of op een vast tijdstip dagelijks/wekelijks.

    1. Op frequentie gebaseerde back-upplanning: dit schematype moet worden gebruikt als u gegevensback-ups met vaste intervallen wilt maken. Het gewenste tijdsinterval tussen twee opeenvolgende back-ups wordt gedefinieerd met ISO8601 indeling. Back-upschema op basis van frequentie ondersteunt intervalresolutie tot de minuut.

      {
    "ScheduleKind": "FrequencyBased",
    "Interval": "PT10M"
}

    2. Tijdgebaseerde back-upplanning: dit schematype moet worden gebruikt als u gegevensback-ups wilt maken op specifieke tijdstippen van de dag of week. Het frequentietype planning kan dagelijks of wekelijks zijn.

      1. Dagelijkse back-upplanning op basis van tijd: dit schematype moet worden gebruikt als het nodig is om gegevensback-ups te maken op specifieke tijdstippen van de dag. Als u dit wilt opgeven, stelt u deze in op ScheduleFrequencyType Dagelijks; en stelt u in op RunTimes een lijst met de gewenste tijd gedurende de dag in ISO8601 notatie, wordt de datum die samen met de tijd is opgegeven, genegeerd. Vertegenwoordigt bijvoorbeeld 0001-01-01T18:00:00 dagelijks 18:00 uur, waarbij datum deel 0001-01-01 wordt genegeerd. In het onderstaande voorbeeld ziet u de configuratie voor het activeren van dagelijkse back-up om 9:00 en 18:00 uur elke dag.

        {
    "ScheduleKind": "TimeBased",
    "ScheduleFrequencyType": "Daily",
    "RunTimes": [
      "0001-01-01T09:00:00Z",
      "0001-01-01T18:00:00Z"
    ]
}

      2. Wekelijks back-upschema op basis van tijd: dit schematype moet worden gebruikt als u gegevensback-up op specifieke tijdstippen van de dag wilt maken. Als u dit wilt opgeven, stelt u deze optie in op ScheduleFrequencyType Wekelijks; ingesteld RunDays op een lijst met dagen in een week wanneer een back-up moet worden geactiveerd en ingesteld RunTimes op een lijst met de gewenste tijd gedurende de dag in ISO8601 notatie, wordt de datum die samen met tijd is opgegeven, genegeerd. Lijst met dagen van een week waarop de periodieke back-up moet worden geactiveerd. In het onderstaande voorbeeld ziet u de configuratie voor het activeren van een dagelijkse back-up om 9:00 en 18:00 uur van maandag tot en met vrijdag.

        {
    "ScheduleKind": "TimeBased",
    "ScheduleFrequencyType": "Weekly",
    "RunDays": [
       "Monday",
       "Tuesday",
       "Wednesday",
       "Thursday",
       "Friday"
    ],
    "RunTimes": [
      "0001-01-01T09:00:00Z",
      "0001-01-01T18:00:00Z"
    ]
}

  • Back-upopslag: hiermee geeft u de locatie op voor het uploaden van back-ups. Opslag kan Azure Blob Store of bestandsshare zijn.

    1. Azure Blob Store met beheerde identiteit: dit opslagtype moet worden geselecteerd wanneer gegenereerde back-ups moeten worden opgeslagen in Azure. Zowel zelfstandige als cloudclusters kunnen dit opslagtype gebruiken. Beschrijving voor dit opslagtype vereist BlobServiceUri en de naam van de container waar back-ups moeten worden geüpload. Als de container met de opgegeven naam niet beschikbaar is, wordt deze gemaakt tijdens het uploaden van een back-up. Vervang door account-name de naam van uw opslagaccount.

      {
    "StorageKind": "ManagedIdentityAzureBlobStore",
    "FriendlyName": "AzureMI_storagesample",
    "BlobServiceUri": "https://<account-name>.blob.core.windows.net",
    "ContainerName": "backup-container",
    "ManagedIdentityType": "VMSS",
    "ManagedIdentityClientId": "<Client-Id of User-Assigned MI>" 
}

      [OPMERKING] Gebruik de optionele parameter ManagedIdentityClientId met client-id van door de gebruiker toegewezen beheerde identiteit in het geval van meerdere door de gebruiker toegewezen beheerde identiteiten die zijn toegewezen aan uw resource of zowel SAMI als UAMI toegewezen, en we moeten UAMI als standaard gebruiken, anders is deze paramter niet nodig.

      volg de stappen voor toewijzing van beheerde identiteiten in Azure-resource:

      1. Door het systeem toegewezen of door de gebruiker toegewezen beheerde identiteit inschakelen in de VMSS Beheerde identiteiten configureren op virtuele-machineschaalset

      2. Rol toewijzen aan de beheerde identiteit van VMSS aan opslagaccount Azure-rollen toewijzen met behulp van Azure Portal - Azure RBAC

        1. Inzenderrol voor opslagblobgegevens minimaal

      Voor meer informatie over beheerde identiteiten

    2. Azure Blob Store met ConnectionString: dit opslagtype moet worden geselecteerd wanneer gegenereerde back-ups moeten worden opgeslagen in Azure. Zowel zelfstandige als cloudclusters kunnen dit opslagtype gebruiken. Beschrijving voor dit opslagtype vereist verbindingsreeks en de naam van de container waar back-ups moeten worden geüpload. Als de container met de opgegeven naam niet beschikbaar is, wordt deze gemaakt tijdens het uploaden van een back-up.

      {
    "StorageKind": "AzureBlobStore",
    "FriendlyName": "Azure_storagesample",
    "ConnectionString": "<Put your Azure blob store connection string here>",
    "ContainerName": "backup-container"
}

      Notitie

      Back-upherstelservice werkt niet met v1 Azure Storage ConnectionString wordt niet aanbevolen in productie als directe toegang tot resources zonder gebruikersverificatie

    3. Bestandsshare: dit opslagtype moet worden geselecteerd voor zelfstandige clusters wanneer het nodig is om on-premises gegevensback-up op te slaan. Beschrijving voor dit opslagtype vereist het pad naar de bestandsshare waar back-ups moeten worden geüpload. Toegang tot de bestandsshare kan worden geconfigureerd met een van de volgende opties

      1. Geïntegreerde Windows-verificatie, waarbij toegang tot bestandsshares wordt verstrekt aan alle computers die behoren tot het Service Fabric-cluster. In dit geval stelt u de volgende velden in om back-upopslag op basis van bestandsshares te configureren.

        {
    "StorageKind": "FileShare",
    "FriendlyName": "Sample_FileShare",
    "Path": "\\\\StorageServer\\BackupStore"
}

      2. Bestandsshare beveiligen met behulp van gebruikersnaam en wachtwoord, waarbij toegang tot de bestandsshare wordt verstrekt aan specifieke gebruikers. De opslagspecificatie van bestandsshares biedt ook de mogelijkheid om secundaire gebruikersnaam en secundair wachtwoord op te geven om terugvalreferenties op te geven voor het geval verificatie mislukt met de primaire gebruikersnaam en het primaire wachtwoord. In dit geval stelt u de volgende velden in om back-upopslag op basis van bestandsshares te configureren.

        {
    "StorageKind": "FileShare",
    "FriendlyName": "Sample_FileShare",
    "Path": "\\\\StorageServer\\BackupStore",
    "PrimaryUserName": "backupaccount",
    "PrimaryPassword": "<Password for backupaccount>",
    "SecondaryUserName": "backupaccount2",
    "SecondaryPassword": "<Password for backupaccount2>"
}

Notitie

Zorg ervoor dat de opslagbetrouwbaarheid voldoet aan of overschrijdt de betrouwbaarheidsvereisten van back-upgegevens.

  • Bewaarbeleid: hiermee geeft u het beleid op voor het behouden van back-ups in de geconfigureerde opslag. Alleen basisretentiebeleid wordt ondersteund.

    1. Basisretentiebeleid: Met dit bewaarbeleid kunt u optimaal opslaggebruik garanderen door back-upbestanden te verwijderen, die niet meer nodig zijn. RetentionDuration kan worden opgegeven om de periode in te stellen waarvoor back-ups moeten worden bewaard in de opslag. MinimumNumberOfBackups is een optionele parameter die kan worden opgegeven om ervoor te zorgen dat het opgegeven aantal back-ups altijd behouden blijft, ongeacht de RetentionDuration. In het onderstaande voorbeeld ziet u de configuratie voor het bewaren van back-ups gedurende 10 dagen en staat u niet toe dat het aantal back-ups lager is dan 20.

      {
    "RetentionPolicyType": "Basic",
    "RetentionDuration": "P10D",
    "MinimumNumberOfBackups": 20
}

Periodieke back-up inschakelen

Nadat u back-upbeleid hebt gedefinieerd om te voldoen aan de vereisten voor gegevensback-up, moet het back-upbeleid op de juiste wijze worden gekoppeld aan een toepassing of service of een partitie.

Notitie

Zorg ervoor dat er geen toepassingsupgrades worden uitgevoerd voordat u back-up inschakelt

Hiërarchische doorgifte van back-upbeleid

In Service Fabric is de relatie tussen toepassing, service en partities hiërarchisch zoals uitgelegd in het toepassingsmodel. Back-upbeleid kan worden gekoppeld aan een toepassing, service of een partitie in de hiërarchie. Back-upbeleid wordt hiërarchisch doorgegeven aan het volgende niveau. Ervan uitgaande dat er slechts één back-upbeleid is gemaakt en gekoppeld aan een toepassing, worden alle stateful partities die behoren tot alle reliable stateful services en Reliable Actors van de toepassing een back-up gemaakt met behulp van het back-upbeleid. Of als het back-upbeleid is gekoppeld aan een Reliable stateful service, worden alle partities ervan back-ups gemaakt met behulp van het back-upbeleid.

Back-upbeleid overschrijven

Er kan een scenario zijn waarin gegevensback-up met hetzelfde back-upschema vereist is voor alle services van de toepassing, met uitzondering van specifieke services waarbij gegevensback-ups moeten worden gemaakt met een hogere frequentieplanning of het maken van back-ups naar een ander opslagaccount of bestandsshare. Om dergelijke scenario's aan te pakken, biedt back-upherstelservice een faciliteit voor het overschrijven van doorgegeven beleid op service- en partitiebereik. Wanneer het back-upbeleid is gekoppeld aan een service of partitie, wordt het doorgegeven back-upbeleid overschreven, indien van toepassing.

Opmerking

In dit voorbeeld wordt setup gebruikt met twee toepassingen, MyApp_A en MyApp_B. Application MyApp_A bevat twee Reliable Stateful-services, SvcA1 & SvcA3 en één Reliable Actor-service, ActorA2. SvcA1 bevat drie partities terwijl ActorA2 en SvcA3 elk twee partities bevatten. Toepassings-MyApp_B bevat drie Reliable Stateful-services, SvcB1, SvcB2 en SvcB3. _SvcB1 en SvcB2 bevatten elk twee partities, terwijl SvcB3 drie partities bevat.

Stel dat de vereisten voor gegevensback-up van deze toepassingen als volgt zijn

  1. MyApp_A

    1. Maak een dagelijkse back-up van gegevens voor alle partities van alle Reliable Stateful-services en Reliable Actors die deel uitmaken van de toepassing. Back-upgegevens uploaden naar locatie BackupStore1.

    2. Een van de services, SvcA3, vereist elk uur een gegevensback-up.

    3. De grootte van gegevens in partitie SvcA1_P2 is meer dan verwacht en de back-upgegevens moeten worden opgeslagen op een andere opslaglocatie BackupStore2.

  2. MyApp_B

    1. Maak elke zondag om 8:00 uur een back-up van gegevens voor alle partities van de SvcB1-service . Back-upgegevens uploaden naar locatie BackupStore1.

    2. Maak elke dag om 8:00 uur een back-up van gegevens voor partitie-SvcB2_P1. Back-upgegevens uploaden naar locatie BackupStore1.

Om aan deze vereisten voor back-up van gegevens te voldoen, worden back-upbeleidsregels BP_1 voor BP_5 gemaakt en wordt back-up als volgt ingeschakeld.

  1. MyApp_A

    1. Maak back-upbeleid, BP_1, met een back-upschema op basis van frequentie, waarbij de frequentie is ingesteld op 24 uur. en back-upopslag geconfigureerd voor het gebruik van opslaglocatie BackupStore1. Schakel dit beleid in voor application MyApp_A met behulp van de Application Backup-API inschakelen. Met deze actie kunt u gegevensback-ups maken met behulp van back-upbeleid BP_1 voor alle partities van Reliable Stateful-services en Reliable Actors die behoren tot de toepassing MyApp_A.

    2. Maak back-upbeleid, BP_2, met een back-upschema op basis van frequentie, waarbij de frequentie is ingesteld op 1 uur. en back-upopslag geconfigureerd voor het gebruik van opslaglocatie BackupStore1. Schakel dit beleid in voor service-SvcA3 met behulp van de Service Backup-API inschakelen. Deze actie overschrijft het doorgegeven beleid BP_1 door expliciet ingeschakeld back-upbeleid BP_2 voor alle partities van service-SvcA3 die leiden tot back-up van gegevens met behulp van back-upbeleid BP_2 voor deze partities.

    3. Maak back-upbeleid, BP_3, met een back-upschema op basis van frequentie, waarbij de frequentie is ingesteld op 24 uur. en back-upopslag geconfigureerd voor het gebruik van opslaglocatie BackupStore2. Schakel dit beleid in voor partitie SvcA1_P2 met behulp van de Partitieback-up-API inschakelen. Deze actie overschrijft het doorgegeven beleid BP_1 door expliciet ingeschakeld back-upbeleid BP_3 voor partitie-SvcA1_P2.

  2. MyApp_B

    1. Maak back-upbeleid, BP_4, met een op tijd gebaseerd back-upschema, waarbij het schemafrequentietype is ingesteld op wekelijks, de uitvoeringsdagen zijn ingesteld op zondag en de uitvoeringstijden zijn ingesteld op 8:00 uur. Back-upopslag geconfigureerd voor het gebruik van opslaglocatie BackupStore1. Schakel dit beleid in voor service-SvcB1 met behulp van serviceback-up-API inschakelen. Met deze actie kunt u gegevensback-ups maken met behulp van back-upbeleid BP_4 voor alle partities van service-SvcB1.

    2. Maak back-upbeleid, BP_5, met een tijdgebaseerde back-upplanning waarbij het schemafrequentietype is ingesteld op dagelijks en uitvoeringstijden is ingesteld op 8:00 uur. Back-upopslag geconfigureerd voor het gebruik van opslaglocatie BackupStore1. Schakel dit beleid in voor partitie-SvcB2_P1 met behulp van de Partitieback-up-API inschakelen. Met deze actie kunt u gegevensback-ups maken met behulp van back-upbeleid BP_5 voor partitie-SvcB2_P1.

In het volgende diagram ziet u expliciet ingeschakeld back-upbeleid en doorgegeven back-upbeleid.

Service Fabric-toepassingshiërarchie

Back-up uitschakelen

Back-upbeleid kan worden uitgeschakeld wanneer u geen back-upgegevens hoeft te maken. Back-upbeleid dat is ingeschakeld op een toepassing, kan alleen worden uitgeschakeld bij dezelfde toepassing met behulp van de API voor het uitschakelen van de toepassingsback-up, back-upbeleid dat is ingeschakeld bij een service, kan worden uitgeschakeld bij dezelfde service met behulp van de Api voor back-up van partitie uitschakelen.

  • Als u back-upbeleid uitschakelt voor een toepassing , worden alle periodieke gegevensback-ups gestopt als gevolg van het doorgeven van het back-upbeleid aan Reliable Stateful-servicepartities of Reliable Actor-partities.

  • Als u het back-upbeleid voor een service uitschakelt, worden alle periodieke back-ups van gegevens gestopt als gevolg van het doorgeven van dit back-upbeleid aan de partities van de service.

  • Als u het back-upbeleid voor een partitie uitschakelt, wordt alle periodieke gegevensback-up gestopt vanwege het back-upbeleid op de partitie.

  • Tijdens het uitschakelen van back-ups voor een entiteit (toepassing/service/partitie), CleanBackup kan worden ingesteld op true om alle back-ups in geconfigureerde opslag te verwijderen.

    {
    "CleanBackup": true 
}

Notitie

Zorg ervoor dat er geen toepassingsupgrades worden uitgevoerd voordat u de back-up uitschakelt

Back-up onderbreken en hervatten

Bepaalde situaties kunnen een tijdelijke schorsing van periodieke back-ups van gegevens vereisen. In dergelijke situaties kan, afhankelijk van de vereiste, back-up-API worden gebruikt bij een toepassing, service of partitie. Periodieke back-upvering is transitief via substructuur van de hiërarchie van de toepassing vanaf het punt dat deze wordt toegepast.

Zodra de noodzaak van schorsing is verstreken, kan de periodieke gegevensback-up worden hersteld met behulp van de respectieve cv-back-up-API. Periodieke back-up moet worden hervat op dezelfde toepassing, service of partitie waar deze is onderbroken.

  • Als de schorsing is toegepast op een toepassing, moet deze worden hervat met de API voor het maken van een cv-toepassingsback-up .

  • Als de schorsing is toegepast op een service, moet deze worden hervat met behulp van de Api voor back-up van de cv-service .

  • Als de schorsing is toegepast op een partitie, moet deze worden hervat met behulp van de API voor het maken van back-ups van de partitie hervatten.

Verschil tussen back-ups onderbreken en uitschakelen

Back-up uitschakelen moet worden gebruikt wanneer back-ups niet meer nodig zijn voor een bepaalde toepassing, service of partitie. U kunt een back-upaanvraag uitschakelen, samen met de parameter Voor schone back-ups waar zijn, wat betekent dat alle bestaande back-ups ook worden verwijderd. Onderbreking moet echter worden gebruikt in scenario's waarin u back-ups tijdelijk wilt uitschakelen, zoals wanneer de lokale schijf vol raakt of het uploaden van back-ups mislukt vanwege een bekend netwerkprobleem, enzovoort.

Hoewel uitschakelen alleen kan worden aangeroepen op een niveau, dat eerder is ingeschakeld voor back-up, maar schorsing kan worden toegepast op elk niveau, dat momenteel is ingeschakeld voor back-up rechtstreeks of via overname/hiërarchie. Als back-up bijvoorbeeld is ingeschakeld op toepassingsniveau, kan een back-up alleen worden aangeroepen op toepassingsniveau, maar onderbreken kan worden aangeroepen bij toepassing, elke service of partitie onder die toepassing.

Automatisch herstellen bij gegevensverlies

De servicepartitie kan gegevens verliezen vanwege onverwachte fouten. De schijf voor twee van de drie replica's voor een partitie (inclusief de primaire replica) wordt bijvoorbeeld beschadigd of gewist.

Wanneer Service Fabric detecteert dat de partitie gegevensverlies heeft, wordt er een interfacemethode voor de partitie aangeroepen OnDataLossAsync en wordt verwacht dat de partitie de vereiste actie onderneemt om uit gegevensverlies te komen. Als in dit geval het effectieve back-upbeleid op de partitie is AutoRestoreOnDataLoss ingesteld op true , wordt het herstellen automatisch geactiveerd met behulp van de meest recente beschikbare back-up voor deze partitie.

Notitie

Het wordt aanbevolen om Automatisch herstellen niet in te stellen in productieclusters

Back-upconfiguratie ophalen

Afzonderlijke API's worden beschikbaar gesteld om back-upconfiguratiegegevens op te halen voor een toepassing, service en partitiebereik . Get Application Backup Configuration Info, Get Service Backup Configuration Info en Get Partition Backup Configuration Info zijn respectievelijk deze API's. Deze API's retourneren voornamelijk het toepasselijke back-upbeleid, bereik waarop het back-upbeleid wordt toegepast en details van back-upvering. Hieronder vindt u een korte beschrijving van de geretourneerde resultaten van deze API's.

  • Configuratiegegevens van toepassingsback-up: bevat de details van het back-upbeleid dat wordt toegepast op de toepassing en alle genegeerde beleidsregels op services en partities die bij de toepassing horen. Het bevat ook de schorsingsinformatie voor de toepassing en de bijbehorende services en partities.

  • Configuratiegegevens van de serviceback-up: bevat de details van effectief back-upbeleid bij de service en het bereik waarop dit beleid is toegepast en alle genegeerde beleidsregels op de partities. Het bevat ook de schorsingsinformatie voor de service en de bijbehorende partities.

  • Configuratiegegevens voor partitieback-up: bevat de details van effectief back-upbeleid op partitie en het bereik waarop dit beleid is toegepast. Het bevat ook de schorsingsinformatie voor de partities.

Beschikbare back-ups weergeven

Beschikbare back-ups kunnen worden weergegeven met behulp van de API Back-uplijst ophalen. Het resultaat van de API-aanroep bevat back-upgegevensitems met betrekking tot alle back-ups die beschikbaar zijn in de back-upopslag, die is geconfigureerd in het toepasselijke back-upbeleid. Er zijn verschillende varianten van deze API beschikbaar om beschikbare back-ups weer te geven die horen bij een toepassing, service of partitie. Deze API's ondersteunen het verkrijgen van de meest recente beschikbare back-up van alle toepasselijke partities of het filteren van back-ups op basis van de begin- en einddatum.

Deze API's bieden ook ondersteuning voor paginering van de resultaten, wanneer de parameter MaxResults is ingesteld op een niet-positief geheel getal, retourneert de API het maximum aantal back-upgegevensitems van MaxResults . Als er meer back-upgegevensitems beschikbaar zijn dan de waarde MaxResults , wordt er een vervolgtoken geretourneerd. Geldige vervolgtokenparameter kan worden gebruikt om de volgende set resultaten op te halen. Wanneer een geldige vervolgtokenwaarde wordt doorgegeven aan de volgende aanroep van de API, retourneert de API de volgende set resultaten. Er wordt geen vervolgtoken opgenomen in het antwoord wanneer alle beschikbare resultaten worden geretourneerd.

Hieronder vindt u de korte informatie over ondersteunde varianten.

  • Lijst met toepassingsback-ups ophalen: retourneert een lijst met back-ups die beschikbaar zijn voor elke partitie die deel uitmaakt van de gegeven Service Fabric-toepassing.

  • Lijst met serviceback-ups ophalen: retourneert een lijst met back-ups die beschikbaar zijn voor elke partitie die deel uitmaakt van een bepaalde Service Fabric-service.

  • Lijst met partitieback-ups ophalen: retourneert een lijst met back-ups die beschikbaar zijn voor de opgegeven partitie.

Volgende stappen