Delen via

Betrouwbaarheid in Azure NetApp Files

Azure NetApp Files is een systeemeigen, hoogwaardige oplossing voor bestandsopslag die naadloos in Azure kan worden geïntegreerd en het delen van bestanden tussen clients mogelijk maakt via SMB-protocollen (Network File System) en Server Message Block (SMB). Azure NetApp Files is ontworpen voor hoge prestaties en biedt schaalbare en veilige bestandsopslag die wordt beheerd als een service.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe u NetApp Files bestand maakt tegen verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone en regio-storingen. Het beschrijft ook hoe u back-ups kunt gebruiken om te herstellen van andere soorten problemen en onderstreept enkele belangrijke informatie over de Service Level Agreement (SLA) van Azure NetApp Files.

Aanbevelingen voor productie-implementatie

Zie best practices voor architectuur voor Azure NetApp Files in het Azure Well-Architected Framework voor meer informatie over het implementeren van Azure NetApp Files ter ondersteuning van de betrouwbaarheidsvereisten van uw oplossing en hoe betrouwbaarheid van invloed is op andere aspecten van uw architectuur.

Overzicht van betrouwbaarheidsarchitectuur

Als u Azure NetApp Files wilt gebruiken, moet u een NetApp-account configureren dat capaciteitspools bevat die als host fungeren voor volumes. U kunt capaciteit en doorvoer onafhankelijk configureren en opties voor gegevensbeveiliging beheren die aan verschillende behoeften voldoen. U kunt replicatie tussen volumes inschakelen, zelfs als ze zich op verschillende locaties bevinden.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle in de cloud gehoste toepassingen moeten de richtlijnen voor tijdelijke foutafhandeling van Azure volgen wanneer ze communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

Naast tijdelijke fouttypen die van invloed kunnen zijn op elke cloudoplossing, kan incidenteel gepland onderhoud, zoals platformupdates, service-updates en software-upgrades, ook van invloed zijn op Azure NetApp Files.

Vanuit het perspectief van een bestandsprotocol zoals NFS en SMB, zijn tijdelijke fouten niet storend als de toepassing de invoer/uitvoer (I/O) pauzes kan verwerken die zich tijdens deze storingen kunnen voordoen. De I/O-pauzes zijn doorgaans kort, variërend van een paar seconden tot 30 seconden. Voor sommige toepassingen is mogelijk afstemming vereist om de I/O-pauzes af te handelen.

Het NFS-protocol is robuust en bestandsbewerkingen op de clientserver blijven over het algemeen normaal. Voor sommige toepassingen is het afstemmen mogelijk vereist voor het afhandelen van I/O-pauzes gedurende 30 tot 45 seconden. Wees ervoor dat u op de hoogte bent van de instellingen voor veerkracht van de toepassing om om te gaan met de onderhoudsevenementen van de opslagdienst.

Voor menselijke interactieve toepassingen die gebruikmaken van het SMB-protocol zijn de standaardprotocolinstellingen meestal voldoende. Azure NetApp Files biedt ook ondersteuning voor continue beschikbaarheid van SMB, waardoor transparante SMB-failover mogelijk is. SMB Transparent Failover elimineert onderbrekingen die serviceonderhoudsevenementen veroorzaken. Het verbetert ook de betrouwbaarheid en gebruikerservaring.

Continue SMB-beschikbaarheid is alleen beschikbaar voor specifieke toepassingen.

Zie Veelgestelde vragen over toepassingstolerantie voor Azure NetApp Files voor meer aanbevelingen.

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Azure NetApp Files ondersteunt zonegebonden implementaties van volumes. Gebruik de functie voor plaatsing van het volume van de beschikbaarheidszone in Azure NetApp Files om elk volume in één beschikbaarheidszone van uw keuze te implementeren. U kunt deze functie alleen gebruiken als Azure NetApp Files aanwezig is in die beschikbaarheidszone en voldoende capaciteit heeft. Als u latentiegevoelige toepassingen hebt, kunt u een volume implementeren in dezelfde beschikbaarheidszone als uw Azure-rekenresources en andere services.

In het volgende diagram geven oranje pijlen met gevulde pijlpuntjes weer hoe alle virtuele machines (VM's) in de regio binnen gekoppelde virtuele netwerken toegang kunnen krijgen tot alle Azure NetApp Files-resources. Groene pijlen geven aan hoe VM's die toegang hebben tot Azure NetApp Files-volumes in dezelfde zone, het foutdomein van de beschikbaarheidszone delen. Er is geen replicatie tussen de verschillende volumes op platformniveau.

Diagram waarin de plaatsing van het volume van de azure NetApp Files-beschikbaarheidszone wordt weergegeven.

Een implementatie met één zone is niet voldoende om te voldoen aan hoge betrouwbaarheidsvereisten. Als u gegevens asynchroon wilt repliceren tussen volumes in verschillende beschikbaarheidszones, kunt u replicatie tussen meerdere zones gebruiken. U moet replicatie tussen zones afzonderlijk configureren van de plaatsing van het volume van de beschikbaarheidszone.

Als een beschikbaarheidszone mislukt, bent u verantwoordelijk voor het detecteren van de fout en het overschakelen naar een alternatief volume in een andere zone.

Ondersteuning voor regio

Replicatie tussen zones is beschikbaar in alle regio's met beschikbaarheidszone die ondersteuning bieden voor Azure NetApp Files.

Overwegingen

  • Plaatsing van het volume in de beschikbaarheidszone in Azure NetApp Files biedt zonegebonden volumeplaatsing. U ziet een lage latentie wanneer u verbinding maakt met VM's binnen dezelfde beschikbaarheidszone. De plaatsing van het volume in de beschikbaarheidszone biedt echter geen nabijheidsplaatsing met VM's of andere resources en het volume bevindt zich mogelijk in een ander fysiek deel van het datacenter.

  • Replicatie is alleen toegestaan tussen verschillende Azure-abonnementen als ze zich binnen dezelfde Microsoft Entra-tenant bevinden.

  • Voor meer overwegingen over beschikbaarheidszones in Azure NetApp Files raadpleegt u Vereisten en overwegingen voor het gebruik van replicatie tussen zones en het beheren van de plaatsing van het volume van de beschikbaarheidszone.

Kosten

Er worden geen extra kosten in rekening gebracht voor het inschakelen van de plaatsing van volume in de beschikbaarheidszone in Azure NetApp Files. U betaalt alleen voor de capaciteitspools en resources die u in deze zones implementeert.

Gerepliceerde volumes worden gehost in een capaciteitspool. De kosten voor replicatie tussen zones zijn gebaseerd op de ingerichte capaciteitspoolgrootte en -laag. Er zijn geen extra kosten verbonden aan gegevensreplicatie.

Ondersteuning voor beschikbaarheidszones configureren

U moet de plaatsing van volumes en replicatie tussen zones afzonderlijk configureren.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer meerdere Azure NetApp Files-volumes worden geïmplementeerd in afzonderlijke beschikbaarheidszones, replicatie tussen zones is ingeschakeld en alle beschikbaarheidszones operationeel zijn.

  • Verkeersroutering tussen zones: Binnenkomende aanvragen worden doorgestuurd naar het specifieke volume, dat zich in de beschikbaarheidszone bevindt die u selecteert.

  • Gegevensreplicatie tussen zones: Replicatie tussen zones van Azure NetApp Files betekent dat alle wijzigingen in het bronvolume asynchroon worden gerepliceerd naar doelvolumes. U kunt bepalen hoe vaak de replicatie plaatsvindt. Replicatie tussen zones ondersteunt drie replicatieschema's: elke 10 minuten, elk uur en dagelijks.

    Belangrijk

    Het replicatieschema van 10 minuten wordt niet ondersteund voor grote volumes die gebruikmaken van replicatie tussen zones.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer meerdere Azure NetApp Files-volumes worden geïmplementeerd in afzonderlijke beschikbaarheidszones, replicatie tussen zones is ingeschakeld en er een storing in de beschikbaarheidszone is.

  • Detectie en reactie: U bent verantwoordelijk voor het detecteren van het verlies van een beschikbaarheidszone en het initiëren van een failover.

    Failover is een handmatig proces. Wanneer u het doelvolume moet activeren, bijvoorbeeld wanneer u een failover wilt uitvoeren naar de beschikbaarheidszone van de bestemming, moet u de replicatiepeering verbreken en vervolgens het doelvolume koppelen. Zie failover naar het doelvolumevoor meer informatie.

  • Kennisgeving: Als u de status van uw Azure NetApp Files-volume wilt bewaken, kunt u metrische gegevens van Azure Monitor gebruiken. Azure Monitor detecteert afwijkingen die wijzen op een zone-down scenario via realtime metrische gegevens, zoals invoer-/uitvoerbewerkingen per seconde (IOPS), latentie en capaciteitsgebruik. U kunt waarschuwingen en meldingen configureren om naar beheerders te verzenden, zodat ze onmiddellijk kunnen reageren door bestandsshares opnieuw te verdelen of failovers of andere protocollen voor herstel na noodgevallen te starten.

  • Actieve aanvragen: Tijdens een zone-downgebeurtenis kunnen actieve aanvragen onderbrekingen of verhoogde latenties ervaren.

  • Verwachte gegevensverlies: De hoeveelheid gegevensverlies of RPO (Recovery Point Objective), die u tijdens een zonefailover kunt verwachten, is afhankelijk van het replicatieschema voor meerdere zones dat u configureert.

    Replicatieschema Typische RPO
    Elke 10 minuten 20 minuten
    Per uur Twee uur
    Dagelijks Minder dan 48 uur

  • Verwachte downtime: Failover naar een andere zone vereist dat u de peeringrelatie onderbreekt om het doelvolume te activeren en lees- en schrijftoegang tot gegevens op de tweede site te bieden. Nadat u de peering hebt geactiveerd om te breken, kunt u verwachten dat de failover binnen één minuut wordt voltooid.

    De totale hoeveelheid downtime of de beoogde hersteltijd (RTO) die u tijdens een zonefailover kunt verwachten, is echter afhankelijk van meerdere factoren, waaronder hoe lang het duurt voordat uw systemen of processen het verlies van de zone detecteren en failoverprocessen initiëren. Het is ook belangrijk om te bepalen of u uw antwoord wilt automatiseren of handmatige stappen moet uitvoeren. Voor goed voorbereide configuraties vereist het algehele proces doorgaans een paar minuten tot een uur om te voltooien.

  • Verkeer omleiden: U bent verantwoordelijk voor het omleiden van uw toepassingsverkeer om verbinding te maken met het zojuist actieve doelvolume. Zie failover naar het doelvolumevoor meer informatie.

Zoneherstel

Failback is een handmatig proces waarvoor u een hersynchronisatiebewerking moet uitvoeren, de replicatie opnieuw moet herstellen en het bronvolume opnieuw moet koppelen voor toegang tot de client. Zie Herstel na noodgevallen beheren met behulp van Azure NetApp Files voor meer informatie.

Testen op zonefouten

U kunt de replicatieconfiguratie tussen zones veilig testen met behulp van momentopnamen van uw volume. Zie Herstel na noodgevallen testen voor Azure NetApp Files voor meer informatie over een benadering op hoog niveau voor het testen van de replicatieconfiguratie tussen zones.

Tolerantie voor storingen in de hele regio

Azure NetApp Files is standaard een service met één regio. Als de regio niet meer beschikbaar is, zijn volumes die zijn opgeslagen in die regio ook niet meer beschikbaar. Om de tolerantie te verbeteren als er een regionale storing optreedt, ondersteunt Azure NetApp Files replicatie tussen regio's. U kunt asynchroon gegevens repliceren van een Azure NetApp Files-volume (de bron) in de ene regio naar een ander Azure NetApp Files-volume (de bestemming) in een andere regio die door Microsoft vooraf wordt selectief gemaakt. Met deze mogelijkheid kunt u een failover uitvoeren voor uw kritieke toepassing als er een storing of noodgeval in de hele regio optreedt.

Opmerking

U kunt ook één volume repliceren naar een andere beschikbaarheidszone en naar een andere regio. Zie Azure NetApp Files-replicatie begrijpen voor meer informatie.

Ondersteuning voor regio

De secundaire regio waarnaar u uw volumes kunt repliceren, is afhankelijk van de primaire regio. Zie ondersteunde regioparen voor meer informatie.

Overwegingen

Replicatie is alleen toegestaan tussen verschillende Azure-abonnementen als ze zich binnen dezelfde Microsoft Entra-tenant bevinden.

Zie Vereisten en overwegingen voor het gebruik van replicatie tussen regio's in Azure NetApp Files voor andere overwegingen met betrekking tot replicatie tussen regio's.

Kosten

Replicatiekosten tussen regio's zijn gebaseerd op de hoeveelheid gegevens die u repliceert. Zie Kostenmodel voor replicatie tussen regio's voor meer informatie en enkele voorbeeldscenario's.

Ondersteuning voor meerdere regio's configureren

Gedrag wanneer alle regio's in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer Azure NetApp Files-volumes zijn geconfigureerd voor het gebruik van replicatie tussen regio's en beide regio's operationeel zijn.

  • Verkeersroutering tussen regio's: Binnenkomende aanvragen worden doorgestuurd naar het specifieke volume, dat zich in de primaire regio bevindt.

  • Gegevensreplicatie tussen regio's: Replicatie tussen regio's in Azure NetApp Files betekent dat alle wijzigingen in het bronvolume asynchroon worden gerepliceerd naar doelvolumes. U kunt bepalen hoe vaak de replicatie plaatsvindt. Replicatie tussen regio's ondersteunt drie replicatieschema's: elke 10 minuten, elk uur en dagelijks.

    Belangrijk

    Het replicatieschema van 10 minuten wordt niet ondersteund voor grote volumes die gebruikmaken van replicatie tussen regio's.

  • Replicatiestatus bewaken: U kunt de status van de peeringrelatie controleren en u kunt waarschuwingen configureren om u op de hoogte te stellen als de replicatievertraging hoger is dan de verwachte drempelwaarde. Zie De status van de replicatierelatie weergeven en controleren voor meer informatie.

Gedrag tijdens een regiofout

In deze sectie wordt beschreven wat u kunt verwachten wanneer Azure NetApp Files-volumes zijn geconfigureerd voor het gebruik van replicatie tussen regio's en er een storing is in de primaire regio.

  • Detectie en reactie: U bent verantwoordelijk voor het detecteren van het verlies van een regio en het initiëren van een failover. Failover is een handmatig proces. Wanneer u het doelvolume moet activeren, bijvoorbeeld wanneer u een failover naar de doelregio wilt uitvoeren, moet u de replicatiepeering verbreken en vervolgens het doelvolume koppelen. Zie failover naar het doelvolumevoor meer informatie.

  • Kennisgeving: Als u de status van uw Azure NetApp Files-volume wilt bewaken, kunt u metrische gegevens van Azure Monitor gebruiken. Azure Monitor detecteert afwijkingen die wijzen op een scenario waarbij een regio uitvalt via realtime metrische gegevens, zoals IOPS, latentie en capaciteitsgebruik. U kunt waarschuwingen en meldingen configureren om naar beheerders te verzenden, zodat ze onmiddellijk kunnen reageren door bestandsshares opnieuw te verdelen of failovers of andere protocollen voor herstel na noodgevallen te starten.

  • Actieve aanvragen: Tijdens een regio-downgebeurtenis kunnen actieve aanvragen onderbrekingen of verhoogde latenties ervaren.

  • Verwachte gegevensverlies: De hoeveelheid gegevensverlies of RPO die u tijdens een regiofailover kunt verwachten, is afhankelijk van het replicatieschema voor meerdere regio's dat u configureert.

    Replicatieschema Typische RPO
    Elke 10 minuten Minder dan 20 minuten
    Per uur Minder dan twee uur
    Dagelijks Minder dan 48 uur

  • Verwachte downtime: Voor failover naar een andere regio moet u de peeringrelatie verbreken om het doelvolume te activeren en lees- en schrijfgegevenstoegang te bieden op de tweede site. Nadat u de peering hebt geactiveerd om te breken, kunt u verwachten dat de failover binnen één minuut wordt voltooid.

    De totale hoeveelheid downtime of RTO die u tijdens een zonefailover kunt verwachten, is echter afhankelijk van meerdere factoren, waaronder hoe lang het duurt voordat uw systemen of processen het verlies van de zone detecteren en failoverprocessen initiëren. Het is ook belangrijk om te bepalen of u uw antwoord wilt automatiseren of handmatige stappen moet uitvoeren. Voor goed voorbereide configuraties vereist het algehele proces doorgaans een paar minuten tot een uur om te voltooien.

  • Verkeer omleiden: U bent verantwoordelijk voor het omleiden van uw toepassingsverkeer om verbinding te maken met het zojuist actieve doelvolume. Zie failover naar het doelvolumevoor meer informatie.

Regioherstel

Nadat de primaire regio is hersteld, bent u verantwoordelijk voor failback. Failback is een handmatig proces waarvoor u een hersynchronisatiebewerking moet uitvoeren, de replicatie opnieuw moet herstellen en het bronvolume opnieuw moet koppelen voor toegang tot de client. Zie Herstel na noodgevallen beheren met behulp van Azure NetApp Files voor meer informatie.

Test voor regiofouten

U kunt uw replicatieconfiguratie tussen regio's veilig testen met behulp van momentopnamen van uw volume. Zie Herstel na noodgevallen testen voor Azure NetApp Files voor meer informatie over een benadering op hoog niveau voor het testen van uw replicatieconfiguratie tussen regio's.

Backups en herstel

Azure NetApp Files-back-up breidt de mogelijkheden voor gegevensbeveiliging van Azure NetApp Files uit door een volledig beheerde back-upoplossing te bieden voor herstel, archief en naleving op lange termijn. Back-ups die door de service worden gemaakt, worden opgeslagen in Azure Storage, onafhankelijk van volumemomentopnamen die beschikbaar zijn voor herstel of klonen op korte termijn. Back-ups die door de service worden gemaakt, kunnen worden hersteld naar nieuwe Azure NetApp Files-volumes binnen de regio. Back-ups van Azure NetApp Files ondersteunen zowel op beleid gebaseerde (geplande) back-ups als handmatige (on-demand) back-ups.

Voor verdere beveiliging voegen Momentopnamen van Azure NetApp Files stabiliteit, schaalbaarheid en snelle herstelbaarheid toe zonder dat dit van invloed is op de prestaties. Ze bieden de basis voor andere redundantieoplossingen, waaronder back-up, replicatie tussen regio's en replicatie tussen zones.

Voor de meeste oplossingen hoeft u niet uitsluitend te vertrouwen op back-ups. Gebruik in plaats daarvan de andere mogelijkheden die in deze handleiding worden beschreven om uw tolerantievereisten te ondersteunen. Back-ups beschermen echter tegen enkele risico's die andere benaderingen niet opleveren. Zie Wat zijn redundantie, replicatie en back-up? voor meer informatie.

Diensteniveauovereenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

Verwante inhoud

  • Last updated on