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 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?
Napiwek
We wczesnych etapach projektowania i programowania możesz nie zdecydować się na zaimplementowanie zautomatyzowanego procesu skalowania w poziomie. Nadal należy rozważyć i wyraźnie udokumentować procesy wymagane do skalowania w miarę zwiększania się.
Ważne jest również, aby uniknąć wprowadzania założeń w kodzie i konfiguracji, co może ograniczyć możliwość skalowania. Na przykład może być konieczne skalowanie w poziomie do wielu kont magazynu. Upewnij się, że warstwa aplikacji nie zakłada, że łączy się tylko z jednym kontem magazynu dla wszystkich dzierżaw.
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 i będą używać tych zasobów do obsługi 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 i wdrożyć inne składniki dedykowane dla określonej dzierżawy.
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: Adventure Works, Fabrikam i Tailwind. Mogą oni zdecydować się na udostępnienie aplikacji internetowej i konta magazynu między trzema klientami, a następnie wdrożenie poszczególnych baz danych dla każdej dzierżawy. Na poniższym diagramie każdy klient ma przypisaną grupę zasobów zawierającą udostępnione zasoby i grupę zasobów zawierającą bazę danych.
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.
Ostrzeżenie
Zalecamy utworzenie wielu dzierżaw firmy Microsoft Entra dla większości rozwiązań wielodostępnych. Praca w dzierżawach firmy Microsoft Entra wprowadza dodatkową złożoność i zmniejsza możliwość skalowania zasobów i zarządzania nimi. Zazwyczaj to podejście jest używane tylko przez dostawców usług zarządzanych (MSP), którzy obsługują środowiska platformy Azure w imieniu swoich klientów.
Jedna dzierżawa firmy Microsoft Entra może być używana przez wiele oddzielnych subskrypcji i zasobów platformy Azure. Przed podjęciem wysiłku w celu wdrożenia wielu dzierżaw firmy Microsoft Entra należy rozważyć, czy istnieją inne podejścia, które mogą osiągnąć Twoje cele.
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 lub zwiększania się liczby dzierżaw może być konieczne skalowanie zasobów. Rozważ pakowanie pojemników, aby wdrożyć optymalną liczbę zasobów zgodnie z wymaganiami.
Napiwek
W wielu rozwiązaniach łatwiej jest skalować cały zestaw zasobów razem, zamiast pojedynczo skalować zasoby. Rozważ zastosowanie wzorca sygnatur wdrożenia.
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. Na przykład 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ń.
Uwaga
Zasada skalowania do wielu zasobów ma zastosowanie nawet w przypadku pracy z usługami obsługującymi wiele wystąpień.
Na przykład usługa aplikacja systemu Azure obsługuje skalowanie w poziomie liczby wystąpień planu, ale istnieją limity dotyczące tego, jak daleko można skalować pojedynczy plan. W aplikacji wielodostępnej o dużej skali możesz przekroczyć te limity i wdrożyć dodatkowe zasoby usługi App Service w celu dopasowania do wzrostu.
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 wdrożysz bramę aplikacja systemu Azure 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.
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 stać się trudne do jednego. 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.
- 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 klienta, fasttrack dla platformy Azure
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 .