Overwegingen voor bedrijfscontinuïteit en herstel na noodgevallen voor Red Hat Enterprise Linux in Azure
In dit artikel wordt beschreven hoe u de gereedheid voor bedrijfscontinuïteit en herstel na noodgevallen (BCDR) voor een RhEL-omgeving (Red Hat Enterprise Linux) op Azure kunt verbeteren. Het biedt aanbevelingen die u kunt gebruiken om RHEL-workloads te ondersteunen en RHEL-platformbeheeronderdelen te implementeren. Het Red Hat Management-abonnement bevat platformonderdelen waarmee u workloads in een of meer RHEL-landingszones kunt beheren. Deze onderdelen bieden hun eigen BCDR-configuraties.
Ontwerpoverwegingen
Implementeer de volgende overwegingen om de tolerantie van uw RHEL-workloads te verbeteren.
Beoogde hersteltijd
Een beoogde hersteltijd (RTO) is de hoeveelheid tijd die nodig is om uw systeem te herstellen naar de oorspronkelijke staat na een noodgeval. De RTO omvat de tijd die nodig is om:
- Minimale functionaliteit herstellen naar virtuele machines (VM's) en toepassingen.
- Herstel gegevens die toepassingen nodig hebben.
In zakelijke termen vertegenwoordigt de RTO de hoeveelheid tijd die bedrijfsprocessen buiten gebruik hebben. Een lage RTO is ideaal voor bedrijfskritieke workloads , zodat bedrijfsprocessen snel kunnen worden hervat. Voor workloads met een lagere prioriteit heeft een hogere RTO mogelijk geen merkbaar effect op de bedrijfsprestaties.
Beoogde herstelpunten
Als u een cloudomgeving wilt gebruiken, moet u back-ups, replicatie of beide implementeren om gegevens te beschermen tegen storingen. De RPO (Recovery Point Objective) verwijst naar de laatste keer dat gegevens zijn vastgelegd. Wanneer een systeem uitvalt, kunt u het alleen herstellen naar het meest recente herstelpunt.
U meet de RPO vanaf het meest recente herstelpunt tot het moment dat er een storing optreedt. Als u de RPO in uren meet, resulteert een systeemfout in het verlies van gegevens gedurende de uren tussen het laatste herstelpunt en de storing. Als u de RPO in dagen meet, resulteert een systeemfout in het verlies van gegevens voor de dagen tussen het laatste herstelpunt en de storing. Een RPO van één dag resulteert theoretisch in het verlies van alle transacties op de dag die tot de fout leiden.
Voor bedrijfskritieke systemen meet u de RPO in enkele minuten of seconden om verlies in omzet of winst te voorkomen. Een korte RPO resulteert in het algemeen in hogere beheerkosten. Om deze kosten te verlagen, moet u een beheerbasislijn maken die is gericht op de langst acceptabele RPO. Vervolgens kunt u de RPO van de specifieke platforms of workloads verlagen die meer investeringen rechtvaardigen.
Overwegingen voor BCDR voor workload
Ontwerpoverwegingen voor hoge beschikbaarheid en herstel na noodgevallen voor RHEL-workloads zijn afhankelijk van de technologieën die deze workloads ondersteunen. Veel moderne workloads kunnen profiteren van systeemeigen Azure-services om redundantie te bieden tussen beschikbaarheidszones en regio's. Gebruik Azure-services om gegevensreplicatie te beheren, beschikbaarheidssets automatisch te schalen en update- en foutdomeinen te beheren. Deze procedures maken het eenvoudiger om de beschikbaarheid van RHEL-implementaties te garanderen.
Databaseoplossingen en andere stateful toepassingen hebben mogelijk besturingssysteemgerichte oplossingen nodig om hoge beschikbaarheid en herstel na noodgevallen mogelijk te bieden. Neem contact op met de ontwikkelaar of leverancier van de toepassing om de oplossingen te controleren die door de toepassingen worden ondersteund. Zie Hoge beschikbaarheid en herstel na noodgevallen voor IaaS-apps voor meer informatie.
| Azure-functie of -service | Definitie | Overwegingen |
|---|---|---|
| Regio's | Een groep datacenters die zich dicht bij elkaar bevinden om lage netwerkvertragingen te bieden. Om een snelle gegevensoverdracht te garanderen, verbindt een specifiek regionaal netwerk de datacenters. | Wanneer u een Azure-regio kiest, moet u rekening houden met de locatie van uw datacenters, gebruikers en back-endgegevens. Controleer de beschikbaarheid van de services die u nodig hebt in de regio's die u selecteert. Voor RHEL-implementaties hebt u mogelijk één regio om te beginnen en vervolgens kunt u in de toekomst meer regio's toevoegen voor BCDR-doeleinden. |
| Azure ExpressRoute | Een Azure-service die u kunt gebruiken om privéverbindingen tot stand te brengen van Microsoft-datacenters naar uw eigen infrastructuur of naar een colocatiefaciliteit. | ExpressRoute omzeilt het openbare internet en biedt een speciale privéverbinding. Deze configuratie is een algemene vereiste voor grootschalige RHEL-implementaties. ExpressRoute is een gedeelde service, dus u moet uw bandbreedtecapaciteit zorgvuldig plannen om te voldoen aan de totale bandbreedtebehoeften van uw bedrijf. Als u onvoldoende bandbreedte hebt, kunt u de gebruikerservaring of de toegang tot kritieke services in het datacenter in gevaar krijgen. Zorg ervoor dat u ExpressRoute op een flexibele manier implementeert in regio's en peeringlocaties. |
| Beschikbaarheidszones | Afzonderlijke groepen datacenters met hun eigen energie-, koelings- en netwerksystemen binnen een Azure-regio. Beschikbaarheidszones bieden hoge beschikbaarheid en tolerantie voor storingen in datacenters. | Als u een SLA (High Service Level Agreement) wilt garanderen, gebruikt u waar mogelijk beschikbaarheidszones met RHEL-infrastructuur. Beschikbaarheidszones bieden datacenterredundantie binnen een regio. Maar niet elke regio heeft beschikbaarheidszones, dus u moet zorgvuldig plannen. RHEL-services, zoals Azure Red Hat OpenShift en de beheerservices voor landingszones, ondersteunen beschikbaarheidszones. |
| Beschikbaarheidssets | Een logische groepering van VM's. Ten minste één VM is altijd actief tijdens geplande of ongeplande onderhoudsgebeurtenissen. Een foutdomein is een subset van een beschikbaarheidsset die een gemeenschappelijke fysieke infrastructuur deelt, zoals stroom of netwerk. Wanneer u VM's over verschillende foutdomeinen distribueert, vermindert een beschikbaarheidsset de impact van hardwarefouten op de beschikbaarheid van de VM. | Beschikbaarheidssets bieden een hoge SLA. Beschikbaarheidssets zijn geschikt voor een RHEL-infrastructuur wanneer een regio geen beschikbaarheidszones heeft. Beschikbaarheidssets hebben alleen hardwareredundantie, wat vergelijkbaar is met regels voor hypervisor-antiaffiniteit. Dus als uw regio's geen beschikbaarheidszones hebben, hebt u een strategie voor meerdere regio's nodig voor datacenter- en geografische redundantie. |
| Azure-belastingsverdeling | Een netwerktaakverdelingsservice. U kunt Load Balancer zo configureren dat netwerkverkeer met een hoog volume efficiënt wordt geboden op meerdere Red Hat Enterprise-servers. De service werkt met lage latentie en hoge doorvoer, waardoor de prestaties en beschikbaarheid van toepassingen worden verbeterd. Load Balancer kan automatisch worden geschaald op basis van de vraag. Om een hybride implementatie van uw toepassingen te bevorderen, kan Load Balancer netwerkverkeer verdelen over meerdere regio's in Azure en ook tussen on-premises omgevingen en Azure. |
Load Balancer verdeelt netwerkverkeer over meerdere servers om ononderbroken beschikbaarheid van toepassingen te bieden en storingen met één punt te voorkomen. Als zich een noodgeval voordoet, leidt Load Balancer verkeer om naar operationele servers om een snelle failover en herstel te bieden. Deze bewerking minimaliseert downtime en onderhoudt bedrijfsactiviteiten. Load Balancer kan verkeer verdelen over on-premises servers naar de Azure-cloud of naar servers in meerdere Azure-regio's. Zie Opties voor taakverdeling voor meer informatie. |
| Beheerde schijven | Gevirtualiseerde schijven die azure beheert. U kiest de schijfgrootte en het type. Azure distribueert schijven over verschillende opslageenheden om uw gegevens te beschermen tegen hardwarefouten. | Beheerde schijven zijn de beste keuze voor alle RHEL-infrastructuur. Gebruik geen niet-beheerde schijven. Zie SLA's voor VM's voor meer informatie. Verschillende typen schijven hebben verschillende prestaties en kosten. Voor RHEL-infrastructuurmachines raden we Azure Premium SSD aan. Houd rekening met kosten, prestaties en beschikbaarheid wanneer u het schijftype kiest. Wanneer u de toewijzing van een systeem ongedaan wilt maken, worden lokale SSD- en kortstondige schijven verwijderd. Maak waar nodig een back-up van de gegevens op deze schijven. |
| Azure Backup | Een service die rendabele oplossingen biedt om een back-up van uw gegevens te maken en deze te herstellen vanuit de Azure-cloud. | Back-up is een betrouwbare en rendabele oplossing die uw RHEL-infrastructuur beschermt tegen VM-fouten of beschadigingen. Gebruik Back-up om uw hele VIRTUELE machine of specifieke bestanden en mappen eenvoudig te herstellen vanuit de cloud, zonder dat u de virtuele machine opnieuw hoeft te maken of gegevens kwijtraakt. U kunt ook andere ondersteunde partneroplossingen gebruiken. |
| Azure Arc | Een platform dat Azure-services uitbreidt, zodat ze worden uitgevoerd in diverse omgevingen, waaronder datacenters, edge-apparaten en architecturen met meerdere clouds. Gebruik Azure Arc om consistent ontwikkelings-, bewerkingen- en beveiligingsbeheer te bieden voor toepassingen en services. | Gebruik Azure Arc om gecentraliseerde geautomatiseerde back-ups en bewaking te implementeren, waardoor de tolerantie vanuit een BCDR-perspectief toeneemt. |
| Azure Site Recovery | Een service die mogelijkheden biedt voor herstel na noodgevallen om bedrijfscontinuïteit te garanderen. U kunt workloads, waaronder Azure-VM's en on-premises VM's, repliceren en beheren in verschillende regio's. Met Site Recovery kunt u replicatie-, failover- en herstelprocessen instellen om uw toepassingen te beschermen tijdens geplande storingen en niet-geplande storingen. | Gebruik Site Recovery om herstelproblemen te minimaliseren, infrastructuurkosten te verlagen en veilig en betrouwbaar herstel tussen Azure-regio's of on-premises locaties naar Azure te garanderen. |
| Resourcevergrendelingen | Een Azure-functie die u kunt gebruiken om gebruikers en rollen in uw organisatie te beperken. Beveilig uw kritieke resources tegen onbedoelde of schadelijke wijzigingen. U kunt een resource vergrendelen op verschillende bereikniveaus, zoals abonnement, resourcegroep of afzonderlijke resourceniveaus. Afhankelijk van het type vergrendeling kunt u voorkomen dat gebruikers een resource verwijderen of wijzigen, maar ze kunnen de configuratie nog wel lezen. | Gebruik resourcevergrendelingen om alle RHEL-infrastructuur en golden image-VM's te beveiligen. Als u wilt voorkomen dat belangrijke machines per ongeluk verloren gaan, past u de verwijderingsvergrendeling minimaal toe. Pas de ReadOnly-vergrendeling toe op RHEL-infrastructuurmachines omdat ze niet vaak veranderen. Breng alleen wijzigingen aan tijdens de juiste vensters voor wijzigingsbeheer. |
BCDR-overwegingen voor RHEL-platform
Zie voor meer informatie over BCDR-mogelijkheden voor een RHEL-platforminfrastructuur:
- Architectuur voor hoge beschikbaarheid van satellieten.
- Architectuur voor hoge beschikbaarheid van Ansible Automation-platform.
- Architectuur voor hoge beschikbaarheid van identiteitsbeheer.
Ontwerpaanaanvelingen
Gebruik voor cloudeigen toepassingen in Linux-containers een Op Kubernetes gebaseerd platform om schaalbaarheid, hoge beschikbaarheid en redundantie te garanderen. Overweeg het Azure Red Hat OpenShift-platform of een zelfbeheerde OpenShift-implementatie te gebruiken met gerepliceerde of geo-gerepliceerde opslag.
Voor front-ends van systeemeigen webtoepassingen en staatloze toepassingen kunt u veel van de systeemeigen Azure-services gebruiken die de beschikbaarheid van toepassingen bieden. Zie voor architecturen die gebruikmaken van dergelijke services:
- Maximaal beschikbare zone-redundante webtoepassing basislijn.
- Maximaal beschikbare webtoepassing met meerdere regio's.
In de voorgaande architecturen worden verschillende Azure-services gebruikt voor beschikbaarheidszones. De architectuur voor meerdere regio's maakt gebruik van geo-replicatiefuncties voor inhoud en Azure Front Door als een taakverdelingsservice.
Voor veel traditionele stateful toepassingen waarvoor hoge beschikbaarheid is vereist, biedt RHEL de invoegtoepassing Pacemaker voor hoge beschikbaarheid. U kunt systemen ophalen met deze functie van Azure Marketplace of u kunt een aangepaste installatiekopieën implementeren met de vereiste softwareonderdelen die zijn ingesloten. Zie Een Red Hat-cluster met hoge beschikbaarheid configureren in Microsoft Azure voor meer informatie.
Beschikbaarheidsproblemen zijn van invloed op servicestoringen en reactietijden van de service. Servicedegradatie kan optreden, wat de service-ervaring van uw klant kan verminderen. Gebruik de azure on-demand capaciteitsreserveringsfunctie om ervoor te zorgen dat u prestatieniveaus en voldoende capaciteit binnen de vereiste regio's onderhoudt .
Betrouwbaarheid
Veel van de concepten die van toepassing zijn op infrastructure as a service VM-infrastructuren, zijn ook van toepassing op RHEL-architecturen. Zie ontwerpprincipes voor betrouwbaarheid voor meer informatie.
Clusters
Azure biedt geen ondersteuning voor het combineren van Application Server Central Services en hoge beschikbaarheid van databases binnen één RHEL Pacemaker-cluster. Als u deze beperking wilt oplossen, scheidt u deze in afzonderlijke clusters. U kunt maximaal vijf centrale servicesclusters combineren in een paar VM's.
Overweeg voor BCDR in SAP de volgende services om SAP Central-servicesclusters uit te voeren:
- RHEL Pacemaker-cluster: STONITH-blokapparaten worden niet ondersteund, maar u kunt gebruikmaken van de Azure Fence-agent.
- SAP-gecertificeerde niet-Microsoft-clustersoftware: verken deze optie als deze overeenkomt met uw vereisten.
Kies de juiste service op basis van uw specifieke behoeften en uw besturingssysteem.
Zie voor meer informatie:
- Configureer een Red Hat-cluster met hoge beschikbaarheid in Microsoft Azure voor RHEL 9.
- Clusters met hoge beschikbaarheid configureren en beheren voor RHEL 9.
- RHEL 8-documentatie.
Replica's van de Azure Compute-galerie
U kunt Compute Gallery gebruiken om gouden installatiekopieën op te slaan voor implementaties. Gebruik deze installatiekopieën voor herstel na noodgevallen van toepassingen en hulpprogramma's. Compute Gallery kan maximaal beschikbare resources gebruiken met ZRS-accounts (zone-redundante opslag) in regio's die beschikbaarheidszones ondersteunen. ZRS biedt tolerantie tegen zonegebonden fouten. U kunt galerieafbeeldingen ook repliceren naar andere regio's of geografische gebieden.
Notitie
U wordt aangeraden ten minste twee galerieën in verschillende regio's te hebben.
Siteherstel
Site Recovery kan de tolerantie van sommige RHEL-onderdelen verbeteren. Zie de ondersteuningsmatrix voor herstel na noodgevallen van Azure-VM's met Site Recovery voor een lijst met ondersteunde RHEL-siteherstelservers. U kunt Site Recovery ook instellen als een failover van on-premises omgevingen naar de cloud. Gebruik de Site Recovery-implementatieplanner om een schatting te krijgen van de Kosten van Site Recovery.
Herstelclusterknooppunten
Als u rto's wilt verminderen en de tolerantie wilt vergroten, kunt u actieve of stand-by clusterknooppunten voor extern herstel gebruiken. U moet clusteritems voor herstel na noodgevallen handmatig configureren. U moet bijvoorbeeld configuraties toepassen om resources in te stellen en gegevens te kopiëren.