Dela via


Överväganden för affärskontinuitet och haveriberedskap för Red Hat Enterprise Linux i Azure

Den här artikeln beskriver hur du förbättrar bcdr-beredskapen för affärskontinuitet och haveriberedskap för en Red Hat Enterprise Linux-baserad miljö (RHEL) i Azure. Den innehåller rekommendationer som du kan använda för att stödja RHEL-arbetsbelastningar och för att distribuera RHEL-plattformshanteringskomponenter. Red Hat Management-prenumerationen innehåller plattformskomponenter som hjälper dig att hantera arbetsbelastningar i en eller flera RHEL-landningszoner. Dessa komponenter erbjuder sina egna BCDR-konfigurationer.

Utformningsbeaktanden

Implementera följande överväganden för att förbättra återhämtning för dina RHEL-arbetsbelastningar.

Mål för återställningstid

Ett mål för återställningstid (RTO) är hur lång tid det ska ta för systemet att återställa till sitt ursprungliga tillstånd efter en katastrof. RTO innehåller den tid det tar att:

  • Återställ minimal funktionalitet till virtuella datorer och program.
  • Återställa data som program kräver.

I affärstermer representerar RTO den tid som affärsprocesserna inte är i drift. En låg RTO är perfekt för verksamhetskritiska arbetsbelastningar så att affärsprocesser kan återupptas snabbt. För arbetsbelastningar med lägre prioritet kanske en högre RTO inte har någon märkbar effekt på företagets prestanda.

Mål för återställningspunkt

För att kunna använda en molnmiljö måste du implementera säkerhetskopior, replikering eller båda för att skydda data från fel. Målet för återställningspunkten (RPO) refererar till den senaste gången som data hämtades. När ett system misslyckas kan du bara återställa det till den senaste återställningspunkten.

Du mäter RPO från den senaste återställningspunkten till den tidpunkt då ett avbrott inträffar. Om du mäter grupprincipobjektet i timmar resulterar ett systemfel i dataförlusten för timmarna mellan den senaste återställningspunkten och driftstoppet. Om du mäter RPO i dagar resulterar ett systemfel i dataförlusten för dagarna mellan den senaste återställningspunkten och avbrott. Ett endags-RPO resulterar teoretiskt sett i förlust av alla transaktioner under dagen som leder till felet.

För verksamhetskritiska system mäter du RPO i minuter eller sekunder för att undvika förlust i intäkter eller vinster. Ett kort RPO resulterar i allmänhet i ökade hanteringskostnader. För att minska dessa kostnader bör du skapa en hanteringsbaslinje som fokuserar på det längsta godtagbara RPO:et. Du kan sedan minska RPO för de specifika plattformar eller arbetsbelastningar som kräver mer investeringar.

BCDR-överväganden för arbetsbelastning

Designöverväganden för hög tillgänglighet och haveriberedskap för RHEL-baserade arbetsbelastningar beror på vilka tekniker som stöder dessa arbetsbelastningar. Många moderna arbetsbelastningar kan dra nytta av interna Azure-tjänster för att tillhandahålla redundans mellan tillgänglighetszoner och mellan regioner. Använd Azure-tjänster för att hantera datareplikering, automatiskt skala tillgänglighetsuppsättningar och kontrollera uppdaterings- och feldomäner. Dessa metoder gör det enklare att säkerställa tillgängligheten för RHEL-distributioner.

Databaslösningar och andra tillståndskänsliga program kan behöva operativsystemcentrerade lösningar för att ge hög tillgänglighet och haveriberedskap. Kontakta programutvecklaren eller leverantören för att verifiera de lösningar som programmen stöder. Mer information finns i Hög tillgänglighet och haveriberedskap för IaaS-appar.

Azure-funktion eller -tjänst Definition Att tänka på
Regioner En grupp datacenter som ligger nära varandra för att ge låga nätverksfördröjningar. För att säkerställa en snabb dataöverföring ansluter ett specifikt regionalt nätverk datacentren. När du väljer en Azure-region bör du överväga platsen för dina datacenter, användare och serverdelsdata. Kontrollera tillgängligheten för de tjänster som du behöver i de regioner som du väljer. För RHEL-distributioner kan du ha en region att starta, och sedan kan du lägga till fler regioner i framtiden för BCDR-ändamål.
Azure ExpressRoute En Azure-tjänst som du kan använda för att upprätta privata anslutningar från Microsofts datacenter till din egen infrastruktur eller till en samlokaliseringsanläggning. ExpressRoute kringgår det offentliga Internet och tillhandahåller en dedikerad privat anslutning. Den här konfigurationen är ett vanligt krav för storskaliga RHEL-distributioner. ExpressRoute är en delad tjänst, så du måste planera bandbreddskapaciteten noggrant för att uppfylla företagets totala bandbreddsbehov.

Om du inte har tillräckligt med bandbredd kan du äventyra användarupplevelsen eller åtkomsten till kritiska tjänster i datacentret. Se till att du distribuerar ExpressRoute på ett motståndskraftigt sätt mellan regioner och peeringplatser.
Tillgänglighetszoner Separata grupper av datacenter som har egna kraft-, kylnings- och nätverkssystem i en Azure-region. Tillgänglighetszoner ger hög tillgänglighet och återhämtning för datacenterfel. Om du vill säkerställa ett serviceavtal (SLA) använder du tillgänglighetszoner med RHEL-infrastruktur när det är möjligt. Tillgänglighetszoner erbjuder datacenterredundans inom en region. Men alla regioner har inte tillgänglighetszoner, så du måste planera noggrant. RHEL-tjänster, till exempel Azure Red Hat OpenShift och hanteringstjänster för landningszoner, stöder tillgänglighetszoner.
Tillgänglighetsuppsättningar En logisk gruppering av virtuella datorer. Minst en virtuell dator är alltid igång under planerade eller oplanerade underhållshändelser. En feldomän är en delmängd av en tillgänglighetsuppsättning som delar en gemensam fysisk infrastruktur, till exempel ström eller nätverk. När du distribuerar virtuella datorer mellan olika feldomäner minskar en tillgänglighetsuppsättning effekten av maskinvarufel på den virtuella datorns tillgänglighet. Tillgänglighetsuppsättningar ger ett högt serviceavtal. Tillgänglighetsuppsättningar är lämpliga för en RHEL-infrastruktur när en region saknar tillgänglighetszoner. Tillgänglighetsuppsättningar har endast maskinvaruredundans, vilket liknar regler för hypervisor-antitillhörighet. Så om dina regioner inte har tillgänglighetszoner behöver du en strategi för flera regioner för datacenter och geografisk redundans.
Azure Load Balancer En tjänst för belastningsutjämning i nätverket. Du kan konfigurera Load Balancer för att effektivt tillhandahålla nätverkstrafik med hög volym över flera Red Hat Enterprise-servrar. Tjänsten fungerar med låg svarstid och högt dataflöde, vilket förbättrar programmets prestanda och tillgänglighet.

Load Balancer kan skalas automatiskt efter behov. För att främja en hybriddistribution av dina program kan Load Balancer distribuera nätverkstrafik över flera regioner i Azure och även mellan lokala miljöer och Azure.
Load Balancer distribuerar nätverkstrafik över flera servrar för att tillhandahålla oavbruten programtillgänglighet och förhindra fel med en enda punkt. Om ett haveri inträffar omdirigerar Load Balancer trafik till driftservrar för att tillhandahålla en snabb redundansväxling och återställning. Den här åtgärden minimerar stilleståndstiden och underhåller verksamheten.

Load Balancer kan balansera trafik mellan lokala servrar till Azure-molnet eller till servrar i flera Azure-regioner. Mer information finns i Alternativ för belastningsutjämning.
Hanterade diskar Virtualiserade diskar som Azure hanterar. Du väljer diskstorlek och typ. Azure distribuerar diskar över olika lagringsenheter för att skydda dina data mot maskinvarufel. Hanterade diskar är det bästa valet för all RHEL-infrastruktur. Använd inte ohanterade diskar. Mer information finns i Serviceavtal för virtuella datorer.

Olika typer av diskar har olika prestanda och kostnader. För RHEL-infrastrukturdatorer rekommenderar vi Azure Premium SSD. Överväg kostnad, prestanda och tillgänglighet när du väljer disktyp. När du frigör ett system tas lokala SSD- och tillfälliga diskar bort. Säkerhetskopiera data på dessa diskar efter behov.
Azure Backup En tjänst som tillhandahåller kostnadseffektiva lösningar för att säkerhetskopiera dina data och återställa dem från Azure-molnet. Säkerhetskopiering är en tillförlitlig och kostnadseffektiv lösning som skyddar RHEL-infrastrukturen mot vm-fel eller skador. Använd Säkerhetskopiering för att enkelt återställa hela den virtuella datorn eller specifika filer och mappar från molnet, utan att behöva återskapa den virtuella datorn eller förlora data. Du kan också använda andra partnerlösningar som stöds.
Azure Arc En plattform som utökar Azure-tjänster så att de körs i olika miljöer, inklusive datacenter, gränsenheter och arkitekturer med flera moln. Använd Azure Arc för att tillhandahålla konsekvent utveckling, drift och säkerhetshantering för program och tjänster. Använd Azure Arc för att implementera centraliserade automatiserade säkerhetskopieringar och övervakning, vilket ökar motståndskraften ur ett BCDR-perspektiv.
Azure Site Recovery En tjänst som tillhandahåller funktioner för haveriberedskap för att säkerställa affärskontinuitet. Du kan replikera och hantera arbetsbelastningar, inklusive virtuella Azure-datorer och lokala virtuella datorer i olika regioner. Med Site Recovery kan du konfigurera replikerings-, redundans- och återställningsprocesser för att skydda dina program vid planerade avbrott och oplanerade avbrott. Använd Site Recovery för att minimera återställningsproblem, minska infrastrukturkostnaderna och säkerställa säker och tillförlitlig återställning mellan Azure-regioner eller från lokala platser till Azure.
Resurslås En Azure-funktion som du kan använda för att begränsa användare och roller i din organisation. Skydda dina kritiska resurser från oavsiktliga eller skadliga ändringar. Du kan låsa en resurs på olika omfångsnivåer, till exempel prenumeration, resursgrupp eller enskilda resursnivåer. Beroende på typen av lås kan du förhindra användare från att ta bort eller ändra en resurs, men de kan fortfarande läsa dess konfiguration. Om du vill skydda alla RHEL-infrastrukturer och virtuella datorer med gyllene avbildningar använder du resurslås. Om du vill förhindra att viktiga datorer förloras av misstag använder du borttagningslåset som ett minimum. Använd ReadOnly-låset på RHEL-infrastrukturdatorer eftersom de inte ändras ofta. Gör endast ändringar under lämpliga ändringskontrollfönster.

ÖVERVÄGANDEN FÖR RHEL-plattformens BCDR

Mer information om BCDR-funktioner för en RHEL-plattformsinfrastruktur finns i:

Designrekommendationer

För molnbaserade program i Linux-containrar använder du en Kubernetes-baserad plattform för att säkerställa skalbarhet, hög tillgänglighet och redundans. Överväg att använda Azure Red Hat OpenShift-plattformen eller en självhanterad OpenShift-distribution med replikerad eller geo-replikerad lagring.

För interna klientdelar för webbprogram och tillståndslösa program kan du använda många av de Azure-inbyggda tjänster som tillhandahåller programtillgänglighet. För arkitekturer som använder sådana tjänster, se:

De föregående arkitekturerna använder olika Azure-tjänster för tillgänglighetszoner. Arkitekturen i flera regioner använder geo-replikeringsfunktioner för innehåll och Azure Front Door som en belastningsutjämningstjänst.

För många traditionella tillståndskänsliga program som kräver hög tillgänglighet erbjuder RHEL tillägget Pacemaker med hög tillgänglighet. Du kan hämta system som har den här funktionen från Azure Marketplace, eller så kan du distribuera en anpassad avbildning med nödvändiga programvarukomponenter inbäddade. Mer information finns i Konfigurera ett Red Hat-kluster med hög tillgänglighet i Microsoft Azure.

Tillgänglighetsproblem påverkar tjänststopp och svarstider för tjänsten. Tjänstförsämring kan inträffa, vilket kan försämra kundens tjänstupplevelse. För att säkerställa att du behåller prestandanivåer och tillräcklig kapacitet i de regioner som krävs använder du funktionen för kapacitetsreservation på begäran i Azure.

Tillförlitlighet

Många av de begrepp som gäller för infrastruktur som en tjänst vm-infrastrukturer gäller även för RHEL-arkitekturer. Mer information finns i Designprinciper för tillförlitlighet.

Kluster

Azure har inte stöd för att kombinera Application Server Central Services och databas med hög tillgänglighet i ett enda RHEL Pacemaker-kluster. För att åtgärda den här begränsningen ska du dela upp dem i enskilda kluster. Du kan kombinera upp till fem centrala tjänstkluster i ett par virtuella datorer.

För BCDR på SAP bör du överväga följande tjänster för att köra SAP-kluster för centrala tjänster:

  • RHEL Pacemaker-kluster: STONITH-blockenheter stöds inte, men du kan lita på Azure Fence-agenten.
  • SAP-certifierad icke-Microsoft-klusterprogramvara: Utforska det här alternativet om det överensstämmer med dina krav.

Välj lämplig tjänst baserat på dina specifika behov och ditt operativsystem.

Mer information finns i:

Du kan använda Compute Gallery för att lagra gyllene avbildningar för distributioner. Använd dessa avbildningar för haveriberedskap för program och verktyg. Beräkningsgalleriet kan använda resurser med hög tillgänglighet med zonredundanta lagringskonton (ZRS) i regioner som stöder tillgänglighetszoner. ZRS erbjuder återhämtning mot zonfel. Du kan också replikera galleribilder till andra regioner eller geografiska områden.

Kommentar

Vi rekommenderar att du har minst två gallerier i olika regioner.

Site Recovery

Site Recovery kan förbättra motståndskraften hos vissa RHEL-komponenter. En lista över RHEL-platsåterställningsservrar som stöds finns i Supportmatris för haveriberedskap för virtuella Azure-datorer med Site Recovery. Du kan också konfigurera Site Recovery som en redundansväxling från lokala miljöer till molnet. Om du vill få en uppskattning av Site Recovery-kostnaderna använder du Distributionshanteraren för Site Recovery.

Återställningsklusternoder

Om du vill minska RTO:er och öka motståndskraften kan du använda aktiva eller väntelägesnoder för fjärråterställningskluster. Du måste konfigurera haveriberedskapsklusterobjekt manuellt. Du måste till exempel använda konfigurationer för att konfigurera resurser och kopiera data.

Nästa steg