Hög tillgänglighet i Azure virtuella maskiner

Posted in : Azure, Microsoft By Jonas Back Translate with Google ⟶

8 years ago

Windows Azure garanterar ett SLA på 99,95% men bara om du bygger dina virtuella maskiner i så kallade Availability Sets.
Det finns två saker som kan påverka tillgängligheten för dina virtuella maskiner, underhåll som är planerade eller oplanerade.

• Planerade – Microsoft genomför periodiska uppdateringar av Azure plattformen. De flesta av dessa uppdateringar sker utan att VMs påverkas men ibland kan dina VMs behöva startas om.
• Oplanerade – Om någon komponent fallerar, till exempel lokalt nätverk, ström, lokal disk eller fel i ett helt rack. Azure kommer då migrera över dina VMs till annan fysisk server. Detta händer sällan men detta kan också orsaka att din VM behöver startas om.

Xenit har noterat att de planerade underhållen kan orsaka flertalet omstarter av dina VMs och det kan ske under flertalet timmar som underhållet pågår och idag finns det inga möjligheter att styra när detta sker.
För att inte påverkas av detta bör du grupperna två eller flera VMs i ett Availibility Set. När du skapar VMs i ett Availibilty Set kommer Azure se till att placera dem i olika UD (Update Domain) och FD (Fault Domain). När de ligger i olika UD kommer de inte uppdateras samtidigt och när de ligger i olika FD så delar de inte samma ström eller nätverk, rent konkret skapas dessa VMs förmodligen i olika rack.

Rent tekniskt så måste med andra ord alla applikationer vara möjliga att installeras högtillgängligt och det finns flera sätt att göra det. Ett par exempel:

• Domänkontrollantera för Active Directory har native stöd för hög tillgänglighet om de placeras på olika VMs
• Citrix XenApp har också inbyggt stöd så de sprids över flera servrar
• IIS, webbservrar kan lastdelas genom att använda en lastbalanserar som är inbyggt i Azure
• SQL har flera olika sätt att ska högtillgänglighet mellan olika VMs

Kortfattat kan sägas att den applikation du deployar på VMs måste vara högtillgänglig och du nästan ska räkna med att dina VMs startar om utan att du kan påverka det.
Det kan tyckas något konstigt att Azure fungerar på det sättet och kan skapa en utmaning för hur du designar din miljö men det är högst medvetet från Microsofts sida. Först och främst anser Microsoft att vad du än kör i Azure så ska designen ”by default” vara högtillgänglig och det ska inte finnas några SPOF (Single-Point-of-Failure). Är det inte möjligt med din applikation så är kanske Azure inte rätt val för dig. Sedan föreslår Microsoft att bygga lösningar som baseras på deras ”cloud services” (app service, sql database, storage osv) snarare än Virtual Machines.
En teknisk anledning varför Azure väljer att inte flytta över VMs innan planerade underhåll är för de tillhandahåller extremt stora VMS, med upp till 448 GB minne. Att behöva flytta över alla dessa VMs skulle konsumera extremt stora datamängder i ”East-West bandbredd” som normalt behövas för annat.
Microsoft har inte annonserat några planer för att ändra detta upplägg men däremot känner Microsoft till synpunkter på denna funktion. Med största sannolikhet kommer uppdateringar betyda färre omstartarter och det är möjligt att vi i framtiden kan styra vilken tidpunkt planerade underhåll ska ske, något som inte går idag.
Vad du än har för applikation så kan Xenit kan hjälpa dig bygga en design för Azure.

Tags : Azure