Azure-resourceorganisatie in multitenant-oplossingen

Azure biedt veel opties voor het ordenen van uw resources. In een multitenant-oplossing zijn er specifieke afwegingen die u moet overwegen wanneer u de strategie van uw resourceorganisatie plant. In dit artikel bekijken we twee belangrijke elementen van het organiseren van uw Azure-resources: tenantisolatie en uitschalen over meerdere resources. We beschrijven enkele algemene implementatiemethoden die verschillende tenantisolatiemodellen kunnen ondersteunen. We beschrijven ook hoe u kunt werken met de resourcelimieten en quota van Azure en hoe u uw oplossing kunt schalen buiten deze limieten.

Belangrijke overwegingen en vereisten

Vereisten voor tenantisolatie

Wanneer u een multitenant-oplossing in Azure implementeert, moet u beslissen of u resources toedeelt aan elke tenant of resources deelt tussen meerdere tenants. In de multitenancy-benaderingen en servicespecifieke richtlijnen van deze reeks beschrijven we de opties en afwegingen voor veel categorieën resources. Over het algemeen zijn er verschillende opties voor tenantisolatie. Bekijk Tenancy-modellen om rekening te houden met een multitenant-oplossing voor meer richtlijnen over het bepalen van uw isolatiemodel.

Schaal wijzigen

De meeste Azure-resources, evenals resourcegroepen en abonnementen, leggen limieten op die van invloed kunnen zijn op uw capaciteit om te schalen. Mogelijk moet u overwegen om uit - of binverpakkingen uit te schalen om te voldoen aan het geplande aantal tenants of de geplande systeembelasting.

Als u zeker weet dat u niet groter wordt dan grote aantallen tenants of een hoge belasting, moet u uw scale-outplan niet overwerken. Maar als u van plan bent om uw oplossing te laten groeien, moet u zorgvuldig rekening houden met uw uitschaalplan. Zorg ervoor dat u schalen ontwerpt door de richtlijnen in dit artikel te volgen.

Als u een geautomatiseerd implementatieproces hebt en moet schalen tussen resources, moet u bepalen hoe u tenants implementeert en toewijst aan meerdere resource-exemplaren. Hoe detecteert u bijvoorbeeld dat u het aantal tenants nadert dat aan een specifieke resource kan worden toegewezen? Bent u van plan om nieuwe resources net op tijd te implementeren voor wanneer u ze nodig hebt? Of implementeert u van tevoren een pool met resources, zodat ze klaar zijn voor gebruik wanneer u ze nodig hebt?

Het is ook belangrijk om te voorkomen dat u veronderstellingen maakt in uw code en configuratie, waardoor u de schaal kunt beperken. U moet bijvoorbeeld in de toekomst uitschalen naar meerdere opslagaccounts, dus wanneer u uw toepassingslaag bouwt, moet u ervoor zorgen dat het dynamisch kan worden overgeschakeld naar het opslagaccount dat wordt verbonden op basis van de actieve tenant.

Benaderingen en patronen om rekening mee te houden

Isolatie van tenants

Azure-resources worden geïmplementeerd en beheerd via een hiërarchie. De meeste resources worden geïmplementeerd in resourcegroepen, die zijn opgenomen in abonnementen. Beheergroepen groeperen abonnementen logisch. Al deze hiërarchische lagen zijn gekoppeld aan een Microsoft Entra-tenant.

Wanneer u bepaalt hoe u resources voor elke tenant implementeert, kunt u zich op verschillende niveaus in de hiërarchie isoleren. Elke optie is geldig voor bepaalde typen multitenant-oplossingen en wordt geleverd met voordelen en compromissen. Het is ook gebruikelijk om benaderingen te combineren, waarbij verschillende isolatiemodellen worden gebruikt voor verschillende onderdelen van een oplossing.

Isolatie binnen een gedeelde resource

U kunt ervoor kiezen om een Azure-resource te delen tussen meerdere tenants en al hun workloads uit te voeren op één exemplaar. Bekijk de servicespecifieke richtlijnen voor de Azure-services die u gebruikt om specifieke overwegingen of opties te begrijpen die belangrijk kunnen zijn.

Wanneer u één exemplaar van een resource uitvoert, moet u rekening houden met servicelimieten, abonnementslimieten of quota die mogelijk worden bereikt wanneer u schaalt. Er is bijvoorbeeld een maximumaantal knooppunten dat wordt ondersteund door een AKS-cluster (Azure Kubernetes Service) en er is een bovengrens voor het aantal transacties per seconde dat wordt ondersteund door een opslagaccount. Overweeg hoe u schaalt naar meerdere gedeelde resources wanneer u deze limieten nadert.

U moet er ook voor zorgen dat uw toepassingscode volledig op de hoogte is van multitenancy en dat de toegang tot de gegevens voor een specifieke tenant wordt beperkt.

Stel dat Contoso een saaS-toepassing met meerdere tenants bouwt die een webtoepassing, een database en een opslagaccount bevat. Ze kunnen besluiten om gedeelde resources te implementeren voor al hun klanten. In het volgende diagram wordt één set resources gedeeld door alle klanten.

Resources in een resourcegroep scheiden

U kunt ook toegewezen resources implementeren voor elke tenant. U kunt een volledige kopie van uw oplossing implementeren voor één tenant. Of u kunt sommige onderdelen tussen tenants delen terwijl andere onderdelen zijn toegewezen aan een specifieke tenant. Deze benadering wordt horizontale partitionering genoemd.

U wordt aangeraden resourcegroepen te gebruiken om resources met dezelfde levenscyclus te beheren. In sommige systemen met meerdere tenants is het zinvol om resources voor meerdere tenants te implementeren in één resourcegroep of een set resourcegroepen.

Het is belangrijk dat u overweegt hoe u deze resources implementeert en beheert, inclusief of de implementatie van tenantspecifieke resources wordt gestart door uw implementatiepijplijn of uw toepassing. U moet ook bepalen hoe u duidelijk identificeert welke specifieke resources betrekking hebben op specifieke tenants. Overweeg een duidelijke naamconventiestrategie, resourcetags of een tenantcatalogusdatabase te gebruiken.

Het is een goede gewoonte om afzonderlijke resourcegroepen te gebruiken voor de resources die u deelt tussen meerdere tenants en de resources die u voor afzonderlijke tenants implementeert. Voor sommige resources beperkt Azure echter het aantal resources van één type dat kan worden geïmplementeerd in een resourcegroep. Deze limiet betekent dat u mogelijk moet schalen in meerdere resourcegroepen wanneer u groeit.

Stel dat Contoso drie klanten (tenants) heeft: Adventure Works, Fabrikam en Tailwind. Ze kunnen ervoor kiezen om de webtoepassing en het opslagaccount tussen de drie tenants te delen en vervolgens afzonderlijke databases voor elke tenant te implementeren. In het volgende diagram ziet u een resourcegroep die gedeelde resources en een resourcegroep bevat die de database van elke tenant bevat.

Afzonderlijke resourcegroepen in een abonnement

Wanneer u een set resources voor elke tenant implementeert, kunt u overwegen om toegewezen tenantspecifieke resourcegroepen te gebruiken. Wanneer u bijvoorbeeld het patroon Implementatiestempels volgt, moet elke zegel worden geïmplementeerd in een eigen resourcegroep. U kunt overwegen om meerdere tenantspecifieke resourcegroepen te implementeren in een gedeeld Azure-abonnement, waarmee u eenvoudig beleidsregels en regels voor toegangsbeheer kunt configureren.

U kunt ervoor kiezen om een set resourcegroepen te maken voor elke tenant en ook voor gedeelde resourcegroepen voor gedeelde resources.

Wanneer u tenantspecifieke resourcegroepen implementeert in gedeelde abonnementen, moet u rekening houden met het maximum aantal resourcegroepen in elk abonnement en andere limieten op abonnementsniveau die van toepassing zijn op de resources die u implementeert. Wanneer u deze limieten nadert, moet u mogelijk schalen voor meerdere abonnementen.

In ons voorbeeld kan Contoso ervoor kiezen om een stempel te implementeren voor elk van hun klanten en de stempels in toegewezen resourcegroepen binnen één abonnement te plaatsen. In het volgende diagram wordt voor elke klant een abonnement gemaakt dat drie resourcegroepen bevat.

Afzonderlijke abonnementen

Door tenantspecifieke abonnementen te implementeren, kunt u tenantspecifieke resources volledig isoleren. Omdat de meeste quota en limieten binnen een abonnement van toepassing zijn, zorgt het gebruik van een afzonderlijk abonnement per tenant ervoor dat elke tenant alle toepasselijke quota's volledig gebruikt. Voor sommige typen Azure-factureringsaccounts kunt u programmatisch abonnementen maken. U kunt ook Azure-reserveringen en een Azure-besparingsplan gebruiken voor berekeningen tussen abonnementen.

Maak u bewust van het aantal abonnementen dat u kunt maken. Het maximum aantal abonnementen kan verschillen, afhankelijk van uw commerciële relatie met Microsoft of een Microsoft-partner, bijvoorbeeld als u een Enterprise Agreement hebt.

Het kan echter lastiger zijn om quotumverhogingen aan te vragen wanneer u werkt voor een groot aantal abonnementen. De Quota-API biedt een programmatische interface voor sommige resourcetypen. Voor veel resourcetypen moeten quotumverhogingen echter worden aangevraagd door een ondersteuningsaanvraag in te dienen. Het kan ook lastig zijn om met ondersteuning voor Azure overeenkomsten en ondersteuningsaanvragen te werken, wanneer u met veel abonnementen werkt.

Overweeg om uw tenantspecifieke abonnementen te groeperen in een beheergroephiërarchie om eenvoudig beheer van regels en beleidsregels voor toegangsbeheer mogelijk te maken.

Stel dat Contoso heeft besloten afzonderlijke Azure-abonnementen te maken voor elk van hun drie klanten, zoals wordt weergegeven in het volgende diagram. Elk abonnement bevat een resourcegroep, met de volledige set resources voor die klant.

Elk abonnement bevat een resourcegroep, met de volledige set resources voor die klant.

Ze gebruiken een beheergroep om het beheer van hun abonnementen te vereenvoudigen. Door productie in de naam van de beheergroep op te neemt, kunnen ze alle productietenants duidelijk onderscheiden van niet-productie- of testtenants. Voor niet-productietenants gelden verschillende regels en beleidsregels voor Azure-toegangsbeheer.

Al hun abonnementen zijn gekoppeld aan één Microsoft Entra-tenant. Het gebruik van één Microsoft Entra-tenant betekent dat de identiteiten van het Contoso-team, inclusief gebruikers en service-principals, kunnen worden gebruikt in hun hele Azure-estate.

Afzonderlijke abonnementen in afzonderlijke Microsoft Entra-tenants

Het is ook mogelijk om handmatig afzonderlijke Microsoft Entra-tenants te maken voor elk van uw tenants of om uw resources te implementeren in abonnementen binnen de Microsoft Entra-tenants van uw klanten. Het werken met meerdere Microsoft Entra-tenants maakt het echter moeilijker om te verifiëren, roltoewijzingen te beheren, globale beleidsregels toe te passen en vele andere beheerbewerkingen uit te voeren.

In situaties waarin u Azure-resources moet beheren in abonnementen die zijn gekoppeld aan meerdere Microsoft Entra-tenants, kunt u overwegen Azure Lighthouse te gebruiken om uw resources te beheren in uw Microsoft Entra-tenants.

Contoso kan bijvoorbeeld afzonderlijke Microsoft Entra-tenants en afzonderlijke Azure-abonnementen maken voor elk van hun klanten, zoals wordt weergegeven in het volgende diagram.

Een Microsoft Entra-tenant is geconfigureerd voor elke tenant van Contoso, die een abonnement en de vereiste resources bevat. Azure Lighthouse is verbonden met elke Microsoft Entra-tenant.

Verpakking van container

Ongeacht uw resourceisolatiemodel is het belangrijk om te overwegen wanneer en hoe uw oplossing wordt uitgeschaald over meerdere resources. Mogelijk moet u uw resources schalen naarmate de belasting van uw systeem toeneemt of naarmate het aantal tenants toeneemt. Overweeg het verpakken van containers om een optimaal aantal resources te implementeren voor uw vereisten.

Bronlimieten

Azure-resources hebben limieten en quota die moeten worden overwogen in uw oplossingsplanning. Resources kunnen bijvoorbeeld ondersteuning bieden voor een maximum aantal gelijktijdige aanvragen of tenantspecifieke configuratie-instellingen.

De manier waarop u elke resource configureert en gebruikt, heeft ook invloed op de schaalbaarheid van die resource. Stel dat uw toepassing, uitgaande van een bepaalde hoeveelheid rekenresources, kan reageren op een gedefinieerd aantal transacties per seconde. Buiten dit punt moet u mogelijk uitschalen. Prestatietests helpen u bij het identificeren van het punt waarop uw resources niet meer aan uw vereisten voldoen.

Wanneer u enkele van uw resources deelt tussen tenants, moet u eerst het aantal tenants bepalen dat door de resource wordt ondersteund wanneer deze is geconfigureerd volgens uw vereisten. Implementeer vervolgens zoveel resources als u nodig hebt om uw totale aantal tenants te leveren.

Stel dat u Azure-toepassing Gateway implementeert als onderdeel van een SaaS-oplossing met meerdere tenants. U controleert uw toepassingsontwerp, test de prestaties van de toepassingsgateway onder belasting en controleert de configuratie. Vervolgens bepaalt u dat één toepassingsgatewayresource kan worden gedeeld tussen 100 klanten. Volgens het groeiplan van uw organisatie verwacht u in uw eerste jaar 150 klanten te onboarden, dus u moet plannen om meerdere toepassingsgateways te implementeren om uw verwachte belasting te kunnen verwerken.

In het vorige diagram zijn er twee toepassingsgateways. De eerste gateway is toegewezen aan klanten 1 tot en met 100 en de tweede is toegewezen aan klanten 101 tot en met 200.

Resourcegroep- en abonnementslimieten

Of u nu met gedeelde of toegewezen resources werkt, het is belangrijk dat u rekening houdt met limieten. Azure beperkt het aantal resources dat kan worden geïmplementeerd in een resourcegroep en in een Azure-abonnement. Wanneer u deze limieten nadert, moet u van plan zijn om te schalen in meerdere resourcegroepen of abonnementen.

Stel dat u voor elk van uw klanten een toegewezen toepassingsgateway implementeert in een gedeelde resourcegroep. Voor sommige resources implementeert ondersteuning voor Azure maximaal 800 resources van hetzelfde type in één resourcegroep. Wanneer u deze limiet bereikt, moet u dus nieuwe toepassingsgateways implementeren in een andere resourcegroep. In het volgende diagram zijn er twee resourcegroepen. Elke resourcegroep bevat 800 toepassingsgateways.

Bin pack-tenants in resourcegroepen en abonnementen

U kunt ook het containerverpakkingsconcept toepassen op resources, resourcegroepen en abonnementen. Als u bijvoorbeeld een klein aantal tenants hebt, kunt u mogelijk één resource implementeren en deze delen tussen al uw tenants. In het volgende diagram ziet u bin-verpakking in één resource.

Naarmate u groeit, kunt u de capaciteitslimiet voor één resource benaderen en uitschalen naar meerdere (R)-resources. In het volgende diagram ziet u bin-verpakking voor meerdere resources.

Na verloop van tijd bereikt u mogelijk de limiet van het aantal resources in één resourcegroep en implementeert u vervolgens meerdere (R)-resources in meerdere (G)-resourcegroepen. In het volgende diagram ziet u bin-verpakking voor meerdere resources, in meerdere resourcegroepen.

En naarmate u nog groter wordt, kunt u implementeren in meerdere (S)-abonnementen, elk met meerdere (G)-resourcegroepen met meerdere (R)-resources. In het volgende diagram ziet u bin-verpakking voor meerdere resources, in meerdere resourcegroepen en abonnementen.

Door uw uitschaalstrategie te plannen, kunt u schalen naar zeer grote aantallen tenants en een hoog belastingsniveau behouden.

Tags

Met resourcetags kunt u aangepaste metagegevens toevoegen aan uw Azure-resources. Dit kan handig zijn voor het beheer en het bijhouden van kosten. Zie Kosten toewijzen met behulp van resourcetags voor meer informatie.

Implementatiestacks

Met implementatiestacks kunt u resources groeperen op basis van een gemeenschappelijke levensduur, zelfs als ze meerdere resourcegroepen of abonnementen omvatten. Implementatiestacks zijn handig wanneer u tenantspecifieke resources implementeert, met name als u een implementatiebenadering hebt waarvoor verschillende typen resources op verschillende locaties moeten worden geïmplementeerd vanwege problemen met schaal of naleving. Met implementatiestacks kunt u ook eenvoudig alle resources verwijderen die betrekking hebben op één tenant in één bewerking, als die tenant is uitgeschakeld. Zie Implementatiestacks voor meer informatie.

Antipatroon om te voorkomen

• Niet van plan om te schalen. Zorg ervoor dat u een duidelijk beeld hebt van de limieten van de resources die u gaat implementeren en welke limieten belangrijk kunnen worden, naarmate uw belasting of aantal tenants toeneemt. Plan hoe u extra resources gaat implementeren terwijl u schaalt en test het plan.
• Het is niet van plan om een bin pack in te pakken. Zelfs als u niet onmiddellijk hoeft te groeien, kunt u uw Azure-resources in de loop van de tijd schalen voor meerdere resources, resourcegroepen en abonnementen. Vermijd het maken van veronderstellingen in uw toepassingscode, zoals dat er één resource is wanneer u in de toekomst naar meerdere resources moet schalen.
• Veel afzonderlijke resources schalen. Als u een complexe resourcetopologie hebt, kan het lastig zijn om elk onderdeel afzonderlijk te schalen. Het is vaak eenvoudiger om uw oplossing als een eenheid te schalen door het patroon Implementatiestempels te volgen.
• Het implementeren van geïsoleerde resources voor elke tenant, indien niet vereist. In veel oplossingen is het rendabeler en efficiënter om gedeelde resources voor meerdere tenants te implementeren.
• Kan tenantspecifieke resources niet bijhouden. Als u tenantspecifieke resources implementeert, moet u weten welke resources worden toegewezen aan welke tenants. Deze informatie is belangrijk voor nalevingsdoeleinden, voor het bijhouden van kosten en voor het ongedaan maken van de inrichting van resources als een tenant is uitgeschakeld. Overweeg resourcetags te gebruiken om tenantgegevens over resources bij te houden en overweeg implementatiestacks te gebruiken om tenantspecifieke resources samen te groeperen in een logische eenheid, ongeacht de resourcegroep of het abonnement waarin ze zich bevinden.
• Afzonderlijke Microsoft Entra-tenants gebruiken. Over het algemeen is het niet mogelijk om meerdere Microsoft Entra-tenants in te richten. Het beheren van resources in Microsoft Entra-tenants is complex. Het is eenvoudiger om te schalen tussen abonnementen die zijn gekoppeld aan één Microsoft Entra-tenant.
• Overarchitecteren wanneer u niet hoeft te schalen. In sommige oplossingen weet u zeker dat u nooit meer dan een bepaald schaalniveau gaat groeien. In deze scenario's hoeft u geen complexe schaallogica te bouwen. Als uw organisatie echter van plan is te groeien, moet u voorbereid zijn op schaalaanpassing, mogelijk op korte termijn.

Medewerkers

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

Hoofdauteur:

• John Downs | Principal Software Engineer

Andere Inzenders:

• Jason Beck | Senior klanttechnicus, FastTrack voor Azure
• Bohdan Cherchyk | Senior klanttechnicus, FastTrack voor Azure
• Laura Nicolas | Senior klanttechnicus, FastTrack voor Azure
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack voor Azure
• Joshua Waddell | Senior klanttechnicus, FastTrack voor Azure

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

Volgende stappen

Bekijk de benaderingen kostenbeheer en toewijzing .