- Identifiera en tillgänglighetszonkod
- Lagringslager kontra serverinstanser
- Vad ger Multi-AZ-distribution?
För att till fullo förstå vad en Multi-AZ Deployment För din infrastruktur är det viktigt att känna igen hur Amazon Web Services är konfigurerat över hela världen och därmed hur det tillhandahåller redundanstjänster oavsett var du befinner dig.
Som diskuteras i den officiella dokumentationen består AWS-molnet av ett antal Regions , som är fysiska platser runt om i världen, såsom Oregon, USA; North Virginia, USA; Irland; och Tokyo.
Inom varje Region Det finns ett antal separata fysiska datacenter, kända som Availability Zones . Varje Availability Zone är en fristående anläggning med egen kraft, anslutningsmöjligheter och nätverksmöjligheter. De flesta Regions är hem för 2-3 olika Availability Zones var och en, tillhandahåller adekvat redundans vid behov inom en given Region .
Medan Amazon alltid expanderar sin Region och Availability Zone täckning kan du se en aktuell karta över AWS Cloud-infrastrukturen i bilden nedan:
Bild med tillstånd från Amazon Web Services
Alla Availability Zones inom en enda Region är anslutna till varandra via privata fiberoptiska nätverk, vilket tillåter varje Availability Zone att kommunicera med varandra och överföra data snabbt och effektivt efter behov.
Identifiera en tillgänglighetszonskod
När du skapar en ny instans via AWS-instrumentpanelen kan du få möjlighet att välja en specifik Availability Zone , eller i många fall helt enkelt en Region och systemet kommer att välja Availability Zone för dig.
Regions är märkta med en enkel sträng för att presentera landet och/eller underregionen vid behov. Till exempel, us-west-2 är beteckningen för Oregon, USAs Region medan us-west-1 är för Kalifornien, USA.
Availability Zones anges genom att följa Region tagg med en bokstavsbeteckning, till exempel us-west-1b eller us-west-2a .
Lagringslager kontra serverinstanser
Ett annat viktigt koncept att förstå för att förstå vilka Multi-AZ Deployments innebär är skillnaden mellan storage layer och server instance .
server instance för din databas ses bäst som den fysiska maskinen som kontrollerar strukturen för din databas och rutter all din data som finns i storage layer .
storage layer är en SSD-stödd virtualiserad representation av alla faktiska data i din databas. Nyckelordet att fokusera på här är virtualiserat , vilket är Amazons snygga sätt att säga att storage layer som representerar den faktiska datan i ditt system är inte kopplad till någon fysisk plats eller maskin, utan är istället virtualiserad och sprids till många platser (sex totalt över tre Availability Zones i de flesta fall).
Vad ger Multi-AZ-distribution?
I nästan alla fall med Amazon Web Services är det standardpraxis för storage layer (där all data finns) för att lagras redundant i alla Availability Zones inom den givna Region utan extra kostnad. I händelse av att en Availability Zone går offline av någon anledning (hur osannolikt det än kan vara), är systemet redan på plats för att omedelbart och automatiskt fortsätta tjänsterna i din databas genom en identisk kopia av storage layer från en av de andra anslutna Availability Zones .
Men , om inte annat anges, tillämpas denna redundans endast på storage layer , men finns inte för den fysiska maskinen för din faktiska server instance . Om något skulle orsaka Availability Zone där din server instance ligger till avstängning, skulle din databas sluta fungera, som den fysiska server instance är offline.
Det är här Multi-AZ Deployment kommer in för tjänster som Amazon Aurora. Precis som den automatiska redundansen för data i ditt storage layer , en Multi-AZ Deployment betyder att din server instance kopieras också redundant över flera Availability Zones . Av denna anledning, alla Amazon Aurora Multi-AZ Deployment är säker på att bör en enda Availability Zone gå offline där den fysiska server instance maskinen finns, initieras en automatisk failover på en uppdaterad standbyreplikering i en annan ansluten Availability Zone .
Som diskuteras i den officiella dokumentationen, för att maximera systemets drifttid, kommer failover-proceduren (som vanligtvis bara tar 1-2 minuter) att utföras automatiskt i fallet med någon av följande händelser:
- Förlust av tillgänglighet i primär
Availability Zone - Förlust av nätverksanslutning till primär
- Datorenhetsfel på primär
- Lagringsfel på primär