Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
In dit artikel wordt de betrouwbaarheidsondersteuning in Azure Elastic SAN beschreven en wordt zowel regionale tolerantie behandeld als beschikbaarheidszones en herstel na noodgevallen en bedrijfscontinuïteit.
Ondersteuning voor beschikbaarheidszone
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 ondersteunt implementatie van beschikbaarheidszones met lokaal redundante opslag (LRS) en regionale implementatie met zone-redundante opslag (ZRS).
Vereisten
LRS en ZRS Elastic SAN zijn momenteel alleen beschikbaar in een subset van regio's. Zie Schaaldoelen voor Elastisch SAN voor een lijst met regio's.
Een resource maken met behulp van beschikbaarheidszones
Zie Een elastisch SAN implementeren om een elastisch SAN te maken waarvoor een beschikbaarheidszone is ingeschakeld.
Ontspanningservaring
Als u bij het implementeren van een elastisch SAN ZRS selecteert voor de redundantieoptie van uw SAN, wordt zonegebonden failover ondersteund door het platform. Als u een privé-eindpunt gebruikt om verbinding te maken met uw elastische SAN, vindt deze failover plaats zonder handmatige tussenkomst. Een elastische SAN van ZRS die gebruikmaakt van privé-eindpunten is ontworpen om zichzelf automatisch te herstellen en opnieuw te verdelen, zodat het kan profiteren van gezonde zones. Er kunnen enkele minuten na een failover beschikbaarheid en prestatievermindering optreden totdat het SAN zichzelf opnieuw in evenwicht brengt.
Als u verbinding maakt met behulp van opslagservice-eindpunten, wordt zonegebonden failover ondersteund, maar is mogelijk handmatige interventie nodig. Een elastische SAN van ZRS die gebruikmaakt van opslagservice-eindpunten, schakelt niet automatisch over naar een gezonde zone. Mogelijk moet u de iSCSI-initiator opnieuw opstarten om een failover naar een andere, gezonde zone te starten.
Als u een elastisch LRS-SAN hebt geïmplementeerd, moet u mogelijk een nieuwe SAN implementeren met behulp van momentopnamen die zijn geëxporteerd naar beheerde schijven.
Ontwerp met lage latentie
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.
Migratie van beschikbaarheidszone
Als u een elastisch SAN op LRS wilt migreren naar ZRS, maakt u een momentopname van uw Elastische SAN-volumes, exporteert u deze naar momentopnamen van beheerde schijven, implementeert u een elastisch SAN in ZRS en maakt u vervolgens volumes op de SAN in ZRS met behulp van deze momentopnamen van schijven. Zie Snapshot Azure Elastic SAN-volumes voor meer informatie over het gebruik van momentopnamen.
Herstel na noodgevallen en bedrijfscontinuïteit
Herstel na noodgevallen (DR) verwijst naar procedures die organisaties gebruiken om te herstellen van gebeurtenissen met hoge impact, zoals natuurrampen of mislukte implementaties die leiden tot downtime en gegevensverlies. Ongeacht de oorzaak is de beste oplossing voor een noodgeval een goed gedefinieerd en getest DR-plan en een toepassingsontwerp dat actief dr ondersteunt. Zie Aanbevelingen voor het ontwerpen van een strategie voor herstel na noodgevallenvoordat u begint met het maken van uw plan voor herstel na noodgevallen.
Voor DR maakt Microsoft gebruik van het model voor gedeelde verantwoordelijkheid. In dit model zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Veel Azure-services repliceren echter niet automatisch gegevens of vallen terug van een mislukte regio om kruislings te repliceren naar een andere ingeschakelde regio. Voor deze services bent u verantwoordelijk voor het instellen van een plan voor herstel na noodgevallen dat geschikt is voor uw workload. De meeste services die worden uitgevoerd op PaaS-aanbiedingen (Platform as a Service) van Azure bieden functies en richtlijnen voor ondersteuning van disaster recovery. U kunt servicespecifieke functies gebruiken om snelle herstelbewerkingen te ondersteunen en uw noodherstelplan te ontwikkelen.
Herstel na noodgevallen voor één regio en meerdere regio's
Voor Elastic SAN bent u verantwoordelijk voor de DR-ervaring (disaster recovery). U kunt momentopnamen van uw volumes maken en deze exporteren naar momentopnamen van beheerde schijven. Vervolgens kunt u een incrementele momentopname naar een nieuwe regio kopiëren om uw gegevens zich op te slaan in een andere regio dan de regio waarin uw Elastische SAN zich bevindt. U moet exporteren naar regio's die geografisch ver van uw primaire regio liggen om de kans te verminderen dat meerdere regio's worden getroffen vanwege een noodgeval.
Detectie, melding en beheer van storingen
U vindt storingsdeclaraties in Service Health - Microsoft Azure.
Capaciteit en proactieve veerkracht bij rampenherstel
Microsoft en haar klanten werken onder het Model voor gedeelde verantwoordelijkheid. Gedeelde verantwoordelijkheid betekent dat u voor cliëntaangebrachte vraagrespons (klantverantwoordelijke services) de vraagrespons moet aanpakken voor elke service die u implementeert en controleert. Valideer vooraf of elke service die u implementeert werkt met Elastic SAN. Om ervoor te zorgen dat herstel proactief is, moet u secundaire databases vooraf implementeren om ervoor te zorgen dat er geen capaciteitsproblemen zijn als uw omgevingen worden beïnvloed.