Architectuurbenaderingen voor de implementatie en configuratie van multitenant-oplossingen

Ongeacht uw architectuur en de onderdelen die u gebruikt om deze te implementeren, moet u de onderdelen van uw oplossing implementeren en configureren. In een omgeving met meerdere tenants is het belangrijk om na te gaan hoe u uw Azure-resources implementeert, met name wanneer u toegewezen resources voor elke tenant implementeert of wanneer u resources opnieuw configureert op basis van het aantal tenants in uw systeem. Op deze pagina bieden we oplossingsarchitecten richtlijnen over het implementeren van multitenant-oplossingen en laten we enkele benaderingen zien waarmee u rekening moet houden wanneer u uw implementatiestrategie plant.

Belangrijke overwegingen en vereisten

Het is belangrijk om een duidelijk beeld te hebben van uw vereisten voordat u uw implementatiestrategie plant. Specifieke overwegingen zijn onder andere:

• Verwachte schaal: Verwacht u dat u een klein aantal tenants (zoals vijf of minder) ondersteunt of dat u groeit tot een groot aantal tenants?
• Geautomatiseerde of ondersteunde onboarding: Wanneer een tenant gereed is voor onboarding, kunnen ze het proces zelf voltooien door een geautomatiseerde procedure te volgen? Of starten nieuwe tenants een aanvraag en voert u deze handmatig uit nadat u de aanvraag hebt ontvangen? Zijn er handmatige goedkeuringsstappen vereist voor uw team, bijvoorbeeld om misbruik van uw service te voorkomen?
• Inrichtingstijd: Wanneer een tenant gereed is om te worden voorbereid, hoe snel moet het onboardingproces worden voltooid? Als u geen duidelijk antwoord hebt, kunt u overwegen of dit moet worden gemeten in seconden, minuten, uren of dagen.
• Azure Marketplace: Bent u van plan de Azure Marketplace te gebruiken om de implementatie te initiëren? Als u dit doet, zijn er vereisten waaraan u moet voldoen om nieuwe tenants toe te voegen.

U moet ook rekening houden met onboarding- en inrichtingsstappen, automatisering en verantwoordelijkheid voor resourcebeheer.

Stappen voor onboarding en inrichting

Houd rekening met alles wat u moet doen bij het onboarden van een tenant en documenteer deze lijst en werkstroom, zelfs als deze handmatig wordt uitgevoerd. De onboarding-werkstroom bevat doorgaans het volgende:

• Aanvaarding van commerciële overeenkomsten.
• Verzameling van de informatie die u nodig hebt om uw systeem voor de nieuwe tenant te configureren.
• Handmatige goedkeuringsstappen, bijvoorbeeld om fraude of misbruik van uw service te voorkomen.
• Het inrichten van resources in Azure.
• Domeinnamen maken of configureren.
• Voer configuratietaken na de implementatie uit, zoals het maken van het eerste gebruikersaccount voor de tenant en het veilig verzenden van de referenties naar de tenant.
• Handmatige configuratiewijzigingen, zoals wijzigingen in DNS-records.

Documenteer duidelijk de werkstroom die nodig is voor het onboarden van een nieuwe tenant.

Houd ook rekening met de specifieke Azure-resources die u voor een tenant moet inrichten. Zelfs als u geen toegewezen resources voor elke tenant inricht, moet u overwegen of u soms resources moet implementeren wanneer een nieuwe tenant wordt voorbereid. Dit kan gebeuren wanneer een tenant vereist dat hun gegevens worden opgeslagen in een specifieke regio of wanneer u de limieten van een zegel of onderdeel in uw oplossing nadert en een ander exemplaar moet maken voor de volgende batch tenants.

Overweeg of het onboardingproces waarschijnlijk verstorend is voor andere tenants, met name voor degenen die dezelfde infrastructuur delen. Als u bijvoorbeeld gedeelde databases wilt wijzigen, kan dit proces een invloed hebben op de prestaties die andere tenants kunnen merken? Overweeg of u deze effecten kunt voorkomen of beperken door het onboardingproces buiten normale bedrijfsuren uit te voeren.

Automation

Geautomatiseerde implementaties zijn altijd aan te raden voor cloudoplossingen. Bij het werken met multitenant-oplossingen wordt implementatieautomatisering nog belangrijker om de volgende redenen:

• Schaal: handmatige implementatieprocessen worden steeds complexer en tijdrovender, naarmate uw tenantpopulatie toeneemt. Een geautomatiseerde implementatiebenadering is eenvoudiger te schalen naarmate het aantal tenants groeit.
• Herhaalbaar: Gebruik in een omgeving met meerdere tenants een consistent proces voor implementaties in alle tenants. Handmatige processen introduceren de kans op fouten of stappen die worden uitgevoerd voor sommige tenants en niet voor andere. Deze handmatige processen laten uw omgeving in een inconsistente status staan, waardoor uw team de oplossing moeilijker kan beheren.
• Impact van storingen: handmatige implementaties zijn aanzienlijk riskanter en gevoeliger voor storingen dan geautomatiseerde implementaties. In een omgeving met meerdere tenants kan de impact van een systeembrede storing (vanwege een implementatiefout) hoog zijn, omdat elke tenant mogelijk wordt beïnvloed.

Wanneer u implementeert in een omgeving met meerdere tenants, moet u implementatiepijplijnen gebruiken en infrastructuur gebruiken als codetechnologieën (IaC), zoals Bicep, JSON ARM-sjablonen, Terraform of de Azure-SDK's.

Als u van plan bent om uw oplossing via Azure Marketplace aan te bieden, moet u een volledig geautomatiseerd onboardingproces voor nieuwe tenants bieden. Dit proces wordt beschreven in de documentatie over SaaS-fulfillment-API's.

Maximale resourcecapaciteit

Wanneer u tenantresources programmatisch implementeert op gedeelde resources, kunt u de capaciteitslimiet voor elke resource overwegen. Wanneer u deze limiet nadert, moet u mogelijk een ander exemplaar van de resource maken om verdere schaal te ondersteunen. Houd rekening met de limieten van elke resource die u implementeert en de voorwaarden die u zullen activeren om een ander exemplaar te implementeren.

Stel dat uw oplossing een logische Azure SQL-server bevat en dat uw oplossing een toegewezen database op die server voor elke tenant inricht. Eén logische server heeft limieten, waaronder een maximum aantal databases dat door een logische server wordt ondersteund. Wanneer u deze limieten nadert, moet u mogelijk nieuwe servers inrichten, zodat u tenants kunt blijven onboarden. Overweeg of u dit proces automatiseert of de groei handmatig bewaakt.

Verantwoordelijkheid voor resourcebeheer

In sommige multitenant-oplossingen implementeert u toegewezen Azure-resources voor elke tenant, zoals een database voor elke tenant. U kunt ook besluiten om een vast aantal tenants te gebruiken voor één exemplaar van een resource, dus het aantal tenants dat u hebt, bepaalt de set resources die u in Azure implementeert. In andere oplossingen implementeert u één set gedeelde resources en configureert u vervolgens de resources opnieuw wanneer u nieuwe tenants onboardt.

Voor elk van deze modellen moet u resources op verschillende manieren implementeren en beheren. U moet overwegen hoe u de levenscyclus van de resources die u inricht, implementeert en beheert. Twee veelvoorkomende benaderingen zijn als volgt:

• Als u tenants wilt behandelen als configuratie van de resources die u implementeert, en uw implementatiepijplijnen gebruiken om deze resources te implementeren en te configureren.
• Als u tenants als gegevens wilt behandelen en een besturingsvlak wilt inrichten en infrastructuur voor uw tenants wilt configureren.

Hieronder vindt u verdere bespreking van deze benaderingen.

Testen

Plan om uw oplossing grondig te testen tijdens en na elke implementatie. U kunt geautomatiseerde tests gebruiken om het functionele en niet-functionele gedrag van uw oplossing te controleren. Zorg ervoor dat u uw tenantisolatiemodel test en overweeg om hulpprogramma's zoals Azure Chaos Studio te gebruiken om opzettelijk fouten te introduceren die echte storingen simuleren en controleren of uw oplossingsfuncties zelfs wanneer een onderdeel niet beschikbaar of defect is.

Benaderingen en patronen om rekening mee te houden

Verschillende ontwerppatronen van het Azure Architecture Center en de bredere community zijn van belang voor de implementatie en configuratie van multitenant-oplossingen.

Patroon Implementatiestempels

Het patroon Implementatiestempels omvat het implementeren van een toegewezen infrastructuur voor een tenant of groep tenants. Eén stempel kan meerdere tenants bevatten, of het is mogelijk toegewezen aan één tenant. U kunt ervoor kiezen om één stempel te implementeren of u kunt een implementatie coördineren voor meerdere stempels. Als u speciale stempels voor elke tenant implementeert, kunt u ook overwegen om programmatisch volledige stempels te implementeren.

Implementatieringen

Met implementatieringen kunt u updates voor verschillende groepen infrastructuur op verschillende momenten implementeren. Deze benadering wordt vaak gebruikt met het patroon Implementatiestempels en groepen stempels kunnen worden toegewezen aan afzonderlijke ringen op basis van tenantvoorkeuren, workloadtypen en andere overwegingen. Zie Implementatieringen voor meer informatie.

Functievlaggen

Met functievlagmen kunt u geleidelijk nieuwe functies of versies van uw oplossing beschikbaar maken voor verschillende tenants, terwijl u één codebasis onderhoudt. Overweeg het gebruik van Azure-app Configuratie om uw functievlagmen te beheren. Zie Functievlagmen voor meer informatie.

Soms moet u specifieke functies voor bepaalde klanten selectief inschakelen. U hebt bijvoorbeeld verschillende prijscategorieën die toegang tot bepaalde mogelijkheden toestaan. Functievlagmen zijn meestal niet de juiste keuze voor deze scenario's. In plaats daarvan kunt u overwegen een proces te bouwen om de licentierechten bij te houden en af te dwingen die elke klant heeft.

Antipatroon om te voorkomen

Wanneer u multitenant-oplossingen implementeert en configureert, is het belangrijk om situaties te voorkomen die uw vermogen om te schalen remmen. Dit zijn onder meer de volgende:

• Handmatige implementatie en testen. Zoals hierboven beschreven, voegen handmatige implementatieprocessen risico's toe en vertraagt u de mogelijkheid om te implementeren. Overweeg pijplijnen te gebruiken voor geautomatiseerde implementaties, programmatisch resources te maken op basis van de code van uw oplossing of een combinatie van beide.
• Gespecialiseerde aanpassingen voor tenants. Vermijd het implementeren van functies of een configuratie die alleen van toepassing is op één tenant. Deze aanpak voegt complexiteit toe aan uw implementaties en testprocessen. Gebruik in plaats daarvan dezelfde resourcetypen en codebasis voor elke tenant en gebruik strategieën zoals functievlagmen voor tijdelijke wijzigingen of voor functies die geleidelijk worden geïmplementeerd, of gebruik verschillende prijscategorieën met licentierechten om functies selectief in te schakelen voor tenants waarvoor deze zijn vereist. Gebruik een consistent en geautomatiseerd implementatieproces, zelfs voor tenants met geïsoleerde of toegewezen resources.

Tenantlijsten als configuratie of gegevens

U kunt rekening houden met de volgende twee benaderingen wanneer u resources in een multitenant-oplossing implementeert:

• Gebruik een geautomatiseerde implementatiepijplijn om elke resource te implementeren. Wanneer er nieuwe tenants worden toegevoegd, configureert u de pijplijn opnieuw om de resources voor elke tenant in te richten.
• Gebruik een geautomatiseerde implementatiepijplijn om gedeelde resources te implementeren die niet afhankelijk zijn van het aantal tenants. Voor resources die voor elke tenant zijn geïmplementeerd, maakt u deze in uw toepassing.

Wanneer u rekening houdt met de twee benaderingen, moet u onderscheid maken tussen het behandelen van uw tenantlijst als een configuratie of als gegevens. Dit onderscheid is ook belangrijk wanneer u bedenkt hoe u een besturingsvlak voor uw systeem bouwt.

Tenantlijst als configuratie

Wanneer u uw tenantlijst als configuratie behandelt, implementeert u al uw resources vanuit een gecentraliseerde implementatiepijplijn. Wanneer er nieuwe tenants worden toegevoegd, configureert u de pijplijn of de bijbehorende parameters opnieuw. Normaal gesproken vindt de herconfiguratie plaats via handmatige wijzigingen, zoals wordt geïllustreerd in het volgende diagram.

Het proces voor onboarding van een nieuwe tenant kan er ongeveer als volgt uitzien:

1. Werk de tenantlijst bij. Dit gebeurt meestal handmatig door de pijplijn zelf te configureren of door een parameterbestand te wijzigen dat is opgenomen in de configuratie van de pijplijn.
2. Activeer de pijplijn om uit te voeren.
3. Met de pijplijn wordt uw volledige set Azure-resources opnieuw geïmplementeerd, inclusief nieuwe tenantspecifieke resources.

Deze benadering werkt meestal goed voor kleine aantallen tenants en voor architecturen waarin alle resources worden gedeeld. Het is een eenvoudige benadering omdat al uw Azure-resources kunnen worden geïmplementeerd en geconfigureerd met behulp van één proces.

Wanneer u echter een groter aantal tenants benadert, bijvoorbeeld 5 tot 10 of meer, wordt het lastig om de pijplijn opnieuw te configureren terwijl u tenants toevoegt. De tijd die nodig is om de implementatiepijplijn uit te voeren, neemt vaak ook aanzienlijk toe. Deze aanpak biedt ook geen eenvoudige ondersteuning voor het maken van selfservicetenants en de doorlooptijd voordat een tenant wordt toegevoegd, kan langer duren, omdat u uw pijplijn moet activeren om uit te voeren.

Tenantlijst als gegevens

Wanneer u uw tenantlijst als gegevens behandelt, implementeert u uw gedeelde onderdelen nog steeds met behulp van een pijplijn. Voor resources en configuratie-instellingen die voor elke tenant moeten worden geïmplementeerd, moet u uw resources echter imperatief implementeren of configureren. Uw besturingsvlak kan bijvoorbeeld de Azure SDK's gebruiken om een specifieke resource te maken of om de implementatie van een geparameteriseerde sjabloon te initiëren.

Het proces voor het onboarden van een nieuwe tenant kan er ongeveer als volgt uitzien en zou asynchroon gebeuren:

1. Vraag een tenant aan om onboarding uit te voeren, bijvoorbeeld door een API-aanvraag in te voeren op het besturingsvlak van uw systeem.
2. Een werkstroomonderdeel ontvangt de aanvraag voor het maken en organiseert de resterende stappen.
3. De werkstroom initieert de implementatie van tenantspecifieke resources naar Azure. Dit kan worden bereikt met behulp van een imperatief programmeermodel, zoals met behulp van de Azure SDK's, of door de implementatie van een Bicep- of Terraform-sjabloon imperatief te activeren.
4. Wanneer de implementatie is voltooid, worden de gegevens van de nieuwe tenant opgeslagen in de centrale tenantcatalogus. De gegevens die voor elke tenant zijn opgeslagen, bevatten mogelijk de tenant-id en de resource-id's voor alle tenantspecifieke resources die door de werkstroom zijn gemaakt.

Hiermee kunt u resources inrichten voor nieuwe tenants zonder de volledige oplossing opnieuw te implementeren. De tijd die nodig is voor het inrichten van nieuwe resources voor elke tenant is waarschijnlijk korter, omdat alleen die resources moeten worden geïmplementeerd.

Deze benadering is echter vaak veel tijdrovender om te bouwen en de inspanning die u besteedt, moet worden gerechtvaardigd door het aantal tenants of de inrichtingsperioden waaraan u moet voldoen.

Zie Overwegingen voor multitenant-besturingsvlakken voor meer informatie over deze aanpak.

Opmerking

Contoso voert een multitenant-oplossing uit voor hun klanten. Op dit moment hebben ze zes tenants en verwachten ze dat ze binnen de komende 18 maanden tot 300 tenants groeien. Contoso volgt de multitenant-app met toegewezen databases voor elke tenantbenadering . Ze hebben één set App Service-resources en een logische Azure SQL-server geïmplementeerd die worden gedeeld tussen al hun tenants en ze implementeren een toegewezen Azure SQL-database voor elke tenant, zoals wordt weergegeven in het volgende diagram.

Contoso gebruikt Bicep om hun Azure-resources te implementeren.

Optie 1: implementatiepijplijnen voor alles gebruiken

Contoso kan overwegen om al hun resources te implementeren met behulp van een implementatiepijplijn. Met hun pijplijn wordt een Bicep-bestand geïmplementeerd dat alle Azure-resources bevat, inclusief de Azure SQL-databases voor elke tenant. Een parameterbestand definieert de lijst met tenants en het Bicep-bestand maakt gebruik van een resourcelus voor het implementeren van een database voor elk van de vermelde tenants, zoals wordt weergegeven in het volgende diagram.

Als Contoso dit model volgt, moeten ze hun parameterbestand bijwerken als onderdeel van de onboarding van een nieuwe tenant. Vervolgens moeten ze hun pijplijn opnieuw uitvoeren. Ze moeten ook handmatig bijhouden of ze bijna limieten hebben, bijvoorbeeld als ze met een onverwacht hoge snelheid groeien en het maximum aantal databases benaderen dat wordt ondersteund op één logische Azure SQL-server.

Optie 2: gebruik een combinatie van implementatiepijplijnen en het maken van imperatieve resources

Contoso kan ook overwegen de verantwoordelijkheid voor de Azure-implementaties te scheiden.

Contoso maakt gebruik van een Bicep-bestand dat de gedeelde resources definieert die moeten worden geïmplementeerd. De gedeelde resources ondersteunen al hun tenants en bevatten een tenanttoewijzingsdatabase, zoals wordt weergegeven in het volgende diagram.

Het Contoso-team bouwt vervolgens een besturingsvlak met een onboarding-API voor tenants. Wanneer het verkoopteam de verkoop aan een nieuwe klant heeft voltooid, activeert Microsoft Dynamics de API om het onboardingproces te starten. Contoso biedt ook een selfservicewebinterface die klanten kunnen gebruiken en die de API ook activeert.

De API start asynchroon een werkstroom die de nieuwe tenants onboardt. De werkstroom initieert de implementatie van een nieuwe Azure SQL-database. Dit kan worden uitgevoerd op een van de volgende manieren:

• Gebruik de Azure SDK om de implementatie van een tweede Bicep-bestand te initiëren dat de Azure SQL-database definieert.
• Gebruik de Azure SDK om een Azure SQL-database imperatief te maken met behulp van de beheerbibliotheek.

Nadat de database is geïmplementeerd, voegt de werkstroom de tenant toe aan de tenantlijstdatabase, zoals wordt weergegeven in het volgende diagram.

Doorlopende databaseschema-updates worden gestart door hun toepassingslaag.

Medewerkers

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

Hoofdauteur:

• John Downs | Principal Software Engineer

Andere Inzenders:

• Bohdan Cherchyk | Senior klanttechnicus, FastTrack voor Azure
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack voor Azure

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

Volgende stappen

• Bekijk de overwegingen voor het bijwerken van een multitenant-oplossing.
• Overweeg architectuurmethoden voor opslag en gegevens.
• Overweeg hoe u Azure Resource Manager gebruikt in een multitenant-oplossing.