Betrouwbaarheid in elastische SAN van Azure

Azure Elastic SAN is een SAN-service (Cloud Native Storage Area Network) die een schaalbare, rendabele, krachtige en uitgebreide opslagoplossing biedt voor een scala aan rekenopties. Met elastisch SAN kunt u volumes maken en beheren. Dit zijn virtuele schijven die u kunt verbinden met uw virtuele machines, containers of andere Azure-services via het iSCSI-protocol.

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 Azure Elastic SAN bestand maakt tegen verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, fouten in beschikbaarheidszones en regiobrede fouten. Ook worden back-up- en herstelopties beschreven en wordt belangrijke informatie over de service level agreement (SLA) van Azure Elastic SAN gemarkeerd.

Aanbevelingen voor productie-implementatie voor betrouwbaarheid

Gebruik de volgende aanbevelingen voor productieworkloads:

Overzicht van betrouwbaarheidsarchitectuur

Elastisch SAN heeft een resourcehiërarchie met drie niveaus:

• Elastisch SAN: de resource op het hoogste niveau waar u redundantie configureert, opslagcapaciteit toewijst en prestatielimieten instelt. Het aantal basiseenheden dat aan uw elastische SAN is toegewezen, bepaalt de totale IOPS en doorvoer die beschikbaar is voor het hele SAN.
• Volumegroepen: beheerconstructies die worden gebruikt voor het beheren van volumes op schaal. Instellingen voor netwerktoegang, zoals privé-eindpunten of service-eindpunten, worden geconfigureerd op volumegroepniveau en overgenomen door alle volumes in de groep.
• Volumes: Afzonderlijke opslagvolumes gepartitioneerd op basis van de totale capaciteit van het SAN. Volumes zijn verbonden met rekenresources via het iSCSI-protocol.

Zie Elastische SAN-resources voor meer informatie over de resources die u implementeert.

Intern slaat Elastic SAN uw gegevens op in opslagclusters. Wanneer u uw Elastische SAN configureert voor het gebruik van lokaal redundante opslag (LRS), worden uw gegevens drie keer gerepliceerd binnen één opslagcluster in één datacenter. U kunt zone-redundante opslag (ZRS) configureren om kopieën van de gegevens op te slaan in drie beschikbaarheidszones. Zie Tolerantie voor fouten in beschikbaarheidszones voor meer informatie.

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 cloudtoepassingen moeten de Azure richtlijnen voor tijdelijke foutafhandeling volgen wanneer ze communiceren met api's, databases en andere onderdelen die in de cloud worden gehost. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

Als uw iSCSI-verbinding met een elastisch SAN-volume wordt onderbroken, probeert de iSCSI-initiator op de client automatisch opnieuw verbinding te maken. Tijdens het opnieuw verbinden kunt u een korte pauze in I/O-bewerkingen ervaren. Configureer uw iSCSI-initiator met de juiste instellingen voor opnieuw proberen en time-outs om tijdelijke onderbrekingen af te handelen. Zie De prestaties van uw elastische SAN optimaliseren voor gedetailleerde aanbevelingen voor iSCSI- en MPIO-instellingen.

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 Elastic SAN kunnen worden geconfigureerd voor het gebruik van zone-redundante opslag (ZRS), wat betekent dat uw gegevens synchroon worden gerepliceerd in drie beschikbaarheidszones in de regio. Met zoneredundantie kunt u tolerantie en betrouwbaarheid bereiken voor uw productieworkloads.

Uw connectiviteitsbenadering is van invloed op de mogelijkheid van uw workload om een failover transparant uit te voeren tijdens een zonefout. Gebruik privé-eindpunten om verbinding te maken met uw volumes. Privé-eindpunten ondersteunen automatische failover. Als u service-eindpunten gebruikt, is voor failover mogelijk handmatige tussenkomst vereist. Zie Leer over netwerkconfiguraties voor Elastic SAN voor meer informatie over de connectiviteitsmethoden.

Als u lokaal redundante opslag (LRS) gebruikt, blijft uw Elastische SAN onbeveiligd tegen fouten in de beschikbaarheidszone. LRS maakt het elastische SAN niet-zonegebonden door gegevens op te slaan in één beschikbaarheidszone in plaats van deze te verdelen over zones met ZRS.

Requirements

Regioondersteuning: Zone-redundante elastische SAN-resources kunnen worden geïmplementeerd in een subset van regio's. Zie Schaaldoelen voor Elastisch SAN voor een lijst met regio's.

Cost

Wanneer u een elastisch SAN met ZRS maakt, zijn de kosten hoger dan LRS. Zie Azure Elastic SAN prijzen voor meer informatie over prijzen.

Ondersteuning voor beschikbaarheidszones configureren

• Maak een nieuwe elastische SAN met ZRS: Wanneer u een elastisch SAN maakt en ZRS selecteert als redundantieoptie, wordt uw elastische SAN automatisch zone-redundant. U kunt de redundantieoptie niet wijzigen nadat de elastische SAN is gemaakt. Zie Een elastisch SAN implementeren voor meer informatie over het maken van een nieuwe elastische SAN-resource.

• Zoneredundantie inschakelen op een bestaande elastische LRS-SAN: U kunt een elastische LRS-SAN niet ter plaatse converteren naar ZRS. Als u wilt migreren, maakt u een momentopname van uw elastische SAN-volumes, exporteert u deze naar momentopnamen van beheerde schijven, implementeert u een nieuwe elastische SAN in ZRS en maakt u vervolgens volumes op de nieuwe elastische SAN met behulp van deze schijfmomentopnamen. Zie Snapshot Azure Elastic SAN volumes voor meer informatie.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een elastisch SAN configureert voor zoneredundantie en alle zones operationeel zijn.

• Bewerking tussen zones: Wanneer u verbinding maakt met een elastisch SAN-volume, wordt uw iSCSI-verbinding gerouteerd naar een cluster in een van de beschikbaarheidszones. Het platform routeert automatisch verkeer tussen zones.

• Replicatie van gegevens in meerdere zones: Wanneer een client gegevens naar een elastisch SAN-volume schrijft, worden die gegevens synchroon naar clusters binnen drie beschikbaarheidszones geschreven voordat de schrijfbewerking wordt bevestigd. Synchrone replicatie zorgt voor een hoog gegevensconsistentieniveau en zorgt ervoor dat er geen gegevensverlies is tijdens een zonefout.

  Het implementeren van een elastischE SAN van ZRS biedt meer betrouwbaarheid dan een elastisch LRS-SAN, maar voegt meer schrijflatentie toe. Benchmark uw Elastische SAN en simuleer de workload van uw toepassing om de latentie tussen LRS en ZRS te vergelijken om te zien of dit van invloed is op uw workload.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer u een elastisch SAN configureert voor zoneredundantie en er een storing is in een van de zones.

• Detectie en reactie: Het Elastic SAN-platform detecteert eventuele fouten in een beschikbaarheidszone. U hoeft niets te doen om een zonefailover te starten voor ZRS Elastische SAN's.

• Notification: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Service Health echter gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

• Actieve aanvragen: Wanneer een beschikbaarheidszone niet beschikbaar is, kan de service I/O-bewerkingen die worden uitgevoerd, beëindigen die verbinding maken met replica's in de betrokken zone en moet u deze bewerkingen opnieuw proberen. Als u privé-eindpunten gebruikt, voert de service automatisch een failover uit. Als u service-eindpunten gebruikt, moet u de iSCSI-initiator mogelijk opnieuw opstarten om een failover uit te voeren naar een goede zone.

• Verwachte gegevensverlies: Elastisch SAN voorkomt gegevensverlies tijdens een zonefout door gegevens synchroon te repliceren in drie beschikbaarheidszones.

• Verwachte downtime: Wanneer u privé-eindpunten gebruikt, vindt zonefailover automatisch plaats. Mogelijk ondervindt u een paar minuten na een failover een afname van de beschikbaarheid en prestaties, terwijl het SAN zichzelf opnieuw in evenwicht brengt.

  Wanneer u service-eindpunten gebruikt, schakelt Elastic SAN niet automatisch over naar een goede zone. Mogelijk moet u de iSCSI-initiator opnieuw opstarten om een failover naar een andere, gezonde zone te starten.

• Verkeer omleiden: Wanneer een zone niet beschikbaar is, detecteert het Elastische SAN-platform het verlies van de zone en routeert het verkeer naar de resterende gezonde zones.

  Als u automatische zonefailover wilt garanderen zonder handmatige tussenkomst, gebruikt u privé-eindpunten om verbinding te maken met uw elastische SAN. Wanneer u service-eindpunten gebruikt in plaats van privé-eindpunten, moet u de iSCSI-initiator mogelijk handmatig opnieuw opstarten om een failover naar een goede zone te starten.

Zoneherstel

Wanneer de beschikbaarheidszone wordt hersteld, herstelt het elastische SAN-platform automatisch normale bewerkingen en hervat de replicatie tussen drie zones. U hoeft geen actie te ondernemen.

Testen op zonefouten

Het Azure Elastic SAN platform beheert verkeersroutering, failover en zoneherstel voor zone-redundante resources. Omdat deze functie volledig wordt beheerd, hoeft u de foutprocessen van de beschikbaarheidszone niet te valideren.

Tolerantie voor storingen in de hele regio

Azure Elastic SAN is een service met één regio. Als de regio niet meer beschikbaar is, is uw Elastische SAN-resource ook niet beschikbaar. Er is geen ingebouwde replicatie voor meerdere regio's of failovers voor Elastisch SAN. U bent verantwoordelijk voor het ontwerpen van uw eigen oplossing voor herstel na noodgevallen in meerdere regio's als uw workload tolerantie op regioniveau vereist.

Aangepaste multiregionale oplossingen voor veerkracht

U bent verantwoordelijk voor het implementeren van herstel na noodgevallen voor meerdere regio's voor uw Elastische SAN-gegevens. De aanbevolen aanpak is om volumemomentopnamen te gebruiken.

1. Maak regelmatig momentopnamen. Gebruik volumesnapshots om kopieën van uw Elastic SAN-volumes op een bepaald tijdstip vast te leggen.

   Uw beoogde herstelpunt (RPO) is afhankelijk van hoe vaak u momentopnamen maakt en kopieert naar de secundaire regio. Hoe vaker u momentopnamen maakt en kopieert, hoe lager uw potentiële gegevensverlies tijdens een noodgeval.

2. Momentopnamen exporteren naar momentopnamen van beheerde schijven.Exporteer uw volumemomentopnamen naar momentopnamen van beheerde schijven, die naar andere regio's kunnen worden gekopieerd.

3. Kopieer momentopnamen naar een secundaire regio.Kopieer de incrementele momentopname naar een nieuwe regio die geografisch ver van uw primaire regio ligt. Dit vermindert het risico dat meerdere regio's worden getroffen door één noodgeval.

4. Terugzetten vanuit momentopnamen. Maak in een scenario voor herstel na noodgevallen nieuwe volumes op de secundaire elastische SAN op basis van de gekopieerde momentopnamen van beheerde schijven.

Uw beoogde hersteltijd (RTO) is afhankelijk van de grootte van uw gegevens, de tijd die nodig is voor het kopiëren van momentopnamen tussen regio's en de tijd die nodig is voor het implementeren en configureren van een nieuwe elastische SAN in de secundaire regio. Als u de hersteltijd wilt verminderen, kunt u overwegen om een secundair elastisch SAN in uw herstelregio te implementeren voordat er zich een noodgeval voordoet. Dit helpt ook om capaciteitsbeperkingen tijdens een storing te voorkomen.

Back-up maken en terugzetten

Back-ups en momentopnamen kunnen herstelpunten bieden voor beschadiging, schadelijke wijzigingen en sommige typen onbedoelde verwijdering, maar ze behouden geen opslag beschikbaar tijdens een storing in de infrastructuur. Beveiliging tegen onbedoelde volumeverwijdering is afhankelijk van de optie voor gegevensbeveiliging die u gebruikt. Gebruik deze opties met de andere methoden die in deze handleiding worden beschreven. Zie Redundantie, replicatie en back-up voor meer informatie over hoe replicatie en back-up verschillende risico's aanpakken.

Elastisch SAN ondersteunt twee opties voor gegevensbeveiliging:

• Azure Elastic SAN back-up: deze Azure Backup biedt een volledig beheerde oplossing voor het plannen van back-ups, het instellen van verlooptijdlijnen voor herstelpunten en het herstellen van gegevens naar een nieuw volume. Herstelpunten zijn onafhankelijk van de levenscyclus van het bronvolume, dus deze optie helpt beschermen tegen gegevensverlies tegen onbedoelde volumeverwijdering, ransomware en toepassingsupdates. Zie Azure Elastic SAN back-up voor meer informatie.

• Momentopnamen van elastisch SAN-volume: U kunt momentopnamen maken en beheren op basis van uw vereisten voor gegevensbescherming.

  Momentopnamen zijn incrementele, punt-in-tijd kopieën van uw volumes die ruimte verbruiken van de totale capaciteit van uw Elastic SAN. Momentopnamen van Elastic SAN-volumes worden samen met het bronvolume verwijderd, dus niet-geëxporteerde momentopnamen bieden geen herstelpunt bij het per ongeluk verwijderen van een volume.

  Maak momentopnamen met een frequentie die voldoet aan uw beoogde herstelpunt (RPO). U kunt momentopnamen handmatig maken of uw eigen automatisering bouwen om ze volgens een schema te maken.

  Momentopnamen die u maakt terwijl workloads worden uitgevoerd, zijn mogelijk alleen crashconsistent. Wanneer u bestandsconsistent herstel nodig hebt, bevriest u de volumes en schrijft u alle schrijfbewerkingen in behandeling weg voordat u de momentopnamen maakt. Coördineer momentopnamen voor alle volumes die gerelateerde gegevens bevatten en gebruik toepassingsspecifieke mechanismen wanneer u toepassingsconsistente herstel nodig hebt. Zie Een stabiele momentopname maken voor meer informatie.

  Momentopnamen worden opgeslagen in hetzelfde elastische SAN als uw volumes en gebruiken dezelfde redundantie-instelling. Ter bescherming tegen storingen in de hele regio exporteert u uw momentopnamen naar momentopnamen van beheerde schijven en kopieert u deze naar een andere regio. Zie Momentopname van volume exporteren en een incrementele momentopname kopiëren naar een nieuwe regio voor meer informatie.

  U kunt een nieuw elastisch SAN-volume maken op basis van een momentopname of een momentopname van een beheerde schijf. Zie Een volume maken op basis van een momentopname voor meer informatie.

Tolerantie voor serviceonderhoud

Microsoft past regelmatig service-updates toe en voert ander onderhoud uit. Het Azure platform verwerkt deze activiteiten automatisch en zorgt ervoor dat onderhoud naadloos en transparant voor u is. Er wordt geen downtime verwacht tijdens onderhoudsgebeurtenissen, tenzij u op de hoogte bent gesteld via Azure Service Health gepland onderhoud.

Diensteniveau-overeenkomst

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

• Wat is Azure Elastic SAN?
• Plan voor het implementeren van een Elastic SAN
• Betrouwbaarheid in Azure