Deze browser wordt niet meer ondersteund.
Upgrade naar Microsoft Edge om te profiteren van de nieuwste functies, beveiligingsupdates en technische ondersteuning.
Dit artikel bevat een sleutelpatroon voor bedrijfskritieke architecturen in Azure. Pas dit patroon toe wanneer u het ontwerpproces start en selecteer vervolgens onderdelen die het meest geschikt zijn voor uw zakelijke vereisten. Het artikel raadt een north star ontwerpbenadering aan en bevat andere voorbeelden met algemene technologieonderdelen.
U wordt aangeraden de belangrijkste ontwerpgebiedente evalueren, de kritieke gebruikers- en systeemstromen te definiëren die gebruikmaken van de onderliggende onderdelen, en een matrix met Azure-resources en hun configuratie te ontwikkelen, waarbij u rekening houdt met de volgende kenmerken.
| Karakteristiek | Overwegingen |
|---|---|
| Levensduur | Wat is de verwachte levensduur van de resource ten opzichte van andere resources in de oplossing? Moet het middel de levensduur van het hele systeem of de hele regio overleven of delen, of moet het tijdelijk zijn? |
| Staat | Welke invloed heeft de persistente status op deze laag op betrouwbaarheid of beheerbaarheid? |
| Bereiken | Is het nodig dat de bron wereldwijd wordt gedistribueerd? Kan de resource communiceren met andere resources, wereldwijd of binnen die regio? |
| Afhankelijkheden | Wat zijn de afhankelijkheden van andere resources? |
| Schaallimieten | Wat is de verwachte doorvoer voor die resource? Hoeveel capaciteit wordt door de bron geleverd om aan die vraag te voldoen? |
| Beschikbaarheid/herstel na noodgevallen | Wat is de impact op de beschikbaarheid van een noodgeval op deze laag? Zou dit leiden tot een systemische storing of alleen een gelokaliseerd capaciteits- of beschikbaarheidsprobleem? |
Belangrijk
Dit artikel maakt deel uit van de Azure Well-Architected bedrijfskritische workloads serie. Als u niet bekend bent met deze reeks, raden we u aan om te beginnen met wat is een bedrijfskritieke workload?
Bepaalde resources worden wereldwijd gedeeld door resources die in elke regio zijn uitgerold. Veelvoorkomende voorbeelden zijn resources die worden gebruikt voor het distribueren van verkeer over meerdere regio's, het opslaan van een permanente status voor de hele toepassing en het bewaken van deze resources.
| Karakteristiek | Overwegingen |
|---|---|
| Levensduur | Deze resources zullen naar verwachting een lange levensduur hebben (niet-tijdelijk). De levensduur overschrijdt die van het systeem of zelfs meer. Vaak worden de resources beheerd met updates van gegevens- en besturingsvlakken ter plaatse, uitgaande van hun ondersteuning van updatebewerkingen zonder downtime. |
| Staat | Omdat deze resources ten minste de levensduur van het systeem hebben, is deze laag vaak verantwoordelijk voor het opslaan van de globale, geo-gerepliceerde status. |
| Bereiken | De resources moeten wereldwijd worden gedistribueerd en gerepliceerd naar de regio's die deze resources hosten. Het wordt aanbevolen dat deze resources communiceren met regionale of andere resources met lage latentie en de gewenste consistentie. |
| Afhankelijkheden | De resources moeten afhankelijkheden van regionale resources voorkomen omdat hun onbeschikbaarheid een oorzaak kan zijn van globale fouten. Certificaten of geheimen die in één kluis worden bewaard, kunnen bijvoorbeeld globale gevolgen hebben als er een regionale fout optreedt in de kluis. |
| Schaallimieten | Vaak zijn deze resources singleton-instanties in het systeem en moeten ze kunnen schalen zodat ze de doorvoer van het systeem als geheel kunnen verwerken. |
| Beschikbaarheid/herstel na noodgevallen | Regionale en stempelbronnen kunnen wereldwijde bronnen gebruiken. Het is cruciaal dat wereldwijde middelen zijn geconfigureerd met hoge beschikbaarheid en disaster recovery voor de gezondheid van het hele systeem. |
De stempel bevat de applicatie en middelen die betrokken zijn bij het voltooien van zakelijke transacties. Een stempel komt meestal overeen met een implementatie in een Azure-regio. Hoewel een regio meer dan één stempel kan hebben.
| Karakteristiek | Overwegingen |
|---|---|
| Levensduur | Naar verwachting hebben de resources een korte levensduur (kortstondig) met de bedoeling dat ze dynamisch kunnen worden toegevoegd en verwijderd, terwijl regionale resources buiten de stempel blijven bestaan. De tijdelijke aard is nodig om gebruikers meer flexibiliteit, schaal en nabijheid te bieden. |
| Staat | Omdat stempels kortstondig zijn en bij elke implementatie worden vernietigd, moet een stempel zoveel mogelijk staatloos zijn. |
| Bereiken | Kan communiceren met regionale en wereldwijde resources. Echter, communicatie met andere regio's of andere stempels moet worden vermeden. |
| Afhankelijkheden | De stempelbronnen moeten onafhankelijk zijn. Naar verwachting hebben ze regionale en globale afhankelijkheden, maar moeten ze niet afhankelijk zijn van onderdelen in andere stempels in dezelfde of andere regio's. |
| Schaallimieten | De doorvoer wordt tot stand gebracht door testen. De doorvoer van de algehele zegel is beperkt tot de minst presterende resource. De doorvoer van zegels moet een schatting maken van het hoge vraagniveau dat wordt veroorzaakt door een failover naar een andere stempel. |
| Beschikbaarheid/herstel na noodgevallen | Vanwege de tijdelijke aard van stempels wordt herstel na noodgevallen uitgevoerd door de stempel opnieuw te implementeren. Als middelen zich in een ongezonde toestand bevinden, kan de stempel als geheel worden vernietigd en opnieuw worden ingezet. |
Een systeem kan resources bevatten die zijn geïmplementeerd in de regio, maar langer meegaan dan de stempelresources. Bijvoorbeeld waarneembaarheidsbronnen die resources op regionaal niveau bewaken, inclusief de stempels.
| Karakteristiek | Overweging |
|---|---|
| Levensduur | De middelen hebben dezelfde levensduur als de regio en overleven de stempelbronnen. |
| Staat | Status die is opgeslagen in een regio, kan niet langer duren dan de levensduur van de regio. Als de status moet worden gedeeld tussen regio's, kunt u overwegen een globaal gegevensarchief te gebruiken. |
| Bereiken | De resources hoeven niet wereldwijd te worden gedistribueerd. Directe communicatie met andere regio's moet ten koste van alle kosten worden vermeden. |
| Afhankelijkheden | De middelen kunnen afhankelijk zijn van globale middelen, maar niet van stempelmiddelen, omdat stempels bedoeld zijn om een korte levensduur te hebben. |
| Schaallimieten | Bepaal de schaallimiet van regionale resources door alle stempels binnen de regio te combineren. |
Deze basislijnvoorbeelden fungeren als de aanbevolen north star-architectuur voor bedrijfskritieke toepassingen. De basislijn raadt ten zeerste aan om containerisatie uit te voeren en een containerorchestrator te gebruiken voor het toepassingsplatform. De basislijn maakt gebruik van AKS (Azure Kubernetes Service).
Raadpleeg Well-Architected bedrijfskritieke workloads: Containerisatie.
Als u net begint met uw bedrijfskritieke traject, gebruikt u deze architectuur als referentie. De werkbelasting wordt geopend via een openbaar eindpunt en vereist geen privénetwerkconnectiviteit met andere bedrijfsresources.
Deze architectuur bouwt voort op de basislijnarchitectuur. Het ontwerp is uitgebreid om strikte netwerkcontroles te bieden om onbevoegde openbare toegang van internet tot de workloadresources te voorkomen.
Deze architectuur is geschikt als u de workload implementeert in een bedrijfsinstallatie waarbij integratie binnen een bredere organisatie vereist is. De workload maakt gebruik van gecentraliseerde gedeelde services, heeft on-premises connectiviteit nodig en kan worden geïntegreerd met andere workloads binnen de onderneming. Het wordt geïmplementeerd in een Azure-landingszoneabonnement dat wordt overgenomen van de Corp.-beheergroep.
Deze architectuur breidt de basislijnverwijzing uit door App Services te beschouwen als de primaire toepassing die als hosttechnologie fungeert, waardoor een eenvoudig te gebruiken omgeving wordt geboden voor containerimplementaties.
U wordt aangeraden de opgegeven ontwerprichtlijnen te gebruiken om door de belangrijkste ontwerpbeslissingen te navigeren om een optimale oplossing te bereiken. Voor informatie, zie Wat zijn de belangrijkste ontwerpgebieden?
Bekijk de aanbevolen procedures voor het ontwerpen van bedrijfskritieke toepassingsscenario's.