Architektura linii bazowej usługi Azure Virtual Machines w strefie docelowej platformy Azure

Architektura w tym artykule rozszerza architekturę punktu odniesienia maszyny wirtualnej, aby sprostać zmianom i oczekiwaniom podczas wdrażania jej w strefie docelowej platformy Azure.

W przykładzie w tym artykule organizacja chce, aby obciążenie oparte na maszynach wirtualnych używało zasobów federacyjnych zarządzanych centralnie przez zespół platformy. Te zasoby obejmują zasoby sieciowe na potrzeby łączności obejmującej wiele lokalizacji, zarządzania dostępem do tożsamości i zasad. W tym przykładzie przyjęto założenie, że organizacja przyjmuje strefy docelowe platformy Azure w celu wymuszania spójnego ładu i wydajności kosztów w wielu obciążeniach.

Jako właściciel obciążenia możesz odciążyć zarządzanie zasobami udostępnionymi zespołom centralnym, aby skoncentrować się na wysiłkach programistycznych obciążeń. W tym artykule przedstawiono perspektywę zespołu roboczego. Rekomendacje, które są przeznaczone dla zespołu platformy, są określone.

Układ artykułu

Architektura	Decyzja projektowa	Podejście azure Well-Architected Framework
▪ Diagram architektury ▪ Zasoby obciążenia ▪ Zasoby federacyjne	▪ Konfiguracja subskrypcji ▪ Wymagania dotyczące sieci ▪ Zmiany projektu sieci z punktu odniesienia ▪ Monitorowania ▪ Zgodność poprawek ▪ Nadzór organizacyjny ▪ Zarządzanie zmianami	▪ Niezawodność ▪ Zabezpieczeń ▪ Optymalizacja kosztów

Architektura

Pobierz plik programu Visio z tą architekturą.

Składniki

Wszystkie architektury strefy docelowej platformy Azure mają separację własności między zespołem platformy a zespołem obciążenia. Architekci aplikacji i zespoły DevOps muszą mieć silne zrozumienie tego podziału odpowiedzialności, aby zrozumieć, co jest pod ich bezpośrednim wpływem lub kontrolą, a co nie.

Zasoby należące do zespołu obciążeń

Następujące zasoby pozostają w większości niezmienione z architektury punktu odniesienia.

• Usługa Azure Virtual Machines to platforma aplikacji. Zasoby obliczeniowe są dystrybuowane w różnych strefach dostępności.

• Usługa Azure Load Balancer służy do prywatnego równoważenia obciążenia ruchu z maszyn wirtualnych frontonu do maszyn wirtualnych zaplecza. Moduł równoważenia obciążenia dystrybuuje ruch do maszyn wirtualnych między strefami.

• aplikacja systemu Azure Gateway jest używana jako zwrotny serwer proxy do kierowania żądań użytkowników do maszyn wirtualnych frontonu. Wybrana jednostka SKU jest również używana do hostowania usługi Azure Web Application Firewall w celu ochrony maszyn wirtualnych frontonu przed potencjalnie złośliwym ruchem.

• Usługa Azure Key Vault służy do przechowywania wpisów tajnych aplikacji i certyfikatów.

• Usługi Azure Monitor, Log Analytics i Application Szczegółowe informacje służą do zbierania, przechowywania i wizualizowania danych z obserwacji.

• Usługa Azure Policy służy do stosowania zasad specyficznych dla obciążenia.

Zespół ds. obciążeń utrzymuje i spełnia następujące zasoby i obowiązki.

• Podsieci sieci wirtualnej szprych i sieciowe grupy zabezpieczeń umieszczone w tych podsieciach w celu utrzymania segmentacji i sterowania przepływem ruchu.

• Prywatne punkty końcowe w celu zabezpieczenia łączności z rozwiązaniami PaaS (Platform as a Service) i prywatnymi strefami DNS wymaganymi dla tych punktów końcowych.

• Usługa Azure Dyski zarządzane przechowuje pliki dziennika na serwerach zaplecza, a dane są zachowywane nawet podczas ponownego uruchamiania maszyn wirtualnych. Serwery frontonu mają dołączone dyski, których można użyć do wdrożenia aplikacji bezstanowej.

Zasoby należące do zespołu platformy

Zespół platformy jest właścicielem i utrzymuje te scentralizowane zasoby. W tej architekturze przyjęto założenie, że te zasoby są wstępnie aprowidowane i uwzględnia je w zależnościach.

• Usługa Azure Firewall w sieci piasty służy do inspekcji i ograniczania ruchu wychodzącego. Ten składnik zastępuje standardowy moduł równoważenia obciążenia w architekturze bazowej, która nie zapewnia ograniczeń dotyczących ruchu wychodzącego do Internetu.

• Usługa Azure Bastion w sieci piasty zapewnia bezpieczny dostęp operacyjny do maszyn wirtualnych obciążeń. W architekturze bazowej zespół ds. obciążeń jest właścicielem tego składnika.

• Sieć wirtualna szprychy to miejsce, w którym jest wdrażane obciążenie.

• Trasy zdefiniowane przez użytkownika są używane do wymuszania tunelowania do sieci piasty.

• Ograniczenia ładu oparte na usłudze Azure Policy i DeployIfNotExists zasady (DINE) są częścią subskrypcji obciążenia.

Konfiguracja subskrypcji

W kontekście strefy docelowej zespół ds. obciążeń musi poinformować zespół platformy o określonych wymaganiach.

Zespół ds. obciążeń musi zawierać szczegółowe informacje o przestrzeni sieciowej, których potrzebuje obciążenie, aby zespół platformy mógł przydzielić niezbędne zasoby. Twój zespół określa wymagania, a zespół platformy określa adresy IP do przypisania w sieci wirtualnej i grupie zarządzania, do której przypisano subskrypcję.

Zespół platformy przypisuje odpowiednią grupę zarządzania na podstawie krytycznego działania i wymagań technicznych obciążenia, na przykład w przypadku uwidocznienia obciążenia w Internecie. Organizacja określa konfigurację tych grup zarządzania, a zespół platformy je implementuje.

Na przykład grupy zarządzania w scenariuszach aplikacji dla architektury punktu odniesienia są brane pod uwagę:

• Aplikacje prywatne, takie jak wewnętrzne aplikacje biznesowe lub komercyjne rozwiązania poza półki (COTS), które często znajdują się w grupie zarządzania Corp stref docelowych platformy Azure.

• Aplikacje publiczne, podobnie jak w aplikacjach dostępnych z Internetu, które często znajdują się w grupie zarządzania Corp lub Online.

Zespół platformy jest również odpowiedzialny za skonfigurowanie subskrypcji lub grupy subskrypcji na potrzeby wdrożenia obciążenia.

Poniższe sekcje zawierają wskazówki dotyczące początkowej konfiguracji subskrypcji. Jednak zespół platformy zazwyczaj wprowadza zmiany w scentralizowanych usługach w celu rozwiązania nieodebranych lub zmienionych wymagań. Zmiany platformy mają szerszy wpływ na wszystkie zespoły obciążeń.

W związku z tym zespół platformy musi upewnić się, że wszystkie obciążenia maszyn wirtualnych są przygotowane na wszelkie zmiany i muszą mieć świadomość cyklu życia rozwiązania opartego na maszynie wirtualnej i cyklu testowania. Aby uzyskać więcej informacji, zobacz Zarządzanie zmianami w czasie.

Wymagania i realizacja obciążeń

Zespoły ds. obciążeń i zespoły platform mają dwa główne obowiązki: przypisywanie grup zarządzania i konfigurowanie sieci. W przypadku tej architektury należy wziąć pod uwagę następujące wymagania dotyczące sieci, które należy przekazać zespołowi platformy. Użyj tych punktów jako przykładów, aby zrozumieć dyskusję i negocjacje między dwoma zespołami podczas implementowania podobnej architektury.

• Liczba sieci wirtualnych szprych: w tej architekturze wymagana jest tylko jedna dedykowana szprycha. Wdrożone zasoby nie muszą obejmować wielu sieci i są kolokowane w ramach jednej sieci wirtualnej.

• Rozmiar sieci szprych: weź pod uwagę wymagania operacyjne i oczekiwany wzrost obciążenia. Jeśli na przykład planujesz zaimplementować aktualizacje niebieskie/zielone lub kanary, maksymalny rozmiar powinien uwzględniać miejsce wymagane przez wdrożenia równoległe.

  Przyszłe zmiany mogą wymagać większej ilości miejsca na adres IP, co może być niezgodne z bieżącą alokacją. Integracja tych przestrzeni może powodować dodatkową złożoność. Bądź proaktywny i żądaj wystarczającej ilości zasobów sieciowych z góry, aby zapewnić, że przydzielone miejsce może pomieścić przyszłe rozszerzenie.

• Region wdrażania: ważne jest określenie regionów, w których zostanie wdrożone obciążenie. Zespół platformy może użyć tych informacji, aby upewnić się, że sieci wirtualne będące szprychą i piastą są aprowizowane w tym samym regionie. Sieci w różnych regionach mogą prowadzić do problemów z opóźnieniami ze względu na przekroczenie granic regionalnych przez ruch, co może również wiązać się z dodatkowymi kosztami przepustowości.

• Charakterystykę obciążenia i wybory projektowe: przekaż swoje wybory projektowe, składniki i cechy zespołowi platformy. Jeśli na przykład oczekujesz, że obciążenie wygeneruje dużą liczbę współbieżnych połączeń z Internetem (czatty), zespół platformy powinien upewnić się, że istnieją wystarczające porty, aby zapobiec wyczerpaniu. Mogą dodawać adresy IP do scentralizowanej zapory w celu obsługi ruchu lub skonfigurować bramę translatora adresów sieciowych w celu kierowania ruchu przez alternatywną ścieżkę.

  Z drugiej strony, jeśli oczekujesz, że obciążenie będzie generować minimalny ruch sieciowy (szum w tle), zespół platformy powinien efektywnie korzystać z zasobów w całej organizacji.

  Zespół platformy musi jasno zrozumieć wszelkie zależności. Na przykład obciążenie może wymagać dostępu do bazy danych, która jest właścicielem innego zespołu, lub obciążenie może mieć ruch między środowiskami lokalnymi. Czy obciążenie ma zależności spoza platformy Azure? Takie informacje są ważne dla zespołu platformy, aby wiedzieć.

• Konfiguracja zapory: zespół platformy musi mieć świadomość ruchu, który opuszcza sieć szprych i jest tunelowany do sieci piasty. Zapora w centrum nie może zablokować tego ruchu.

  Jeśli na przykład obciążenie musi uzyskiwać dostęp do aktualizacji systemu Windows, aby zachować poprawki, zapora nie powinna blokować tych aktualizacji. Podobnie, jeśli istnieją agenci monitora, którzy uzyskują dostęp do określonych punktów końcowych, zapora nie powinna blokować tego ruchu, ponieważ może zakłócać monitorowanie danych dla obciążenia. Aplikacja może wymagać dostępu do punktów końcowych innych firm. Niezależnie od tego, użyj scentralizowanej zapory, aby odróżnić oczekiwany i nieuzasadniony ruch.

• Dostęp operatora: jeśli istnieją grupy zabezpieczeń identyfikatora Entra firmy Microsoft, które operatory używają do uzyskiwania dostępu do maszyn wirtualnych za pośrednictwem usługi Azure Bastion, poinformuj zespół platformy. Usługa Azure Bastion jest zazwyczaj zasobem centralnym. Niezwykle ważne jest zapewnienie, że grupy zabezpieczeń i maszyny wirtualne obsługują bezpieczny protokół.

  Ponadto poinformuj zespół platformy o zakresach adresów IP, które zawierają maszyny wirtualne. Te informacje są niezbędne do skonfigurowania sieciowych grup zabezpieczeń wokół usługi Azure Bastion w sieci piasty.

• Publiczne adresy IP: poinformuj zespół platformy o profilu ruchu przychodzącego, w tym o przewidywanych publicznych adresach IP. W tej architekturze tylko ruch internetowy jest kierowany do publicznego adresu IP w usłudze Application Gateway. Zespół ds. platformy powinien poinformować zespół ds. obciążeń, jeśli te adresy IP znajdują się w ramach planu usługi Azure DDoS Protection lub jeśli jest to odpowiedzialność zespołu ds. obciążeń.

  W tej architekturze istnieje inny publiczny adres IP umożliwiający dostęp operacyjny za pośrednictwem usługi Azure Bastion. Zespół platformy jest właścicielem tego publicznego adresu IP i jest zarejestrowany w usłudze, takiej jak DDoS Protection, którą zarządza również zespół platformy.

Opcje projektowania maszyny wirtualnej

Wybór jednostki SKU i dysku maszyny wirtualnej pozostaje taki sam jak architektura punktu odniesienia.

Organizacja może narzucić zespołowi obciążeń wymagania dotyczące zgodności, które wymusza korzystanie z określonych obrazów maszyn wirtualnych. Biorąc pod uwagę takie wymagania, zespół platformy może zarządzać zestawem standardowych obrazów, często nazywanych złotymi obrazami, które są tworzone do użytku w całej organizacji.

Zespół platformy może używać oferty zarządzanej, takiej jak Azure Compute Gallery lub repozytorium prywatne, do przechowywania zatwierdzonych obrazów systemu operacyjnego lub artefaktów obciążeń. Po wybraniu obrazu systemu operacyjnego dla maszyn wirtualnych skontaktuj się z zespołem platformy w zakresie źródeł obrazów, częstotliwości aktualizacji i oczekiwań dotyczących użycia. Upewnij się również, że obrazy mogą spełniać niezbędne wymagania biznesowe, które spełnia obciążenie.

Sieć

W architekturze bazowej obciążenie jest aprowidowane w jednej sieci wirtualnej. Zespół ds. obciążeń zarządza siecią wirtualną.

W tej architekturze zespół platformy określa topologię sieci. Topologia piasty i szprych jest zakładana w tej architekturze.

Pobierz plik programu Visio z tą architekturą.

• Sieć wirtualna koncentratora: centrum regionalne zawiera scentralizowane usługi komunikujące się z zasobami obciążenia w tym samym regionie. Aby uzyskać więcej informacji, zobacz Zasoby należące do zespołu platformy. Zalecamy umieszczenie centrum w subskrypcji łączności.

• Sieć wirtualna szprych: w tej architekturze pojedyncza sieć wirtualna z architektury bazowej jest siecią szprych. Jest ona równorzędna do sieci piasty, która zawiera scentralizowane usługi. Zespół platformy jest właścicielem tej sieci szprych i zarządza nią. Ta sieć zawiera zasoby obciążenia. Zespół ds. obciążeń jest właścicielem zasobów w tej sieci, w tym jej podsieci.

Upewnij się, że wymagania dotyczące obciążenia są przekazywane zespołowi platformy i okresowo je przeglądać.

Podsieci sieci wirtualnej

W sieci wirtualnej będącej szprychą zespół ds. obciążeń tworzy i przydziela podsieci. Umieszczenie kontrolek w celu ograniczenia ruchu do i z podsieci pomaga zapewnić segmentację. Ta architektura używa tej samej topologii podsieci co architektura punktu odniesienia, która ma dedykowane podsieci dla usługi Application Gateway, maszyn wirtualnych frontonu, modułu równoważenia obciążenia, maszyn wirtualnych zaplecza i prywatnych punktów końcowych.

Podczas wdrażania obciążenia w strefie docelowej platformy Azure nadal trzeba zaimplementować mechanizmy kontroli sieci. Organizacje mogą nakładać ograniczenia w celu ochrony przed eksfiltracją danych i zapewnić widoczność centralnego centrum operacji zabezpieczeń (SOC) i zespołu ds. sieci IT.

Dzięki temu zespół ds. platformy może zoptymalizować ogólne wydatki organizacyjne przy użyciu scentralizowanych usług, a nie wdrażać nadmiarowych mechanizmów kontroli zabezpieczeń dla każdego obciążenia w całej organizacji. W tej architekturze usługa Azure Firewall jest przykładem usługi centralnej. Nie jest to opłacalne ani praktyczne rozwiązanie dla każdego zespołu ds. obciążeń w celu zarządzania własnym wystąpieniem zapory. Zalecamy scentralizowane podejście do zarządzania zaporą.

Ruch przychodzący

Przepływ ruchu przychodzącego pozostaje taki sam jak architektura punktu odniesienia.

Właściciel obciążenia jest odpowiedzialny za wszelkie zasoby związane z publicznym dostępem internetowym do obciążenia. Na przykład w tej architekturze usługa Application Gateway i jej publiczny adres IP są umieszczane w sieci szprychy, a nie w sieci piasty. Niektóre organizacje mogą umieszczać zasoby z ruchem przychodzącym w subskrypcji łączności przy użyciu scentralizowanej implementacji demilitaryzowanej (DMZ). Integracja z tą konkretną topologią jest poza zakresem tego artykułu.

Ruch wychodzący

W architekturze bazowej zestawy skalowania maszyn wirtualnych obciążenia uzyskują dostęp do publicznego Internetu za pośrednictwem usługi Azure Load Balancer, ale ruch ten nie jest ograniczony.

Ten projekt różni się w tej architekturze. Cały ruch, który opuszcza sieć wirtualną szprychy, jest kierowany przez sieć koncentratora równorzędnego za pośrednictwem zapory ruchu wychodzącego. Trasa jest dołączona do wszystkich możliwych podsieci w sieci szprych, która kieruje cały ruch dla adresów IP nieznajdujących się w lokalnej sieci wirtualnej (0.0.0.0/0) do usługi Azure Firewall centrum.

Pobierz plik programu Visio z tą architekturą.

Komunikacja obciążenia z prywatnym punktem końcowym na potrzeby dostępu do usługi Key Vault pozostaje taka sama jak architektura punktu odniesienia. Ta ścieżka zostanie pominięta na powyższym diagramie w celu zwięzłości.

Zespół ds. obciążeń musi identyfikować, dokumentować i komunikować wszystkie niezbędne przepływy ruchu wychodzącego dla operacji infrastruktury i obciążeń. Zespół platformy zezwala na wymagany ruch, a cały ruch wychodzący bez polecenia prawdopodobnie zostanie odrzucony.

Kontrolowanie ruchu wychodzącego to nie tylko upewnienie się, że oczekiwany ruch będzie dozwolony. Chodzi również o upewnienie się, że dozwolony jest tylko oczekiwany ruch. Ruch wychodzący niekomunikowane jest prawdopodobnie domyślnie blokowany, ale najlepiej interesuje cię bezpieczeństwo obciążenia, aby upewnić się, że ruch jest prawidłowo kierowany.

Przekaż wszelkie unikatowe wymagania dotyczące ruchu wychodzącego do zespołu platformy. Jeśli na przykład obciążenie ustanawia wiele współbieżnych połączeń z zewnętrznymi punktami końcowymi sieci, poinformuj zespół platformy. Następnie zespół platformy może aprowizować odpowiednią implementację usługi Azure NAT Gateway lub dodać więcej publicznych adresów IP w regionalnej zaporze w celu ograniczenia ryzyka.

Twoja organizacja może mieć wymagania, które zniechęcają do używania wzorców architektury, które używają publicznych adresów IP należących do obciążeń na potrzeby ruchu wychodzącego. W takim przypadku można użyć usługi Azure Policy do odmowy publicznych adresów IP na kartach interfejsu sieciowego maszyny wirtualnej i innych publicznych adresach IP, innych niż znane punkty ruchu przychodzącego.

Prywatne strefy DNS

Architektury korzystające z prywatnych punktów końcowych wymagają prywatnych stref DNS do pracy z dostawcą DNS. Zespół ds. obciążeń musi mieć jasne zrozumienie wymagań i zarządzania prywatnymi strefami DNS w ramach subskrypcji zapewnianej przez zespół platformy. Prywatna strefa DNS strefy są zwykle zarządzane na dużą skalę przy użyciu zasad DINE, co umożliwia usłudze Azure Firewall działanie jako niezawodnego serwera proxy DNS i obsługę w pełni kwalifikowanych reguł sieciowych nazw domen (FQDN).

W tej architekturze zespół platformy zapewnia niezawodne rozpoznawanie prywatnych nazw DNS dla punktów końcowych łącza prywatnego. Współpracuj z zespołem ds. platformy, aby zrozumieć ich oczekiwania.

testowanie Połączenie ivity

W przypadku architektur opartych na maszynach wirtualnych istnieje kilka narzędzi testowych, które mogą pomóc w określeniu problemów z siecią, routingiem i systemem DNS. Możesz użyć tradycyjnych narzędzi do rozwiązywania problemów, takich jak netstat, nslookuplub tcping. Ponadto można sprawdzić ustawienia protokołu DHCP (Dynamic Host Configuration Protocol) i DNS karty sieciowej. Jeśli istnieją karty sieciowe, masz więcej możliwości rozwiązywania problemów, które umożliwiają przeprowadzanie kontroli łączności przy użyciu usługi Azure Network Watcher.

Dostęp operatora

Podobnie jak architektura punktu odniesienia, dostęp operacyjny za pośrednictwem usługi Azure Bastion jest obsługiwany w tej architekturze.

Jednak architektura punktu odniesienia wdraża usługę Azure Bastion w ramach obciążenia. W przypadku typowej organizacji, która przyjmuje strefy docelowe platformy Azure, wdrażają usługę Azure Bastion jako zasoby centralne dla każdego regionu. Zespół platformy jest właścicielem usługi Azure Bastion i obsługuje usługę Azure Bastion, a wszystkie obciążenia w organizacji je współużytkuje. Aby zademonstrować ten przypadek użycia w tej architekturze, usługa Azure Bastion znajduje się w sieci piasty w subskrypcji łączności.

Tożsamość operatora

Ta architektura używa tego samego rozszerzenia uwierzytelniania co architektura punktu odniesienia.

Zawsze zacznij od zasady najniższych uprawnień i szczegółowego dostępu do zadania zamiast długotrwałego dostępu. W kontekście strefy docelowej skorzystaj z obsługi typu just in time (JIT), którą zarządza zespół platformy.

Poprawki zgodności i uaktualnienia systemu operacyjnego

Architektura linii bazowej opisuje autonomiczne podejście do stosowania poprawek i uaktualnień. Gdy obciążenie jest zintegrowane ze strefami docelowymi, takie podejście może ulec zmianie. Zespół platformy może dyktować operacje stosowania poprawek, aby wszystkie obciążenia spełniały wymagania organizacyjne.

Upewnij się, że proces stosowania poprawek zawiera wszystkie składniki dodawane do architektury. Jeśli na przykład zdecydujesz się dodać maszyny wirtualne agenta kompilacji w celu zautomatyzowania wdrażania, skalowania i zarządzania aplikacjami, te maszyny wirtualne muszą spełniać wymagania dotyczące platformy.

Monitorowanie

Platforma strefy docelowej platformy Azure zapewnia współużytkowane zasoby umożliwiające obserwowanie w ramach subskrypcji zarządzania. Zalecamy jednak aprowizowanie własnych zasobów monitorowania w celu ułatwienia odpowiedzialności za własność obciążenia. Takie podejście jest zgodne z architekturą punktu odniesienia.

Zespół ds. obciążeń aprowizuje zasoby monitorowania, w tym:

• Aplikacja Szczegółowe informacje jako usługa monitorowania wydajności aplikacji (APM) dla zespołu obciążenia.

• Obszar roboczy usługi Log Analytics jako ujednolicony ujście dla wszystkich dzienników i metryk zbieranych z zasobów platformy Azure należących do obciążenia i kodu aplikacji.

Pobierz plik programu Visio z tą architekturą.

Podobnie jak w przypadku planu bazowego, wszystkie zasoby są skonfigurowane do wysyłania dzienników Diagnostyka Azure do obszaru roboczego usługi Log Analytics, który zespół obciążenia aprowizuje jako część wdrożenia infrastruktury jako kodu (IaC) zasobów. Może być również konieczne wysłanie dzienników do centralnego obszaru roboczego usługi Log Analytics. W strefach docelowych platformy Azure ten obszar roboczy znajduje się w subskrypcji zarządzania.

Zespół platformy może również mieć zasady DINE, których mogą używać do konfigurowania diagnostyki w celu wysyłania dzienników do scentralizowanych subskrypcji zarządzania. Ważne jest, aby upewnić się, że implementacja nie ogranicza dodatkowych przepływów dziennika.

Korelowanie danych z wielu ujściów

Dzienniki i metryki obciążenia oraz jego składniki infrastruktury są przechowywane w obszarze roboczym usługi Log Analytics obciążenia. Jednak dzienniki i metryki, które scentralizowane usługi, takie jak Azure Firewall, Microsoft Entra ID i Azure Bastion, są przechowywane w centralnym obszarze roboczym usługi Log Analytics. Korelacja danych z wielu ujść może być złożonym zadaniem.

Skorelowane dane są często używane podczas reagowania na zdarzenia. Jeśli występuje problem z korelowaniem danych z wielu ujściów, upewnij się, że element Runbook klasyfikacji dla tej architektury rozwiązuje ten problem i uwzględnia punkty organizacyjne kontaktu, jeśli problem wykracza poza zasoby obciążenia. Administratorzy obciążeń mogą wymagać pomocy od administratorów platformy w celu skorelowania wpisów dziennika z sieci, zabezpieczeń lub innych usług platformy w przedsiębiorstwie.

Azure Policy

Zespół platformy prawdopodobnie stosuje zasady wpływające na wdrożenie obciążenia. Często stosują zasady DINE do obsługi wdrożeń automatycznych w subskrypcji strefy docelowej aplikacji. Zasady DINE mogą modyfikować zasoby obciążenia lub dodawać zasoby do wdrożenia, co może spowodować rozbieżność między zasobami, które są deklaratywne wdrażane za pośrednictwem szablonu obciążenia i zasobów, z których rzeczywiście korzystają żądania przetwarzania. Typowym rozwiązaniem jest naprawienie tych zmian za pomocą metod imperatywnych, które nie są idealne.

Aby uniknąć tej rozbieżności, z góry uwzględnij i przetestuj zmiany inicjowane przez platformę w szablonach IaC. Jeśli zespół platformy korzysta z zasad platformy Azure, które powodują konflikt z wymaganiami aplikacji, możesz wynegocjować rozwiązanie z zespołem platformy.

Zarządzanie zmianami w czasie

Usługi i operacje udostępniane przez platformę są uznawane za zależności zewnętrzne w tej architekturze. Zespół platformy nadal stosuje zmiany, dołącza użytkowników i stosuje mechanizmy kontroli kosztów. Zespół platformy obsługujący organizację może nie określać priorytetów poszczególnych obciążeń. Zmiany tych zależności, niezależnie od tego, czy są to zmiany złotego obrazu, modyfikacje zapory, automatyczne stosowanie poprawek czy zmiany reguł, mogą mieć wpływ na wiele obciążeń.

W związku z tym zespoły ds. obciążeń i platform muszą efektywnie i terminowo komunikować się, aby zarządzać wszystkimi zależnościami zewnętrznymi. Ważne jest przetestowanie zmian, więc nie mają negatywnego wpływu na obciążenia.

Zmiany platformy wpływające na obciążenie

W tej architekturze zespół platformy zarządza następującymi zasobami. Zmiany w tych zasobach mogą potencjalnie wpływać na niezawodność, zabezpieczenia, operacje i cele wydajności obciążenia. Ważne jest, aby ocenić te zmiany, zanim zespół platformy włoży je w życie, aby określić, jak wpływają one na obciążenie.

• Zasady platformy Azure: zmiany zasad platformy Azure mogą mieć wpływ na zasoby obciążeń i ich zależności. Na przykład mogą istnieć bezpośrednie zmiany zasad lub przenoszenie strefy docelowej do nowej hierarchii grup zarządzania. Te zmiany mogą pozostać niezauważone, dopóki nie zostanie wprowadzone nowe wdrożenie, dlatego ważne jest, aby dokładnie je przetestować.

• Reguły zapory: modyfikacje reguł zapory mogą mieć wpływ na sieć wirtualną obciążenia lub reguły, które mają zastosowanie szeroko we wszystkich ruchach. Te modyfikacje mogą spowodować zablokowany ruch, a nawet dyskretne błędy procesów, takie jak nieudane stosowanie poprawek systemu operacyjnego. Te potencjalne problemy dotyczą zarówno wychodzących zapór platformy Azure, jak i reguł sieciowej grupy zabezpieczeń stosowanej przez usługę Azure Virtual Network Manager.

• Zasoby udostępnione: zmiany w jednostce SKU lub funkcjach zasobów udostępnionych mogą mieć wpływ na obciążenie.

• Routing w sieci piasty: zmiany w przejściowym charakterze routingu w centrum mogą potencjalnie wpłynąć na funkcjonalność obciążenia, jeśli obciążenie zależy od routingu do innych sieci wirtualnych.

• Host usługi Azure Bastion: zmiany dostępności lub konfiguracji hosta usługi Azure Bastion mogą mieć wpływ na operacje obciążeń. Upewnij się, że zmiany wzorca dostępu do serwera przesiadkowego mają obowiązującą procedurę, ad hoc i dostęp awaryjny.

• Zmiany własności: poinformuj o wszelkich zmianach własności i punktach kontaktu z zespołem obciążeń, ponieważ mogą one wpływać na żądania zarządzania i pomocy technicznej obciążenia.

Zmiany obciążenia wpływające na platformę

Poniższe przykłady to zmiany obciążenia w tej architekturze, które należy przekazać zespołowi platformy. Ważne jest, aby zespół platformy weryfikował niezawodność, zabezpieczenia, operacje i cele wydajności usługi platformy przed wprowadzeniem zmian w nowym zespole obciążeń.

• Ruch wychodzący sieci: monitoruj znaczny wzrost ruchu wychodzącego sieci, aby zapobiec utracie hałaśliwego sąsiada na urządzeniach sieciowych. Ten problem może potencjalnie mieć wpływ na cele wydajności lub niezawodności innych obciążeń.

• Dostęp publiczny: zmiany w publicznym dostępie do składników obciążenia mogą wymagać dalszego testowania. Zespół platformy może przenieść obciążenie do innej grupy zarządzania.

• Ocena krytycznej działalności biznesowej: jeśli istnieją zmiany umów dotyczących poziomu usług (SLA) obciążenia, może być konieczne nowe podejście współpracy między zespołami platformy i obciążeń.

• Zmiany własności: przekazywanie zmian własności i punktów kontaktowych zespołowi platformy.

Zmiany wymagań biznesowych obciążeń

Aby zachować cele poziomu usług (SLO) obciążenia, zespół platformy może być zaangażowany w zmiany architektury obciążenia. Te zmiany mogą wymagać zarządzania zmianami od zespołu platformy lub weryfikacji, że istniejący ład obsługuje zmienione wymagania.

Na przykład przekaż zmiany w dowolnym wcześniej niedozwolonym przepływie ruchu wychodzącego, aby zespół platformy mógł dodać ten przepływ w zaporze, menedżerze sieci wirtualnej lub innych składnikach w celu obsługi wymaganego ruchu. Z drugiej strony, jeśli wcześniej dozwolony przepływ ruchu wychodzącego nie jest już potrzebny, zespół platformy powinien zablokować ten przepływ w celu zachowania zabezpieczeń obciążenia. Ponadto komunikują zmiany routingu z innymi sieciami wirtualnymi lub punktami końcowymi między lokalnymi lub zmianami w składnikach architektury. Każdy zasób podlega zasadom i potencjalnie kontrolce zapory ruchu wychodzącego.

Niezawodność

Ta architektura jest zgodna z gwarancjami niezawodności w architekturze punktu odniesienia.

Cele dotyczące niezawodności

Maksymalna możliwa złożona cel slo jest niższa niż punkt odniesienia złożonego celu slo ze względu na składniki, takie jak kontrola sieci ruchu wychodzącego. Te składniki, wspólne w środowiskach strefy docelowej, nie są unikatowe dla tej architektury. Cel slo jest podobnie zmniejszony, jeśli zespół obciążenia bezpośrednio kontroluje te usługi platformy Azure.

Pomimo niższego możliwego celu slo kluczowego aspektu niezawodności jest podział składników obciążenia między zespoły funkcjonalne. Dzięki tej metodzie zespół ds. obciążeń korzysta z wyspecjalizowanego zespołu, który koncentruje się na infrastrukturze krytycznej dla działania używanej przez to obciążenie i inne obciążenia.

Aby uzyskać więcej informacji, zobacz Rekomendacje na potrzeby definiowania celów niezawodności.

Zależności krytyczne

Wyświetl wszystkie funkcje wykonywane przez obciążenie w strefie docelowej platformy i aplikacji jako zależności. Plany reagowania na zdarzenia wymagają, aby zespół ds. obciążeń wiedział o punkcie i metodzie informacji kontaktowych dotyczących tych zależności. Uwzględnij również te zależności w analizie trybu awarii obciążenia (FMA).

W przypadku tej architektury należy wziąć pod uwagę następujące zależności:

• Zapora ruchu wychodzącego: scentralizowana zapora ruchu wychodzącego współużytkowana przez wiele obciążeń przechodzi zmiany niepowiązane z obciążeniem.

• Wyczerpanie portów sieciowych: skoki użycia ze wszystkich obciążeń współużytkowania urządzenia sieciowego mogą prowadzić do nasycenia sieci lub wyczerpania portów w zaporze ruchu wychodzącego.

• Zasady DINE: zasady DINE dla prywatnych stref DNS usługi Azure DNS (lub innych zależności udostępnianych przez platformę) są najlepszym rozwiązaniem, bez umowy SLA dotyczącej wykonywania. Opóźnienie konfiguracji DNS może spowodować opóźnienia w gotowości aplikacji do obsługi ruchu.

• Zasady grupy zarządzania: spójne zasady między środowiskami mają kluczowe znaczenie dla niezawodności. Upewnij się, że środowiska przedprodukcyjne są podobne do środowisk produkcyjnych, aby zapewnić dokładne testowanie i zapobiec odchyleniu specyficznym dla środowiska, które mogą blokować wdrożenie lub skalę. Aby uzyskać więcej informacji, zobacz Zarządzanie środowiskami projektowymi aplikacji w strefach docelowych platformy Azure.

Wiele z tych zagadnień może istnieć bez stref docelowych platformy Azure, ale zespoły ds. obciążeń i platform muszą wspólnie rozwiązywać te problemy, aby zapewnić spełnienie wymagań.

Aby uzyskać więcej informacji, zobacz Rekomendacje na potrzeby przeprowadzania analizy trybu awarii.

Zabezpieczenia

Zagadnienia dotyczące zabezpieczeń tej architektury są przenoszone z architektury bazowej. Zalecenia opisane w poniższych sekcjach są oparte na liście kontrolnej przeglądu projektu zabezpieczeń w strukturze Well-Architected Framework.

Formanty sieciowe

Poprawnie skonfiguruj mechanizmy kontroli sieci, aby upewnić się, że obciążenie jest bezpieczne.

Ruch przychodzący

Obciążenie można odizolować od innych szprych obciążeń w organizacji za pośrednictwem sieciowych grup zabezpieczeń w podsieciach lub nieprzejętnego charakteru lub kontrolek w centrum regionalnym. Konstruowanie kompleksowych sieciowych grup zabezpieczeń, które zezwalają tylko na wymagania dotyczące sieci przychodzącej aplikacji i jej infrastruktury. Zalecamy, aby nie polegać wyłącznie na nieprzejaśnianiu sieci koncentratora w celu zapewnienia bezpieczeństwa.

Zespół platformy prawdopodobnie implementuje zasady platformy Azure, aby upewnić się, że usługa Application Gateway ma zaporę aplikacji internetowej ustawioną na tryb odmowy, aby ograniczyć liczbę publicznych adresów IP dostępnych dla twojej subskrypcji i innych kontroli. Oprócz tych zasad zespół ds. obciążeń powinien być właścicielem obowiązków związanych z wdrażaniem zasad skoncentrowanych na obciążeniach, które wzmacniają stan zabezpieczeń ruchu przychodzącego.

W poniższej tabeli przedstawiono przykłady kontrolek ruchu przychodzącego w tej architekturze.

Źródło	Purpose	Kontrola obciążenia	Kontrolka platformy
Internet	Przepływy ruchu użytkowników	Lejki wszystkie żądania za pośrednictwem sieciowej grupy zabezpieczeń, zapory aplikacji internetowej i reguł routingu przed zezwoleniem na przejście ruchu publicznego do ruchu prywatnego, który przechodzi do maszyn wirtualnych frontonu	Brak
Azure Bastion	Dostęp operatora do maszyn wirtualnych	Sieciowa grupa zabezpieczeń w podsieciach maszyn wirtualnych, która blokuje cały ruch do portów dostępu zdalnego, chyba że jest ona źródłowa z wyznaczonej podsieci usługi Azure Bastion	Brak
Inne szprychy	Brak	Zablokowane za pośrednictwem reguł sieciowej grupy zabezpieczeń	Routing nietransitive lub reguły usługi Azure Firewall w przypadku koncentratora zabezpieczonego przez wirtualną sieć WAN platformy Azure

Ruch wychodzący

Zastosuj reguły sieciowej grupy zabezpieczeń, które wyrażają wymagane wymagania dotyczące łączności wychodzącej rozwiązania i odrzucają wszystkie inne elementy. Nie należy polegać tylko na kontrolkach sieci piasty. Jako operator obciążenia ponosisz odpowiedzialność za zatrzymanie niepożądanego ruchu wychodzącego tak blisko źródła, jak to możliwe.

Należy pamiętać, że gdy jesteś właścicielem podsieci w sieci wirtualnej, zespół platformy prawdopodobnie utworzył reguły zapory, aby w szczególności reprezentować przechwycone wymagania w ramach procesu sprzedaż abonamentów. Upewnij się, że zmiany w podsieciach i umieszczaniu zasobów w okresie istnienia architektury są nadal zgodne z oryginalnym żądaniem. Możesz też współpracować z zespołem ds. sieci, aby zapewnić ciągłość kontroli ruchu wychodzącego o najmniejszym dostępie.

W poniższej tabeli przedstawiono przykłady ruchu wychodzącego w tej architekturze.

Punkt końcowy	Purpose	Kontrolka obciążenia (NSG)	Kontrolka platformy (koncentratora)
ntp.ubuntu.com	Protokół NTP (Network Time Protocol) dla maszyn wirtualnych z systemem Linux	UDP/123 do Internetu w podsieci maszyny wirtualnej frontonu (zapora ruchu wychodzącego zawęża to szerokie otwarcie)	Zasiłek dla reguły sieciowej zapory dla tej samej kontrolki obciążenia
Punkty końcowe usługi Windows Update	Funkcje usługi Windows Update z serwerów firmy Microsoft	Tcp/443 i TCP/80 do Internetu w podsieci maszyny wirtualnej zaplecza (zapora ruchu wychodzącego zawęża to szerokie otwarcie)	Reguła limitu zapory z tagiem FQDN WindowsUpdate
Monitorowanie punktów końcowych agenta	Wymagany ruch dla rozszerzenia Monitor na maszynach wirtualnych	Protokół TCP/443 do Internetu w obu podsieciach maszyn wirtualnych (zapora ruchu wychodzącego zawęża to szerokie otwarcie)	Niezbędne przydziały reguł aplikacji zapory dla wszystkich określonych nazw FQDN na tcp /443
nginx.org	Aby zainstalować serwer Nginx (przykładowy składnik aplikacji) bezpośrednio od dostawcy	Protokół TCP/443 do Internetu w podsieci maszyny wirtualnej frontonu (zapora ruchu wychodzącego zawęża to szerokie otwarcie)	Wymagany zasiłek reguły aplikacji zapory dla nginx.org na tcp /443
Key Vault	Aby zaimportować (Transport Layer Security) certyfikaty TLS w usłudze Application Gateway i maszynach wirtualnych	- TCP/443 do podsieci prywatnego punktu końcowego z obu podsieci maszyn wirtualnych do podsieci prywatnego punktu końcowego - PROTOKÓŁ TCP/443 do podsieci prywatnego punktu końcowego z podsieci usługi Application Gateway - Protokół TCP/443 z maszyn wirtualnych oznaczonych wymaganym oznaczeniem grupy zabezpieczeń aplikacji (ASG) i podsiecią usługi Application Gateway	Brak

Ochrona przed atakami DDoS

Ustal, kto jest odpowiedzialny za zastosowanie planu usługi DDoS Protection, który obejmuje wszystkie publiczne adresy IP rozwiązania. Zespół platformy może używać planów ochrony adresów IP lub nawet użyć usługi Azure Policy do wymuszania planów ochrony sieci wirtualnej. Ta architektura powinna mieć pokrycie, ponieważ obejmuje publiczny adres IP dla ruchu przychodzącego z Internetu.

Aby uzyskać więcej informacji, zobacz Rekomendacje dotyczące sieci i łączności.

Zarządzanie wpisami tajnymi

W przypadku zarządzania wpisami tajnymi ta architektura jest zgodna z architekturą punktu odniesienia.

Jako zespół ds. obciążeń kontynuuj przechowywanie wpisów tajnych w wystąpieniu usługi Key Vault. Wdróż więcej wystąpień zgodnie z potrzebami, aby obsługiwać operacje aplikacji i infrastruktury.

Aby uzyskać więcej informacji, zobacz Rekomendacje na potrzeby ochrony wpisów tajnych aplikacji.

Optymalizacja kosztów

W przypadku zasobów obciążeń strategie optymalizacji kosztów w architekturze punktu odniesienia mają również zastosowanie do tej architektury.

Ta architektura znacznie korzysta z zasobów platformy docelowej platformy Azure. Nawet jeśli używasz tych zasobów za pośrednictwem modelu obciążenia zwrotnego, dodatkowe zabezpieczenia i łączność między lokalizacjami są bardziej ekonomiczne niż samodzielne zarządzanie tymi zasobami.

Zespół platformy zarządza następującymi zasobami w tej architekturze. Te zasoby są często oparte na użyciu (obciążenie zwrotne) lub potencjalnie bezpłatne dla zespołu ds. obciążeń.

• Azure Firewall
• Zarządzanie informacjami o zabezpieczeniach i zdarzeniami (SIEM)
• Hosty usługi Azure Bastion
• Łączność między lokalizacjami, na przykład ExpressRoute

Skorzystaj z innych scentralizowanych ofert od zespołu platformy, aby rozszerzyć te korzyści na obciążenie bez naruszania celu SLO, celu czasu odzyskiwania (RTO) lub celu punktu odzyskiwania (RPO).

Aby uzyskać więcej informacji, zobacz Rekomendacje na potrzeby zbierania i przeglądania danych kosztów.

Wdrażanie tego scenariusza

Wdrożenie tej architektury referencyjnej jest dostępne w usłudze GitHub.

Następny krok

Zapoznaj się ze szczegółami współpracy i technicznymi udostępnionymi między zespołami ds. obciążeń i zespołami platformy.

Subskrypcja z automatem