Dela via

Riktlinjer för driftsbaslinje för Azure Red Hat OpenShift

  • Artikel

Azure Red Hat OpenShift ger mycket skalbara, fullständigt hanterade OpenShift-kluster på begäran. Genom att utforma din lösning korrekt med hantering och övervakning i åtanke kan du arbeta mot driftseffektivitet och kundframgång.

Designöverväganden

Tänk på följande faktorer:

  • Granska ansvarsmatrisen för Azure Red Hat OpenShift för att förstå hur ansvarsområden för kluster delas mellan Microsoft, Red Hat och kunder.
  • Tänk på begränsningar för virtuella Azure-datorer och regioner som stöds. Se till att det finns tillgänglig kapacitet för att distribuera resurser.
  • Tänk på olika sätt att isolera arbetsbelastningar logiskt i ett kluster och fysiskt i separata kluster.
  • Tänk på olika sätt att hjälpa Kubernetes att förstå hälsotillståndet för dina arbetsbelastningar.
  • Var medveten om olika storlekar på virtuella datorer och effekten av att använda den ena eller den andra.
  • Tänk på olika sätt att övervaka och logga 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. Både klustret och programmen som körs ovanpå kan generera många händelser. Använd aviseringar för att skilja mellan loggposter för historiska ändamål och poster som kräver omedelbara åtgärder.
  • Tänk på viktiga systemuppdateringar och uppgraderingar. Viktiga korrigeringsuppdateringar tillämpas automatiskt på kluster av Azure Red Hat OpenShift site reliability engineers (SRE). Kunder som vill installera korrigeringsuppdateringar i förväg kan göra det.
  • Tänk på resursbegränsningar för klustret och enskilda arbetsbelastningar.
  • Tänk på skillnaderna mellan horisontell autoskalning av poddar och autoskalning av kluster.
  • Granska supportlivscykeln och förstå policyn för versionsstöd. Azure Red Hat OpenShift stöder endast aktuella och tidigare allmänt tillgängliga mindre versioner av Red Hat OpenShift Container Platform. Supportbegäranden kräver att klustret har en version som stöds.
  • Granska kraven för klusterkonfiguration för att upprätthålla klusterstöd.
  • Granska nätverk mellan namnområden för att skydda trafiken i klustret med hjälp av en nätverksprincip.

Designrekommendationer

  • Azure Red Hat OpenShift har ett omfattande operatörsekosystem och bör användas för att utföra och automatisera operativa aktiviteter med effektivitet och noggrannhet.
  • Lägg till hälsoavsökningar i dina poddar för att övervaka programmets hälsa. Se till att poddar innehåller livenessProbe och readinessProbe. Använd startavsökningar för att fastställa den punkt där programmet har startats.
  • Använd storlekar för virtuella datorer som är tillräckligt stora för att innehålla flera containerinstanser så att du får fördelarna med ökad densitet, men inte så stora att klustret inte kan hantera arbetsbelastningen för en nod som misslyckas.
  • Reglera klusterfunktioner med hjälp av plugin-program för antagning, som ofta används för att framtvinga säkerhetsprinciper, resursbegränsningar eller konfigurationskrav.
  • Använd poddbegäranden och gränser för att hantera beräkningsresurserna i ett kluster. Poddbegäranden och gränser informerar Kubernetes-schemaläggaren, som tilldelar beräkningsresurser till en podd. Begränsa resursförbrukningen i ett projekt med hjälp av gränsintervall.
  • Optimera värdena för cpu- och minnesbegäran och maximera effektiviteten för klusterresurserna med hjälp av vertikal autoskalning av poddar.
  • OpenShift-webbkonsolen innehåller alla mått på nodnivå. Upprätta en övervakningsprocess med hjälp av den inbyggda Prometheus- eller Container Insights-integreringen.
    • Prometheus är förinstallerat och konfigurerat för Azure Red Hat OpenShift 4.x-kluster.
    • Container Insights kan aktiveras genom att registrera klustret till Azure Arc-aktiverade Kubernetes.
    • OpenShift-loggning distribuerar loggaggregatorer, lagring och visualiseringskomponenter.
  • Automatisera processen för programleverans via DevOps-metoder och CI/CD-lösningar, till exempel Pipelines/GitOps som tillhandahålls av OpenShift Container Platform.
  • 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 hälsokontroller för datorer för att automatiskt reparera skadade datorer i en datorpool.
  • Skala poddar för att möta efterfrågan med horisontell autoskalning av poddar.
  • Använd ett aviseringssystem för att ge meddelanden när saker behöver direkt åtgärd: Måttaviseringar för Container Insights eller inbyggt användargränssnitt för aviseringar.

Affärskontinuitet och haveriberedskap (BCDR)

Din organisation måste utforma lämpliga azure Red Hat OpenShift-funktioner på plattformsnivå för att uppfylla sina specifika krav. Dessa programtjänster har krav relaterade till mål för återställningstid (RTO) och mål för återställningspunkt (RPO). Det finns flera saker att tänka på när det gäller haveriberedskap. Det första steget är att definiera ett serviceavtal (SLA) för din infrastruktur och ditt program. Läs mer om serviceavtalet för Azure Red Hat OpenShift. Information om månatliga drifttidsberäkningar finns i avsnittet SLA-information .

Designöverväganden för BCDR

Tänk på följande faktorer:

  • Azure Red Hat OpenShift-klustret bör använda flera datoruppsättningar för att tillhandahålla den lägsta tillgänglighetsnivån för ditt program.
  • Ange poddbegäranden och gränser. Om du ställer in dessa gränser kan Kubernetes:
    • Tilldela effektivt processor- och minnesresurser till poddarna.
    • Ha högre containerdensitet på en nod.
    • Öka tillförlitligheten med lägre kostnader på grund av bättre användning av maskinvara.
  • Sprid noder över alla tillgängliga zoner för högre tillgänglighet.
    • Välj en region som stöder Tillgänglighetszoner.
    • För fullständig zonindelad förmån måste alla tjänstberoenden också ha stöd för zoner. Om en beroende tjänst inte stöder zoner är det möjligt att ett zonfel kan orsaka att tjänsten misslyckas. Granska de disktyper som används när arbetsbelastningen sprids mellan zoner.
    • Om du vill ha högre tillgänglighet än vad Tillgänglighetszoner kan uppnå kan du köra flera kluster i olika länkade regioner. Om en Azure-resurs stöder geo-redundans anger du den plats där den redundanta tjänsten ska ha sin sekundära region.
  • Skapa säkerhetskopior för program och data konsekvent.
    • En icke-tillståndskänslig tjänst kan replikeras effektivt.
    • Om du behöver lagra tillstånd i klustret säkerhetskopierar du data ofta i den länkade regionen.
  • Uppgradera och underhålla dina kluster.
  • För nätverksanslutning om en redundansväxling inträffar:
    • Om du behöver distribuera trafik mellan regioner bör du överväga att använda Azure Front Door.
  • För planerade och oplanerade redundansväxlingar:
    • När du konfigurerar varje Azure-tjänst väljer du funktioner som stöder haveriberedskap. Om du till exempel väljer Azure Container Registry aktiverar du den för geo-replikering. Om en region kraschar kan du fortfarande hämta avbildningar från den replikerade regionen.
  • Underhåll tekniska DevOps-funktioner för att nå servicenivåmål.

Designrekommendationer för BCDR

Följande är metodtips för din design:

  • Azure Red Hat OpenShift-kluster etableras med tre kontrollplansnoder och tre eller fler arbetsnoder. Se till att klustret skapas i en region som stöder Tillgänglighetszoner så att noderna är spridda över zonerna.
  • För hög tillgänglighet distribuerar du dessa noder till olika Tillgänglighetszoner. Eftersom du behöver olika datoruppsättningar för varje tillgänglighetszon skapar du minst tre datoruppsättningar.
  • Kör inte extra arbetsbelastningar på kontrollplansnoderna. Även om de kan schemaläggas på kontrollplansnoderna orsakar det extra resursanvändning och stabilitetsproblem som kan påverka hela klustret.
  • Skapa infrastrukturdatoruppsättningar som ska innehålla infrastrukturkomponenter. Tillämpa specifika Kubernetes-etiketter på dessa datorer och uppdatera sedan infrastrukturkomponenterna så att de endast körs på dessa datorer.
  • Ta bort tjänsttillståndet från containrar när det är möjligt. Använd i stället en Azure-plattform som en tjänst (PaaS) som stöder replikering i flera regioner.
  • Distributioner bör ange krav för poddresurser. Schemaläggaren kan sedan schemalägga podden på rätt sätt. Tillförlitligheten minskar avsevärt när poddar inte schemaläggs.
  • Konfigurera flera repliker i distributionen för att hantera avbrott som maskinvarufel. För planerade händelser som uppdateringar och uppgraderingar kan en avbrottsbudget säkerställa att det antal poddrepliker som krävs finns för att hantera förväntad programbelastning.
  • Använd begränsningar för poddtopologi för att automatiskt schemalägga poddar på noder i hela klustret.
  • Dina program kan använda lagring för sina data och bör säkerställa tillgänglighet mellan regioner om det behövs:
  • Skapa programsäkerhetskopiering och planera för återställning:
  • Beräkna gränser för poddresurser. Testa och upprätta en baslinje. Börja med lika värden för begäranden och gränser. Justera sedan dessa värden gradvis tills du har fastställt ett tröskelvärde som kan orsaka instabilitet i klustret. Poddgränser kan anges i dina distributionsmanifest. Vertikal autoskalning av poddar optimerar värdena för CPU- och minnesbegäran och kan maximera effektiviteten för klusterresurser.
    • De inbyggda funktionerna kan hantera fel och störningar i tjänstarkitekturen. De här konfigurationerna förenklar både design och distributionsautomatisering. När en organisation definierar en standard för SLA, RTO och RPO kan den använda tjänster som är inbyggda i Kubernetes och Azure för att uppnå affärsmål.
  • Överväg blå/gröna eller kanariebaserade strategier för att distribuera nya versioner av programmet.
  • Ange budgetar för poddprioritet/poddavbrott för att begränsa antalet poddrepliker som klustret tillåts ta bort för underhållsåtgärder, vilket säkerställer tillgängligheten.
  • Framtvinga resurskvoter för tjänstnamnområden. Resurskvoten för ett namnområde säkerställer att poddbegäranden och gränser är korrekt inställda för en distribution.
    • Om du anger resurskvoter på klusternivå kan det orsaka problem när du distribuerar partnertjänster som inte har rätt begäranden och gränser.
  • Lagra dina containeravbildningar i Azure Container Registry och geo-replikera registret till varje region.
  • Använd flera regioner och peeringplatser för Azure ExpressRoute-anslutning . Om ett avbrott som påverkar en Azure-region eller peeringproviderplats inträffar kan en redundant hybridnätverksarkitektur hjälpa till att säkerställa oavbruten anslutning mellan flera platser.
  • Koppla samman regioner med global peering för virtuella nätverk. Om klustren behöver prata med varandra kan du ansluta båda virtuella nätverken till varandra genom peering för virtuella nätverk. Den här tekniken förbinder virtuella nätverk med varandra för att tillhandahålla hög bandbredd i Microsofts stamnätverk, även i olika geografiska regioner.
  • Använd det delade TCP-baserade anycast-protokollet , Azure Front Door, för att snabbt ansluta slutanvändarna till närmaste Front Door POP (närvaropunkt). Fler funktioner i Azure Front Door är:
    • TLS-avslutning
    • Anpassad domän
    • Brandvägg för webbaserade program
    • URL-omskrivning
    • Sessionstillhörighet

Nästa steg

Lär dig mer om designöverväganden och rekommendationer för plattformsautomatisering och DevOps i dina Azure-landningszoner.