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 te overwegen 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 voor het implementeren van multitenant-oplossingen en laten we enkele benaderingen zien waarmee u rekening moet houden bij het plannen van uw implementatiestrategie.
Belangrijkste 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 een klein aantal tenants (zoals vijf of minder) te ondersteunen of groeit u uit naar een groot aantal tenants?
- Geautomatiseerde of ondersteunde onboarding: Wanneer een tenant klaar is voor onboarding, kan deze het proces dan zelf voltooien door een geautomatiseerde procedure te volgen? Of initiëren nieuwe tenants een aanvraag en onboardt u ze handmatig nadat u de aanvraag hebt ontvangen? Zijn er handmatige goedkeuringsstappen vereist van uw team, bijvoorbeeld om misbruik van uw service te voorkomen?
- Inrichtingstijd: Hoe snel moet het onboardingproces worden voltooid wanneer een tenant gereed is voor onboarding? 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 starten? Als u dat 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 onboardingwerkstroom omvat doorgaans het volgende:
- Aanvaarding van commerciële overeenkomsten.
- Verzameling van de informatie die u nodig hebt om uw systeem te configureren voor de nieuwe tenant.
- 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 dns-recordwijzigingen.
Documenteer duidelijk de werkstroom die nodig is voor het onboarden van een nieuwe tenant.
Overweeg ook de specifieke Azure-resources die u moet inrichten voor een tenant. Zelfs als u niet voor elke tenant toegewezen resources inricht, moet u overwegen of u soms resources moet implementeren wanneer een nieuwe tenant wordt toegevoegd. Dit kan gebeuren wanneer een tenant vereist dat de gegevens worden opgeslagen in een specifieke regio, of wanneer u de limieten van een stempel 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 gevolgen hebben voor de prestaties die andere tenants mogelijk merken? Overweeg of u deze effecten kunt voorkomen of kunt beperken door het onboardingproces buiten normale bedrijfsuren uit te voeren.
Automation
Geautomatiseerde implementaties zijn altijd raadzaam voor oplossingen die in de cloud worden gehost. Wanneer u met multitenant-oplossingen werkt, wordt implementatieautomatisering nog belangrijker om de volgende redenen:
- Schaal: Handmatige implementatieprocessen worden steeds complexer en tijdrovender naarmate uw tenantpopulatie toeneemt. Een geautomatiseerde implementatie is eenvoudiger te schalen naarmate het aantal tenants toeneemt.
- Herhaalbare: 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 andere niet. Deze handmatige processen laten uw omgeving in een inconsistente status achter, waardoor het moeilijker wordt voor uw team om de oplossing te beheren.
- Gevolgen 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 (als gevolg van een implementatiefout) hoog zijn, omdat elke tenant kan worden beïnvloed.
Wanneer u implementeert in een omgeving met meerdere tenants, moet u implementatiepijplijnen gebruiken en IaC-technologieën (infrastructure as code) gebruiken, zoals Bicep, JSON ARM-sjablonen, Terraform of de Azure SDK's.
Als u van plan bent om uw oplossing aan te bieden via de Azure Marketplace, moet u een volledig geautomatiseerd onboardingproces voor nieuwe tenants bieden. Dit proces wordt beschreven in de documentatie over SaaS-afhandelings-API's.
Maximale resourcecapaciteit
Wanneer u tenantresources programmatisch implementeert op gedeelde resources, moet u rekening houden met de capaciteitslimiet voor elke resource. Wanneer u deze limiet nadert, moet u mogelijk een ander exemplaar van de resource maken om verdere schaalaanpassing 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 Azure SQL logische server bevat en dat uw oplossing voor elke tenant een toegewezen database op die server inricht. Eén logische server heeft limieten, waaronder een maximum aantal databases dat door een logische server wordt ondersteund. Naarmate 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 een bepaald aantal tenants kiezen dat moet worden ondergebracht in één exemplaar van een resource, zodat het aantal tenants dat u hebt, bepaalt welke set resources u in Azure implementeert. In andere oplossingen implementeert u één set gedeelde resources en configureert u de resources opnieuw wanneer u nieuwe tenants onboardt.
Voor elk van deze modellen moet u resources op verschillende manieren implementeren en beheren, en u moet overwegen hoe u de levenscyclus van de resources die u inricht, gaat implementeren en beheren. Twee algemene benaderingen zijn als volgt:
- Tenants behandelen als configuratie van de resources die u implementeert en uw implementatiepijplijnen gebruiken om deze resources te implementeren en configureren.
- Als u tenants als gegevens wilt behandelen en een besturingsvlak wilt gebruiken om infrastructuur voor uw tenants in te richten en te configureren.
Hieronder vindt u meer informatie over deze benaderingen.
Testen
Plan uw oplossing grondig te testen tijdens en na elke implementatie. U kunt geautomatiseerd testen gebruiken om het functionele en niet-functionele gedrag van uw oplossing te controleren. Zorg ervoor dat u uw tenantisolatiemodel test en overweeg hulpprogramma's zoals Azure Chaos Studio te gebruiken om opzettelijk fouten te introduceren die uitval in de echte wereld simuleren en te controleren of uw oplossing werkt, zelfs wanneer een onderdeel niet beschikbaar of slecht werkt.
Benaderingen en patronen die u moet overwegen
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 aan één tenant zijn toegewezen. U kunt ervoor kiezen om één stempel te implementeren of u kunt een implementatie over meerdere stempels coördineren. Als u speciale stempels voor elke tenant implementeert, kunt u ook overwegen om hele stempels programmatisch te implementeren.
Implementatieringen
Met implementatieringen kunt u updates op verschillende tijdstippen implementeren voor verschillende groepen infrastructuur. Deze benadering wordt vaak gebruikt met het patroon Implementatiestempels en groepen stempels kunnen worden toegewezen aan verschillende 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 Configuration om uw functievlagmen te beheren. Zie Functievlagken voor meer informatie.
Soms moet u bepaalde functies selectief inschakelen voor bepaalde klanten. U kunt bijvoorbeeld verschillende prijscategorieën hebben die toegang tot bepaalde mogelijkheden toestaan. Functievlagmen zijn meestal niet de juiste keuze voor deze scenario's. Overweeg in plaats daarvan een proces te bouwen om de licentierechten van elke klant bij te houden en af te dwingen.
Antipatronen om te vermijden
Wanneer u multitenant-oplossingen implementeert en configureert, is het belangrijk om situaties te voorkomen die uw vermogen om te schalen belemmeren. Dit zijn onder andere de volgende:
- Handmatige implementatie en testen. Zoals hierboven beschreven, voegen handmatige implementatieprocessen risico's toe en vertragen de implementatie. Overweeg het gebruik van pijplijnen voor geautomatiseerde implementaties, het programmatisch maken van resources 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 functievlaggingen 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 nodig zijn. Gebruik een consistent en geautomatiseerd implementatieproces, zelfs voor tenants met geïsoleerde of toegewezen resources.
Tenantlijsten als configuratie of gegevens
U kunt de volgende twee benaderingen overwegen wanneer u resources implementeert in een oplossing met meerdere tenants:
- 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 de twee benaderingen overweegt, moet u onderscheid maken tussen het behandelen van uw tenantlijst als een configuratie of als gegevens. Dit onderscheid is ook belangrijk wanneer u overweegt 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 nieuwe tenants worden onboarding uitgevoerd, configureert u de pijplijn of de bijbehorende parameters opnieuw. Normaal gesproken vindt de herconfiguratie plaats via handmatige wijzigingen, zoals geïllustreerd in het volgende diagram.
Het proces voor het onboarden van een nieuwe tenant kan er ongeveer als volgt uitzien:
- 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.
- De pijplijn activeren om uit te voeren.
- Met de pijplijn wordt uw volledige set Azure-resources opnieuw geïmplementeerd, inclusief eventuele nieuwe tenantspecifieke resources.
Deze aanpak 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 wanneer u tenants toevoegt. De tijd die nodig is om de implementatiepijplijn uit te voeren, neemt vaak ook aanzienlijk toe. Deze benadering biedt ook geen eenvoudige ondersteuning voor het maken van selfservice-tenants en de doorlooptijd voordat een tenant wordt onboarding kan langer zijn omdat u de pijplijn moet activeren om uit te voeren.
Tenantlijst als gegevens
Wanneer u uw tenantlijst als gegevens behandelt, implementeert u nog steeds uw gedeelde onderdelen met behulp van een pijplijn. Voor resources en configuratie-instellingen die voor elke tenant moeten worden geïmplementeerd, moet u echter uw resources implementeren of configureren. Uw besturingsvlak kan bijvoorbeeld de Azure SDK's gebruiken om een specifieke resource te maken of om de implementatie van een sjabloon met parameters te initiëren.
Het proces voor het onboarden van een nieuwe tenant kan vergelijkbaar zijn met het volgende en zou asynchroon plaatsvinden:
- Vraag om onboarding van een tenant, bijvoorbeeld door het initiëren van een API-aanvraag naar het besturingsvlak van uw systeem.
- Een werkstroomonderdeel ontvangt de aanvraag voor het maken en organiseert de resterende stappen.
- De werkstroom initieert de implementatie van tenantspecifieke resources in 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.
- Wanneer de implementatie is voltooid, slaat de werkstroom de gegevens van de nieuwe tenant op in de centrale tenantcatalogus. De gegevens die voor elke tenant zijn opgeslagen, kunnen de tenant-id en de resource-id's bevatten voor alle tenantspecifieke resources die door de werkstroom zijn gemaakt.
Hiermee kunt u resources inrichten voor nieuwe tenants zonder uw hele oplossing opnieuw te implementeren. De tijd die nodig is om nieuwe resources voor elke tenant in te richten, is waarschijnlijk korter, omdat alleen deze resources hoeven te worden geïmplementeerd.
Deze aanpak kost echter vaak veel meer tijd om te bouwen en de moeite 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.
Notitie
Azure-implementatie- en configuratiebewerkingen nemen vaak tijd in beslag. Zorg ervoor dat u een geschikt proces gebruikt om deze langlopende bewerkingen te initiëren en te bewaken. U kunt bijvoorbeeld het patroon Asynchroon Request-Reply volgen. Gebruik technologieën die zijn ontworpen ter ondersteuning van langdurige bewerkingen, zoals Azure Logic Apps en Durable Functions.
Voorbeeld
Contoso voert een multitenant-oplossing uit voor hun klanten. Momenteel hebben ze zes tenants en ze verwachten in de komende 18 maanden te groeien naar 300 tenants. Contoso volgt de multitenant-app met toegewezen databases voor elke tenantbenadering . Ze hebben één set App Service resources en een Azure SQL logische 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 gebruiken voor alles
Contoso kan overwegen om al hun resources te implementeren met behulp van een implementatiepijplijn. Hun pijplijn implementeert een Bicep-bestand dat al hun 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 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 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 in de buurt zijn van limieten, bijvoorbeeld als ze met een onverwacht hoge snelheid groeien en het maximum aantal databases benaderen dat wordt ondersteund op één Azure SQL logische server.
Optie 2: gebruik een combinatie van implementatiepijplijnen en het maken van imperatieve resources
Contoso kan ook overwegen om de verantwoordelijkheid voor de Azure-implementaties te scheiden.
Contoso gebruikt een Bicep-bestand dat de gedeelde resources definieert die moeten worden geïmplementeerd. De gedeelde resources ondersteunen alle 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 activeert ook de API.
De API start asynchroon een werkstroom die de nieuwe tenants onboardt. De werkstroom initieert de implementatie van een nieuwe Azure SQL-database, die op een van de volgende manieren kan worden uitgevoerd:
- Gebruik de Azure SDK om de implementatie van een tweede Bicep-bestand te initiëren waarmee de Azure SQL-database wordt gedefinieerd.
- Gebruik de Azure SDK om een Azure SQL database 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 updates van databaseschema's worden geïnitieerd door hun toepassingslaag.
Medewerkers
Dit artikel wordt onderhouden door Microsoft. Het is oorspronkelijk geschreven door de volgende inzenders.
Hoofdauteur:
- John Downs - Nederland | Principal Customer Engineer, FastTrack voor Azure
Andere inzenders:
- Bohdan Cherchyk | Senior Customer Engineer, FastTrack voor Azure
- Arsen Vladimirskiy - Nederland | Principal Customer Engineer, FastTrack voor Azure
Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.