Víceklientové řešení má více rovin a každý má své vlastní zodpovědnosti. Rovina dat umožňuje koncovým uživatelům a klientům pracovat se systémem. Řídicí rovina je komponenta, která spravuje úlohy vyšší úrovně napříč všemi tenanty, jako je řízení přístupu, zřizování a údržba systému pro podporu úloh správců platformy.
Tento článek obsahuje informace o zodpovědnostech řídicích rovin a o tom, jak navrhnout řídicí rovinu, která vyhovuje vašim potřebám.
Představte si například systém účetnictví pro správu finančních záznamů. V systému ukládá několik tenantů své finanční záznamy. Když koncoví uživatelé přistupují k systému, aby mohli zobrazit a zadat své finanční záznamy, používají rovinu dat. Rovina dat je pravděpodobně primární komponentou aplikace pro vaše řešení. Vaši tenanti si ho pravděpodobně myslí jako způsob, jak systém používat pro zamýšlený účel. Řídicí rovina je komponenta, která onboarduje nové tenanty, vytváří databáze pro každého tenanta a provádí další operace správy a údržby. Pokud systém nemá řídicí rovinu, správci by museli spouštět mnoho ručních procesů. Úkoly roviny dat a řídicí roviny by se také směšovaly dohromady a překomplikovaly řešení.
Mnoho složitých systémů zahrnuje řídicí roviny. Například řídicí rovina Azure, Azure Resource Manager, je sada rozhraní API, nástrojů a back-endových komponent, které zodpovídají za nasazení a konfiguraci prostředků Azure. Řídicí rovina Kubernetes spravuje mnoho úloh, jako je umístění podů Kubernetes na pracovních uzlech. Téměř všechna řešení typu software jako služba (SaaS) mají řídicí rovinu pro zpracování úloh napříč tenanty.
Při návrhu víceklientských řešení je potřeba zvážit řídicí roviny. Následující části obsahují podrobnosti, které potřebujete k určení rozsahu a návrhu řídicí roviny.
Odpovědnosti řídicí roviny
Neexistuje žádná šablona řídicí roviny ani její odpovědnosti. Požadavky a architektura vašeho řešení určují, co vaše řídicí rovina musí dělat. V některých víceklientských řešeních má řídicí rovina širokou škálu zodpovědností a je to složitý systém ve svém vlastním právu. V jiných víceklientských řešeních má řídicí rovina pouze základní povinnosti.
Řídicí rovina může mít obecně mnoho z následujících základních zodpovědností:
- Zřiďte a spravujte systémové prostředky, které systém potřebuje k poskytování úloh, včetně prostředků specifických pro tenanta. Vaše řídicí rovina může vyvolat a orchestrovat kanál nasazení, který je zodpovědný za nasazení, nebo může spouštět samotné operace nasazení.
- Překonfigurujte sdílené prostředky tak, aby věděly o nových tenantech. Vaše řídicí rovina může například nakonfigurovat směrování sítě, aby se zajistilo, že příchozí provoz je namapovaný na správné prostředky tenanta, nebo možná budete muset kapacitu prostředku škálovat.
- Uložte a spravujte konfiguraci každého tenanta.
- Zpracování událostí životního cyklu tenanta, včetně onboardingu, přesunu a offboardingu tenantů
- Sledujte, jak jednotlivé tenanty používají vaše funkce a výkon systému.
- Změřte spotřebu prostředků systému každého tenanta. Metriky spotřeby můžou informovat vaše fakturační systémy nebo se můžou používat pro zásady správného řízení prostředků.
Pokud používáte plně víceklientská tenantská architektura a nenasazujete žádné prostředky specifické pro tenanty, základní řídicí rovina může jenom sledovat tenanty a jejich přidružená metadata. Například pokaždé, když se nový tenant zaregistruje do vaší služby, může řídicí rovina aktualizovat příslušné záznamy v databázi tak, aby zbytek systému mohl obsluhovat požadavky nového tenanta.
Předpokládejme, že vaše řešení používá model nasazení, který vyžaduje infrastrukturu specifickou pro tenanta, jako je automatizovaný model s jedním tenantem. V tomto scénáři může mít vaše řídicí rovina další zodpovědnosti, jako je nasazení nebo změna konfigurace infrastruktury Azure pokaždé, když nasadíte nového tenanta. Řídicí rovina vašeho řešení pravděpodobně potřebuje pracovat s řídicími rovinami pro služby a technologie, které používáte, jako je Azure Resource Manager nebo řídicí rovina Kubernetes.
Pokročilejší řídicí roviny můžou mít také větší odpovědnost:
- Proveďte automatizované operace údržby. Mezi běžné operace údržby patří odstranění nebo archivace starých dat, vytváření a správa indexů databáze a obměně tajných kódů a kryptografických certifikátů.
- Přidělte tenantům existující nasazení nebo razítka, což se někdy označuje jako umístění tenanta.
- Změna rovnováhy existujících tenantů napříč razítky nasazení
- Integrace s externími řešeními pro správu zákazníků, jako je Microsoft Dynamics 365, za účelem sledování aktivit zákazníků
Určení rozsahu řídicí roviny
Musíte pečlivě zvážit, kolik úsilí vynaložené na vytvoření řídicí roviny pro vaše řešení. Řídicí roviny samy o sobě neposkytují okamžitou hodnotu zákazníka, takže nemusí být snadné ospravedlnit úsilí přípravy výdajů na navrhování a vytváření vysoce kvalitní řídicí roviny. Jak ale váš systém roste a škáluje, budete stále více potřebovat automatizovanou správu a operace, abyste mohli držet krok s růstem.
V některých situacích možná nebudete potřebovat úplnou řídicí rovinu. Tato situace se může použít, pokud váš systém bude mít méně než pět tenantů. Místo toho může váš tým převzít odpovědnost řídicí roviny a může používat ruční operace a procesy k onboardingu a správě tenantů. Přesto byste měli mít proces a centrální místo ke sledování tenantů a jejich konfigurací.
Tip
Pokud se rozhodnete nevytvořovat úplnou řídicí rovinu, je stále vhodné, abyste se mohli systematicky zabývat vašimi postupy řízení:
- Důkladně zdokumentujte procesy.
- Kdykoli je to možné, vytvořte a znovu použijte skripty pro operace správy.
Pokud potřebujete procesy v budoucnu automatizovat, můžou vaše dokumentace a skripty tvořit základ řídicí roviny.
S tím, jak rostete nad rámec několika tenantů, budete mít pravděpodobně výhodu, že budete mít možnost sledovat každého tenanta a používat monitorování napříč vozovým parkem prostředků a tenantů. Můžete si také všimnout, že váš tým stráví rostoucím množstvím času a úsilím na správu tenantů. Nebo si můžete všimnout chyb nebo provozních problémů z důvodu nekonzistence způsoby, kterými členové týmu provádějí úlohy správy. Pokud k těmto situacím dojde, je vhodné zvážit vytvoření komplexnější řídicí roviny, aby tyto povinnosti převzaly.
Poznámka:
Pokud poskytujete samoobslužnou správu tenantů, potřebujete řídicí rovinu na začátku cesty. Můžete se rozhodnout vytvořit základní řídicí rovinu a automatizovat jenom některé z nejčastěji používaných funkcí. V průběhu času můžete postupně přidávat další funkce.
Návrh řídicí roviny
Jakmile určíte požadavky a rozsah řídicí roviny, musíte ji navrhnout a navrhnout. Řídicí rovina je důležitou součástí. Potřebujete ho pečlivě naplánovat stejně jako ostatní prvky systému.
Dobře navržená řídicí rovina
Vzhledem k tomu, že řídicí rovina je vlastní systém, je důležité při návrhu vzít v úvahu všechny pět pilířů architektury Azure Well-Architected Framework . Následující části zvýrazňují některé konkrétní oblasti, na které se chcete zaměřit.
Spolehlivost
Řídicí roviny jsou často klíčové komponenty. Je nezbytné naplánovat úroveň odolnosti a spolehlivosti, kterou vaše řídicí rovina potřebuje.
Zvažte, co se stane, pokud řídicí rovina není k dispozici. V extrémních případech může výpadek řídicí roviny způsobit nedostupnost celého řešení. I když řídicí rovina není kritickým bodem selhání, může dojít k výpadku některých z následujících efektů:
- Váš systém nemůže připojit nové tenanty, což může mít vliv na váš prodej a obchodní růst.
- Váš systém nemůže spravovat existující tenanty, což vede k dalším voláním týmu podpory.
- Nemůžete měřit spotřebu tenantů ani je účtovat za jejich využití, což vede ke ztrátě výnosů.
- Na incident zabezpečení nemůžete reagovat zakázáním nebo opětovnou konfigurací tenanta.
- Dluh na údržbu se hromadí, což vede k dlouhodobému poškození systému. Pokud například vaše řešení vyžaduje noční vyčištění starých dat, disky by mohly zaplnit nebo by se výkon mohl snížit.
Definujte cíle na úrovni služby pro řídicí rovinu, včetně cílů dostupnosti, cíle doby obnovení (RTO) a cíle bodu obnovení (RPO). Cíle nastavené pro řídicí rovinu se můžou lišit od cílů, které zákazníkům nabízíte.
Postupujte podle pokynů k architektuře Azure pro vytváření spolehlivých řešení v celém systému, včetně řídicí roviny.
Zabezpečení
Řídicí roviny jsou často vysoce privilegované systémy. Bezpečnostní problémy v řídicí rovině můžou mít katastrofické důsledky. V závislosti na jeho návrhu a funkčnosti může být řídicí rovina zranitelná vůči mnoha různým typům útoků, včetně následujících:
- Řídicí rovina může mít přístup ke klíčům a tajným kódům pro všechny tenanty. Útočník, který má přístup k řídicí rovině, může mít přístup k datům nebo prostředkům tenanta.
- Řídicí rovina může často nasazovat nové prostředky do Azure. Útočníci můžou vaši řídicí rovinu zneužít k nasazení vlastních prostředků do vašich předplatných a potenciálně se vám budou účtovat rozsáhlé poplatky.
- Pokud útočník úspěšně přenese řídicí rovinu do režimu offline, může dojít k okamžitému a dlouhodobému poškození systému a vaší firmy. Viz Spolehlivost , například důsledky nedostupnosti řídicí roviny.
Při návrhu a implementaci řídicí roviny je nezbytné dodržovat osvědčené postupy zabezpečení a vytvořit komplexní model hrozeb pro dokumentaci a zmírnění potenciálních hrozeb a problémů se zabezpečením ve vašem řešení. Další informace najdete v pokynech k architektuře Azure pro vytváření zabezpečených řešení.
Provozní dokonalost
Vzhledem k tomu, že řídicí rovina je kritická komponenta, měli byste pečlivě zvážit, jak ji nasadíte a provozujete v produkčním prostředí.
Stejně jako jiné části řešení byste měli nasadit neprodukční instance řídicí roviny, abyste mohli důkladně otestovat jeho funkčnost. Pokud řídicí rovina provádí operace nasazení, zvažte, jak vaše neprodukční řídicí roviny komunikují s prostředím Azure a do kterého předplatného Azure nasadíte neprodukční prostředky.
Měli byste také naplánovat, jak řídit přístup týmu k řídicí rovině. Při udělování oprávnění, která členové týmu potřebují k plnění svých povinností, dodržujte osvědčené postupy. Kromě toho, že pomáháte vyhnout se incidentům zabezpečení, tento přístup pomáhá snížit vliv náhodné chybné konfigurace.
Součásti
Pro řídicí rovinu neexistuje žádná šablona a komponenty, které navrhujete a sestavujete, závisí na vašich požadavcích. Řídicí rovina se obvykle skládá z rozhraní API a komponent pracovních procesů na pozadí. V některých řešeních může řídicí rovina obsahovat také uživatelské rozhraní.
Izolace řídicí roviny od úloh tenanta
Je vhodné oddělit prostředky řídicí roviny od prostředků používaných k poskytování roviny dat tenantů. Měli byste například zvážit použití samostatných databázových serverů, aplikačních serverů a Aplikace Azure plánů služeb a dalších komponent. Často je vhodné zachovat prostředky řídicí roviny v samostatné skupině prostředků Azure od prostředků, které obsahují prostředky specifické pro tenanta.
Izolováním řídicí roviny z úloh tenantů získáte několik výhod:
- Škálování můžete nakonfigurovat samostatně. Vaše řídicí rovina může mít například konzistentní požadavky na prostředky a prostředky tenantů se můžou elasticky škálovat v závislosti na jejich potřebách.
- Mezi řídicími rovinami a rovinami dat existuje přepážka , která pomáhá zabránit hlučným problémům sousedů v šíření mezi rovinami vašeho řešení.
- Řídicí roviny jsou obvykle vysoce privilegované systémy, které mají vysokou úroveň přístupu. Oddělením řídicí roviny od roviny dat snížíte pravděpodobnost, že ohrožení zabezpečení může útočníkům umožnit zvýšit svá oprávnění v celém systému.
- Můžete nasadit samostatné konfigurace sítě a brány firewall. Roviny dat a řídicí roviny obvykle vyžadují různé typy přístupu k síti.
Orchestrace sekvencí dlouhotrvajících operací
Operace, které řídicí rovina provádí, jsou často dlouhotrvající a zahrnují koordinaci mezi více systémy. Operace můžou mít také složité režimy selhání. Při návrhu řídicí roviny je důležité použít vhodnou technologii pro koordinaci dlouhotrvajících operací nebo pracovních postupů.
Předpokládejme například, že když připojíte nového tenanta, vaše řídicí rovina spustí následující akce v posloupnosti:
- Nasaďte novou databázi. Tato akce je operace nasazení Azure. Dokončení může trvat několik minut.
- Aktualizujte katalog metadat tenanta. Tato akce může zahrnovat spuštění příkazu pro databázi Azure SQL.
- Pošlete uvítací e-mail novému tenantovi. Tato akce vyvolá rozhraní API třetí strany k odeslání e-mailu.
- Aktualizujte fakturační systém a připravte se na fakturaci nového tenanta. Tato akce vyvolá rozhraní API třetí strany. Všimli jste si, že občas selže.
- Aktualizujte systém správy vztahů se zákazníky (CRM) tak, aby sledoval nového tenanta. Tato akce vyvolá rozhraní API třetí strany.
Pokud některý krok v sekvenci selže, musíte zvážit, co dělat, například:
- Zopakujte neúspěšnou operaci. Pokud například váš příkaz Azure SQL v kroku 2 selže s přechodnou chybou, můžete to zkusit znovu.
- Pokračujte dalším krokem. Můžete se například rozhodnout, že je přijatelné, pokud aktualizace vašeho fakturačního systému selže, protože prodejní tým zákazníka přidá ručně.
- Opusťte pracovní postup a aktivujte ruční proces obnovení.
Musíte také zvážit, jak se uživatelské prostředí podobá pro každý scénář selhání.
Správa sdílených komponent
Řídicí rovina musí vědět o všech komponentách, které nejsou vyhrazené pro konkrétní tenanty, ale jsou sdílené. Některé komponenty můžou být sdíleny mezi všemi tenanty v rámci razítka. Ostatní komponenty můžou být sdíleny mezi všemi razítky v oblasti nebo dokonce sdíleny globálně napříč všemi oblastmi a razítky. Pokaždé, když je tenant onboardovaný, překonfigurovaný nebo vypnutý, musí vaše řídicí rovina vědět, co dělat s těmito sdílenými komponentami.
Některé sdílené komponenty může být potřeba překonfigurovat při každém přidání nebo odebrání tenanta. Předpokládejme například, že máte globálně sdílený profil služby Azure Front Door. Pokud přidáte tenanta s vlastním názvem domény, možná bude potřeba aktualizovat konfiguraci profilu tak, aby směrovat požadavky na tento název domény do správné aplikace. Podobně když dojde k vyřazení tenanta, může být potřeba odebrat vlastní název domény z profilu služby Azure Front Door, aby nedocházelo k útokům na převzetí subdomény.
Sdílené komponenty můžou mít složitá pravidla škálování, která vaše řídicí rovina musí dodržovat. Předpokládejme například, že při nasazování databází tenantů postupujete podle postupu při balení přihrádek . Když je nový tenant nasazený, přidáte pro něj novou databázi Azure SQL a pak ji přiřadíte elastickému fondu Azure SQL. Možná jste zjistili, že potřebujete zvýšit prostředky přidělené vašemu fondu pro každou desátou databázi, kterou přidáte. Když přidáte nebo odeberete tenanta, vaše řídicí rovina musí znovu vyhodnotit konfiguraci fondu a rozhodnout se, jestli chcete změnit prostředky fondu. Když dosáhnete maximálního počtu databází, které můžete přiřadit k jednomu elastickému fondu, musíte vytvořit nový fond a začít ho používat pro nové databáze tenantů. Vaše řídicí rovina musí převzít odpovědnost za správu každé z těchto sdílených komponent, škálování a změnu jejich konfigurace, kdykoli se něco změní.
Když řídicí rovina spravuje sdílené komponenty, je důležité vědět o podmínkách časování, ke kterým může dojít, když dojde k více operacím paralelně. Pokud například při onboardingu nového tenanta současně přepnete jiného tenanta, musíte zajistit, aby byl konečný koncový stav konzistentní a splňoval vaše požadavky na škálování.
Použití více řídicích rovin
V komplexním prostředí možná budete muset použít více řídicích rovin, z nichž každá má různé oblasti odpovědnosti. Řada víceklientských řešení se řídí vzorem razítka nasazení a tenanty horizontálních oddílů napříč několika kolky. Při použití tohoto vzoru můžete vytvořit samostatné řídicí roviny pro globální a kolkové zodpovědnosti.
Tip
Koordinace napříč několika řídicími rovinami je složitá, proto se pokuste minimalizovat počet řídicích rovin, které vytváříte. Většina řešení potřebuje jenom jednu řídicí rovinu.
Globální řídicí roviny
Globální řídicí rovina obvykle zodpovídá za celkovou správu a sledování tenantů. Globální řídicí rovina může mít následující odpovědnosti:
- Umístění tenanta. Globální řídicí rovina určuje, které razítko tenanta má použít. Toto rozhodnutí může být založeno na faktorech, jako je oblast tenanta, využití kapacity každého razítka a požadavky na úroveň služeb tenanta.
- Onboarding tenanta a správa životního cyklu Mezi tyto odpovědnosti patří sledování všech tenantů napříč všemi nasazeními.
Řídicí roviny razítka
Řídicí rovina kolku se nasadí do každého razítka nasazení a zodpovídá za tenanty a prostředky přidělené danému kolku. Řídicí rovina kolku může mít tyto odpovědnosti:
- Vytváření a správa prostředků specifických pro tenanty v rámci razítka, jako jsou databáze a kontejnery úložiště
- Správa sdílených prostředků, včetně monitorování spotřeby sdílených prostředků a nasazení nových instancí, když se blíží maximální kapacitě
- Provádění operací údržby v rámci razítka, jako je správa indexů databáze a operace čištění
Řídicí rovina každého kolku koordinuje s globální řídicí rovinou. Předpokládejme například, že se zaregistruje nový tenant. Globální řídicí rovina je zpočátku zodpovědná za výběr razítka pro prostředky tenanta. Pak globální řídicí rovina vyzve řídicí rovinu razítka k vytvoření potřebných prostředků pro tenanta.
Následující diagram znázorňuje příklad, jak mohou tyto dvě řídicí roviny existovat v jednom systému:
Řídicí roviny tenanta
Tenanti můžou ke správě vlastních logických nebo fyzických prostředků použít řídicí rovinu na úrovni tenanta. Řídicí rovina tenanta může mít následující odpovědnosti:
- Správa konfigurace specifické pro tenanta, jako je přístup uživatelů
- Operace údržby iniciované tenantem, jako je zálohování dat nebo stažení předchozí zálohy
- Správa aktualizací, pokud klientům povolíte řídit vlastní aktualizace svých aplikací
Následující diagram znázorňuje složitý systém, který má globální řídicí rovinu, řídicí roviny razítka a řídicí rovinu pro každého tenanta:
Přispěvatelé
Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.
Hlavní autor:
- John Downs | Hlavní zákaznický inženýr, FastTrack pro Azure
Další přispěvatelé:
- Mick Alberts | Technický spisovatel
- Bohdan Cherchyk | Vedoucí zákaznický inženýr, FastTrack pro Azure
- Landon Pierce | Customer Engineer, FastTrack pro Azure
- Daniel Scott-Raynsford | Partner Technology Strategist
- Vladimirskij Vladimirskij | Hlavní zákaznický inženýr, FastTrack pro Azure
Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.