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
Azure-beschikbaarheidszones zijn ten minste drie fysiek afzonderlijke groepen datacenters binnen elke Azure-regio. Datacenters binnen elke zone zijn uitgerust met onafhankelijke energie-, koelings- en netwerkinfrastructuur. In het geval van een storing in een lokale zone worden beschikbaarheidszones zodanig ontworpen dat als de ene zone wordt beïnvloed, regionale services, capaciteit en hoge beschikbaarheid worden ondersteund door de resterende twee zones.
Fouten kunnen variëren van software- en hardwarefouten tot gebeurtenissen zoals aardbevingen, overstromingen en brand. Tolerantie voor fouten wordt bereikt met redundantie en logische isolatie van Azure-services. Zie Regio's en beschikbaarheidszones voor meer informatie over beschikbaarheidszones in Azure.
Services met azure-beschikbaarheidszones zijn ontworpen om het juiste niveau van betrouwbaarheid en flexibiliteit te bieden. Ze kunnen op twee manieren worden geconfigureerd. Ze kunnen zone-redundant zijn, met automatische replicatie tussen zones of zonegebonden, waarbij exemplaren zijn vastgemaakt aan een specifieke zone. U kunt deze benaderingen ook combineren. Zie Aanbevelingen voor meer informatie over zone-redundante versus zone-redundante architectuur voor het gebruik van beschikbaarheidszones en regio's.
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 bij het implementeren van een elastisch SAN ZRS selecteert voor de redundantieoptie van uw SAN, wordt zonegebonden failover ondersteund door het platform zonder handmatige tussenkomst. Een elastisch SAN met ZRS is ontworpen om zichzelf te herstellen en zichzelf opnieuw te verdelen om automatisch te profiteren van gezonde zones.
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
De latentieverschillen tussen een elastisch SAN op LRS en een elastisch SAN op ZRS zijn niet bijzonder hoog. Voor workloads die gevoelig zijn voor latentiepieken, kunt u echter een elastisch SAN in LRS overwegen omdat deze de laagste latentie biedt.
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 voordat u nadenkt 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.