Ta architektura referencyjna zawiera wskazówki dotyczące wdrażania obciążenia o krytycznym znaczeniu, które korzysta ze scentralizowanych usług udostępnionych, wymaga łączności lokalnej i integruje się z innymi obciążeniami przedsiębiorstwa. Te wskazówki są przeznaczone dla właściciela obciążenia, który jest częścią zespołu aplikacji w organizacji.
W takiej sytuacji może się okazać, że organizacja chce wdrożyć obciążenie w strefie docelowej aplikacji platformy Azure, która dziedziczy grupę zarządzania corp. Oczekuje się, że obciążenie zostanie zintegrowane ze wstępnie aprowizowaną zasobami udostępnionymi w strefie docelowej platformy Azure zarządzanej przez scentralizowane zespoły.
Ważne
Co to jest strefa docelowa platformy Azure? Strefa docelowa aplikacji to subskrypcja platformy Azure, w której działa obciążenie. Jest ona połączona z zasobami udostępnionymi organizacji. Za pośrednictwem tego połączenia ma dostęp do podstawowej infrastruktury potrzebnej do uruchomienia obciążenia, takiego jak sieć, zarządzanie dostępem do tożsamości, zasady i monitorowanie. Strefy docelowe platformy to kolekcja różnych subskrypcji, z których każda ma określoną funkcję. Na przykład subskrypcja Połączenie ivity zapewnia scentralizowane rozpoznawanie nazw DNS, łączność lokalną i wirtualne urządzenia sieciowe (WUS), które są dostępne do użycia przez zespoły aplikacji.
Jako właściciel obciążenia możesz korzystać dzięki odciążeniu zarządzania zasobami udostępnionymi zespołom centralnym i skoncentrowaniu się na wysiłkach związanych z programowaniem obciążeń. Korzyści organizacji dzięki zastosowaniu spójnego ładu i amortyzowania kosztów w wielu obciążeniach.
Zdecydowanie zalecamy zrozumienie koncepcji stref docelowych platformy Azure.
W tym podejściu maksymalna niezawodność jest wspólną odpowiedzialnością między Tobą a zespołem platformy. Składniki zarządzane centralnie muszą być wysoce niezawodne, aby obciążenie o znaczeniu krytycznym działało zgodnie z oczekiwaniami. Musisz mieć zaufaną relację z zespołem platformy, aby problemy z niedostępnością w scentralizowanych usługach, które wpływają na obciążenie, zostały złagodzone na poziomie platformy. Twój zespół jest jednak odpowiedzialny za spełnienie wymagań związanych z zespołem platformy w celu osiągnięcia celów.
Ta architektura opiera się na architekturze punktu odniesienia o krytycznym znaczeniu z kontrolkami sieci. Zaleca się zapoznanie się z architekturą punktu odniesienia przed kontynuowaniem pracy z tym artykułem.
Uwaga
Wskazówki są wspierane przez przykładową implementację klasy produkcyjnej, która prezentuje programowanie aplikacji o kluczowym znaczeniu na platformie Azure. Ta implementacja może służyć jako podstawa do dalszego opracowywania rozwiązań jako pierwszego kroku w kierunku produkcji.
Kluczowe strategie projektowania
Zastosuj te strategie w oparciu o punkt odniesienia o znaczeniu krytycznym:
Ścieżka krytyczna
Nie wszystkie składniki architektury muszą być równie niezawodne. Ścieżka krytyczna obejmuje te składniki, które muszą być funkcjonalne, aby obciążenie nie miało żadnego czasu awarii ani obniżonej wydajności. Utrzymanie tej ścieżki pochylone spowoduje zminimalizowanie punktów awarii.
Cykl życia składników
Rozważ cykl życia krytycznych składników, ponieważ ma to wpływ na cel osiągnięcia niemal zerowego czasu awarii. Składniki mogą być efemeryczne lub krótkotrwałe zasoby, które można tworzyć i niszczyć w razie potrzeby; nie efemeryczne lub długotrwałe zasoby, które współdzielą okres istnienia z systemem lub regionem.
Zależności zewnętrzne
Zminimalizuj zależności zewnętrzne od składników i procesów, które mogą powodować awarie. Architektura ma zasoby należące do różnych zespołów spoza zespołu. Te składniki (jeśli krytyczne) są w zakresie tej architektury.
Topologia subskrypcji
Strefy docelowe platformy Azure nie oznaczają jednej topologii subskrypcji. Zaplanuj swoją subskrypcję z wyprzedzeniem wraz z zespołem platformy, aby uwzględnić wymagania dotyczące niezawodności obciążeń we wszystkich środowiskach.
Autonomiczna możliwość obserwacji ścieżki krytycznej
Mają dedykowane zasoby monitorowania, które umożliwiają zespołowi szybkie wykonywanie zapytań dotyczących zbierania danych (zwłaszcza ścieżki krytycznej) i reagowanie na korygowanie.
Architektura
Pobierz plik programu Visio z tą architekturą.
Składniki tej architektury są takie same jak architektura punktu odniesienia o krytycznym znaczeniu z kontrolkami sieci. Opisy są krótkie. Jeśli potrzebujesz więcej informacji, zobacz połączone artykuły. Aby uzyskać dokumentację produktu dotyczącą usług platformy Azure, zobacz Powiązane zasoby.
Zasoby globalne
Te zasoby są aktywne w subskrypcjach strefy docelowej aplikacji. Zasoby globalne nie są efemeryczne i współużytkują okres istnienia systemu. Usługi platformy Azure i ich konfiguracja pozostają takie same jak zasoby globalne punktu odniesienia.
Zasoby sieciowe regionalne
Te zasoby są aktywne w ramach subskrypcji strefy docelowej platformy i subskrypcji strefy docelowej aplikacji. Architektura punktu odniesienia wdraża wszystkie zasoby należące do Ciebie. Jednak w tej architekturze zasoby sieciowe są udostępniane za pośrednictwem subskrypcji Połączenie ivity są aprowizowane w ramach strefy docelowej platformy.
W tym artykule zobacz sekcję Sieć wirtualna koncentratora regionalnego.
Zasoby sygnatur regionalnych
Te zasoby są aktywne w subskrypcjach strefy docelowej aplikacji. Te zasoby nie współdzielą nic z innymi zasobami, z wyjątkiem zasobów globalnych.
Większość usług platformy Azure i ich konfiguracja pozostają takie same jak architektura sygnatury bazowej, z wyjątkiem zasobów sieciowych, które są wstępnie aprowidowane przez zespół platformy.
W tym artykule zobacz sekcję Regionalna sieć wirtualna będącej szprychą.
Zasoby zewnętrzne
Obciążenie współdziała z zasobami lokalnymi. Niektóre z nich znajdują się na ścieżce krytycznej dla obciążenia, na przykład lokalnej bazy danych. Te zasoby i komunikacja z nimi są uwzględniane w ogólnej złożonej umowie dotyczącej poziomu usług (SLA) obciążenia. Cała komunikacja odbywa się za pośrednictwem subskrypcji Połączenie ivity. Istnieją inne zasoby zewnętrzne, do których może dotrzeć obciążenie, ale nie są traktowane jako krytyczne.
Zasoby potoku wdrażania
Potoki kompilacji i wydawania dla aplikacji o znaczeniu krytycznym muszą być w pełni zautomatyzowane, aby zagwarantować spójny sposób wdrażania zweryfikowanej sygnatury. Te zasoby pozostają takie same jak potok wdrażania punktu odniesienia.
Zasoby monitorowania regionalnego
Te zasoby są aktywne w subskrypcjach strefy docelowej aplikacji. Dane monitorowania zasobów globalnych i zasobów regionalnych są przechowywane niezależnie. Usługi platformy Azure i ich konfiguracja pozostają takie same jak zasoby monitorowania punktu odniesienia.
W tym artykule zapoznaj się z sekcją Zagadnienia dotyczące monitorowania.
Zasoby zarządzania
Aby uzyskać dostęp do prywatnego klastra obliczeniowego i innych zasobów, ta architektura korzysta z prywatnych agentów kompilacji i wystąpień maszyn wirtualnych przesiadkowych. Usługa Azure Bastion zapewnia bezpieczny dostęp do pól przesiadkowych. Zasoby wewnątrz sygnatur pozostają takie same jak zasoby zarządzania punktu odniesienia.
Zagadnienia dotyczące pracy w sieci
W tym projekcie obciążenie jest wdrażane w strefie docelowej aplikacji i wymaga łączności z zasobami federacyjnym w strefie docelowej platformy. Celem może być uzyskiwanie dostępu do zasobów lokalnych, kontrolowanie ruchu wychodzącego itd.
Topologia sieci
Zespół platformy decyduje o topologii sieci dla całej organizacji. Topologia piasty i szprych jest zakładana w tej architekturze. Alternatywą może być usługa Azure Virtual WAN.
Sieć wirtualna koncentratora regionalnego
Subskrypcja Połączenie ivity zawiera sieć wirtualną koncentratora z zasobami, które są współużytkowane przez całą organizację. Te zasoby są własnością zespołu platformy i są obsługiwane przez zespół platformy.
Z punktu widzenia misji krytycznej ta sieć nie jest efemeryczna, a te zasoby znajdują się na ścieżce krytycznej.
| Zasób platformy Azure | Purpose |
|---|---|
| Azure ExpressRoute | Zapewnia łączność prywatną z infrastruktury lokalnej do infrastruktury platformy Azure. |
| Azure Firewall | Działa jako urządzenie WUS, które sprawdza i ogranicza ruch wychodzący. |
| Usługa DNS platformy Azure | Zapewnia rozpoznawanie nazw między środowiskami lokalnymi. |
| VPN Gateway | Połączenie zdalnych oddziałów organizacji za pośrednictwem publicznego Internetu do infrastruktury platformy Azure. Działa również jako alternatywa dla łączności kopii zapasowej w celu dodania odporności. |
Zasoby są aprowizowane w każdym regionie i za pomocą komunikacji równorzędnej z siecią wirtualną szprych (opisaną poniżej). Upewnij się, że rozumiesz i zgadzasz się na aktualizacje urządzenia WUS, reguł zapory, reguł routingu, trybu failover usługi ExpressRoute do usługi VPN Gateway, infrastruktury DNS itd.
Uwaga
Kluczową korzyścią w korzystaniu z centrum federacyjnego jest to, że obciążenie może integrować się z innymi obciążeniami na platformie Azure lub między środowiskami, przechodząc przez centra sieci zarządzane przez organizację. Ta zmiana obniża również koszty operacyjne, ponieważ część odpowiedzialności zostaje przeniesiona do zespołu platformy.
Sieć wirtualna będącej szprychą regionalną
Strefa docelowa aplikacji ma co najmniej dwie wstępnie aprowizowane sieci wirtualne platformy Azure na region, do których odwołują się sygnatury regionalne. Te sieci nie są efemeryczne. Jeden obsługuje ruch produkcyjny, a drugi dotyczy wdrożenia vNext. Takie podejście zapewnia możliwość wykonywania niezawodnych i bezpiecznych rozwiązań dotyczących wdrożeń.
Sieć wirtualna Operacje
Ruch operacyjny jest izolowany w oddzielnej sieci wirtualnej. Ta sieć wirtualna nie jest efemeryczna i jest właścicielem tej sieci. Ta architektura zachowuje ten sam projekt co architektura linii bazowej z kontrolkami sieci.
Nie ma komunikacji równorzędnej między siecią operacjami i siecią szprych. Cała komunikacja odbywa się za pośrednictwem linków prywatnych.
Wspólna odpowiedzialność
Jasne zrozumienie, który zespół jest odpowiedzialny za każdy element projektu architektury. Oto kilka kluczowych obszarów.
Planowanie adresów IP
Po oszacowaniu rozmiaru potrzebnego do uruchomienia obciążenia skontaktuj się z zespołem platformy, aby umożliwić odpowiednią aprowizację sieci.
Zespół platformy
Podaj różne adresy dla sieci wirtualnych, które uczestniczą w komunikacji równorzędnej. Nakładające się adresy, na przykład sieci lokalne i robocze, mogą powodować zakłócenia, co prowadzi do awarii.
Przydziel przestrzenie adresowe IP, które są wystarczająco duże, aby zawierać zasoby środowiska uruchomieniowego i wdrożenia, obsługiwać tryb failover i obsługiwać skalowalność.
Wstępnie aprowizowana sieć wirtualna i komunikacja równorzędna muszą mieć możliwość obsługi oczekiwanego wzrostu obciążenia. Należy regularnie oceniać ten wzrost wraz z zespołem platformy. Aby uzyskać więcej informacji, zobacz Połączenie ivity to Azure (Połączenie ivity to Azure).
Podsieć sieci będącej szprychą regionalną
Odpowiadasz za przydzielanie podsieci w regionalnej sieci wirtualnej. Podsieci i zasoby w nich są efemeryczne. Przestrzeń adresowa powinna być wystarczająco duża, aby pomieścić potencjalny wzrost.
Podsieć prywatnych punktów końcowych Po dotarciu ruchu do sieci wirtualnej komunikacja z usługami PaaS w sieci jest ograniczona przy użyciu prywatnych punktów końcowych, podobnie jak architektura punktu odniesienia z kontrolkami sieci. Te punkty końcowe są umieszczane w dedykowanej podsieci. Prywatne adresy IP do prywatnych punktów końcowych są przypisywane z tej podsieci.
Podsieć klastra Wymagania dotyczące skalowalności obciążenia wpływają na to, ile przestrzeni adresowej należy przydzielić dla podsieci. W miarę skalowania węzłów i zasobników usługi AKS adresy IP są przypisywane z tej podsieci.
Segmentacja sieci
Zachowaj odpowiednią segmentację, aby niezawodność obciążenia nie została naruszona przez nieautoryzowany dostęp.
Ta architektura używa sieciowych grup zabezpieczeń w celu ograniczenia ruchu między podsieciami i subskrypcją Połączenie ivity. Sieciowe grupy zabezpieczeń używają elementów ServiceTag dla obsługiwanych usług.
Zespół platformy
Wymuszanie korzystania z sieciowych grup zabezpieczeń za pomocą zasad usługi Azure Network Manager.
Należy pamiętać o projekcie obciążenia. Nie ma żadnego bezpośredniego ruchu między sygnaturami. Nie ma również przepływów między regionami. Jeśli te ścieżki są potrzebne, ruch musi przepływać przez subskrypcję Połączenie ivity.
Zapobiegaj niepotrzebnemu ruchowi koncentratora pochodzącemu z innych obciążeń do obciążenia o krytycznym znaczeniu.
Ruch wychodzący z sygnatur regionalnych
Cały ruch wychodzący z każdej regionalnej sieci szprych jest kierowany przez scentralizowaną usługę Azure Firewall w sieci koncentratora regionalnego. Działa jako następny przeskok, który sprawdza, a następnie zezwala na ruch lub odmawia go.
Zespół platformy
Utwórz trasy zdefiniowane przez użytkownika dla tej trasy niestandardowej.
Przypisz zasady platformy Azure, które zablokują zespołowi aplikacji możliwość tworzenia podsieci, które nie mają nowej tabeli tras.
Nadaj odpowiednie uprawnienia kontroli dostępu opartej na rolach (RBAC) zespołowi aplikacji, aby umożliwić rozszerzanie tras na podstawie wymagań obciążenia.
Nadmiarowość w wielu regionach
Obciążenia o krytycznym znaczeniu muszą być wdrażane w wielu regionach, aby wytrzymać awarie regionalne. Skontaktuj się z zespołem ds. platformy, aby upewnić się, że infrastruktura jest niezawodna.
Zespół platformy
Wdrażanie scentralizowanych zasobów sieciowych na region. Metodologia projektowania o krytycznym znaczeniu wymaga izolacji regionalnej.
Skontaktuj się z zespołem aplikacji, aby odkryć ukryte zależności regionalne, aby zasób platformy o obniżonej wydajności w jednym regionie nie wpływał na obciążenia w innym regionie.
Rozpoznawanie nazw DNS
Subskrypcja Połączenie ivity zapewnia prywatne strefy DNS. Jednak takie scentralizowane podejście może nie uwzględniać potrzeb DNS, które mogą być specyficzne dla twojego przypadku użycia. Aprowizuj własne strefy DNS i połącz się z sygnaturą regionalną. Jeśli zespół aplikacji nie jest właścicielem systemu DNS, zarządzanie łączami prywatnymi staje się trudne dla zasobów globalnych, takich jak usługa Azure Cosmos DB.
Zespół platformy
Deleguj strefy usługi Azure Prywatna strefa DNS do zespołu aplikacji, aby uwzględnić ich przypadki użycia.
W przypadku sieci koncentratora regionalnego ustaw wartość Domyślna (zapewniana przez platformę Azure) na obsługę prywatnych stref DNS zarządzanych przez zespół aplikacji.
Zagadnienia dotyczące projektowania środowiska
Ogólną praktyką jest umieszczenie obciążeń w osobnych środowiskach dla środowiska produkcyjnego, przedprodukcyjnego i programistycznego. Oto kilka kluczowych zagadnień.
Jak jest utrzymywana izolacja?
Środowisko produkcyjne musi być odizolowane od innych środowisk. Niższe środowiska powinny również utrzymywać poziom izolacji. Unikaj udostępniania zasobów należących do aplikacji między środowiskami.
Jedno środowisko produkcyjne jest wymagane dla zasobów globalnych, regionalnych i sygnatur należących do zespołu aplikacji. Środowiska przedprodukcyjne, takie jak przemieszczanie i integracja, są potrzebne, aby upewnić się, że aplikacja jest testowana w środowisku, które symuluje środowisko produkcyjne, jak najwięcej. Środowisko programistyczne powinno być skalowaną w dół wersją środowiska produkcyjnego.
Jaki jest oczekiwany cykl życia?
Środowiska przedprodukcyjne można zniszczyć po zakończeniu testów sprawdzania poprawności. Zaleca się, aby środowiska deweloperskie współdzielą okres istnienia funkcji i zostały zniszczone po zakończeniu programowania. Te akcje wykonywane przez automatyzację ciągłej integracji/ciągłego wdrażania (CI/CD).
Jakie są kompromisy?
Rozważ kompromisy między izolacją środowisk, złożonością zarządzania i optymalizacją kosztów.
Napiwek
Wszystkie środowiska powinny mieć zależności od wystąpień produkcyjnych zasobów zewnętrznych, w tym zasobów platformy. Na przykład centrum regionalne produkcyjne w subskrypcji Połączenie ivity. Będzie można zminimalizować różnicę między środowiskami przedprodukcyjnymi i produkcyjnymi.
Topologia subskrypcji dla infrastruktury obciążeń
Subskrypcje są przekazywane przez zespół platformy. W zależności od liczby środowisk zażądasz kilku subskrypcji tylko dla jednego obciążenia. W zależności od typu środowiska niektóre środowiska mogą potrzebować dedykowanych subskrypcji, podczas gdy inne środowiska mogą być konsolidowane w jednej subskrypcji.
Niezależnie od tego, współpracuj z zespołem platformy, aby zaprojektować topologię spełniającą ogólny cel niezawodności obciążenia. Istnieje korzyść z udostępniania zasobów udostępnianych przez platformę między środowiskami w tej samej subskrypcji, ponieważ będzie odzwierciedlać środowisko produkcyjne.
Uwaga
Użycie wielu subskrypcji do przechowywania środowisk może osiągnąć wymagany poziom izolacji. Subskrypcje strefy docelowej są dziedziczone z tej samej grupy zarządzania. Dlatego spójność z produkcją jest zapewniana na potrzeby testowania i walidacji.
Subskrypcja produkcyjna
Mogą istnieć limity zasobów dla danej subskrypcji. Jeśli kolokujesz wszystkie te zasoby w jednej subskrypcji, możesz osiągnąć te limity. Na podstawie jednostek skalowania i oczekiwanej skali rozważ bardziej rozproszony model. Przykład:
Jedna subskrypcja zawierająca zarówno agentów kompilacji usługi Azure DevOps, jak i zasobów globalnych.
Jedna subskrypcja na region. Zawiera on zasoby regionalne, zasoby sygnatury i pola przesiadkowe dla regionalnych znaczków.
Oto przykładowa topologia subskrypcji używana w tej architekturze.
Subskrypcja przedprodukcyjny
Wymagana jest co najmniej jedna subskrypcja. Można jednak uruchamiać wiele niezależnych środowisk, jednak zalecane jest posiadanie wielu środowisk w dedykowanych subskrypcjach. Ta subskrypcja może również podlegać limitom zasobów, takim jak subskrypcja produkcyjna, opisana powyżej.
Subskrypcja programowania
Wymagana jest co najmniej jedna subskrypcja. Ta subskrypcja może podlegać limitom zasobów, jeśli są uruchamiane wszystkie niezależne środowiska. Dlatego możesz zażądać wielu subskrypcji. Zalecane jest posiadanie poszczególnych środowisk w swoich dedykowanych subskrypcjach.
Staraj się jak najbardziej dopasować topologię produkcyjną.
Uwagi dotyczące wdrażania
Nieudane wdrożenia lub błędne wydania są typowymi przyczynami awarii aplikacji. Dokładnie przetestuj aplikację (i nowe funkcje) w ramach cyklu życia aplikacji. Podczas wdrażania obciążenia w strefie docelowej należy zintegrować projekt z zasobami udostępnianymi przez platformę i ładem.
Zapoznaj się z tematem: Dobrze zaprojektowane obciążenia o znaczeniu krytycznym: Wdrażanie i testowanie.
Infrastruktura wdrażania
Niezawodność infrastruktury wdrażania, takiej jak agenci kompilacji i ich sieć, jest często tak ważna jak zasoby środowiska uruchomieniowego obciążenia.
Ta architektura używa prywatnych agentów kompilacji, aby zapobiec nieautoryzowanemu dostępowi, który może mieć wpływ na dostępność aplikacji.
Utrzymywanie izolacji między zasobami wdrażania jest zdecydowanie zalecane. Infrastruktura wdrażania powinna być powiązana z subskrypcjami obciążeń dla tego środowiska. Jeśli używasz wielu środowisk w subskrypcjach przedprodukcyjnych, utwórz dalsze rozdzielenie, ograniczając dostęp tylko do tych indywidualnych środowisk. Zasoby wdrażania dla poszczególnych regionów można rozważyć, aby infrastruktura wdrażania byłaby bardziej niezawodna.
Wdrażanie bez przestojów
Aktualizacje aplikacji może powodować awarie. Wymuszanie spójnych wdrożeń zwiększy niezawodność. Zalecane są następujące podejścia:
- Mają w pełni zautomatyzowane potoki wdrażania.
- Wdrażanie aktualizacji w środowiskach przedprodukcyjnych na czystej sygnaturze.
Aby uzyskać więcej informacji, zobacz Wytyczne dotyczące wdrażania i testowania o znaczeniu krytycznym.
W architekturze bazowej te strategie są implementowane przez anulowanie aprowizacji, a następnie usunięcie sygnatury z każdą aktualizacją. W tym projekcie nie można ukończyć aprowizacji, ponieważ zespół platformy jest właścicielem niektórych zasobów. Dlatego model wdrażania został zmieniony.
Model wdrażania
Architektura linii bazowej używa modelu Blue-Green do wdrażania aktualizacji aplikacji. Nowe sygnatury ze zmianami są wdrażane wraz z istniejącymi sygnaturami. Po przeniesieniu ruchu do nowej sygnatury istniejąca sygnatura zostanie zniszczona.
W takim przypadku dana równorzędna sieć wirtualna nie jest efemeryczna. Sygnatura nie może utworzyć sieci wirtualnej ani komunikacji równorzędnej z regionalnym koncentratorem. Należy ponownie użyć tych zasobów w każdym wdrożeniu.
Model canary może osiągnąć bezpieczne wdrożenie z opcją wycofania. Najpierw zostanie wdrożona nowa sygnatura ze zmianami kodu. Potok wdrażania odwołuje się do wstępnie aprowizowanej sieci wirtualnej i przydziela podsieci, wdraża zasoby, dodaje prywatne punkty końcowe. Następnie przenosi ruch do tych podsieci w wstępnie aprowizowanej sieci wirtualnej.
Gdy istniejąca sygnatura nie jest już wymagana, wszystkie zasoby sygnatury są usuwane przez potok, z wyjątkiem zasobów należących do platformy. Sieć wirtualna, ustawienia diagnostyczne, komunikacja równorzędna, przestrzeń adresów IP, konfiguracja DNS i kontrola dostępu oparta na rolach (RBAC) są zachowywane. W tym momencie sygnatura jest w stanie czystym i jest gotowa do następnego nowego wdrożenia.
Zasady platformy Azure dotyczące usługi DINE (deploy-if-not-exists)
Strefy docelowe aplikacji platformy Azure mogą mieć zasady platformy Azure DINE (deploy-if-not-exists). Te testy zapewniają, że wdrożone zasoby spełniają standardy firmowe w strefach docelowych aplikacji, nawet jeśli są one własnością zespołu aplikacji. Może wystąpić niezgodność między wdrożeniem a ostateczną konfiguracją zasobu.
Poznaj wpływ wszystkich zasad DINE, które zostaną zastosowane do zasobów. W przypadku zmian w konfiguracji zasobów należy uwzględnić intencje zasad we wdrożeniach deklaratywnych na wczesnym etapie cyklu tworzenia obciążenia. W przeciwnym razie może wystąpić dryf prowadzący do różnicy między żądanym stanem a wdrożonym stanem.
Wdrażanie zarządzania dostępem do subskrypcji
Traktuj granice subskrypcji jako granice zabezpieczeń, aby ograniczyć promień wybuchu. Zagrożenia mogą mieć wpływ na niezawodność obciążenia.
Zespół platformy
- Nadaj zespołom aplikacji autoryzację dla operacji z uprawnieniami w zakresie subskrypcji strefy docelowej aplikacji.
Jeśli korzystasz z wielu wdrożeń w ramach jednej subskrypcji, naruszenie będzie miało wpływ na oba wdrożenia. Zalecane jest uruchamianie wdrożeń w dedykowanych subskrypcjach. Tworzenie jednostek usługi na środowisko w celu zachowania separacji logicznej.
Jednostka usługi powinna zapewnić autonomię nad zasobami obciążenia. Ponadto powinny istnieć ograniczenia, które uniemożliwią nadmierne manipulowanie zasobami platformy w ramach subskrypcji.
Zagadnienia dotyczące monitorowania
Platforma strefy docelowej platformy Azure udostępnia współużytkowane zasoby umożliwiające obserwowanie w ramach subskrypcji zarządzania. Scentralizowany zespół operacyjny zachęca zespoły ds. aplikacji do korzystania z modelu federacyjnego. Jednak w przypadku obciążeń o znaczeniu krytycznym pojedynczy, scentralizowany magazyn obserwacji nie jest zalecany, ponieważ może to być pojedynczy punkt awarii. Obciążenia o znaczeniu krytycznym generują również dane telemetryczne, które mogą nie być stosowane lub możliwe do działania w przypadku scentralizowanych zespołów operacyjnych.
Dlatego zdecydowanie zaleca się autonomiczne podejście do monitorowania. Operatorzy obciążeń są ostatecznie odpowiedzialni za monitorowanie i muszą mieć dostęp do wszystkich danych reprezentujących ogólną kondycję.
Architektura linii bazowej jest zgodna z tym podejściem i jest kontynuowana w tej architekturze referencyjnej. Usługi Azure Log Analytics i aplikacja systemu Azure Szczegółowe informacje są wdrażane regionalnie i globalnie w celu monitorowania zasobów w tych zakresach. Agregowanie dzienników, tworzenie pulpitów nawigacyjnych i alertów jest w zakresie twojego zespołu. Skorzystaj z funkcji Diagnostyka Azure, które wysyłają metryki i dzienniki do różnych ujściów, aby obsługiwać wymagania platformy dotyczące zbierania dzienników i metryk.
Health model (Model kondycji)
Metodologia projektowania o krytycznym znaczeniu wymaga modelu kondycji systemu. Podczas definiowania ogólnego wyniku kondycji uwzględnij przepływy strefy docelowej platformy w zakresie, od których zależy aplikacja. Tworzenie zapytań dziennika, kondycji i alertów w celu przeprowadzania monitorowania między obszarami roboczymi.
Zespół platformy
Udziel zapytań kontroli dostępu opartej na rolach (RBAC) i odczytuje ujścia dzienników dla odpowiednich zasobów platformy, które są używane w ścieżce krytycznej aplikacji o znaczeniu krytycznym.
Obsługa organizacyjnego celu niezawodności w kierunku obciążenia o krytycznym znaczeniu, dając zespołowi aplikacji wystarczające uprawnienia do wykonywania operacji.
W tej architekturze model kondycji zawiera dzienniki i metryki z zasobów aprowizowania w subskrypcji Połączenie ivity. Jeśli ten projekt zostanie rozszerzony w celu uzyskania dostępu do zasobu lokalnego, takiego jak baza danych, model kondycji musi obejmować łączność sieciową z tym zasobem, w tym granice zabezpieczeń, takie jak wirtualne urządzenia sieciowe na platformie Azure i lokalnie. Te informacje są ważne, aby szybko określić główną przyczynę i skorygować wpływ na niezawodność. Czy na przykład wystąpił błąd podczas próby przekierowania do bazy danych, czy wystąpił problem z bazą danych?
Zapoznaj się z tematem: Dobrze zaprojektowane obciążenia o znaczeniu krytycznym: Modelowanie kondycji.
Integracja z zasadami i regułami udostępnianymi przez platformę
Subskrypcja strefy docelowej aplikacji dziedziczy zasady platformy Azure, reguły usługi Azure Network Manager i inne kontrolki z grupy zarządzania. Zespół platformy udostępnia te bariery ochronne.
W przypadku wdrożeń nie zależą wyłącznie od zasad udostępnianych przez platformę, ponieważ:
- Nie są one projektowe w celu zaspokojenia potrzeb poszczególnych obciążeń.
- Zasady i reguły mogą zostać zaktualizowane lub usunięte poza zespołem, co może mieć wpływ na niezawodność.
Zdecydowanie zaleca się tworzenie i przypisywanie zasad platformy Azure we wdrożeniach. Ten wysiłek może prowadzić do duplikowania, ale jest to akceptowalne, biorąc pod uwagę potencjalny wpływ na niezawodność systemu. Jeśli w zasadach platformy zostaną wprowadzone zmiany, zasady obciążenia będą nadal obowiązywać lokalnie.
Zespół platformy
- Zaangażuj zespół aplikacji w proces zarządzania zmianami zasad w miarę ich rozwoju.
- Należy pamiętać o zasadach używanych przez zespół aplikacji. Oceń, czy powinny zostać dodane do grupy zarządzania.
Wdrażanie tej architektury
Aspekty sieciowe tej architektury są implementowane w implementacji o znaczeniu krytycznym Połączenie.
Uwaga
Implementacja Połączenie ma na celu zilustrowanie obciążenia o krytycznym znaczeniu, które opiera się na zasobach organizacji, integruje się z innymi obciążeniami i korzysta z usług udostępnionych. W implementacji przyjęto założenie, że istnieje już subskrypcja Połączenie ivity.
Następne kroki
Zapoznaj się z obszarem projektowania sieci i łączności w witrynie Azure Well-Architected Framework.
Powiązane zasoby
Oprócz usług platformy Azure używanych w architekturze bazowej te usługi są ważne dla tej architektury.