Grupy zarządzania i subskrypcje

Azure organizuje zasoby w hierarchii składającej się z czterech poziomów. Na szczycie znajdują się grupy zarządzania — kontenery grupujące subskrypcje w celu stosowania zasad i kontroli dostępu na dużą skalę. Poniżej są subskrypcje — jednostki rozliczeniowe i granice zasobów. W subskrypcjach znajdują się grupy zasobów — logiczne kontenery powiązanych zasobów. Na dole znajdują się zasoby — pojedyncze usługi, takie jak maszyny wirtualne, bazy danych i konta magazynu. Zasady i uprawnienia zastosowane na wyższych poziomach są dziedziczone przez poziomy niższe.

Subskrypcja Azure jest jednocześnie jednostką rozliczeniową i logiczną granicą zasobów. Całe wykorzystanie zasobów w ramach subskrypcji jest uwzględniane na jednej fakturze. Subskrypcje określają limity (przydziały) dotyczące liczby zasobów każdego typu, które można wdrożyć. Organizacje często tworzą oddzielne subskrypcje dla różnych środowisk (Production, Development, Testing), jednostek biznesowych lub regionów geograficznych — każda z nich ma własne raportowanie kosztów i kontrolę dostępu.

Duże przedsiębiorstwa korzystają z wielu subskrypcji z kilku powodów. Izolacja — zasoby produkcyjne są całkowicie odseparowane od środowisk deweloperskich i testowych; błędna konfiguracja w środowisku deweloperskim nie może wpłynąć na produkcję. Szczegółowość rozliczeń — subskrypcja każdego działu generuje własną fakturę, co ułatwia przejrzystą alokację kosztów. Limity subskrypcji — Azure ma przydziały dotyczące poszczególnych subskrypcji (np. 250 maszyn wirtualnych na region); duże obciążenia mogą wymagać wielu subskrypcji, aby mieścić się w tych limitach.

Grupa zarządzania to kontener znajdujący się w hierarchii Azure powyżej subskrypcji. Subskrypcje można organizować w grupy zarządzania, a na poziomie grupy zarządzania stosować definicje zasad Azure Policy i przypisania ról RBAC. Są one dziedziczone przez każdą subskrypcję i każdy zasób w grupie. Eliminuje to konieczność powielania tych samych zasad lub przypisań ról w dziesiątkach poszczególnych subskrypcji.

Grupy zarządzania można zagnieżdżać na maksymalnie sześciu poziomach. Każdy katalog Azure ma jedną nadrzędną główną grupę zarządzania (Root Management Group) znajdującą się na szczycie hierarchii, której podlegają wszystkie pozostałe grupy zarządzania i subskrypcje. Typowa hierarchia przedsiębiorstwa może wyglądać następująco: Root → Company → Platform → Production → Landing Zones → Individual Workload Subscriptions. Zasady zastosowane na poziomie Root wpływają na każdą subskrypcję w całym katalogu.

Przypisania kontroli dostępu na dowolnym poziomie hierarchii są dziedziczone w dół. Jeśli użytkownikowi zostanie przypisana rola Reader w grupie zarządzania, automatycznie uzyska on dostęp Reader do każdej subskrypcji i grupy zasobów znajdującej się w tej grupie zarządzania. Dziedziczenie ma charakter addytywny — nie można odebrać odziedziczonego uprawnienia w zakresie niższego poziomu (można jedynie dodać kolejne uprawnienia). Wyjątkiem są przypisania odmowy: blokują one działania nawet wtedy, gdy przypisanie roli by na nie zezwalało.

Podobnie przypisania Azure Policy na poziomie grupy zarządzania mają zastosowanie do wszystkich subskrypcji, grup zasobów i zasobów w tej grupie. Częstą praktyką jest przypisanie bazowych zasad organizacji na poziomie głównej grupy zarządzania lub grupy zarządzania firmy, aby wymusić standardy takie jak dozwolone regiony, wymagane tagi lub obowiązkowe ustawienia diagnostyki w całej organizacji. Właściciele poszczególnych subskrypcji mogą jednocześnie dodawać bardziej szczegółowe zasady na niższych poziomach, bez zastępowania bazowych zasad organizacji.

Subskrypcje Azure można tworzyć, zmieniać ich nazwy, anulować oraz przenosić między grupami zarządzania. Przeniesienie subskrypcji do innej grupy zarządzania zmienia zasady i przypisania ról, które mają do niej zastosowanie — zmiany zasad zaczynają obowiązywać natychmiast dla wszystkich zasobów w subskrypcji. Anulowanie subskrypcji wyłącza możliwość tworzenia zasobów, a po upływie okresu karencji ostatecznie usuwa wszystkie zasoby, dlatego tę czynność należy wykonywać wyłącznie po dokładnym zaplanowaniu.

Duże organizacje korzystają z Azure na podstawie umów rozliczeniowych, które wpływają na strukturę subskrypcji. Enterprise Agreement (EA) zapewnia subskrypcje w ramach rejestracji z centralnym kontem rozliczeniowym, przeznaczone dla organizacji deklarujących duże wydatki. Microsoft Customer Agreement (MCA) to nowocześniejszy następca tej umowy, zapewniający większe możliwości samodzielnego zarządzania subskrypcjami. W obu modelach profile rozliczeniowe i sekcje faktur pozwalają grupować opłaty za subskrypcje według różnych działów.

Każda subskrypcja Azure ma przydziały usług — miękkie limity określające, ile zasobów danego typu może istnieć w poszczególnym regionie. Przykładowe wartości domyślne to: 20 000 procesorów wirtualnych vCPU na region, 980 grup zasobów na subskrypcję oraz 800 dysków zarządzanych na subskrypcję. Gdy obciążenie zbliża się do limitu, można przesłać w witrynie Azure portal żądanie zwiększenia przydziału (Support + troubleshooting > New support request). W przypadku wdrożeń na ogromną skalę firma Microsoft zaleca rozłożenie obciążeń na wiele subskrypcji.

Firma Microsoft zaleca kilka najlepszych praktyk dotyczących projektowania grup zarządzania. Należy unikać zagnieżdżania na więcej niż trzech lub czterech poziomach — zbyt wiele poziomów komplikuje diagnozowanie problemów z zasadami. Należy utworzyć dedykowaną grupę zarządzania Platform dla usług współdzielonych (tożsamość, łączność, zarządzanie), oddzieloną od obciążeń w landing zones. Środowiska produkcyjne i nieprodukcyjne należy umieścić w różnych grupach zarządzania, aby zasady przeznaczone wyłącznie dla środowisk produkcyjnych (np. wyłączające publiczny dostęp do Internetu) nie zostały przypadkowo zastosowane w środowiskach deweloperskich.

Sprawdź swoją znajomość zagadnień Microsoft Azure Fundamentals (AZ-900) omówionych w tej lekcji.

W tej lekcji poznali Państwo następujące zagadnienia: hierarchia zasobów Azure obejmuje kolejno grupy zarządzania, subskrypcje, grupy zasobów i zasoby, zasady oraz przypisania RBAC na poziomie grupy zarządzania są dziedziczone przez wszystkie podrzędne subskrypcje, a także wiele subskrypcji zapewnia odizolowanie rozliczeń, rozdzielenie środowisk oraz sposób obejścia limitów obowiązujących dla pojedynczej subskrypcji. W następnej części szczegółowo omówimy Azure Policy.