Dela via

Överväganden för kontrollplan för flera klienter

En lösning för flera klientorganisationer har flera plan och varje plan har ett eget ansvar. Dataplanet gör det möjligt för användare och klienter att interagera med ett system. Kontrollplanet hanterar uppgifter på högre nivå, till exempel åtkomstkontroll, etablering och systemunderhåll, för alla klienter för att stödja plattformsadministratörernas uppgifter.

Diagram som visar en logisk systemdesign. Ett enda kontrollplan ger hantering över flera klientspecifika dataplan.

Den här artikeln innehåller information om ansvaret för kontrollplan och hur du utformar ett kontrollplan som uppfyller dina behov.

Överväg till exempel ett bokföringssystem för hantering av finansiella poster. Flera klienter lagrar sina ekonomiska poster i systemet. När användarna kommer åt systemet för att visa och ange sina ekonomiska poster använder de dataplanet. Dataplanet är troligen den primära programkomponenten för din lösning. Hyresgäster ser det vanligtvis som huvudgränssnittet för att använda systemet som avsett.

Kontrollplanet registrerar nya hyresgäster, skapar databaser för varje hyresgäst och utför andra hanterings- och underhållsåtgärder. Utan ett kontrollplan måste administratörer förlita sig på manuella processer. I vissa fall blir dataplans- och kontrollplansuppgifter sammanflätade, vilket överkomplicerar lösningar.

Många komplexa system innehåller ett kontrollplan. Till exempel är Azure-kontrollplanet , Azure Resource Manager, en uppsättning API:er, verktyg och serverdelskomponenter som distribuerar och konfigurerar Azure-resurser. Och Kubernetes-kontrollplanet hanterar många uppgifter, till exempel placeringen av Kubernetes-poddar på arbetsnoder. Nästan alla SaaS-lösningar (programvara som en tjänst) har ett kontrollplan för att hantera uppgifter mellan klientorganisationer.

När du utformar lösningar för flera klientorganisationer måste du överväga kontrollplan. I följande avsnitt beskrivs hur du omfångsbegränsar och utformar ett kontrollplan.

Ansvarsområden för ett kontrollplan

Det finns ingen enskild mall för ett kontrollplan eller dess ansvarsområden. Din lösnings krav och arkitektur avgör vad kontrollplanet behöver göra och hur det fungerar. I vissa lösningar med flera klientorganisationer har kontrollplanet ett brett ansvarsområde och är ett komplext system i sig. I andra lösningar för flera klientorganisationer har kontrollplanet endast grundläggande ansvarsområden.

I allmänhet kan ett kontrollplan ha många av följande grundläggande ansvarsområden:

Om du använder den fullständig multitenant-modell och inte distribuerar klientspecifika resurser, kan ett grundläggande kontrollplan enbart spåra klienter och deras tillhörande metadata. När en ny klientorganisation till exempel registrerar sig för din tjänst kan kontrollplanet uppdatera lämpliga poster i en databas så att resten av systemet kan hantera den nya klientorganisationens begäranden.

Om din lösning däremot använder en distributionsmodell som kräver klientspecifik infrastruktur, som den automatiserade modellen med en enda klientorganisation, kan kontrollplanet ha mer ansvar. Den kan behöva distribuera eller konfigurera om Azure-infrastrukturen när du ansluter en ny klientorganisation. I det här scenariot interagerar kontrollplanet troligen med kontrollplan för andra verktyg, till exempel Resource Manager eller Kubernetes-kontrollplanet.

Avancerade kontrollplaner kan ta sig an fler ansvarsområden.

  • Automatiserade underhållsåtgärder: Den utför vanliga underhållsåtgärder, inklusive att ta bort eller arkivera gamla data, skapa och hantera databasindex och rotera hemligheter och kryptografiska certifikat.

  • Hyresgästplacering: Den allokerar hyresgäster till befintliga utplaceringar eller märken baserat på kriterier som målen för märkesanvändning, hyresgästkrav och Bin-packningsstrategier.

  • Ombalansering av hyresgäster: Den ombalanserar befintliga hyresgäster mellan distributionsenheter när deras användning ändras.

  • Spårning av kundaktivitet: Den integreras med externa kundhanteringslösningar, till exempel Dynamics 365, för att spåra kundaktivitet.

Omfång för ett kontrollplan

Fundera noga på hur mycket arbete du lägger på att skapa ett kontrollplan för din lösning. Ett kontrollplan ger inte direkt ett omedelbart kundvärde, vilket kan göra det svårt att motivera tekniska ansträngningar för att utforma och bygga ett högkvalitativt kontrollplan. Men i takt med att systemet växer och skalas behöver du i allt högre grad automatiserad hantering och åtgärder för att hänga med i din tillväxt.

I vissa situationer kanske du inte behöver ett fullständigt kontrollplan. Den här metoden kan fungera om systemet har färre än 10 klienter. Ditt team kan ta på sig kontrollplanets ansvarsområden och använda manuella åtgärder och processer för att registrera och hantera klienter. Du bör dock fortfarande ha en process och underhålla en central plats för att spåra dina klienter och deras konfigurationer.

Tips/Råd

Om du inte skapar ett fullständigt kontrollplan bör du fortfarande tillämpa en systematisk metod för dina hanteringsförfaranden:

  • Dokumentera dina processer noggrant.
  • Skapa och återanvända skript för dina hanteringsåtgärder när det är möjligt.

Om du behöver automatisera processer i framtiden kan dokumentationen och skripten utgöra grunden för kontrollplanet.

När du får fler än några få hyresgäster kan du dra nytta av att spåra varje hyresgäst och övervaka din uppsättning av resurser och hyresgäster. Du kanske märker att ditt team lägger allt mer tid och arbete på klienthantering. Eller så kanske du märker buggar eller driftsproblem på grund av inkonsekvenser i hur teammedlemmar utför hanteringsuppgifter. Om dessa situationer inträffar bör du överväga att bygga ett mer omfattande kontrollplan för att ta på sig dessa ansvarsområden.

Anmärkning

Om du tillhandahåller klienthantering med självbetjäning behöver du ett kontrollplan tidigt på resan. Du kan välja att skapa ett grundläggande kontrollplan och bara automatisera några av de vanligaste funktionerna. Du kan gradvis lägga till fler funktioner över tid.

Utforma ett kontrollplan

När du har fastställt kraven och omfattningen för kontrollplanet måste du designa och strukturera det. Ett kontrollplan är en viktig komponent, och det förtjänar samma planeringsnivå som alla andra delar av din arkitektur.

Överväganden

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som du kan använda för att förbättra kvaliteten på en arbetsbelastning. Mer information finns iWell-Architected Framework.

Ett kontrollplan fungerar som ett eget system, så du bör överväga alla fem pelarna i Well-Architected Framework när du utformar ett. Följande avsnitt belyser specifika områden att fokusera på.

Tillförlitlighet

Tillförlitlighet hjälper till att säkerställa att ditt program kan uppfylla de åtaganden som du gör gentemot dina kunder. Mer information finns i Checklista för designgranskning för tillförlitlighet.

Kontrollplan fungerar ofta som verksamhetskritiska komponenter. Du måste planera lämplig återhämtningsnivå och tillförlitlighet som kontrollplanet behöver.

Överväg effekten av ett avbrott i kontrollplanet. I extrema fall kan ett avbrott göra hela lösningen otillgänglig. Även om kontrollplanet inte är en enda felpunkt kan ett avbrott orsaka följande problem:

  • Systemet kan inte registrera nya klienter, vilket kan påverka din försäljning och affärstillväxt.

  • Systemet kan inte hantera befintliga klienter, vilket resulterar i fler anrop till supportteamet.

  • Du kan inte mäta förbrukningen av klienter eller fakturera dem för deras användning, vilket resulterar i förlorade intäkter.

  • Du kan inte inaktivera eller omkonfigurera en hyresgäst som svar på en säkerhetsincident.

  • Underhållsskulden ackumuleras, vilket resulterar i långsiktiga skador på systemet. Om din lösning till exempel kräver att gamla data rensas varje natt kan diskarna bli fulla eller så kan prestandan försämras.

Definiera servicenivåmål för kontrollplanet, inklusive tillgänglighetsmål, mål för återställningstid (RTO) och mål för återställningspunkt (RPO). De mål som du anger för kontrollplanet kan skilja sig från de mål som du erbjuder dina kunder.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Checklista för designgranskning för säkerhet.

Kontrollplan är ofta mycket privilegierade system. Säkerhetsproblem i ett kontrollplan kan få katastrofala konsekvenser. Beroende på dess design och funktioner kan ett kontrollplan vara sårbart för många olika typer av attacker, inklusive följande typer:

  • Obehörig åtkomst till hemligheter: Kontrollplanet kan ha åtkomst till nycklar och hemligheter för alla hyresgäster. En angripare som har åtkomst till kontrollplanet kan få åtkomst till klientorganisationens data eller resurser.

  • Missbruk av distributionsfunktioner: Ett kontrollplan kan ofta distribuera nya resurser till Azure. Angripare kan utnyttja ditt kontrollplan för att distribuera sina egna resurser till dina prenumerationer och eventuellt medföra omfattande avgifter.

  • Denial of Service: Om en angripare stänger ner ditt kontrollplan kan omedelbara och långsiktiga skador på systemet och verksamheten inträffa. Potentiella konsekvenser av kontrollplanets stilleståndstid finns i Tillförlitlighet.

När du utformar och implementerar ett kontrollplan måste du följa rekommenderade säkerhetsmetoder och skapa en omfattande hotmodell. Den här modellen bör identifiera och minimera potentiella hot och säkerhetsproblem i din lösning.

Operativ skicklighet

Operational Excellence omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Checklista för designgranskning för Operational Excellence.

Ett kontrollplan är en viktig komponent, så du bör noga överväga hur du distribuerar och använder det i produktion.

Precis som andra delar av lösningen bör du distribuera icke-produktionsinstanser av kontrollplanet så att du kan testa deras funktioner noggrant. Om kontrollplanet utför distributionsåtgärder bör du tänka på hur dina icke-produktionskontrollplan interagerar med din Azure-miljö och vilken Azure-prenumeration som du vill distribuera icke-produktionsresurser till. Planera hur du snabbt ska rensa testresurser så att de inte ackumulerar avgifter av misstag.

Planera även hur du ska styra teamets åtkomst till ditt kontrollplan. Bevilja endast de behörigheter som gruppmedlemmar behöver för att utföra sina uppgifter. Den här metoden hjälper till att förhindra säkerhetsincidenter och minska effekten av oavsiktlig felkonfiguration.

Komponenter

Det finns ingen enskild mall för att skapa ett kontrollplan. De komponenter som du utformar och bygger beror på dina krav. De flesta kontrollplan består av API:er och bakgrundsarbetskomponenter. I vissa lösningar innehåller ett kontrollplan även ett användargränssnitt som ditt team eller till och med dina kunder kan använda.

Isolera kontrollplanet från klientarbetsbelastningar

Du bör separera kontrollplanens resurser från resurser som betjänar hyresgästens dataplan. Använd till exempel separata databasservrar, programservrar och andra komponenter. Behåll kontrollplansresurser i en dedikerad Azure-resursgrupp, separat från klientspecifika resurser.

Isolering av kontrollplan ger följande fördelar:

  • Du kan konfigurera skalning separat. Kontrollplanet kan till exempel ha konsekventa resurskrav och klientorganisationens resurser kan skalas elastiskt beroende på deras behov.

  • En tydlig separation skapar ett skott mellan dina kontrollplan och dataplan, vilket hjälper till att förhindra att bullriga grannproblem sprids över din lösning.

  • Kontrollplan är vanligtvis mycket privilegierade system som har hög åtkomstnivå. Isolering av kontrollplan minskar sannolikheten för en säkerhetsrisk så att angripare kan höja sina behörigheter i hela systemet.

  • Du kan distribuera separata nätverks- och brandväggskonfigurationer. Dataplan och kontrollplan kräver vanligtvis olika typer av nätverksåtkomst.

Orkestrera sekvenser med långvariga åtgärder

Kontrollplan utför ofta långvariga åtgärder som kräver samordning mellan flera system. Dessa åtgärder kan också ha komplexa fellägen, så du måste välja tekniker som stöder långvariga åtgärder eller arbetsflöden.

När du till exempel registrerar en ny klient kan kontrollplanet köra följande åtgärder i följd:

  1. Distribuera en ny databas. Den här Azure-distributionsåtgärden kan ta flera minuter att slutföra.

  2. Uppdatera din klientmetadatakatalog. Den här åtgärden kan innebära att köra ett kommando mot en Azure SQL-databas.

  3. Skicka ett välkomstmeddelande till den nya klientorganisationen. Den här åtgärden anropar ett ICKE-Microsoft-API för att skicka e-postmeddelandet.

  4. Uppdatera faktureringssystemet för att förbereda för att fakturera den nya klientorganisationen. Den här åtgärden anropar ett ICKE-Microsoft-API som ibland misslyckas.

  5. Uppdatera crm-systemet (customer relationship management) för att spåra den nya klientorganisationen. Den här åtgärden anropar ett API som inte kommer från Microsoft.

Om något steg i sekvensen misslyckas bör du överväga hur du ska svara:

  • Försök igen med den misslyckade åtgärden. Om ditt Azure SQL-kommando i steg 2 till exempel misslyckas med ett tillfälligt fel kan du försöka igen.

  • Fortsätt till nästa steg. Du kan till exempel bestämma att du kan tillåta att uppdateringen av faktureringssystemet misslyckas eftersom säljteamet kan lägga till kunden manuellt senare.

  • Överge arbetsflödet och utlösa en manuell återställningsprocess.

Tänk också på användarupplevelsen för varje felscenario.

Hantera delade komponenter

Ett kontrollplan måste identifiera alla komponenter som delas i stället för dedikerade till specifika klienter. Vissa komponenter kan delas mellan alla klienter inom en stämpel. Andra komponenter kan delas mellan alla stämplar i en region, eller till och med delas globalt i alla regioner och stämplar. När du registrerar, konfigurerar om eller avregistrerar en klientorganisation måste kontrollplanet veta hur de delade komponenterna ska hanteras.

Vissa delade komponenter kräver omkonfiguration när klienter läggs till eller tas bort. Anta till exempel att du har en globalt delad Azure Front Door-profil. Om du lägger till en klientorganisation som har ett anpassat domännamn kan kontrollplanet behöva uppdatera profilens konfiguration för att dirigera begäranden för domännamnet till rätt program. På samma sätt kan kontrollplanet när en klientorganisation är avregistrerad behöva ta bort det anpassade domännamnet från Azure Front Door-profilen för att undvika underdomänövertagandeattacker.

Delade komponenter kan ha komplexa skalningsregler som kontrollplanet måste följa. Om du till exempel använder en bin-packning för att distribuera dina tenants databaser måste kontrollinstansen tilldela varje ny databas till en elastisk Azure SQL-pool.

Du kan fastställa att du behöver öka de resurser som allokerats till poolen för varje tionde databas som du lägger till. När du lägger till eller tar bort en klient måste kontrollplanet utvärdera poolens konfiguration igen och bestämma om poolens resurser ska ändras. När du når det maximala antalet databaser som du kan tilldela till en enda elastisk pool måste du skapa en ny pool och använda poolen för nya klientdatabaser. Kontrollplanet måste hantera var och en av dessa delade komponenter, inklusive skalning och omkonfiguration av dem när ändringar sker.

När kontrollplanet hanterar delade komponenter är det viktigt att vara medveten om konkurrensförhållanden, vilket kan inträffa när flera åtgärder utförs parallellt. Om du till exempel registrerar en ny klient samtidigt som du avregistrerar en annan klientorganisation måste du se till att det ultimata sluttillståndet är konsekvent och uppfyller dina skalningskrav.

Använda flera kontrollplan

I en komplex miljö kan du behöva använda flera kontrollplan som hanterar olika områden. Många lösningar för flera klienter följer mönstret Distributionsstämplar och shardklientorganisationer över flera stämplar. I det här mönstret kan du skapa separata kontrollplan för globala ansvarsområden och stämpelansvar.

Tips/Råd

Samordning över flera kontrollplan ger komplexitet, så försök att minimera antalet kontrollplan som du skapar. De flesta lösningar behöver bara ett kontrollplan.

Globala kontrollplan

Ett globalt kontrollplan hanterar vanligtvis övergripande hantering och spårning av klienter. Ett globalt kontrollplan kan ha följande ansvarsområden:

  • Placering av klientorganisation: Det globala kontrollplanet avgör vilken stämpel en klient ska använda. Den kan göra detta baserat på faktorer som klientorganisationens region, varje stämpels kapacitetsanvändning och klientens servicenivåkrav.

  • Hyresgästanpassning och livscykelhantering: Dessa ansvarsområden omfattar spårning av alla hyresgäster över distributioner.

Plan för stämpelkontroll

Varje distributionsstämpel innehåller ett eget stämpelkontrollplan som hanterar klientorganisationer och resurser som allokerats till den stämpeln. Ett stämpelkontrollplan kan ha följande ansvarsområden:

  • Etablering av klientresurser: Den skapar och hanterar klientspecifika resurser inom plattformen, till exempel databaser och lagringscontainrar.

  • Hantering av delade resurser: Den övervakar förbrukningen av delade resurser och distribuerar nya instanser när de närmar sig sin maximala kapacitet.

  • Underhållsåtgärder: Den hanterar uppgifter inom stämpeln, till exempel hantering av databasindex och rensningsåtgärder.

Varje stämpels kontrollplan koordineras med det globala kontrollplanet. Om en ny klientorganisation till exempel registrerar sig kan det globala kontrollplanet initialt välja en stämpel för klientorganisationens resurser. Sedan uppmanar det globala kontrollplanet stämpelns kontrollplan att skapa nödvändiga resurser för klientorganisationen.

Följande diagram visar hur två kontrollplan kan samexistera i ett enda system.

Diagram som visar en logisk systemdesign. Designen har ett globalt kontrollplan och stämpelkontrollplan.

Klientkontrollplan

Klienter kan använda ett kontrollplan på klientorganisationsnivå för att hantera sina egna logiska eller fysiska resurser. Ett klientkontrollplan kan ha följande ansvarsområden:

  • Konfigurationshantering: Den hanterar klientspecifik konfiguration, till exempel användaråtkomst.

  • Klientinitierade underhållsåtgärder: Den stöder åtgärder som säkerhetskopiering av data eller nedladdning av tidigare säkerhetskopior.

  • Uppdateringshantering: Den utför uppdateringar om du tillåter klientorganisationer att styra sina egna uppdateringar av sina program.

Följande diagram visar ett komplext system som har ett globalt kontrollplan, stämpelkontrollplan och klientkontrollplan.

Diagram som visar en logisk systemdesign. Designen har ett globalt kontrollplan, stämpelkontrollplan och klientkontrollplan.

Bidragsgivare

Microsoft ansvarar för den här artikeln. Följande deltagare skrev den här artikeln.

Huvudförfattare:

Övriga medarbetare:

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg