Bewerken

Delen via

Web-apps implementeren met zoneredundante Azure Red Hat OpenShift

Azure Red Hat OpenShift
Azure Cosmos DB
Azure Front Door

Dit artikel bevat een uitgebreid overzicht van een workload van een web-app in Azure Red Hat OpenShift in een zone-redundante configuratie. Zone-redundante services repliceren uw services en gegevens in beschikbaarheidszones om ze te beschermen tegen single points of failure en hoge beschikbaarheid te bieden.

Voordat u een productieomgeving bouwt met Azure Red Hat OpenShift, leest u de azure Red Hat OpenShift-landingszoneversneller.

Architectuur

Diagram met de architectuur voor een webtoepassing met hoge beschikbaarheid.

Een Visio-bestand van deze architectuur downloaden.

Workflow

  • Een gebruiker verzendt een aanvraag naar Azure.
  • Azure Front Door ontvangt de aanvraag en stuurt de aanvraag door naar een webtoepassing die wordt gehost in Azure Red Hat OpenShift.
  • De webtoepassing voert de aanvraag uit met behulp van Azure Key Vault, Azure Cosmos DB en Azure Container Registry.
  • De webtoepassing stuurt een antwoord terug naar de gebruiker.

Onderdelen

  • Microsoft Entra ID of Azure AD B2C verifieert gebruikers. In deze architectuur biedt Microsoft Entra ID veilige, gedetailleerde toegang tot externe resources.
  • Azure Front Door is de openbare interface voor alle internetaanvragen. Het fungeert als een globale omgekeerde HTTP-proxy en cache voor back-endservices. Azure Front Door verbetert de beveiliging en prestaties van deze architectuur, zoals het toevoegen van beveiliging tegen DDoS-aanvallen (Layer 4 Distributed Denial-of-Service).
  • Azure Red Hat OpenShift is de kubernetes-containerorchestrator die als host fungeert voor de API-toepassingen en -services en biedt een interface voor back-endservices. Azure Red Hat OpenShift fungeert als het primaire rekenplatform in deze architectuur.
  • Container Registry ondersteunt containerinstallatiekopieën die compatibel zijn met Docker en Open Container Initiative (OCI). Container Registry ondersteunt zoneredundantie, waardoor deze maximaal beschikbaar is en bestand is tegen zonefouten. Het biedt ook ondersteuning voor geo-replicatie, waarmee de service wordt gerepliceerd in meerdere regio's. In deze architectuur biedt Container Registry privétoegang tot het ARO-cluster privétoegang tot lokaal beheerde containerinstallatiekopieën die deel uitmaken van de workload.
  • Azure Red Hat OpenShift maakt gebruik van integratie van virtuele netwerken om verbinding te maken met back-endservices via een particulier virtueel netwerk. Integratie van virtuele netwerken biedt een beveiligd netwerk met Azure Red Hat OpenShift en andere Azure-services in deze architectuur.
  • Azure Cosmos DB biedt NoSQL-documentdatabases voor front-endservices. Azure Cosmos DB wordt door de workload in deze architectuur gebruikt om gebruikersgegevens op te slaan.
  • Privé-eindpunten maken verbindingen met PaaS Azure-services mogelijk vanuit particuliere virtuele netwerken en stellen u in staat om de openbare eindpunten op deze services uit te schakelen. In deze architectuur houden privé-eindpunten met integratie van virtuele netwerken netwerkverkeer van Azure Red Hat OpenShift privé tijdens de communicatie met PaaS-services.
  • Azure Privé-DNS configureert en werkt de DNS-records bij die nodig zijn voor de privé-eindpuntservices. In deze architectuur wordt Azure Privé-DNS gebruikt voor naamomzetting in privénetwerken.
  • Key Vault slaat veilig geheimen en certificaten op die toegankelijk zijn voor Azure-services. In deze architectuur slaat Azure Key Vault veilig geheimen op voor de toepassingen die worden uitgevoerd in Azure Red Hat OpenShift.
  • Azure Monitor en Application Insights verzamelen servicelogboeken en metrische gegevens over toepassingsprestaties voor waarneembaarheid. In deze architectuur is Azure Monitor de logboeksynchronisatie voor zowel platform- als workloadlogboeken. Application Insights is specifiek bedoeld voor logboeken en metrische gegevens die afkomstig zijn uit de workloadcode.

Alternatieven

  • Door Azure beheerde DNS wordt aanbevolen, maar u kunt uw eigen DNS-provider gebruiken.
  • Gebruik Azure-toepassing Gateway in plaats van Azure Front Door als de meeste gebruikers zich dicht bij de Azure-regio bevinden die als host fungeert voor uw workload en als u geen inhoudscache nodig hebt. Gebruik Azure DDoS Protection om internetgerichte Application Gateway-services te beveiligen.
  • Implementeer een premium Azure API Management-exemplaar met zoneredundantie als alternatief voor het hosten van front-end-API's, back-end-API's of beide. Zie Azure API Management migreren naar ondersteuning voor beschikbaarheidszones voor meer informatie over zoneredundantie van API Management.
  • U kunt OpenShift Container Platform (OCP) of Origin Community Distribution of Kubernetes (OKD) gebruiken op virtuele Azure-machines in plaats van Azure Red Hat OpenShift. OCP of OKD zijn iaaS-alternatieven (infrastructure-as-a-service) voor een volledig door het platform beheerde service, zoals Azure Red Hat OpenShift. U moet Azure Virtual Machine Scale Sets gebruiken voor zoneredundantie. Zie Azure Red Hat OpenShift voor meer informatie.

Scenariodetails

In deze architectuur wordt beschreven hoe u zone-redundante services opstelt in een oplossing die hoge beschikbaarheid biedt en bestand is tegen zonegebonden fouten.

Beschikbaarheidszones zijn afzonderlijke fysieke locaties in elke Azure-regio. Beschikbaarheidszones verspreiden een oplossing over meerdere onafhankelijke zones in een regio, waardoor een toepassing kan blijven functioneren wanneer één zone uitvalt. Deze architectuur bouwt voort op de infrastructuur voor beschikbaarheidszones die zich in veel regio's bevindt. Zie Azure-regio's met beschikbaarheidszones voor een lijst met regio's die ondersteuning bieden voor Azure-beschikbaarheidszones.

Wanneer hostingplatforms op schaal zijn, is het vaak moeilijk om ze maximaal beschikbaar te houden. Hoge beschikbaarheid heeft in het verleden complexe en dure implementaties in meerdere regio's nodig met gegevensconsistentie en hoge prestaties. Beschikbaarheidszones lossen veel van deze problemen op. De meeste algemene Azure-services en veel gespecialiseerde Azure-services bieden ondersteuning voor beschikbaarheidszones. Alle Azure-services in deze architectuur zijn zone-redundant, wat de implementatie en het beheer vereenvoudigt. Zie Azure-services die beschikbaarheidszones ondersteunen voor meer informatie.

Om de sla's (Service Level Agreements) te onderhouden, beheert en beperkt zoneredundante Azure Red Hat OpenShift fouten, waaronder zonefouten. Zoneredundantie biedt een hersteltijd van nul voor zonefouten. Als één zone in een regio niet beschikbaar is, verliest u geen gegevens en blijft uw workload actief. Zoneredundantie wordt geconfigureerd tijdens de implementatie en wordt beheerd door services, dus u hoeft zonepinning of zonegebonden implementaties niet te beheren.

In deze architectuur wordt een Azure Red Hat OpenShift-cluster geïmplementeerd in drie beschikbaarheidszones in Azure-regio's die deze ondersteunen. Een cluster bestaat uit drie besturingsvlakknooppunten en drie of meer werkknooppunten. Om de redundantie te verbeteren, worden de knooppunten verspreid over de zones.

Azure Front Door, Microsoft Entra ID en Azure DNS zijn wereldwijd beschikbare services die bestand zijn tegen zone- en regiobrede storingen. Alle andere services in deze architectuur zijn zone-redundant.

Potentiële gebruikscases

Azure Red Hat OpenShift is een containerindelingsservice die gebruikmaakt van Kubernetes. Het is geschikt voor veel gebruiksvoorbeelden, zoals:

  • Bankieren
  • Aandelenhandel
  • E-commerce
  • Sociale media
  • Webtoepassingen
  • Mobiele toepassingen
  • Batchverwerkingstoepassingen
  • Mediastreaming
  • Machine learning-workloads

Aanbevelingen

De volgende aanbevelingen zijn van toepassing op de meeste scenario's.

Azure Front Door

  • Gebruik door Azure beheerde certificaten in alle front-endtoepassingen om onjuiste configuratie en verloopproblemen met certificaten te voorkomen.
  • Cache inschakelen voor routes om de beschikbaarheid te verbeteren. De Azure Front Door-cache distribueert uw dynamische inhoud en statische inhoud naar de Edge-knooppunten van Azure Point-of-Presence (POP). Caching vermindert de belasting op oorspronkelijke servers en verbetert de prestaties.
  • Implementeer Azure Front Door Premium en configureer een WAF-beleid (Web Application Firewall) met een door Microsoft beheerde regelset. Pas het beleid toe op alle aangepaste domeinen. Gebruik de preventiemodus om webaanvallen te beperken die een origin-service-fout kunnen veroorzaken.

Azure Red Hat OpenShift

  • Zorg ervoor dat de Azure-regio waarin Azure Red Hat OpenShift is geïmplementeerd, beschikbaarheidszones ondersteunt. Zie Azure-regio's met ondersteuning voor beschikbaarheidszones voor meer informatie.
  • Een Azure Red Hat OpenShift-cluster is afhankelijk van sommige services. Zorg ervoor dat deze services worden ondersteund en geconfigureerd voor zoneredundantie. Zie Azure-services met ondersteuning voor beschikbaarheidszones voor meer informatie.
  • Verwijder de status uit containers en gebruik in plaats daarvan Azure Storage- of databaseservices.
  • Stel meerdere replica's in implementaties in met de juiste budgetconfiguratie voor onderbrekingen om toepassingsservice continu te bieden ondanks onderbrekingen, zoals hardwarefouten in zones.
  • Beveiligde toegang tot Azure Red Hat OpenShift. Om ervoor te zorgen dat aanvragen de Azure Front Door WAF niet kunnen omzeilen, staat u alleen Azure Front Door-verkeer toe. Zie Beveiligde toegang tot Azure Red Hat OpenShift met Azure Front Door voor meer informatie over het beperken van de toegang tot een specifiek Azure Front Door-exemplaar.

Container Registry

Zie Zoneredundantie inSchakelen in Container Registry voor tolerantie en hoge beschikbaarheid en Container Registry gebruiken met Azure Red Hat OpenShift voor meer informatie.

Azure Cosmos DB

Key Vault

Key Vault is zone-redundant in elke regio waar beschikbaarheidszones beschikbaar zijn. In deze architectuur wordt Key Vault geïmplementeerd met een privé-eindpunt ingeschakeld en een openbaar eindpunt uitgeschakeld. Zie Key Vault integreren met Private Link voor meer informatie over privé-eindpunten voor Key Vault.

Privé-Azure DNS-zones

Om DNS-beheer te vereenvoudigen, integreert u privé-eindpunten met privé-Azure DNS-zones. Zie DNS-configuratie voor privé-eindpunten in Azure voor meer informatie.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Azure Well-Architected Framework voor meer informatie.

Betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie Controlelijst ontwerpbeoordeling voor betrouwbaarheidvoor meer informatie.

Deze architectuur zorgt voor betrouwbaarheid door beschikbaarheid, tolerantie en betrouwbare wereldwijde servicefuncties te bieden.

Beschikbaarheid

Wanneer de infrastructuur van de beschikbaarheidszone correct wordt geïmplementeerd, biedt deze architectuur een uitstekende beschikbaarheid voor lagere kosten en lagere operationele overhead dan andere oplossingen. Deze architectuur beperkt het risico van een zonefout in een Azure-regio omdat zone-redundante services bestand zijn tegen de fout terwijl ze nog steeds binnen de gedefinieerde SLA werken.

Regionale storingen zijn onwaarschijnlijk, maar mogelijk. In een regionale fout zijn services niet beschikbaar in alle beschikbaarheidszones binnen een regio. Combineer deze zoneredundante architectuur met een architectuur met meerdere regio's om het risico op regiofouten te beperken. Plan uw architectuur voor meerdere regio's om de hersteltijd te verminderen als een hele regio niet beschikbaar is.

Ontwerpen in meerdere regio's zijn complexer en vaak duurder dan ontwerpen met meerdere zones in één regio, maar ontwerpen in meerdere regio's bieden een mogelijkheid om de beschikbaarheid en algehele betrouwbaarheid verder te optimaliseren.

Notitie

Voer een risicoanalyse uit om te bepalen of uw oplossing een architectuur met meerdere regio's vereist.

Flexibiliteit

Ontwerpen met meerdere zones die zijn gebaseerd op beschikbaarheidszones bieden beschikbaarheid en tolerantie die voldoet aan of overschrijdt de bedrijfsvereisten van de meeste organisaties. Maar als u gegevens wilt repliceren naar een secundaire regio voor herstel na noodgevallen, zijn uw opties afhankelijk van de Azure-services die u gebruikt.

Azure Storage ondersteunt bijvoorbeeld objectreplicatie voor blok-blobs. Azure-gegevensservices, zoals Azure Cosmos DB, bieden gegevensreplicatie naar andere Azure-regio's met continue back-up. U kunt deze functies gebruiken om uw oplossing te herstellen als er zich een noodgeval voordoet. Zie Continue back-up met herstel naar een bepaald tijdstip in Azure Cosmos DB voor meer informatie.

Global Services

Fouten in wereldwijde services, zoals Azure Front Door en Microsoft Entra ID, zijn zeldzaam, maar het effect van een fout kan hoog zijn. Om het herstel te verbeteren als er een fout optreedt, bereidt u runbooks voor en oefent u deze uit.

U kunt bijvoorbeeld de downtime van Azure Front Door verminderen door een runbook te gebruiken om Azure-toepassing Gateway te implementeren en DNS-records te wijzigen om verkeer om te leiden totdat Azure Front Door is hersteld.

Zie Tolerantie bouwen in de infrastructuur voor identiteits- en toegangsbeheer voor meer informatie.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie voor meer informatie controlelijst ontwerpbeoordeling voor Security.

  • Overweeg om een privécluster te implementeren.
  • Gebruik privé-eindpunten in Azure-services die niet toegankelijk zijn via het openbare internet.
  • Standaard is alle service-naar-service-communicatie in Azure tls (Transport Layer Security) versleuteld. Configureer Azure Front Door om alleen HTTPS-verkeer te accepteren en stel de minimale TLS-versie in.
  • Beheerde identiteiten verifiëren communicatie van Azure-service-naar-service waar deze beschikbaar is. Zie Wat zijn beheerde identiteiten voor Azure-resources? voor meer informatie.
  • Als u geheimen, certificaten en verbindingsreeks s in uw cluster wilt beheren en beveiligen, verbindt u het Azure Red Hat OpenShift-cluster met Kubernetes met Azure Arc. Gebruik de Key Vault Secrets Provider-extensie om geheimen op te halen.
  • Configureer Microsoft Defender for Containers om beveiliging te bieden voor clusters, containers en toepassingen. Defender for Containers wordt ondersteund via Kubernetes met Azure Arc. Scan uw afbeeldingen op beveiligingsproblemen met Microsoft Defender of een andere oplossing voor het scannen van afbeeldingen.
  • Configureer Microsoft Entra-integratie om Microsoft Entra ID te gebruiken om gebruikers (bijvoorbeeld SRE, SecOps of toepassingsontwikkelaars) te verifiëren in uw Azure Red Hat OpenShift-cluster.

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie controlelijst ontwerpbeoordeling voor kostenoptimalisatievoor meer informatie.

Zone-redundante architecturen zijn goedkoper dan alternatieven voor meerdere regio's, omdat services in één regio worden geïmplementeerd. Er zijn echter verschillende gevolgen voor de kosten om rekening mee te houden:

  • Voor sommige services moet een minimum aantal exemplaren of replica's worden geïmplementeerd om zoneredundantie te bereiken.
  • Zone-redundante opslag (ZRS) en lokaal redundante opslag (LRS) hebben verschillende prijzen. Zie Opslagprijzen voor meer informatie.
  • Privé-eindpunten zijn meestal beschikbaar in premium Azure-service-SKU's. Voor privé-eindpunten worden uurkosten en bandbreedtekosten in rekening gebracht. Zie Prijzen voor Private Link voor meer informatie.

Optimaliseer de kosten door vooraf resources te reserveren. Veel services in deze architectuur komen in aanmerking voor prijzen voor gereserveerde capaciteit. Zie Reserveringen voor meer informatie.

Gebruik de Azure-prijscalculator om een schatting van de kosten te maken.

Operationele uitmuntendheid

Operational Excellence behandelt de operationele processen die een toepassing implementeren en deze in productie houden. Zie controlelijst ontwerpbeoordeling voor Operational Excellencevoor meer informatie.

Alle Azure-services die Platform as a Service (PaaS) zijn, zijn geïntegreerd met Azure Monitor. Volg de best practices van Azure Monitor (betrouwbaarheid, beveiliging, kostenoptimalisatie, operationele uitmuntendheid en prestatie-efficiëntie) om:

  • Bouw een statusmodel om de toepassingsstatus te kwantificeren in de context van bedrijfsvereisten.
  • Configureer de juiste hoeveelheid logboekgegevensverzameling.
  • Maak Azure-dashboards om gegevens te combineren in één weergave voor operationele teams.
  • Maak een geslaagde waarschuwingsstrategie.
  • Integreer Application Insights in apps om metrische gegevens over de prestaties van toepassingen bij te houden.
  • Als u meldingen wilt opgeven wanneer directe actie nodig is, gebruikt u een waarschuwingssysteem, zoals metrische waarschuwingen voor Container Insights of de waarschuwingsgebruikersinterface van Azure Red Hat OpenShift.
  • Overweeg verschillende methoden voor het bewaken en registreren van Azure Red Hat OpenShift om inzicht te krijgen in de status van uw resources en potentiële problemen te voorzien.
  • Bekijk de verantwoordelijkheidsmatrix van Azure Red Hat OpenShift om te begrijpen hoe Microsoft, Red Hat en klanten verantwoordelijkheden voor clusters delen.
  • Automatiseer service-implementaties met Bicep, een sjabloontaal voor het implementeren van infrastructuur als code (IaC). Omdat Azure-services in deze architectuur privé-eindpunten hebben, kunt u geen door Microsoft gehoste agents van Azure Pipelines of door GitHub gehoste runners gebruiken. Gebruik in plaats daarvan oplossingen zoals zelf-hostende agents van Azure Pipelines of door GitHub gehoste hardlopers .
  • Valideer continu de workload om de prestaties en tolerantie van de hele oplossing te testen met behulp van services, zoals Azure Load Testing en Azure Chaos Studio.

Prestatie-efficiëntie

Prestatie-efficiëntie is de mogelijkheid van uw workload om te schalen om te voldoen aan de eisen die gebruikers op een efficiënte manier stellen. Zie controlelijst ontwerpbeoordeling voor prestatie-efficiëntievoor meer informatie.

  • Cacheassets in Azure Front Door om workloads te distribueren naar edge-locaties.
  • Bekijk abonnementslimieten en -quota om ervoor te zorgen dat services naar vraag worden geschaald.
  • Bewaak de prestaties van toepassingen met behulp van Application Insights.
  • Prestatietestworkloads om eventuele latentie te meten die wordt veroorzaakt door verbindingen tussen zones.
  • Kies de juiste grootten voor virtuele machines voor uw workloads. Kies een grootte die groot genoeg is om de voordelen van een verhoogde dichtheid te krijgen, maar niet zo groot dat uw cluster de werkbelasting van een mislukt knooppunt niet kan verwerken.
  • Gebruik podaanvragen en -limieten om de rekenresources binnen een cluster te beheren. Podaanvragen en -limieten informeren de Kubernetes-planner, die rekenresources toewijst aan een pod. Beperk het resourceverbruik in een project met behulp van limietbereiken.
  • Definieer podresourceaanvragen en -limieten in de distributiemanifesten van de toepassing en dwing deze af met Azure Policy.
  • Optimaliseer de CPU- en geheugenaanvraagwaarden en maximaliseer de efficiëntie van de clusterbronnen met behulp van de verticale schaalaanpassing voor pods.
  • Schaal pods om aan de vraag te voldoen met behulp van de horizontale automatische schaalaanpassing van pods.
  • Definieer ClusterAutoScaler en MachineAutoScaler om machines te schalen wanneer uw cluster onvoldoende resources heeft om meer implementaties te ondersteunen.

Dit scenario implementeren

Als u deze architectuur wilt implementeren, raadpleegt u de Azure Red Hat OpenShift-landingszoneversneller en de bijbehorende GitHub-opslagplaats.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Belangrijkste auteurs:

Andere Inzenders:

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen