Overwegingen voor multitenant-besturingsvlakken

Een multitenant-oplossing heeft meerdere vlakken en elk heeft zijn eigen verantwoordelijkheden. Met het gegevensvlak kunnen eindgebruikers en clients communiceren met het systeem. Het besturingsvlak is het onderdeel dat taken op een hoger niveau beheert voor alle tenants, zoals toegangsbeheer, inrichting en systeemonderhoud ter ondersteuning van de taken van uw platformbeheerders.

Dit artikel bevat informatie over de verantwoordelijkheden van besturingsvlakken en het ontwerpen van een besturingsvlak dat aan uw behoeften voldoet.

Denk bijvoorbeeld aan een boekhoudsysteem voor het beheren van financiële records. Meerdere tenants slaan hun financiële records op in het systeem. Wanneer eindgebruikers toegang hebben tot het systeem om hun financiële records te bekijken en in te voeren, gebruiken ze het gegevensvlak. Het gegevensvlak is waarschijnlijk het primaire toepassingsonderdeel voor uw oplossing. Uw tenants beschouwen het waarschijnlijk als de manier om het systeem te gebruiken voor het beoogde doel. Het besturingsvlak is het onderdeel dat nieuwe tenants onboardt, databases voor elke tenant maakt en andere beheer- en onderhoudsbewerkingen uitvoert. Als het systeem geen besturingsvlak heeft, moeten beheerders veel handmatige processen uitvoeren. Of taken van het gegevensvlak en besturingsvlak worden gecombineerd, zodat de oplossing te veel wordt gecompliceerd.

Veel complexe systemen omvatten besturingsvlakken. Het Azure-besturingsvlak, Azure Resource Manager, is bijvoorbeeld een set API's, hulpprogramma's en back-endonderdelen die verantwoordelijk zijn voor het implementeren en configureren van Azure-resources. Het Kubernetes-besturingsvlak beheert veel taken, zoals de plaatsing van Kubernetes-pods op werkknooppunten. Bijna alle SaaS-oplossingen (Software as a Service) hebben een besturingsvlak voor het afhandelen van taken tussen tenants.

Wanneer u multitenant-oplossingen ontwerpt, moet u rekening houden met besturingsvlakken. De volgende secties bevatten de details die u nodig hebt om een besturingsvlak te bepalen en te ontwerpen.

Verantwoordelijkheden van een besturingsvlak

Er is geen enkele sjabloon voor een besturingsvlak of de bijbehorende verantwoordelijkheden. De vereisten en architectuur van uw oplossing bepalen wat uw besturingsvlak moet doen. In sommige multitenant-oplossingen heeft het besturingsvlak een breed scala aan verantwoordelijkheden en is het een complex systeem op zichzelf. In andere multitenant-oplossingen heeft het besturingsvlak alleen basisverantwoordelijkheden.

Over het algemeen kan een besturingsvlak veel van de volgende kernverantwoordelijkheden hebben:

• Richt de systeemresources in die het systeem nodig heeft voor de workload, inclusief tenantspecifieke resources. Uw besturingsvlak kan een implementatiepijplijn aanroepen en organiseren die verantwoordelijk is voor implementaties, of de implementatiebewerkingen zelf uitvoeren.
• Configureer gedeelde resources opnieuw om op de hoogte te zijn van nieuwe tenants. Uw besturingsvlak kan bijvoorbeeld netwerkroutering configureren om ervoor te zorgen dat binnenkomend verkeer is toegewezen aan de juiste tenantresources of dat u de resourcecapaciteit moet schalen.
• Sla de configuratie van elke tenant op en beheer deze.
• Afhandelen van tenantlevenscyclus-gebeurtenissen, waaronder onboarding, verplaatsing en offboarding-tenants.
• Houd het gebruik van uw functies en de prestaties van het systeem bij voor elke tenant.
• Meet het verbruik van elke tenant van de resources van uw systeem. Metrische verbruiksgegevens kunnen uw factureringssystemen informeren of ze kunnen worden gebruikt voor resourcebeheer.

Als u het volledig multitenant tenancymodel gebruikt en geen tenantspecifieke resources implementeert, kan een eenvoudig besturingsvlak alleen tenants en de bijbehorende metagegevens bijhouden. Wanneer een nieuwe tenant zich bijvoorbeeld aanmeldt bij uw service, kan het besturingsvlak de juiste records in een database bijwerken, zodat de rest van het systeem de aanvragen van de nieuwe tenant kan verwerken.

Stel dat uw oplossing gebruikmaakt van een implementatiemodel waarvoor tenantspecifieke infrastructuur is vereist, zoals het geautomatiseerde model met één tenant. In dit scenario heeft uw besturingsvlak mogelijk extra verantwoordelijkheden, zoals het implementeren of opnieuw configureren van de Azure-infrastructuur wanneer u een nieuwe tenant onboardt. Het besturingsvlak van uw oplossing moet waarschijnlijk communiceren met de besturingsvlakken voor de services en technologieën die u gebruikt, zoals Azure Resource Manager of het Kubernetes-besturingsvlak.

Meer geavanceerde besturingsvlakken kunnen ook meer verantwoordelijkheden aannemen:

• Voer geautomatiseerde onderhoudsbewerkingen uit. Veelvoorkomende onderhoudsbewerkingen zijn onder andere het verwijderen of archiveren van oude gegevens, het maken en beheren van databaseindexen en het roteren van geheimen en cryptografische certificaten.
• Wijs tenants toe aan bestaande implementaties of stempels, ook wel tenantplaatsing genoemd.
• Bestaande tenants opnieuw verdelen over implementatiestempels.
• Integreer met externe oplossingen voor klantbeheer, zoals Microsoft Dynamics 365, om klantactiviteiten bij te houden.

Bereik van een besturingsvlak

U moet zorgvuldig overwegen hoeveel moeite u moet besteden aan het bouwen van een besturingsvlak voor uw oplossing. Besturingsvlakken zelf bieden geen onmiddellijke klantwaarde, dus het is misschien niet eenvoudig om uitgaventechnisch werk te rechtvaardigen voor het ontwerpen en bouwen van een besturingsvlak van hoge kwaliteit. Naarmate uw systeem groeit en schaalt, hebt u echter steeds meer geautomatiseerd beheer en bewerkingen nodig om uw groei bij te houden.

In bepaalde situaties hebt u mogelijk geen volledig besturingsvlak nodig. Deze situatie kan van toepassing zijn als uw systeem minder dan vijf tenants heeft. In plaats daarvan kan uw team de verantwoordelijkheden van een besturingsvlak overnemen en handmatige bewerkingen en processen gebruiken om tenants te onboarden en te beheren. U moet echter nog steeds een proces en centrale plaats hebben om uw tenants en hun configuraties bij te houden.

Naarmate u verder gaat dan een paar tenants, profiteert u waarschijnlijk van een manier om elke tenant bij te houden en bewaking toe te passen op uw vloot van resources en tenants. Mogelijk merkt u ook dat uw team steeds meer tijd en moeite besteedt aan tenantbeheer. Of u merkt mogelijk bugs of operationele problemen vanwege inconsistenties op de manier waarop teamleden beheertaken uitvoeren. Als deze situaties zich voordoen, is het de moeite waard om een uitgebreider besturingsvlak te bouwen om deze verantwoordelijkheden op te nemen.

Een besturingsvlak ontwerpen

Nadat u de vereisten en het bereik van uw besturingsvlak hebt bepaald, moet u het ontwerpen en ontwerpen. Een besturingsvlak is een belangrijk onderdeel. U moet het zorgvuldig plannen, net zoals u de andere elementen van uw systeem zou plannen.

Goed ontworpen besturingsvlakken

Omdat een besturingsvlak een eigen systeem is, is het belangrijk om alle vijf de pijlers van het Azure Well-Architected Framework te overwegen wanneer u er een ontwerpt. In de volgende secties worden enkele specifieke gebieden gemarkeerd waarop u zich kunt richten.

Betrouwbaarheid

Besturingsvlakken zijn vaak essentiële onderdelen. Het is essentieel dat u het tolerantie- en betrouwbaarheidsniveau plant dat uw besturingsvlak nodig heeft.

Bedenk wat er gebeurt als uw besturingsvlak niet beschikbaar is. In extreme gevallen kan een storing in het besturingsvlak ertoe leiden dat uw hele oplossing niet beschikbaar is. Zelfs als uw besturingsvlak geen single point of failure is, kan een storing enkele van de volgende effecten hebben:

• Uw systeem kan geen nieuwe tenants onboarden, wat van invloed kan zijn op uw verkoop- en bedrijfsgroei.
• Uw systeem kan bestaande tenants niet beheren, wat resulteert in meer oproepen naar uw ondersteuningsteam.
• U kunt het verbruik van tenants niet meten of factureren voor hun gebruik, wat resulteert in omzetverlies.
• U kunt niet reageren op een beveiligingsincident door een tenant uit te schakelen of opnieuw te configureren.
• Onderhoudsschuld accumuleren, wat resulteert in langdurige schade aan het systeem. Als uw oplossing bijvoorbeeld 's nachts opschonen van oude gegevens vereist, kunnen uw schijven vollopen of kunnen uw prestaties afnemen.

Definieer serviceniveaudoelstellingen voor uw besturingsvlak, inclusief beschikbaarheidsdoelen, de beoogde hersteltijd (RTO) en de beoogde herstelpunt (RPO). De doelstellingen die u voor uw besturingsvlak instelt, kunnen afwijken van de doelstellingen die u uw klanten aanbiedt.

Volg de richtlijnen van Azure Well-Architected Framework voor het bouwen van betrouwbare oplossingen in uw systeem, inclusief uw besturingsvlak.

Beveiliging

Besturingsvlakken zijn vaak systemen met hoge bevoegdheden. Beveiligingsproblemen binnen een besturingsvlak kunnen catastrofale gevolgen hebben. Afhankelijk van het ontwerp en de functionaliteit kan een besturingsvlak kwetsbaar zijn voor veel verschillende soorten aanvallen, waaronder de volgende:

• Een besturingsvlak heeft mogelijk toegang tot sleutels en geheimen voor alle tenants. Een aanvaller die toegang heeft tot uw besturingsvlak, kan mogelijk toegang krijgen tot de gegevens of resources van een tenant.
• Een besturingsvlak kan vaak nieuwe resources implementeren in Azure. Aanvallers kunnen mogelijk gebruikmaken van uw besturingsvlak om hun eigen resources in uw abonnementen te implementeren, waardoor er mogelijk uitgebreide kosten in rekening worden gebracht.
• Als een aanvaller uw besturingsvlak offline brengt, kan er directe en langdurige schade aan uw systeem en uw bedrijf optreden. Zie Betrouwbaarheid , bijvoorbeeld gevolgen van een besturingsvlak dat niet beschikbaar is.

Wanneer u een besturingsvlak ontwerpt en implementeert, is het essentieel dat u de aanbevolen beveiligingsprocedures volgt en een uitgebreid bedreigingsmodel maakt om potentiële bedreigingen en beveiligingsproblemen in uw oplossing vast te leggen en te beperken. Zie de richtlijnen voor het Azure Well-Architected Framework voor het bouwen van veilige oplossingen voor meer informatie.

Operationele uitmuntendheid

Omdat een besturingsvlak een essentieel onderdeel is, moet u zorgvuldig overwegen hoe u het in productie implementeert en gebruikt.

Net als andere onderdelen van uw oplossing moet u niet-productie-exemplaren van uw besturingsvlak implementeren, zodat u de functionaliteit ervan grondig kunt testen. Als uw besturingsvlak implementatiebewerkingen uitvoert, kunt u overwegen hoe uw niet-productiebesturingsvlakken communiceren met uw Azure-omgeving en naar welk Azure-abonnement u niet-productieresources implementeert.

U moet ook plannen hoe u de toegang van uw team tot uw besturingsvlak bepaalt. Volg de aanbevolen procedures voor het verlenen van alleen de machtigingen die teamleden nodig hebben om hun taken uit te voeren. Naast het helpen voorkomen van beveiligingsincidenten, helpt deze aanpak om het effect van onbedoelde onjuiste configuratie te verminderen.

Onderdelen

Er is geen enkele sjabloon voor een besturingsvlak en de onderdelen die u ontwerpt en bouwt, zijn afhankelijk van uw vereisten. Meestal bestaat een besturingsvlak uit API's en achtergrondwerkrolonderdelen. In sommige oplossingen kan een besturingsvlak ook een gebruikersinterface bevatten.

Uw besturingsvlak isoleren van tenantworkloads

Het is een goede gewoonte om de resources van uw besturingsvlak te scheiden van de resources die worden gebruikt om de gegevensvlakken van uw tenants te bedienen. U moet bijvoorbeeld overwegen om afzonderlijke databaseservers, toepassingsservers en Azure-app Service-plannen en andere onderdelen te gebruiken. Het is vaak een goed idee om de resources van uw besturingsvlak in een afzonderlijke Azure-resourcegroep te houden van resources die tenantspecifieke resources bevatten.

Door uw besturingsvlak te isoleren van de workloads van tenants, profiteert u van verschillende voordelen:

• U kunt schalen afzonderlijk configureren. Uw besturingsvlak kan bijvoorbeeld consistente resourcevereisten hebben en de resources van uw tenants kunnen elastisch worden geschaald, afhankelijk van hun behoeften.
• Er is een schot tussen uw besturings- en gegevensvlakken, waarmee u kunt voorkomen dat lawaaierige burenproblemen zich verspreiden tussen de vliegtuigen van uw oplossing.
• Besturingsvlakken zijn doorgaans systemen met hoge bevoegdheden die hoge toegangsniveaus hebben. Door het besturingsvlak van gegevensvlakken te scheiden, vermindert u de kans dat aanvallers met een beveiligingsprobleem hun machtigingen in uw hele systeem kunnen verhogen.
• U kunt afzonderlijke netwerk- en firewallconfiguraties implementeren. Voor gegevensvlakken en besturingsvlakken zijn meestal verschillende typen netwerktoegang vereist.

Reeksen van langlopende bewerkingen organiseren

De bewerkingen die een besturingsvlak uitvoert, zijn vaak langlopend en omvatten coördinatie tussen meerdere systemen. De bewerkingen kunnen ook complexe foutmodi hebben. Wanneer u uw besturingsvlak ontwerpt, is het belangrijk om een geschikte technologie te gebruiken voor het coördineren van langdurige bewerkingen of werkstromen.

Stel dat wanneer u een nieuwe tenant onboardt, uw besturingsvlak de volgende acties op volgorde uitvoert:

1. Een nieuwe database implementeren. Deze actie is een Azure-implementatiebewerking. Het kan enkele minuten duren voordat het is voltooid.
2. Werk de metagegevenscatalogus van uw tenant bij. Deze actie kan betrekking hebben op het uitvoeren van een opdracht voor een Azure SQL-database.
3. Stuur een welkomstbericht naar de nieuwe tenant. Met deze actie wordt een API van derden aangeroepen om het e-mailbericht te verzenden.
4. Werk uw factureringssysteem bij om de nieuwe tenant voor te bereiden. Met deze actie wordt een API van derden aangeroepen. U hebt gemerkt dat het af en toe mislukt.
5. Werk uw CRM-systeem (Customer Relationship Management) bij om de nieuwe tenant bij te houden. Met deze actie wordt een API van derden aangeroepen.

Als een stap in de reeks mislukt, moet u overwegen wat u moet doen, zoals:

• Voer de mislukte bewerking opnieuw uit. Als uw Azure SQL-opdracht in stap 2 bijvoorbeeld mislukt met een tijdelijke fout, kunt u het opnieuw proberen.
• Ga door naar de volgende stap. U kunt bijvoorbeeld besluiten dat het acceptabel is als de update van uw factureringssysteem mislukt, omdat uw verkoopteam de klant handmatig toevoegt.
• De werkstroom verlaten en een handmatig herstelproces activeren.

U moet ook rekening houden met wat de gebruikerservaring is voor elk foutscenario.

Gedeelde onderdelen beheren

Een besturingsvlak moet op de hoogte zijn van alle onderdelen die niet zijn toegewezen aan specifieke tenants, maar in plaats daarvan worden gedeeld. Sommige onderdelen kunnen worden gedeeld tussen alle tenants binnen een stempel. Andere onderdelen kunnen worden gedeeld tussen alle stempels in een regio of zelfs wereldwijd worden gedeeld in alle regio's en stempels. Wanneer een tenant wordt onboarded, opnieuw geconfigureerd of offboarded, moet uw besturingsvlak weten wat u moet doen met deze gedeelde onderdelen.

Sommige gedeelde onderdelen moeten mogelijk opnieuw worden geconfigureerd wanneer een tenant wordt toegevoegd of verwijderd. Stel dat u een globaal gedeeld Azure Front Door-profiel hebt. Als u een tenant met een aangepaste domeinnaam toevoegt, moet het besturingsvlak mogelijk de configuratie van het profiel bijwerken om aanvragen voor die domeinnaam naar de juiste toepassing te routeren. Op dezelfde manier moet uw besturingsvlak, wanneer een tenant is uitgeschakeld, mogelijk de aangepaste domeinnaam verwijderen uit het Azure Front Door-profiel om overnameaanvallen voor subdomeinen te voorkomen.

Gedeelde onderdelen hebben mogelijk complexe schaalregels die uw besturingsvlak moet volgen. Stel dat u een bin-verpakkingsbenadering volgt om de databases van uw tenants te implementeren. Wanneer een nieuwe tenant wordt toegevoegd, voegt u een nieuwe Azure SQL-database voor die tenant toe en wijst u deze vervolgens toe aan een elastische Azure SQL-pool. Mogelijk hebt u vastgesteld dat u de resources moet verhogen die aan uw pool zijn toegewezen voor elke tiende database die u toevoegt. Wanneer u een tenant toevoegt of verwijdert, moet uw besturingsvlak de configuratie van de pool opnieuw evalueren en beslissen of u de resources van de pool wilt wijzigen. Wanneer u het maximum aantal databases bereikt dat u kunt toewijzen aan één elastische pool, moet u een nieuwe pool maken en die pool gaan gebruiken voor nieuwe tenantdatabases. Uw besturingsvlak moet verantwoordelijk zijn voor het beheren van elk van deze gedeelde onderdelen, het schalen en opnieuw configureren van onderdelen wanneer er iets verandert.

Wanneer uw besturingsvlak gedeelde onderdelen beheert, is het belangrijk dat u rekening moet houden met racevoorwaarden, die kunnen optreden wanneer er meerdere bewerkingen parallel plaatsvinden. Als u bijvoorbeeld een nieuwe tenant onboardt op hetzelfde moment dat u zich buiten een andere tenant bevindt, moet u ervoor zorgen dat uw uiteindelijke eindstatus consistent is en voldoet aan uw schaalvereisten.

Meerdere besturingsvlakken gebruiken

In een complexe omgeving moet u mogelijk meerdere besturingsvlakken gebruiken, elk met verschillende verantwoordelijkheden. Veel multitenant-oplossingen volgen het patroon Implementatiestempels en shard-tenants op meerdere stempels. Wanneer u dit patroon gebruikt, kunt u afzonderlijke besturingsvlakken maken voor globale en stempelverantwoordelijkheden.

Globale besturingsvlakken

Een globaal besturingsvlak is doorgaans verantwoordelijk voor het algehele beheer en het bijhouden van tenants. Een globaal besturingsvlak kan de volgende verantwoordelijkheden hebben:

• Tenantplaatsing. Het globale besturingsvlak bepaalt welke stempel een tenant moet gebruiken. Dit kan worden bepaald op basis van factoren zoals de regio van de tenant, het capaciteitsgebruik van elke zegel en de vereisten op serviceniveau van de tenant.
• Onboarding van tenants en levenscyclusbeheer. Deze verantwoordelijkheden omvatten het bijhouden van alle tenants in alle implementaties.

Stempelbesturingsvlakken

Er wordt een zegelbesturingsvlak geïmplementeerd in elke implementatiestempel en is verantwoordelijk voor de tenants en resources die aan die stempel zijn toegewezen. Een zegelbesturingsvlak kan deze verantwoordelijkheden hebben:

• Tenantspecifieke resources binnen de stempel maken en beheren, zoals databases en opslagcontainers
• Gedeelde resources beheren, inclusief het bewaken van het verbruik van gedeelde resources en het implementeren van nieuwe exemplaren wanneer ze hun maximale capaciteit naderen
• Onderhoudsbewerkingen uitvoeren binnen de stempel, zoals databaseindexbeheer en opschoningsbewerkingen

Het besturingsvlak van elke stempel coördineert met het globale besturingsvlak. Stel dat een nieuwe tenant zich registreert. Het globale besturingsvlak is in eerste instantie verantwoordelijk voor het selecteren van een stempel voor de resources van de tenant. Vervolgens vraagt het globale besturingsvlak het besturingsvlak van de stempel om de benodigde resources voor de tenant te maken.

In het volgende diagram ziet u een voorbeeld van hoe de twee besturingsvlakken naast elkaar kunnen bestaan in één systeem:

Tenantbesturingsvlakken

Tenants kunnen een besturingsvlak op tenantniveau gebruiken om hun eigen logische of fysieke resources te beheren. Een tenantbeheervlak kan de volgende verantwoordelijkheden hebben:

• Beheer van tenantspecifieke configuratie, zoals gebruikerstoegang
• Door tenant geïnitieerde onderhoudsbewerkingen, zoals het maken van back-ups van gegevens of het downloaden van een vorige back-up
• Updatebeheer, als u tenants toestaat hun eigen updates voor hun toepassingen te beheren

In het volgende diagram ziet u een complex systeem met een globaal besturingsvlak, stempelbesturingsvlakken en een besturingsvlak voor elke tenant:

Inzenders

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

Hoofdauteur:

• John Downs | Principal Customer Engineer, FastTrack voor Azure

Andere Inzenders:

• Mick Alberts | Technische schrijver
• Bohdan Cherchyk | Senior klanttechnicus, FastTrack voor Azure
• Landon Pierce | Klanttechnicus, FastTrack voor Azure
• Daniel Scott-Raynsford | PartnerTechnologie Strategist
• Arsen Vladimirskiy | Principal Customer Engineer, FastTrack voor Azure

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

Volgende stappen

• Overzicht van architectuuroverwegingen
• Azure Well-Architected Framework
• Architectuurbenaderingen voor besturingsvlakken in multitenant-oplossingen