Multitenancy en Azure Storage

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

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 vanuit een clienttoepassing werkt, is het belangrijk om te overwegen of clientaanvragen moeten worden verzonden via een ander onderdeel dat u controleert, 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 te verzenden via een ander onderdeel, waaronder het opslaan van gegevens in deaching aan de rand van uw netwerk. In sommige gevallen is het echter voordeliger voor client-eindpunten om rechtstreeks verbinding te maken met Azure Storage gegevens te downloaden of 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 te beperken van bewerkingen die een client kan uitvoeren en de objecten waarmee ze bewerkingen kunnen uitvoeren. Als u bijvoorbeeld een gedeeld opslagaccount hebt voor al uw tenants en u alle gegevens van tenant A opgeslagen in een blobcontainer met de naam , kunt u een SAS maken die alleen gebruikers van tenant A toegang geeft tot die tenanta container. Zie Isolatiemodellen voor meer informatie om de benaderingen te verkennen 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 bereikbare shared access signatures uit te geven vanuit uw toepassingslaag. Stel bijvoorbeeld dat u een multitenant-toepassing 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 verstrekken 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, waardoor de extra bandbreedte en belasting van uw API worden vermeden. Als ze proberen gegevens uit de blobcontainer 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.

Op identiteit gebaseerd toegangsbeheer

Azure Storage biedt ook op identiteit gebaseerd toegangsbeheer met behulp van Azure Active Directory (Azure AD). Met deze mogelijkheid kunt u ook op kenmerken gebaseerd toegangsbeheer gebruiken,waarmee u fijner toegang hebt tot blobpaden of tot blobs die zijn getagd met een specifieke tenant-id.

Levenscyclusbeheer

Wanneer u blobopslag gebruikt in een multitenant-oplossing, hebben uw tenants mogelijk verschillende beleidsregels nodig voor gegevensretentie. Wanneer u grote hoeveelheden gegevens opgeslagen, wilt u mogelijk ook de gegevens voor een specifieke tenant configureren om automatisch te worden verplaatst naar de opslaglagen voor 'cool' of 'archive' opslag ,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 beleid voor levenscyclusbeheer kan worden toegepast op blobcontainers of op een subset blobs in een container. Er gelden echter limieten voor het aantal regels dat u kunt opgeven in een beleid voor levenscyclusbeheer. Zorg ervoor dat u het gebruik van deze functie in een multitenant-omgeving plant en test en overweeg meerdere opslagaccounts te implementeren als u de limieten overschrijdt.

Onveranderbare opslag

Wanneer u onveranderbare blobopslag op opslagcontainers configureert met retentiebeleid op basis van tijd,voorkomt Azure Storage verwijderen of wijzigen van de gegevens vóór een opgegeven tijd. De preventie wordt afgedwongen op de laag van het opslagaccount en geldt voor alle gebruikers. Zelfs de beheerders van uw organisatie kunnen onveranderbare gegevens niet verwijderen.

Onveranderbare opslag kan nuttig zijn wanneer u werkt met tenants die wettelijke of nalevingsvereisten hebben voor het onderhouden van gegevens of records. U moet echter overwegen hoe deze functie wordt gebruikt binnen de context van de levenscyclus van uw tenant. Als tenants bijvoorbeeld worden ge-offboard en de verwijdering van hun gegevens aanvragen, kunt u hun aanvragen mogelijk niet indienen. Als u onveranderbare opslag gebruikt voor de gegevens van uw tenants, kunt u overwegen hoe u dit probleem in uw servicevoorwaarden kunt oplossen.

Kopiëren 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 tussen implementatiestempels verplaatst of een shard-set opslagaccounts opnieuw in evenwicht brengt, moet u de gegevens van een specifieke tenant kopiëren of verplaatsen. Wanneer u werkt met grote hoeveelheden gegevens, is het raadzaam om kopieer-API's aan de serverzijde te gebruiken om de tijd te verminderen die nodig is om de gegevens te migreren.

Het AzCopy-hulpprogramma 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 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 bij het werken met kleinere blobs.

Objectreplicatie

Met de functie Objectreplicatie worden gegevens automatisch gerepliceerd tussen een bron- en doelopslagaccount. Objectreplicatie is asynchroon. In een multitenant-oplossing kan deze functie nuttig zijn wanneer u continu gegevens wilt repliceren tussen implementatiestempels of in een implementatie van het Geode-patroon.

Versleuteling

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

Bewaking

Wanneer u met een multitenant-oplossing werkt, moet u overwegen of u het verbruik voor elke tenantmoet meten en de specifieke metrische gegevens moet definiëren die u moet bijhouden, zoals de hoeveelheid opslag die wordt gebruikt voor elke tenant (de capaciteit) of het aantal bewerkingen dat voor de gegevens van elke tenant wordt uitgevoerd.

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

U kunt ook alle aanvragen voor Azure Storageen vervolgens kunt u deze logboeken aggregeren en analyseren. Dit biedt meer flexibiliteit in de manier waarop u gegevens voor elke tenant aggregatiet en groept. In oplossingen die grote hoeveelheden aanvragen naar Azure Storage maken, is het echter belangrijk om te overwegen of het voordeel dat u van deze benadering hebt, de kosten rechtvaardigt die nodig zijn voor het vastleggen en verwerken van deze logboeken.

Azure Storage inventaris biedt een andere benadering voor het meten van de totale grootte van een blobcontainer.

Isolatiemodellen

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

Storage per tenant beheren

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 geroteerd. Met deze aanpak kunt u uw oplossing schalen om limieten en quota te vermijden 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.

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

Isolatiemodellen voor blob-opslag

Gedeelde blobcontainers

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

Hoewel deze aanpak eenvoudig te implementeren is, bieden blobpaden in veel scenario's niet voldoende isolatie tussen tenants. Dit komt doordat blobopslag doorgaans 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 de mogelijkheid om blobs weer te geven (op te semuleren) die beginnen met een opgegeven voorvoegsel . Dit kan handig zijn wanneer u met gedeelde blobcontainers werkt en geen toegangsbeheerop mapniveau vereist.

Azure Storage hiërarchische naamruimtefunctie van Azure Storage de mogelijkheid om een sterker concept van een map of map te hebben, met inbegrip van directory-specifiek toegangsbeheer. Dit kan handig zijn in sommige multitenant-scenario's waarin u gedeelde blobcontainers hebt, maar u toegang wilt verlenen tot de gegevens van één tenant.

In sommige oplossingen met meerdere tenants 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 is één gedeelde blobcontainer mogelijk voldoende. U kunt de tenant-id gebruiken als de blobnaam en vervolgens een specifieke blob lezen in plaats van een blobpad op te snoemen.

Wanneer u met gedeelde containers werkt, moet u overwegen of u het gegevens- en Azure Storage-servicegebruik voor elke tenant moet bijhouden en een benadering moet plannen om dit te 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 kunt maken, binnen een opslagaccount.

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

Gedeelde bestands shares

Wanneer u met bestands shares werkt, kunt u ervoor kiezen om een gedeelde bestands share te gebruiken. Vervolgens kunt u bestandspaden gebruiken om gegevens voor elke tenant te scheiden:

Wanneer u een toepassing gebruikt die kan communiceren met behulp van het SMB-protocol (Server Message Block), en wanneer u Active Directory Domain Services on-premises of in Azure gebruikt, ondersteunen bestands shares autorisatie op zowel het niveau van de share als de map/bestandsniveaus.

In andere scenario's kunt u sas gebruiken om toegang te verlenen tot specifieke bestands shares of bestanden. Wanneer u SAS gebruikt, kunt u geen toegang verlenen tot directories.

Wanneer u met gedeelde bestands shares werkt, moet u overwegen of u de 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.

Bestands shares per tenant

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

Door bestands shares te maken voor elke tenant, 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 door elke bestands share wordt gebruikt.

Isolatiemodellen voor Table Storage

Gedeelde tabellen met partitiesleutels per tenant

Wanneer u Table Storage gebruikt met één gedeelde tabel, 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 beleid voor gedeelde toegang kunt u een partitiesleutelbereik opgeven en Azure Storage zorgt ervoor dat aanvragen met de handtekening alleen toegang hebben tot de opgegeven partitiesleutelbereiken. Hiermee kunt u het Valet Key-patroonimplementeren, waarmee niet-vertrouwde clients toegang hebben tot de partitie van één tenant, zonder dat dit van invloed is op andere tenants.

Houd rekening met de maximale doorvoer van elke tabelpartitie en het opslagaccount voor grootschalige toepassingen.

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

Gedeelde wachtrijen

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

Wachtrijen bieden geen partitionering of subwachtrijen, zodat gegevens voor alle tenants kunnen worden verwisseld.

Wachtrijen per tenant

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

Door wachtrijen voor elke tenant te maken, 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, moet u rekening houden met de manier waarop uw toepassingslaag de berichten uit de wachtrij van elke tenant verbruikt. Voor geavanceerdere scenario's kunt u azure Service Busgebruiken, dat ondersteuning biedt voor functies zoals onderwerpen en abonnementen,sessies en automatisch doorsturen van berichten, wat nuttig kan zijn in een multitenant-oplossing.

Volgende stappen

Bekijk Resources voor architecten en ontwikkelaars van multitenant-oplossingen.