Den här referensarkitekturen ger vägledning för att distribuera en verksamhetskritisk arbetsbelastning som använder centraliserade delade tjänster, behöver lokal anslutning och integrerar med andra arbetsbelastningar i ett företag. Den här vägledningen är avsedd för en arbetsbelastningsägare som ingår i ett programteam i organisationen.
Du kan hamna i den här situationen när din organisation vill distribuera arbetsbelastningen i en Azure-programlandningszon som ärver Corp. Management-gruppen. Arbetsbelastningen förväntas integreras med företablerade delade resurser i Azure-plattformens landningszon som hanteras av centraliserade team.
Viktigt!
Vad är en Azure-landningszon? En programlandningszon är en Azure-prenumeration där arbetsbelastningen körs. Den är ansluten till organisationens delade resurser. Via den anslutningen har den åtkomst till den grundläggande infrastruktur som krävs för att köra arbetsbelastningen, till exempel nätverk, hantering av identitetsåtkomst, principer och övervakning. Plattformslandningszonerna är en samling olika prenumerationer, var och en med en specifik funktion. Till exempel tillhandahåller prenumerationen Anslut ivity centraliserad DNS-matchning, lokal anslutning och virtuella nätverksinstallationer (NVA) som är tillgängliga för användning av programteam.
Som arbetsbelastningsägare drar du nytta av att avlasta hanteringen av delade resurser till centrala team och fokusera på arbetsbelastningsutvecklingsarbetet. Organisationen drar nytta av att tillämpa konsekvent styrning och amortering av kostnader för flera arbetsbelastningar.
Vi rekommenderar starkt att du förstår begreppet Azure-landningszoner.
I den här metoden är maximal tillförlitlighet ett delat ansvar mellan dig och plattformsteamet. De centralt hanterade komponenterna måste vara mycket tillförlitliga för att en verksamhetskritisk arbetsbelastning ska fungera som förväntat. Du måste ha en betrodd relation med plattformsteamet så att otillgänglighetsproblem i de centraliserade tjänsterna, som påverkar arbetsbelastningen, minimeras på plattformsnivå. Men ditt team är ansvarigt för att driva krav med plattformsteamet för att uppnå dina mål.
Den här arkitekturen bygger på den verksamhetskritiska baslinjearkitekturen med nätverkskontroller. Vi rekommenderar att du bekantar dig med baslinjearkitekturen innan du fortsätter med den här artikeln.
Kommentar
Vägledningen stöds av ett exempelimplementering i produktionsklass som visar verksamhetskritisk programutveckling i Azure. Den här implementeringen kan användas som grund för ytterligare lösningsutveckling som ditt första steg mot produktion.
Viktiga designstrategier
Använd dessa strategier ovanpå den verksamhetskritiska baslinjen:
Kritisk sökväg
Alla komponenter i arkitekturen behöver inte vara lika tillförlitliga. Den kritiska sökvägen innehåller de komponenter som måste hållas funktionella så att arbetsbelastningen inte får någon stilleståndstid eller försämrade prestanda. Om du håller den sökvägen lean minimeras felpunkterna.
Livscykel för komponenter
Tänk på livscykeln för kritiska komponenter eftersom det påverkar ditt mål att uppnå nära noll nertid. Komponenter kan vara tillfälliga eller kortvariga resurser som kan skapas och förstöras efter behov. icke-tillfälliga eller långlivade resurser som delar livslängden med systemet eller regionen.
Externa beroenden
Minimera externa beroenden för komponenter och processer, vilket kan leda till felpunkter. Arkitekturen har resurser som ägs av olika team utanför ditt team. Dessa komponenter (om de är kritiska) är inom omfånget för den här arkitekturen.
Prenumerationstopologi
Azure-landningszoner innebär inte en enda prenumerationstopologi. Planera prenumerationens fotavtryck i förväg med ditt plattformsteam för att hantera arbetsbelastningens tillförlitlighetskrav i alla miljöer.
Autonom observerbarhet i den kritiska vägen
Ha dedikerade övervakningsresurser som gör det möjligt för teamet att snabbt köra frågor mot sin datainsamling (särskilt den kritiska sökvägen) och vidta åtgärder för åtgärder.
Arkitektur
Ladda ned en Visio-fil med den här arkitekturen.
Komponenterna i den här arkitekturen är samma som den verksamhetskritiska baslinjearkitekturen med nätverkskontroller. Beskrivningarna är korta för korthet. Om du behöver mer information kan du läsa de länkade artiklarna. Produktdokumentation om Azure-tjänster finns i Relaterade resurser.
Globala resurser
Dessa resurser finns i programlandningszonens prenumerationer. Globala resurser är icke-tillfälliga och delar systemets livslängd. Azure-tjänsterna och deras konfiguration förblir desamma som de globala baslinjeresurserna.
Regionala nätverksresurser
Dessa resurser finns i plattformsanslutningszonprenumerationer och prenumerationer på programlandningszoner. Baslinjearkitekturen distribuerar alla resurser som ägs av dig. I den här arkitekturen tillhandahålls dock nätverksresurser via prenumerationen Anslut ivity som en del av plattformens landningszon.
I den här artikeln finns avsnittet Regionalt nav för virtuellt nätverk .
Regionala stämpelresurser
Dessa resurser finns i programlandningszonens prenumerationer. Dessa resurser delar ingenting med andra resurser, förutom de globala resurserna.
De flesta Azure-tjänster och deras konfiguration förblir desamma som baslinjestämpelarkitekturen, förutom nätverksresurserna, som är företablerade av plattformsteamet.
I den här artikeln kan du läsa avsnittet Regionalt eker virtuellt nätverk .
Externa resurser
Arbetsbelastningen interagerar med lokala resurser. Vissa av dem är på den kritiska vägen för arbetsbelastningen, till exempel en lokal databas. Dessa resurser och kommunikationen med dem räknas in i det övergripande sammansatta serviceavtalet (SLA) för arbetsbelastningen. All kommunikation sker via prenumerationen Anslut ivity. Det finns andra externa resurser som arbetsbelastningen kan nå, men de anses inte vara kritiska.
Resurser för distributionspipeline
Bygg- och versionspipelines för ett verksamhetskritiskt program måste vara helt automatiserade för att garantera ett konsekvent sätt att distribuera en validerad stämpel. Dessa resurser förblir samma som pipelinen för baslinjedistribution.
Regionala övervakningsresurser
Dessa resurser finns i programlandningszonens prenumerationer. Övervakningsdata för globala resurser och regionala resurser lagras oberoende av varandra. Azure-tjänsterna och deras konfiguration förblir desamma som baslinjeövervakningsresurserna.
I den här artikeln finns avsnittet Övervakningsöverväganden .
Hanteringsresurser
För att få åtkomst till det privata beräkningsklustret och andra resurser använder den här arkitekturen privata byggagenter och instanser av virtuella jump box-datorer. Azure Bastion ger säker åtkomst till hopprutorna. Resurserna i stämplarna förblir desamma som baslinjehanteringsresurserna.
Nätverksöverväganden
I den här designen distribueras arbetsbelastningen i programmets landningszon och behöver anslutning till de federerade resurserna i plattformslandningszonen. Syftet kan vara att komma åt lokala resurser, kontrollera utgående trafik och så vidare.
Nätverkstopologi
Plattformsteamet bestämmer nätverkstopologin för hela organisationen. Topologin hub-spoke antas i den här arkitekturen. Ett alternativ kan vara Azure Virtual WAN.
Virtuellt nätverk för regional hubb
Prenumerationen Anslut ivity innehåller ett virtuellt hubbnätverk med resurser som delas av hela organisationen. Dessa resurser ägs och underhålls av plattformsteamet.
Ur ett verksamhetskritiskt perspektiv är det här nätverket icke-tillfälliga, och dessa resurser är på den kritiska vägen.
| Azure-resurs | Syfte |
|---|---|
| Azure ExpressRoute | Tillhandahåller privat anslutning från lokal till Azure-infrastruktur. |
| Azure Firewall | Fungerar som den NVA som inspekterar och begränsar utgående trafik. |
| Azure DNS | Ger namnmatchning mellan platser. |
| VPN gateway | Anslut s fjärranslutna organisationsgrenar via det offentliga Internet till Azure-infrastrukturen. Fungerar också som ett alternativ för säkerhetskopieringsanslutning för att lägga till återhämtning. |
Resurserna etableras i varje region och peer-kopplas till det virtuella ekernätverket (beskrivs härnäst). Se till att du förstår och godkänner uppdateringarna av NVA, brandväggsregler, routningsregler, ExpressRoute redundansväxla till VPN Gateway, DNS-infrastruktur och så vidare.
Kommentar
En viktig fördel med att använda den federerade hubben är att arbetsbelastningen kan integreras med andra arbetsbelastningar antingen i Azure eller lokalt genom att gå igenom de organisationshanterade nätverkshubbarna. Den här ändringen sänker även driftskostnaderna eftersom en del av ansvaret flyttas till plattformsteamet.
Virtuellt nätverk för regional eker
Programlandningszonen har minst två företablerade virtuella Azure-nätverk, per region, som refereras till av de regionala stämplarna. Dessa nätverk är inte tillfälliga. Den ena hanterar produktionstrafik och den andra är inriktad på vNext-distributionen. Med den här metoden kan du utföra tillförlitliga och säkra distributionsmetoder.
Drift virtuellt nätverk
Drifttrafiken isoleras i ett separat virtuellt nätverk. Det här virtuella nätverket är inte tillfälliga och du äger det här nätverket. Den här arkitekturen har samma design som baslinjearkitekturen med nätverkskontroller.
Det finns ingen peering mellan driftnätverket och ekernätverket. All kommunikation sker via privata länkar.
Delat ansvar
Ha en tydlig förståelse för vilket team som är ansvarigt för varje designelement i arkitekturen. Här är några viktiga områden.
Planering av IP-adress
När du har uppskattat den storlek som krävs för att köra din arbetsbelastning arbetar du med plattformsteamet så att de kan etablera nätverket på rätt sätt.
Plattformsteam
Ange distinkta adresser för virtuella nätverk som deltar i peerings. Överlappande adresser, till exempel lokala nätverk och arbetsbelastningsnätverk, kan orsaka störningar som leder till avbrott.
Allokera IP-adressutrymmen som är tillräckligt stora för att innehålla körnings- och distributionsresurser, hantera redundans och stödja skalbarhet.
Det företablerade virtuella nätverket och peerings måste kunna stödja den förväntade tillväxten av arbetsbelastningen. Du måste utvärdera den tillväxten med plattformsteamet regelbundet. Mer information finns i Anslut ivity to Azure ( Anslut ivity to Azure ).
Regional ekernätverksundering
Du ansvarar för att allokera undernät i det regionala virtuella nätverket. Undernäten och resurserna i dem är tillfälliga. Adressutrymmet bör vara tillräckligt stort för att hantera potentiell tillväxt.
Undernät för privata slutpunkter När trafiken når det virtuella nätverket begränsas kommunikationen med PaaS-tjänster i nätverket med hjälp av privata slutpunkter, precis som baslinjearkitekturen med nätverkskontroller. Dessa slutpunkter placeras i ett dedikerat undernät. Privata IP-adresser till de privata slutpunkterna tilldelas från det undernätet.
Klusterundernät Skalbarhetskraven för arbetsbelastningen påverkar hur mycket adressutrymme som ska allokeras för undernäten. När AKS-noder och poddar skalas ut tilldelas IP-adresser från det här undernätet.
Nätverkssegmentering
Upprätthålla rätt segmentering så att arbetsbelastningens tillförlitlighet inte komprometteras av obehörig åtkomst.
Den här arkitekturen använder nätverkssäkerhetsgrupper (NSG:er) för att begränsa trafiken mellan undernät och prenumerationen Anslut ivity. NSG:er använder ServiceTags för de tjänster som stöds.
Plattformsteam
Framtvinga användningen av NSG:er via Azure Network Manager-principer.
Tänk på arbetsbelastningsdesignen. Det finns ingen direkt trafik mellan stämplarna. Det finns inte heller flöden mellan regioner. Om dessa sökvägar behövs måste trafiken flöda genom Anslut ivity-prenumerationen.
Förhindra onödig hubbtrafik från andra arbetsbelastningar till den verksamhetskritiska arbetsbelastningen.
Utgående trafik från regionala stämplar
All utgående trafik från varje regionalt ekernätverk dirigeras via den centraliserade Azure Firewall i det regionala hubbnätverket. Det fungerar som nästa hopp som inspekterar och sedan tillåter eller nekar trafik.
Plattformsteam
Skapa UDR:er för den anpassade vägen.
Tilldela Azure-principer som blockerar programteamet från att skapa undernät som inte har den nya routningstabellen.
Ge programteamet tillräckliga behörigheter för rollbaserad åtkomstkontroll (RBAC) så att de kan utöka vägarna baserat på arbetsbelastningens krav.
Redundans för flera regioner
Dina verksamhetskritiska arbetsbelastningar måste distribueras i flera regioner för att klara regionala avbrott. Arbeta med plattformsteamet för att se till att infrastrukturen är tillförlitlig.
Plattformsteam
Distribuera centraliserade nätverksresurser per region. Den verksamhetskritiska designmetoden kräver regional isolering.
Arbeta med programteamet för att hitta dolda regionala beroenden så att en degraderad plattformsresurs i en region inte påverkar arbetsbelastningar i en annan region.
DNS-upplösning
Prenumerationen Anslut ivity tillhandahåller privata DNS-zoner. Den centraliserade metoden kanske dock inte beaktar de DNS-behov som kan vara specifika för ditt användningsfall. Etablera dina egna DNS-zoner och länka till den regionala stämpeln. Om programteamet inte äger DNS blir hanteringen av privata länkar utmanande för globala resurser, till exempel Azure Cosmos DB.
Plattformsteam
Delegera Azure Privat DNS-zonerna till programteamet för att täcka deras användningsfall.
För det regionala hubbnätverket anger du VÄRDET FÖR DNS-servrar till Standard (Azure-tillhandahållen) för att stödja privata DNS-zoner som hanteras av programteamet.
Miljödesignöverväganden
Det är en allmän praxis att placera arbetsbelastningar i separata miljöer för produktion, förproduktion och utveckling. Här följer några viktiga överväganden.
Hur upprätthålls isoleringen?
Produktionsmiljön måste isoleras från andra miljöer. Lägre miljöer bör också upprätthålla en isoleringsnivå. Undvik att dela programägda resurser mellan miljöer.
En produktionsmiljö krävs för globala, regionala och stämpelresurser som ägs av programteamet. Förproduktionsmiljöer, till exempel mellanlagring och integrering, behövs för att säkerställa att programmet testas i en miljö som simulerar produktion så mycket som möjligt. Utvecklingsmiljön bör vara en nedskalad version av produktionen.
Vilken är den förväntade livscykeln?
Förproduktionsmiljöer kan förstöras när valideringstesterna har slutförts. Vi rekommenderar att utvecklingsmiljöer delar livslängden för en funktion och förstörs när utvecklingen är klar. De åtgärder som utförs genom kontinuerlig integrering/kontinuerlig distribution (CI/CD) automatisering.
Vilka är kompromisserna?
Överväg kompromisserna mellan isolering av miljöer, hanteringskomplexitet och kostnadsoptimering.
Dricks
Alla miljöer bör vara beroende av produktionsinstanser av externa resurser, inklusive plattformsresurser. Till exempel en regional produktionshubb i prenumerationen Anslut ivity. Du kommer att kunna minimera deltat mellan förproduktions- och produktionsmiljöer.
Prenumerationstopologi för arbetsbelastningsinfrastruktur
Prenumerationer ges till dig av plattformsteamet. Beroende på antalet miljöer begär du flera prenumerationer för bara en arbetsbelastning. Beroende på typen av miljö kan vissa miljöer behöva dedikerade prenumerationer medan andra miljöer kan konsolideras till en prenumeration.
Oavsett, arbeta med plattformsteamet för att utforma en topologi som uppfyller det övergripande tillförlitlighetsmålet för arbetsbelastningen. Det finns fördelar med att dela de plattformsbaserade resurserna mellan miljöer i samma prenumeration eftersom det återspeglar produktionsmiljön.
Kommentar
Att använda flera prenumerationer för att innehålla miljöerna kan uppnå den isoleringsnivå som krävs. Landningszonprenumerationer ärvs från samma hanteringsgrupp. Därför säkerställs konsekvens med produktion för testning och validering.
Produktionsprenumeration
Det kan finnas resursbegränsningar för den prenumeration som du har fått. Om du samlokaliserar alla dessa resurser i en prenumeration kan du nå dessa gränser. Baserat på dina skalningsenheter och förväntad skala bör du överväga en mer distribuerad modell. Exempel:
En prenumeration som innehåller både Azure DevOps-byggagenter och globala resurser.
En prenumeration per region. Den innehåller de regionala resurserna, stämpelresurserna och hopprutorna för de regionala stämplarna.
Här är ett exempel på en prenumerationstopologi som används i den här arkitekturen.
Förproduktionsprenumeration
Minst en prenumeration krävs. Den kan köra många oberoende miljöer, men det rekommenderas att du har flera miljöer i dedikerade prenumerationer. Den här prenumerationen kan också omfattas av resursgränser som produktionsprenumerationen, som beskrivs ovan.
Utvecklingsprenumeration
Minst en prenumeration krävs. Den här prenumerationen kan omfattas av resursbegränsningar om den kör alla oberoende miljöer. Därför kan du begära flera prenumerationer. Att ha enskilda miljöer i sina dedikerade prenumerationer rekommenderas.
Försök att matcha produktionstopologin så mycket som möjligt.
Att tänka på vid distribuering
Misslyckade distributioner eller felaktiga versioner är vanliga orsaker till programfel. Testa ditt program (och nya funktioner) noggrant som en del av programmets livscykel. När du distribuerar arbetsbelastningen i en landningszon måste du integrera din design med de resurser och styrning som tillhandahålls av plattformen.
Se: Väldefinierade verksamhetskritiska arbetsbelastningar: Distribution och testning.
Distributionsinfrastruktur
Tillförlitligheten för distributionsinfrastrukturen, till exempel byggagenter och deras nätverk, är ofta lika viktig som arbetsbelastningens körningsresurser.
Den här arkitekturen använder privata byggagenter för att förhindra obehörig åtkomst som kan påverka programmets tillgänglighet.
Att upprätthålla isolering mellan distributionsresurser rekommenderas starkt. En distributionsinfrastruktur bör vara bunden till dina arbetsbelastningsprenumerationer för den miljön. Om du använder flera miljöer i förproduktionsprenumerationer skapar du ytterligare separation genom att begränsa åtkomsten till endast dessa enskilda miljöer. Distributionsresurser per region kan anses göra distributionsinfrastrukturen mer tillförlitlig.
Distribution med noll stilleståndstid
Uppdateringar till programmet kan orsaka avbrott. Att framtvinga konsekventa distributioner ökar tillförlitligheten. Dessa metoder rekommenderas:
- Ha fullständigt automatiserade distributionspipelines.
- Distribuera uppdateringar i förproduktionsmiljöer med en ren stämpel.
Mer information finns i Riktlinjer för verksamhetskritisk distribution och testning.
I baslinjearkitekturen implementeras dessa strategier genom att avetablera och sedan ta bort stämpeln med varje uppdatering. I den här designen är fullständig avetablering inte möjlig eftersom plattformsteamet äger vissa resurser. Distributionsmodellen ändrades därför.
Distributionsmodell
Baslinjearkitekturen använder blågrön modell för att distribuera programuppdateringar. Nya stämplar med ändringar distribueras tillsammans med befintliga stämplar. När trafiken har flyttats till den nya stämpeln förstörs den befintliga stämpeln.
I det här fallet är det angivna peer-kopplade virtuella nätverket icke-tillfälliga. Stämpeln får inte skapa det virtuella nätverket eller peering till den regionala hubben. Du måste återanvända dessa resurser i varje distribution.
Kanariemodell kan uppnå säker distribution med alternativet att återställa. Först distribueras en ny stämpel med kodändringar. Distributionspipelinen refererar till det företablerade virtuella nätverket och allokerar undernät, distribuerar resurser, lägger till privata slutpunkter. Sedan flyttas trafiken till dessa undernät i det här företablerade virtuella nätverket.
När den befintliga stämpeln inte längre krävs tas alla stämpelresurser bort av pipelinen, förutom de plattformsägda resurserna. Det virtuella nätverket, diagnostikinställningar, peering, IP-adressutrymme, DNS-konfiguration och rollbaserad åtkomstkontroll (RBAC) bevaras. Nu är stämpeln i ett rent tillstånd och redo för nästa nya distribution.
DINE(deploy-if-not-exists) Azure-principer
Azure-programlandningszoner kan ha DINE-principer (deploy-if-not-exists). Dessa kontroller säkerställer att distribuerade resurser uppfyller företagets standarder i programlandningszoner, även när de ägs av programteamet. Det kan uppstå ett matchningsfel mellan distributionen och den slutliga resurskonfigurationen.
Förstå effekten av alla DINE-principer som ska tillämpas på dina resurser. Om det finns ändringar i resurskonfigurationen bör du införliva avsikten med principerna i dina deklarativa distributioner tidigt i arbetsbelastningens utvecklingscykel. Annars kan det finnas en driftavdrift som leder till delta mellan önskat tillstånd och det distribuerade tillståndet.
Åtkomsthantering för distributionsprenumeration
Behandla prenumerationsgränser som dina säkerhetsgränser för att begränsa explosionsradien. Hot kan påverka arbetsbelastningens tillförlitlighet.
Plattformsteam
- Ge programteamen auktorisering för åtgärder med behörigheter som är begränsade till programmets landningszonprenumeration.
Om du kör flera distributioner i en enda prenumeration påverkar ett intrång båda distributionerna. Vi rekommenderar att du kör distributioner i dedikerade prenumerationer. Skapa tjänstens huvudnamn per miljö för att upprätthålla logisk separation.
Tjänstens huvudnamn bör ge oberoende över arbetsbelastningsresurser. Dessutom bör det finnas begränsningar som förhindrar överdriven manipulering av plattformsresurserna i prenumerationen.
Övervakningsöverväganden
Azure-landningszonens plattform tillhandahåller delade observerbarhetsresurser som en del av hanteringsprenumerationerna. Det centraliserade driftsteamet uppmuntrar programteamen att använda den federerade modellen. Men för verksamhetskritiska arbetsbelastningar rekommenderas inte ett enda centraliserat observerbarhetslager eftersom det kan vara en enda felpunkt. Verksamhetskritiska arbetsbelastningar genererar också telemetri som kanske inte är tillämpligt eller kan användas för centraliserade driftsteam.
Därför rekommenderas en autonom metod för övervakning. Arbetsbelastningsoperatorer ansvarar slutligen för övervakningen och måste ha åtkomst till alla data som representerar den övergripande hälsan.
Baslinjearkitekturen följer den metoden och fortsätter i den här referensarkitekturen. Azure Log Analytics och Azure Application Insights distribueras regionalt och globalt för att övervaka resurser i dessa omfång. Att aggregera loggar, skapa instrumentpaneler och aviseringar finns i omfånget för ditt team. Dra nytta av Azure Diagnostics-funktioner som skickar mått och loggar till olika mottagare för att stödja plattformskrav för logg- och måttinsamling.
Hälsomodell
Verksamhetskritisk designmetodik kräver en systemhälsomodell. När du definierar en övergripande hälsopoäng ska du inkludera plattformslandningszonflöden inom omfång som programmet är beroende av. Skapa logg-, hälso- och aviseringsfrågor för att utföra övervakning mellan arbetsytor.
Plattformsteam
Bevilja rollbaserad åtkomstkontrollfråga (RBAC) och läsloggmottagare för relevanta plattformsresurser som används i den kritiska sökvägen för det verksamhetskritiska programmet.
Stödja organisationens tillförlitlighetsmål mot den verksamhetskritiska arbetsbelastningen genom att ge programteamet tillräcklig behörighet för att utföra sin verksamhet.
I den här arkitekturen innehåller hälsomodellen loggar och mått från resurser som etablerats i Anslut ivity-prenumerationen. Om du utökar den här designen för att nå en lokal resurs, till exempel en databas, måste hälsomodellen innehålla nätverksanslutning till den resursen, inklusive säkerhetsgränser som virtuella nätverksinstallationer i Azure och lokalt. Den här informationen är viktig för att snabbt fastställa rotorsaken och åtgärda tillförlitlighetspåverkan. Inträffade till exempel felet när du försökte dirigera till databasen, eller uppstod det ett problem med databasen?
Se: Väldefinierade verksamhetskritiska arbetsbelastningar: Hälsomodellering.
Integrering med plattformsspecifika principer och regler
Prenumerationen för programlandningszonen ärver Azure-principer, Azure Network Manager-regler och andra kontroller från dess hanteringsgrupp. Plattformsteamet tillhandahåller dessa skyddsräcken.
För distributioner är du inte beroende av de principer som tillhandahålls av plattformen exklusivt, eftersom:
- De är inte designade för att täcka behoven hos enskilda arbetsbelastningar.
- Principer och regler kan uppdateras eller tas bort utanför ditt team, vilket kan påverka tillförlitligheten.
Vi rekommenderar starkt att du skapar och tilldelar Azure-principer i dina distributioner. Den här ansträngningen kan leda till viss duplicering, men det är acceptabelt med tanke på systemets potentiella inverkan på tillförlitligheten. Om det finns ändringar i plattformsprinciperna tillämpas arbetsbelastningsprinciperna fortfarande lokalt.
Plattformsteam
- Involvera programteamet i ändringshanteringsprocessen för principer när de utvecklas.
- Var medveten om de principer som används av programteamet. Utvärdera om de ska läggas till i hanteringsgruppen.
Distribuera den här arkitekturen
Nätverksaspekterna i den här arkitekturen implementeras i den verksamhetskritiska Anslut implementeringen.
Kommentar
Den Anslut implementeringen är avsedd att illustrera en verksamhetskritisk arbetsbelastning som förlitar sig på organisationsresurser, integrerar med andra arbetsbelastningar och använder delade tjänster. Implementeringen förutsätter att det redan finns en Anslut ivity-prenumeration.
Nästa steg
Granska designområdet för nätverk och anslutningar i Azure Well-architected Framework.
Relaterade resurser
Förutom de Azure-tjänster som används i baslinjearkitekturen är dessa tjänster viktiga för den här arkitekturen.