Delen via

Multitenancy en Azure Storage

  • Artikel

Azure Storage is een basisservice die in vrijwel elke oplossing wordt gebruikt. Multitenant-oplossingen maken vaak gebruik van Azure Storage voor blob-, bestands-, wachtrij- en tabelopslag. Op deze pagina beschrijven we enkele van de functies van Azure Storage die nuttig zijn voor multitenant-oplossingen. Vervolgens bieden we koppelingen naar de richtlijnen die u kunnen helpen wanneer u plant hoe u Azure Storage gaat gebruiken.

Functies van Azure Storage die ondersteuning bieden voor multitenancy

Azure Storage bevat veel functies die ondersteuning bieden voor multitenancy.

Shared Access Signatures

Wanneer u met Azure Storage werkt vanuit een clienttoepassing, is het belangrijk om na te gaan of clientaanvragen moeten worden verzonden via een ander onderdeel dat u bepaalt, zoals een netwerk voor contentlevering of API, of dat de client rechtstreeks verbinding moet maken met uw opslagaccount. Er kunnen goede redenen zijn om aanvragen via een ander onderdeel te verzenden, waaronder het opslaan van gegevens in de cache aan de rand van uw netwerk. In sommige situaties is het echter voordelig voor clienteindpunten om rechtstreeks verbinding te maken met Azure Storage om gegevens te downloaden of te uploaden. Deze verbinding helpt u de prestaties van uw oplossing te verbeteren, met name wanneer u met grote blobs of grote aantallen bestanden werkt. Het vermindert ook de belasting van uw back-endtoepassingen en -servers en vermindert het aantal netwerkhops. Met een Shared Access Signature (SAS) kunt u uw clienttoepassingen veilig toegang bieden tot objecten in Azure Storage.

Handtekeningen voor gedeelde toegang kunnen worden gebruikt om het bereik van bewerkingen te beperken die een client kan uitvoeren en de objecten waarop ze bewerkingen kunnen uitvoeren. Als u bijvoorbeeld een gedeeld opslagaccount hebt voor al uw tenants en u alle gegevens van tenant A opslaat in een blobcontainer met de naam tenanta, kunt u een SAS maken waarmee alleen tenant A's gebruikers toegang hebben tot die container. Zie Isolatiemodellen voor meer informatie over de benaderingen die u kunt gebruiken om de gegevens van uw tenants in een opslagaccount te isoleren.

Het valetsleutelpatroon is handig als een manier om beperkte en scope-handtekeningen voor gedeelde toegang vanuit uw toepassingslaag uit te geven. Stel dat u een toepassing met meerdere tenants hebt waarmee gebruikers video's kunnen uploaden. Uw API of toepassingslaag kan de client verifiëren met behulp van uw eigen verificatiesysteem. Vervolgens kunt u een SAS aan de client opgeven waarmee ze een videobestand kunnen uploaden naar een opgegeven blob, naar een container en blobpad dat u opgeeft. De client uploadt het bestand vervolgens rechtstreeks naar het opslagaccount, voorkomt de extra bandbreedte en belasting van uw API. Als ze gegevens uit de blobcontainer proberen te lezen of als ze proberen gegevens naar een ander deel van de container te schrijven naar een andere container in het opslagaccount, blokkeert Azure Storage de aanvraag. De handtekening verloopt na een configureerbare periode.

Opgeslagen toegangsbeleid breidt de SAS-functionaliteit uit, waarmee u één beleid kunt definiëren dat kan worden gebruikt bij het uitgeven van meerdere handtekeningen voor gedeelde toegang.

Toegangsbeheer op basis van identiteit

Azure Storage biedt ook toegangsbeheer op basis van identiteiten met behulp van Microsoft Entra ID. Met deze mogelijkheid kunt u ook toegangsbeheer op basis van kenmerken gebruiken, waardoor u nauwkeuriger toegang hebt tot blobpaden of blobs die zijn gelabeld met een specifieke tenant-id.

Levenscyclusbeheer

Wanneer u blobopslag gebruikt in een multitenant-oplossing, vereisen uw tenants mogelijk verschillende beleidsregels voor gegevensretentie. Wanneer u grote hoeveelheden gegevens opslaat, wilt u mogelijk ook de gegevens voor een specifieke tenant zo configureren dat ze automatisch worden verplaatst naar de statische opslaglagen of archiefopslaglagen voor kostenoptimalisatie.

Overweeg het gebruik van levenscyclusbeheerbeleid om de levenscyclus van de blob in te stellen voor alle tenants of voor een subset van tenants. Een levenscyclusbeheerbeleid kan worden toegepast op blobcontainers of op een subset van blobs binnen een container. Er gelden echter limieten voor het aantal regels dat u kunt opgeven in een levenscyclusbeheerbeleid. Zorg ervoor dat u uw gebruik van deze functie plant en test in een omgeving met meerdere tenants en overweeg om meerdere opslagaccounts te implementeren als u de limieten overschrijdt.

Onveranderbare opslag

Wanneer u onveranderbare blobopslag configureert in opslagcontainers met bewaarbeleid op basis van tijd, voorkomt Azure Storage dat de gegevens vóór een opgegeven tijd worden verwijderd of gewijzigd. De preventie wordt afgedwongen op de opslagaccountlaag en is van toepassing op alle gebruikers. Zelfs de beheerders van uw organisatie kunnen onveranderbare gegevens niet verwijderen.

Onveranderbare opslag kan handig zijn wanneer u met tenants werkt die wettelijke of nalevingsvereisten hebben om gegevens of records te onderhouden. U moet echter overwegen hoe deze functie wordt gebruikt binnen de context van de levenscyclus van uw tenant. Als tenants bijvoorbeeld offboarded zijn en het verwijderen van hun gegevens aanvragen, kunt u mogelijk niet voldoen aan hun aanvragen. Als u onveranderbare opslag gebruikt voor de gegevens van uw tenants, kunt u overwegen hoe u dit probleem in uw servicevoorwaarden kunt oplossen.

Kopie aan serverzijde

In een multitenant-systeem is het soms nodig om gegevens van het ene opslagaccount naar het andere te verplaatsen. Als u bijvoorbeeld een tenant verplaatst tussen implementatiestempels of een shard-set opslagaccounts opnieuw in evenwicht brengt, moet u de gegevens van een specifieke tenant kopiëren of verplaatsen. Wanneer u met grote hoeveelheden gegevens werkt, is het raadzaam om kopieer-API's aan de serverzijde te gebruiken om de tijd te verkorten die nodig is om de gegevens te migreren.

Het hulpprogramma AzCopy is een toepassing die u kunt uitvoeren vanaf uw eigen computer of vanaf een virtuele machine om het kopieerproces te beheren. AzCopy is compatibel met de functie voor kopiëren aan de serverzijde en biedt een scriptbare opdrachtregelinterface die u vanuit uw eigen oplossingen kunt uitvoeren. AzCopy is ook handig voor het uploaden en downloaden van grote hoeveelheden gegevens.

Als u de API's aan de serverzijde rechtstreeks vanuit uw code wilt gebruiken, kunt u overwegen om de PUT Block From URL-API, Put Page From URL API, Append Block From URL API en de Copy Blob From URL API te gebruiken wanneer u werkt met kleinere blobs.

Objectreplicatie

De functie Objectreplicatie repliceert automatisch gegevens tussen een bron- en doelopslagaccount. Objectreplicatie is asynchroon. In een multitenant-oplossing kan deze functie handig zijn wanneer u continu gegevens tussen implementatiestempels of in een implementatie van het geode-patroon moet repliceren.

Versleuteling

Met Azure Storage kunt u versleutelingssleutels voor uw gegevens opgeven. In een oplossing met meerdere tenants kunt u deze mogelijkheid combineren met versleutelingsbereiken, waarmee u verschillende versleutelingssleutels voor verschillende tenants kunt definiëren, zelfs als de gegevens in hetzelfde opslagaccount worden opgeslagen. Door deze functies samen te gebruiken, kunt u tenants ook controle geven over hun eigen gegevens. Als ze hun account moeten deactiveren, zorgt het verwijderen van de versleutelingssleutel ervoor dat hun gegevens niet meer toegankelijk zijn.

Controleren

Wanneer u met een multitenant-oplossing werkt, moet u het verbruik voor elke tenant meten en de specifieke metrische gegevens definiëren die u moet bijhouden, zoals de hoeveelheid opslagruimte die wordt gebruikt voor elke tenant (de capaciteit) of het aantal bewerkingen dat voor de gegevens van elke tenant wordt uitgevoerd. U kunt ook kostentoewijzing gebruiken om de kosten van het gebruik van elke tenant bij te houden en terugstorting in te schakelen voor meerdere abonnementen.

Azure Storage biedt ingebouwde bewakingsmogelijkheden. Het is belangrijk om rekening te houden met de services die u in het Azure Storage-account gaat gebruiken. Wanneer u bijvoorbeeld met blobs werkt, is het mogelijk om de totale capaciteit van een opslagaccount weer te geven, maar niet één container. Als u echter met bestandsshares werkt, is het mogelijk om de capaciteit voor elke share te zien, maar niet voor elke map.

U kunt ook alle aanvragen in Azure Storage registreren en deze logboeken vervolgens aggregeren en analyseren. Deze benadering biedt meer flexibiliteit bij het aggregeren en groeperen van gegevens voor elke tenant. In oplossingen die grote hoeveelheden aanvragen naar Azure Storage maken, is het echter belangrijk om na te gaan of het voordeel dat u krijgt van deze benadering de kosten rechtvaardigt die gepaard gaan met het vastleggen en verwerken van deze logboeken.

Azure Storage-inventaris biedt een andere methode om de totale grootte van een blobcontainer te meten.

Isolatiemodellen

Wanneer u werkt met een multitenant-systeem met behulp van Azure Storage, moet u een beslissing nemen over het isolatieniveau dat u wilt gebruiken. Azure Storage ondersteunt verschillende isolatiemodellen.

Opslagaccounts per tenant

Het sterkste isolatieniveau is het implementeren van een toegewezen opslagaccount voor een tenant. Dit zorgt ervoor dat alle opslagsleutels worden geïsoleerd en onafhankelijk kunnen worden gedraaid. Met deze aanpak kunt u uw oplossing schalen om limieten en quota te voorkomen die van toepassing zijn op elk opslagaccount, maar u moet ook rekening houden met het maximum aantal opslagaccounts dat kan worden geïmplementeerd in één Azure-abonnement.

Notitie

Azure Storage heeft veel quota en limieten die u moet overwegen wanneer u een isolatiemodel selecteert. Dit zijn onder andere Azure-servicelimieten, schaalbaarheidsdoelen en schaalbaarheidsdoelen voor de Azure Storage-resourceprovider.

Daarnaast biedt elk onderdeel van Azure Storage verdere opties voor tenantisolatie.

Isolatiemodellen voor Blob Storage

De volgende tabel bevat een overzicht van de verschillen tussen de belangrijkste tenancy-isolatiemodellen voor Azure Storage-blobs:

Overweging Gedeelde blobcontainers Blobcontainers per tenant Opslagaccounts per tenant
Gegevensisolatie Laag/middelgroot. Paden gebruiken om de gegevens van elke tenant of hiërarchische naamruimten te identificeren Gemiddeld. SAS-URL's met containerbereik gebruiken ter ondersteuning van beveiligingsisolatie Hoog
Isolatie van prestaties Beperkt Laag. De meeste quota en limieten zijn van toepassing op het hele opslagaccount Hoog
Implementatiecomplexiteit Beperkt Gemiddeld Hoog
Operationele complexiteit Beperkt Gemiddeld Hoog
Voorbeeldscenario Een klein aantal blobs per tenant opslaan SAS-URL's met tenantbereik uitgeven Afzonderlijke implementatiestempels voor elke tenant

Gedeelde blobcontainers

Wanneer u met blob-opslag werkt, kunt u ervoor kiezen om een gedeelde blobcontainer te gebruiken en kunt u vervolgens blobpaden gebruiken om gegevens voor elke tenant te scheiden:

Tenant-id Voorbeeld van blobpad
tenant-a https://contoso.blob.core.windows.net/sharedcontainer/tenant-a/blob1.mp4
tenant-b https://contoso.blob.core.windows.net/sharedcontainer/tenant-b/blob2.mp4

Hoewel deze aanpak eenvoudig te implementeren is, bieden blobpaden in veel scenario's onvoldoende isolatie tussen tenants. Dit komt doordat blobopslag geen concept van mappen of mappen biedt. Dit betekent dat u geen toegang kunt toewijzen aan alle blobs binnen een opgegeven pad. Azure Storage biedt echter een mogelijkheid om blobs weer te geven (opsommen) die beginnen met een opgegeven voorvoegsel. Dit kan handig zijn wanneer u met gedeelde blobcontainers werkt en geen toegangsbeheer op adreslijstniveau vereist.

De hiërarchische naamruimtefunctie van Azure Storage biedt de mogelijkheid om een sterker concept van een map of map te hebben, waaronder directoryspecifiek toegangsbeheer. Dit kan handig zijn in sommige scenario's met meerdere tenants waarin u blobcontainers hebt gedeeld, maar u toegang wilt verlenen tot de gegevens van één tenant.

In sommige multitenant-oplossingen hoeft u mogelijk slechts één blob of set blobs voor elke tenant op te slaan, zoals tenantpictogrammen voor het aanpassen van een gebruikersinterface. In deze scenario's kan één gedeelde blobcontainer voldoende zijn. U kunt de tenant-id gebruiken als de naam van de blob en vervolgens een specifieke blob lezen in plaats van een blobpad op te sommen.

Wanneer u met gedeelde containers werkt, kunt u overwegen of u het gegevens- en Azure Storage-servicegebruik voor elke tenant moet bijhouden en hoe u dit moet doen. Zie Bewaking voor meer informatie.

Blobcontainers per tenant

U kunt afzonderlijke blobcontainers maken voor elke tenant binnen één opslagaccount. Er is geen limiet voor het aantal blobcontainers dat u in een opslagaccount kunt maken.

Door containers voor elke tenant te maken, kunt u azure Storage-toegangsbeheer, inclusief SAS, gebruiken om de toegang voor de gegevens van elke tenant te beheren. U kunt ook eenvoudig de capaciteit bewaken die elke container gebruikt.

Isolatiemodellen voor bestandsopslag

De volgende tabel bevat een overzicht van de verschillen tussen de belangrijkste tenantisolatiemodellen voor Azure Storage-bestanden:

Overweging Gedeelde bestandsshares Bestandsshares per tenant Opslagaccounts per tenant
Gegevensisolatie Gemiddeld-hoog. Autorisatieregels toepassen voor tenantspecifieke bestanden en mappen Gemiddeld hoog Hoog
Isolatie van prestaties Beperkt Laag/middelgroot. De meeste quota en limieten zijn van toepassing op het hele opslagaccount, maar stel de groottequota in op een niveau per share Hoog
Implementatiecomplexiteit Beperkt Gemiddeld Hoog
Operationele complexiteit Beperkt Gemiddeld Hoog
Voorbeeldscenario Toepassing bepaalt alle toegang tot bestanden Tenants hebben toegang tot hun eigen bestanden Afzonderlijke implementatiestempels voor elke tenant

Gedeelde bestandsshares

Wanneer u met bestandsshares werkt, kunt u ervoor kiezen om een gedeelde bestandsshare te gebruiken en vervolgens kunt u bestandspaden gebruiken om gegevens voor elke tenant te scheiden:

Tenant-id Voorbeeldbestandspad
tenant-a https://contoso.file.core.windows.net/share/tenant-a/blob1.mp4
tenant-b https://contoso.file.core.windows.net/share/tenant-b/blob2.mp4

Wanneer u een toepassing gebruikt die kan communiceren met het SMB-protocol (Server Message Block), en wanneer u Active Directory-domein on-premises of in Azure services gebruikt, ondersteunen bestandsshares autorisatie op zowel de share- als de map-/bestandsniveaus.

In andere scenario's kunt u overwegen sas te gebruiken om toegang te verlenen tot specifieke bestandsshares of bestanden. Wanneer u SAS gebruikt, kunt u geen toegang verlenen tot mappen.

Wanneer u met gedeelde bestandsshares werkt, moet u overwegen of u het gegevens- en Azure Storage-servicegebruik voor elke tenant moet bijhouden en vervolgens een benadering moet plannen om dit te doen (indien nodig). Zie Bewaking voor meer informatie.

Bestandsshares per tenant

U kunt afzonderlijke bestandsshares maken voor elke tenant, binnen één opslagaccount. Er is geen limiet voor het aantal bestandsshares dat u in een opslagaccount kunt maken.

Door bestandsshares te maken voor elke tenant, kunt u toegangsbeheer van Azure Storage, inclusief SAS, gebruiken om de toegang voor de gegevens van elke tenant te beheren. U kunt ook eenvoudig de capaciteit bewaken die elke bestandsshare gebruikt.

Tabelopslagisolatiemodellen

De volgende tabel bevat een overzicht van de verschillen tussen de belangrijkste tenantisolatiemodellen voor Azure Storage-tabellen:

Overweging Gedeelde tabellen met partitiesleutels per tenant Tabellen per tenant Opslagaccounts per tenant
Gegevensisolatie Laag. Toepassing dwingt isolatie af Laag/gemiddeld Hoog
Isolatie van prestaties Beperkt Laag. De meeste quota en limieten zijn van toepassing op het hele opslagaccount Hoog
Implementatiecomplexiteit Beperkt Gemiddeld Hoog
Operationele complexiteit Beperkt Gemiddeld Hoog
Voorbeeldscenario Grote multitenant-oplossing met gedeelde toepassingslaag SAS-URL's met tenantbereik uitgeven Afzonderlijke implementatiestempels voor elke tenant

Gedeelde tabellen met partitiesleutels per tenant

Wanneer u tabelopslag met één gedeelde tabel gebruikt, kunt u overwegen de ingebouwde ondersteuning voor partitionering te gebruiken. Elke entiteit moet een partitiesleutel bevatten. Een tenant-id is vaak een goede keuze voor een partitiesleutel.

Met handtekeningen en beleidsregels voor gedeelde toegang kunt u een bereik voor partitiesleutels opgeven en zorgt Azure Storage ervoor dat aanvragen met de handtekening alleen toegang hebben tot de opgegeven partitiesleutelbereiken. Hiermee kunt u het valetsleutelpatroon implementeren, waardoor niet-vertrouwde clients toegang hebben tot de partitie van één tenant, zonder dat dit van invloed is op andere tenants.

Voor toepassingen op grote schaal kunt u de maximale doorvoer van elke tabelpartitie en het opslagaccount overwegen.

Tabellen per tenant

U kunt afzonderlijke tabellen maken voor elke tenant binnen één opslagaccount. Er is geen limiet voor het aantal tabellen dat u in een opslagaccount kunt maken.

Door tabellen te maken voor elke tenant, kunt u azure Storage-toegangsbeheer, inclusief SAS, gebruiken om de toegang voor de gegevens van elke tenant te beheren.

Isolatiemodellen voor wachtrijopslag

De volgende tabel bevat een overzicht van de verschillen tussen de belangrijkste tenantisolatiemodellen voor Azure Storage-wachtrijen:

Overweging Gedeelde wachtrijen Wachtrijen per tenant Opslagaccounts per tenant
Gegevensisolatie Beperkt Laag/gemiddeld Hoog
Isolatie van prestaties Beperkt Laag. De meeste quota en limieten zijn van toepassing op het hele opslagaccount Hoog
Implementatiecomplexiteit Beperkt Gemiddeld Hoog
Operationele complexiteit Beperkt Gemiddeld Hoog
Voorbeeldscenario Grote multitenant-oplossing met gedeelde toepassingslaag SAS-URL's met tenantbereik uitgeven Afzonderlijke implementatiestempels voor elke tenant

Gedeelde wachtrijen

Als u ervoor kiest om een wachtrij te delen, moet u rekening houden met de quota en limieten die van toepassing zijn. In oplossingen met een hoog aanvraagvolume kunt u overwegen of de doeldoorvoer van 2000 berichten per seconde voldoende is.

Wachtrijen bieden geen partitionering of subqueeën, zodat gegevens voor alle tenants kunnen worden gekruist.

Wachtrijen per tenant

U kunt afzonderlijke wachtrijen maken voor elke tenant binnen één opslagaccount. Er is geen limiet voor het aantal wachtrijen dat u in een opslagaccount kunt maken.

Door wachtrijen te maken voor elke tenant, kunt u azure Storage-toegangsbeheer, inclusief SAS, gebruiken om de toegang voor de gegevens van elke tenant te beheren.

Wanneer u dynamisch wachtrijen voor elke tenant maakt, kunt u overwegen hoe uw toepassingslaag de berichten uit de wachtrij van elke tenant verbruikt. Voor geavanceerdere scenario's kunt u overwegen Om Azure Service Bus te gebruiken, die functies zoals onderwerpen en abonnementen, sessies en automatisch doorsturen van berichten ondersteunt, wat nuttig kan zijn in een multitenant-oplossing.

Medewerkers

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

Hoofdauteur:

Andere Inzenders:

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

Volgende stappen

Bekijk de opslag- en gegevensbenaderingen voor multitenancy.