Ten artykuł zawiera podstawową architekturę referencyjną dla obciążenia wdrożonego na maszynach wirtualnych platformy Azure.
Przykładowe obciążenie zakładane przez tę architekturę jest wielowarstwową aplikacją internetową, która jest wdrażana na oddzielnych zestawach maszyn wirtualnych. Maszyny wirtualne są aprowizowane w ramach wdrożeń usługi Azure Virtual Machine Scale Sets. Tej architektury można używać w następujących scenariuszach:
- Aplikacje prywatne. Aplikacje te obejmują wewnętrzne aplikacje biznesowe lub komercyjne rozwiązania poza półki.
- Aplikacje publiczne. Te aplikacje są aplikacjami dostępnymi z Internetu. Ta architektura nie jest przeznaczony dla obliczeń o wysokiej wydajności, obciążeń o znaczeniu krytycznym, aplikacji o dużym wpływie na opóźnienia ani innych wyspecjalizowanych przypadków użycia.
Głównym celem tej architektury nie jest aplikacja. Zamiast tego ten artykuł zawiera wskazówki dotyczące konfigurowania i wdrażania składników infrastruktury, z którymi współdziała aplikacja. Składniki te obejmują składniki obliczeniowe, magazynowe, sieciowe i monitorujące.
Ta architektura służy jako punkt wyjścia dla obciążenia hostowanego przez infrastrukturę jako usługę (IaaS). Warstwa danych jest celowo wykluczona z tych wskazówek, aby zachować nacisk na infrastrukturę obliczeniową.
Układ artykułu
| Architektura | Decyzja projektowa | Dobrze zaprojektowane podejście do struktury |
|---|---|---|
| ▪ Diagram architektury ▪ Zasoby obciążenia ▪ Zasoby pomocnicze ▪ Przepływy użytkownika |
▪ Opcje projektowania maszyny wirtualnej ▪ Dysków ▪ Sieci ▪ Monitorowania ▪ Zarządzanie aktualizacjami |
▪ Niezawodność ▪ Zabezpieczeń ▪ Optymalizacja kosztów |
Napiwek
Ta implementacja referencyjna przedstawia najlepsze rozwiązania opisane w tym artykule.
Implementacja obejmuje aplikację, która jest małym testem, aby przećwiczyć konfigurację infrastruktury od końca do końca.
Architektura
Pobierz plik programu Visio z tą architekturą.
Aby uzyskać informacje o tych zasobach, zobacz dokumentację produktu platformy Azure wymienioną w temacie Powiązane zasoby.
Elementy
Ta architektura składa się z kilku usług platformy Azure dla zasobów obciążeń i zasobów pomocniczych obciążeń. Usługi dla każdej i ich ról opisano w poniższych sekcjach.
Zasoby obciążenia
Usługa Azure Virtual Machines służy jako zasób obliczeniowy dla aplikacji i jest dystrybuowana w różnych strefach dostępności. W celach ilustracyjnych jest używana kombinacja maszyn wirtualnych z systemami Windows i Linux.
Zestawy skalowania maszyn wirtualnych platformy Azure w trybie elastycznej aranżacji służą do aprowizowania maszyn wirtualnych i zarządzania nimi.
Przykładowa aplikacja może być reprezentowana w dwóch warstwach, z których każda wymaga własnych obliczeń.
- Fronton uruchamia serwer internetowy i odbiera żądania użytkowników.
- Zaplecze uruchamia inny serwer internetowy działający jako internetowy interfejs API, który uwidacznia pojedynczy punkt końcowy, w którym jest wykonywana logika biznesowa.
Maszyny wirtualne frontonu mają dołączone dyski danych (Premium_LRS), których można użyć do wdrożenia aplikacji bezstanowej. Maszyny wirtualne zaplecza utrwalają dane w celu Premium_ZRS dysków lokalnych w ramach operacji. Ten układ można rozszerzyć w celu uwzględnienia warstwy bazy danych na potrzeby przechowywania stanu z obliczeń frontonu i zaplecza. Ta warstwa wykracza poza zakres tej architektury.
Usługa Azure Virtual Network udostępnia sieć prywatną dla wszystkich zasobów obciążeń. Sieć jest podzielona na podsieci, które służą jako granice izolacji.
aplikacja systemu Azure Gateway to pojedynczy punkt ruchu przychodzącego, który kieruje żądania do serwerów frontonu. Wybrana jednostka SKU obejmuje zintegrowaną zaporę aplikacji internetowej platformy Azure (WAF) na potrzeby dodanych zabezpieczeń.
Wewnętrzny moduł równoważenia obciążenia platformy Azure kieruje ruch z warstwy frontonu do serwerów zaplecza.
Jednostka SKU usługi Azure Load Balancer w warstwie Standardowa zapewnia wychodzący dostęp do Internetu do maszyn wirtualnych przy użyciu trzech publicznych adresów IP.
Usługa Azure Key Vault przechowuje certyfikaty używane do kompleksowej komunikacji z zabezpieczeniami warstwy transportu (TLS). Może być również używany do obsługi wpisów tajnych aplikacji.
Obciążenie pomocnicze zasobów
Usługa Azure Bastion zapewnia dostęp operacyjny do maszyn wirtualnych za pośrednictwem bezpiecznych protokołów.
Aplikacja Szczegółowe informacje zbiera dzienniki i metryki z aplikacji. Ponieważ aplikacja nie koncentruje się na tej architekturze, zbieranie dzienników nie jest pokazane w implementacji.
Usługa Log Analytics to ujście danych monitorowania, które zbiera dzienniki i metryki z zasobów platformy Azure i Szczegółowe informacje aplikacji. Konto magazynu jest aprowidowane w ramach obszaru roboczego.
Przepływy użytkowników
Istnieją dwa typy użytkowników, którzy wchodzą w interakcję z zasobami obciążenia: użytkownik i operator obciążenia. Przepływy dla tych użytkowników są wyświetlane na powyższym diagramie architektury.
Użytkownik obciążenia
Użytkownik uzyskuje dostęp do witryny internetowej przy użyciu uwidocznionego publicznego adresu IP usługi Application Gateway.
Usługa Application Gateway odbiera ruch HTTPS, odszyfrowuje dane przy użyciu certyfikatu zewnętrznego na potrzeby inspekcji zapory aplikacji internetowej i ponownie szyfruje go przy użyciu wewnętrznego certyfikatu wieloznacznych na potrzeby transportu do frontonu.
Usługa Application Gateway równoważy ruch między maszynami wirtualnymi frontonu i przekazuje żądanie do maszyny wirtualnej frontonu.
Wybrana maszyna wirtualna frontonu komunikuje się z maszyną wirtualną zaplecza przy użyciu prywatnego adresu IP modułu równoważenia obciążenia, a nie adresu IP żadnej pojedynczej maszyny wirtualnej. Ta komunikacja jest również szyfrowana przy użyciu wewnętrznego certyfikatu wieloznacznych.
Maszyna wirtualna zaplecza odszyfrowuje żądanie przy użyciu certyfikatu wewnętrznego. Gdy zaplecze przetwarza żądanie, zwraca wynik do frontonu, który zwraca wynik do bramy aplikacji, a na koniec zwraca wynik do użytkownika.
Operator
Maszyny wirtualne w tej architekturze mogą wymagać bezpośredniego dostępu przez operatorów, ale zalecamy zminimalizowanie dostępu zdalnego przez automatyzację i monitorowanie dostępu. Dostęp może dotyczyć sytuacji, w których rozwiązane problemy, rozwiązywanie problemów lub część zautomatyzowanego procesu wdrażania. Ta architektura nie ma publicznych adresów IP na potrzeby dostępu do płaszczyzny sterowania. Usługa Azure Bastion działa jako brama bezserwerowa, umożliwiając operacjom uzyskiwanie dostępu do maszyn wirtualnych za pośrednictwem protokołu SSH lub RDP. Ta konfiguracja zapewnia bezpieczne i wydajne zarządzanie dostępem.
- Operator loguje się do witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure.
- Operator uzyskuje dostęp do usługi Azure Bastion i zdalnie nawiązuje połączenie z żądaną maszyną wirtualną.
Opcje projektowania maszyny wirtualnej
Podczas wybierania jednostek SKU ważne jest, aby mieć oczekiwania dotyczące wydajności według planu bazowego. Kilka cech wpływa na proces podejmowania decyzji, w tym:
- Procesor CPU, pamięć i operacje wejścia/wyjścia dysku na sekundę (IOPS).
- Architektura procesorów.
- Rozmiar obrazu systemu operacyjnego.
Jeśli na przykład migrujesz obciążenie ze środowiska lokalnego, które wymaga maszyn procesora Intel, wybierz jednostki SKU maszyn wirtualnych, które obsługują procesory Intel.
Aby uzyskać informacje o obsługiwanych jednostkach SKU maszyn wirtualnych, zobacz Rozmiary maszyn wirtualnych na platformie Azure.
Bootstrap
Maszyny wirtualne często muszą być uruchamiane, co jest procesem, w którym maszyny wirtualne są przygotowane i dostrojone do uruchamiania aplikacji. Typowe zadania uruchamiania obejmują instalowanie certyfikatów, konfigurowanie dostępu zdalnego, instalowanie pakietów, dostrajanie i wzmacnianie konfiguracji systemu operacyjnego oraz formatowanie i instalowanie dysków danych. Ważne jest, aby jak najwięcej zautomatyzować proces uruchamiania aplikacji, aby aplikacja mogła uruchamiać się na maszynie wirtualnej bez opóźnień lub ręcznej interwencji. Poniżej przedstawiono zalecenia dotyczące automatyzacji:
Rozszerzenia maszyny wirtualnej. Te rozszerzenia to obiekty usługi Azure Resource Manager zarządzane za pomocą wdrożenia infrastruktury jako kodu (IaC). W ten sposób wszelkie błędy są zgłaszane jako wdrożenie, w którym można podjąć działania. Jeśli nie ma rozszerzenia na potrzeby uruchamiania, utwórz skrypty niestandardowe. Zaleca się uruchamianie skryptów za pośrednictwem rozszerzenia niestandardowego skryptu platformy Azure.
Poniżej przedstawiono inne rozszerzenia, których można użyć do automatycznego instalowania lub konfigurowania funkcji na maszynach wirtualnych.
- Agent usługi Azure Monitor (AMA) zbiera dane monitorowania z systemu operacyjnego gościa i dostarcza je do usługi Azure Monitor.
- Rozszerzenie niestandardowego skryptu platformy Azure (Windows, Linux) w wersji 2 pobiera i uruchamia skrypty na maszynach wirtualnych platformy Azure. To rozszerzenie jest przydatne do automatyzacji konfiguracji po wdrożeniu, instalacji oprogramowania lub innych zadań konfiguracji lub zarządzania.
- Rozszerzenie maszyny wirtualnej usługi Azure Key Vault (Windows, Linux) zapewnia automatyczne odświeżanie certyfikatów przechowywanych w usłudze Key Vault przez wykrywanie zmian i instalowanie odpowiednich certyfikatów.
- Rozszerzenie application Health z zestawami skalowania maszyn wirtualnych jest ważne, gdy usługa Azure Virtual Machine Scale Sets wykonuje automatyczne uaktualnienia stopniowe. Platforma Azure korzysta z monitorowania kondycji poszczególnych wystąpień w celu wykonania aktualizacji. Za pomocą rozszerzenia można również monitorować kondycję aplikacji każdego wystąpienia w zestawie skalowania i wykonywać naprawy wystąpień przy użyciu automatycznych napraw wystąpień.
- Microsoft Entra ID i OpenSSH (Windows, Linux) integrują się z uwierzytelnianiem firmy Microsoft Entra. Teraz możesz użyć identyfikatora Entra firmy Microsoft jako podstawowej platformy uwierzytelniania i urzędu certyfikacji do protokołu SSH na maszynie wirtualnej z systemem Linux przy użyciu uwierzytelniania opartego na certyfikatach Microsoft Entra ID i OpenSSH. Ta funkcja umożliwia zarządzanie dostępem do maszyn wirtualnych przy użyciu kontroli dostępu opartej na rolach (RBAC) platformy Azure i zasad dostępu warunkowego.
Konfiguracja oparta na agencie. Maszyny wirtualne z systemem Linux mogą używać uproszczonej natywnej konfiguracji żądanego stanu dostępnej za pośrednictwem pakietu cloud-init na różnych obrazach maszyn wirtualnych udostępnianych na platformie Azure. Konfiguracja jest określona i wersjonowana za pomocą artefaktów IaC. Wprowadzenie własnego rozwiązania do zarządzania konfiguracją jest innym sposobem. Większość rozwiązań stosuje podejście deklaratywne do uruchamiania, ale obsługuje niestandardowe skrypty w celu zapewnienia elastyczności. Popularne opcje to Desired State Configuration for Windows, Desired State Configuration for Linux, Ansible, Chef, Puppet i inne. Wszystkie te rozwiązania konfiguracyjne można połączyć z rozszerzeniami maszyn wirtualnych w celu uzyskania najlepszego środowiska.
W implementacji referencyjnej wszystkie bootstrapping odbywa się za pomocą rozszerzeń maszyn wirtualnych i skryptów niestandardowych, w tym niestandardowego skryptu do automatyzowania formatowania i instalowania dysku danych.
Zapoznaj się z tematem Well-Architected Framework: RE:02 - Rekomendacje w celu projektowania automatyzacji.
Łączność z maszyną wirtualną
Aby umożliwić prywatną komunikację między maszyną wirtualną a innymi urządzeniami w określonej sieci wirtualnej, karta interfejsu sieciowego maszyny wirtualnej jest połączona z jedną z podsieci sieci wirtualnej. Jeśli potrzebujesz wielu kart sieciowych dla maszyny wirtualnej, pamiętaj, że maksymalna liczba kart sieciowych jest zdefiniowana dla każdego rozmiaru maszyny wirtualnej.
Jeśli obciążenie wymaga komunikacji z małymi opóźnieniami między maszynami wirtualnymi w sieci wirtualnej, rozważ przyspieszoną sieć, która jest obsługiwana przez karty sieciowe maszyn wirtualnych platformy Azure. Aby uzyskać więcej informacji, zobacz Zalety przyspieszonej sieci.
Zestawy skalowania maszyn wirtualnych z elastyczną aranżacją
Maszyny wirtualne są aprowizowane w ramach zestawów skalowania maszyn wirtualnych z elastyczną aranżacją. Zestawy skalowania maszyn wirtualnych to logiczne grupy maszyn wirtualnych, które są używane do zaspokojenia potrzeb biznesowych. Typy maszyn wirtualnych w grupowaniu mogą być identyczne lub różne. Umożliwiają one zarządzanie cyklem życia maszyn, interfejsów sieciowych i dysków przy użyciu standardowych interfejsów API i poleceń maszyn wirtualnych platformy Azure.
Tryb elastycznej aranżacji ułatwia operacje na dużą skalę i pomaga w podejmowaniu szczegółowych decyzji dotyczących skalowania.
Konfiguracja domeny błędów jest wymagana w celu ograniczenia wpływu awarii sprzętu fizycznego, awarii sieci lub przerw w dostawie prądu. Dzięki zestawom skalowania platforma Azure równomiernie rozkłada wystąpienia między domenami błędów w celu zapewnienia odporności na pojedynczy problem ze sprzętem lub infrastrukturą.
Zalecamy odciążenie alokacji domeny błędów na platformę Azure w celu zapewnienia maksymalnego rozłożenia wystąpienia, zwiększenia odporności i dostępności.
Dyski
Aby uruchomić składniki systemu operacyjnego i aplikacji, dyski magazynu są dołączone do maszyny wirtualnej. Rozważ użycie dysków efemerycznych dla systemu operacyjnego i dysków zarządzanych na potrzeby magazynu danych.
Platforma Azure oferuje szereg opcji pod względem wydajności, wszechstronności i kosztów. Zacznij od dysków SSD w warstwie Premium dla większości obciążeń produkcyjnych. Wybór zależy od jednostki SKU maszyny wirtualnej. Jednostki SKU obsługujące dyski SSD w warstwie Premium zawierają s w nazwie zasobu, na przykład Dsv4, ale nie Dv4.
Aby uzyskać więcej informacji na temat opcji dysku z metrykami, takimi jak pojemność, liczba operacji we/wy na sekundę i przepływność, zobacz Porównanie typów dysków.
Podczas wybierania dysku należy wziąć pod uwagę charakterystykę dysku i oczekiwania dotyczące wydajności.
Ograniczenia jednostki SKU maszyny wirtualnej. Dyski działają na maszynie wirtualnej, do której są dołączone, które mają limity liczby operacji we/wy na sekundę i przepływności. Upewnij się, że dysk nie ogranicza limitów maszyny wirtualnej i odwrotnie. Wybierz rozmiar dysku, wydajność i możliwości maszyny wirtualnej (rdzenie, procesor, pamięć), które optymalnie uruchamiają składnik aplikacji. Unikaj nadmiernej aprowizacji, ponieważ ma to wpływ na koszty.
Zmiany konfiguracji. Podczas działania maszyny wirtualnej można zmienić konfigurację wydajności dysku i pojemności. Jednak wiele zmian może wymagać ponownej aprowizacji i ponownego kompilowania zawartości dysku, co wpływa na dostępność obciążenia. W związku z tym należy dokładnie zaplanować wybór dysku i jednostki SKU maszyny wirtualnej, aby zminimalizować wpływ dostępności i przerobić pracę.
Efemeryczne dyski systemu operacyjnego. Aprowizuj dyski systemu operacyjnego jako dyski efemeryczne. Używaj dysków zarządzanych tylko wtedy, gdy pliki systemu operacyjnego muszą być utrwalane. Unikaj używania efemerycznych dysków do przechowywania składników i stanu aplikacji.
Pojemność efemerycznych dysków systemu operacyjnego zależy od wybranej jednostki SKU maszyny wirtualnej. Upewnij się, że rozmiar dysku obrazu systemu operacyjnego jest mniejszy niż dostępna pamięć podręczna lub dysk tymczasowy jednostki SKU. Możesz użyć pozostałego miejsca do przechowywania tymczasowego.
Wydajność dysku. Wstępne aprowizowanie miejsca na dysku na podstawie szczytowego obciążenia jest powszechne, ale może prowadzić do niedostatecznego użycia zasobów, ponieważ większość obciążeń nie utrzymuje szczytowego obciążenia.
Monitoruj wzorce użycia obciążenia, zauważając skoki lub długotrwałe operacje odczytu, i uwzględnij te wzorce w wybranej jednostce SKU maszyny wirtualnej i dysku zarządzanego.
Wydajność na żądanie można dostosować, zmieniając warstwy wydajności lub korzystając z funkcji skalowania oferowanych w niektórych jednostkach SKU dysku zarządzanego.
Podczas gdy nadmierna aprowizacja zmniejsza potrzebę zwiększenia wydajności, może to prowadzić do nieużywanej pojemności, za którą płacisz. Najlepiej połączyć obie funkcje w celu uzyskania optymalnych wyników.
Dostrajanie buforowania dla obciążenia. Skonfiguruj ustawienia pamięci podręcznej dla wszystkich dysków na podstawie użycia składnika aplikacji.
Składniki, które wykonują głównie operacje odczytu, nie wymagają wysokiej spójności transakcyjnej dysku. Te składniki mogą korzystać z buforowania tylko do odczytu. Składniki z dużym obciążeniem zapisem wymagające wysokiej spójności transakcyjnej często mają wyłączone buforowanie.
Użycie buforowania odczytu i zapisu może spowodować utratę danych, jeśli maszyna wirtualna ulegnie awarii i nie jest zalecana w przypadku większości scenariuszy dotyczących dysków danych.
W tej architekturze:
Dyski systemu operacyjnego wszystkich maszyn wirtualnych są efemeryczne i znajdują się na dysku pamięci podręcznej.
Aplikacja obciążenia w frontonie (Linux) i zapleczu (Windows Server) są odporne na poszczególne awarie maszyn wirtualnych i używają małych obrazów (około 30 GB). Takie atrybuty sprawiają, że kwalifikują się do korzystania z efemerycznych dysków systemu operacyjnego utworzonych jako część lokalnego magazynu maszyny wirtualnej (partycji pamięci podręcznej) zamiast trwałego dysku systemu operacyjnego zapisanego w zdalnych zasobach usługi Azure Storage. Taka sytuacja nie wiąże się z żadnymi kosztami magazynowania dla dysków systemu operacyjnego, a także poprawia wydajność, zapewniając mniejsze opóźnienia i skracając czas wdrażania maszyny wirtualnej.
Każda maszyna wirtualna ma własny dysk zarządzany SSD W warstwie Premium P1, zapewniając podstawową aprowizowaną przepływność odpowiednią dla obciążenia.
Układ sieci
Ta architektura wdraża obciążenie w jednej sieci wirtualnej. Mechanizmy kontroli sieci są istotną częścią tej architektury i opisano je w sekcji Zabezpieczenia .
Ten układ można zintegrować z topologią przedsiębiorstwa. Ten przykład przedstawiono w temacie Architektura punktu odniesienia maszyny wirtualnej w strefie docelowej platformy Azure.
Sieć wirtualna
Jedna z początkowych decyzji dotyczących układu sieciowego odnosi się do zakresu adresów sieciowych. Należy pamiętać o przewidywanym wzroście sieci w fazie planowania pojemności. Sieć powinna być wystarczająco duża, aby utrzymać wzrost, co może wymagać dodatkowych konstrukcji sieciowych. Na przykład sieć wirtualna powinna mieć pojemność, aby pomieścić inne maszyny wirtualne wynikające z operacji skalowania.
Z drugiej strony należy odpowiednio rozmiesić przestrzeń adresową. Nadmiernie duża sieć wirtualna może prowadzić do niedoceniania. Należy pamiętać, że po utworzeniu sieci wirtualnej nie można zmodyfikować zakresu adresów.
W tej architekturze przestrzeń adresowa jest ustawiona na /21, decyzja oparta na przewidywanym wzroście.
Zagadnienia dotyczące podsieci
W sieci wirtualnej podsieci są podzielone na podstawie funkcjonalności i wymagań dotyczących zabezpieczeń, jak opisano tutaj:
- Podsieć do hostowania bramy aplikacji, która służy jako zwrotny serwer proxy. Usługa Application Gateway wymaga dedykowanej podsieci.
- Podsieć do hostowania wewnętrznego modułu równoważenia obciążenia na potrzeby dystrybucji ruchu do maszyn wirtualnych zaplecza.
- Podsieci do hostowania maszyn wirtualnych obciążeń, jednej dla frontonu i jednej dla zaplecza. Te podsieci są tworzone zgodnie z warstwami aplikacji.
- Podsieć hosta usługi Azure Bastion w celu ułatwienia dostępu operacyjnego do maszyn wirtualnych obciążeń. Zgodnie z projektem host usługi Azure Bastion potrzebuje dedykowanej podsieci.
- Podsieć do hostowania prywatnych punktów końcowych utworzonych w celu uzyskania dostępu do innych zasobów platformy Azure za pośrednictwem usługi Azure Private Link. Chociaż dedykowane podsieci nie są obowiązkowe dla tych punktów końcowych, zalecamy ich użycie.
Podobnie jak w przypadku sieci wirtualnych, podsieci muszą mieć odpowiedni rozmiar. Możesz na przykład zastosować maksymalny limit maszyn wirtualnych obsługiwanych przez orkiestrację elastyczną, aby spełnić potrzeby skalowania aplikacji. Podsieci obciążeń powinny być w stanie obsłużyć ten limit.
Innym przypadkiem użycia do rozważenia jest uaktualnienie systemu operacyjnego maszyny wirtualnej, które mogą wymagać tymczasowych adresów IP. Odpowiednie ustalanie rozmiaru zapewnia żądany poziom segmentacji, upewniając się, że podobne zasoby są pogrupowane, aby można było zastosować znaczące reguły zabezpieczeń za pośrednictwem sieciowych grup zabezpieczeń do granic podsieci. Aby uzyskać więcej informacji, zobacz Zabezpieczenia: segmentacja.
Ruch przychodzący
Dwa publiczne adresy IP są używane na potrzeby przepływów ruchu przychodzącego. Jednym z adresów jest usługa Application Gateway, która służy jako zwrotny serwer proxy. Użytkownicy łączą się przy użyciu tego publicznego adresu IP. Odwrotne obciążenie serwera proxy równoważy ruch przychodzący do prywatnych adresów IP maszyn wirtualnych. Drugi adres dotyczy dostępu operacyjnego za pośrednictwem usługi Azure Bastion.
Pobierz plik programu Visio z tą architekturą.
Ruch wychodzący
Ta architektura używa standardowego modułu równoważenia obciążenia jednostki SKU z regułami ruchu wychodzącego zdefiniowanymi z wystąpień maszyn wirtualnych. Wybrano moduł równoważenia obciążenia, ponieważ jest strefowo nadmiarowy.
Pobierz plik programu Visio z tą architekturą.
Ta konfiguracja umożliwia korzystanie z publicznych adresów IP modułu równoważenia obciążenia w celu zapewnienia wychodzącej łączności internetowej dla maszyn wirtualnych. Reguły ruchu wychodzącego umożliwiają jawne definiowanie portów translacji adresów sieciowych (SNAT). Reguły umożliwiają skalowanie i dostrajanie tej możliwości za pomocą ręcznej alokacji portów. Ręczne przydzielanie portu SNAT na podstawie rozmiaru i liczby puli zaplecza frontendIPConfigurations może pomóc uniknąć wyczerpania SNAT.
Zalecamy przydzielenie portów na podstawie maksymalnej liczby wystąpień zaplecza. W przypadku dodania większej liczby wystąpień niż pozostałych dozwolonych portów SNAT operacje skalowania zestawów skalowania maszyn wirtualnych mogą zostać zablokowane lub nowe maszyny wirtualne nie otrzymają wystarczających portów SNAT.
Oblicz porty na wystąpienie jako: Number of front-end IPs * 64K / Maximum number of back-end instances.
Dostępne są inne opcje, takie jak wdrażanie zasobu usługi Azure NAT Gateway dołączonego do podsieci. Inną opcją jest użycie usługi Azure Firewall lub innego wirtualnego urządzenia sieciowego z niestandardową trasą zdefiniowaną przez użytkownika (UDR) jako następnego przeskoku przez zaporę. Ta opcja jest wyświetlana w architekturze punktu odniesienia maszyny wirtualnej w strefie docelowej platformy Azure.
Rozpoznawanie nazw DNS
Usługa Azure DNS jest używana jako podstawowa usługa dla wszystkich przypadków użycia rozpoznawania, na przykład rozpoznawania w pełni kwalifikowanych nazw domen (FQDN) skojarzonych z maszynami wirtualnymi obciążenia. W tej architekturze maszyny wirtualne używają wartości DNS ustawionych w konfiguracji sieci wirtualnej, która jest usługą Azure DNS.
Prywatne strefy DNS platformy Azure są używane do rozpoznawania żądań do prywatnych punktów końcowych używanych do uzyskiwania dostępu do nazwanych zasobów usługi Private Link.
Monitorowanie
Ta architektura zawiera stos monitorowania, który jest oddzielony od narzędzia obciążenia. Skupiamy się przede wszystkim na źródłach danych i aspektach zbierania danych.
Uwaga
Aby uzyskać kompleksowy wgląd w obserwację, zobacz OE:07 Rekomendacje do projektowania i tworzenia systemu monitorowania.
Metryki i dzienniki są generowane w różnych źródłach danych, zapewniając wgląd w szczegółowe informacje o różnych wysokościach:
Uwzględniana jest podstawowa infrastruktura i składniki , takie jak maszyny wirtualne, sieci wirtualne i usługi magazynu. Dzienniki platformy Azure zawierają informacje o operacjach i działaniach na platformie Azure.
Poziom aplikacji zapewnia wgląd w wydajność i zachowanie aplikacji działających w systemie.
Obszar roboczy usługi Log Analytics to zalecany ujście danych monitorowania używany do zbierania dzienników i metryk z zasobów platformy Azure i Szczegółowe informacje aplikacji.
Ten obraz przedstawia stos monitorowania punktu odniesienia ze składnikami do zbierania danych z infrastruktury i aplikacji, ujść danych i różnych narzędzi do analizy i wizualizacji. Implementacja wdraża niektóre składniki, takie jak Application Szczegółowe informacje, diagnostyka rozruchu maszyny wirtualnej i Log Analytics. Inne składniki są przedstawione w celu zaprezentowania opcji rozszerzalności, takich jak pulpity nawigacyjne i alerty.
Pobierz plik programu Visio z tą architekturą.
Monitorowanie na poziomie infrastruktury
Ta tabela zawiera linki do dzienników i metryk zebranych przez usługę Azure Monitor. Dostępne alerty pomagają aktywnie rozwiązywać problemy przed ich wpływem na użytkowników.
Aby uzyskać więcej informacji na temat kosztów zbierania metryk i dzienników, zobacz Obliczenia kosztów i opcje usługi Log Analytics oraz Cennik obszaru roboczego usługi Log Analytics. Charakter obciążenia oraz częstotliwość i liczba metryk i dzienników zebranych znacznie wpływają na koszty metryki i zbierania dzienników.
Maszyny wirtualne
Diagnostyka rozruchu platformy Azure jest włączona, aby obserwować stan maszyn wirtualnych podczas rozruchu, zbierając informacje o dzienniku szeregowym i zrzuty ekranu. W tej architekturze dostęp do danych można uzyskać za pośrednictwem witryny Azure Portal i polecenia get-boot-log maszyny wirtualnej interfejsu wiersza polecenia platformy Azure get-boot-log. Dane są zarządzane przez platformę Azure i nie masz kontroli ani dostępu do bazowego zasobu magazynu. Jeśli jednak wymagania biznesowe wymagają większej kontroli, możesz aprowizować własne konto magazynu w celu przechowywania diagnostyki rozruchu.
Szczegółowe informacje o maszynach wirtualnych oferują wydajny sposób monitorowania maszyn wirtualnych i zestawów skalowania. Zbiera dane z obszarów roboczych usługi Log Analytics i udostępnia wstępnie zdefiniowane skoroszyty dotyczące trendów danych wydajności. Te dane można wyświetlać na maszynę wirtualną lub agregować na wielu maszynach wirtualnych.
Usługa Application Gateway i wewnętrzny moduł równoważenia obciążenia używają sond kondycji do wykrywania stanu punktu końcowego maszyn wirtualnych przed wysłaniem ruchu.
Sieć
W tej architekturze dane dziennika są zbierane z kilku składników sieciowych, które uczestniczą w przepływie. Składniki te obejmują usługę Application Gateway, moduły równoważenia obciążenia i usługę Azure Bastion. Obejmują one również składniki zabezpieczeń sieci, takie jak sieci wirtualne, sieciowe grupy zabezpieczeń, publiczne adresy IP i usługa Private Link.
dyski zarządzane
Metryki dysków zależą od obciążenia, co wymaga kombinacji kluczowych metryk. Monitorowanie powinno łączyć te perspektywy w celu izolowania problemów z przepływnością systemu operacyjnego lub aplikacji.
Perspektywa platformy Azure reprezentuje metryki wskazujące usługę platformy Azure, niezależnie od obciążenia, które jest z nim połączone. Metryki wydajności dysku (liczba operacji we/wy na sekundę i przepływność) można wyświetlać pojedynczo lub zbiorczo dla wszystkich dysków dołączonych do maszyn wirtualnych. Użyj metryk użycia operacji we/wy magazynu na potrzeby rozwiązywania problemów lub zgłaszania alertów dotyczących potencjalnego ograniczenia dysku. Jeśli używasz skalowania w celu optymalizacji kosztów, monitoruj metryki procentowe środków, aby zidentyfikować możliwości dalszej optymalizacji.
Perspektywa systemu operacyjnego gościa reprezentuje metryki, które operator obciążenia wyświetli, niezależnie od podstawowej technologii dysków. Szczegółowe informacje o maszynie wirtualnej są zalecane w przypadku kluczowych metryk na dołączonych dyskach, takich jak używane miejsce na dysku logicznym i perspektywa jądra systemu operacyjnego w zakresie liczby operacji we/wy na sekundę i przepływności dysku.
Monitorowanie na poziomie aplikacji
Mimo że implementacja referencyjna nie korzysta z niej, aplikacja Szczegółowe informacje jest aprowizowana jako zarządzanie wydajnością aplikacji (APM) na potrzeby rozszerzalności. Aplikacja Szczegółowe informacje zbiera dane z aplikacji i wysyła te dane do obszaru roboczego usługi Log Analytics. Może również wizualizować te dane z aplikacji obciążeń.
Rozszerzenie kondycji aplikacji jest wdrażane na maszynach wirtualnych, aby monitorować stan kondycji binarnej każdego wystąpienia maszyny wirtualnej w zestawie skalowania i w razie potrzeby wykonywać naprawy wystąpień przy użyciu automatycznej naprawy wystąpienia zestawu skalowania. Testuje on ten sam plik co usługa Application Gateway i wewnętrzna sonda kondycji modułu równoważenia obciążenia platformy Azure, aby sprawdzić, czy aplikacja odpowiada.
Zarządzanie aktualizacjami
Maszyny wirtualne muszą być regularnie aktualizowane i poprawiane, aby nie osłabiły one stanu zabezpieczeń obciążenia. Zalecamy automatyczne i okresowe oceny maszyn wirtualnych na potrzeby wczesnego odnajdywania i stosowania poprawek.
Aktualizacje infrastruktury
Platforma Azure okresowo aktualizuje swoją platformę w celu zwiększenia niezawodności, wydajności i zabezpieczeń infrastruktury hosta dla maszyn wirtualnych. Te aktualizacje obejmują stosowanie poprawek składników oprogramowania w środowisku hostingu, uaktualnianie składników sieciowych lub likwidowanie sprzętu i nie tylko. Aby uzyskać informacje na temat procesu aktualizacji, zobacz Konserwacja maszyn wirtualnych na platformie Azure.
Jeśli aktualizacja nie wymaga ponownego uruchomienia, maszyna wirtualna jest wstrzymana podczas aktualizacji hosta lub maszyna wirtualna jest migrowana na żywo do już zaktualizowanego hosta. Jeśli konserwacja wymaga ponownego uruchomienia, otrzymasz powiadomienie o planowanej konserwacji. Platforma Azure udostępnia również przedział czasu, w którym można rozpocząć konserwację, dla wygody. Aby uzyskać informacje o oknie samodzielnej konserwacji i sposobie konfigurowania dostępnych opcji, zobacz Obsługa powiadomień o planowanej konserwacji.
Niektóre obciążenia mogą nie tolerować nawet kilku sekund zamrożenia lub rozłączenia maszyny wirtualnej w celu przeprowadzenia konserwacji. Aby uzyskać większą kontrolę nad wszystkimi działaniami konserwacyjnymi, w tym bez wpływu i aktualizacjami bez ponownego uruchamiania, zobacz Konfiguracje konserwacji. Utworzenie konfiguracji konserwacji zapewnia opcję pomijania wszystkich aktualizacji platformy i stosowania aktualizacji dla wygody. Po ustawieniu tej konfiguracji niestandardowej platforma Azure pomija wszystkie aktualizacje nienależące do zera, w tym aktualizacje bez ponownego uruchamiania. Aby uzyskać więcej informacji, zobacz Zarządzanie aktualizacjami platformy za pomocą konfiguracji konserwacji
Uaktualnienia obrazów systemu operacyjnego
W przypadku uaktualniania systemu operacyjnego mają przetestowany złoty obraz. Rozważ użycie galerii obrazów udostępnionych platformy Azure i galerii zasobów obliczeniowych platformy Azure do publikowania obrazów niestandardowych. Należy mieć proces, który uaktualnia partie wystąpień w sposób kroczący za każdym razem, gdy nowy obraz zostanie opublikowany przez wydawcę.
Wycofywanie obrazów maszyn wirtualnych przed osiągnięciem ich końca życia w celu zmniejszenia obszaru powierzchni.
Proces automatyzacji powinien uwzględniać nadmiarową aprowizę z dodatkową pojemnością.
Usługa Azure Update Management umożliwia zarządzanie aktualizacjami systemu operacyjnego dla maszyn wirtualnych z systemem Windows i Linux w usłudze Azure.Azure Update Manager zapewnia rozwiązanie SaaS do zarządzania aktualizacjami oprogramowania dla maszyn z systemem Windows i Linux oraz zarządzania nimi w środowiskach platformy Azure, lokalnych i wielochmurowych.
Stosowanie poprawek systemu operacyjnego gościa
Maszyny wirtualne platformy Azure zapewniają opcję automatycznego stosowania poprawek gościa maszyny wirtualnej. Po włączeniu tej usługi maszyny wirtualne są okresowo oceniane i klasyfikowane są dostępne poprawki. Zaleca się włączenie trybu oceny, aby umożliwić codzienną ocenę oczekujących poprawek. Można jednak przeprowadzić ocenę na żądanie, która nie wyzwala stosowania poprawek. Jeśli tryb oceny nie jest włączony, mają ręczne sposoby wykrywania oczekujących aktualizacji.
Tylko poprawki sklasyfikowane jako krytyczne lub zabezpieczenia są stosowane automatycznie we wszystkich regionach świadczenia usługi Azure. Zdefiniuj niestandardowe procesy zarządzania aktualizacjami, które stosują inne poprawki.
W celu zapewnienia ładu rozważ stosowanie poprawek obrazu systemu operacyjnego Wymagaj automatycznego stosowania w usłudze Azure Policy zestawów skalowania maszyn wirtualnych.
Automatyczne stosowanie poprawek może spowodować obciążenie systemu i może być destrukcyjne, ponieważ maszyny wirtualne używają zasobów i mogą zostać uruchomione ponownie podczas aktualizacji. Nadmierna aprowizacja jest zalecana w przypadku zarządzania obciążeniami. Wdróż maszyny wirtualne w różnych Strefy dostępności, aby uniknąć współbieżnych aktualizacji i obsługiwać co najmniej dwa wystąpienia na strefę w celu zapewnienia wysokiej dostępności. Maszyny wirtualne w tym samym regionie mogą otrzymywać różne poprawki, które powinny być uzgadniane w czasie.
Należy pamiętać o kompromisie kosztów związanych z nadmierną aprowizowaniem.
Testy kondycji są uwzględniane w ramach automatycznego stosowania poprawek gościa maszyny wirtualnej. Te testy sprawdzają pomyślną aplikację poprawek i wykrywają problemy.
Jeśli istnieją niestandardowe procesy stosowania poprawek, użyj repozytoriów prywatnych dla źródeł poprawek. Dzięki temu można lepiej kontrolować testowanie poprawek, aby upewnić się, że aktualizacja nie ma negatywnego wpływu na wydajność ani zabezpieczenia.
Aby uzyskać więcej informacji, zobacz Automatyczne stosowanie poprawek gościa maszyn wirtualnych platformy Azure.
Niezawodność
Ta architektura używa stref dostępności jako podstawowego elementu w celu rozwiązania problemów z niezawodnością.
W tej konfiguracji poszczególne maszyny wirtualne są powiązane z jedną strefą. Jeśli wystąpi awaria, te maszyny wirtualne można łatwo zastąpić innymi wystąpieniami maszyn wirtualnych przy użyciu zestawów skalowania maszyn wirtualnych.
Wszystkie inne składniki tej architektury są następujące:
- Strefowo nadmiarowe, co oznacza, że są replikowane w wielu strefach w celu zapewnienia wysokiej dostępności, takich jak usługa Application Gateway lub publiczne adresy IP.
- Odporność na strefy, co oznacza, że mogą wytrzymać awarie strefy, takie jak usługa Key Vault.
- Zasoby regionalne lub globalne, które są dostępne w różnych regionach lub globalnie, takich jak Microsoft Entra ID.
Projekt obciążenia powinien uwzględniać gwarancje niezawodności w kodzie aplikacji, infrastrukturze i operacjach. W poniższych sekcjach przedstawiono niektóre strategie, aby upewnić się, że obciążenie jest odporne na awarie i jest w stanie odzyskać dane w przypadku awarii na poziomie infrastruktury.
Strategie używane w architekturze są oparte na liście kontrolnej przeglądu niezawodności podanej w witrynie Azure Well-Architected Framework. Sekcje są oznaczone adnotacjami z zaleceniami z tej listy kontrolnej.
Ponieważ żadna aplikacja nie jest wdrożona, odporność w kodzie aplikacji wykracza poza zakres tej architektury. Zalecamy przejrzenie wszystkich zaleceń na liście kontrolnej i wdrożenie ich w obciążeniu, jeśli ma to zastosowanie.
Określanie priorytetów gwarancji niezawodności dla przepływu użytkownika
W większości projektów istnieje wiele przepływów użytkownika, z których każdy ma własny zestaw wymagań biznesowych. Nie wszystkie te przepływy wymagają najwyższego poziomu gwarancji, dlatego segmentacja jest zalecana jako strategia niezawodności. Każdy segment można zarządzać niezależnie, zapewniając, że jeden segment nie ma wpływu na inne i zapewnia odpowiedni poziom odporności w każdej warstwie. Takie podejście sprawia również, że system jest elastyczny.
W tej architekturze warstwy aplikacji implementują segmentację. Oddzielne zestawy skalowania są aprowizowane dla warstw frontonu i zaplecza. Ta separacja umożliwia niezależne skalowanie każdej warstwy, co pozwala na implementację wzorców projektowych na podstawie określonych wymagań, między innymi.
Zapoznaj się z tematem Well-Architected Framework: RE:02 - Rekomendacje w celu identyfikowania i oceniania przepływów.
Identyfikowanie potencjalnych punktów awarii
Każda architektura jest podatna na błędy. Ćwiczenie analizy trybu awarii umożliwia przewidywanie awarii i przygotowanie ich przy użyciu środków zaradczych. Poniżej przedstawiono niektóre potencjalne punkty awarii w tej architekturze:
| Składnik | Ryzyko | Prawdopodobieństwo | Efekt/Środki zaradcze/Uwaga | Awaria |
|---|---|---|---|---|
| Tożsamość Microsoft Entra | Błąd konfiguracji | Średnia | Użytkownicy platformy Ops nie mogą się zalogować. Brak efektu podrzędnego. Dział pomocy technicznej zgłasza problem z konfiguracją zespołowi tożsamości. | Brak |
| Application Gateway | Błąd konfiguracji | Średnia | Błędy konfiguracji powinny zostać przechwycone podczas wdrażania. Jeśli te błędy wystąpią podczas aktualizacji konfiguracji, zespół DevOps musi wycofać zmiany. Aprowizacja większości wdrożeń korzystających z jednostki SKU w wersji 2 trwa około 6 minut. Jednak może to trwać dłużej w zależności od typu wdrożenia. Na przykład wdrożenia w wielu strefach dostępności z wieloma wystąpieniami mogą potrwać ponad 6 minut. | Pełny |
| Application Gateway | Atak DDoS | Średnia | Potencjalne zakłócenia. Firma Microsoft zarządza ochroną przed atakami DDoS (L3 i L4). Potencjalne ryzyko efektu ataków L7. | Pełny |
| Virtual Machine Scale Sets | Awaria usługi | Minimum | Potencjalna awaria obciążenia, jeśli wystąpią wystąpienia maszyn wirtualnych w złej kondycji, które wyzwalają autorepair. Zależne od firmy Microsoft do skorygowania. | Potencjalna awaria |
| Virtual Machine Scale Sets | Awaria strefy dostępności | Minimum | Brak wpływu. Zestawy skalowania są wdrażane jako strefowo nadmiarowe. | Brak |
Zapoznaj się z dobrze zaprojektowaną strukturą: RE:03 — Rekomendacje do przeprowadzania analizy trybu awarii.
Cele dotyczące niezawodności
Aby podjąć decyzje projektowe, należy obliczyć cele dotyczące niezawodności, takie jak złożone cele poziomu usług (SLO) obciążenia. Obejmuje to zrozumienie umów dotyczących poziomu usług (SLA) udostępnianych przez usługi platformy Azure używane w architekturze. Cele SLO obciążeń nie mogą być wyższe niż umowy SLA gwarantowane przez platformę Azure. Dokładnie zbadaj poszczególne składniki z maszyn wirtualnych i ich zależności, sieci i opcji magazynu.
Oto przykładowe obliczenie, w którym głównym celem jest zapewnienie przybliżonego złożonego celu SLO. Chociaż jest to szorstka wskazówka, powinieneś dotrzeć do czegoś podobnego. Nie należy uzyskać wyższego maksymalnego złożonego celu slo dla tych samych przepływów, chyba że wprowadzisz modyfikacje w architekturze.
Przepływ operacji
| Składnik | Wskaźnik SLO |
|---|---|
| Tożsamość Microsoft Entra | 99,99% |
| Azure Bastion | 99,95% |
Złożony cel slo: 99,94% | Przestój na rok: 0d 5h 15m 20s
Przepływ użytkownika aplikacji
| Składnik | Wskaźnik SLO |
|---|---|
| Application Gateway | 99,95% |
| Azure Load Balancer (wewnętrzny) | 99,99% |
| Maszyny wirtualne frontonu korzystające z magazynu w warstwie Premium (złożone slo) | 99.70% |
| Maszyny wirtualne zaplecza korzystające z magazynu w warstwie Premium (złożone slo) | 99.70% |
Złożony cel slo: 99,34% | Przestój rocznie: 2d 9h 42m 18s
W poprzednim przykładzie uwzględniono niezawodność maszyn wirtualnych i zależności, takie jak dyski skojarzone z maszynami wirtualnymi. Umowy SLA skojarzone z magazynem dyskowym mają wpływ na ogólną niezawodność.
Podczas obliczania złożonego celu SLO występują pewne wyzwania. Ważne jest, aby pamiętać, że różne warstwy usług mogą być dostarczane z różnymi umowami SLA, a często obejmują one gwarancje wspierane finansowo, które ustawiają cele dotyczące niezawodności. Na koniec mogą istnieć składniki architektury, które nie mają zdefiniowanych umów SLA. Na przykład pod względem sieci, kart sieciowych i sieci wirtualnych nie mają własnych umów SLA.
Wymagania biznesowe i ich cele muszą być jasno zdefiniowane i uwzględniane w obliczeniach. Należy pamiętać o limitach usług i innych ograniczeniach narzuconych przez organizację. Udostępnianie subskrypcji innym obciążeniom może mieć wpływ na zasoby dostępne dla maszyn wirtualnych. Obciążenie może używać ograniczonej liczby rdzeni dostępnych dla maszyn wirtualnych. Zrozumienie użycia zasobów subskrypcji może pomóc w bardziej efektywnym projektowaniu maszyn wirtualnych.
Zapoznaj się z tematem Well-Architected Framework: RE:04 — Rekomendacje w celu zdefiniowania celów dotyczących niezawodności.
Nadmiarowość
Ta architektura używa nadmiarowości strefowej dla kilku składników. Każda strefa składa się z co najmniej jednego centrum danych z niezależnym zasilaniem, chłodzeniem i siecią. Uruchamianie wystąpień w oddzielnych strefach chroni aplikację przed awariami centrum danych.
Zestawy skalowania maszyn wirtualnych przydziela określoną liczbę wystąpień i dystrybuują je równomiernie między strefami dostępności i domenami błędów. Ta dystrybucja jest osiągana dzięki maksymalnej możliwości rozłożenia , którą zalecamy. Rozłożenie wystąpień maszyn wirtualnych w różnych domenach błędów zapewnia, że wszystkie maszyny wirtualne nie są jednocześnie aktualizowane.
Rozważmy scenariusz, w którym istnieją trzy strefy dostępności. Jeśli masz trzy wystąpienia, każde wystąpienie zostanie przydzielone do innej strefy dostępności i umieszczone w innej domenie błędów. Platforma Azure gwarantuje, że tylko jedna domena błędów jest aktualizowana jednocześnie w każdej strefie dostępności. Może jednak wystąpić sytuacja, w której wszystkie trzy domeny błędów hostują maszyny wirtualne w trzech strefach dostępności są aktualizowane jednocześnie. Dotyczy to wszystkich stref i domen. Posiadanie co najmniej dwóch wystąpień w każdej strefie zapewnia bufor podczas uaktualniania.
Dyski zarządzane mogą być dołączone tylko do maszyny wirtualnej w tym samym regionie. Ich dostępność zwykle wpływa na dostępność maszyny wirtualnej. W przypadku wdrożeń w jednym regionie dyski można skonfigurować pod kątem nadmiarowości, aby wytrzymać awarie strefowe. W tej architekturze dyski danych są konfigurowane w magazynie strefowo nadmiarowym (ZRS) na maszynach wirtualnych zaplecza. Wymaga to strategii odzyskiwania, aby korzystać ze stref dostępności. Strategia odzyskiwania polega na ponownym wdróż rozwiązanie. Idealne wstępne aprowizowania zasobów obliczeniowych w alternatywnych strefach dostępności gotowych do odzyskania po awarii strefowej.
Strefowo nadmiarowa usługa Application Gateway lub standardowy moduł równoważenia obciążenia mogą kierować ruch do maszyn wirtualnych między strefami przy użyciu jednego adresu IP, zapewniając ciągłość nawet w przypadku wystąpienia awarii strefy. Te usługi używają sond kondycji do sprawdzania dostępności maszyn wirtualnych. Tak długo, jak jedna strefa w regionie pozostaje operacyjna, routing będzie kontynuowany pomimo potencjalnych awarii w innych strefach. Jednak routing między strefami może mieć większe opóźnienie w porównaniu z routingiem wewnątrz strefy.
Wszystkie publiczne adresy IP używane w tej architekturze są strefowo nadmiarowe.
Platforma Azure oferuje usługi odporne na strefy w celu uzyskania lepszej niezawodności, takiej jak usługa Key Vault.
Zasoby globalne platformy Azure są zawsze dostępne i mogą w razie potrzeby przełączyć się do innego regionu, takiego jak podstawowy dostawca tożsamości, identyfikator Firmy Microsoft Entra.
Zapoznaj się z dobrze zaprojektowaną strukturą: RE:05 — Rekomendacje do projektowania pod kątem nadmiarowości.
Strategia skalowania
Aby zapobiec pogorszeniu poziomu usług i awariom, upewnij się, że niezawodne operacje skalowania. Skalowanie obciążenia w poziomie (skalowanie w poziomie), w pionie (skalowanie w górę) lub użycie kombinacji obu tych podejść. Automatyczne skalowanie usługi Azure Monitor umożliwia aprowizowanie wystarczającej ilości zasobów do obsługi zapotrzebowania na aplikację bez przydzielania większej pojemności niż jest to konieczne i ponoszenia niepotrzebnych kosztów.
Automatyczne skalowanie umożliwia definiowanie różnych profilów na podstawie różnych typów zdarzeń, takich jak czas, harmonogram lub metryki. Profile oparte na metrykach mogą używać wbudowanych metryk (opartych na hoście) lub bardziej szczegółowych metryk (metryk maszyn wirtualnych gościa), które wymagają zainstalowania agenta usługi Azure Monitor w celu ich zbierania. Każdy profil zawiera reguły skalowania w poziomie (zwiększanie) i skalowanie (zmniejszanie). Rozważ eksplorowanie wszystkich różnych scenariuszy skalowania w oparciu o zaprojektowane profile i oceń je pod kątem potencjalnych warunków pętli, które mogą powodować szereg przeciwnych zdarzeń skalowania. Usługa Azure Monitor podejmie próbę ograniczenia tej sytuacji, czekając na okres ochładzania przed ponownym skalowaniem.
Mimo że zestawy skalowania maszyn wirtualnych platformy Azure w trybie elastycznym obsługują środowiska heterogeniczne, skalowanie automatyczne wielu profilów nie jest obsługiwane. Rozważ utworzenie różnych zestawów skalowania, aby zarządzać nimi oddzielnie, jeśli planujesz używać autoskalowania z więcej niż jednym typem maszyny wirtualnej.
Podczas tworzenia lub usuwania wystąpień maszyn wirtualnych należy wziąć pod uwagę inne aspekty, takie jak uruchamianie, bezproblemowe zamykanie, instalowanie obciążenia i wszystkie jego zależności oraz zarządzanie dyskami.
Obciążenia stanowe mogą wymagać dodatkowego zarządzania dyskami zarządzanymi, które muszą działać poza wystąpieniem obciążenia. Zaprojektuj obciążenie pod kątem zarządzania danymi w ramach zdarzeń skalowania pod kątem spójności, synchronizacji, replikacji i integralności danych obciążenia. W tych scenariuszach rozważ dodanie wstępnie wypełnionych dysków do zestawów skalowania. W przypadku przypadków użycia skalowania w celu zapobiegania wąskim gardłom podczas uzyskiwania dostępu do danych należy zaplanować partycjonowanie i dzielenie na fragmenty. Aby uzyskać więcej informacji, zobacz Autoskaluj najlepsze rozwiązania.
Zapoznaj się z tematem Well-Architected Framework: RE:06 — Rekomendacje w celu projektowania niezawodnej strategii skalowania.
Samonaprawiania i odzyskiwalności
Automatyczne naprawy wystąpień są włączone w zestawach skalowania maszyn wirtualnych w celu zautomatyzowania odzyskiwania po awariach maszyn wirtualnych. Rozszerzenie kondycji aplikacji jest wdrażane na maszynach wirtualnych w celu obsługi wykrywania nieodpowiadujących maszyn wirtualnych i aplikacji. W przypadku tych wystąpień akcje naprawy są wyzwalane automatycznie.
Zapoznaj się z dobrze zaprojektowaną strukturą: Rekomendacje do samonaprawiania i samozachowawnictwa.
Zabezpieczenia
Ta architektura ilustruje niektóre z gwarancji zabezpieczeń podane na liście kontrolnej przeglądu projektu zabezpieczeń podane w witrynie Azure Well-Architected Framework. Sekcje są oznaczone adnotacjami z zaleceniami z tej listy kontrolnej.
Zabezpieczenia nie odnoszą się tylko do mechanizmów kontroli technicznej. Zalecamy przestrzeganie całej listy kontrolnej, aby zrozumieć aspekty operacyjne filaru zabezpieczeń.
Segmentacja
Segmentacja sieci. Zasoby obciążenia są umieszczane w sieci wirtualnej, która zapewnia izolację od Internetu. W sieci wirtualnej podsieci mogą być używane jako granice zaufania. Kolokuj powiązane zasoby potrzebne do obsługi transakcji w jednej podsieci. W tej architekturze sieć wirtualna jest podzielona na podsieci na podstawie logicznego grupowania aplikacji i przeznaczenia różnych usług platformy Azure używanych w ramach obciążenia.
Zaletą segmentacji podsieci jest możliwość umieszczenia mechanizmów kontroli zabezpieczeń w obwodzie, który kontroluje przepływ ruchu przychodzącego i wychodzącego z podsieci, ograniczając w ten sposób dostęp do zasobów obciążenia.
Segmentacja tożsamości. Przypisz odrębne role do różnych tożsamości z odpowiednimi uprawnieniami, aby wykonać swoje zadanie. Ta architektura używa tożsamości zarządzanych przez identyfikator entra firmy Microsoft do segmentowania dostępu do zasobów.
Segmentacja zasobów. Aplikacja jest podzielona według warstw na oddzielne zestawy skalowania, co gwarantuje, że składniki aplikacji nie są kolokowane.
Zapoznaj się z tematem Well-Architected Framework: SE:04 — Rekomendacje w celu utworzenia strategii segmentacji.
Zarządzanie tożsamościami i dostępem
Zalecamy używanie identyfikatora Entra firmy Microsoft do uwierzytelniania i autoryzacji zarówno użytkowników, jak i usług.
Dostęp do maszyn wirtualnych wymaga konta użytkownika kontrolowanego przez uwierzytelnianie identyfikatora Entra firmy Microsoft i wspieranego przez grupy zabezpieczeń. Ta architektura zapewnia obsługę przez wdrożenie rozszerzenia uwierzytelniania identyfikatora entra firmy Microsoft na wszystkich maszynach wirtualnych. Zalecamy, aby użytkownicy końcowi używali tożsamości firmowych w dzierżawie microsoft Entra ID w organizacji. Upewnij się również, że żaden dostęp oparty na jednostce usługi nie jest współużytkowany między funkcjami.
Zasoby obciążeń, takie jak maszyny wirtualne, uwierzytelniają się przy użyciu przypisanych tożsamości zarządzanych do innych zasobów. Te tożsamości oparte na jednostkach usługi Microsoft Entra ID są automatycznie zarządzane.
Na przykład rozszerzenia usługi Key Vault są instalowane na maszynach wirtualnych, które uruchamiają maszyny wirtualne z certyfikatami. W tej architekturze tożsamości zarządzane przypisane przez użytkownika są używane przez usługę Application Gateway, maszyny wirtualne frontonu i maszyny wirtualne zaplecza w celu uzyskania dostępu do usługi Key Vault. Te tożsamości zarządzane są konfigurowane podczas wdrażania i używane do uwierzytelniania w usłudze Key Vault. Zasady dostępu w usłudze Key Vault są skonfigurowane tak, aby akceptowały tylko żądania z poprzednich tożsamości zarządzanych.
Architektura punktu odniesienia używa kombinacji tożsamości zarządzanych przypisanych przez system i przypisanych przez użytkownika. Te tożsamości są wymagane do używania identyfikatora Entra firmy Microsoft do celów autoryzacji podczas uzyskiwania dostępu do innych zasobów platformy Azure.
Zapoznaj się z tematem Well-Architected Framework: SE:05 — Rekomendacje na potrzeby zarządzania tożsamościami i dostępem.
Formanty sieciowe
Ruch przychodzący. Maszyny wirtualne obciążenia nie są bezpośrednio udostępniane publicznemu Internetowi. Każda maszyna wirtualna ma prywatny adres IP. Użytkownicy obciążeń łączą się przy użyciu publicznego adresu IP usługi Application Gateway.
Więcej zabezpieczeń zapewnia zapora aplikacji internetowej zintegrowana z usługą Application Gateway. Zawiera reguły, które sprawdzają ruch przychodzący i mogą podejmować odpowiednie działania. Zapora aplikacji internetowej śledzi luki w zabezpieczeniach open Web Application Security Project (OWASP) uniemożliwiające znane ataki.
Ruch wychodzący. W podsieciach maszyn wirtualnych nie ma żadnych kontrolek dla ruchu wychodzącego, z wyjątkiem reguł sieciowej grupy zabezpieczeń dla ruchu wychodzącego. Zalecamy, aby cały wychodzący ruch internetowy przepływł przez jedną zaporę. Ta zapora jest zwykle usługą centralną zapewnianą przez organizację. Ten przypadek użycia jest wyświetlany w architekturze punktu odniesienia maszyny wirtualnej w strefie docelowej platformy Azure.
Ruch wschodnio-zachodni. Przepływ ruchu między podsieciami jest ograniczony przez zastosowanie szczegółowych reguł zabezpieczeń.
Sieciowe grupy zabezpieczeń są umieszczane w celu ograniczenia ruchu między podsieciami na podstawie parametrów, takich jak zakres adresów IP, porty i protokoły. Grupy zabezpieczeń aplikacji (ASG) są umieszczane na maszynach wirtualnych frontonu i zaplecza. Są one używane z sieciowymi grupami zabezpieczeń do filtrowania ruchu do i z maszyn wirtualnych.
Ruch operacyjny. Zalecamy zapewnienie bezpiecznego dostępu operacyjnego do obciążenia za pośrednictwem usługi Azure Bastion, co eliminuje konieczność korzystania z publicznego adresu IP. W tej architekturze komunikacja odbywa się za pośrednictwem protokołu SSH i jest obsługiwana przez maszyny wirtualne z systemami Windows i Linux. Identyfikator Entra firmy Microsoft jest zintegrowany z protokołem SSH dla obu typów maszyn wirtualnych przy użyciu odpowiedniego rozszerzenia maszyny wirtualnej. Ta integracja umożliwia uwierzytelnienie i autoryzowanie tożsamości operatora za pośrednictwem identyfikatora Entra firmy Microsoft.
Alternatywnie możesz użyć oddzielnej maszyny wirtualnej jako serwera przesiadkowego wdrożonego we własnej podsieci, w której możesz zainstalować wybrane narzędzia administratora i narzędzia do rozwiązywania problemów. Operator uzyskuje dostęp do serwera przesiadkowego za pośrednictwem hosta usługi Azure Bastion. Następnie logują się do maszyn wirtualnych za modułem równoważenia obciążenia z poziomu pola przesiadkowego.
W tej architekturze ruch operacyjny jest chroniony przy użyciu reguł sieciowej grupy zabezpieczeń w celu ograniczenia ruchu, a dostęp just in time (JIT) maszyn wirtualnych jest włączony na maszynach wirtualnych. Ta funkcja Microsoft Defender dla Chmury umożliwia tymczasowy dostęp przychodzący do wybranych portów.
W celu zapewnienia zwiększonych zabezpieczeń użyj usługi Microsoft Entra Privileged Identity Management (PIM). PIM to usługa w usłudze Microsoft Entra ID, która umożliwia zarządzanie, kontrolowanie i monitorowanie dostępu do ważnych zasobów w organizacji. Usługa PIM zapewnia aktywację roli opartą na czasie i zatwierdzania w celu ograniczenia ryzyka nadmiernego, niepotrzebnego lub nieprawidłowego użycia uprawnień dostępu do zasobów, które cię interesują.
Prywatna łączność z usługami platformy jako usługi (PaaS). Komunikacja między maszynami wirtualnymi a usługą Key Vault odbywa się za pośrednictwem usługi Private Link. Ta usługa wymaga prywatnych punktów końcowych, które są umieszczane w oddzielnej podsieci.
Ochrona przed atakami DDoS. Rozważ włączenie usługi Azure DDoS Protection na publicznych adresach IP uwidocznionych przez usługę Application Gateway i hosta usługi Azure Bastion w celu wykrywania zagrożeń. Usługa DDoS Protection zapewnia również alerty, dane telemetryczne i analizę za pośrednictwem monitora. Aby uzyskać więcej informacji, zobacz Azure DDoS Protection: najlepsze rozwiązania i architektury referencyjne.
Zapoznaj się z tematem Well-Architected Framework: SE:06 — Rekomendacje na potrzeby sieci i łączności.
Szyfrowanie
Dane przesyłane. Ruch użytkowników między użytkownikami a publicznym adresem IP usługi Application Gateway jest szyfrowany przy użyciu certyfikatu zewnętrznego. Ruch między bramą aplikacji a maszynami wirtualnymi frontonu oraz między maszynami wirtualnymi frontonu i zaplecza jest szyfrowany przy użyciu certyfikatu wewnętrznego. Oba certyfikaty są przechowywane w usłudze Key Vault:
- app.contoso.com: certyfikat zewnętrzny używany przez klientów i usługę Application Gateway do bezpiecznego publicznego ruchu internetowego.
- *.workload.contoso.com: certyfikat wieloznaczny używany przez składniki infrastruktury do bezpiecznego ruchu wewnętrznego.
Dane magazynowane. Dane dziennika są przechowywane na dysku zarządzanym dołączonym do maszyn wirtualnych. Te dane są automatycznie szyfrowane przy użyciu szyfrowania udostępnianego przez platformę na platformie Azure.
Zapoznaj się z tematem Well-Architected Framework: SE:07 — Rekomendacje na potrzeby szyfrowania danych.
Zarządzanie wpisami tajnymi
Pobierz plik programu Visio z tą architekturą.
Usługa Key Vault zapewnia bezpieczne zarządzanie wpisami tajnymi, w tym certyfikaty TLS. W tej architekturze certyfikaty TLS są przechowywane w usłudze Key Vault i pobierane podczas procesu aprowizacji przez tożsamości zarządzane usługi Application Gateway i maszyny wirtualne. Po początkowej konfiguracji te zasoby uzyskują dostęp tylko do usługi Key Vault po odświeżeniu certyfikatów.
Maszyny wirtualne używają rozszerzenia maszyny wirtualnej usługi Key Vault do automatycznego odświeżania monitorowanych certyfikatów. Jeśli w lokalnym magazynie certyfikatów zostaną wykryte jakiekolwiek zmiany, rozszerzenie pobiera i instaluje odpowiednie certyfikaty z usługi Key Vault. Rozszerzenie obsługuje typy zawartości certyfikatów PKCS #12 i PEM.
Ważne
Twoim obowiązkiem jest zapewnienie regularnej rotacji przechowywanych lokalnie certyfikatów. Aby uzyskać więcej informacji, zobacz Rozszerzenie maszyny wirtualnej usługi Azure Key Vault dla systemu Linux lub rozszerzenia maszyny wirtualnej usługi Azure Key Vault dla systemu Windows.
Zapoznaj się z tematem Well-Architected Framework: SE:09 — Rekomendacje w celu ochrony wpisów tajnych aplikacji.
Optymalizacja kosztów
Wymagania dotyczące obciążenia muszą być spełnione, pamiętając o ograniczeniach kosztów. Strategie używane w architekturze są oparte na liście kontrolnej przeglądu optymalizacji kosztów podanej w witrynie Azure Well-Architected Framework. W tej sekcji opisano niektóre opcje optymalizacji kosztów i są oznaczone adnotacjami z tej listy kontrolnej.
Koszt składnika
Wybierz obrazy maszyn wirtualnych zoptymalizowane pod kątem obciążenia zamiast używać obrazów ogólnego przeznaczenia. W tej architekturze wybierane są stosunkowo małe obrazy maszyn wirtualnych zarówno dla systemów Windows, jak i Linux, które mają rozmiar 30 GB. W przypadku mniejszych obrazów jednostki SKU maszyn wirtualnych z dyskami są również mniejsze, co prowadzi do obniżenia kosztów, zmniejszenia zużycia zasobów oraz skrócenia czasu wdrażania i rozruchu. Zaletą jest zwiększone bezpieczeństwo ze względu na zmniejszony obszar powierzchni.
Implementowanie rotacji dzienników z limitami rozmiaru jest kolejną strategią oszczędzania kosztów. Umożliwia korzystanie z małych dysków danych, co może spowodować obniżenie kosztów. Implementacja tej architektury używa dysków 4 GB.
Korzystanie z efemerycznych dysków systemu operacyjnego może również prowadzić do obniżenia kosztów i zwiększenia wydajności. Te dyski są przeznaczone do korzystania z zasobów maszyny wirtualnej, za które już płacisz, ponieważ są one zainstalowane na dysku pamięci podręcznej aprowizowanej z maszyną wirtualną. Eliminuje koszty magazynowania związane z tradycyjnymi dyskami trwałymi. Ponieważ te dyski są tymczasowe, nie ma żadnych kosztów związanych z długoterminowym magazynem danych.
Zapoznaj się z tematem Well-Architected Framework: CO:07 — Rekomendacje w celu optymalizacji kosztów składników.
Koszt przepływu
Wybierz zasoby obliczeniowe w oparciu o krytyczność przepływu. W przypadku przepływów, które są przeznaczone do tolerowania nieokreślonej długości, rozważ użycie maszyn wirtualnych typu spot z elastycznym trybem aranżacji zestawów skalowania maszyn wirtualnych . Takie podejście może być skuteczne w przypadku hostowania przepływów o niskim priorytecie na maszynach wirtualnych o niższym priorytecie. Ta strategia umożliwia optymalizację kosztów, jednocześnie spełniając wymagania różnych przepływów.
Zapoznaj się z tematem Well-Architected Framework: CO:09 — Rekomendacje w celu optymalizacji kosztów przepływu.
Skalowanie kosztów
Jeśli głównym czynnikiem kosztu jest liczba wystąpień, skalowanie w górę może być bardziej opłacalne przez zwiększenie rozmiaru lub wydajności maszyn wirtualnych. Takie podejście może prowadzić do oszczędności kosztów w kilku obszarach:
- Licencjonowanie oprogramowania. Większe maszyny wirtualne mogą obsługiwać więcej obciążeń, co potencjalnie zmniejsza liczbę wymaganych licencji na oprogramowanie.
- Czas konserwacji: mniejsze, większe maszyny wirtualne mogą zmniejszyć koszty operacyjne.
- Równoważenie obciążenia: mniejsza liczba maszyn wirtualnych może spowodować obniżenie kosztów równoważenia obciążenia. Na przykład w tej architekturze istnieje wiele warstw równoważenia obciążenia, takich jak brama aplikacji z przodu i wewnętrzny moduł równoważenia obciążenia w środku. Koszty równoważenia obciążenia zwiększają się, jeśli wymagana jest większa liczba wystąpień.
- Magazyn dyskowy. Jeśli istnieją aplikacje stanowe, więcej wystąpień wymaga więcej dołączonych dysków zarządzanych, co zwiększa koszt magazynu.
Zapoznaj się z tematem Well-Architected Framework: CO:12 — Rekomendacje w celu optymalizacji kosztów skalowania.
Koszty operacyjne
Automatyczne stosowanie poprawek gościa maszyny wirtualnej zmniejsza obciążenie związane z ręcznym stosowaniem poprawek i powiązanymi kosztami konserwacji. Nie tylko ta akcja pomaga zwiększyć bezpieczeństwo systemu, ale także optymalizuje alokację zasobów, przyczyniając się do ogólnej wydajności kosztów.
Zapoznaj się z dobrze zaprojektowaną strukturą: CO:13 — Rekomendacje w celu optymalizacji czasu personelu.
Wdrażanie tego scenariusza
Wdrożenie tej architektury referencyjnej jest dostępne w usłudze GitHub.
Powiązane zasoby
Aby uzyskać szczegółowe informacje na temat określonych usług platformy Azure, zobacz dokumentację produktu:
- Azure Virtual Machines
- Zestawy skalowania maszyn wirtualnych Azure
- Azure Virtual Network
- Standard_v2 bramy aplikacja systemu Azure
- Azure Load Balancer
- Azure Key Vault
- Azure Bastion
- Application Insights
- Log Analytics
Następny krok
Zapoznaj się z architekturami referencyjnymi IaaS, które pokazują opcje dla warstwy danych: