Upravit

Sdílet prostřednictvím


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

Azure
Azure Resource Manager
Microsoft Entra ID

Azure nabízí řadu možností pro uspořádání prostředků. Ve víceklientských řešeních existují určité kompromisy, které je potřeba zvážit při plánování strategie 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 některé běžné přístupy k nasazení, které můžou podporovat různé modely izolace tenantů. 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é procesy 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. Dokumentováním procesů usnadníte jejich automatizaci v případě potřeby v budoucnu.

Je také důležité, abyste se vyhnuli jakýmkoli předpokladům v celém kódu a konfiguraci, které můžou omezit vaši schopnost škálování. V budoucnu budete například muset škálovat na více účtů úložiště, takže při sestavování aplikační vrstvy se ujistěte, že může dynamicky přepínat účet úložiště, ke který se připojuje, na základě aktivního tenanta.

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 do služby 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 znázorňující jednu sadu prostředků, které sdílí všichni zákazníci

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, zatímco jiné komponenty jsou vyhrazené pro konkrétního tenanta. Tento přístup se označuje jako horizontální dělení.

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 (tenanty): Adventure Works, Fabrikam a Tailwind. Můžou se rozhodnout sdílet webovou aplikaci a účet úložiště mezi třemi tenanty a pak nasadit jednotlivé databáze pro každého tenanta. Následující diagram znázorňuje skupinu prostředků, která obsahuje sdílené prostředky a skupinu prostředků, která obsahuje databázi každého tenanta.

Diagram znázorňující skupinu prostředků, která obsahuje sdílené prostředky, a jinou skupinu prostředků, která obsahuje databázi pro každého zákazníka

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 znázorňující předplatné, které obsahuje tři skupiny prostředků, z nichž každý je kompletní sadou prostředků pro konkrétního zákazníka

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 znázorňující tři předplatná specifická pro zákazníky Každé předplatné obsahuje skupinu prostředků s kompletní sadou prostředků pro daného zákazníka.

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ů.

Než se pustíte do nasazení více tenantů Microsoft Entra, zvažte, jestli místo toho můžete dosáhnout svých požadavků pomocí skupin pro správu nebo předplatných v rámci jednoho tenanta.

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 znázorňující tenanta Microsoft Entra 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.

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 s rostoucím zatížením systému nebo s rostoucím počtem 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. Předpokládejme například, že 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 potřebujete nasadit více plánů 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 lication 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 znázorňující 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.

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 znázorňující dvě skupiny prostředků Každá skupina prostředků obsahuje 800 aplikačních bran.

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 znázorňující balení přihrádek do jednoho prostředku

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 znázorňující balení přihrádek napříč několika prostředky

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 znázorňující balení přihrádek napříč několika prostředky ve více skupinách prostředků

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 znázorňující balení přihrádek napříč několika prostředky ve více skupinách prostředků a předplatných

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ů.

Zásobníky nasazení

Zásobníky nasazení umožňují seskupit prostředky na základě společné doby života, i když pokrývají více skupin prostředků nebo předplatných. Zásobníky nasazení jsou užitečné při nasazování prostředků specifických pro tenanta, zejména pokud máte přístup nasazení, který vyžaduje nasazení různých typů prostředků na různá místa z důvodu problémů se škálováním nebo dodržováním předpisů. Zásobníky nasazení také umožňují snadno odebrat všechny prostředky související s jedním tenantem v jedné operaci, pokud se tento tenant zruší. Další informace najdete v tématu Zásobníky nasazení.

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 jednotlivě. Č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ů.
  • Nedaří se sledovat prostředky specifické pro tenanta. Pokud nasadíte prostředky specifické pro tenanta, ujistěte se, že rozumíte prostředkům, kterým tenantům se přidělují. Tyto informace jsou důležité pro účely dodržování předpisů, pro sledování nákladů a pro zrušení zřízení prostředků, pokud je tenant vyřazen. Zvažte použití značek prostředků ke sledování informací o tenantech o prostředcích a zvažte použití zásobníků nasazení k seskupení prostředků specifických pro tenanty do logické jednotky bez ohledu na skupinu prostředků nebo předplatné, ve kterém jsou.
  • 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:

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í .