Betrouwbaarheid in elastisch SAN
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 afzonderlijke groepen datacenters binnen elke Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.
Zie Wat zijn beschikbaarheidszones in Azure voor meer informatie over beschikbaarheidszones?
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.
Zone-down-ervaring
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 goede 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, moet u een momentopname maken van de volumes van uw elastische SAN, deze exporteren naar momentopnamen van beheerde schijven, een elastisch SAN implementeren in ZRS en vervolgens volumes maken op het SAN in ZRS met behulp van deze momentopnamen van schijven. Zie Snapshot Azure Elastic SAN-volumes (preview) voor meer informatie over het gebruik van momentopnamen (preview).
Herstel na noodgevallen en bedrijfscontinuïteit
Herstel na noodgevallen (DR) gaat over het herstellen van gebeurtenissen met een hoge impact, zoals natuurrampen of mislukte implementaties die downtime en gegevensverlies tot gevolg hebben. 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 noodgevallen voordat u begint na te denken over het maken van uw plan voor herstel na noodgevallen.
Als het gaat om herstel na noodgevallen, gebruikt Microsoft het model voor gedeelde verantwoordelijkheid. In een model voor gedeelde verantwoordelijkheid zorgt Microsoft ervoor dat de basisinfrastructuur en platformservices beschikbaar zijn. Tegelijkertijd repliceren veel Azure-services niet automatisch gegevens of vallen ze 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 ter ondersteuning van herstel na noodgeval en u kunt servicespecifieke functies gebruiken om snel herstel te ondersteunen om uw DR-plan te ontwikkelen.
Herstel na noodgevallen voor één regio en meerdere regio's
Voor Azure Elastic SAN bent u verantwoordelijk voor de DR-ervaring. U kunt momentopnamen van uw volumes maken en deze exporteren naar momentopnamen van beheerde schijven. Vervolgens kunt u een incrementele momentopname kopiëren naar een nieuwe regio om uw gegevens op te slaan zich 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.
Tolerantie voor capaciteit en proactief herstel na noodgevallen
Microsoft en haar klanten werken onder het Model voor gedeelde verantwoordelijkheid. Gedeelde verantwoordelijkheid betekent dat u voor herstel na noodgeval (klantverantwoordelijke services) herstel na noodgeval moet aanpakken voor elke service die u implementeert en controleert. U moet elke service die u implementeert voorafvalideren, werkt met elastic SAN. Om ervoor te zorgen dat herstel proactief is, moet u altijd secundaire databases vooraf implementeren, omdat er geen garantie is voor capaciteit op het moment van impact voor degenen die de toewijzing niet vooraf hebben toegewezen.