- Identifikation af en tilgængelighedszonekode
- Lagringslag vs. serverforekomster
- Hvad giver Multi-AZ-implementering?
For fuldt ud at forstå, hvad en Multi-AZ Deployment betyder for din infrastruktur, er det afgørende at genkende, hvordan Amazon Web Services er konfigureret over hele kloden, og dermed hvordan det leverer redundanstjenesterne uanset din placering.
Som beskrevet i den officielle dokumentation består AWS Cloud af en række Regions , som er fysiske steder rundt om i verden, såsom Oregon, USA; North Virginia, USA; Irland; og Tokyo.
Inden for hver Region eksisterer en række separate fysiske datacentre, kendt som Availability Zones . Hver Availability Zone er en selvstændig facilitet med sin egen strøm, tilslutningsmuligheder og netværksmuligheder. De fleste Regions er hjemsted for 2-3 forskellige Availability Zones hver, der giver tilstrækkelig redundans, når det er nødvendigt inden for en given Region .
Mens Amazon altid udvider deres Region og Availability Zone dækning, kan du se et aktuelt kort over AWS Cloud-infrastrukturen på billedet nedenfor:
Billede udlånt af Amazon Web Services
Alle Availability Zones inden for en enkelt Region er forbundet med hinanden via privat fiberoptisk netværk, hvilket tillader hver Availability Zone at kommunikere med hinanden og overføre data hurtigt og effektivt efter behov.
Identifikation af en tilgængelighedszonekode
Når du opretter en ny instans gennem AWS-dashboardet, kan du blive præsenteret for muligheden for at vælge en specifik Availability Zone , eller i mange tilfælde blot en Region og systemet vil vælge Availability Zone for dig.
Regions er mærket med en simpel streng for at præsentere landet og/eller underregionen, hvis det er nødvendigt. For eksempel us-west-2 er betegnelsen for Oregon, USAs Region mens us-west-1 er for Californien, USA.
Availability Zones er udpeget ved at følge Region tag med en bogstavbetegnelse, såsom us-west-1b eller us-west-2a .
Lagerlag vs serverforekomster
Et andet vigtigt koncept at forstå for at forstå, hvad Multi-AZ Deployments entail er forskellen mellem storage layer og server instance .
server instance for din database opfattes bedst som den fysiske maskine, der styrer strukturen af din database og ruter alle dine data, der er indeholdt i storage layer .
storage layer er en SSD-understøttet virtualiseret repræsentation af alle de faktiske data i din database. Nøgleordet, der skal fokuseres på her, er virtualiseret , hvilket er Amazons smarte måde at sige, at storage layer som repræsenterer de faktiske data i dit system er ikke knyttet til en fysisk placering eller maskine, men er i stedet virtualiseret og udbredt til mange lokationer (seks i alt på tværs af tre Availability Zones i de fleste tilfælde).
Hvad giver Multi-AZ-implementering?
I næsten alle tilfælde, der bruger Amazon Web Services, er det standardpraksis for storage layer (hvor alle data findes) for at blive redundant lagret på tværs af alle Availability Zones inden for den givne Region uden ekstra omkostninger. I tilfælde af at én Availability Zone går offline af en eller anden grund (så usandsynligt det end måtte være), er systemet allerede på plads til øjeblikkeligt og automatisk at fortsætte tjenesterne i din database gennem en identisk kopi af storage layer fra en af de andre tilsluttede Availability Zones .
Men , medmindre andet er angivet, anvendes denne redundans kun på storage layer , men eksisterer ikke for den fysiske maskine i din faktiske server instance . Hvis noget skulle forårsage Availability Zone hvor din server instance ligger til nedlukning, vil din database ophøre med at fungere som den fysiske server instance er offline.
Det er her Multi-AZ Deployment kommer ind for tjenester som Amazon Aurora. Ligesom den automatiske redundans af dataene i dit storage layer , en Multi-AZ Deployment betyder, at din server instance er også redundant kopieret på tværs af flere Availability Zones . Af denne grund kan enhver Amazon Aurora Multi-AZ Deployment er sikret, at bør en enkelt Availability Zone gå offline, hvor den fysiske server instance maskinen befinder sig, initieres en automatisk failover på en opdateret standby-replikering i en anden tilsluttet Availability Zone .
Som diskuteret i den officielle dokumentation, for at maksimere dit systems oppetid, udføres failover-proceduren (som typisk kun tager 1-2 minutter) automatisk i tilfælde af en af følgende hændelser:
- Tab af tilgængelighed i primær
Availability Zone - Tab af netværksforbindelse til primær
- Fejl i computerenheden på primær
- Lagerfejl på primær