Organizacja zasobów platformy Azure w rozwiązaniach wielodostępnych

Platforma Azure oferuje wiele opcji organizowania zasobów. W rozwiązaniu wielodostępnym istnieją konkretne kompromisy, które należy wziąć pod uwagę podczas planowania strategii organizacji zasobów. W tym artykule zapoznamy się z dwoma podstawowymi elementami organizowania zasobów platformy Azure: izolacją dzierżawy i skalowaniem w poziomie w wielu zasobach. Opisano niektóre typowe podejścia wdrażania, które mogą obsługiwać różne modele izolacji dzierżawy. Opisano również, jak pracować z limitami zasobów i limitami przydziałów platformy Azure oraz jak skalować rozwiązanie poza te limity.

Kluczowe zagadnienia i wymagania

Wymagania dotyczące izolacji dzierżawy

Podczas wdrażania wielodostępnego rozwiązania na platformie Azure należy zdecydować, czy dedykujesz zasoby do każdej dzierżawy, czy udostępniasz zasoby między wieloma dzierżawami. W ramach różnych metod i sekcji wskazówek specyficznych dla usługi w tej serii opisano opcje i kompromisy dla wielu kategorii zasobów. Ogólnie rzecz biorąc, istnieje szereg opcji izolacji dzierżawy. Zapoznaj się z modelami dzierżawy, aby wziąć pod uwagę rozwiązanie wielodostępne, aby uzyskać więcej wskazówek dotyczących sposobu decydowania o modelu izolacji.

Skaluj

Większość zasobów platformy Azure, a także grup zasobów i subskrypcji, nakłada limity, które mogą mieć wpływ na możliwość skalowania. Może być konieczne rozważenie skalowania w górę lub pakowania pojemników w celu spełnienia planowanej liczby dzierżaw lub planowanego obciążenia systemu.

Jeśli wiesz z pewnością, że nie będziesz zwiększać się do dużej liczby dzierżaw ani do dużego obciążenia, nie przesadzaj z planem skalowania w poziomie. Jeśli jednak planujesz rozwój swojego rozwiązania, należy dokładnie rozważyć plan skalowania w poziomie. Upewnij się, że projektujesz pod kątem skalowania, postępując zgodnie ze wskazówkami w tym artykule.

Jeśli masz zautomatyzowany proces wdrażania i musisz przeprowadzić skalowanie między zasobami, określ, jak wdrożysz i przypiszesz dzierżawy w wielu wystąpieniach zasobów. Na przykład w jaki sposób wykryjesz, że zbliżasz się do liczby dzierżaw, które można przypisać do określonego zasobu? Czy planujesz wdrożyć nowe zasoby w odpowiednim czasie , gdy będą potrzebne? Czy też wdrożysz pulę zasobów przed upływem czasu , aby były gotowe do użycia, gdy ich potrzebujesz?

Ważne jest również, aby uniknąć wprowadzania wszelkich założeń w całym kodzie i konfiguracji, które mogą ograniczyć możliwość skalowania. Na przykład może być konieczne skalowanie w poziomie do wielu kont magazynu w przyszłości, więc podczas kompilowania warstwy aplikacji upewnij się, że może dynamicznie przełączać konto magazynu, z którym łączy się na podstawie aktywnej dzierżawy.

Podejścia i wzorce do rozważenia

Izolacja dzierżawy

Zasoby platformy Azure są wdrażane i zarządzane za pośrednictwem hierarchii. Większość zasobów jest wdrażana w grupach zasobów, które znajdują się w subskrypcjach. Grupy zarządzania logicznie grupują subskrypcje. Wszystkie te warstwy hierarchiczne są skojarzone z dzierżawą firmy Microsoft Entra.

Podczas określania sposobu wdrażania zasobów dla każdej dzierżawy można odizolować na różnych poziomach w hierarchii. Każda opcja jest prawidłowa dla niektórych typów rozwiązań wielodostępnych i zapewnia korzyści i kompromisy. Typowe jest również łączenie podejść przy użyciu różnych modeli izolacji dla różnych składników rozwiązania.

Izolacja w zasobie udostępnionym

Możesz udostępnić zasób platformy Azure wielu dzierżawcom i uruchomić wszystkie obciążenia w jednym wystąpieniu. Zapoznaj się ze wskazówkami specyficznymi dla usługi platformy Azure, których używasz, aby zrozumieć wszelkie konkretne zagadnienia lub opcje, które mogą być ważne.

Po uruchomieniu pojedynczych wystąpień zasobu należy wziąć pod uwagę wszelkie limity usług, limity subskrypcji lub limity przydziału, które mogą być osiągane podczas skalowania. Na przykład istnieje maksymalna liczba węzłów obsługiwanych przez klaster usługi Azure Kubernetes Service (AKS) i istnieje górny limit liczby transakcji na sekundę obsługiwanych przez konto magazynu. Rozważ sposób skalowania do wielu zasobów udostępnionych w miarę zbliżania się do tych limitów.

Należy również upewnić się, że kod aplikacji jest w pełni świadomy wielodostępności i że ogranicza dostęp do danych dla określonej dzierżawy.

Na ilustracji podejścia do zasobów udostępnionych załóżmy, że firma Contoso tworzy wielodostępną aplikację SaaS obejmującą aplikację internetową, bazę danych i konto magazynu. Mogą zdecydować się na wdrożenie udostępnionych zasobów w usłudze wszystkich swoich klientów. Na poniższym diagramie jeden zestaw zasobów jest współużytkowany przez wszystkich klientów.

Oddzielanie zasobów w grupie zasobów

Można również wdrożyć dedykowane zasoby dla każdej dzierżawy. Możesz wdrożyć całą kopię rozwiązania dla jednej dzierżawy. Możesz też udostępnić niektóre składniki między dzierżawami, podczas gdy inne składniki są przeznaczone dla określonej dzierżawy. Takie podejście jest nazywane partycjonowaniem poziomym.

Zalecamy używanie grup zasobów do zarządzania zasobami przy użyciu tego samego cyklu życia. W niektórych systemach wielodostępnych warto wdrożyć zasoby dla wielu dzierżaw w jednej grupie zasobów lub zestawie grup zasobów.

Ważne jest, aby wziąć pod uwagę sposób wdrażania tych zasobów i zarządzania nimi, w tym niezależnie od tego, czy wdrażanie zasobów specyficznych dla dzierżawy jest inicjowane przez potok wdrażania, czy aplikację. Należy również określić, w jaki sposób jasno określisz , że konkretne zasoby odnoszą się do określonych dzierżaw. Rozważ użycie jasnej strategii konwencji nazewnictwa, tagów zasobów lub bazy danych katalogu dzierżaw.

Dobrym rozwiązaniem jest użycie oddzielnych grup zasobów dla zasobów współużytkujących wiele dzierżaw i zasobów wdrażanych dla poszczególnych dzierżaw. Jednak w przypadku niektórych zasobów platforma Azure ogranicza liczbę zasobów pojedynczego typu, które można wdrożyć w grupie zasobów. Ten limit oznacza, że w miarę wzrostu może być konieczne skalowanie w wielu grupach zasobów.

Załóżmy, że firma Contoso ma trzech klientów (dzierżaw): Adventure Works, Fabrikam i Tailwind. Mogą oni zdecydować się na udostępnienie aplikacji internetowej i konta magazynu między trzema dzierżawami, a następnie wdrożenie poszczególnych baz danych dla każdej dzierżawy. Na poniższym diagramie przedstawiono grupę zasobów zawierającą udostępnione zasoby i grupę zasobów zawierającą bazę danych każdej dzierżawy.

Oddzielanie grup zasobów w subskrypcji

Podczas wdrażania zestawu zasobów dla każdej dzierżawy rozważ użycie dedykowanych grup zasobów specyficznych dla dzierżawy. Na przykład w przypadku przestrzegania wzorca sygnatur wdrażania każda sygnatura powinna zostać wdrożona w własnej grupie zasobów. Możesz rozważyć wdrożenie wielu grup zasobów specyficznych dla dzierżawy w udostępnionej subskrypcji platformy Azure, co umożliwia łatwe konfigurowanie zasad i reguł kontroli dostępu.

Możesz utworzyć zestaw grup zasobów dla każdej dzierżawy, a także grupy zasobów współużytkowanych dla wszystkich zasobów udostępnionych.

Podczas wdrażania grup zasobów specyficznych dla dzierżawy w subskrypcjach udostępnionych należy pamiętać o maksymalnej liczbie grup zasobów w każdej subskrypcji i innych limitach na poziomie subskrypcji, które mają zastosowanie do wdrażanych zasobów. W miarę zbliżania się do tych limitów może być konieczne skalowanie w wielu subskrypcjach.

W naszym przykładzie firma Contoso może zdecydować się na wdrożenie sygnatury dla każdego ze swoich klientów i umieszczenie sygnatur w dedykowanych grupach zasobów w ramach jednej subskrypcji. Na poniższym diagramie jest tworzona subskrypcja zawierająca trzy grupy zasobów dla każdego klienta.

Oddzielne subskrypcje

Wdrażając subskrypcje specyficzne dla dzierżawy, można całkowicie odizolować zasoby specyficzne dla dzierżawy. Ponadto, ponieważ większość przydziałów i limitów ma zastosowanie w ramach subskrypcji, użycie oddzielnej subskrypcji na dzierżawę gwarantuje, że każda dzierżawa ma pełne wykorzystanie wszelkich odpowiednich przydziałów. W przypadku niektórych typów kont rozliczeniowych platformy Azure można programowo tworzyć subskrypcje. Możesz również użyć rezerwacji platformy Azure i planu oszczędności platformy Azure na potrzeby obliczeń w ramach subskrypcji.

Pamiętaj o liczbie subskrypcji, które można utworzyć. Maksymalna liczba subskrypcji może się różnić w zależności od relacji komercyjnych z firmą Microsoft lub partnerem firmy Microsoft, na przykład w przypadku umowy Enterprise Agreement.

Jednak w przypadku pracy w dużej liczbie subskrypcji może być trudniej zażądać zwiększenia limitu przydziału. Interfejs API limitu przydziału udostępnia interfejs programowy dla niektórych typów zasobów. Jednak w przypadku wielu typów zasobów należy zażądać zwiększenia limitu przydziału przez zainicjowanie zgłoszenia do pomocy technicznej. Może to być również trudne do pracy z umowami pomoc techniczna platformy Azure i sprawami pomocy technicznej, gdy pracujesz z wieloma subskrypcjami.

Rozważ grupowanie subskrypcji specyficznych dla dzierżawy w hierarchii grup zarządzania, aby umożliwić łatwe zarządzanie regułami i zasadami kontroli dostępu.

Załóżmy na przykład, że firma Contoso zdecydowała się utworzyć oddzielne subskrypcje platformy Azure dla każdego z trzech klientów, jak pokazano na poniższym diagramie. Każda subskrypcja zawiera grupę zasobów z kompletnym zestawem zasobów dla tego klienta.

Każda subskrypcja zawiera grupę zasobów z kompletnym zestawem zasobów dla tego klienta.

Używają grupy zarządzania, aby uprościć zarządzanie subskrypcjami. Dzięki włączeniu nazwy produkcyjnej w nazwie grupy zarządzania mogą wyraźnie odróżnić dzierżawy produkcyjne od dzierżaw nieprodukcyjnych lub testowych. Dzierżawy nieprodukcyjne miałyby różne reguły i zasady kontroli dostępu platformy Azure.

Wszystkie subskrypcje są skojarzone z jedną dzierżawą firmy Microsoft Entra. Użycie jednej dzierżawy firmy Microsoft Entra oznacza, że tożsamości zespołu firmy Contoso, w tym użytkowników i jednostek usługi, mogą być używane w całej infrastrukturze platformy Azure.

Oddzielne subskrypcje w oddzielnych dzierżawach firmy Microsoft

Istnieje również możliwość ręcznego tworzenia poszczególnych dzierżaw firmy Microsoft Entra dla każdej dzierżawy lub wdrażania zasobów w subskrypcjach w dzierżawach firmy Microsoft klientów. Jednak praca z wieloma dzierżawami firmy Microsoft Entra utrudnia uwierzytelnianie, zarządzanie przypisaniami ról, stosowanie zasad globalnych i wykonywanie wielu innych operacji zarządzania.

W sytuacjach, w których musisz zarządzać zasobami platformy Azure w subskrypcjach powiązanych z wieloma dzierżawami firmy Microsoft Entra, rozważ użycie usługi Azure Lighthouse , aby ułatwić zarządzanie zasobami w dzierżawach firmy Microsoft Entra.

Na przykład firma Contoso może utworzyć oddzielne dzierżawy firmy Microsoft Entra i oddzielne subskrypcje platformy Azure dla każdego ze swoich klientów, jak pokazano na poniższym diagramie.

Dzierżawa firmy Microsoft Entra jest skonfigurowana dla każdej dzierżawy firmy Contoso, która zawiera subskrypcję i wymagane zasoby. Usługa Azure Lighthouse jest połączona z każdą dzierżawą firmy Microsoft Entra.

Pakowanie pojemników

Niezależnie od modelu izolacji zasobów należy wziąć pod uwagę, kiedy i jak rozwiązanie będzie skalowane w poziomie w wielu zasobach. W miarę wzrostu obciążenia systemu może być konieczne skalowanie zasobów lub zwiększenie liczby dzierżaw. Rozważ pakowanie pojemników, aby wdrożyć optymalną liczbę zasobów zgodnie z wymaganiami.

Limity zasobów

Zasoby platformy Azure mają limity i limity przydziału , które należy uwzględnić w planowaniu rozwiązania. Na przykład zasoby mogą obsługiwać maksymalną liczbę współbieżnych żądań lub ustawień konfiguracji specyficznych dla dzierżawy.

Sposób konfigurowania i używania każdego zasobu wpływa również na skalowalność tego zasobu. Załóżmy na przykład, że biorąc pod uwagę pewną ilość zasobów obliczeniowych, aplikacja może pomyślnie odpowiedzieć na zdefiniowaną liczbę transakcji na sekundę. Poza tym może być konieczne skalowanie w poziomie. Testowanie wydajnościowe pomaga zidentyfikować punkt, w którym zasoby nie spełniają już wymagań.

Po udostępnieniu niektórych zasobów między dzierżawami należy najpierw określić liczbę dzierżaw, które obsługuje zasób, gdy jest skonfigurowany zgodnie z wymaganiami. Następnie wdróż tyle zasobów, ile potrzebujesz, aby obsłużyć całkowitą liczbę dzierżaw.

Załóżmy na przykład, że wdrażasz usługę aplikacja systemu Azure Gateway w ramach wielodostępnego rozwiązania SaaS. Przejrzyj projekt aplikacji, przetestuj wydajność bramy aplikacji pod obciążeniem i przejrzyj jej konfigurację. Następnie należy określić, że jeden zasób bramy aplikacji może być współużytkowany przez 100 klientów. Zgodnie z planem rozwoju organizacji oczekujesz, że w pierwszym roku dołączysz 150 klientów, więc musisz zaplanować wdrożenie wielu bram aplikacji w celu obsługi oczekiwanego obciążenia.

Na poprzednim diagramie znajdują się dwie bramy aplikacji. Pierwsza brama jest przeznaczona dla klientów od 1 do 100, a druga jest przeznaczona dla klientów od 101 do 200.

Limity grupy zasobów i subskrypcji

Niezależnie od tego, czy pracujesz z zasobami udostępnionymi, czy dedykowanymi, ważne jest, aby uwzględnić limity. Platforma Azure ogranicza liczbę zasobów, które można wdrożyć w grupie zasobów i w subskrypcji platformy Azure. W miarę zbliżania się do tych limitów należy zaplanować skalowanie w wielu grupach zasobów lub subskrypcjach.

Załóżmy na przykład, że wdrożysz dedykowaną bramę aplikacji dla każdego z klientów w udostępnionej grupie zasobów. W przypadku niektórych zasobów pomoc techniczna platformy Azure wdrażanie do 800 zasobów tego samego typu w jednej grupie zasobów. Dlatego po osiągnięciu tego limitu należy wdrożyć wszystkie nowe bramy aplikacji w innej grupie zasobów. Na poniższym diagramie znajdują się dwie grupy zasobów. Każda grupa zasobów zawiera 800 bram aplikacji.

Dzierżawy pakietu bin pack między grupami zasobów i subskrypcjami

Można również zastosować koncepcję pakowania pojemników między zasobami, grupami zasobów i subskrypcjami. Jeśli na przykład masz niewielką liczbę dzierżaw, możesz wdrożyć pojedynczy zasób i udostępnić go we wszystkich dzierżawach. Na poniższym diagramie przedstawiono pakowanie pojemnika w jeden zasób.

W miarę rozwoju możesz zbliżyć się do limitu pojemności pojedynczego zasobu i skalować w poziomie do wielu zasobów (R). Na poniższym diagramie przedstawiono pakowanie pojemników w wielu zasobach.

W miarę upływu czasu można osiągnąć limit liczby zasobów w jednej grupie zasobów, a następnie wdrożyć wiele zasobów (R) w wielu grupach zasobów (G). Na poniższym diagramie przedstawiono pakowanie pojemników w wielu zasobach w wielu grupach zasobów.

W miarę zwiększania się jeszcze większego rozmiaru można wdrażać w wielu subskrypcjach (S), z których każda zawiera wiele grup zasobów (G) z wieloma zasobami (R). Na poniższym diagramie przedstawiono pakowanie pojemników w wielu zasobach w wielu grupach zasobów i subskrypcjach.

Planując strategię skalowania w poziomie, można skalować do bardzo dużej liczby dzierżaw i utrzymać wysoki poziom obciążenia.

Tagi

Tagi zasobów umożliwiają dodawanie niestandardowych metadanych do zasobów platformy Azure, co może być przydatne w przypadku zarządzania i śledzenia kosztów. Aby uzyskać więcej informacji, zobacz Przydzielanie kosztów przy użyciu tagów zasobów.

Stosy wdrażania

Stosy wdrażania umożliwiają grupowanie zasobów na podstawie wspólnego okresu istnienia, nawet jeśli obejmują one wiele grup zasobów lub subskrypcji. Stosy wdrażania są przydatne podczas wdrażania zasobów specyficznych dla dzierżawy, zwłaszcza jeśli masz podejście do wdrażania, które wymaga wdrożenia różnych typów zasobów w różnych miejscach z powodu problemów ze skalowaniem lub zgodnością. Stosy wdrażania umożliwiają również łatwe usuwanie wszystkich zasobów związanych z jedną dzierżawą w jednej operacji, jeśli ta dzierżawa jest odłączona. Aby uzyskać więcej informacji, zobacz Wdrażanie stosów.

Antywzorzecy, aby uniknąć

• Nie planujesz skalowania. Upewnij się, że masz wyraźną wiedzę na temat limitów wdrażanych zasobów i które limity mogą stać się ważne w miarę zwiększania obciążenia lub liczby dzierżaw. Zaplanuj wdrażanie dodatkowych zasobów podczas skalowania i testowanie planu.
• Nie planujesz pakowania pojemników. Nawet jeśli nie musisz natychmiast rosnąć, zaplanuj skalowanie zasobów platformy Azure między wieloma zasobami, grupami zasobów i subskrypcjami w czasie. Unikaj wprowadzania założeń w kodzie aplikacji, takich jak pojedynczy zasób, gdy może być konieczne skalowanie do wielu zasobów w przyszłości.
• Skalowanie wielu pojedynczych zasobów. Jeśli masz złożoną topologię zasobów, skalowanie poszczególnych składników może być trudne. Często łatwiej jest skalować rozwiązanie jako jednostkę, postępując zgodnie ze wzorcem sygnatur wdrażania.
• Wdrażanie izolowanych zasobów dla każdej dzierżawy, jeśli nie jest to wymagane. W wielu rozwiązaniach bardziej ekonomiczne i wydajne jest wdrażanie udostępnionych zasobów dla wielu dzierżaw.
• Nie można śledzić zasobów specyficznych dla dzierżawy. Jeśli wdrażasz zasoby specyficzne dla dzierżawy, upewnij się, które zasoby są przydzielane do których dzierżaw. Te informacje są ważne dla celów zgodności, śledzenia kosztów i anulowania aprowizacji zasobów, jeśli dzierżawa jest odłączona. Rozważ użycie tagów zasobów, aby śledzić informacje o dzierżawie dotyczące zasobów i rozważyć użycie stosów wdrażania do grupowania zasobów specyficznych dla dzierżawy w jednostce logicznej niezależnie od grupy zasobów lub subskrypcji, w której się znajduje.
• Używanie oddzielnych dzierżaw firmy Microsoft Entra. Ogólnie rzecz biorąc, nie można aprowizować wielu dzierżaw firmy Microsoft Entra. Zarządzanie zasobami w dzierżawach firmy Microsoft Entra jest złożone. Skalowanie między subskrypcjami połączonymi z jedną dzierżawą firmy Microsoft Entra jest prostsze.
• Overarchitecting, gdy nie trzeba skalować. W niektórych rozwiązaniach wiesz z pewnością, że nigdy nie przekroczysz określonego poziomu skali. W tych scenariuszach nie ma potrzeby tworzenia złożonej logiki skalowania. Jeśli jednak organizacja planuje rozwój, konieczne będzie przygotowanie do skalowania — potencjalnie w krótkim czasie.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

• John Downs | Główny inżynier oprogramowania

Inni współautorzy:

• Jason Beck | Starszy inżynier klienta, fasttrack dla platformy Azure
• Bohdan Cherchyk | Starszy inżynier klienta, fasttrack dla platformy Azure
• Laura Nicolas | Starszy inżynier klienta, fasttrack dla platformy Azure
• Arsen Vladimirskiy | Główny inżynier klienta, fasttrack dla platformy Azure
• Joshua Waddell | Starszy inżynier klienta, fasttrack dla platformy Azure

Aby wyświetlić niepubalne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

Zapoznaj się z podejściami do zarządzania kosztami i alokacji .