Azure har många alternativ för att organisera dina resurser. I en lösning med flera klientorganisationer finns det specifika kompromisser att tänka på när du planerar din resursorganisationsstrategi. I den här artikeln granskar vi två kärnelement för att organisera dina Azure-resurser: klientisolering och utskalning över flera resurser. Vi beskriver några vanliga distributionsmetoder som kan stödja olika modeller för klientisolering. Vi beskriver också hur du arbetar med Azures resursgränser och kvoter och hur du skalar din lösning utöver dessa gränser.
Viktiga överväganden och krav
Krav för klientisolering
När du distribuerar en lösning för flera klienter i Azure måste du bestämma om du ska ägna resurser åt varje klientorganisation eller dela resurser mellan flera klienter. I de olika metoderna för flera innehavare och tjänstespecifika vägledningsavsnitt i den här serien beskriver vi alternativen och kompromisserna för många resurskategorier. I allmänhet finns det en rad alternativ för klientisolering. Mer information om hur du bestämmer dig för din isoleringsmodell finns i Innehavarmodeller att överväga för en lösning med flera klientorganisationer.
Skala
De flesta Azure-resurser, samt resursgrupper och prenumerationer, inför gränser som kan påverka din förmåga att skala. Du kan behöva överväga att skala ut eller lagra packning för att uppfylla ditt planerade antal klienter eller din planerade systembelastning.
Om du med säkerhet vet att du inte kommer att växa till ett stort antal klienter eller till en hög belastning ska du inte överanvända din utskalningsplan. Men om du planerar att din lösning ska växa bör du noga överväga din utskalningsplan. Se till att du skapar för skalning genom att följa riktlinjerna i den här artikeln.
Om du har en automatiserad distributionsprocess och behöver skala över resurser ska du bestämma hur du ska distribuera och tilldela klienter över flera resursinstanser. Hur identifierar du till exempel att du närmar dig det antal klienter som kan tilldelas till en specifik resurs? Planerar du att distribuera nya resurser precis i tid för när du behöver dem? Eller distribuerar du en pool med resurser i förväg så att de är redo att användas när du behöver dem?
Dricks
I de tidiga stadierna av design och utveckling kanske du inte väljer att implementera automatiserade utskalningsprocesser. Du bör fortfarande överväga och tydligt dokumentera de processer som krävs för att skala när du växer. Genom att dokumentera processerna gör du det enklare för dig själv att automatisera dem om behovet uppstår i framtiden.
Det är också viktigt att undvika att göra några antaganden i koden och konfigurationen som kan begränsa din skalbarhet. Du kan till exempel behöva skala ut till flera lagringskonton i framtiden, så när du skapar programnivån ser du till att den dynamiskt kan växla det lagringskonto som den ansluter till baserat på den aktiva klientorganisationen.
Metoder och mönster att tänka på
Isolering av klientorganisation
Azure-resurser distribueras och hanteras via en hierarki. De flesta resurser distribueras till resursgrupper som finns i prenumerationer. Hanteringsgrupper grupperar prenumerationer logiskt tillsammans. Alla dessa hierarkiska lager är associerade med en Microsoft Entra-klientorganisation.
När du bestämmer hur du distribuerar resurser för varje klientorganisation kan du isolera på olika nivåer i hierarkin. Varje alternativ är giltigt för vissa typer av lösningar för flera klienter och har fördelar och kompromisser. Det är också vanligt att kombinera metoder med olika isoleringsmodeller för olika komponenter i en lösning.
Isolering inom en delad resurs
Du kan välja att dela en Azure-resurs mellan flera klienter och köra alla deras arbetsbelastningar på en enda instans. Läs den tjänstspecifika vägledningen för de Azure-tjänster som du använder för att förstå eventuella specifika överväganden eller alternativ som kan vara viktiga.
När du kör enskilda instanser av en resurs måste du överväga tjänstbegränsningar, prenumerationsgränser eller kvoter som kan nås när du skalar. Det finns till exempel ett maximalt antal noder som stöds av ett AKS-kluster (Azure Kubernetes Service) och det finns en övre gräns för antalet transaktioner per sekund som stöds av ett lagringskonto. Fundera på hur du skalar till flera delade resurser när du närmar dig dessa gränser.
Du måste också se till att programkoden är fullt medveten om flera klientorganisationer och att den begränsar åtkomsten till data för en specifik klientorganisation.
Som en illustration av metoden för delad resurs antar vi att Contoso skapar ett SaaS-program med flera klientorganisationer som innehåller ett webbprogram, en databas och ett lagringskonto. De kan välja att distribuera delade resurser för att betjäna alla sina kunder. I följande diagram delas en enda uppsättning resurser av alla kunder.
Avgränsa resurser i en resursgrupp
Du kan också distribuera dedikerade resurser för varje klientorganisation. Du kan distribuera en hel kopia av din lösning för en enda klientorganisation. Eller så kan du dela vissa komponenter mellan klientorganisationer medan andra komponenter är dedikerade till en specifik klientorganisation. Den här metoden kallas horisontell partitionering.
Vi rekommenderar att du använder resursgrupper för att hantera resurser med samma livscykel. I vissa system med flera klienter är det klokt att distribuera resurser för flera klienter till en enskild resursgrupp eller en uppsättning resursgrupper.
Det är viktigt att du överväger hur du distribuerar och hanterar dessa resurser, inklusive om distributionen av klientspecifika resurser initieras av din distributionspipeline eller ditt program. Du måste också ta reda på hur du tydligt identifierar att specifika resurser är relaterade till specifika klienter. Överväg att använda en tydlig strategi för namngivningskonventioner, resurstaggar eller en klientkatalogdatabas.
Det är en bra idé att använda separata resursgrupper för de resurser som du delar mellan flera klienter och de resurser som du distribuerar för enskilda klientorganisationer. För vissa resurser begränsar Azure dock antalet resurser av en enda typ som kan distribueras till en resursgrupp. Den här gränsen innebär att du kan behöva skala över flera resursgrupper när du växer.
Anta att Contoso har tre kunder (klienter): Adventure Works, Fabrikam och Tailwind. De kan välja att dela webbprogrammet och lagringskontot mellan de tre klientorganisationer och sedan distribuera enskilda databaser för varje klientorganisation. Följande diagram visar en resursgrupp som innehåller delade resurser och en resursgrupp som innehåller varje klientorganisations databas.
Avgränsa resursgrupper i en prenumeration
När du distribuerar en uppsättning resurser för varje klientorganisation bör du överväga att använda dedikerade klientspecifika resursgrupper. När du till exempel följer mönstret Distributionsstämplar ska varje stämpel distribueras till en egen resursgrupp. Du kan överväga att distribuera flera klientspecifika resursgrupper till en delad Azure-prenumeration, vilket gör att du enkelt kan konfigurera principer och åtkomstkontrollregler.
Du kan välja att skapa en uppsättning resursgrupper för varje klientorganisation och även delade resursgrupper för alla delade resurser.
När du distribuerar klientspecifika resursgrupper till delade prenumerationer bör du vara medveten om det maximala antalet resursgrupper i varje prenumeration och andra begränsningar på prenumerationsnivå som gäller för de resurser som du distribuerar. När du närmar dig dessa gränser kan du behöva skala över flera prenumerationer.
I vårt exempel kan Contoso välja att distribuera en stämpel för var och en av sina kunder och placera stämplarna i dedikerade resursgrupper i en enda prenumeration. I följande diagram skapas en prenumeration, som innehåller tre resursgrupper, för varje kund.
Separata prenumerationer
Genom att distribuera klientspecifika prenumerationer kan du helt isolera klientspecifika resurser. Dessutom, eftersom de flesta kvoter och gränser gäller inom en prenumeration, säkerställer användning av en separat prenumeration per klientorganisation att varje klientorganisation har full användning av eventuella tillämpliga kvoter. För vissa typer av Azure-faktureringskonton kan du programmatiskt skapa prenumerationer. Du kan också använda Azure-reservationer och Azure-sparplan för beräkning mellan prenumerationer.
Se till att du är medveten om antalet prenumerationer som du kan skapa. Det maximala antalet prenumerationer kan variera beroende på din kommersiella relation med Microsoft eller en Microsoft-partner, till exempel om du har ett enterprise-avtal.
Det kan dock vara svårare att begära kvotökningar när du arbetar i ett stort antal prenumerationer. Kvot-API:et tillhandahåller ett programmatiskt gränssnitt för vissa resurstyper. För många resurstyper måste dock kvotökningar begäras genom att ett supportärende initieras. Det kan också vara svårt att arbeta med Azure-supportavtal och supportärenden när du arbetar med många prenumerationer.
Överväg att gruppera dina klientspecifika prenumerationer i en hanteringsgruppshierarki , så att du enkelt kan hantera regler och principer för åtkomstkontroll.
Anta till exempel att Contoso bestämde sig för att skapa separata Azure-prenumerationer för var och en av sina tre kunder, enligt följande diagram. Varje prenumeration innehåller en resursgrupp med den fullständiga uppsättningen resurser för kunden.
Varje prenumeration innehåller en resursgrupp med den fullständiga uppsättningen resurser för kunden.
De använder en hanteringsgrupp för att förenkla hanteringen av sina prenumerationer. Genom att inkludera Produktion i hanteringsgruppens namn kan de tydligt skilja alla produktionsklienter från icke-produktions- eller testklientorganisationer. Icke-produktionsklienter skulle ha olika regler och principer för Åtkomstkontroll i Azure.
Alla deras prenumerationer är associerade med en enda Microsoft Entra-klientorganisation. Att använda en enda Microsoft Entra-klientorganisation innebär att Contoso-teamets identiteter, inklusive användare och tjänstens huvudnamn, kan användas i hela azure-egendomen.
Avgränsa prenumerationer i separata Microsoft Entra-klienter
Du kan också skapa enskilda Microsoft Entra-klienter manuellt för var och en av dina klienter eller distribuera dina resurser till prenumerationer i dina kunders Microsoft Entra-klientorganisationer. Att arbeta med flera Microsoft Entra-klienter gör det dock svårare att autentisera, hantera rolltilldelningar, tillämpa globala principer och utföra många andra hanteringsåtgärder.
Varning
Vi rekommenderar att du inte skapar flera Microsoft Entra-klienter för de flesta lösningar med flera klienter. Att arbeta med Microsoft Entra-klienter ger extra komplexitet och minskar möjligheten att skala och hantera dina resurser. Vanligtvis används den här metoden endast av hanterade tjänstleverantörer (MSP: er), som driver Azure-miljöer för sina kunders räkning.
Innan du försöker distribuera flera Microsoft Entra-klienter bör du överväga om du kan uppfylla dina krav genom att använda hanteringsgrupper eller prenumerationer i en enda klientorganisation i stället.
I situationer där du behöver hantera Azure-resurser i prenumerationer som är knutna till flera Microsoft Entra-klienter bör du överväga att använda Azure Lighthouse för att hantera dina resurser i dina Microsoft Entra-klienter.
Contoso kan till exempel skapa separata Microsoft Entra-klienter och separata Azure-prenumerationer för var och en av sina kunder, enligt följande diagram.
En Microsoft Entra-klient har konfigurerats för var och en av Contosos klienter, som innehåller en prenumeration och de resurser som krävs. Azure Lighthouse är anslutet till varje Microsoft Entra-klientorganisation.
Paketering av lagerplatser
Oavsett din resursisoleringsmodell är det viktigt att tänka på när och hur din lösning skalar ut över flera resurser. Du kan behöva skala dina resurser när belastningen på systemet ökar, eller när antalet klienter växer. Överväg att paketera lagerplatser för att distribuera ett optimalt antal resurser för dina behov.
Dricks
I många lösningar är det enklare att skala ihop hela resursuppsättningen i stället för att skala resurser individuellt. Överväg att följa mönstret Distributionsstämplar.
Resursgränser
Azure-resurser har gränser och kvoter som måste beaktas i din lösningsplanering. Resurser kan till exempel ha stöd för ett maximalt antal samtidiga begäranden eller klientspecifika konfigurationsinställningar.
Hur du konfigurerar och använder varje resurs påverkar även resursens skalbarhet. Anta till exempel att programmet, med tanke på en viss mängd beräkningsresurser, kan svara på ett definierat antal transaktioner per sekund. Utöver detta kan du behöva skala ut. Prestandatestning hjälper dig att identifiera den punkt där dina resurser inte längre uppfyller dina krav.
Kommentar
Principen för skalning till flera resurser gäller även när du arbetar med tjänster som stöder flera instanser.
Azure App Service stöder till exempel utskalning av antalet instanser av din plan, men det finns gränser för hur långt du kan skala en enda plan. I en storskalig app för flera klientorganisationer kan du överskrida dessa gränser och behöva distribuera fler App Service-planer för att matcha din tillväxt.
När du delar en del av dina resurser mellan klientorganisationer bör du först fastställa antalet klienter som resursen stöder när den konfigureras enligt dina krav. Distribuera sedan så många resurser som du behöver för att hantera det totala antalet klienter.
Anta till exempel att du distribuerar Azure Application Gateway som en del av en SaaS-lösning med flera klientorganisationer. Du granskar programdesignen, testar programgatewayens prestanda under belastning och granskar dess konfiguration. Sedan fastställer du att en enda application gateway-resurs kan delas mellan 100 kunder. Enligt organisationens tillväxtplan förväntar du dig att registrera 150 kunder under ditt första år, så du måste planera att distribuera flera programgatewayer för att hantera den förväntade belastningen.
I föregående diagram finns det två programgatewayer. Den första gatewayen är dedikerad till kunder mellan 1 och 100 och den andra är dedikerad till kunder mellan 101 och 200.
Resursgrupps- och prenumerationsgränser
Oavsett om du arbetar med delade eller dedikerade resurser är det viktigt att ta hänsyn till begränsningar. Azure begränsar antalet resurser som kan distribueras till en resursgrupp och till en Azure-prenumeration. När du närmar dig dessa gränser måste du planera att skala över flera resursgrupper eller prenumerationer.
Anta till exempel att du distribuerar en dedikerad programgateway för var och en av dina kunder till en delad resursgrupp. För vissa resurser stöder Azure distribution av upp till 800 resurser av samma typ till en enda resursgrupp. Så när du når den här gränsen måste du distribuera alla nya programgatewayer till en annan resursgrupp. I följande diagram finns det två resursgrupper. Varje resursgrupp innehåller 800 programgatewayer.
Bin pack-klientorganisationer mellan resursgrupper och prenumerationer
Du kan också använda konceptet för paketering av lagerplatser mellan resurser, resursgrupper och prenumerationer. Om du till exempel har ett litet antal klienter kanske du kan distribuera en enskild resurs och dela den mellan alla dina klienter. Följande diagram visar lagerplatspackning i en enda resurs.
När du växer kan du närma dig kapacitetsgränsen för en enskild resurs och skala ut till flera (R) resurser. I följande diagram visas paketering av lagerplatser över flera resurser.
Med tiden kan du nå gränsen för antalet resurser i en enskild resursgrupp och sedan distribuera flera (R) resurser till flera (G) resursgrupper. I följande diagram visas paketering av lagerplatser över flera resurser i flera resursgrupper.
Och när du blir ännu större kan du distribuera över flera (S) prenumerationer, som var och en innehåller flera (G) resursgrupper med flera (R) resurser. Följande diagram visar lagerplatspackning över flera resurser, i flera resursgrupper och prenumerationer.
Genom att planera din utskalningsstrategi kan du skala till ett extremt stort antal klienter och upprätthålla en hög belastningsnivå.
Taggar
Med resurstaggar kan du lägga till anpassade metadata till dina Azure-resurser, vilket kan vara användbart för hanterings- och spårningskostnader. Mer information finns i Allokera kostnader med hjälp av resurstaggar.
Distributionsstackar
Med distributionsstackar kan du gruppera resurser baserat på en gemensam livslängd, även om de omfattar flera resursgrupper eller prenumerationer. Distributionsstackar är användbara när du distribuerar klientspecifika resurser, särskilt om du har en distributionsmetod som kräver distribution av olika typer av resurser på olika platser på grund av skalnings- eller efterlevnadsproblem. Med distributionsstackar kan du också enkelt ta bort alla resurser som är relaterade till en enskild klientorganisation i en enda åtgärd, om klientorganisationen är avregistrerad. Mer information finns i Distributionsstackar.
Antimönster att undvika
- Planerar inte för skalning. Se till att du har en tydlig förståelse för gränserna för de resurser som du distribuerar och vilka gränser som kan bli viktiga när belastningen eller antalet klienter ökar. Planera hur du ska distribuera ytterligare resurser när du skalar och testa planen.
- Planerar inte att bin packa. Även om du inte behöver växa omedelbart planerar du att skala dina Azure-resurser över flera resurser, resursgrupper och prenumerationer över tid. Undvik att göra antaganden i programkoden, som att det finns en enda resurs när du kan behöva skala till flera resurser i framtiden.
- Skala många enskilda resurser. Om du har en komplex resurstopologi kan det bli svårt att skala varje komponent individuellt. Det är ofta enklare att skala lösningen som en enhet genom att följa mönstret Distributionsstämplar.
- Distribuera isolerade resurser för varje klientorganisation när det inte behövs. I många lösningar är det mer kostnadseffektivt och effektivt att distribuera delade resurser för flera klienter.
- Det går inte att spåra klientspecifika resurser. Om du distribuerar klientspecifika resurser ser du till att du förstår vilka resurser som allokeras till vilka klienter. Den här informationen är viktig för efterlevnadsändamål, för att spåra kostnader och för att avetablera resurser om en klientorganisation är avregistrerad. Överväg att använda resurstaggar för att hålla reda på klientinformation om resurser och överväg att använda distributionsstackar för att gruppera klientspecifika resurser i en logisk enhet oavsett vilken resursgrupp eller prenumeration de finns i.
- Använda separata Microsoft Entra-klienter. I allmänhet är det olämpligt att etablera flera Microsoft Entra-klienter. Det är komplext att hantera resurser mellan Microsoft Entra-klienter. Det är enklare att skala mellan prenumerationer som är länkade till en enda Microsoft Entra-klientorganisation.
- Överarchitecting när du inte behöver skala. I vissa lösningar vet du med säkerhet att du aldrig kommer att växa bortom en viss skalningsnivå. I dessa scenarier behöver du inte skapa komplex skalningslogik. Men om din organisation planerar att växa måste du vara beredd att skala – eventuellt med kort varsel.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudförfattare:
- John Downs | Huvudprogramtekniker
Övriga medarbetare:
- Jason Beck | Senior kundtekniker, FastTrack för Azure
- Bohdan Cherchyk | Senior kundtekniker, FastTrack för Azure
- Laura Nicolas | Senior kundtekniker, FastTrack för Azure
- Arsen Vladimirskiy | Huvudkundtekniker, FastTrack för Azure
- Joshua Waddell | Senior kundtekniker, FastTrack för Azure
Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.