Betrouwbaarheid in Azure DDoS-netwerkbeveiliging
In dit artikel wordt ondersteuning voor betrouwbaarheid in Azure DDoS-netwerkbeveiliging beschreven, en zowel regionale tolerantie met beschikbaarheidszones als herstel in meerdere regio's en bedrijfscontinuïteit. Zie Azure-betrouwbaarheid voor een gedetailleerder overzicht van betrouwbaarheid in Azure.
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 DDoS Protection is standaard zone-redundant en wordt beheerd door de service zelf. U hoeft zelf geen zoneredundantie te configureren of in te stellen.
Herstel na noodgevallen en bedrijfscontinuïteit tussen regio's
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 in geografie in meerdere regio's
U kunt een van de twee benaderingen kiezen voor het beheren van bedrijfscontinuïteit voor DDoS Protection via uw VNets. De eerste benadering is reactief en de tweede benadering is proactief.
- Reactief plan voor bedrijfscontinuïteit. Virtuele netwerken zijn redelijk lichtgewicht resources. In het geval van een regionale storing kunt u Azure-API's aanroepen om een VNet met dezelfde adresruimte te maken, maar in een andere regio. Als u dezelfde omgeving wilt maken die aanwezig was in de betrokken regio, moet u API-aanroepen uitvoeren om VNet-resources van de primaire regio opnieuw te implementeren. Als on-premises connectiviteit beschikbaar is, zoals in een hybride implementatie, moet u een nieuwe VPN-gateway implementeren en verbinding maken met uw on-premises netwerk.
Notitie
Een reactieve benadering voor het onderhouden van bedrijfscontinuïteit loopt altijd het risico dat u mogelijk geen toegang hebt tot de resources van de primaire regio, vanwege de omvang van het noodgeval. In dat geval moet u alle resources van de primaire regio opnieuw maken.
- Proactief plan voor bedrijfscontinuïteit. U kunt twee VNets maken met dezelfde privé-IP-adresruimte en resources in twee verschillende regio's van tevoren. Als u internetgerichte services host in het VNet, kunt u Traffic Manager instellen om verkeer op geografische locaties te routeren naar de regio die actief is. U kunt echter geen twee VNets met dezelfde adresruimte verbinden met uw on-premises netwerk, omdat dit routeringsproblemen zou veroorzaken. Op het moment van een noodgeval en verlies van een VNet in één regio kunt u het andere VNet in de beschikbare regio verbinden met de overeenkomende adresruimte voor uw on-premises netwerk.
Zie Een virtueel netwerk maken om een virtueel netwerk te maken.
Herstel na noodgevallen in geografie met één regio
Voor regio's met één regio in een noodscenario blijven het virtuele netwerk en de resources in de getroffen regio niet toegankelijk tijdens de serviceonderbreking.