Upravit

Sdílet prostřednictvím


Organizace prostředků Azure ve víceklientských řešeních

Azure
Microsoft Entra ID

Azure nabízí řadu možností pro uspořádání prostředků. Ve víceklientských řešeních je potřeba vzít v úvahu konkrétní kompromisy, když plánujete strategii organizace prostředků. V tomto článku se podíváme na dva základní prvky uspořádání prostředků Azure: izolace tenanta a horizontální navýšení kapacity napříč několika prostředky. Popisujeme také, jak pracovat s limity a kvótami prostředků Azure a jak škálovat řešení nad rámec těchto limitů.

Klíčové aspekty a požadavky

Požadavky na izolaci tenanta

Když nasadíte víceklientské řešení v Azure, musíte se rozhodnout, jestli vyhrazujete prostředky pro každého tenanta nebo sdílíte prostředky mezi více tenanty. V rámci víceklientských přístupů a pokynů specifických pro služby této série popisujeme možnosti a kompromisy pro mnoho kategorií zdrojů. Obecně platí, že existuje celá řada možností izolace tenanta. Projděte si modely tenantů a zvažte víceklientské řešení , kde najdete další pokyny k rozhodování o modelu izolace.

Měřítko

Většina prostředků Azure a také skupiny prostředků a předplatná ukládají omezení, která můžou ovlivnit vaši schopnost škálování. Možná budete muset zvážit horizontální navýšení kapacity nebo balení přihrádek , abyste vyhověli plánovanému počtu tenantů nebo plánovanému zatížení systému.

Pokud víte s jistotou, že nebudete růst na velký počet tenantů ani na vysoké zatížení, nepřetěžujte plán horizontálního navýšení kapacity. Pokud ale plánujete, aby se vaše řešení rozrůstal, pečlivě zvažte plán horizontálního navýšení kapacity. Podle pokynů v tomto článku se ujistěte, že architektujete škálování.

Pokud máte automatizovaný proces nasazení a potřebujete škálovat mezi prostředky, určete, jak nasadíte a přiřadíte tenanty napříč několika instancemi prostředků. Jak například zjistíte, že se blížíte počtu tenantů, které je možné přiřadit ke konkrétnímu prostředku? Plánujete nasadit nové prostředky včas , když je potřebujete? Nebo předem nasadíte fond prostředků, abyste je mohli použít, když je potřebujete?

Tip

V počátečních fázích návrhu a vývoje se nemusíte rozhodnout implementovat automatizovaný proces horizontálního navýšení kapacity. Stále byste měli zvážit a jasně zdokumentovat procesy potřebné ke škálování při růstu.

Je také důležité, abyste se vyhnuli předpokladům v kódu a konfiguraci, což může omezit vaši schopnost škálování. Můžete například potřebovat horizontální navýšení kapacity na více účtů úložiště. Ujistěte se, že vaše aplikační vrstva nepředpokládá, že se připojuje jenom k jednomu účtu úložiště pro všechny tenanty.

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

Izolace tenanta

Prostředky Azure se nasazují a spravují prostřednictvím hierarchie. Většina prostředků se nasazuje do skupin prostředků, které jsou obsaženy v předplatných. Skupiny pro správu logicky seskupují předplatná. Všechny tyto hierarchické vrstvy jsou přidružené k tenantovi Microsoft Entra.

Když určíte, jak nasadit prostředky pro každého tenanta, můžete izolovat na různých úrovních v hierarchii. Každá možnost je platná pro určité typy víceklientských řešení a přináší výhody a kompromisy. Je také běžné kombinovat přístupy pomocí různých modelů izolace pro různé komponenty řešení.

Izolace ve sdíleném prostředku

Můžete se rozhodnout sdílet prostředek Azure mezi více tenanty a spouštět všechny úlohy v jedné instanci. Projděte si pokyny pro služby Azure, které používáte, abyste porozuměli konkrétním aspektům nebo možnostem, které můžou být důležité.

Při spouštění jednotlivých instancí prostředku je potřeba vzít v úvahu všechny limity služeb, limity předplatného nebo kvóty, které se můžou dosáhnout při škálování. Existuje například maximální počet uzlů podporovaných clusterem Azure Kubernetes Service (AKS) a maximální limit počtu transakcí za sekundu podporovaných účtem úložiště. Při přístupu k těmto limitům zvažte škálování na více sdílených prostředků .

Musíte také zajistit, aby kód aplikace plně věděl o víceklientské úrovni a že omezuje přístup k datům pro konkrétního tenanta.

Předpokládejme, že Contoso vytváří víceklientské aplikace SaaS, která zahrnuje webovou aplikaci, databázi a účet úložiště. Můžou se rozhodnout nasadit sdílené prostředky a tyto prostředky budou používat k poskytování služeb všem svým zákazníkům. V následujícím diagramu sdílí jednu sadu prostředků všichni zákazníci.

Diagram that shows a single set of resources that are shared by all the customers.

Oddělení prostředků ve skupině prostředků

Pro každého tenanta můžete také nasadit vyhrazené prostředky. Můžete nasadit celou kopii vašeho řešení pro jednoho tenanta. Nebo můžete sdílet některé komponenty mezi tenanty a nasadit jiné komponenty, které jsou vyhrazené pro konkrétního tenanta.

Ke správě prostředků se stejným životním cyklem doporučujeme používat skupiny prostředků. V některých víceklientských systémech je vhodné nasadit prostředky pro více tenantů do jedné skupiny prostředků nebo sady skupin prostředků.

Je důležité zvážit, jak nasazovat a spravovat tyto prostředky, včetně toho, jestli je nasazení prostředků specifických pro tenanta inicializováno kanálem nasazení nebo vaší aplikací. Musíte také určit, jak budete jasně identifikovat konkrétní prostředky související s konkrétními tenanty. Zvažte použití jasné strategie zásad vytváření názvů, značek prostředků nebo databáze katalogu tenantů.

Je vhodné použít samostatné skupiny prostředků pro prostředky, které sdílíte mezi více tenanty, a prostředky, které nasadíte pro jednotlivé tenanty. U některých prostředků ale Azure omezuje počet prostředků jednoho typu, které je možné nasadit do skupiny prostředků. Tento limit znamená, že při zvětšování možná budete muset škálovat napříč několika skupinami prostředků.

Předpokládejme, že contoso má tři zákazníky: Adventure Works, Fabrikam a Tailwind. Můžou se rozhodnout sdílet webovou aplikaci a účet úložiště mezi třemi zákazníky a pak nasadit jednotlivé databáze pro každého tenanta. V následujícím diagramu je každému zákazníkovi přiřazena skupina prostředků, která obsahuje sdílené prostředky, a skupinu prostředků, která obsahuje databázi.

Diagram showing a resource group that contains shared resources, and another resource group that contains a database for each customer.

Oddělení skupin prostředků v předplatném

Při nasazování sady prostředků pro každého tenanta zvažte použití vyhrazených skupin prostředků specifických pro tenanta. Pokud například postupujete podle vzoru Razítka nasazení, každé razítko by se mělo nasadit do vlastní skupiny prostředků. Můžete zvážit nasazení několika skupin prostředků specifických pro tenanta do sdíleného předplatného Azure, které vám umožní snadno konfigurovat zásady a pravidla řízení přístupu.

Můžete se rozhodnout vytvořit sadu skupin prostředků pro každého tenanta a také sdílené skupiny prostředků pro všechny sdílené prostředky.

Když nasadíte skupiny prostředků specifické pro tenanta do sdílených předplatných, mějte na paměti maximální počet skupin prostředků v každém předplatném a další limity na úrovni předplatného, které platí pro prostředky, které nasazujete. Při přístupu k těmto limitům možná budete muset škálovat napříč několika předplatnými.

V našem příkladu se společnost Contoso může rozhodnout nasadit razítko pro každého zákazníka a umístit razítka do vyhrazených skupin prostředků v rámci jednoho předplatného. V následujícím diagramu se pro každého zákazníka vytvoří předplatné, které obsahuje tři skupiny prostředků.

Diagram showing a subscription that contains three resource groups, each of which is a complete set of resources for a specific customer.

Samostatná předplatná

Nasazením předplatných specifických pro tenanta můžete zcela izolovat prostředky specifické pro tenanty. Vzhledem k tomu, že většina kvót a omezení platí v rámci předplatného, zajišťuje použití samostatného předplatného na tenanta, že každý tenant plně využívá všechny příslušné kvóty. U některých typů fakturačních účtů Azure můžete programově vytvářet předplatná. Můžete také použít rezervace Azure a plán úspory Azure pro výpočetní prostředky napříč předplatnými.

Mějte na paměti počet předplatných, která můžete vytvořit. Maximální počet předplatných se může lišit v závislosti na vašem komerčním vztahu s Microsoftem nebo partnerem Microsoftu, například pokud máte smlouvu Enterprise.

Při práci s velkým počtem předplatných ale může být obtížnější požádat o navýšení kvóty. Rozhraní API pro kvóty poskytuje programové rozhraní pro některé typy prostředků. U mnoha typů prostředků je však potřeba požádat o navýšení kvóty zahájením případu podpory. Při práci s mnoha předplatnými může být také náročné pracovat s podpora Azure smlouvami a případy podpory.

Zvažte seskupení předplatných specifických pro tenanta do hierarchie skupin pro správu, abyste umožnili snadnou správu pravidel řízení přístupu a zásad.

Předpokládejme například, že se Společnost Contoso rozhodla vytvořit samostatná předplatná Azure pro každého ze tří zákazníků, jak je znázorněno v následujícím diagramu. Každé předplatné obsahuje skupinu prostředků s kompletní sadou prostředků pro daného zákazníka.

Diagram showing three customer-specific subscriptions. Each subscription contains a resource group, with the complete set of resources for that customer.

Každé předplatné obsahuje skupinu prostředků s kompletní sadou prostředků pro daného zákazníka.

Ke zjednodušení správy předplatných používají skupinu pro správu. Zahrnutím produkčního prostředí do názvu skupiny pro správu mohou jasně odlišit všechny produkční tenanty od neprodukčního nebo testovacího tenanta. Neprodukční tenanti by měli různá pravidla a zásady řízení přístupu Azure.

Všechna jejich předplatná jsou přidružená k jednomu tenantovi Microsoft Entra. Použití jednoho tenanta Microsoft Entra znamená, že identity týmu Contoso, včetně uživatelů a instančních objektů, je možné použít v rámci celého jejich majetku Azure.

Oddělení předplatných v samostatných tenantech Microsoft Entra

Můžete také ručně vytvořit jednotlivé tenanty Microsoft Entra pro každého z vašich tenantů nebo nasadit prostředky do předplatných v rámci tenantů Microsoft Entra vašich zákazníků. Práce s několika tenanty Microsoft Entra ale ztěžuje ověřování, správu přiřazení rolí, použití globálních zásad a provádění mnoha dalších operací správy.

Upozorňující

Doporučujeme, abyste pro většinu víceklientských řešení vytvořili více tenantů Microsoft Entra. Práce napříč tenanty Microsoft Entra přináší větší složitost a snižuje schopnost škálovat a spravovat prostředky. Tento přístup obvykle používají jenom poskytovatelé spravovaných služeb (MSP), kteří provozují prostředí Azure jménem svých zákazníků.

Jeden tenant Microsoft Entra může používat více samostatných předplatných a prostředků Azure. Než se pustíte do nasazení více tenantů Microsoft Entra, zvažte, jestli existují další přístupy, které by mohly dosáhnout vašich účelů.

V situacích, kdy potřebujete spravovat prostředky Azure v předplatných, která jsou svázaná s několika tenanty Microsoft Entra, zvažte použití Azure Lighthouse , které vám pomůže spravovat prostředky v rámci vašich tenantů Microsoft Entra.

Společnost Contoso může například vytvořit samostatné tenanty Microsoft Entra a samostatná předplatná Azure pro každého zákazníka, jak je znázorněno na následujícím diagramu.

Diagram showing a Microsoft Entra tenant for each of Contoso's tenants, which contains a subscription and the resources required. Azure Lighthouse is connected to each Microsoft Entra tenant.

Tenant Microsoft Entra je nakonfigurovaný pro každého tenanta Společnosti Contoso, který obsahuje předplatné a požadované prostředky. Azure Lighthouse je připojený ke každému tenantovi Microsoft Entra.

Balení přihrádek

Bez ohledu na model izolace prostředků je důležité zvážit, kdy a jak bude vaše řešení škálovat na více prostředků. Možná budete muset škálovat prostředky, protože se zvyšuje zatížení systému nebo roste počet tenantů. Zvažte balení přihrádek a nasaďte optimální počet prostředků pro vaše požadavky.

Tip

V mnoha řešeních je jednodušší škálovat celou sadu prostředků společně místo škálování prostředků jednotlivě. Zvažte použití vzoru razítka nasazení.

Omezení prostředků

Prostředky Azure mají limity a kvóty , které je potřeba při plánování řešení zvážit. Prostředky můžou například podporovat maximální počet souběžných požadavků nebo nastavení konfigurace specifické pro tenanta.

Způsob, jakým konfigurujete a používáte jednotlivé prostředky, má vliv také na škálovatelnost daného prostředku. Například vzhledem k určitému množství výpočetních prostředků může vaše aplikace úspěšně reagovat na definovaný počet transakcí za sekundu. Kromě tohoto bodu možná budete muset vertikálně na více instancí na více instancí. Testování výkonu vám pomůže identifikovat bod, ve kterém už vaše prostředky nesplňují vaše požadavky.

Poznámka:

Princip škálování na více prostředků platí i v případě, že pracujete se službami, které podporují více instancí.

Služba Aplikace Azure například podporuje horizontální navýšení kapacity počtu instancí vašeho plánu, ale existují omezení, jak daleko můžete škálovat jeden plán. Ve vysoce škálované víceklientských aplikacích můžete tyto limity překročit a budete muset nasadit další prostředky služby App Service, aby odpovídaly vašemu růstu.

Když sdílíte některé prostředky mezi tenanty, měli byste nejprve určit počet tenantů, které prostředek podporuje, když je nakonfigurovaný podle vašich požadavků. Pak nasaďte tolik prostředků, kolik potřebujete k poskytování celkového počtu tenantů.

Předpokládejme například, že nasadíte bránu Aplikace Azure jako součást řešení SaaS s více tenanty. Zkontrolujete návrh aplikace, otestujete výkon služby Application Gateway při zatížení a zkontrolujete jeho konfiguraci. Pak zjistíte, že jeden prostředek služby Application Gateway je možné sdílet mezi 100 zákazníky. Podle plánu růstu vaší organizace očekáváte, že v prvním roce nasadíte 150 zákazníků, takže je potřeba naplánovat nasazení několika aplikačních bran pro zajištění očekávaného zatížení.

Diagram showing two application gateways. The first gateway is dedicated to customers 1 through 100, and the second is dedicated to customers 101 through 200.

V předchozím diagramu jsou dvě aplikační brány. První brána je vyhrazená zákazníkům 1 až 100 a druhá je vyhrazená pro zákazníky 101 až 200.

Omezení skupin prostředků a předplatného

Bez ohledu na to, jestli pracujete se sdílenými nebo vyhrazenými prostředky, je důležité počítat s limity. Azure omezuje počet prostředků, které je možné nasadit do skupiny prostředků a do předplatného Azure. Při přístupu k těmto limitům je potřeba naplánovat škálování napříč několika skupinami prostředků nebo předplatnými.

Předpokládejme například, že pro každého zákazníka nasadíte vyhrazenou aplikační bránu do sdílené skupiny prostředků. U některých prostředků podpora Azure nasazení až 800 prostředků stejného typu do jedné skupiny prostředků. Takže když dosáhnete tohoto limitu, musíte nasadit všechny nové aplikační brány do jiné skupiny prostředků. V následujícím diagramu jsou dvě skupiny prostředků. Každá skupina prostředků obsahuje 800 aplikačních bran.

Diagram that shows two resource groups. Each resource group contains 800 application gateways.

Tenanti sady Bin Pack napříč skupinami prostředků a předplatnými

Koncept balení přihrádek můžete použít také napříč prostředky, skupinami prostředků a předplatnými. Pokud máte například malý počet tenantů, můžete být schopni nasadit jeden prostředek a sdílet ho mezi všemi tenanty. Následující diagram znázorňuje balení přihrádek do jednoho prostředku.

Diagram that shows bin packing into a single resource.

S rostoucím růstem můžete přistoupit k limitu kapacity pro jeden prostředek a škálovat na více prostředků (R). Následující diagram znázorňuje balení přihrádek napříč několika prostředky.

Diagram that shows bin packing across multiple resources.

V průběhu času můžete dosáhnout limitu počtu prostředků v jedné skupině prostředků a pak byste nasadí více prostředků (R) do více skupin prostředků (G). Následující diagram znázorňuje balení přihrádek napříč několika prostředky ve více skupinách prostředků.

Diagram that shows bin packing across multiple resources, in multiple resource groups.

A s tím, jak se rozrůstáte, můžete nasadit více předplatných (S), z nichž každá obsahuje více skupin prostředků (G) s více prostředky (R). Následující diagram znázorňuje balení přihrádek napříč několika prostředky ve více skupinách prostředků a předplatných.

Diagram that shows bin packing across multiple resources, in multiple resource groups and subscriptions.

Plánováním strategie horizontálního navýšení kapacity můžete škálovat na extrémně velký počet tenantů a udržet vysokou úroveň zatížení.

Značky

Značky prostředků umožňují přidat do prostředků Azure vlastní metadata, což může být užitečné pro správu a sledování nákladů. Další podrobnosti najdete v tématu Přidělení nákladů pomocí značek prostředků.

Antipatterny, aby se zabránilo

  • Neplánuje se škálování. Ujistěte se, že máte jasný přehled o limitech prostředků, které nasadíte, a o tom, které limity se můžou stát důležitými při nárůstu zatížení nebo počtu tenantů. Naplánujte, jak nasadíte další prostředky při škálování a otestujete plán.
  • Neplánuje se balení přihrádek. I když nepotřebujete růst okamžitě, naplánujte škálování prostředků Azure napříč několika prostředky, skupinami prostředků a předplatnými v průběhu času. Vyhněte se vytváření předpokladů v kódu aplikace, jako je jeden prostředek, když budete možná muset v budoucnu škálovat na více prostředků.
  • Škálování mnoha jednotlivých prostředků Pokud máte složitou topologii prostředků, může být obtížné škálovat jednotlivé komponenty, jednu po druhé. Často je jednodušší škálovat řešení jako jednotku podle vzoru Razítka nasazení.
  • Nasazení izolovaných prostředků pro každého tenanta, pokud není potřeba. V mnoha řešeních je nákladově efektivnější a efektivnější nasadit sdílené prostředky pro více tenantů.
  • Použití samostatných tenantů Microsoft Entra Obecně platí, že je možné zřídit více tenantů Microsoft Entra. Správa prostředků napříč tenanty Microsoft Entra je složitá. Škálování mezi předplatnými propojenými s jedním tenantem Microsoft Entra je jednodušší.
  • Overarchitecting when you don't need to scale. V některýchřešeních V těchto scénářích není potřeba vytvářet složitou logiku škálování. Pokud ale vaše organizace plánuje růst, budete muset být připravení na škálování – potenciálně na krátkou dobu.

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é:

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

Další kroky

Projděte si přístupy ke správě nákladů a přidělování .