Dela via

Flera klientorganisationer och Azure Storage

  • Artikel

Azure Storage är en grundläggande tjänst som används i nästan alla lösningar. Lösningar för flera klientorganisationer använder ofta Azure Storage för blob-, fil-, kö- och tabelllagring. På den här sidan beskriver vi några av funktionerna i Azure Storage som är användbara för lösningar med flera klientorganisationer och sedan tillhandahåller vi länkar till vägledningen som kan hjälpa dig när du planerar hur du ska använda Azure Storage.

Funktioner i Azure Storage som stöder flera klientorganisationer

Azure Storage innehåller många funktioner som stöder flera klientorganisationer.

Signaturer för delad åtkomst

När du arbetar med Azure Storage från ett klientprogram är det viktigt att överväga om klientbegäranden ska skickas via en annan komponent som du styr, till exempel ett nätverk eller API för innehållsleverans, eller om klienten ska ansluta direkt till ditt lagringskonto. Det kan finnas goda skäl att skicka begäranden via en annan komponent, inklusive cachelagring av data i utkanten av nätverket. I vissa situationer är det dock fördelaktigt för klientslutpunkter att ansluta direkt till Azure Storage för att ladda ned eller ladda upp data. Den här anslutningen hjälper dig att förbättra prestandan för din lösning, särskilt när du arbetar med stora blobbar eller ett stort antal filer. Det minskar också belastningen på dina serverdelsprogram och servrar och minskar antalet nätverkshopp. Med en signatur för delad åtkomst (SAS) kan du på ett säkert sätt ge dina klientprogram åtkomst till objekt i Azure Storage.

Signaturer för delad åtkomst kan användas för att begränsa omfattningen av åtgärder som en klient kan utföra och de objekt som de kan utföra åtgärder mot. Om du till exempel har ett delat lagringskonto för alla dina klienter och du lagrar alla klient-A:s data i en blobcontainer med namnet tenantakan du skapa en SAS som endast tillåter klient-A:s användare att komma åt containern. Mer information finns i Isoleringsmodeller för att utforska de metoder som du kan använda för att isolera klientorganisationens data i ett lagringskonto.

Valet Key-mönstret är användbart som ett sätt att utfärda begränsade och begränsade signaturer för delad åtkomst från programnivån. Anta till exempel att du har ett program med flera klientorganisationer som gör att användarna kan ladda upp videor. Din API- eller programnivå kan autentisera klienten med ditt eget autentiseringssystem. Du kan sedan ange en SAS till klienten som gör att de kan ladda upp en videofil till en angiven blob till en container och en blobsökväg som du anger. Klienten laddar sedan upp filen direkt till lagringskontot och undviker den extra bandbredden och belastningen på ditt API. Om de försöker läsa data från blobcontainern eller om de försöker skriva data till en annan del av containern till en annan container i lagringskontot blockerar Azure Storage begäran. Signaturen upphör att gälla efter en konfigurerbar tidsperiod.

Lagrade åtkomstprinciper utökar SAS-funktionerna, vilket gör att du kan definiera en enda princip som kan användas när du utfärdar flera signaturer för delad åtkomst.

Identitetsbaserad åtkomstkontroll

Azure Storage tillhandahåller även identitetsbaserad åtkomstkontroll med hjälp av Microsoft Entra-ID. Med den här funktionen kan du också använda attributbaserad åtkomstkontroll, vilket ger dig finare åtkomst till blobsökvägar eller till blobar som har taggats med ett specifikt klient-ID.

Livscykelhantering

När du använder bloblagring i en lösning med flera klienter kan dina klienter kräva olika principer för datakvarhållning. När du lagrar stora mängder data kanske du också vill konfigurera data för en specifik klientorganisation så att de automatiskt flyttas till lågfrekvent lagringsnivå eller arkivlagringsnivåer i kostnadsoptimeringssyfte.

Överväg att använda livscykelhanteringsprinciper för att ange bloblivscykeln för alla klienter eller för en delmängd av klientorganisationer. En livscykelhanteringsprincip kan tillämpas på blobcontainrar eller på en delmängd blobar i en container. Det finns dock gränser för hur många regler du kan ange i en livscykelhanteringsprincip. Se till att du planerar och testar din användning av den här funktionen i en miljö med flera klientorganisationer och överväg att distribuera flera lagringskonton om du överskrider gränserna.

Oföränderlig lagring

När du konfigurerar oföränderlig bloblagring på lagringscontainrar med tidsbaserade kvarhållningsprinciper förhindrar Azure Storage borttagning eller ändring av data före en angiven tid. Förebyggandet tillämpas på lagringskontots lager och gäller för alla användare. Inte ens organisationens administratörer kan ta bort oföränderliga data.

Oföränderlig lagring kan vara användbart när du arbetar med klienter som har juridiska krav eller efterlevnadskrav för att underhålla data eller poster. Du bör dock överväga hur den här funktionen används inom ramen för klientorganisationens livscykel. Om klientorganisationer till exempel är avregistrerade och begär borttagning av deras data kanske du inte kan uppfylla deras begäranden. Om du använder oföränderlig lagring för klientorganisationens data bör du fundera på hur du hanterar det här problemet i dina tjänstvillkor.

Kopia på serversidan

I ett system med flera klientorganisationer finns det ibland ett behov av att flytta data från ett lagringskonto till ett annat. Om du till exempel flyttar en klientorganisation mellan distributionsstämplar eller balanserar om en fragmenterad uppsättning lagringskonton måste du kopiera eller flytta en specifik klients data. När du arbetar med stora mängder data rekommenderar vi att du använder API:er för kopiering på serversidan för att minska den tid det tar att migrera data.

AzCopy-verktyget är ett program som du kan köra från din egen dator eller från en virtuell dator för att hantera kopieringsprocessen. AzCopy är kompatibelt med kopieringsfunktionen på serversidan och innehåller ett skriptbart kommandoradsgränssnitt som du kan köra från dina egna lösningar. AzCopy är också användbart för att ladda upp och ladda ned stora mängder data.

Om du behöver använda API:erna för kopiering på serversidan direkt från koden kan du överväga att använda API:et Put Block From URL , Put Page From URL API (Placera sida från URL API), Lägg till blockera från URL-API :et och API:et Kopiera blob från URL när du arbetar med mindre blobar.

Objektreplikering

Funktionen Objektreplikering replikerar automatiskt data mellan ett käll- och mållagringskonto. Objektreplikering är asynkron. I en lösning med flera klientorganisationer kan den här funktionen vara användbar när du kontinuerligt behöver replikera data mellan distributionsstämplar eller i en implementering av Geode-mönstret.

Kryptering

Med Azure Storage kan du ange krypteringsnycklar för dina data. I en lösning med flera klienter kan du överväga att kombinera den här funktionen med krypteringsomfång, vilket gör att du kan definiera olika krypteringsnycklar för olika klienter, även om deras data lagras i samma lagringskonto. Genom att använda dessa funktioner tillsammans kan du även ge klientorganisationer kontroll över sina egna data. Om de behöver inaktivera sitt konto ser borttagningen av krypteringsnyckeln till att deras data inte längre är tillgängliga.

Övervakning

När du arbetar med en lösning för flera klienter bör du överväga om du behöver mäta förbrukningen för varje klientorganisation och definiera de specifika mått som du behöver spåra, till exempel mängden lagringsutrymme som används för varje klientorganisation (kapaciteten) eller antalet åtgärder som utförs för varje klientorganisations data. Du kan också använda kostnadsallokering för att spåra kostnaden för varje klientorganisations användning och aktivera återbetalning för flera prenumerationer.

Azure Storage tillhandahåller inbyggda övervakningsfunktioner. Det är viktigt att tänka på vilka tjänster du ska använda i Azure Storage-kontot. När du till exempel arbetar med blobar är det möjligt att visa den totala kapaciteten för ett lagringskonto, men inte en enda container. När du däremot arbetar med filresurser är det möjligt att se kapaciteten för varje resurs, men inte för varje mapp.

Du kan också logga alla begäranden som görs till Azure Storage och sedan kan du aggregera och analysera dessa loggar. Den här metoden ger större flexibilitet i hur du aggregerar och grupperar data för varje klientorganisation. I lösningar som skapar stora mängder begäranden till Azure Storage är det dock viktigt att fundera på om den nytta du får av den här metoden motiverar kostnaden för att samla in och bearbeta loggarna.

Azure Storage-inventering ger en annan metod för att mäta den totala storleken på en blobcontainer.

Isoleringsmodeller

När du arbetar med ett system med flera klientorganisationer med Hjälp av Azure Storage måste du fatta ett beslut om vilken isoleringsnivå du vill använda. Azure Storage stöder flera isoleringsmodeller.

Lagringskonton per klientorganisation

Den starkaste isoleringsnivån är att distribuera ett dedikerat lagringskonto för en klientorganisation. Detta säkerställer att alla lagringsnycklar är isolerade och kan roteras oberoende av varandra. Med den här metoden kan du skala din lösning för att undvika gränser och kvoter som gäller för varje lagringskonto, men du måste också överväga det maximala antalet lagringskonton som kan distribueras till en enda Azure-prenumeration.

Kommentar

Azure Storage har många kvoter och gränser som du bör tänka på när du väljer en isoleringsmodell. Dessa omfattar Azure-tjänstbegränsningar, skalbarhetsmål och skalbarhetsmål för Azure Storage-resursprovidern.

Dessutom ger varje komponent i Azure Storage ytterligare alternativ för klientisolering.

Isoleringsmodeller för bloblagring

I följande tabell sammanfattas skillnaderna mellan de viktigaste modellerna för innehavarisolering för Azure Storage-blobar:

Att tänka på Delade blobcontainrar Blobcontainrar per klientorganisation Lagringskonton per klientorganisation
Dataisolering Låg medelhög. Använda sökvägar för att identifiera varje klients data eller hierarkiska namnområden Medel. Använda SAS-URL:er med containeromfattning för att stödja säkerhetsisolering Högt
Prestandaisolering Låg Låg. De flesta kvoter och gränser gäller för hela lagringskontot Högt
Distributionskomplexitet Låg Medium Högt
Driftkomplexitet Låg Medium Högt
Exempelscenario Lagra ett litet antal blobar per klientorganisation Utfärda SAS-URL:er med klientomfattning Separata distributionsstämplar för varje klientorganisation

Delade blobcontainrar

När du arbetar med bloblagring kan du välja att använda en delad blobcontainer och sedan använda blobsökvägar för att separera data för varje klientorganisation:

Klientorganisations-ID Exempel på blobsökväg
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

Den här metoden är enkel att implementera, men i många scenarier ger blobsökvägar inte tillräcklig isolering mellan klientorganisationer. Det beror på att bloblagring inte ger något begrepp om kataloger eller mappar. Det innebär att du inte kan tilldela åtkomst till alla blobar inom en angiven sökväg. Azure Storage ger dock möjlighet att lista (räkna upp) blobar som börjar med ett angivet prefix, vilket kan vara användbart när du arbetar med delade blobcontainrar och inte kräver åtkomstkontroll på katalognivå.

Azure Storages hierarkiska namnområdesfunktion ger möjlighet att ha ett starkare koncept för en katalog eller mapp, inklusive katalogspecifik åtkomstkontroll. Detta kan vara användbart i vissa scenarier med flera klienter där du har delade blobcontainrar, men du vill ge åtkomst till en enskild klientorganisations data.

I vissa lösningar med flera klienter kanske du bara behöver lagra en enda blob eller en uppsättning blobar för varje klientorganisation, till exempel klientikoner för att anpassa ett användargränssnitt. I dessa scenarier kan en enda delad blobcontainer vara tillräcklig. Du kan använda klientidentifieraren som blobnamn och sedan läsa en specifik blob i stället för att räkna upp en blobsökväg.

När du arbetar med delade containrar bör du överväga om du behöver spåra data- och Azure Storage-tjänstanvändningen för varje klientorganisation och planera en metod för att göra det. Mer information finns i Övervakning .

Blobcontainrar per klientorganisation

Du kan skapa enskilda blobcontainrar för varje klientorganisation i ett enda lagringskonto. Det finns ingen gräns för antalet blobcontainrar som du kan skapa i ett lagringskonto.

Genom att skapa containrar för varje klientorganisation kan du använda Azure Storage-åtkomstkontroll, inklusive SAS, för att hantera åtkomst för varje klientorganisations data. Du kan också enkelt övervaka kapaciteten som varje container använder.

Isoleringsmodeller för fillagring

I följande tabell sammanfattas skillnaderna mellan de viktigaste modellerna för innehavarisolering för Azure Storage-filer:

Att tänka på Delade filresurser Filresurser per klientorganisation Lagringskonton per klientorganisation
Dataisolering Medelhög. Tillämpa auktoriseringsregler för klientspecifika filer och kataloger Medelhög Högt
Prestandaisolering Låg Låg medelhög. De flesta kvoter och gränser gäller för hela lagringskontot, men ange storlekskvoter på en nivå per resurs Högt
Distributionskomplexitet Låg Medium Högt
Driftkomplexitet Låg Medium Högt
Exempelscenario Programmet styr all åtkomst till filer Klientorganisationer får åtkomst till sina egna filer Separata distributionsstämplar för varje klientorganisation

Delade filresurser

När du arbetar med filresurser kan du välja att använda en delad filresurs och sedan kan du använda filsökvägar för att separera data för varje klientorganisation:

Klientorganisations-ID Exempel på filsökväg
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

När du använder ett program som kan kommunicera med SMB-protokollet (Server Message Block), och när du använder Usluge domena aktivnog direktorijuma antingen lokalt eller i Azure, stöder filresurser auktorisering på både resurs- och katalog-/filnivå.

I andra scenarier bör du överväga att använda SAS för att bevilja åtkomst till specifika filresurser eller filer. När du använder SAS kan du inte bevilja åtkomst till kataloger.

När du arbetar med delade filresurser bör du överväga om du behöver spåra data- och Azure Storage-tjänstanvändningen för varje klientorganisation och sedan planera en metod för att göra det (efter behov). Mer information finns i Övervakning .

Filresurser per klientorganisation

Du kan skapa enskilda filresurser för varje klientorganisation inom ett enda lagringskonto. Det finns ingen gräns för antalet filresurser som du kan skapa i ett lagringskonto.

Genom att skapa filresurser för varje klientorganisation kan du använda Azure Storage-åtkomstkontroll, inklusive SAS, för att hantera åtkomst för varje klientorganisations data. Du kan också enkelt övervaka kapaciteten som varje filresurs använder.

Isoleringsmodeller för tabelllagring

I följande tabell sammanfattas skillnaderna mellan de viktigaste modellerna för innehavarisolering för Azure Storage-tabeller:

Att tänka på Delade tabeller med partitionsnycklar per klientorganisation Tabeller per klientorganisation Lagringskonton per klientorganisation
Dataisolering Låg. Programmet framtvingar isolering Låg medelhög Högt
Prestandaisolering Låg Låg. De flesta kvoter och gränser gäller för hela lagringskontot Högt
Distributionskomplexitet Låg Medium Högt
Driftkomplexitet Låg Medium Högt
Exempelscenario Stor lösning för flera klientorganisationer med delad programnivå Utfärda SAS-URL:er med klientomfattning Separata distributionsstämplar för varje klientorganisation

Delade tabeller med partitionsnycklar per klientorganisation

När du använder tabelllagring med en enda delad tabell kan du överväga att använda det inbyggda stödet för partitionering. Varje entitet måste innehålla en partitionsnyckel. En klientidentifierare är ofta ett bra val för en partitionsnyckel.

Med signaturer och principer för delad åtkomst kan du ange ett partitionsnyckelintervall, och Azure Storage ser till att begäranden som innehåller signaturen endast kan komma åt de angivna partitionsnyckelintervallen. På så sätt kan du implementera Valet Key-mönstret, som gör det möjligt för ej betrodda klienter att komma åt en enskild klients partition, utan att påverka andra klienter.

För storskaliga program bör du överväga det maximala dataflödet för varje tabellpartition och lagringskontot.

Tabeller per klientorganisation

Du kan skapa enskilda tabeller för varje klientorganisation i ett enda lagringskonto. Det finns ingen gräns för antalet tabeller som du kan skapa i ett lagringskonto.

Genom att skapa tabeller för varje klientorganisation kan du använda Azure Storage-åtkomstkontroll, inklusive SAS, för att hantera åtkomst för varje klientorganisations data.

Isoleringsmodeller för kölagring

I följande tabell sammanfattas skillnaderna mellan de viktigaste modellerna för innehavarisolering för Azure Storage-köer:

Att tänka på Delade köer Köer per klientorganisation Lagringskonton per klientorganisation
Dataisolering Låg Låg medelhög Högt
Prestandaisolering Låg Låg. De flesta kvoter och gränser gäller för hela lagringskontot Högt
Distributionskomplexitet Låg Medium Högt
Driftkomplexitet Låg Medium Högt
Exempelscenario Stor lösning för flera klientorganisationer med delad programnivå Utfärda SAS-URL:er med klientomfattning Separata distributionsstämplar för varje klientorganisation

Delade köer

Om du väljer att dela en kö bör du överväga de kvoter och gränser som gäller. I lösningar med en hög begärandevolym bör du överväga om måldataflödet på 2 000 meddelanden per sekund är tillräckligt.

Köer tillhandahåller inte partitionering eller underfrågor, så data för alla klienter kan blandas.

Köer per klientorganisation

Du kan skapa enskilda köer för varje klientorganisation i ett enda lagringskonto. Det finns ingen gräns för antalet köer som du kan skapa i ett lagringskonto.

Genom att skapa köer för varje klientorganisation kan du använda Azure Storage-åtkomstkontroll, inklusive SAS, för att hantera åtkomst för varje klientorganisations data.

När du dynamiskt skapar köer för varje klientorganisation bör du fundera på hur programnivån ska använda meddelandena från varje klientorganisations kö. För mer avancerade scenarier bör du överväga att använda Azure Service Bus, som stöder funktioner som ämnen och prenumerationer, sessioner och automatisk vidarebefordran av meddelanden, vilket kan vara användbart i en lösning med flera klientorganisationer.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

Övriga medarbetare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Granska lagrings- och datametoder för flera klientorganisationer.