Gegevens worden vaak beschouwd als het waardevolste onderdeel van een oplossing, omdat deze uw - en uw klanten - waardevolle bedrijfsgegevens vertegenwoordigt. Het is dus belangrijk om uw gegevens zorgvuldig te beheren. Bij het plannen van opslag- of gegevensonderdelen voor een systeem met meerdere tenants, moet u beslissen over een benadering voor het delen of isoleren van de gegevens van uw tenants.
In dit artikel bieden we richtlijnen over de belangrijkste overwegingen en vereisten die essentieel zijn voor oplossingsarchitecten bij het kiezen van een benadering voor het opslaan van gegevens in een multitenant-systeem. We raden vervolgens enkele algemene patronen aan voor het toepassen van multitenancy op opslag- en gegevensservices, en sommige antipatronen om te voorkomen. Ten slotte bieden we gerichte richtlijnen voor bepaalde specifieke situaties.
Belangrijke overwegingen en vereisten
Het is belangrijk om rekening te houden met de benaderingen die u gebruikt voor opslag- en gegevensservices vanuit een aantal perspectieven, die ongeveer overeenkomen met de pijlers van het Azure Well-Architected Framework.
Schaal wijzigen
Wanneer u werkt met services die uw gegevens opslaan, moet u rekening houden met het aantal tenants dat u hebt en het aantal gegevens dat u opslaat. Als u een klein aantal tenants (zoals vijf of minder) hebt en u kleine hoeveelheden gegevens voor elke tenant opslaat, is het waarschijnlijk een verspilde inspanning om een zeer schaalbare benadering voor gegevensopslag te plannen of om een volledig geautomatiseerde benadering te bouwen voor het beheren van uw gegevensresources. Maar naarmate u groeit, profiteert u steeds meer van een duidelijke strategie om uw gegevens en opslagbronnen te schalen en automatisering toe te passen op hun beheer. Wanneer u 50 tenants of meer hebt of als u van plan bent dat schaalniveau te bereiken, is het vooral belangrijk om uw gegevens- en opslagbenadering te ontwerpen, met schaal als belangrijke overweging.
Houd rekening met de mate waarin u van plan bent om te schalen en plan uw architectuurbenadering voor gegevensopslag duidelijk om te voldoen aan dat schaalniveau.
Voorspelbaarheid van prestaties
Multitenant-gegevens- en opslagservices zijn bijzonder gevoelig voor het probleem met Ruis. Het is belangrijk om na te gaan of uw tenants de prestaties van elkaar kunnen beïnvloeden. Hebben uw tenants bijvoorbeeld overlappende pieken in hun gebruikspatronen in de loop van de tijd? Gebruiken al uw klanten uw oplossing elke dag op hetzelfde moment of worden aanvragen gelijkmatig verdeeld? Deze factoren zijn van invloed op het isolatieniveau dat u moet ontwerpen, de hoeveelheid resources die u moet inrichten en de mate waarin resources kunnen worden gedeeld tussen tenants.
Het is belangrijk om rekening te houden met de resource en aanvraagquota van Azure als onderdeel van deze beslissing. Stel dat u één opslagaccount implementeert dat alle gegevens van uw tenants bevat. Als u een specifiek aantal opslagbewerkingen per seconde overschrijdt, weigert Azure Storage de aanvragen van uw toepassing en worden al uw tenants beïnvloed. Dit wordt beperkingsgedrag genoemd. Het is belangrijk dat u bewaakt op vertraagde aanvragen. Zie Richtlijnen voor opnieuw proberen voor Azure-services voor meer informatie.
Gegevensisolatie
Bij het ontwerpen van een oplossing die multitenant-gegevensservices bevat, zijn er meestal verschillende opties en niveaus van gegevensisolatie, elk met hun eigen voordelen en compromissen. Bijvoorbeeld:
- Wanneer u Azure Cosmos DB gebruikt, kunt u afzonderlijke containers implementeren voor elke tenant en kunt u databases en accounts delen tussen meerdere tenants. U kunt ook overwegen om verschillende databases of zelfs accounts voor elke tenant te implementeren, afhankelijk van het vereiste isolatieniveau.
- Wanneer u Azure Storage gebruikt voor blobgegevens, kunt u afzonderlijke blobcontainers implementeren voor elke tenant of kunt u afzonderlijke opslagaccounts implementeren.
- Wanneer u Azure SQL gebruikt, kunt u afzonderlijke tabellen in gedeelde databases gebruiken of afzonderlijke databases of servers implementeren voor elke tenant.
- In alle Azure-services kunt u overwegen om resources binnen één gedeeld Azure-abonnement te implementeren, of u kunt meerdere Azure-abonnementen gebruiken, misschien zelfs één per tenant.
Er is geen enkele oplossing die voor elke situatie werkt. De optie die u kiest, is afhankelijk van een aantal factoren en de vereisten van uw tenants. Als uw tenants bijvoorbeeld moeten voldoen aan specifieke nalevings- of regelgevingsstandaarden, moet u mogelijk een hoger isolatieniveau toepassen. Op dezelfde manier hebt u mogelijk commerciële vereisten om de gegevens van uw klanten fysiek te isoleren of moet u isolatie afdwingen om het probleem met Noisy Neighbor te voorkomen. Als tenants hun eigen versleutelingssleutels moeten gebruiken, hebben ze afzonderlijke beleidsregels voor back-up en herstel of moeten ze hun gegevens op verschillende geografische locaties opslaan, moet u ze mogelijk isoleren van andere tenants of groeperen met tenants die vergelijkbaar beleid hebben.
Complexiteit van de implementatie
Het is belangrijk om rekening te houden met de complexiteit van uw implementatie. Het is een goede gewoonte om uw architectuur zo eenvoudig mogelijk te houden, terwijl u nog steeds aan uw vereisten voldoet. Vermijd het doorvoeren van een architectuur die steeds complexer wordt wanneer u schaalt, of een architectuur die u niet over de resources of expertise beschikt om te ontwikkelen en te onderhouden.
Als uw oplossing niet hoeft te worden geschaald naar een groot aantal tenants, of als u geen zorgen hebt over prestaties of gegevensisolatie, is het beter om uw oplossing eenvoudig te houden en onnodige complexiteit toe te voegen.
Een bepaalde zorg voor multitenant-gegevensoplossingen is het aanpassingsniveau dat u ondersteunt. Kan een tenant bijvoorbeeld uw gegevensmodel uitbreiden of aangepaste gegevensregels toepassen? Zorg ervoor dat u vooraf ontwerpt voor deze vereiste. Vermijd forking of het leveren van aangepaste infrastructuur voor afzonderlijke tenants. Aangepaste infrastructuur remt uw vermogen om te schalen, uw oplossing te testen en updates te implementeren. Overweeg in plaats daarvan functievlagmen en andere vormen van tenantconfiguratie te gebruiken.
Complexiteit van beheer en bewerkingen
Bedenk hoe u uw oplossing wilt gebruiken en hoe uw multitenancy-benadering van invloed is op uw bewerkingen en processen. Bijvoorbeeld:
- Beheer: Overweeg beheerbewerkingen tussen tenants, zoals reguliere onderhoudsactiviteiten. Als u meerdere accounts, servers of databases gebruikt, hoe start en bewaakt u de bewerkingen voor elke tenant?
- Bewaking en meting: Als u uw tenants bewaakt of meet, kunt u overwegen hoe metrische gegevens van uw oplossing worden gerapporteerd en of deze eenvoudig kunnen worden gekoppeld aan de tenant die de aanvraag heeft geactiveerd.
- Rapportage: Rapportagegegevens van over geïsoleerde tenants vereisen mogelijk dat elke tenant gegevens publiceert naar een gecentraliseerd datawarehouse, in plaats van query's uit te voeren op elke database afzonderlijk en vervolgens de resultaten samen te voegen.
- Schema-updates: Als u een database gebruikt die een schema afdwingt, moet u plannen hoe u schema-updates in uw omgeving implementeert. Bedenk hoe uw toepassing weet welke schemaversie moet worden gebruikt voor de databasequery's van een specifieke tenant.
- Vereisten: Overweeg de vereisten voor hoge beschikbaarheid van uw tenants (bijvoorbeeld serviceovereenkomsten voor uptime of SLA's) en vereisten voor herstel na noodgevallen (bijvoorbeeld doelstellingen voor hersteltijd of RPO's en beoogde herstelpunten, of RPO's). Als tenants andere verwachtingen hebben, kunt u aan de vereisten van elke tenant voldoen?
- Migratie: Hoe migreert u tenants als ze moeten overstappen op een ander type service, een andere implementatie of een andere regio?
Kosten
Over het algemeen, hoe hoger de dichtheid van tenants voor uw implementatie-infrastructuur, hoe lager de kosten voor het inrichten van die infrastructuur. Gedeelde infrastructuur verhoogt echter de kans op problemen zoals het probleem met Ruis, dus overweeg de afwegingen zorgvuldig.
Benaderingen en patronen om rekening mee te houden
Verschillende ontwerppatronen van Het Azure Architecture Center zijn relevant voor opslag- en gegevensservices met meerdere tenants. U kunt ervoor kiezen om één patroon consistent te volgen. U kunt ook overwegen patronen te combineren en te vergelijken. U kunt bijvoorbeeld een database met meerdere tenants gebruiken voor de meeste tenants, maar u kunt zegels met één tenant implementeren voor tenants die meer betalen of die ongebruikelijke vereisten hebben. Op dezelfde manier is het vaak een goede gewoonte om te schalen met behulp van implementatiestempels, zelfs wanneer u een multitenant-database of shard-databases binnen een stempel gebruikt.
Patroon Implementatiestempels
Zie Overzicht voor meer informatie over hoe het patroon Implementatiestempels kan worden gebruikt ter ondersteuning van een multitenant-oplossing.
Gedeelde multitenantdatabases en bestandsarchieven
U kunt overwegen om een gedeelde multitenant-database, opslagaccount of bestandsshare te implementeren en deze te delen in al uw tenants.
Deze benadering biedt de hoogste dichtheid van tenants naar infrastructuur, dus het komt meestal tegen de laagste kosten van elke benadering. Het vermindert ook vaak de beheeroverhead, omdat er één database of resource is voor het beheren, maken van back-ups en beveiliging.
Wanneer u echter met een gedeelde infrastructuur werkt, moet u rekening houden met het volgende:
- Schaallimieten: Wanneer u afhankelijk bent van één resource, kunt u rekening houden met de ondersteunde schaal en limieten van die resource. De maximale grootte van één database of bestandsarchief, of de maximale doorvoerlimieten, wordt uiteindelijk een harde blokkering, als uw architectuur afhankelijk is van één database. Houd zorgvuldig rekening met de maximale schaal die u moet bereiken en vergelijk deze met uw huidige en toekomstige limieten voordat u dit patroon selecteert.
- Luidruchtige buren: het probleem met ruis buur kan een factor worden, met name als u tenants hebt die bijzonder bezet zijn of hogere workloads genereren dan anderen. Overweeg om het beperkingspatroon of het frequentiebeperkingspatroon toe te passen om deze effecten te beperken.
- Elke tenant bewaken: u kunt problemen ondervinden bij het bewaken van de activiteit en het meten van het verbruik voor één tenant. Sommige services, zoals Azure Cosmos DB, bieden rapportage over resourcegebruik voor elke aanvraag, zodat deze informatie kan worden bijgehouden om het verbruik voor elke tenant te meten. Andere services bieden niet hetzelfde detailniveau. De metrische gegevens van Azure Files voor bestandscapaciteit zijn bijvoorbeeld alleen beschikbaar per bestandssharedimensie, alleen wanneer u Premium-shares gebruikt. De standard-laag biedt echter alleen de metrische gegevens op het niveau van het opslagaccount.
- Tenantvereisten: tenants kunnen verschillende vereisten hebben voor beveiliging, back-up, beschikbaarheid of opslaglocatie. Als deze niet overeenkomen met de configuratie van uw individuele resource, kunt u deze mogelijk niet gebruiken.
- Schemaaanpassing: wanneer u met een relationele database werkt of een andere situatie waarin het schema van de gegevens belangrijk is, is het aanpassen van het schema op tenantniveau moeilijk.
Patroon Sharding
Het Sharding-patroon omvat het implementeren van meerdere afzonderlijke databases, shards genoemd, die elk een of meer tenantgegevens bevatten. In tegenstelling tot implementatiestempels impliceren shards niet dat de volledige infrastructuur wordt gedupliceerd. U kunt sharddatabases maken zonder ook andere infrastructuur in uw oplossing te dupliceren of sharden.
Sharding is nauw gerelateerd aan partitionering en de termen worden vaak door elkaar gebruikt. Houd rekening met de richtlijnen voor partitionering van horizontale, verticale en functionele gegevens.
Het Sharding-patroon kan worden geschaald naar zeer grote aantallen tenants. Afhankelijk van uw workload kunt u bovendien een hoge dichtheid van tenants tot shards bereiken, zodat de kosten aantrekkelijk kunnen zijn. Het Sharding-patroon kan ook worden gebruikt voor het aanpakken van Azure-abonnements- en servicequota, limieten en beperkingen.
Sommige gegevensarchieven, zoals Azure Cosmos DB, bieden systeemeigen ondersteuning voor sharding of partitionering. Wanneer u met andere oplossingen, zoals Azure SQL, werkt, kan het complexer zijn om een sharding-infrastructuur te bouwen en aanvragen naar de juiste shard te routeren voor een bepaalde tenant.
Sharding maakt het ook moeilijk om configuratieverschillen op tenantniveau te ondersteunen en klanten in staat te stellen hun eigen versleutelingssleutels te bieden.
Multitenant-app met toegewezen databases voor elke tenant
Een andere veelvoorkomende aanpak is het implementeren van één multitenant-toepassing, met toegewezen databases voor elke tenant.
In dit model worden de gegevens van elke tenant geïsoleerd van de andere en kunt u mogelijk een zekere mate van aanpassing voor elke tenant ondersteunen.
Omdat u toegewezen gegevensbronnen voor elke tenant inricht, kunnen de kosten voor deze benadering hoger zijn dan gedeelde hostingmodellen. Azure biedt echter verschillende opties die u kunt overwegen om de kosten voor het hosten van afzonderlijke gegevensbronnen over meerdere tenants te delen. Wanneer u bijvoorbeeld met Azure SQL werkt, kunt u elastische pools overwegen. Voor Azure Cosmos DB kunt u doorvoer inrichten voor een database en de doorvoer wordt gedeeld tussen de containers in die database, hoewel deze methode niet geschikt is wanneer u gegarandeerde prestaties voor elke container nodig hebt.
In deze benadering kunt u, omdat alleen de gegevensonderdelen afzonderlijk voor elke tenant worden geïmplementeerd, waarschijnlijk high-density bereiken voor de andere onderdelen in uw oplossing en de kosten van deze onderdelen verlagen.
Het is belangrijk om geautomatiseerde implementatiemethoden te gebruiken wanneer u databases inricht voor elke tenant.
Geodes-patroon
Het Geode-patroon is speciaal ontworpen voor geografisch gedistribueerde oplossingen, waaronder multitenant-oplossingen. Het ondersteunt hoge belasting en hoge mate van tolerantie. Als u het geode-patroon implementeert, moet uw gegevenslaag de gegevens in geografische regio's kunnen repliceren en moet deze schrijfbewerkingen voor meerdere geografische gebieden ondersteunen.
Azure Cosmos DB biedt schrijfbewerkingen met meerdere masters ter ondersteuning van dit patroon en Cassandra ondersteunt clusters met meerdere regio's. Andere gegevensservices kunnen dit patroon over het algemeen niet ondersteunen, zonder aanzienlijke aanpassingen.
Antipatroon om te voorkomen
Wanneer u multitenant-gegevensservices maakt, is het belangrijk om situaties te voorkomen die uw vermogen om te schalen remmen.
Voor relationele databases zijn dit onder andere:
- Isolatie op basis van tabellen. Wanneer u in één database werkt, vermijdt u het maken van afzonderlijke tabellen voor elke tenant. Een individuele database kan geen ondersteuning bieden voor zeer grote aantallen tenants wanneer u deze benadering gebruikt en het wordt steeds moeilijker om gegevens op te vragen, te beheren en bij te werken. In plaats daarvan kunt u overwegen om één set multitenant-tabellen met een tenant-id-kolom te gebruiken. U kunt ook een van de hierboven beschreven patronen gebruiken om afzonderlijke databases voor elke tenant te implementeren.
- Aanpassing van tenant op kolomniveau. Vermijd het toepassen van schema-updates die alleen van toepassing zijn op één tenant. Stel dat u één multitenant-database hebt. Vermijd het toevoegen van een nieuwe kolom om te voldoen aan de vereisten van een specifieke tenant. Het kan acceptabel zijn voor een klein aantal aanpassingen, maar dit wordt snel onbeheerd wanneer u een groot aantal aanpassingen moet overwegen. U kunt in plaats daarvan uw gegevensmodel herzien om aangepaste gegevens voor elke tenant in een toegewezen tabel bij te houden.
- Handmatige schemawijzigingen. Vermijd het handmatig bijwerken van uw databaseschema, zelfs als u slechts één gedeelde database hebt. Het is eenvoudig om de updates die u hebt toegepast, te verliezen en als u wilt uitschalen naar meer databases, is het lastig om het juiste schema te identificeren dat moet worden toegepast. Bouw in plaats daarvan een geautomatiseerde pijplijn om uw schemawijzigingen te implementeren en gebruik deze consistent. Houd de schemaversie bij die wordt gebruikt voor elke tenant in een toegewezen database of opzoektabel.
- Versieafhankelijkheden. Vermijd dat uw toepassing afhankelijk is van één versie van uw databaseschema. Wanneer u schaalt, moet u mogelijk schema-updates toepassen op verschillende tijdstippen voor verschillende tenants. Zorg er in plaats daarvan voor dat uw toepassingsversie achterwaarts compatibel is met ten minste één schemaversie en vermijd destructieve schema-updates.
Databases
Er zijn enkele functies die nuttig kunnen zijn voor multitenancy. Deze zijn echter niet beschikbaar in alle databaseservices. Overweeg of u deze nodig hebt wanneer u besluit welke service u voor uw scenario wilt gebruiken:
- Beveiliging op rijniveau kan beveiligingsisolatie bieden voor de gegevens van specifieke tenants in een gedeelde multitenant-database. Deze functie is beschikbaar in Azure SQL en Postgres Flex, maar is niet beschikbaar in andere databases, zoals MySQL of Azure Cosmos DB.
- Versleuteling op tenantniveau kan vereist zijn om tenants te ondersteunen die hun eigen versleutelingssleutels voor hun gegevens bieden. Deze functie is beschikbaar in Azure SQL als onderdeel van Always Encrypted. Azure Cosmos DB biedt door de klant beheerde sleutels op accountniveau en biedt ook ondersteuning voor Always Encrypted.
- Resourcepooling biedt de mogelijkheid om resources en kosten te delen tussen meerdere databases of containers. Deze functie is beschikbaar in elastische pools en beheerde exemplaren van Azure SQL en in de doorvoer van de Azure Cosmos DB-database, hoewel elke optie beperkingen heeft waar u rekening mee moet houden.
- Sharding en partitionering hebben sterkere systeemeigen ondersteuning in sommige services dan andere. Deze functie is beschikbaar in Azure Cosmos DB, met behulp van logische en fysieke partitionering en in PostgreSQL Hyperscale. Hoewel Azure SQL geen systeemeigen ondersteuning biedt voor sharding, biedt azure SQL sharding-hulpprogramma's ter ondersteuning van dit type architectuur.
Wanneer u werkt met relationele databases of andere op schema's gebaseerde databases, moet u ook overwegen waar het schema-upgradeproces moet worden geactiveerd wanneer u een vloot van databases onderhoudt. In een klein domein van databases kunt u overwegen om een implementatiepijplijn te gebruiken om schemawijzigingen te implementeren. Naarmate u groeit, is het mogelijk beter voor uw toepassingslaag om de schemaversie voor een specifieke database te detecteren en het upgradeproces te starten.
Bestands- en blobopslag
Houd rekening met de benadering die u gebruikt om gegevens binnen een opslagaccount te isoleren. U kunt bijvoorbeeld afzonderlijke opslagaccounts implementeren voor elke tenant of u kunt opslagaccounts delen en afzonderlijke containers implementeren. U kunt ook gedeelde blobcontainers maken en vervolgens het blobpad gebruiken om gegevens voor elke tenant te scheiden. Overweeg limieten en quota voor Azure-abonnementen en plan uw groei zorgvuldig om ervoor te zorgen dat uw Azure-resources worden geschaald om uw toekomstige behoeften te ondersteunen.
Als u gedeelde containers gebruikt, moet u uw verificatie- en autorisatiestrategie zorgvuldig plannen om ervoor te zorgen dat tenants geen toegang hebben tot elkaars gegevens. Houd rekening met het valetsleutelpatroon wanneer u clients toegang geeft tot Azure Storage-resources.
Kostenverdeling
Overweeg hoe u het verbruik meet en kosten toewijst aan tenants, voor het gebruik van gedeelde gegevensservices. Probeer waar mogelijk ingebouwde metrische gegevens te gebruiken in plaats van uw eigen metrische gegevens te berekenen. Met een gedeelde infrastructuur is het echter moeilijk om telemetrie te splitsen voor afzonderlijke tenants en moet u aangepaste metingen op toepassingsniveau overwegen.
In het algemeen bieden cloudeigen services, zoals Azure Cosmos DB en Azure Blob Storage, gedetailleerdere metrische gegevens om het gebruik voor een specifieke tenant bij te houden en te modelleren. Azure Cosmos DB biedt bijvoorbeeld de verbruikte doorvoer voor elke aanvraag en elk antwoord.
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:
- Paul Burpo | Principal Customer Engineer, 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
Zie voor meer informatie over multitenancy en specifieke Azure-services: