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

En lösning för flera klientorganisationer har flera plan och var och en har sitt eget ansvar. Dataplanet gör det möjligt för slutanvändare och klienter att interagera med systemet. Kontrollplanet är den komponent som hanterar uppgifter på högre nivå för alla klienter, till exempel åtkomstkontroll, etablering och systemunderhåll för att stödja plattformsadministratörernas uppgifter.

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 slutanvändarna får åtkomst till 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. Dina klienter ser det förmodligen som ett sätt att använda systemet för sitt avsedda syfte. Kontrollplanet är den komponent som registrerar nya klienter, skapar databaser för varje klientorganisation och utför andra hanterings- och underhållsåtgärder. Om systemet inte hade något kontrollplan skulle administratörer behöva köra många manuella processer. Eller så skulle dataplans- och kontrollplansuppgifter blandas ihop, vilket överkomplicerar lösningen.

Många komplexa system omfattar kontrollplan. Azure-kontrollplanet, Azure Resource Manager, är till exempel en uppsättning API:er, verktyg och serverdelskomponenter som ansvarar för att distribuera och konfigurera Azure-resurser. 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. Följande avsnitt innehåller den information som du behöver för att omfångsbegränsa och utforma 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. 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:

• Etablera och hantera de systemresurser som systemet behöver för att hantera arbetsbelastningen, inklusive klientspecifika resurser. Kontrollplanet kan anropa och orkestrera en distributionspipeline som ansvarar för distributioner, eller så kan det köra själva distributionsåtgärderna.
• Konfigurera om delade resurser så att de är medvetna om nya klienter. Kontrollplanet kan till exempel konfigurera nätverksroutning för att säkerställa att inkommande trafik mappas till rätt klientorganisations resurser, eller så kan du behöva skala resurskapaciteten.
• Lagra och hantera konfigurationen för varje klientorganisation.
• Hantera klientorganisationens livscykelhändelser, inklusive registrering, flytt och offboarding-klientorganisationer.
• Spåra varje klientorganisations användning av dina funktioner och systemets prestanda.
• Mät varje klientorganisations förbrukning av systemets resurser. Förbrukningsmått kan informera dina faktureringssystem, eller så kan de användas för resursstyrning.

Om du använder den fullständigt multitenanta innehavarmodellen och inte distribuerar några klientspecifika resurser kan ett grundläggande kontrollplan bara spåra klienter och deras associerade 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.

Anta däremot att din lösning använder en distributionsmodell som kräver klientspecifik infrastruktur, till exempel den automatiserade modellen med en enda klientorganisation. I det här scenariot kan kontrollplanet ha ytterligare ansvarsområden, till exempel att distribuera eller konfigurera om Azure-infrastrukturen när du registrerar en ny klientorganisation. Din lösnings kontrollplan behöver förmodligen interagera med kontrollplan för de tjänster och tekniker som du använder, till exempel Azure Resource Manager eller Kubernetes-kontrollplanet.

Mer avancerade kontrollplan kan också ta mer ansvar:

• Utför automatiserade underhållsåtgärder. Vanliga underhållsåtgärder är att ta bort eller arkivera gamla data, skapa och hantera databasindex och rotera hemligheter och kryptografiska certifikat.
• Allokera klienter till befintliga distributioner eller stämplar, som ibland kallas innehavarplacering.
• Balansera om befintliga klienter mellan distributionsstämplar.
• Integrera med externa kundhanteringslösningar, till exempel Microsoft Dynamics 365, för att spåra kundaktivitet.

Omfång för ett kontrollplan

Du måste noga överväga hur mycket arbete du behöver lägga på att skapa ett kontrollplan för din lösning. Kontrollplan själva ger inte omedelbart kundvärde, så det kanske inte är lätt att motivera tekniska ansträngningar för att utforma och bygga ett högkvalitativt kontrollplan. I takt med att systemet växer och skalas behöver du dock i allt högre grad automatiserad hantering och åtgärder för att kunna hålla jämna nivå med din tillväxt.

I vissa situationer kanske du inte behöver ett fullständigt kontrollplan. Den här situationen kan gälla om systemet har färre än fem klienter. I stället kan ditt team 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 en central plats för att spåra dina klienter och deras konfigurationer.

När du växer bortom några få klienter kommer du förmodligen att ha nytta av att ha ett sätt att spåra varje klientorganisation och tillämpa övervakning över din flotta av resurser och klienter. Du kanske också 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 är det värt att överväga att bygga ett mer omfattande kontrollplan för att ta på sig dessa ansvarsområden.

Utforma ett kontrollplan

När du har fastställt kraven och omfattningen för kontrollplanet måste du utforma och utforma det. Ett kontrollplan är en viktig komponent. Du måste planera det noggrant, precis som du planerar de andra elementen i systemet.

Välarkitekterade kontrollplan

Eftersom ett kontrollplan är ett eget system är det viktigt att tänka på alla fem grundpelarna i Azure Well-Architected Framework när du utformar ett. Följande avsnitt belyser några specifika områden att fokusera på.

Tillförlitlighet

Kontrollplan är ofta verksamhetskritiska komponenter. Det är viktigt att du planerar den återhämtningsnivå och tillförlitlighet som kontrollplanet behöver.

Tänk på vad som händer om kontrollplanet inte är tillgängligt. I extrema fall kan ett avbrott i kontrollplanet leda till att hela lösningen inte är tillgänglig. Även om kontrollplanet inte är en enda felpunkt kan ett avbrott ha några av följande effekter:

• 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 svara på en säkerhetsincident genom att inaktivera eller konfigurera om en klientorganisation.
• 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 fyllas på 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 som du erbjuder dina kunder.

Följ vägledningen för Azure Well-Architected Framework för att skapa tillförlitliga lösningar i hela systemet, inklusive ditt kontrollplan.

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:

• Ett kontrollplan kan ha åtkomst till nycklar och hemligheter för alla klienter. En angripare som har åtkomst till kontrollplanet kanske kan få åtkomst till en klientorganisations data eller resurser.
• Ett kontrollplan kan ofta distribuera nya resurser till Azure. Angripare kanske kan utnyttja ditt kontrollplan för att distribuera sina egna resurser till dina prenumerationer, vilket kan medföra omfattande avgifter.
• Om en angripare lyckas koppla från ditt kontrollplan kan det uppstå omedelbara och långsiktiga skador på systemet och ditt företag. Se Tillförlitlighet för exempel på konsekvenser av att ett kontrollplan inte är tillgängligt.

När du utformar och implementerar ett kontrollplan är det viktigt att du följer rekommenderade säkerhetsmetoder och skapar en omfattande hotmodell för att dokumentera och minimera potentiella hot och säkerhetsproblem i din lösning. Mer information finns i vägledningen för Azure Well-Architected Framework för att skapa säkra lösningar.

Driftsäkerhet

Eftersom ett kontrollplan är en kritisk komponent bör du 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 dess funktioner noggrant. Om kontrollplanet utför distributionsåtgärder bör du överväga hur dina kontrollplan som inte är produktionsbaserade interagerar med din Azure-miljö och vilken Azure-prenumeration du distribuerar icke-produktionsresurser till.

Du bör också planera hur du styr teamets åtkomst till ditt kontrollplan. Följ metodtipsen för att endast bevilja de behörigheter som gruppmedlemmar behöver för att utföra sina uppgifter. Förutom att hjälpa till att undvika säkerhetsincidenter hjälper den här metoden till att minska effekten av oavsiktlig felkonfiguration.

Komponenter

Det finns ingen enskild mall för ett kontrollplan, och de komponenter som du utformar och skapar beror på dina krav. Ett kontrollplan består vanligtvis av API:er och bakgrundsarbetskomponenter. I vissa lösningar kan ett kontrollplan också innehålla ett användargränssnitt.

Isolera kontrollplanet från klientarbetsbelastningar

Det är en bra idé att skilja kontrollplanets resurser från de som används för att hantera klientorganisationens dataplan. Du bör till exempel överväga att använda separata databasservrar, programservrar och Azure App Service-planer och andra komponenter. Det är ofta en bra idé att behålla kontrollplanets resurser i en separat Azure-resursgrupp från dem som innehåller klientspecifika resurser.

Genom att isolera kontrollplanet från klienternas arbetsbelastningar får du flera fördelar:

• Du kan konfigurera skalning separat. Kontrollplanet kan till exempel ha konsekventa resurskrav och klientorganisationens resurser kan skalas elastiskt beroende på deras behov.
• Det finns ett skott mellan din kontroll och dataplan, vilket hjälper till att förhindra att bullriga grannproblem sprids mellan planen i din lösning.
• Kontrollplan är vanligtvis mycket privilegierade system som har hög åtkomstnivå. Genom att separera kontrollplanet från dataplan minskar du sannolikheten för att en säkerhetsrisk kan göra det möjligt för angripare att 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

De åtgärder som ett kontrollplan utför är ofta tidskrävande och omfattar samordning mellan flera system. Åtgärderna kan också ha komplexa fellägen. När du utformar kontrollplanet är det viktigt att använda en lämplig teknik för att samordna långvariga åtgärder eller arbetsflöden.

Anta till exempel att kontrollplanet kör följande åtgärder i följd när du registrerar en ny klientorganisation:

1. Distribuera en ny databas. Den här åtgärden är en Azure-distributionsåtgärd. Det 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 API från tredje part 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 API från tredje part. Du har märkt att det misslyckas tillfälligt.
5. Uppdatera crm-systemet (customer relationship management) för att spåra den nya klientorganisationen. Den här åtgärden anropar ett API från tredje part.

Om något steg i sekvensen misslyckas måste du överväga vad du ska göra, till exempel:

• 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 besluta att det är acceptabelt om uppdateringen av faktureringssystemet misslyckas, eftersom säljteamet lägger till kunden manuellt.
• Överge arbetsflödet och utlösa en manuell återställningsprocess.

Du måste också tänka på hur användarupplevelsen är för varje felscenario.

Hantera delade komponenter

Ett kontrollplan måste vara medvetet om komponenter som inte är dedikerade till specifika klienter, utan i stället delas. 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 en klientorganisation registreras, konfigureras om eller avregistreras måste kontrollplanet veta vad du ska göra med dessa delade komponenter.

Vissa delade komponenter kan behöva konfigureras om när en klient 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 med 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. Anta till exempel att du följer en metod för paketering av lagerplatser för att distribuera klientorganisationens databaser. När en ny klientorganisation registreras lägger du till en ny Azure SQL-databas för den klientorganisationen och tilldelar den sedan till en elastisk Azure SQL-pool. Du kanske har fastställt 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 börja använda poolen för nya klientdatabaser. Kontrollplanet måste ta ansvar för att hantera var och en av dessa delade komponenter, skala och konfigurera om dem när något ändras.

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, var och en med olika ansvarsområden. Många lösningar för flera klienter följer mönstret Distributionsstämplar och shardklientorganisationer över flera stämplar. När du använder det här mönstret kan du skapa separata kontrollplan för globala ansvarsområden och stämpelansvar.

Globala kontrollplan

Ett globalt kontrollplan ansvarar vanligtvis för den övergripande hanteringen och spårningen 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. Det kan göra den här bedömningen baserat på faktorer som klientorganisationens region, varje stämpels kapacitetsanvändning och klientens servicenivåkrav.
• Registrering av klientorganisation och livscykelhantering. Dessa ansvarsområden omfattar spårning av alla klienter i alla distributioner.

Plan för stämpelkontroll

Ett stämpelkontrollplan distribueras till varje distributionsstämpel och ansvarar för de klienter och resurser som allokeras till den stämpeln. Ett stämpelkontrollplan kan ha följande ansvarsområden:

• Skapa och hantera klientspecifika resurser inom stämpeln, till exempel databaser och lagringscontainrar
• Hantera delade resurser, inklusive övervakning av förbrukningen av delade resurser och distribution av nya instanser när de närmar sig sin maximala kapacitet
• Utföra underhållsåtgärder inom stämpeln, till exempel hantering av databasindex och rensningsåtgärder

Varje stämpels kontrollplan koordineras med det globala kontrollplanet. Anta till exempel att en ny klientorganisation registrerar sig. Det globala kontrollplanet ansvarar först för att 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 ett exempel på hur de två kontrollplanen kan samexistera i ett enda system:

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:

• Hantering av klientspecifik konfiguration, till exempel användaråtkomst
• Klientinitierade underhållsåtgärder, till exempel säkerhetskopiering av data eller nedladdning av en tidigare säkerhetskopia
• Uppdateringshantering, 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 ett kontrollplan för varje klientorganisation:

Deltagare

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

Huvudförfattare:

• John Downs | Huvudkundtekniker, FastTrack för Azure

Övriga medarbetare:

• Mick Alberts | Teknisk författare
• Bohdan Cherchyk | Senior kundtekniker, FastTrack för Azure
• Landon Pierce | Kundtekniker, FastTrack för Azure
• Daniel Scott-Raynsford | Partnerteknikstrateg
• Arsen Vladimirskiy | Huvudkundtekniker, FastTrack för Azure

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

Nästa steg

• Översikt över arkitekturöverväganden
• Azure Well-Architected Framework
• Arkitekturmetoder för kontrollplan i lösningar för flera klientorganisationer