Přístupy k architektuře pro nasazení a konfiguraci víceklientských řešení

Bez ohledu na architekturu a komponenty, které používáte k jeho implementaci, je potřeba nasadit a nakonfigurovat komponenty vašeho řešení. V prostředí s více tenanty je důležité zvážit, jak nasadíte prostředky Azure, zejména když nasadíte vyhrazené prostředky pro každého tenanta nebo když změníte konfiguraci prostředků na základě počtu tenantů ve vašem systému. Na této stránce poskytujeme architektům řešení pokyny k nasazení víceklientských řešení a ukážeme si některé přístupy, které je potřeba zvážit při plánování strategie nasazení.

Klíčové aspekty a požadavky

Před plánováním strategie nasazení je důležité mít jasnou představu o vašich požadavcích. Mezi konkrétní aspekty patří:

• Očekávané škálování: Očekáváte, že budete podporovat malý počet tenantů (například pět nebo méně), nebo budete růst na velký počet tenantů?
• Automatizované nebo podporované onboarding: Když je tenant připravený k onboardingu, bude moct proces dokončit sami pomocí automatizovaného postupu? Nebo noví tenanti iniciují žádost a po přijetí žádosti je ručně nasadíte? Vyžaduje se od vašeho týmu ruční schválení, například aby se zabránilo zneužití vaší služby?
• Čas zřizování: Když je tenant připravený k onboardingu, jak rychle se musí proces onboardingu dokončit? Pokud nemáte jasnou odpověď, zvažte, jestli se má měřit v sekundách, minutách, hodinách nebo dnech.
• Azure Marketplace: Plánujete k zahájení nasazení použít Azure Marketplace? Pokud to uděláte, musíte splnit požadavky pro přidání nových tenantů.

Měli byste také zvážit kroky onboardingu a zřizování, automatizaci a zodpovědnost za správu prostředků.

Postup onboardingu a zřizování

Vezměte v úvahu vše, co potřebujete udělat při onboardingu tenanta, a dokumentujte tento seznam a pracovní postup, i když se provádí ručně. Pracovní postup onboardingu obvykle zahrnuje následující:

• Přijetí obchodních smluv.
• Kolekce informací, které potřebujete ke konfiguraci systému pro nového tenanta.
• Postup ručního schvalování, například k zabránění podvodům nebo zneužití vaší služby.
• Zřizování prostředků v Azure
• Vytváření nebo konfigurace názvů domén
• Proveďte úlohy konfigurace po nasazení, například vytvoření prvního uživatelského účtu tenanta a bezpečné přenosy přihlašovacích údajů do tenanta.
• Změny ruční konfigurace, například změny záznamů DNS.

Jasně zdokumentujte pracovní postup, který je nutný k připojení nového tenanta.

Kromě toho zvažte konkrétní prostředky Azure, které potřebujete zřídit pro tenanta. I když pro každého tenanta nezřídíte vyhrazené prostředky, zvažte, jestli při onboardingu nového tenanta někdy potřebujete nasadit prostředky. K tomu může dojít v případě, že tenant vyžaduje, aby byla data uložená v konkrétní oblasti nebo když přistupujete k limitům razítka nebo komponenty ve vašem řešení a potřebujete vytvořit další instanci pro další dávku tenantů.

Zvažte, jestli proces onboardingu pravděpodobně nenaruší jiné tenanty, zejména pro ty, kteří sdílejí stejnou infrastrukturu. Pokud například potřebujete upravit sdílené databáze, může tento proces způsobit dopad na výkon, který by si ostatní tenanti mohli všimnout? Zvažte, jestli se těmto účinkům můžete vyhnout, nebo je zmírnit provedením procesu připojování mimo normální provozní dobu.

Automation

Automatizovaná nasazení jsou vždy vhodná pro řešení hostovaná v cloudu. Při práci s víceklientovými řešeními je automatizace nasazení ještě důležitější z následujících důvodů:

• Škálování: Procesy ručního nasazení se s rostoucím počtem obyvatel tenanta stávají stále složitějšími a časově náročnými. S rostoucím počtem tenantů je jednodušší škálovat automatizovaný přístup k nasazení.
• Opakovatelné: Ve víceklientských prostředích používejte konzistentní proces pro nasazení napříč všemi tenanty. Ruční procesy představují šanci na chybu nebo kroky prováděné u některých tenantů a ne pro jiné. Tyto ruční procesy opustí vaše prostředí v nekonzistentním stavu, což vašemu týmu znesnadňuje správu řešení.
• Dopad výpadků: Ruční nasazení jsou výrazně riziknější a náchylnější k výpadkům než automatizovaná nasazení. V prostředí s více tenanty může být dopad výpadku celého systému (kvůli chybě nasazení) vysoký, protože může to mít vliv na každého tenanta.

Když nasadíte do víceklientského prostředí, měli byste použít kanály nasazení a používat technologie infrastruktury jako kódu (IaC), jako jsou Bicep, šablony JSON ARM, Terraform nebo sady SDK Azure.

Pokud plánujete nabízet řešení prostřednictvím Azure Marketplace, měli byste poskytnout plně automatizovaný proces onboardingu pro nové tenanty. Tento proces je popsaný v dokumentaci k rozhraním API pro plnění SaaS.

Maximální kapacita prostředků

Pokud prostředky tenanta nasazujete na sdílené prostředky prostřednictvím kódu programu, zvažte limit kapacity pro každý prostředek. Při přístupu k danému limitu možná budete muset vytvořit další instanci prostředku, která bude podporovat další škálování. Zvažte omezení jednotlivých prostředků, které nasadíte, a podmínky, které vás aktivují k nasazení jiné instance.

Předpokládejme například, že vaše řešení zahrnuje logický server Azure SQL a vaše řešení zřídí vyhrazenou databázi na tomto serveru pro každého tenanta. Jeden logický server má omezení, která zahrnují maximální počet databází, které logický server podporuje. Při přístupu k těmto limitům možná budete muset zřídit nové servery, abyste mohli pokračovat v onboardingu tenantů. Zvažte, jestli tento proces automatizujete nebo ručně monitorujete růst.

Odpovědnost za správu prostředků

V některých víceklientských řešeních nasadíte vyhrazené prostředky Azure pro každého tenanta, například databázi pro každého tenanta. Nebo se můžete rozhodnout o nastaveném počtu tenantů, kteří se mají nacházet v jedné instanci prostředku, takže počet tenantů, které jste nasadili do Azure, určuje sadu prostředků, které nasadíte do Azure. V jiných řešeních nasadíte jednu sadu sdílených prostředků a potom znovu nakonfigurujete prostředky při onboardingu nových tenantů.

Každý z těchto modelů vyžaduje nasazení a správu prostředků různými způsoby a musíte zvážit, jak nasadíte a budete spravovat životní cyklus prostředků, které zřídíte. Dva běžné přístupy jsou následující:

• Pokud chcete s tenanty zacházet jako s konfigurací prostředků, které nasazujete, a ke konfiguraci těchto prostředků použijte kanály nasazení.
• Pokud chcete s tenanty zacházet jako s daty a mít zřízenou řídicí rovinu a konfigurovat infrastrukturu pro vaše tenanty.

Další diskuzi o těchto přístupech najdete níže.

Testování

Naplánujte důkladné otestování řešení během a po každém nasazení. Pomocí automatizovaného testování můžete ověřit funkční a nefunkční chování vašeho řešení. Ujistěte se, že model izolace tenanta otestujete, a zvažte použití nástrojů, jako je Azure Chaos Studio , a záměrně zavést chyby simulující výpadky reálného světa a ověřit, že vaše řešení funguje i v případě, že komponenta není dostupná nebo nefunguje správně.

Přístupy a vzory, které je potřeba zvážit

Několik vzorů návrhu z Centra architektury Azure a širší komunity má význam pro nasazení a konfiguraci víceklientských řešení.

Model razítka nasazení

Model Razítka nasazení zahrnuje nasazení vyhrazené infrastruktury pro tenanta nebo skupinu tenantů. Jedno razítko může obsahovat více tenantů nebo může být vyhrazené pro jednoho tenanta. Můžete se rozhodnout nasadit jedno razítko nebo můžete koordinovat nasazení napříč několika kolky. Pokud nasadíte vyhrazené razítka pro každého tenanta, můžete také zvážit nasazení celých kolků prostřednictvím kódu programu.

Okruhy nasazení

Okruhy nasazení umožňují zavést aktualizace různých skupin infrastruktury v různých časech. Tento přístup se běžně používá se vzorem Razítka nasazení a skupiny kolek se dají přiřadit k odlišným okruhům na základě předvoleb tenanta, typů úloh a dalších aspektů. Další informace najdete v tématu Okruhy nasazení.

Hlavní příznaky

Příznaky funkcí umožňují postupně zveřejnit nové funkce nebo verze vašeho řešení pro různé tenanty, zatímco udržujete jediný základ kódu. Zvažte použití konfigurace Aplikace Azure ke správě příznaků funkcí. Další informace najdete v tématu Příznaky funkcí.

Někdy potřebujete selektivně povolit konkrétní funkce pro určité zákazníky. Můžete mít například různé cenové úrovně , které umožňují přístup k určitým možnostem. Příznaky funkcí nejsou obvykle správnou volbou pro tyto scénáře. Místo toho zvažte vytvoření procesu, který bude sledovat a vynucovat nároky na licence, které má každý zákazník.

Antipatterny, aby se zabránilo

Při nasazování a konfiguraci víceklientských řešení je důležité se vyhnout situacím, které brání škálování. Patří mezi ně následující:

• Ruční nasazení a testování Jak je popsáno výše, procesy ručního nasazení přidávají riziko a zpomalují vaši schopnost nasazení. Zvažte použití kanálů pro automatizovaná nasazení, programové vytváření prostředků z kódu vašeho řešení nebo kombinace obou.
• Specializovaná přizpůsobení pro tenanty Vyhněte se nasazování funkcí nebo konfigurace, které platí jenom pro jednoho tenanta. Tento přístup zvyšuje složitost vašich nasazení a procesů testování. Místo toho použijte stejné typy prostředků a základ kódu pro každého tenanta a použijte strategie, jako jsou příznaky funkcí pro dočasné změny nebo pro funkce, které se postupně nasadí, nebo použijte různé cenové úrovně s oprávněními k selektivnímu povolení funkcí pro tenanty, kteří je vyžadují. Používejte konzistentní a automatizovaný proces nasazení, a to i pro tenanty, kteří mají izolované nebo vyhrazené prostředky.

Seznamy tenantů jako konfigurace nebo data

Při nasazování prostředků ve víceklientských řešeních můžete zvážit následující dva přístupy:

• K nasazení všech prostředků použijte automatizovaný kanál nasazení. Při přidání nových tenantů překonfigurujte kanál tak, aby zřídil prostředky pro každého tenanta.
• Pomocí automatizovaného kanálu nasazení nasaďte sdílené prostředky, které nezávisí na počtu tenantů. Pro prostředky nasazené pro každého tenanta je vytvořte v rámci vaší aplikace.

Při zvažování těchto dvou přístupů byste měli rozlišovat mezi zacházením se seznamem tenantů jako s konfigurací nebo daty. Tento rozdíl je důležitý také v případě, že uvažujete o tom, jak vytvořit řídicí rovinu pro váš systém.

Seznam tenantů jako konfigurace

Když se seznamem tenantů považujete za konfiguraci, nasadíte všechny prostředky z centralizovaného kanálu nasazení. Při onboardingu nových tenantů překonfigurujete kanál nebo jeho parametry. Rekonfigurace se obvykle provede ručními změnami, jak je znázorněno v následujícím diagramu.

Proces nasazení nového tenanta může vypadat nějak takto:

1. Aktualizujte seznam tenantů. K tomu obvykle dochází ručně konfigurací samotného kanálu nebo úpravou souboru parametrů, který je součástí konfigurace kanálu.
2. Aktivujte spuštění kanálu.
3. Kanál znovu nasadí celou sadu prostředků Azure, včetně všech nových prostředků specifických pro tenanta.

Tento přístup obvykle funguje dobře pro malý počet tenantů a pro architektury, ve kterých jsou sdílené všechny prostředky. Je to jednoduchý přístup, protože všechny prostředky Azure je možné nasadit a nakonfigurovat pomocí jednoho procesu.

Když ale přiblížíte větší počet tenantů, řekněme 5 až 10 nebo více, bude obtížné kanál při přidávání tenantů překonfigurovat. Čas potřebný ke spuštění kanálu nasazení se často také výrazně zvyšuje. Tento přístup také nepodporuje samoobslužné vytváření tenanta a předstih před onboardingem tenanta může být delší, protože je potřeba aktivovat spuštění kanálu.

Seznam tenantů jako data

Když se seznamem tenantů zacházíte jako s daty, stále nasazujete sdílené komponenty pomocí kanálu. Pro prostředky a nastavení konfigurace, které je potřeba nasadit pro každého tenanta, ale imperativní nasazení nebo konfiguraci prostředků. Řídicí rovina může například použít sady Azure SDK k vytvoření konkrétního prostředku nebo k zahájení nasazení parametrizované šablony.

Proces nasazení nového tenanta může být podobný následujícímu a asynchronně:

1. Požádejte o onboarding tenanta, například zahájením požadavku rozhraní API na řídicí rovinu vašeho systému.
2. Komponenta pracovního postupu obdrží žádost o vytvoření a orchestruje zbývající kroky.
3. Pracovní postup zahájí nasazení prostředků specifických pro tenanta do Azure. Toho lze dosáhnout pomocí imperativního programovacího modelu, například pomocí sad SDK Azure, nebo imperativním spuštěním nasazení šablony Bicep nebo Terraformu.
4. Po dokončení nasazení pracovní postup uloží podrobnosti nového tenanta do centrálního katalogu tenantů. Data uložená pro každého tenanta můžou zahrnovat ID tenanta a ID prostředků pro všechny prostředky specifické pro tenanta, které pracovní postup vytvořil.

Tímto způsobem můžete zřídit prostředky pro nové tenanty bez opětovného nasazení celého řešení. Čas potřebný ke zřizování nových prostředků pro každého tenanta bude pravděpodobně kratší, protože je potřeba nasadit jenom tyto prostředky.

Tento přístup je ale často časově náročnější na sestavení a úsilí, které strávíte, musí být odůvodněné počtem tenantů nebo časovými rámci zřizování, které potřebujete splnit.

Další informace o tomto přístupu najdete v tématu Důležité informace o víceklientských řídicích rovinách.

Příklad

Společnost Contoso pro své zákazníky provozuje víceklientských řešení. V současné době mají šest tenantů a během následujících 18 měsíců očekává růst na 300 tenantů. Společnost Contoso se řídí víceklientovou aplikací s vyhrazenými databázemi pro každý přístup tenanta . Nasadili jednu sadu prostředků služby App Service a logický server Azure SQL, který se sdílí mezi všemi tenanty, a nasadí vyhrazenou databázi Azure SQL pro každého tenanta, jak je znázorněno v následujícím diagramu.

Společnost Contoso nasadí prostředky Azure pomocí Bicep.

Možnost 1 – Použití kanálů nasazení pro všechno

Společnost Contoso může zvážit nasazení všech svých prostředků pomocí kanálu nasazení. Jejich kanál nasadí soubor Bicep, který zahrnuje všechny prostředky Azure, včetně databází Azure SQL pro každého tenanta. Soubor parametrů definuje seznam tenantů a soubor Bicep používá smyčku prostředků k nasazení databáze pro každého z uvedených tenantů, jak je znázorněno v následujícím diagramu.

Pokud společnost Contoso tento model dodržuje, musí aktualizovat soubor parametrů jako součást onboardingu nového tenanta. Pak musí znovu spustit svůj kanál. Musí také ručně sledovat, jestli se blíží jakýmkoli omezením, například pokud rostou neočekávaně vysokou rychlostí, a přistupovat k maximálnímu počtu databází podporovaných na jednom logickém serveru Azure SQL.

Možnost 2 – Použití kombinace kanálů nasazení a imperativního vytváření prostředků

Případně může společnost Contoso zvážit oddělení odpovědnosti za nasazení Azure.

Společnost Contoso používá soubor Bicep, který definuje sdílené prostředky, které by se měly nasadit. Sdílené prostředky podporují všechny své tenanty a zahrnují mapovou databázi tenanta, jak je znázorněno v následujícím diagramu.

Tým Společnosti Contoso pak sestaví řídicí rovinu, která zahrnuje rozhraní API pro onboarding tenanta. Jakmile prodejní tým dokončí prodej novému zákazníkovi, Microsoft Dynamics aktivuje rozhraní API, aby zahájil proces onboardingu. Společnost Contoso také poskytuje samoobslužné webové rozhraní pro zákazníky, které můžou používat a které také aktivuje rozhraní API.

Rozhraní API asynchronně spustí pracovní postup, který nasadí nové tenanty. Pracovní postup zahájí nasazení nové databáze Azure SQL, kterou může provést jeden z následujících přístupů:

• Pomocí sady Azure SDK zahajte nasazení druhého souboru Bicep, který definuje databázi Azure SQL.
• Pomocí sady Azure SDK můžete imperativním způsobem vytvořit databázi Azure SQL pomocí knihovny pro správu.

Po nasazení databáze pracovní postup přidá tenanta do databáze seznamu tenantů, jak je znázorněno v následujícím diagramu.

Probíhající aktualizace schématu databáze jsou inicializovány jejich aplikační vrstvou.

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í softwarový inženýr

Další přispěvatelé:

• Bohdan Cherchyk | Vedoucí zákaznický inženýr, FastTrack pro Azure
• Vladimirskij Vladimirskij | Hlavní zákaznický inženýr, FastTrack pro Azure

Pokud chcete zobrazit neveřejné profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

• Projděte si důležité informace o aktualizaci víceklientských řešení.
• Zvažte přístupy architektury pro ukládání a data.
• Zvažte použití Azure Resource Manageru v víceklientských řešeních.