Redigera

Dela via

Distribuera webbappar med zonredundant Azure Red Hat OpenShift

Azure Red Hat OpenShift
Azure Cosmos DB
Azure Front Door

Den här artikeln innehåller en omfattande översikt över en webbappsarbetsbelastning på Azure Red Hat OpenShift i en zonredundant konfiguration. Zonredundanta tjänster replikerar dina tjänster och data mellan tillgänglighetszoner för att skydda dem mot enskilda felpunkter och ge hög tillgänglighet.

Innan du skapar en produktionsmiljö med Azure Red Hat OpenShift läser du Azure Red Hat OpenShift-acceleratorn för landningszoner.

Arkitektur

Diagram som visar arkitekturen för ett webbprogram med hög tillgänglighet.

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsflöde

  • En användare skickar en begäran till Azure.
  • Azure Front Door tar emot begäran och dirigerar begäran till ett webbprogram som finns i Azure Red Hat OpenShift.
  • Webbprogrammet kör begäran med hjälp av Azure Key Vault, Azure Cosmos DB och Azure Container Registry.
  • Webbprogrammet skickar ett svar tillbaka till användaren.

Komponenter

  • Microsoft Entra ID eller Azure AD B2C autentiserar användare. I den här arkitekturen ger Microsoft Entra ID säker, detaljerad åtkomst till externa resurser.
  • Azure Front Door är det offentliga gränssnittet för alla Internetbegäranden. Den fungerar som en global OMVÄND HTTP-proxy och cache för serverdelstjänster. Azure Front Door förbättrar säkerheten och prestandan för den här arkitekturen, som att lägga till skydd mot DDoS-attacker (Layer 4 Distributed Denial-of-Service).
  • Azure Red Hat OpenShift är den Kubernetes-baserade containerorkestratorn som är värd för API-program och -tjänster och tillhandahåller ett gränssnitt för serverdelstjänster. Azure Red Hat OpenShift fungerar som den primära beräkningsplattformen i den här arkitekturen.
  • Container Registry stöder Docker- och Open Container Initiative-kompatibla containeravbildningar (OCI). Container Registry stöder zonredundans, vilket gör det mycket tillgängligt och motståndskraftigt mot zonfel. Det stöder också geo-replikering, som replikerar tjänsten över flera regioner. I den här arkitekturen ger Container Registry ARO-klustret privat åtkomst till lokalt hanterade containeravbildningar som ingår i arbetsbelastningen.
  • Azure Red Hat OpenShift använder integrering av virtuella nätverk för att ansluta till serverdelstjänster via ett privat virtuellt nätverk. Integrering av virtuella nätverk ger ett säkert nätverk med Azure Red Hat OpenShift och andra Azure-tjänster i den här arkitekturen.
  • Azure Cosmos DB tillhandahåller NoSQL-dokumentdatabaser för klientdelstjänster. Azure Cosmos DB används av arbetsbelastningen i den här arkitekturen för att lagra användardata.
  • Privata slutpunkter aktiverar anslutningar till PaaS Azure-tjänster från privata virtuella nätverk och gör att du kan inaktivera de offentliga slutpunkterna för dessa tjänster. I den här arkitekturen håller privata slutpunkter med integrering av virtuella nätverk nätverkstrafik från Azure Red Hat OpenShift privata samtidigt som de kommunicerar med PaaS-tjänster.
  • Azure Privat DNS konfigurerar och uppdaterar DE DNS-poster som krävs för de privata slutpunktstjänsterna. I den här arkitekturen används Azure Privat DNS för namnmatchning i privata nätverk.
  • Key Vault lagrar på ett säkert sätt hemligheter och certifikat som används av Azure-tjänster. I den här arkitekturen lagrar Azure Key Vault på ett säkert sätt hemligheter för de program som körs på Azure Red Hat OpenShift.
  • Azure Monitor och Application Insights samlar in tjänstloggar och prestandamått för program för observerbarhet. I den här arkitekturen är Azure Monitor loggsynkronisering för både plattforms- och arbetsbelastningsloggar. Application Insights är specifikt för loggar och mått som kommer från arbetsbelastningskoden.

Alternativ

  • Azure-hanterad DNS rekommenderas, men du kan använda din egen DNS-provider.
  • Du bör använda Azure Application Gateway i stället för Azure Front Door om de flesta av dina användare finns nära Den Azure-region som är värd för din arbetsbelastning och om du inte behöver cachelagring av innehåll. Använd Azure DDoS Protection för att skydda Internetuppkopplade Application Gateway-tjänster.
  • Distribuera en Premium Azure API Management-instans med zonredundans som ett alternativ för att vara värd för klientdels-API:er, serverdels-API:er eller båda. Mer information om zonredundans för API Management finns i Migrera Azure API Management till stöd för tillgänglighetszoner.
  • Du kan använda OpenShift Container Platform (OCP) eller Origin Community Distribution of Kubernetes (OKD) på Azure Virtual Machines i stället för Azure Red Hat OpenShift. OCP eller OKD är IaaS-alternativ (infrastruktur som en tjänst) till en fullständigt plattformshanterad tjänst, till exempel Azure Red Hat OpenShift. Du bör använda Azure Virtual Machine Scale Sets för zonredundans. Mer information finns i Azure Red Hat OpenShift.

Information om scenario

Den här arkitekturen beskriver hur du skapar zonredundanta tjänster i en lösning som ger hög tillgänglighet och är motståndskraftig mot zonfel.

Tillgänglighetszoner är separata fysiska platser i varje Azure-region. Tillgänglighetszoner sprider en lösning över flera oberoende zoner i en region, vilket gör att ett program kan fortsätta att fungera när en zon misslyckas. Den här arkitekturen bygger på den infrastruktur för tillgänglighetszoner som finns i många regioner. En lista över regioner som stöder Azure-tillgänglighetszoner finns i Azure-regioner med tillgänglighetszoner.

När värdplattformarna är i stor skala är det ofta svårt att hålla dem mycket tillgängliga. Hög tillgänglighet har historiskt krävt komplexa och dyra distributioner i flera regioner med datakonsekvens och kompromisser med höga prestanda. Tillgänglighetszoner löser många av dessa problem. De flesta vanliga Azure-tjänster och många specialiserade Azure-tjänster ger stöd för tillgänglighetszoner. Alla Azure-tjänster i den här arkitekturen är zonredundanta, vilket förenklar distributionen och hanteringen. Mer information finns i Azure-tjänster som stöder tillgänglighetszoner.

För att underhålla serviceavtal (SLA) hanterar och åtgärdar zonredundanta Azure Red Hat OpenShift fel, inklusive zonfel. Zonredundans ger en återställningstid på noll för zonfel. Om en enskild zon i en region inte är tillgänglig förlorar du inga data och din arbetsbelastning fortsätter att köras. Zonredundans konfigureras vid distributionstillfället och hanteras av tjänster, så du behöver inte hantera zonindelning eller zonindelade distributioner.

I den här arkitekturen distribueras ett Azure Red Hat OpenShift-kluster över tre tillgänglighetszoner i Azure-regioner som stöder dem. Ett kluster består av tre kontrollplansnoder och tre eller flera arbetsnoder. För att förbättra redundansen sprids noderna över zonerna.

Azure Front Door, Microsoft Entra ID och Azure DNS är globalt tillgängliga tjänster som är motståndskraftiga mot zon- och regionomfattande avbrott. Alla andra tjänster i den här arkitekturen är zonredundanta.

Potentiella användningsfall

Azure Red Hat OpenShift är en containerorkestreringstjänst som använder Kubernetes. Den är lämplig för många användningsfall, till exempel:

  • Bankverksamhet
  • Aktiehandel
  • Näthandel
  • Sociala medier
  • Webbprogram
  • Mobilprogram
  • Batchbearbetningsprogram
  • Medieuppspelning
  • Arbetsbelastningar för maskininlärning

Rekommendationer

Följande rekommendationer gäller för de flesta scenarier.

Azure Front Door

  • Använd Azure-hanterade certifikat i alla klientdelsprogram för att förhindra felkonfiguration av certifikat och förfalloproblem.
  • Aktivera cachelagring på vägar för att förbättra tillgängligheten. Azure Front Door-cachen distribuerar ditt dynamiska innehåll samt statiskt innehåll till POP-gränsnoderna (Point of Presence) i Azure. Cachelagring minskar belastningen på ursprungsservrar och förbättrar prestandan.
  • Distribuera Azure Front Door Premium och konfigurera en brandväggsprincip för webbprogram (WAF) med en Microsoft-hanterad regeluppsättning. Tillämpa principen på alla anpassade domäner. Använd förebyggande läge för att minska webbattacker som kan orsaka ett fel i ursprungstjänsten.

Azure Red Hat OpenShift

  • Se till att Azure-regionen där Azure Red Hat OpenShift distribueras har stöd för tillgänglighetszoner. Mer information finns i Azure-regioner med stöd för tillgänglighetszoner.
  • Ett Azure Red Hat OpenShift-kluster är beroende av vissa tjänster. Se till att tjänsterna stöder och är konfigurerade för zonredundans. Mer information finns i Azure-tjänster med stöd för tillgänglighetszoner.
  • Ta bort tillståndet från containrar och använd Azure Storage- eller databastjänster i stället.
  • Konfigurera flera repliker i distributioner med lämplig budgetkonfiguration för avbrott för att kontinuerligt tillhandahålla programtjänst trots störningar, till exempel maskinvarufel i zoner.
  • Säker åtkomst till Azure Red Hat OpenShift. För att säkerställa att begäranden inte kan kringgå Azure Front Door WAF tillåter du endast Azure Front Door-trafik. Mer information om hur du begränsar åtkomsten till en specifik Azure Front Door-instans finns i Säker åtkomst till Azure Red Hat OpenShift med Azure Front Door.

Container Registry

Mer information finns i Aktivera zonredundans i Container Registry för återhämtning och hög tillgänglighet och Använd Container Registry med Azure Red Hat OpenShift.

Azure Cosmos DB

Key Vault

Key Vault är zonredundant i alla regioner där tillgänglighetszoner är tillgängliga. I den här arkitekturen distribueras Key Vault med en privat slutpunkt aktiverad och en offentlig slutpunkt inaktiverad. Mer information om privata slutpunkter för Key Vault finns i Integrera Key Vault med Private Link.

Privata Azure DNS-zoner

För att förenkla DNS-hanteringen integrerar du privata slutpunkter med privata Azure DNS-zoner. Mer information finns i DNS-konfiguration för privata Slutpunkter i Azure.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Azure Well-Architected Framework.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i checklistan för Designgranskning för tillförlitlighet.

Den här arkitekturen säkerställer tillförlitligheten genom att tillhandahålla tillgänglighet, motståndskraft och pålitliga globala tjänstfunktioner.

Tillgänglighet

När tillgänglighetszonens infrastruktur implementeras korrekt ger den här arkitekturen utmärkt tillgänglighet för lägre kostnad och lägre driftkostnader än andra lösningar. Den här arkitekturen minskar risken för ett zonfel i en Azure-region eftersom zonredundanta tjänster står emot felet medan de fortfarande körs inom det definierade serviceavtalet.

Regionala fel är osannolika men möjliga. I ett regionalt fel är tjänsterna inte tillgängliga i alla tillgänglighetszoner i en region. Kombinera den här zonredundanta arkitekturen med en arkitektur med flera regioner för att minska risken för regionfel. Planera arkitekturen för flera regioner för att minska återställningstiden om en hel region inte är tillgänglig.

Design för flera regioner är mer komplex och ofta dyrare än design i flera zoner i en enda region, men design för flera regioner ger en möjlighet att ytterligare optimera tillgängligheten och den övergripande tillförlitligheten.

Kommentar

Utför en riskbedömning för att avgöra om lösningen kräver en arkitektur för flera regioner.

Elasticitet

Design i flera zoner som baseras på tillgänglighetszoner erbjuder tillgänglighet och motståndskraft som uppfyller eller överskrider de flesta organisationers affärskrav. Men om du vill replikera data till en sekundär region för haveriberedskap beror alternativen på vilka Azure-tjänster du använder.

Azure Storage har till exempel stöd för objektreplikering för blockblobar. Azure-datatjänster, som Azure Cosmos DB, erbjuder datareplikering till andra Azure-regioner som har kontinuerlig säkerhetskopiering. Du kan använda de här funktionerna för att återställa lösningen om en katastrof inträffar. Mer information finns i Kontinuerlig säkerhetskopiering med återställning till tidpunkt i Azure Cosmos DB.

Globala tjänster

Fel i globala tjänster, till exempel Azure Front Door och Microsoft Entra-ID, är sällsynta, men effekten av ett fel kan vara hög. Förbered och repetera runbooks för att förbättra återställningen om ett fel inträffar.

Du kan till exempel minska stilleståndstiden för Azure Front Door med hjälp av en runbook för att distribuera Azure Application Gateway och ändra DNS-poster för att omdirigera trafik tills Azure Front Door har återställts.

Mer information finns i Skapa motståndskraft i infrastrukturen för identitets- och åtkomsthantering.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i checklistan för Designgranskning för Security.

  • Överväg att distribuera ett privat kluster.
  • Använd privata slutpunkter på Azure-tjänster som inte nås från det offentliga Internet.
  • Som standard krypteras all tjänst-till-tjänst-kommunikation i Azure TLS (Transport Layer Security). Konfigurera Azure Front Door att endast acceptera HTTPS-trafik och ange den lägsta TLS-versionen.
  • Hanterade identiteter autentiserar azure service-to-service-kommunikation där den är tillgänglig. Mer information finns i Vad är hanterade identiteter för Azure-resurser?
  • Om du vill hantera och skydda hemligheter, certifikat och anslutningssträng i klustret ansluter du Azure Red Hat OpenShift-klustret till Azure Arc-aktiverade Kubernetes. Använd tillägget Key Vault Secrets Provider för att hämta hemligheter.
  • Konfigurera Microsoft Defender för containrar för att ge säkerhet för kluster, containrar och program. Defender for Containers stöds via Azure Arc-aktiverade Kubernetes. Sök igenom dina bilder efter säkerhetsrisker med Microsoft Defender eller någon annan lösning för bildgenomsökning.
  • Konfigurera Microsoft Entra-integrering för att använda Microsoft Entra-ID för att autentisera användare (till exempel SRE, SecOps eller programutvecklare) i ditt Azure Red Hat OpenShift-kluster.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i checklistan Designgranskning för kostnadsoptimering.

Zonredundanta arkitekturer är billigare än alternativ för flera regioner eftersom tjänster distribueras i en enda region. Men det finns flera kostnadskonsekvenser att vara medveten om:

  • Vissa tjänster kräver att ett minsta antal instanser eller repliker distribueras för att uppnå zonredundans.
  • Zonredundant lagring (ZRS) och lokalt redundant lagring (LRS) har olika priser. Mer information finns i Priser för lagring.
  • Privata slutpunkter är mestadels tillgängliga på Premium Azure-tjänst-SKU:er. Privata slutpunkter medför timavgifter och bandbreddsavgifter. Mer information finns i Priser för Private Link.

Optimera kostnaderna genom att reservera resurser i förväg. Många tjänster i den här arkitekturen är berättigade till priser för reserverad kapacitet. Mer information finns i Reservationer.

Normalt beräknar du kostnader med hjälp av priskalkylatorn för Azure.

Operational Excellence

Operational Excellence omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i checklistan för Designgranskning för Operational Excellence.

Alla Azure-tjänster som är plattform som en tjänst (PaaS) är integrerade med Azure Monitor. Följ metodtipsen för Azure Monitor (tillförlitlighet, säkerhet, kostnadsoptimering, driftseffektivitet och prestandaeffektivitet) för att:

  • Skapa en hälsomodell för att kvantifiera programmets hälsa i samband med affärskrav.
  • Konfigurera rätt mängd loggdatainsamling.
  • Skapa Azure-instrumentpaneler för att förena data i en enda vy för driftsteam.
  • Skapa en lyckad aviseringsstrategi.
  • Integrera Application Insights i appar för att spåra programprestandamått.
  • Om du vill tillhandahålla meddelanden när direkt åtgärd behövs använder du ett aviseringssystem, till exempel måttaviseringar för Container Insights eller Azure Red Hat OpenShift-aviseringsgränssnittet.
  • Överväg olika metoder för övervakning och loggning av Azure Red Hat OpenShift för att få insikter om hälsotillståndet för dina resurser och för att förutse potentiella problem.
  • Gå igenom ansvarsmatrisen för Azure Red Hat OpenShift för att förstå hur Microsoft, Red Hat och kunder delar ansvar för kluster.
  • Automatisera tjänstdistributioner med Bicep, ett mallspråk för att distribuera infrastruktur som kod (IaC). Eftersom Azure-tjänster i den här arkitekturen har privata slutpunkter kan du inte använda Microsoft-värdbaserade agenter för Azure Pipelines eller GitHub-värdbaserade löpare. Använd lösningar som lokalt installerade agenter för Azure Pipelines eller GitHub-värdbaserade löpare i stället.
  • Validera kontinuerligt arbetsbelastningen för att testa prestanda och motståndskraft för hela lösningen med hjälp av tjänster, till exempel Azure Load Testing och Azure Chaos Studio.

Prestandaeffektivitet

Prestandaeffektivitet är arbetsbelastningens förmåga att skala för att uppfylla användarnas krav på ett effektivt sätt. Mer information finns i checklistan för Designgranskning för prestandaeffektivitet.

  • Cachelagrar tillgångar i Azure Front Door för att distribuera arbetsbelastningar till gränsplatser.
  • Granska prenumerationsgränser och kvoter för att säkerställa att tjänsterna skalas efter efterfrågan.
  • Övervaka programmets prestanda med hjälp av Application Insights.
  • Prestandatesta arbetsbelastningar för att mäta eventuella svarstider som orsakas av anslutningar mellan zoner.
  • Välj lämpliga storlekar för virtuella datorer för dina arbetsbelastningar. Välj en storlek som är tillräckligt stor för att få fördelarna med ökad densitet men inte så stor att klustret inte kan hantera arbetsbelastningen för en nod som misslyckas.
  • Använd poddbegäranden och begränsningar för att hantera beräkningsresurserna i ett kluster. Poddbegäranden och begränsningar informerar Kubernetes-schemaläggaren, som tilldelar beräkningsresurser till en podd. Begränsa resursförbrukningen i ett projekt med hjälp av gränsintervall.
  • Definiera poddresursbegäranden och begränsningar i programdistributionsmanifesten och framtvinga dem med Azure Policy.
  • Optimera värdena för cpu- och minnesbegäran och maximera effektiviteten för klusterresurserna med hjälp av autoskalning av lodrät podd.
  • Skala poddar för att möta efterfrågan med hjälp av horisontell podd autoskalning.
  • Definiera ClusterAutoScaler och MachineAutoScaler för att skala datorer när klustret får slut på resurser för att stödja fler distributioner.

Distribuera det här scenariot

Information om hur du distribuerar den här arkitekturen finns i Acceleratorn för Azure Red Hat OpenShift-landningszonen och den associerade GitHub-lagringsplatsen.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

Övriga medarbetare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg