Delen via

Overwegingen voor multitenant-besturingsvlakken

Een multitenant-oplossing heeft meerdere vlakken en elk vlak heeft zijn eigen verantwoordelijkheden. Met het gegevensvlak kunnen gebruikers en clients communiceren met een systeem. Het besturingsvlak beheert taken op hoger niveau, zoals toegangsbeheer, inrichting en systeemonderhoud, voor alle tenants om de taken van platformbeheerders te ondersteunen.

Diagram met een logisch systeemontwerp. Eén besturingsvlak biedt beheer over meerdere tenantspecifieke gegevensvlakken.

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 gebruikers 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. Tenants zien deze doorgaans als de hoofdinterface voor het gebruik van het systeem zoals bedoeld.

Het controlevlak voegt daarentegen nieuwe tenants toe, maakt databases voor elke tenant en voert andere beheer- en onderhoudsbewerkingen uit. Zonder een besturingsvlak moeten beheerders afhankelijk zijn van handmatige processen. In sommige gevallen raken gegevensvlak- en besturingsvlaktaken verstrengeld, waardoor oplossingen worden overcompliceerd.

Veel complexe systemen bevatten een besturingsvlak. Het Azure-besturingsvlak, Azure Resource Manager, is bijvoorbeeld een set API's, hulpprogramma's en back-endonderdelen die Azure-resources implementeren en configureren. En 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. In de volgende secties wordt beschreven hoe u een besturingsvlak kunt definiëren en 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 en hoe het werkt. 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:

Als u het volledig multitenant-model 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.

Als uw oplossing daarentegen gebruikmaakt van een implementatiemodel waarvoor tenantspecifieke infrastructuur is vereist, zoals het geautomatiseerde model met één tenant, heeft uw besturingsvlak mogelijk meer verantwoordelijkheden. Het kan nodig zijn om de Azure-infrastructuur te implementeren of opnieuw te configureren wanneer u een nieuwe tenant onboardt. In dit scenario communiceert het besturingsvlak waarschijnlijk met de besturingsvlakken voor andere hulpprogramma's, zoals Resource Manager of het Kubernetes-besturingsvlak.

Geavanceerde besturingsvlakken kunnen meer verantwoordelijkheden aannemen:

  • Geautomatiseerde onderhoudsbewerkingen: Het voert algemene onderhoudsbewerkingen uit, waaronder het verwijderen of archiveren van oude gegevens, het maken en beheren van databaseindexen en het roteren van geheimen en cryptografische certificaten.

  • Tenantplaatsing: Hiermee worden tenants toegewezen aan bestaande implementaties of stempels op basis van criteria, zoals zegelgebruiksdoelen, tenantvereisten en strategieën voor bin-verpakking.

  • Tenantherverdeling: Bestaande tenants worden opnieuw verdeeld over implementatiestempels wanneer hun gebruik verandert.

  • Tracering van klantactiviteiten: Het integreert met externe oplossingen voor klantbeheer, zoals Dynamics 365, om klantactiviteiten bij te houden.

Bereik van een besturingsvlak

Bedenk zorgvuldig hoeveel moeite u moet besteden aan het bouwen van een besturingsvlak voor uw oplossing. Een besturingsvlak biedt geen directe klantwaarde, waardoor het moeilijk kan zijn om technische inspanningen te rechtvaardigen bij 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 benadering werkt mogelijk als uw systeem minder dan 10 tenants heeft. Uw team kan de verantwoordelijkheden van het control plane op zich nemen en handmatige bewerkingen en processen gebruiken om tenants in te voegen en te beheren. U moet echter nog steeds een proces hebben en een centrale locatie onderhouden om uw tenants en hun configuraties bij te houden.

Aanbeveling

Als u geen volledig besturingsvlak maakt, moet u nog steeds een systematische benadering toepassen op uw beheerprocedures:

  • Documenteer uw processen grondig.
  • Maak en hergebruik indien mogelijk scripts voor uw beheerbewerkingen.

Als u in de toekomst processen wilt automatiseren, kunnen uw documentatie en scripts de basis vormen van uw besturingsvlak.

Naarmate u verder groeit dan een paar tenants, kunt u profiteren van het bijhouden van elke tenant en het toepassen van bewaking in uw vloot van resources en tenants. Mogelijk merkt u dat uw team steeds meer tijd en moeite besteedt aan tenantbeheer. Of u merkt mogelijk fouten of operationele problemen vanwege inconsistenties in de wijze waarop teamleden beheertaken uitvoeren. Als deze situaties zich voordoen, kunt u overwegen een uitgebreider besturingsvlak te bouwen om deze verantwoordelijkheden op te nemen.

Opmerking

Als u selfservicetenantbeheer biedt, hebt u vroeg in uw traject een besturingsvlak nodig. U kunt ervoor kiezen om een eenvoudig besturingsvlak te maken en slechts enkele van de meest gebruikte functionaliteit te automatiseren. U kunt geleidelijk meer mogelijkheden toevoegen in de loop van de tijd.

Een besturingsvlak ontwerpen

Nadat u de vereisten en het bereik van uw besturingsvlak hebt bepaald, moet u het ontwerpen en architecturen. Een besturingsvlak is een belangrijk onderdeel en verdient hetzelfde planningsniveau als elk ander deel van uw architectuur.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die u kunt gebruiken om de kwaliteit van een workload te verbeteren. Zie Well-Architected Framework voor meer informatie.

Een besturingsvlak fungeert als een eigen systeem, dus u moet alle vijf de pijlers van het Well-Architected Framework overwegen wanneer u er een ontwerpt. In de volgende secties worden bepaalde gebieden gemarkeerd waarop u zich kunt richten.

Betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie de controlelijst ontwerpbeoordeling voor betrouwbaarheid voor meer informatie.

Besturingsvlakken fungeren vaak als missiekritieke onderdelen. U moet het passende niveau van veerkracht en betrouwbaarheid plannen dat voor uw besturingsvlak vereist is.

Houd rekening met de impact van een storing in het besturingsvlak. In extreme gevallen kan een storing ervoor zorgen dat uw hele oplossing niet beschikbaar is. Zelfs als uw besturingslaag geen single point of failure is, kan een storing de volgende problemen veroorzaken:

  • 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 een tenant niet uitschakelen of opnieuw configureren als reactie op een beveiligingsincident.

  • Onderhoudsschuld accumuleren, wat resulteert in langdurige schade aan het systeem. Als uw oplossing bijvoorbeeld 's nachts opschonen van oude gegevens vereist, kunnen uw schijven vol raken 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 verschillen van de doelstellingen die u uw klanten aanbiedt.

Veiligheid

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie de controlelijst ontwerpbeoordeling voor beveiliging voor meer informatie.

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

  • Onbevoegde toegang tot geheimen: Een besturingsvlak heeft mogelijk toegang tot sleutels en geheimen voor alle tenants. Een aanvaller die toegang heeft tot uw besturingsvlak, kan toegang krijgen tot de gegevens of resources van een tenant.

  • Misbruik van implementatiemogelijkheden: Een besturingsvlak kan vaak nieuwe resources implementeren in Azure. Aanvallers kunnen uw besturingsvlak misbruiken om hun eigen resources in uw abonnementen te implementeren en mogelijk uitgebreide kosten in rekening te brengen.

  • Denial of Service: Als een aanvaller erin slaagt uw controlevlak uit te schakelen, kan dit directe en langdurige schade aan uw systeem en bedrijf veroorzaken. Zie Betrouwbaarheid voor de mogelijke gevolgen van controlevlak downtime.

Wanneer u een besturingsvlak ontwerpt en implementeert, moet u de aanbevolen beveiligingsprocedures volgen en een uitgebreid bedreigingsmodel maken. Dit model moet potentiële bedreigingen en beveiligingsproblemen in uw oplossing identificeren en beperken.

Operationele uitmuntendheid

Operational Excellence behandelt de operationele processen die een toepassing implementeren en deze in productie houden. Zie de controlelijst ontwerpbeoordeling voor Operational Excellence voor meer informatie.

Een besturingsvlak is een essentieel onderdeel, dus u moet 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 hun functionaliteit 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 wilt implementeren. Plan hoe u testbronnen snel kunt opschonen, zodat ze niet per ongeluk kosten veroorzaken.

Plan ook hoe u de toegang van uw team tot uw controlepaneel kunt reguleren. Alleen de machtigingen verlenen die teamleden nodig hebben om hun taken uit te voeren. Deze aanpak helpt beveiligingsincidenten te voorkomen en het effect van onbedoelde onjuiste configuratie te verminderen.

Onderdeel

Er is geen enkele sjabloon voor het bouwen van een besturingsvlak. De onderdelen die u ontwerpt en bouwt, zijn afhankelijk van uw vereisten. De meeste besturingsvlakken bestaan uit API's en achtergrondwerkonderdelen. In sommige oplossingen bevat een besturingsvlak ook een gebruikersinterface, die uw team of zelfs uw klanten kunnen gebruiken.

Uw besturingsvlak isoleren van tenantworkloads

U moet de resources van uw controlevlak scheiden van de resources die de datavlakken van uw tenants bedienen. Gebruik bijvoorbeeld afzonderlijke databaseservers, toepassingsservers en andere onderdelen. Beheervlakresources in een toegewezen Azure-resourcegroep houden, gescheiden van tenantspecifieke resources.

Isolatie van besturingsvlak biedt de volgende 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.

  • Een duidelijke scheiding creëert een schot tussen uw besturingsvlakken en gegevensvlakken, waardoor u kunt voorkomen dat lawaaierige buurproblemen zich verspreiden over uw oplossing.

  • Besturingsvlakken zijn doorgaans systemen met hoge bevoegdheden die hoge toegangsniveaus hebben. Isolatie van besturingsvlak vermindert de kans op een beveiligingsprobleem waardoor aanvallers hun machtigingen in uw hele systeem kunnen uitbreiden.

  • U kunt afzonderlijke netwerk- en firewallconfiguraties implementeren. Voor gegevensvlakken en besturingsvlakken zijn meestal verschillende typen netwerktoegang vereist.

Reeksen van langlopende bewerkingen organiseren

Controlevlakken voeren vaak langdurige bewerkingen uit waarvoor coördinatie tussen meerdere systemen vereist is. Deze bewerkingen kunnen ook complexe foutmodi hebben, dus u moet technologieën kiezen die langdurige bewerkingen of werkstromen ondersteunen.

Wanneer u bijvoorbeeld een nieuwe tenant onboardt, kan het beheerplatform de volgende acties in volgorde uitvoeren:

  1. Een nieuwe database implementeren. Het kan enkele minuten duren voordat deze Azure-implementatiebewerking 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 niet-Microsoft-API aangeroepen om het e-mailbericht te verzenden.

  4. Werk uw factureringssysteem bij om de nieuwe tenant voor te bereiden. Met deze actie wordt een niet-Microsoft-API aangeroepen die 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 niet-Microsoft-API aangeroepen.

Als een stap in de reeks mislukt, kunt u overwegen om te reageren:

  • 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 u de update van uw factureringssysteem kunt laten mislukken omdat uw verkoopteam de klant later handmatig kan toevoegen.

  • De werkstroom verlaten en een handmatig herstelproces activeren.

Houd ook rekening met de gebruikerservaring voor elk foutscenario.

Gedeelde onderdelen beheren

Een besturingsvlak moet alle onderdelen herkennen die worden gedeeld in plaats van toegewezen aan specifieke tenants. 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 u een tenant onboardt, opnieuw configureert of offboardt, moet uw besturingsvlak weten hoe u deze gedeelde onderdelen moet afhandelen.

Voor sommige gedeelde onderdelen is herconfiguratie vereist wanneer tenants worden 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. Als u bijvoorbeeld een bin-packing-benadering gebruikt om de databases van uw tenants te implementeren, moet de besturingslaag elke nieuwe database toewijzen aan een elastische Azure SQL-pool.

U kunt bepalen dat u de resources die aan uw pool zijn toegewezen, moet verhogen 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 gebruiken voor nieuwe tenantdatabases. Uw besturingsvlak moet elk van deze gedeelde onderdelen beheren, inclusief schalen en opnieuw configureren wanneer er wijzigingen optreden.

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 die verschillende gebieden beheren. Veel multitenant-oplossingen volgen het patroon Implementatiestempels en shard-tenants op meerdere stempels. In dit patroon kunt u afzonderlijke besturingsvlakken maken voor globale en stempelverantwoordelijkheden.

Aanbeveling

Het coördineren van meerdere besturingsvlakken voegt complexiteit toe, dus probeer het aantal besturingsvlakken dat u bouwt te minimaliseren. De meeste oplossingen hebben slechts één besturingsvlak nodig.

Globale besturingsvlakken

Een globaal controlevlak beheert doorgaans het algehele beheer en het bijhouden van huurders. 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 implementaties.

Stempelbesturingsvlakken

Elke implementatiestempel heeft een eigen besturingsvlak van de stempel, dat de tenants en resources beheert die aan die stempel zijn toegewezen. Een zegelbesturingsvlak kan de volgende verantwoordelijkheden hebben:

  • Tenantresourceinrichting: Er worden tenantspecifieke resources binnen de stempel gemaakt en beheerd, zoals databases en opslagcontainers.

  • Gedeeld resourcebeheer: Het bewaakt het verbruik van gedeelde resources en implementeert nieuwe exemplaren wanneer ze hun maximale capaciteit benaderen.

  • Onderhoudsbewerkingen: Het verwerkt taken binnen de stempel, zoals databaseindexbeheer en opschoningsbewerkingen.

Het besturingsvlak van elke stempel coördineert met het globale besturingsvlak. Als een nieuwe tenant zich bijvoorbeeld registreert, kan het globale besturingsvlak in eerste instantie een stempel voor de resources van de tenant selecteren. Vervolgens vraagt het globale besturingsvlak het besturingsvlak van de 'stamp' om de nodige middelen voor de huurder te creëren.

In het volgende diagram ziet u hoe twee besturingsvlakken naast elkaar kunnen bestaan in één systeem.

Diagram met een logisch systeemontwerp. Het ontwerp heeft een globaal besturingsvlak en stempelbesturingsvlakken.

Tenantbesturingsvlakken

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

  • Configuratiebeheer: Het verwerkt tenantspecifieke configuratie, zoals gebruikerstoegang.

  • Door tenant geïnitieerde onderhoudsbewerkingen: Het ondersteunt bewerkingen zoals het maken van back-ups van gegevens of het downloaden van eerdere back-ups.

  • Updatebeheer: Er worden updates uitgevoerd 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 tenantbesturingsvlakken.

Diagram met een logisch systeemontwerp. Het ontwerp heeft een globaal besturingsvlak, stempelcontrolevlakken en tenantcontrolevlakken.

Bijdragers

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

Hoofdauteur:

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

Andere Inzenders:

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

Volgende stap

  • Last updated on