Flera innehavare och Azure Storage
Azure Storage är en grundläggande tjänst som används i nästan alla lösningar. Lösningar för flera olika tjänster använder ofta Azure Storage blob-, fil-, kö- och tabellagring. På den här sidan beskriver vi några av de funktioner i Azure Storage som är användbara för lösningar för flera olika tjänster, och sedan tillhandahåller vi länkar till vägledning som kan hjälpa dig när du planerar hur du ska använda Azure Storage.
Funktioner i Azure Storage som stöder flera innehavare
Azure Storage innehåller många funktioner som stöder flera innehavare.
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, t.ex. ett nätverk för innehållsleverans eller ett API, eller om klienten ska ansluta direkt till ditt lagringskonto. Det kan finnas bra skäl att skicka begäranden via en annan komponent, inklusive cachelagring av data vid nätverkskanten. I vissa situationer är det dock fördelaktigt för klientslutpunkter att ansluta direkt till Azure Storage ladda ned eller ladda upp data. Den här anslutningen hjälper dig att förbättra lösningens prestanda, särskilt när du arbetar med stora blobar eller ett stort antal filer. Det minskar också belastningen på dina serverprogram 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 kan du skapa en SAS som endast tillåter användare av klient A att komma åt tenanta 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-nyckelmönstret är användbart som ett sätt att utfärda begränsade och begränsade signaturer för delad åtkomst från din programnivå. Anta till exempel att du har ett program för flera användare som tillåter användare att ladda upp videor. Din API- eller programnivå kan autentisera klienten med ditt eget autentiseringssystem. Du kan sedan tillhandahålla en SAS till klienten som gör att de kan ladda upp en videofil till en angiven blob till en container och blobsökväg som du anger. Klienten laddar sedan upp filen direkt till lagringskontot för att undvika 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, Azure Storage blockerar begäran. Signaturen upphör att gälla efter en konfigurerbar tidsperiod.
Lagrade åtkomstprinciper utökar SAS-funktionen, 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 även identitetsbaserad åtkomstkontroll med hjälp av Azure Active Directory (Azure AD). Med den här funktionen kan du också använda attributbaserad åtkomstkontroll, vilket ger dig mer specifik åtkomst till blobsökvägar eller till blobar som har taggats med ett specifikt klientorganisations-ID.
Livscykelhantering
När du använder bloblagring i en lösning för flera klienter kan dina klienter kräva olika principer för databevarande. När du lagrar stora mängder data kanske du också vill konfigurera data för en specifik klientorganisation så att de flyttas automatiskt till låg energi 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 klienterna. En livscykelhanteringsprincip kan tillämpas på blobcontainrar eller på en delmängd av blobar i en container. Det finns dock begränsningar för antalet regler som du kan ange i en livscykelhanteringsprincip. Se till att du planerar och testar din användning av den här funktionen i en miljö för flera användare 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 tidsbaseradekvarhållningsprinciper Azure Storage borttagning eller ändring av data före en angiven tid. Förebyggandet tillämpas på lagringskontonivån 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 i kontexten för klientlivscykeln. Om klienter till exempel avboardas och begär borttagning av sina data kanske du inte kan uppfylla deras begäranden. Om du använder oföränderlig lagring för dina klienters data bör du överväga hur du ska åtgärda problemet i användningsvillkoren.
Kopiera på serversidan
I ett system med flera olika program finns det ibland behov av att flytta data från ett lagringskonto till ett annat. Om du till exempel flyttar en klient mellan distributionsstämplar eller balanserar om en fragmenterad uppsättning lagringskonton måste du kopiera eller flytta en specifik klientorganisations 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:er för kopiering på serversidan direkt från din kod kan du överväga att använda API:et Put Block From URL (Placera block från URL) och Put Page From URL (Placera sida från URL) samt API:et För att lägga till block från URL och API:et Copy Blob From URL (Kopiera blob från URL) när du arbetar med mindre blobar.
Objektreplikering
Funktionen Objektreplikering replikerar automatiskt data mellan ett källa- och mållagringskonto. Objektreplikering är asynkron. I en multitenant-lösning kan den här funktionen vara användbar när du behöver kontinuerligt replikera data mellan distributionsstämplar eller i en implementering av Geode-mönstret.
Kryptering
Azure Storage kan du ange krypteringsnycklar för dina data. Överväg att kombinera den här funktionen med krypteringsomfång i en lösning för flera klienter, så att du kan definiera olika krypteringsnycklarför olika klienter, även om deras data lagras i samma lagringskonto. Genom att använda dessa funktioner tillsammans kan du även ge klienterna kontroll över sina egna data. Om de behöver inaktivera sitt konto kan de ta bort krypteringsnyckeln och deras data är inte längre 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 klients data.
Azure Storage har inbyggda övervakningsfunktioner. Det är viktigt att tänka på de tjänster som du kommer att använda i Azure Storage konto. När du till exempel arbetar med blobar kan du visa den totala kapaciteten för ett lagringskonto,men inte en enskild container. När du arbetar med filresurser går det däremot 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 Storageoch sedan kan du aggregera och analysera dessa loggar. Detta ger mer flexibilitet i hur du aggregerar och grupperar data för varje klientorganisation. Men i lösningar som skapar stora mängder begäranden till Azure Storage är det viktigt att fundera över om fördelen med den här metoden motiverar kostnaden för att samla in och bearbeta loggarna.
Azure Storage en annan metod för att mäta den totala storleken på en blobcontainer.
Isoleringsmodeller
När du arbetar med ett system med flera Azure Storage måste du fatta ett beslut om vilken isoleringsnivå du vill använda. Azure Storage har stöd för flera isoleringsmodeller.
Storage 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 begränsningar 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.
Anteckning
Azure Storage har många kvoter och begränsningar som du bör tänka på när du väljer en isoleringsmodell. Dessa omfattar Azure-tjänstbegränsningar,skalbarhetsmåloch skalbarhetsmål för Azure Storage resursprovidern.
Dessutom ger varje komponent i Azure Storage ytterligare alternativ för klientisolering.
Blob Storage-isoleringsmodeller
Delade blobcontainrar
När du arbetar med Blob Storage 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 |
Även om den här metoden är enkel att implementera ger blobsökvägar i många fall inte tillräcklig isolering mellan klientorganisationarna. Det beror på att blobblagring vanligtvis inte tillhandahåller ett begrepp om kataloger eller mappar. Det innebär att du inte kan tilldela åtkomst till alla blobar inom en angiven sökväg. Men Azure Storage ger möjlighet att lista (räkna upp) blobarsom 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 Storage hierarkisk namnrymdsfunktion ger möjlighet att ha ett starkare begrepp 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 bevilja åtkomst till en enskild klients data.
I vissa lösningar för flera klienter kanske du bara behöver lagra en enda blob eller en uppsättning blobar för varje klient, 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 klient-ID:t 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ändning för varje klient 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 hur många blobcontainrar du kan skapa i ett lagringskonto.
Genom att skapa containrar för varje klient kan du använda Azure Storage åtkomstkontroll, inklusive SAS, för att hantera åtkomst för varje klientorganisations data. Du kan också enkelt övervaka den kapacitet som varje container använder.
Modeller för fillagringsisolering
Delade filresurser
När du arbetar med filresurser kan du välja att använda en delad filresurs och sedan 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 Active Directory Domain Services 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ändning för varje klient 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 hur många filresurser du kan skapa i ett lagringskonto.
Genom att skapa filresurser för varje klient 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 tabellagring
Delade tabeller med partitionsnycklar per klientorganisation
När du använder tabellagring 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 klient-ID är ofta ett bra alternativ för en partitionsnyckel.
Signaturer och principer för delad åtkomst gör att du kan 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-nyckelmönstret, vilket gör att ej betrodda klienter kan komma åt en enskild klients partition utan att påverka andra klienter.
För storskaliga program bör du tänka på det maximala dataflödet för varje tabellpartition och lagringskontot.
Tabeller per klient
Du kan skapa enskilda tabeller för varje klientorganisation i ett enda lagringskonto. Det finns ingen gräns för hur många tabeller du kan skapa i ett lagringskonto.
Genom att skapa tabeller för varje klient kan du använda Azure Storage åtkomstkontroll, inklusive SAS, för att hantera åtkomst för varje klientorganisations data.
Modeller för isolering av kölagring
Delade köer
Om du väljer att dela en kö bör du tänka på vilka kvoter och begränsningar som gäller. I lösningar med en hög begärandevolym bör du överväga om målgenomflödet på 2 000 meddelanden per sekund är tillräckligt.
Köer tillhandahåller inte partitionering eller underköer, så data för alla klienter kan vara sammankopplade.
Köer per klientorganisation
Du kan skapa enskilda köer för varje klientorganisation inom ett enda lagringskonto. Det finns ingen gräns för hur många köer 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 skapar köer dynamiskt för varje klientorganisation bör du tänka på hur programnivån kommer att använda meddelanden från varje klients kö. För mer avancerade scenarier kan du överväga att använda Azure Service Bus, som har stöd för funktioner som ämnen och prenumerationer,sessioner och vidarebefordran av meddelanden automatiskt,vilket kan vara användbart i en lösning för flera användare.