Deze referentiearchitectuur biedt richtlijnen voor het implementeren van een bedrijfskritieke workload die gebruikmaakt van gecentraliseerde gedeelde services, on-premises connectiviteit nodig heeft en kan worden geïntegreerd met andere workloads van een onderneming. Deze richtlijnen zijn bedoeld voor een eigenaar van een workload die deel uitmaakt van een toepassingsteam in de organisatie.
Het kan zijn dat u zich in deze situatie bevindt wanneer uw organisatie de workload wil implementeren in een Landingszone van een Azure-toepassing die de Corp-beheergroep over neemt. De workload wordt naar verwachting geïntegreerd met vooraf ingerichte gedeelde resources in de landingszone van het Azure-platform die worden beheerd door gecentraliseerde teams.
Belangrijk
Wat is een Azure-landingszone? Een landingszone voor toepassingen is een Azure-abonnement waarin de workload wordt uitgevoerd. Deze is verbonden met de gedeelde resources van de organisatie. Via deze verbinding heeft het toegang tot de basisinfrastructuur die nodig is om de workload uit te voeren, zoals netwerken, identiteitstoegangsbeheer, beleid en bewaking. De platformlandingszones zijn een verzameling van verschillende abonnementen, elk met een specifieke functie. Het Verbinding maken iviteitsabonnement biedt bijvoorbeeld gecentraliseerde DNS-resolutie, on-premises connectiviteit en virtuele netwerkapparaten (NVA's) die beschikbaar zijn voor gebruik door toepassingsteams.
Als eigenaar van een workload profiteert u van offloading van het beheer van gedeelde resources naar centrale teams en richt u zich op de ontwikkeling van workloads. De organisatie profiteert door consistente governance toe te passen en kosten af te schrijven voor meerdere workloads.
We raden u ten zeerste aan het concept van Azure-landingszones te begrijpen.
In deze benadering is maximale betrouwbaarheid een gedeelde verantwoordelijkheid tussen u en het platformteam. De centraal beheerde onderdelen moeten zeer betrouwbaar zijn voor een bedrijfskritieke workload om naar verwachting te kunnen functioneren. U moet een vertrouwde relatie hebben met het platformteam, zodat problemen met niet-beschikbaarheid in de gecentraliseerde services, die van invloed zijn op de workload, worden beperkt op platformniveau. Maar uw team is verantwoordelijk voor het stimuleren van vereisten met het platformteam om uw doelen te bereiken.
Deze architectuur bouwt voort op de essentiële basislijnarchitectuur met netwerkcontroles. Het is raadzaam om vertrouwd te raken met de basislijnarchitectuur voordat u verdergaat met dit artikel.
Notitie
De richtlijnen worden ondersteund door een voorbeeld-implementatie op productieniveau waarin bedrijfskritieke toepassingsontwikkeling in Azure wordt getoond. Deze implementatie kan worden gebruikt als basis voor verdere ontwikkeling van oplossingen als uw eerste stap in de richting van productie.
Belangrijke ontwerpstrategieën
Pas deze strategieën toe op de bedrijfskritieke basislijn:
Kritiek pad
Niet alle onderdelen van de architectuur moeten even betrouwbaar zijn. Kritiek pad omvat de onderdelen die functioneel moeten worden gehouden, zodat de workload geen uitvalt of verminderde prestaties ondervindt. Door dat pad lean te houden, worden storingspunten geminimaliseerd.
Levenscyclus van onderdelen
Houd rekening met de levenscyclus van kritieke onderdelen, omdat dit invloed heeft op uw doel om bijna nul uit de tijd te halen. Onderdelen kunnen kortstondige of kortstondige resources zijn die naar behoefte kunnen worden gemaakt en vernietigd; niet-kortstondige of langlevende resources die de levensduur delen met het systeem of de regio.
Externe afhankelijkheden
Minimaliseer externe afhankelijkheden van onderdelen en processen, wat kan leiden tot storingspunten. De architectuur heeft resources die eigendom zijn van verschillende teams buiten uw team. Deze onderdelen (indien kritiek) vallen binnen het bereik van deze architectuur.
Abonnementstopologie
Azure-landingszones impliceren geen enkele abonnementstopologie. Plan uw abonnementsvoetafdruk vooraf met uw platformteam om tegemoet te komen aan de betrouwbaarheidsvereisten voor workloads in alle omgevingen.
Autonome waarneembaarheid in het kritieke pad
Toegewezen bewakingsresources hebben waarmee het team snel query's kan uitvoeren op hun gegevensverzameling (met name het kritieke pad) en actie kan ondernemen op herstelbewerkingen.
Architectuur
Een Visio-bestand van deze architectuur downloaden.
De onderdelen van deze architectuur zijn hetzelfde als de essentiële basislijnarchitectuur met netwerkcontroles. De beschrijvingen zijn kort voor kortheid. Zie de gekoppelde artikelen als u meer informatie nodig hebt. Zie Verwante resources voor productdocumentatie over Azure-services.
Globale resources
Deze resources bevinden zich in het abonnement(en) van de landingszone van de toepassing. Globale resources zijn niet kortstondig en delen de levensduur van het systeem. De Azure-services en hun configuratie blijven hetzelfde als de globale basisbronnen.
Regionale netwerkresources
Deze resources bevinden zich in de platformlandingszoneabonnementen en het abonnement(en) op de landingszone van de toepassing. Met de basislijnarchitectuur worden alle resources geïmplementeerd die eigendom zijn van u. In deze architectuur worden netwerkresources echter geleverd via het Verbinding maken iviteitsabonnement als onderdeel van de platformlandingszone.
In dit artikel raadpleegt u de sectie Virtueel netwerk van regionale hubs.
Regionale stempelbronnen
Deze resources bevinden zich in het abonnement(en) van de landingszone van de toepassing. Deze resources delen niets met andere resources, behalve de globale resources.
De meeste Azure-services en hun configuratie blijven hetzelfde als de basislijnstempelarchitectuur, met uitzondering van de netwerkresources, die vooraf zijn ingericht door het platformteam.
In dit artikel raadpleegt u de sectie Regionaal spoke virtueel netwerk .
Externe resources
De workload communiceert met on-premises resources. Sommige hiervan bevinden zich op het kritieke pad voor de workload, bijvoorbeeld een on-premises database. Deze resources en communicatie met deze resources worden meegenomen in de algemene SLA (Service Level Agreement) van de workload. Alle communicatie verloopt via het Verbinding maken iviteitsabonnement. Er zijn andere externe resources die de workload mogelijk bereikt, maar ze worden niet als kritiek beschouwd.
Implementatiepijplijnbronnen
Build- en release-pijplijnen voor een bedrijfskritieke toepassing moeten volledig worden geautomatiseerd om een consistente manier te garanderen voor het implementeren van een gevalideerde zegel. Deze resources blijven hetzelfde als de pijplijn voor de basislijnimplementatie.
Regionale bewakingsbronnen
Deze resources bevinden zich in het abonnement(en) van de landingszone van de toepassing. Bewakingsgegevens voor globale resources en regionale resources worden onafhankelijk opgeslagen. De Azure-services en hun configuratie blijven hetzelfde als de bewakingsbronnen van de basislijn.
Zie de sectie Bewakingsoverwegingen in dit artikel.
Beheerbronnen
Voor toegang tot het privé-rekencluster en andere resources maakt deze architectuur gebruik van privé-buildagents en jumpbox-instanties van virtuele machines. Azure Bastion biedt veilige toegang tot de jumpboxen. De resources in de stempels blijven hetzelfde als de basislijnbeheerbronnen.
Aandachtspunten voor netwerken
In dit ontwerp wordt de workload geïmplementeerd in de landingszone van de toepassing en moet deze verbinding hebben met de federatieve resources in de landingszone van het platform. Het doel kan zijn voor toegang tot on-premises resources, het beheren van uitgaand verkeer, enzovoort.
Netwerktopologie
Het platformteam bepaalt de netwerktopologie voor de hele organisatie. Hub-spoke-topologie wordt aangenomen in deze architectuur. Een alternatief kan Azure Virtual WAN zijn.
Virtueel netwerk van regionale hubs
Het Verbinding maken iviteitsabonnement bevat een virtueel hubnetwerk met resources die worden gedeeld door de hele organisatie. Deze resources zijn eigendom van en onderhouden door het platformteam.
Vanuit een bedrijfskritiek perspectief is dit netwerk niet kortstondig en bevinden deze resources zich op het kritieke pad.
| Azure-resource | Doel |
|---|---|
| Azure ExpressRoute | Biedt privéconnectiviteit van on-premises naar Azure-infrastructuur. |
| Azure Firewall | Fungeert als de NVA die uitgaand verkeer inspecteert en beperkt. |
| Azure DNS | Biedt cross-premises naamomzetting. |
| VPN Gateway | Verbinding maken s externe organisatie vertakkingen via het openbare internet naar de Azure-infrastructuur. Fungeert ook als alternatief voor back-upconnectiviteit voor het toevoegen van tolerantie. |
De resources worden ingericht in elke regio en gekoppeld aan het virtuele spoke-netwerk (hierna beschreven). Zorg ervoor dat u de updates voor NVA, firewallregels, routeringsregels, ExpressRoute-failover naar VPN Gateway, DNS-infrastructuur enzovoort begrijpt en akkoord gaat.
Notitie
Een belangrijk voordeel bij het gebruik van de federatieve hub is dat de workload kan worden geïntegreerd met andere workloads in Azure of cross-premises door de door de organisatie beheerde netwerkhubs te doorlopen. Deze wijziging verlaagt ook uw operationele kosten omdat een deel van de verantwoordelijkheid wordt verschoven naar het platformteam.
Virtueel netwerk met regionale spokes
De landingszone van de toepassing heeft ten minste twee vooraf ingerichte Azure Virtual Networks per regio waarnaar wordt verwezen door de regionale stempels. Deze netwerken zijn niet kortstondig. De ene dient productieverkeer en de andere is gericht op de vNext-implementatie. Deze aanpak biedt u de mogelijkheid om betrouwbare en veilige implementatieprocedures uit te voeren.
Virtueel netwerk voor bewerkingen
Operationeel verkeer wordt geïsoleerd in een afzonderlijk virtueel netwerk. Dit virtuele netwerk is niet kortstondig en u bent eigenaar van dit netwerk. Deze architectuur behoudt hetzelfde ontwerp als de basislijnarchitectuur met netwerkbesturingselementen.
Er is geen peering tussen het bewerkingsnetwerk en het spoke-netwerk. Alle communicatie vindt plaats via privékoppelingen.
Gedeelde verantwoordelijkheden
Een duidelijk inzicht hebben in welk team verantwoordelijk is voor elk ontwerpelement van de architectuur. Hier volgen enkele belangrijke gebieden.
PLANNING van IP-adressen
Nadat u de benodigde grootte voor het uitvoeren van uw workload hebt geschat, kunt u samenwerken met het platformteam, zodat ze het netwerk op de juiste manier kunnen inrichten.
Platformteam
Geef afzonderlijke adressen op voor virtuele netwerken die deelnemen aan peerings. Overlappende adressen, bijvoorbeeld on-premises en workloadnetwerken, kunnen onderbrekingen veroorzaken die leiden tot storingen.
Wijs IP-adresruimten toe die groot genoeg zijn om de resources voor runtime en implementaties te bevatten, failovers af te handelen en schaalbaarheid te ondersteunen.
Het vooraf ingerichte virtuele netwerk en peerings moeten de verwachte groei van de workload kunnen ondersteunen. U moet die groei regelmatig evalueren met het platformteam. Zie Verbinding maken iviteit voor Azure voor meer informatie.
Subnetten van het regionale spoke-netwerk
U bent verantwoordelijk voor het toewijzen van subnetten in het regionale virtuele netwerk. De subnetten en de resources hierin zijn kortstondig. De adresruimte moet groot genoeg zijn om potentiële groei mogelijk te maken.
Subnet privé-eindpunten Nadat verkeer het virtuele netwerk bereikt, wordt communicatie met PaaS-services binnen het netwerk beperkt door privé-eindpunten te gebruiken, net zoals de basislijnarchitectuur met netwerkbesturingselementen. Deze eindpunten worden in een toegewezen subnet geplaatst. Privé-IP-adressen aan de privé-eindpunten worden toegewezen vanuit dat subnet.
Clustersubnet De schaalbaarheidsvereisten van de workload beïnvloeden hoeveel adresruimte moet worden toegewezen voor de subnetten. Als AKS-knooppunten en pods worden uitgeschaald, worden IP-adressen toegewezen vanuit dit subnet.
Netwerksegmentatie
Behoud de juiste segmentatie zodat de betrouwbaarheid van uw workload niet wordt aangetast door onbevoegde toegang.
Deze architectuur maakt gebruik van netwerkbeveiligingsgroepen (NSG's) om verkeer tussen subnetten en het Verbinding maken iviteitsabonnement te beperken. NSG's gebruiken ServiceTags voor de ondersteunde services.
Platformteam
Dwing het gebruik van NSG's af via Azure Network Manager-beleid.
Let op het ontwerp van de werkbelasting. Er is geen direct verkeer tussen de stempels. Er zijn ook geen stromen tussen regio's. Als deze paden nodig zijn, moet verkeer via het Verbinding maken iviteitsabonnement stromen.
Voorkom onnodig hubverkeer dat afkomstig is van andere workloads in de bedrijfskritieke workload.
Uitgaand verkeer van regionale stempels
Al het uitgaande verkeer van elk regionaal spoke-netwerk wordt gerouteerd via de gecentraliseerde Azure Firewall in het regionale hubnetwerk. Het fungeert als de volgende hop die inspecteert en vervolgens verkeer toestaat of weigert.
Platformteam
UDR's maken voor die aangepaste route.
Wijs Azure-beleid toe waarmee het toepassingsteam geen subnetten kan maken die niet over de nieuwe routetabel beschikken.
Geef voldoende RBAC-machtigingen (op rollen gebaseerd toegangsbeheer) aan het toepassingsteam, zodat ze de routes kunnen uitbreiden op basis van de vereisten van de workload.
Redundantie in meerdere regio's
Uw bedrijfskritieke workloads moeten in meerdere regio's worden geïmplementeerd om regionale storingen te weerstaan. Werk samen met het platformteam om ervoor te zorgen dat de infrastructuur betrouwbaar is.
Platformteam
Gecentraliseerde netwerkresources per regio implementeren. De bedrijfskritieke ontwerpmethodologie vereist regionale isolatie.
Werk samen met het toepassingsteam om verborgen regionale afhankelijkheden te ontdekken, zodat een gedegradeerde platformresource in de ene regio geen invloed heeft op workloads in een andere regio.
DNS-resolutie
Het Verbinding maken iviteitsabonnement biedt privé-DNS-zones. Deze gecentraliseerde benadering kan echter niet rekening houden met de DNS-behoeften die mogelijk specifiek zijn voor uw use-case. Richt uw eigen DNS-zones in en maak een koppeling naar de regionale stempel. Als het toepassingsteam geen eigenaar is van DNS, wordt het beheer van privékoppelingen lastig voor wereldwijde resources, zoals Azure Cosmos DB.
Platformteam
De Azure Privé-DNS-zones delegeren aan het toepassingsteam om hun gebruiksvoorbeelden te behandelen.
Stel voor het regionale hubnetwerk de waarde van de DNS-servers in op Standaard (door Azure geleverde) ter ondersteuning van privé-DNS-zones die worden beheerd door het toepassingsteam.
Overwegingen bij het ontwerpen van de omgeving
Het is een algemene praktijk om workloads in afzonderlijke omgevingen te plaatsen voor productie, preproductie en ontwikkeling. Hier volgen enkele belangrijke overwegingen.
Hoe wordt isolatie onderhouden?
De productieomgeving moet worden geïsoleerd van andere omgevingen. Lagere omgevingen moeten ook een isolatieniveau behouden. Vermijd het delen van resources die eigendom zijn van toepassingen tussen omgevingen.
Eén productieomgeving is vereist voor wereldwijde, regionale en stempelbronnen die eigendom zijn van het toepassingsteam. Preproductieomgevingen, zoals fasering en integratie, zijn nodig om ervoor te zorgen dat de toepassing wordt getest in een omgeving die productie simuleert, zoveel mogelijk. De ontwikkelomgeving moet een omlaag geschaalde versie van productie zijn.
Wat is de verwachte levenscyclus?
Preproductieomgevingen kunnen worden vernietigd nadat de validatietests zijn voltooid. Het wordt aanbevolen dat ontwikkelomgevingen de levensduur van een functie delen en worden vernietigd wanneer de ontwikkeling is voltooid. Deze acties worden uitgevoerd door automatisering van continue integratie/continue implementatie (CI/CD).
Wat zijn de compromissen?
Houd rekening met de afwegingen tussen isolatie van omgevingen, complexiteit van beheer en kostenoptimalisatie.
Tip
Alle omgevingen moeten afhankelijk zijn van productie-exemplaren van externe resources, inclusief platformbronnen. Bijvoorbeeld een regionale productiehub in het Verbinding maken iviteitsabonnement. U kunt de verschillen tussen preproductie- en productieomgevingen minimaliseren.
Abonnementstopologie voor workloadinfrastructuur
Abonnementen worden aan u gegeven door het platformteam. Afhankelijk van het aantal omgevingen vraagt u verschillende abonnementen aan voor slechts één workload. Afhankelijk van het type omgeving hebben sommige omgevingen mogelijk toegewezen abonnementen nodig, terwijl andere omgevingen mogelijk worden samengevoegd tot één abonnement.
Werk ook samen met het platformteam om een topologie te ontwerpen die voldoet aan het algemene betrouwbaarheidsdoel voor de workload. Het voordeel van het delen van de door het platform geleverde resources tussen omgevingen in hetzelfde abonnement, omdat dit overeenkomt met de productieomgeving.
Notitie
Het gebruik van meerdere abonnementen om de omgevingen te bevatten, kan het vereiste isolatieniveau bereiken. Abonnementen voor landingszones worden overgenomen van dezelfde beheergroep. Consistentie met productie wordt dus gegarandeerd voor testen en validatie.
Productieabonnement
Er zijn mogelijk resourcelimieten voor het abonnement dat u hebt gekregen. Als u al deze resources in één abonnement opgeeft, kunt u deze limieten bereiken. Op basis van uw schaaleenheden en de verwachte schaal kunt u een meer gedistribueerd model overwegen. Bijvoorbeeld:
Eén abonnement dat zowel Azure DevOps-buildagents als globale resources bevat.
Eén abonnement per regio. Het bevat de regionale resources, de stempelbronnen en jumpboxen voor de regionale stempel(s).
Hier volgt een voorbeeld van een abonnementstopologie die in deze architectuur wordt gebruikt.
Preproductieabonnement
Er is ten minste één abonnement vereist. Het kan veel onafhankelijke omgevingen uitvoeren, maar het is raadzaam om meerdere omgevingen in toegewezen abonnementen te hebben. Dit abonnement kan ook onderhevig zijn aan resourcelimieten zoals het productieabonnement, zoals hierboven beschreven.
Ontwikkelingsabonnement
Er is ten minste één abonnement vereist. Dit abonnement kan onderhevig zijn aan resourcelimieten als alle onafhankelijke omgevingen worden uitgevoerd. U kunt dus meerdere abonnementen aanvragen. Het wordt aanbevolen om afzonderlijke omgevingen in hun toegewezen abonnementen te gebruiken.
Probeer zo veel mogelijk de productietopologie te vinden.
Implementatieoverwegingen
Mislukte implementaties of onjuiste releases zijn veelvoorkomende oorzaken voor storingen in toepassingen. Test uw toepassing (en nieuwe functies) grondig als onderdeel van de levenscyclus van de toepassing. Wanneer u de workload in een landingszone implementeert, moet u uw ontwerp integreren met de door het platform geleverde resources en governance.
Raadpleeg: Goed ontworpen bedrijfskritieke workloads: Implementatie en testen.
Implementatie-infrastructuur
Betrouwbaarheid van de implementatie-infrastructuur, zoals buildagents en hun netwerk, is vaak net zo belangrijk als de runtimeresources van de workload.
Deze architectuur maakt gebruik van privé-buildagents om onbevoegde toegang te voorkomen die van invloed kan zijn op de beschikbaarheid van de toepassing.
Het wordt ten zeerste aanbevolen om isolatie tussen implementatiebronnen te onderhouden. Een implementatie-infrastructuur moet zijn gebonden aan uw workloadabonnementen voor die omgeving. Als u meerdere omgevingen in preproductieabonnementen gebruikt, maakt u een verdere scheiding door de toegang tot alleen die afzonderlijke omgevingen te beperken. Resources voor implementatie per regio kunnen worden beschouwd om de implementatie-infrastructuur betrouwbaarder te maken.
Implementatie zonder downtime
Updates voor de toepassing kunnen storingen veroorzaken. Het afdwingen van consistente implementaties verhoogt de betrouwbaarheid. Deze benaderingen worden aanbevolen:
- Volledig geautomatiseerde implementatiepijplijnen hebben.
- Implementeer updates in preproductieomgevingen op een schone stempel.
Zie Bedrijfskritieke implementatie- en testrichtlijnen voor meer informatie.
In de basislijnarchitectuur worden deze strategieën geïmplementeerd door de inrichting ongedaan te maken en vervolgens de stempel met elke update te verwijderen. In dit ontwerp is het volledig ongedaan maken van de inrichting niet mogelijk omdat het platformteam eigenaar is van bepaalde resources. Het implementatiemodel is dus gewijzigd.
Implementatiemodel
De basislijnarchitectuur maakt gebruik van het Blue-Green-model om toepassingsupdates te implementeren. Nieuwe stempels met wijzigingen worden naast bestaande stempels geïmplementeerd. Nadat het verkeer naar de nieuwe stempel is verplaatst, wordt de bestaande stempel vernietigd.
In dit geval is het opgegeven gekoppelde virtuele netwerk niet kortstondig. Het zegel is niet toegestaan om het virtuele netwerk of peering te maken met de regionale hub. U moet deze resources in elke implementatie opnieuw gebruiken.
Canary-model kan veilige implementatie bereiken met de optie om terug te draaien. Eerst wordt er een nieuwe stempel geïmplementeerd met codewijzigingen. De implementatiepijplijn verwijst naar het vooraf ingerichte virtuele netwerk en wijst subnetten toe, implementeert resources en voegt privé-eindpunten toe. Vervolgens wordt verkeer naar deze subnetten verplaatst in dit vooraf ingerichte virtuele netwerk.
Wanneer het bestaande stempel niet meer nodig is, worden alle stempelbronnen verwijderd door de pijplijn, met uitzondering van de resources die eigendom zijn van het platform. Het virtuele netwerk, diagnostische instellingen, peering, IP-adresruimte, DNS-configuratie en op rollen gebaseerd toegangsbeheer (RBAC) blijven behouden. Op dit moment heeft de stempel een schone status en is deze klaar voor de volgende nieuwe implementatie.
Azure-beleid voor DINE (deploy-if-not-exists)
Azure-toepassingslandingszones hebben mogelijk DINE (deploy-if-not-exists) Azure-beleid. Deze controles zorgen ervoor dat geïmplementeerde resources voldoen aan bedrijfsstandaarden in landingszones voor toepassingen, zelfs wanneer ze eigendom zijn van het toepassingsteam. De implementatie en de uiteindelijke resourceconfiguratie komen mogelijk niet overeen.
Inzicht in de impact van alle DINE-beleidsregels die worden toegepast op uw resources. Als er wijzigingen in de resourceconfiguratie zijn, moet u de intentie van het beleid opnemen in uw declaratieve implementaties vroeg in de ontwikkelingscyclus van de workload. Anders kan er een afwijking ontstaan die leidt tot verschillen tussen de gewenste status en de geïmplementeerde status.
Toegangsbeheer voor implementatieabonnementen
Behandel abonnementsgrenzen als uw beveiligingsgrenzen om de straalstraal te beperken. Bedreigingen kunnen van invloed zijn op de betrouwbaarheid van de workload.
Platformteam
- Geef de toepassingsteams autorisatie voor bewerkingen met machtigingen binnen het bereik van het abonnement voor de landingszone van de toepassing.
Als u meerdere implementaties binnen één abonnement uitvoert, heeft een inbreuk invloed op beide implementaties. Het wordt aanbevolen om implementaties in toegewezen abonnementen uit te voeren. Maak service-principals per omgeving voor het onderhouden van logische scheiding.
De service-principal moet autonomie bieden ten opzichte van workloadresources. Er moeten ook beperkingen gelden die overmatige manipulatie van de platformbronnen binnen het abonnement voorkomen.
Overwegingen voor bewaking
Het Azure-landingszoneplatform biedt gedeelde waarneembaarheidsbronnen als onderdeel van de beheerabonnementen. Het gecentraliseerde operations-team moedigt de toepassingsteams aan om het federatieve model te gebruiken. Maar voor bedrijfskritieke workloads wordt één centraal waarneembaarheidsarchief niet aanbevolen, omdat dit mogelijk een single point of failure kan zijn. Bedrijfskritieke workloads genereren ook telemetrie die mogelijk niet van toepassing of actie kan worden uitgevoerd voor gecentraliseerde operationele teams.
Daarom wordt een autonome benadering voor bewaking ten zeerste aanbevolen. Workloadoperators zijn uiteindelijk verantwoordelijk voor de bewaking en moeten toegang hebben tot alle gegevens die de algehele status vertegenwoordigen.
De basislijnarchitectuur volgt die benadering en wordt voortgezet in deze referentiearchitectuur. Azure Log Analytics en Azure-toepassing Insights worden regionaal en wereldwijd geïmplementeerd om resources in deze bereiken te bewaken. Het samenvoegen van logboeken, het maken van dashboards en waarschuwingen valt binnen het bereik van uw team. Profiteer van de mogelijkheden van Azure Diagnostics waarmee metrische gegevens en logboeken naar verschillende sinks worden verzonden om platformvereisten voor logboek- en metrische gegevensverzameling te ondersteunen.
Statusmodel
Bedrijfskritieke ontwerpmethodologie vereist een systeemstatusmodel. Wanneer u een algemene statusscore definieert, neemt u landingszonestromen in het bereik van het platform op waarvoor de toepassing afhankelijk is. Bouw logboek-, status- en waarschuwingsquery's om bewaking tussen werkruimten uit te voeren.
Platformteam
RBAC-query's (op rollen gebaseerd toegangsbeheer) verlenen en logboeksinks lezen voor relevante platformresources die worden gebruikt in het kritieke pad van de bedrijfskritieke toepassing.
Ondersteuning voor het organisatiedoel van betrouwbaarheid voor de bedrijfskritieke workload door het toepassingsteam voldoende toestemming te geven om hun activiteiten uit te voeren.
In deze architectuur bevat het statusmodel logboeken en metrische gegevens van resources die zijn ingericht in Verbinding maken iviteitsabonnement. Als u dit ontwerp uitbreidt om een on-premises resource zoals een database te bereiken, moet het statusmodel netwerkconnectiviteit met die resource bevatten, inclusief beveiligingsgrenzen zoals virtuele netwerkapparaten in Azure en on-premises. Deze informatie is belangrijk om snel de hoofdoorzaak te bepalen en de betrouwbaarheidsimpact op te lossen. Is de fout bijvoorbeeld opgetreden bij het routeren naar de database of is er een probleem met de database?
Raadpleeg: Goed ontworpen bedrijfskritieke workloads: statusmodellering.
Integratie met het door het platform geleverde beleid en regels
Het abonnement voor de landingszone van de toepassing neemt Azure-beleid, Azure Network Manager-regels en andere besturingselementen van de beheergroep over. Het platformteam biedt deze kaders.
Voor implementaties is dit niet afhankelijk van het door het platform geleverde beleid, omdat:
- Ze zijn niet ontworpen om tegemoet te komen aan de behoeften van afzonderlijke workloads.
- Het beleid en de regels worden mogelijk bijgewerkt of verwijderd buiten uw team en kunnen dus van invloed zijn op de betrouwbaarheid.
Het wordt ten zeerste aanbevolen om Azure-beleid binnen uw implementaties te maken en toe te wijzen. Deze inspanning kan leiden tot enige duplicatie, maar dat is acceptabel, gezien de mogelijke impact op de betrouwbaarheid van het systeem. Als er wijzigingen in het platformbeleid zijn, is het workloadbeleid nog steeds lokaal van kracht.
Platformteam
- Betrek het toepassingsteam bij het wijzigingsbeheerproces van beleidsregels naarmate deze zich ontwikkelen.
- Houd rekening met het beleid dat wordt gebruikt door het toepassingsteam. Evalueer of ze moeten worden toegevoegd aan de beheergroep.
Deze architectuur implementeren
De netwerkaspecten van deze architectuur worden geïmplementeerd in de essentiële Verbinding maken implementatie.
Notitie
De Verbinding maken ed implementatie is bedoeld om een bedrijfskritieke workload te illustreren die afhankelijk is van organisatieresources, integreert met andere workloads en gebruikmaakt van gedeelde services. Bij de implementatie wordt ervan uitgegaan dat er al een Verbinding maken iviteitsabonnement bestaat.
Volgende stappen
Bekijk het ontwerpgebied voor netwerken en connectiviteit in Azure Well-architected Framework.
Verwante resources
Naast de Azure-services die worden gebruikt in de basislijnarchitectuur, zijn deze services belangrijk voor deze architectuur.