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 kunt u overwegen hoe u uw Azure-resources implementeert, met name wanneer u toegewezen resources voor elke tenant implementeert of resources dynamisch configureert op basis van het aantal tenants in uw systeem. Dit artikel biedt oplossingsarchitecten richtlijnen voor het implementeren van multitenant-oplossingen. Het laat zien hoe u rekening moet houden bij het plannen van uw implementatiestrategie.

Belangrijke overwegingen en vereisten

Definieer uw vereisten duidelijk voordat u uw implementatiestrategie plant. Houd rekening met de volgende factoren:

• Verwachte schaal: Bepaal of u verwacht slechts een paar tenants te ondersteunen, zoals vijf of minder, of om te groeien tot een groot aantal tenants. Naarmate het aantal tenants groeit, wordt automatisering steeds belangrijker.

• Geautomatiseerde of ondersteunde onboarding: Geef op of tenants onboarding moeten voltooien via een geautomatiseerde procedure of een aanvraag moeten initiëren waarvoor handmatige onboarding is vereist. Definieer handmatige goedkeuringsstappen van uw team, bijvoorbeeld om misbruik van uw service te voorkomen.

• Inrichtingstijd: Bepalen hoe snel het onboardingproces moet worden voltooid. Als u geen duidelijk antwoord hebt, definieert u of deze stap moet worden gemeten in seconden, minuten, uren of dagen.

• Azure Marketplace: Controleer of u Azure Marketplace wilt gebruiken om de implementatie te starten. Als u dit doet, voldoet u aan de vereiste vereisten om nieuwe tenants toe te voegen.

Overweeg ook stappen voor onboarding en inrichting, automatisering en verantwoordelijkheid voor resourcebeheer.

Stappen voor onboarding en inrichting

Definieer en documenteer elke taak die nodig is voor het onboarden van een tenant, zelfs als het proces handmatig is. De onboardingwerkstroom bevat doorgaans de volgende stappen:

1. Accepteer commerciële overeenkomsten.
2. Voltooi handmatige goedkeuringsstappen, bijvoorbeeld om fraude of misbruik van uw service te voorkomen.
3. Resources inrichten in Azure.
4. Domeinnamen maken of configureren.
5. 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.
6. Pas handmatige configuratiewijzigingen toe, zoals DNS-recordwijzigingen (Domain Name System).

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

Houd 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 scenario kan zich voordoen wanneer een tenant gegevensopslag in een specifieke regio vereist. Het kan ook optreden wanneer u een methode voor het verpakken van containers gebruikt. Wanneer u bij het inpakken van containers de limieten van een stempel of onderdeel in uw oplossing nadert, maakt u een ander exemplaar voor de volgende batch tenants.

Overweeg of het onboardingproces andere tenants kan verstoren, met name tenants die dezelfde infrastructuur delen. Als u bijvoorbeeld gedeelde databases wilt wijzigen, moet u bepalen of dit proces een invloed kan 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.

Automatisering

U moet geautomatiseerde implementaties gebruiken voor cloud-hostende oplossingen. In multitenant-oplossingen wordt automatisering om de volgende redenen nog belangrijker:

• Schub: Naarmate uw tenantpopulatie toeneemt, worden handmatige implementatieprocessen steeds complexer en tijdrovender. Een geautomatiseerde implementatiebenadering is eenvoudiger te schalen naarmate het aantal tenants groeit.

• Herhaalbare: Gebruik in een omgeving met meerdere tenants een consistent proces voor implementaties in alle tenants. Handmatige processen introduceren de kans op fouten of inconsistente stappen in tenants. Uw omgeving kan vervolgens in een inconsistente status worden achtergelaten, waardoor uw team de oplossing moeilijker kan beheren.

• Gevolgen van storingen: Handmatige implementaties zijn riskanter en gevoeliger voor storingen dan geautomatiseerde implementaties. In een omgeving met meerdere tenants kan een implementatiefout leiden tot een systeembrede storing die van invloed is op elke tenant, waardoor de algehele impact toeneemt.

Wanneer u implementeert in een omgeving met meerdere tenants, volgt u deze procedures:

• Implementatiepijplijnen gebruiken om algemene resources te implementeren.

• Gebruik infrastructuur als codetechnologieën (IaC), zoals Bicep, JSON Azure Resource Manager-sjablonen (ARM-sjablonen) of Terraform.

• Gebruik code om Azure SDK's aan te roepen, indien van toepassing.

Als u uw oplossing wilt aanbieden via Azure Marketplace, moet u een volledig geautomatiseerd onboardingproces bieden voor nieuwe tenants.

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 activeren om een ander exemplaar te implementeren.

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

Verantwoordelijkheid voor resourcebeheer

In sommige multitenant-oplossingen implementeert u resources met behulp van een van de verschillende modellen. Implementeer toegewezen Azure-resources voor elke tenant, zoals een database voor elke tenant. U kunt ook een vast aantal tenants definiëren dat moet worden ondergebracht op één exemplaar van een resource, dus het aantal tenants dat u hebt dicteert de set resources die u in Azure implementeert. In andere oplossingen implementeert u één set gedeelde resources en configureert u ze opnieuw wanneer u nieuwe tenants onboardt.

Voor elk van deze modellen moet u resources op verschillende manieren implementeren en beheren. U moet rekening houden met het implementeren en beheren van de levenscyclus van de resources die u inricht. Overweeg twee algemene benaderingen:

• Behandelt tenants als configuratie van geïmplementeerde resources en gebruik uw implementatiepijplijnen om deze resources te implementeren en te configureren.

• Tenants behandelen als gegevens en hebben een besturingsvlak inrichten en infrastructuur configureren voor uw tenants.

In de volgende secties worden deze benaderingen nader beschreven.

Testen

Test uw oplossing grondig 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. Overweeg het gebruik van hulpprogramma's zoals Azure Chaos Studio om opzettelijk fouten te introduceren die echte storingen simuleren en controleren of uw oplossing functioneert, zelfs wanneer een onderdeel niet beschikbaar of defect raakt.

Benaderingen en patronen om rekening mee te houden

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

Patroon voor implementatiestempels

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

Implementatieringen

Gebruik implementatieringen om updates uit te rollen voor verschillende groepen infrastructuur op verschillende momenten. Deze benadering vormt vaak een aanvulling op het patroon Implementatiestempels. Wijs groepen stempels toe aan afzonderlijke ringen op basis van tenantvoorkeuren, workloadtypen en andere overwegingen. Zie Implementatieringen voor meer informatie.

Functievlaggen

Gebruik functievlagmen om geleidelijk nieuwe functies of versies van uw oplossing beschikbaar te maken voor verschillende tenants of gebruikers zonder code opnieuw te implementeren. Overweeg het gebruik van Azure App Configuration om uw functievlagmen te beheren. Zie Functievlagmen voor meer informatie.

Soms moet u specifieke functies voor specifieke 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.

Antipatronen die je moet vermijden

Wanneer u multitenant-oplossingen implementeert en configureert, vermijdt u situaties die uw vermogen om te schalen remmen. In de volgende voorbeelden worden veelvoorkomende antipatroonmen gemarkeerd:

• Handmatige implementatie en testen: Handmatige implementatieprocessen voegen risico's toe en vertragen uw 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. 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 ze zijn vereist. Gebruik een consistent en geautomatiseerd implementatieproces, zelfs voor tenants met geïsoleerde of toegewezen resources.

Tenantlijsten als configuratie of gegevens

Houd rekening met de volgende 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. Maak tenantspecifieke resources in uw toepassing.

Wanneer u rekening houdt met de twee benaderingen, maakt u onderscheid tussen het behandelen van uw tenantlijst als een configuratie of als gegevens. Dit onderscheid is ook van invloed op 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 weergegeven in het volgende diagram.

Het onboardingproces voor een nieuwe tenant omvat doorgaans de volgende stappen:

1. Werk de tenantlijst handmatig bij door de pijplijn te configureren of 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 goed voor kleine aantallen tenants en architecturen waar alle resources worden gedeeld. Met één proces worden al uw Azure-resources geïmplementeerd en geconfigureerd, wat de algehele benadering vereenvoudigt.

Naarmate het aantal tenants echter toeneemt, vaak ongeveer 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 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 Azure SDK's gebruiken om een specifieke resource te maken of de implementatie van een geparameteriseerde sjabloon te starten.

Het onboardingproces omvat doorgaans de volgende asynchrone stappen:

1. Aanvraag voor onboarding van een tenant, zoals het initiëren van een API-aanvraag naar 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. U kunt een imperatief programmeermodel, zoals Azure SDK's, gebruiken of de implementatie van een Bicep-bestand of Terraform-sjabloon imperatief 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.

Met deze benadering kunt u resource inrichten voor nieuwe tenants zonder de hele oplossing opnieuw te implementeren. De inrichtingstijd is doorgaans korter omdat alleen tenantspecifieke resources worden geïmplementeerd.

Deze benadering is echter vaak veel tijdrovender om te bouwen. Uw inspanningen moeten worden gerechtvaardigd door het aantal tenants of de inrichtingsperioden waaraan u moet voldoen.

Zie Overwegingen voor multitenant besturingsvlakken voor meer informatie.

Voorbeeld

Contoso voert een multitenant-oplossing uit voor hun klanten. Ze hebben zes tenants en verwachten dat ze binnen de komende 18 maanden tot 300 tenants groeien. Contoso volgt de multitenant-app met toegewezen databases voor elke tenantbenadering . Ze implementeren één set Azure App Service-resources en een logische Azure SQL-server die alle tenants delen. Ze implementeren ook 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 al hun resources 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. Het Bicep-bestand maakt gebruik van een resourcelus om een database te implementeren voor elk van de vermelde tenants, zoals wordt weergegeven in het volgende diagram.

Als Contoso dit model volgt, moeten ze de volgende stappen uitvoeren:

1. Werk het parameterbestand bij als onderdeel van het onboarden van een nieuwe tenant.

2. Voer de pijplijn opnieuw uit.

3. Resourcelimieten handmatig bijhouden, 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 de verantwoordelijkheid voor de Azure-implementaties scheiden.

Contoso maakt gebruik van een Bicep-bestand dat gedeelde resources definieert voor de implementatie. De gedeelde resources ondersteunen alle tenants en bevatten een tenantcatalogusdatabase, ook wel een tenantlijstdatabase genoemd, zoals wordt weergegeven in het volgende diagram.

Het Contoso-team bouwt een besturingsvlak met een onboarding-API voor tenants. Wanneer het verkoopteam de verkoop naar een nieuwe klant voltooit, activeert Microsoft Dynamics de API om het onboardingproces te starten. Contoso biedt ook een selfservicewebinterface die klanten gebruiken om dezelfde API te activeren.

De API start asynchroon een werkstroom die de nieuwe tenants onboardt. De werkstroom initieert de implementatie van een nieuwe Azure SQL-database, die een van de volgende methoden kan gebruiken:

• 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. De toepassingslaag initieert doorlopende updates voor databaseschema's.

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Hoofdauteur:

• John Downs | Principal Software Engineer, Azure Patterns & Practices

Andere Inzenders:

• Bohdan Cherchyk | Senior klanttechnicus, FastTrack voor Azure
• Arsen Vladimirskiy | Hoofdklantingenieur, FastTrack voor Azure

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

Verwante middelen

• Overwegingen voor het bijwerken van een multitenant-oplossing.
• Architectuurbenaderingen voor opslag en gegevens.
• Gebruik Azure Resource Manager in een multitenant-oplossing.