Arkitekturbaserade metoder för lagring och data i lösningar för flera olika tjänster

När du planerar lagring eller datakomponenter för flera innehavare måste du bestämma dig för en metod för att dela eller isolera dina klienters data. Data anses ofta vara den mest värdefulla delen av en lösning, eftersom de representerar din eller dina kunders värdefulla affärsinformation. Därför är det viktigt att noggrant planera den metod som du använder för att hantera data i en miljö med flera olika miljöer. På den här sidan ger vi vägledning om viktiga överväganden och krav som är viktiga för lösningsarkitekter när de bestämmer sig för en metod för att lagra data i ett system med flera tjänster. Sedan föreslår vi några vanliga mönster för att tillämpa flera innehavare på lagrings- och datatjänster och vissa antimönster att undvika. Slutligen ger vi riktad vägledning för vissa specifika situationer.

Viktiga överväganden och krav

Det är viktigt att tänka på de metoder som du använder för lagring och datatjänster ur ett antal perspektiv, som ungefär överensstämmer med grundpelarna i Azure Well-Architected Framework.

Skala

När du arbetar med tjänster som lagrar dina data bör du tänka på antalet klienter som du har och mängden data som du lagrar. Om du har ett litet antal klienter (till exempel fem eller mindre) och du lagrar små mängder data för varje klientorganisation, är det troligt att det är slöseri med arbete att planera en mycket skalbar datalagringsmetod eller att skapa en helt automatiserad metod för att hantera dina dataresurser. När du växer drar du i allt större utsträckning nytta av en tydlig strategi för att skala dina data- och lagringsresurser och tillämpa automatisering på hanteringen. När du har 50 klienter eller fler, eller om du planerar att nå den skalningsnivån, är det särskilt viktigt att utforma din data- och lagringsmetod med skalning som ett viktigt övervägande.

Fundera över i vilken utsträckning du planerar att skala och planera arkitekturen för datalagring för att uppfylla den skalningsnivån.

Prestandaför förutsägbarhet

Data och lagringstjänster för flera användare är särskilt sårbara för problemet Noisy Neighbor. Det är viktigt att fundera över om dina klienter kan påverka varandras prestanda. Har dina klienter till exempel överlappande toppar i sina användningsmönster över tid? Använder alla dina kunder din lösning vid samma tidpunkt varje dag, eller fördelas begäranden jämnt? Dessa faktorer påverkar den isoleringsnivå som du behöver utforma för, mängden resurser som du behöver etablera och hur mycket resurser som kan delas mellan klienter.

Det är viktigt att tänka på Azures resurs och begära kvoter som en del av det här beslutet. Anta till exempel att du distribuerar ett enda lagringskonto som ska innehålla alla dina klienters data. Om du överskrider ett visst antal lagringsåtgärder per sekund Azure Storage avvisar programmets begäranden och alla dina klienter påverkas. Detta kallas begränsningsbeteende. Det är viktigt att du övervakar för begränsade begäranden. Mer information finns i Vägledning om återförsök för Azure-tjänster.

Dataisolering

När du utformar en lösning som innehåller datatjänster för flera entenant finns det vanligtvis olika alternativ och nivåer av dataisolering, var och en med sina egna fördelar och kompromisser. Till exempel:

• När du Azure Cosmos DB kan du distribuera separata containrar för varje klientorganisation och du kan dela databaser och konton mellan flera klienter. Du kan också överväga att distribuera olika databaser eller till och med konton för varje klientorganisation, beroende på vilken isoleringsnivå som krävs.
• När du Azure Storage för blobdata kan du distribuera separata blobcontainrar för varje klient eller distribuera separata lagringskonton.
• När du använder Azure SQL kan du använda separata tabeller i delade databaser eller distribuera separata databaser eller servrar för varje klientorganisation.
• I alla Azure-tjänster kan du överväga att distribuera resurser inom en enda delad Azure-prenumeration, eller så kan du använda flera Azure-prenumerationer – kanske till och med en per klientorganisation.

Det finns ingen enskild lösning som fungerar för varje situation. Vilket alternativ du väljer beror på ett antal faktorer och kraven för dina klienter. Om dina klienter till exempel behöver uppfylla specifika efterlevnads- eller regelkrav kan du behöva tillämpa en högre isoleringsnivå. På samma sätt kan du ha kommersiella krav för att fysiskt isolera dina kunders data, eller så kan du behöva framtvinga isolering för att undvika problemet Noisy Neighbor. Om klienterna dessutom behöver använda sina egna krypteringsnycklar, har de enskilda principer för säkerhetskopiering och återställning, eller om de behöver ha sina data lagrade på olika geografiska platser, kan du behöva isolera dem från andra klienter eller gruppera dem med klienter som har liknande principer.

Implementeringens komplexitet

Det är viktigt att tänka på komplexiteten i implementeringen. Det är bra att hålla din arkitektur så enkel som möjligt, samtidigt som du uppfyller dina krav. Undvik att använda en arkitektur som blir allt mer komplex när du skalar, eller en arkitektur som du inte har de resurser eller kunskaper som krävs för att utveckla och underhålla.

Och om din lösning inte behöver skalas till ett stort antal klienter, eller om du inte har några problem med prestanda eller dataisolering, är det bättre att hålla din lösning enkel och undvika att lägga till onödig komplexitet.

Ett särskilt problem för datalösningar för flera olika tjänster är den anpassningsnivå som du stöder. Kan en klient exempelvis utöka din datamodell eller tillämpa anpassade dataregler? Se till att du utformar för detta i förväg. Undvik att förförföra eller tillhandahålla anpassad infrastruktur för enskilda klienter, eftersom detta hindrar din möjlighet att skala, testa din lösning och distribuera uppdateringar. Överväg i stället att använda funktionsflaggor och andra former av klientkonfiguration.

Komplexiteten i hantering och drift

Fundera över hur du planerar att använda din lösning och hur din metod för flera innehavare påverkar dina åtgärder och processer. Till exempel:

• Överväg hanteringsåtgärder mellan klientorganisationen, till exempel regelbundna underhållsaktiviteter. Hur initierar och övervakar du åtgärderna för varje klientorganisation om du använder flera konton, servrar eller databaser?
• Om du övervakar eller mäter dina klienter bör du överväga hur din lösning rapporterar mått och om de enkelt kan länkas till den klientorganisation som utlöste begäran.
• Rapportering av data mellan isolerade klienter kan kräva att varje klientorganisation publicerar data till ett centraliserat informationslager, i stället för att köra frågor på varje databas individuellt och sedan aggregera resultatet.
• Om du använder en databas som tillämpar ett schema bör du planera hur du ska distribuera schemauppdateringar i din egendom. Fundera över hur ditt program vet vilken schemaversion som ska användas för en specifik klients databasfrågor.
• Överväg dina klienters krav på hög tillgänglighet (till exempel serviceavtal för drifttid eller serviceavtal) och krav på haveriberedskap (till exempel mål för återställningstid eller återställningspunktmål och mål för återställningspunkt eller återställningspunkt). Om klienterna har olika förväntningar, kommer du att kunna uppfylla varje klientorganisations krav?
• Hur migrerar du klienter om de behöver flytta till en annan typ av tjänst, en annan distribution eller en annan region?

Cost

Ju högre densiteten för klienterna i distributionsinfrastrukturen är, desto lägre blir kostnaden för att etablera infrastrukturen. Delad infrastruktur ökar dock sannolikheten för problem som problem med Noisy Neighbor,så överväg kompromisserna noggrant.

Metoder och mönster att överväga

Flera designmönster från Azure Architecture Center är relevanta för multiitenant lagring och datatjänster. Du kan välja att följa ett mönster konsekvent. Eller så kan du överväga att blanda och matcha mönster. Du kan till exempel använda en databas för flera innehavare för de flesta av dina klienter, men distribuera stämplar för en enskild klientorganisation för klienter som betalar mer eller som har ovanliga krav. På samma sätt är det ofta en bra idé att skala med hjälp av distributionsstämplar, även om du använder en databas med flera innehavare eller fragmenterade databaser inom en stämpel.

Mönster för distributionsstämplar

Mer information om hur mönstret distributionsstämplar kan användas för att stödja en lösning för flera olika program finns i Översikt.

Delade databaser och fillager för flera innehavare

Du kan överväga att distribuera en delad databas, ett lagringskonto eller en filresurs för flera innehavare och dela den över alla dina klienter.

Den här metoden ger den högsta densiteten för klienter till infrastruktur, så den tenderar att ha den lägsta kostnaden för alla metoder. Det minskar också ofta hanteringskostnad, eftersom det finns en enkel databas eller resurs att hantera, backa upp och skydda.

Men när du arbetar med delad infrastruktur finns det flera varningar att överväga:

• När du förlitar dig på en enskild resurs bör du överväga den skalning och de gränser som stöds för den resursen. Till exempel blir den maximala storleken för en databas eller ett filarkiv, eller de maximala dataflödesgränserna, till slut en hård blockerare om arkitekturen förlitar sig på en enskild databas. Överväg noggrant den maximala skala som du behöver uppnå och jämför den med dina aktuella och framtida gränser innan du väljer det här mönstret.
• Problemet Noisy Neighbor kan bli en faktor, särskilt om du har klienter som är särskilt upptagna eller genererar högre arbetsbelastningar än andra. Överväg att tillämpa mönstret Begränsning eller Mönster för frekvensbegränsning för att minska dessa effekter.
• Du kan ha problem med att övervaka aktiviteten och mäta förbrukningen för en enskild klientorganisation. Vissa tjänster, till exempel Azure Cosmos DB, tillhandahåller rapportering om resursanvändning för varje begäran, så att den här informationen kan spåras för att mäta förbrukningen för varje klientorganisation. Andra tjänster ger inte samma detaljnivå. Till exempel är Azure Files för filkapacitet tillgängliga per filresursdimension, endast när du använder Premium-resurser. Standardnivån tillhandahåller dock endast mått på lagringskontonivå.
• Klienter kan ha olika krav för säkerhet, säkerhetskopiering, tillgänglighet eller lagringsplats. Om de inte matchar konfigurationen för den enskilda resursen kanske du inte kan hantera dem.
• När du arbetar med en relationsdatabas, eller en annan situation där dataschemat är viktigt, är det svårt att anpassa schemat på klientnivå.

Mönster för horisontell partitionering

Mönstret för horisontell partitionering omfattar distribution av flera separata databaser, som kallas shards,som innehåller en eller flera klientorganisationsdata. Till skillnad från distributionsstämplar innebär shards inte att hela infrastrukturen dupliceras. Du kan fragmentera databaser utan att duplicera eller horisontell partitionera annan infrastruktur i lösningen.

Horisontell partitionering är nära relaterat till partitioneringoch termerna används ofta synonymt. Överväg riktlinjerna för horisontell, vertikal och funktionell datapartitionering.

Mönstret för horisontell partitionering kan skalas till ett mycket stort antal klienter. Beroende på din arbetsbelastning kan du dessutom uppnå en hög densitet av klienter till shards, så att kostnaden kan vara attraktiv. Mönstret för horisontell partitionering kan också användas för att hantera kvoter, begränsningar och begränsningar för Azure-prenumerationer och -tjänster.

Vissa datalager, till exempel Azure Cosmos DB, har inbyggt stöd för horisontell partitionering eller partitionering. När du arbetar med andra lösningar, till exempel Azure SQL, kan det vara mer komplicerat att skapa en infrastruktur för horisontell partitionering och dirigera begäranden till rätt shard för en viss klientorganisation.

App för flera innehavare med dedikerade databaser för varje klientorganisation

En annan vanlig metod är att distribuera ett enda program för flera klienter, med dedikerade databaser för varje klientorganisation.

I den här modellen isoleras varje klientorganisations data från de andra, och du kan eventuellt ha stöd för viss anpassningsgrad för varje klientorganisation.

Eftersom du etablerar dedikerade dataresurser för varje klientorganisation kan kostnaden för den här metoden vara högre än delade värdmodeller. Azure har dock flera alternativ som du kan överväga för att dela kostnaden för att vara värd för enskilda dataresurser över flera klientorganisationsklienter. När du till exempel arbetar med Azure SQL kan du överväga elastiska pooler. För Azure Cosmos DB kan du etablera dataflöde för en databas och dataflödet delas mellan containrarna i databasen, även om den här metoden inte är lämplig när du behöver garanterade prestanda för varje container.

Eftersom endast datakomponenterna distribueras individuellt för varje klientorganisation i den här metoden kan du förmodligen uppnå hög densitet för de andra komponenterna i lösningen och minska kostnaden för dessa komponenter.

Det är viktigt att använda automatiserade distributionsmetoder när du etablerar databaser för varje klientorganisation.

Geodes-mönster

Geode-mönstret är särskilt utformat för geografiskt distribuerade lösningar, inklusive lösningar för flera olika lösningar. Den har stöd för hög belastning och hög återhämtningsnivå. När du arbetar med geode-mönstret måste datanivån kunna replikera data mellan geografiska regioner, och den ska ha stöd för skrivningar till flera geografiska områden.

Azure Cosmos DB tillhandahåller skrivningar med flera original som stöd för det här mönstret, och Cassandra har stöd för kluster i flera regioner. Andra datatjänster kan vanligtvis inte stödja det här mönstret, utan betydande anpassning.

Antimönster att undvika

När du arbetar med datatjänster för flera samma företag är det viktigt att undvika situationer som hindrar din möjlighet att skala.

För relationsdatabaser omfattar dessa:

• Tabellbaserad isolering. Undvik att skapa enskilda tabeller för varje klientorganisation när du arbetar i en enkel databas. En enskild databas kommer inte att kunna stödja ett mycket stort antal klienter när du använder den här metoden och det blir allt svårare att fråga, hantera och uppdatera data. Överväg i stället att använda en enda uppsättning tabeller för flera innehavare med en kolumn för klient-ID. Du kan också använda något av de mönster som beskrivs ovan för att distribuera separata databaser för varje klientorganisation.
• Klientanpassning på kolumnnivå. Undvik att tillämpa schemauppdateringar som endast gäller för en enda klientorganisation. Anta till exempel att du har en enda databas för flera användare. Undvik att lägga till en ny kolumn för att uppfylla en specifik klientorganisations krav. Det kan vara acceptabelt för ett litet antal anpassningar, men detta blir snabbt ohantabelt när du har ett stort antal anpassningar att överväga. Överväg i stället att ändra din datamodell för att spåra anpassade data för varje klient i en dedikerad tabell.
• Manuella schemaändringar. Undvik att uppdatera databasschemat manuellt, även om du bara har en enda delad databas. Det är enkelt att förlora kontrollen över de uppdateringar som du har tillämpat, och om du behöver skala ut till fler databaser är det svårt att identifiera rätt schema som ska tillämpas. Skapa i stället en automatiserad pipeline för att distribuera dina schemaändringar och använd den konsekvent. Spåra den schemaversion som används för varje klientorganisation i en dedikerad databas eller uppslagstabell.
• Versionsberoenden. Undvik att ditt program är beroende av en enda version av databasschemat. När du skalar kan du behöva tillämpa schemauppdateringar vid olika tidpunkter för olika klienter. Se i stället till att programversionen är bakåtkompatibel med minst en schemaversion och undvik destruktiva schemauppdateringar.

Databaser

Det finns vissa funktioner som kan vara användbara för flera innehavare. Dessa är dock inte tillgängliga i alla databastjänster. Överväg om du behöver dessa när du bestämmer dig för vilken tjänst som ska användas för ditt scenario:

• Säkerhet på radnivå kan ge säkerhetsisolering för specifika klientorganisationsdata i en delad databas för flera innehavare. Den här funktionen är tillgänglig i Azure SQL och Postgres Flex, men den är inte tillgänglig i andra databaser som MySQL eller Azure Cosmos DB.
• Kryptering på klientnivå kan krävas för att stödja klienter som tillhandahåller egna krypteringsnycklar för sina data. Den här funktionen är tillgänglig i Azure SQL som en del av Always Encrypted. Cosmos DB tillhandahåller kund hanterade nycklar på kontonivå och har även stöd för Always Encrypted.
• Med resurspooler kan du dela resurser och kostnader mellan flera databaser eller containrar. Den här funktionen är tillgänglig i Azure SQL elastiska pooler och hanterade instanser och i Azure Cosmos DB-databasens dataflöde, även om varje alternativ har begränsningar som du bör känna till.
• Horisontell partitionering och partitionering har starkare inbyggt stöd i vissa tjänster än andra. Den här funktionen är tillgänglig i Azure Cosmos DB, med hjälp av dess logiska och fysiska partitionering, och i Postgres Hyperskala. Azure SQL inte inbyggt stöd för horisontell partitionering, men det innehåller verktyg för horisontell partitionering som stöder den här typen av arkitektur.

När du arbetar med relationsdatabaser eller andra schemabaserade databaser bör du dessutom överväga var schemauppgraderingsprocessen ska utlösas när du underhåller en databaspark. I en liten egendom med databaser kan du överväga att använda en distributionspipeline för att distribuera schemaändringar. När du växer kan det vara bättre för programnivån att identifiera schemaversionen för en specifik databas och starta uppgraderingsprocessen.

Fil- och bloblagring

Överväg den metod du använder för att isolera data i ett lagringskonto. Du kan till exempel distribuera separata lagringskonton för varje klient eller dela lagringskonton och distribuera enskilda containrar. Du kan också skapa delade blobcontainrar och sedan använda blobsökvägen för att separera data för varje klientorganisation. Överväg begränsningar och kvoter för Azure-prenumerationeroch planera din tillväxt noggrant för att se till att dina Azure-resurser skalas för att stödja dina framtida behov.

Om du använder delade containrar bör du planera din autentiserings- och auktoriseringsstrategi noggrant för att säkerställa att klienterna inte kan komma åt varandras data. Överväg valet-nyckelmönstretnär du ger klienter åtkomst till Azure Storage resurser.

Kostnadsallokering

Överväg hur du mäter förbrukning och allokerar kostnader till klienterför användning av delade datatjänster. När det är möjligt bör du använda inbyggda mått i stället för att beräkna dina egna. Med delad infrastruktur blir det dock svårt att dela telemetri för enskilda klienter. Anpassad avläsning på programnivå måste beaktas.

I allmänhet tillhandahåller molnbaserade tjänster som Azure Cosmos DB och Azure Blob Storage mer detaljerade mått för att spåra och modellera användningen för en specifik klientorganisation. Till exempel Azure Cosmos DB det förbrukade dataflödet för varje begäran och svar.

Nästa steg

Mer information om flera innehavare och specifika Azure-tjänster finns i:

• Flera innehavare och Azure Storage
• Flera innehavare och Azure SQL Database
• Flera innehavare och Azure Cosmos DB