Lista kontrolna dotycząca odporności dla określonych usług platformy Azure

Odporność to zdolność systemu do odzyskiwania sprawności po awarii i kontynuowania działania. Każda technologia ma własne konkretne tryby awarii, które należy wziąć pod uwagę podczas projektowania i implementowania aplikacji. Ta lista kontrolna umożliwia zapoznanie się z zagadnieniami dotyczącymi odporności określonych usług platformy Azure. Aby uzyskać więcej informacji na temat projektowania odpornych aplikacji, zobacz Projektowanie niezawodnych aplikacji platformy Azure.

App Service

Użyj warstwy Standardowa lub Premium. Te warstwy obsługują miejsca przejściowe i automatyczne kopie zapasowe. Aby uzyskać więcej informacji, zobacz szczegółowe omówienie planów usługi aplikacja systemu Azure Service

Unikaj skalowania w górę lub w dół. Zamiast tego wybierz warstwę i rozmiar wystąpienia spełniający wymagania dotyczące wydajności w ramach typowego obciążenia, a następnie przeprowadź skalowanie w poziomie wystąpień w celu obsługi zmian w woluminie ruchu. Skalowanie w górę i w dół może spowodować ponowne uruchomienie aplikacji.

Konfiguracja sklepu jako ustawienia aplikacji. Ustawienia aplikacji służą do przechowywania ustawień konfiguracji jako ustawień aplikacji. Zdefiniuj ustawienia w szablonach usługi Resource Manager lub przy użyciu programu PowerShell, aby można je było zastosować w ramach zautomatyzowanego procesu wdrażania/aktualizacji, co jest bardziej niezawodne. Aby uzyskać więcej informacji, zobacz Konfigurowanie aplikacji internetowych w usłudze aplikacja systemu Azure Service.

Utwórz oddzielne plany usługi App Service dla środowiska produkcyjnego i testowego. Nie używaj miejsc we wdrożeniu produkcyjnym na potrzeby testowania. Wszystkie aplikacje w ramach tego samego planu usługi App Service współdzielą te same wystąpienia maszyn wirtualnych. Jeśli wdrożenia produkcyjne i testowe są umieszczane w tym samym planie, może to negatywnie wpłynąć na wdrożenie produkcyjne. Na przykład testy obciążeniowe mogą obniżyć wydajność aktywnej lokacji produkcyjnej. Wprowadzenie wdrożeń testowych do oddzielnego planu pozwala odizolować je od wersji produkcyjnej.

Oddziel aplikacje internetowe od internetowych interfejsów API. Jeśli twoje rozwiązanie ma zarówno fronton internetowy, jak i internetowy interfejs API, rozważ ich rozdzielenie na oddzielne aplikacje usługi App Service. Ten projekt ułatwia rozłożenie rozwiązania według obciążenia. Aplikację internetową i interfejs API można uruchomić w oddzielnych planach usługi App Service, aby można je było skalować niezależnie. Jeśli na początku nie potrzebujesz tego poziomu skalowalności, możesz wdrożyć aplikacje w tym samym planie i w razie potrzeby przenieść je do oddzielnych planów później.

Wdrażanie strefowo nadmiarowych planów usługi App Service. W obsługiwanych regionach plany usługi App Service można wdrożyć jako strefowo nadmiarowe, co oznacza, że wystąpienia są automatycznie dystrybuowane między strefami dostępności. Usługa App Service automatycznie dystrybuuje ruch między strefami i obsługuje tryb failover, jeśli strefa wystąpi awaria. Aby uzyskać więcej informacji, zobacz Migrowanie usługi App Service do obsługi stref dostępności.

Unikaj używania funkcji tworzenia kopii zapasowej usługi App Service do tworzenia kopii zapasowych baz danych Azure SQL Database. Zamiast tego użyj automatycznych kopii zapasowych usługi SQL Database. Kopia zapasowa usługi App Service eksportuje bazę danych do pliku BACPAC SQL, który kosztuje jednostki DTU.

Wdróż w miejscu przejściowym. Utwórz miejsce wdrożenia na potrzeby przemieszczania. Wdróż aktualizacje aplikacji w miejscu przejściowym i zweryfikuj wdrożenie przed zamianą jej na środowisko produkcyjne. Zmniejsza to prawdopodobieństwo nieprawidłowej aktualizacji w środowisku produkcyjnym. Gwarantuje to również, że wszystkie wystąpienia są rozgrzewane przed zamianą na środowisko produkcyjne. Wiele aplikacji ma znaczący czas rozgrzewania i zimnego startu. Aby uzyskać więcej informacji, zobacz Konfigurowanie środowisk przejściowych dla aplikacji internetowych w usłudze aplikacja systemu Azure Service.

Utwórz miejsce wdrożenia do przechowywania ostatniego znanego wdrożenia (LKG). Podczas wdrażania aktualizacji w środowisku produkcyjnym przenieś poprzednie wdrożenie produkcyjne do miejsca LKG. Ułatwia to wycofanie nieprawidłowego wdrożenia. Jeśli później wykryjesz problem, możesz szybko przywrócić wersję LKG. Aby uzyskać więcej informacji, zobacz Podstawowa aplikacja internetowa.

Włącz rejestrowanie diagnostyczne, w tym rejestrowanie aplikacji i rejestrowanie serwera internetowego. Rejestrowanie jest ważne w przypadku monitorowania i diagnostyki. Zobacz Włączanie rejestrowania diagnostycznego dla aplikacji internetowych w usłudze aplikacja systemu Azure Service

Zaloguj się do magazynu obiektów blob. Ułatwia to zbieranie i analizowanie danych.

Utwórz oddzielne konto magazynu dla dzienników. Nie używaj tego samego konta magazynu dla dzienników i danych aplikacji. Pomaga to zapobiec zmniejszeniu wydajności aplikacji przez rejestrowanie.

Monitorowanie wydajności. Użyj usługi monitorowania wydajności, takiej jak New Relic lub Application Szczegółowe informacje, aby monitorować wydajność i zachowanie aplikacji pod obciążeniem. Monitorowanie wydajności zapewnia wgląd w aplikację w czasie rzeczywistym. Umożliwia diagnozowanie problemów i przeprowadzanie analizy głównej przyczyny błędów.

Azure Load Balancer

Wybierz pozycję Jednostka SKU w warstwie Standardowa. usługa Load Balancer w warstwie Standardowa zapewnia wymiar niezawodności, którego podstawowa nie ma — stref dostępności i odporności strefy. Oznacza to, że gdy strefa ulegnie awarii, usługa Load Balancer w warstwie Standardowa strefowo nadmiarowa nie będzie mieć wpływu. Dzięki temu wdrożenia mogą wytrzymać awarie stref w regionie. Ponadto usługa Load Balancer w warstwie Standardowa obsługuje globalne równoważenie obciążenia, dzięki czemu aplikacja nie ma wpływu na awarie regionów.

Aprowizuj co najmniej dwa wystąpienia. Wdróż moduł równoważenia obciążenia platformy Azure z co najmniej dwoma wystąpieniami w zapleczu. Pojedyncze wystąpienie może spowodować pojedynczy punkt awarii. W celu utworzenia na potrzeby skalowania warto sparować moduł równoważenia obciążenia z zestawami skalowania maszyn wirtualnych.

Użyj reguł ruchu wychodzącego. Reguły ruchu wychodzącego zapewniają, że nie występują błędy połączeń w wyniku wyczerpania portów SNAT (Source Network Address Translation). Dowiedz się więcej o łączności wychodzącej. Chociaż reguły ruchu wychodzącego pomogą ulepszyć rozwiązanie w przypadku wdrożeń o małym lub średnim rozmiarze, w przypadku obciążeń produkcyjnych zalecamy sprzężenie usługa Load Balancer w warstwie Standardowa lub dowolnego wdrożenia podsieci z translatorem adresów sieci wirtualnych (NAT).

Application Gateway

Aprowizuj co najmniej dwa wystąpienia. Wdróż usługę Application Gateway z co najmniej dwoma wystąpieniami. Pojedyncze wystąpienie jest pojedynczym punktem awarii. Użyj co najmniej dwóch wystąpień w celu zapewnienia nadmiarowości i skalowalności. Aby kwalifikować się do umowy dotyczącej poziomu usług (SLA), musisz aprowizować co najmniej dwa średnie lub większe wystąpienia.

Azure Cosmos DB

Konfigurowanie nadmiarowości strefy. W przypadku korzystania z nadmiarowości strefy usługa Azure Cosmos DB synchronicznie replikuje wszystkie operacje zapisu w strefach dostępności. Automatyczne przełączenie w tryb failover w przypadku awarii strefy. Aby uzyskać więcej informacji, zobacz Uzyskiwanie wysokiej dostępności za pomocą usługi Azure Cosmos DB.

Replikowanie bazy danych między regionami. Usługa Azure Cosmos DB umożliwia skojarzenie dowolnej liczby regionów platformy Azure z kontem bazy danych usługi Azure Cosmos DB. Baza danych usługi Azure Cosmos DB może mieć jeden region zapisu i wiele regionów odczytu. Jeśli wystąpi błąd w regionie zapisu, możesz odczytać z innej repliki. Zestaw SDK klienta obsługuje to automatycznie. Możesz również przejść w tryb failover w regionie zapisu do innego regionu. Aby uzyskać więcej informacji, zobacz Distribute data globally with Azure Cosmos DB (Globalna dystrybucja danych przy użyciu usługi Azure Cosmos DB).

Event Hubs

Użyj punktów kontrolnych. Odbiorca zdarzenia powinien zapisać swoją bieżącą pozycję w magazynie trwałym w określonym wstępnie zdefiniowanym interwale. W ten sposób, jeśli użytkownik wystąpi błąd (na przykład użytkownik ulegnie awarii lub host ulegnie awarii), nowe wystąpienie może wznowić odczytywanie strumienia z ostatniej zarejestrowanej pozycji. Aby uzyskać więcej informacji, zobacz Odbiorcy zdarzeń.

Obsługa zduplikowanych komunikatów. Jeśli konsument zdarzeń zakończy się niepowodzeniem, przetwarzanie komunikatów zostanie wznowione z ostatniego zarejestrowanego punktu kontrolnego. Wszystkie komunikaty, które zostały już przetworzone po ostatnim punkcie kontrolnym, zostaną ponownie przetworzone. W związku z tym logika przetwarzania komunikatów musi być idempotentna lub aplikacja musi mieć możliwość deduplikacji komunikatów.

Obsługa wyjątków. Odbiorca zdarzeń zwykle przetwarza partię komunikatów w pętli. Należy obsługiwać wyjątki w tej pętli przetwarzania, aby uniknąć utraty całej partii komunikatów, jeśli pojedynczy komunikat powoduje wyjątek.

Użyj kolejki utraconych komunikatów. Jeśli przetwarzanie komunikatu powoduje nieprzejętną awarię, umieść komunikat w kolejce utraconych komunikatów, aby można było śledzić stan. W zależności od scenariusza możesz ponowić próbę późniejszego wykonania komunikatu, zastosować transakcję wyrównywalną lub podjąć inną akcję. Należy pamiętać, że usługa Event Hubs nie ma żadnych wbudowanych funkcji kolejki utraconych komunikatów. Za pomocą usługi Azure Queue Storage lub Service Bus można zaimplementować kolejkę utraconych komunikatów albo użyć usługi Azure Functions lub innego mechanizmu zdarzeń.

Konfigurowanie nadmiarowości strefy. Gdy nadmiarowość strefy jest włączona w przestrzeni nazw, usługa Event Hubs automatycznie replikuje zmiany między wieloma strefami dostępności. Jeśli jedna strefa dostępności zakończy się niepowodzeniem, tryb failover odbywa się automatycznie. Aby uzyskać więcej informacji, zobacz Strefy dostępności.

Zaimplementuj odzyskiwanie po awarii przez przełączenie w tryb failover do pomocniczej przestrzeni nazw usługi Event Hubs. Aby uzyskać więcej informacji, zobacz Odzyskiwanie geograficzne po awarii w usłudze Azure Event Hubs.

Azure Cache for Redis

Konfigurowanie nadmiarowości strefy. Gdy nadmiarowość strefy jest włączona w pamięci podręcznej, usługa Azure Cache for Redis rozdziela maszyny wirtualne hostujące pamięć podręczną w wielu strefach dostępności. Nadmiarowość strefy zapewnia wysoką dostępność i odporność na uszkodzenia w przypadku awarii centrum danych. Aby uzyskać więcej informacji, zobacz Włączanie nadmiarowości stref dla usługi Azure Cache for Redis.

Konfigurowanie replikacji geograficznej. Replikacja geograficzna udostępnia mechanizm łączenia dwóch wystąpień usługi Azure Cache for Redis w warstwie Premium. Dane zapisywane w podstawowej pamięci podręcznej są replikowane do pomocniczej pamięci podręcznej tylko do odczytu. Aby uzyskać więcej informacji, zobacz How to configure geo-replication for Azure Cache for Redis (Jak skonfigurować replikację geograficzną dla usługi Azure Cache for Redis)

Konfigurowanie trwałości danych. Trwałość usługi Redis umożliwia utrwalanie danych przechowywanych w usłudze Redis. Można również tworzyć migawki i tworzyć kopie zapasowe danych, które można załadować w przypadku awarii sprzętu. Aby uzyskać więcej informacji, zobacz How to configure data persistence for a Premium-tier Azure Cache for Redis (Jak skonfigurować trwałość danych dla usługi Azure Cache for Redis w warstwie Premium)

Jeśli używasz usługi Azure Cache for Redis jako tymczasowej pamięci podręcznej danych, a nie jako magazynu trwałego, te zalecenia mogą nie mieć zastosowania.

Cognitive Search

Aprowizuj więcej niż jedną replikę. Użyj co najmniej dwóch replik do odczytu o wysokiej dostępności lub trzech w celu zapewnienia wysokiej dostępności odczytu i zapisu.

Użyj nadmiarowości strefy. Repliki usługi Cognitive Search można wdrożyć w wielu strefach dostępności. Takie podejście ułatwia działanie usługi nawet wtedy, gdy wystąpi awaria centrum danych. Aby uzyskać więcej informacji, zobacz Niezawodność w usłudze Azure Cognitive Search

Konfigurowanie indeksatorów dla wdrożeń w wielu regionach. Jeśli masz wdrożenie w wielu regionach, rozważ opcje ciągłości indeksowania.

• Jeśli źródło danych jest replikowane geograficznie, należy zazwyczaj wskazać każdy indeksator poszczególnych regionalnych usługa wyszukiwania usługi Azure Cognitive do lokalnej repliki źródła danych. Jednak takie podejście nie jest zalecane w przypadku dużych zestawów danych przechowywanych w usłudze Azure SQL Database. Przyczyną jest to, że usługa Azure Cognitive Search nie może wykonywać indeksowania przyrostowego z pomocniczych replik usługi SQL Database tylko z replik podstawowych. Zamiast tego wskaż wszystkie indeksatory do repliki podstawowej. Po przejściu w tryb failover wskaż indeksatory usługi Azure Cognitive Search w nowej repliki podstawowej.

• Jeśli źródło danych nie jest replikowane geograficznie, wskaż wiele indeksatorów w tym samym źródle danych, aby usługa Azure Cognitive usługa wyszukiwania w wielu regionach stale i niezależnie indeksować ze źródła danych. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące wydajności i optymalizacji usługi Azure Search.

Service Bus

Użyj warstwy Premium dla obciążeń produkcyjnych. Obsługa komunikatów usługi Service Bus w warstwie Premium zapewnia dedykowane i zarezerwowane zasoby przetwarzania oraz pojemność pamięci do obsługi przewidywalnej wydajności i przepływności. Warstwa Premium Messaging zapewnia również dostęp do nowych funkcji, które są dostępne tylko dla klientów premium na początku. Możesz zdecydować o liczbie jednostek obsługi komunikatów na podstawie oczekiwanych obciążeń.

Obsługa zduplikowanych komunikatów. Jeśli wydawca zakończy się niepowodzeniem natychmiast po wysłaniu komunikatu lub napotka problemy z siecią lub systemem, może błędnie nie zarejestrować, że komunikat został dostarczony i może wysłać ten sam komunikat do systemu dwa razy. Usługa Service Bus może obsłużyć ten problem, włączając wykrywanie duplikatów. Aby uzyskać więcej informacji, zobacz Wykrywanie duplikatów.

Obsługa wyjątków. Interfejsy API obsługi komunikatów generują wyjątki, gdy wystąpi błąd użytkownika, błąd konfiguracji lub inny błąd. Kod klienta (nadawcy i odbiorcy) powinien obsługiwać te wyjątki w kodzie. Jest to szczególnie ważne w przypadku przetwarzania wsadowego, gdzie można użyć obsługi wyjątków, aby uniknąć utraty całej partii komunikatów. Aby uzyskać więcej informacji, zobacz Wyjątki obsługi komunikatów usługi Service Bus.

Zasady ponawiania prób. Usługa Service Bus umożliwia wybranie najlepszych zasad ponawiania prób dla aplikacji. Domyślne zasady umożliwiają 9 maksymalnych prób ponawiania prób i poczekaj 30 sekund, ale można to jeszcze bardziej dostosować. Aby uzyskać więcej informacji, zobacz Zasady ponawiania prób — Service Bus.

Użyj kolejki utraconych komunikatów. Jeśli nie można przetworzyć ani dostarczyć komunikatu do żadnego odbiorcy po wielu ponownych próbach, zostanie on przeniesiony do kolejki utraconych komunikatów. Zaimplementuj proces odczytywania komunikatów z kolejki utraconych listów, ich inspekcji i korygowania problemu. W zależności od scenariusza możesz ponowić próbę wykonania komunikatu w następujący sposób, wprowadzić zmiany i ponowić próbę lub odrzucić komunikat. Aby uzyskać więcej informacji, zobacz Omówienie kolejek utraconych komunikatów usługi Service Bus.

Użyj nadmiarowości strefy. Gdy nadmiarowość strefy jest włączona w przestrzeni nazw, usługa Service Bus automatycznie replikuje zmiany między wieloma strefami dostępności. Jeśli jedna strefa dostępności zakończy się niepowodzeniem, tryb failover odbywa się automatycznie. Aby uzyskać więcej informacji, zobacz Najlepsze rozwiązania dotyczące izolowania aplikacji przed awariami i awariami usługi Service Bus.

Użyj odzyskiwania po awarii geograficznej. Odzyskiwanie po awarii geograficznej gwarantuje, że przetwarzanie danych będzie nadal działać w innym regionie lub centrum danych, jeśli cały region platformy Azure lub centrum danych stanie się niedostępny z powodu awarii. Aby uzyskać więcej informacji, zobacz Geo-disaster recovery usługi Azure Service Bus.

Storage

Użyj magazynu strefowo nadmiarowego (ZRS). Magazyn strefowo nadmiarowy (ZRS) kopiuje dane synchronicznie w trzech strefach dostępności platformy Azure w regionie podstawowym. Jeśli strefa dostępności wystąpi awaria, usługa Azure Storage automatycznie przełączy się w tryb failover do alternatywnej strefy. Aby uzyskać więcej informacji, zobacz Nadmiarowość usługi Azure Storage.

W przypadku korzystania z nadmiarowości geograficznej skonfiguruj dostęp do odczytu. Jeśli używasz architektury obejmującej wiele regionów, użyj odpowiedniej warstwy magazynowania na potrzeby globalnej nadmiarowości. W przypadku magazynu geograficznie nadmiarowego dostępnego do odczytu (RA-GRS) lub magazynu geograficznie nadmiarowego z dostępem do odczytu (RA-GZRS) dane są replikowane do regionu pomocniczego. Magazyn RA-GRS używa magazynu lokalnie nadmiarowego (LRS) w regionie podstawowym, podczas gdy magazyn RA-GZRS używa magazynu strefowo nadmiarowego (ZRS) w regionie podstawowym. Obie konfiguracje zapewniają dostęp tylko do odczytu do danych w regionie pomocniczym. Jeśli w regionie podstawowym wystąpi awaria magazynu, aplikacja może odczytać dane z regionu pomocniczego, jeśli została zaprojektowana pod kątem tej możliwości. Aby uzyskać więcej informacji, zobacz Nadmiarowość usługi Azure Storage.

W przypadku dysków maszyn wirtualnych użyj dysków zarządzanych.Dyski zarządzane zapewniają lepszą niezawodność maszyn wirtualnych w zestawie dostępności, ponieważ dyski są wystarczająco odizolowane od siebie, aby uniknąć pojedynczych punktów awarii. Ponadto dyski zarządzane nie podlegają limitom liczby operacji we/wy na sekundę wirtualnych dysków twardych utworzonych na koncie magazynu. Aby uzyskać więcej informacji, zobacz Zarządzanie dostępnością maszyn wirtualnych z systemem Windows na platformie Azure.

W przypadku usługi Queue Storage utwórz kolejkę kopii zapasowej w innym regionie. W przypadku usługi Queue Storage replika tylko do odczytu ma ograniczone użycie, ponieważ nie można kolejkować ani dequeue elementów. Zamiast tego utwórz kolejkę kopii zapasowej na koncie magazynu w innym regionie. Jeśli wystąpi awaria usługi Azure Storage, aplikacja może używać kolejki kopii zapasowej, dopóki region podstawowy nie stanie się ponownie dostępny. Dzięki temu aplikacja może nadal przetwarzać nowe żądania podczas awarii.

SQL Database

Użyj warstwy Standardowa lub Premium. Te warstwy zapewniają dłuższy okres przywracania do punktu w czasie (35 dni). Aby uzyskać więcej informacji, zobacz Opcje i wydajność usługi SQL Database.

Włącz inspekcję usługi SQL Database. Inspekcja może służyć do diagnozowania złośliwych ataków lub błędu ludzkiego. Aby uzyskać więcej informacji, zobacz Wprowadzenie do inspekcji bazy danych SQL.

Użyj aktywnej replikacji geograficznej Użyj aktywnej replikacji geograficznej, aby utworzyć pomocniczą z możliwością odczytu w innym regionie. Jeśli podstawowa baza danych ulegnie awarii lub po prostu musi zostać przełączna w tryb offline, wykonaj ręczne przejście w tryb failover do pomocniczej bazy danych. Dopóki nie przełączysz w tryb failover, pomocnicza baza danych pozostanie tylko do odczytu. Aby uzyskać więcej informacji, zobacz Sql Database Active Geo-Replication (Aktywna replikacja geograficzna usługi SQL Database).

Użyj fragmentowania. Rozważ użycie fragmentowania do partycjonowania bazy danych w poziomie. Fragmentowanie może zapewnić izolację błędów. Aby uzyskać więcej informacji, zobacz Skalowanie w górę za pomocą usługi Azure SQL Database.

Użyj przywracania do punktu w czasie, aby odzyskać odzyskiwanie po błędzie człowieka. Przywracanie do punktu w czasie zwraca bazę danych do wcześniejszego punktu w czasie. Aby uzyskać więcej informacji, zobacz Odzyskiwanie bazy danych Azure SQL Database przy użyciu automatycznych kopii zapasowych bazy danych.

Użyj przywracania geograficznego, aby odzyskać dane po awarii usługi. Przywracanie geograficzne przywraca bazę danych z geograficznie nadmiarowej kopii zapasowej. Aby uzyskać więcej informacji, zobacz Odzyskiwanie bazy danych Azure SQL Database przy użyciu automatycznych kopii zapasowych bazy danych.

Azure Synapse Analytics

Nie wyłączaj geograficznej kopii zapasowej. Domyślnie usługa Synapse Analytics wykonuje pełną kopię zapasową danych w dedykowanej puli SQL co 24 godziny na potrzeby odzyskiwania po awarii. Nie zaleca się wyłączania tej funkcji. Aby uzyskać więcej informacji, zobacz Geograficzne kopie zapasowe.

Program SQL Server uruchomiony na maszynie wirtualnej

Tworzenie kopii zapasowej bazy danych. Jeśli używasz już usługi Azure Backup do tworzenia kopii zapasowych maszyn wirtualnych, rozważ użycie usługi Azure Backup dla obciążeń programu SQL Server przy użyciu programu DPM. W tym podejściu istnieje jedna rola administratora kopii zapasowych dla organizacji i ujednolicona procedura odzyskiwania dla maszyn wirtualnych i programu SQL Server. W przeciwnym razie użyj zarządzanej kopii zapasowej programu SQL Server na platformie Microsoft Azure.

Traffic Manager

Wykonaj ręczne powrót po awarii. Po przejściu w tryb failover usługi Traffic Manager wykonaj ręczne powrót po awarii, a nie automatyczne powrót po awarii. Przed powrotem po awarii sprawdź, czy wszystkie podsystemy aplikacji są w dobrej kondycji. W przeciwnym razie możesz utworzyć sytuację, w której aplikacja przerzuca się tam i z powrotem między centrami danych. Aby uzyskać więcej informacji, zobacz Uruchamianie maszyn wirtualnych w wielu regionach w celu zapewnienia wysokiej dostępności.

Utwórz punkt końcowy sondy kondycji. Utwórz niestandardowy punkt końcowy, który raportuje ogólną kondycję aplikacji. Dzięki temu usługa Traffic Manager może przejść w tryb failover, jeśli jakakolwiek ścieżka krytyczna zakończy się niepowodzeniem, a nie tylko frontonem. Punkt końcowy powinien zwrócić kod błędu HTTP, jeśli jakakolwiek krytyczna zależność jest w złej kondycji lub nie jest osiągalna. Nie zgłaszaj jednak błędów dla usług niekrytycznych. W przeciwnym razie sonda kondycji może wyzwolić tryb failover, gdy nie jest potrzebny, tworząc fałszywie dodatnie wyniki. Aby uzyskać więcej informacji, zobacz Monitorowanie punktu końcowego usługi Traffic Manager i przechodzenie w tryb failover.

Virtual Machines

Unikaj uruchamiania obciążenia produkcyjnego na jednej maszynie wirtualnej. Wdrożenie pojedynczej maszyny wirtualnej nie jest odporne na planowaną lub nieplanowaną konserwację. Zamiast tego umieść wiele maszyn wirtualnych w zestawie dostępności lub zestawie skalowania maszyn wirtualnych z modułem równoważenia obciążenia z przodu.

Określ zestaw dostępności podczas aprowizacji maszyny wirtualnej. Obecnie nie ma możliwości dodania maszyny wirtualnej do zestawu dostępności po aprowizacji maszyny wirtualnej. Po dodaniu nowej maszyny wirtualnej do istniejącego zestawu dostępności pamiętaj o utworzeniu karty sieciowej dla maszyny wirtualnej i dodaniu karty sieciowej do puli adresów zaplecza w module równoważenia obciążenia. W przeciwnym razie moduł równoważenia obciążenia nie będzie kierować ruchu sieciowego do tej maszyny wirtualnej.

Umieść każdą warstwę aplikacji w osobnym zestawie dostępności. W aplikacji N-warstwowej nie umieszczaj maszyn wirtualnych z różnych warstw w tym samym zestawie dostępności. Maszyny wirtualne w zestawie dostępności są umieszczane w domenach błędów (FD) i domenach aktualizacji (UD). Jednak aby uzyskać korzyści z nadmiarowości dysków FD i UD, każda maszyna wirtualna w zestawie dostępności musi mieć możliwość obsługi tych samych żądań klientów.

Replikowanie maszyn wirtualnych przy użyciu usługi Azure Site Recovery. Podczas replikowania maszyn wirtualnych platformy Azure przy użyciu usługi Site Recovery wszystkie dyski maszyn wirtualnych są stale replikowane do regionu docelowego asynchronicznie. Punkty odzyskiwania są tworzone co kilka minut. Zapewnia to cel punktu odzyskiwania (RPO) w kolejności minut. Możesz przeprowadzić próbne odzyskiwanie po awarii tyle razy, ile chcesz, bez wpływu na aplikację produkcyjną lub trwającą replikację. Aby uzyskać więcej informacji, zobacz Uruchamianie próbnego odzyskiwania po awarii na platformie Azure.

Wybierz odpowiedni rozmiar maszyny wirtualnej na podstawie wymagań dotyczących wydajności. Podczas przenoszenia istniejącego obciążenia na platformę Azure zacznij od rozmiaru maszyny wirtualnej, który jest najbliżej serwera lokalnego. Następnie zmierz wydajność rzeczywistego obciążenia w odniesieniu do procesora CPU, pamięci i liczby operacji we/wy na sekundę dysku oraz dostosuj rozmiar w razie potrzeby. Pomaga to zapewnić, że aplikacja zachowuje się zgodnie z oczekiwaniami w środowisku chmury. Ponadto, jeśli potrzebujesz wielu kart sieciowych, należy pamiętać o limicie kart interfejsu sieciowego dla każdego rozmiaru.

Użyj dysków zarządzanych dla dysków VHD.Dyski zarządzane zapewniają lepszą niezawodność maszyn wirtualnych w zestawie dostępności, ponieważ dyski są wystarczająco odizolowane od siebie, aby uniknąć pojedynczych punktów awarii. Ponadto dyski zarządzane nie podlegają limitom liczby operacji we/wy na sekundę wirtualnych dysków twardych utworzonych na koncie magazynu. Aby uzyskać więcej informacji, zobacz Zarządzanie dostępnością maszyn wirtualnych z systemem Windows na platformie Azure.

Instalowanie aplikacji na dysku danych, a nie na dysku systemu operacyjnego. W przeciwnym razie można osiągnąć limit rozmiaru dysku.

Tworzenie kopii zapasowych maszyn wirtualnych przy użyciu usługi Azure Backup. Kopie zapasowe chronią przed przypadkową utratą danych. Aby uzyskać więcej informacji, zobacz Ochrona maszyn wirtualnych platformy Azure przy użyciu magazynu usługi Recovery Services.

Włączanie dzienników diagnostycznych. Uwzględnij podstawowe metryki kondycji, dzienniki infrastruktury i diagnostykę rozruchu. Diagnostyka rozruchu może pomóc zdiagnozować błąd rozruchu, jeśli maszyna wirtualna zostanie w stanie nieobsługiwalnym. Aby uzyskać więcej informacji, zobacz Omówienie dzienników diagnostycznych platformy Azure.

Konfigurowanie usługi Azure Monitor. Zbieranie i analizowanie danych monitorowania z maszyn wirtualnych platformy Azure, w tym systemu operacyjnego gościa i obciążeń uruchomionych w nim, zobacz Azure Monitor i Szybki start: Azure Monitor.

Virtual Network

Aby zezwolić na publiczne adresy IP lub zablokować je, dodaj sieciową grupę zabezpieczeń do podsieci. Blokuj dostęp ze strony złośliwych użytkowników lub zezwalaj na dostęp tylko od użytkowników, którzy mają uprawnienia dostępu do aplikacji.

Utwórz niestandardową sondę kondycji. Sondy kondycji modułu równoważenia obciążenia mogą testować protokół HTTP lub TCP. Jeśli maszyna wirtualna uruchamia serwer HTTP, sonda HTTP jest lepszym wskaźnikiem stanu kondycji niż sonda TCP. W przypadku sondy HTTP użyj niestandardowego punktu końcowego, który raportuje ogólną kondycję aplikacji, w tym wszystkie zależności krytyczne. Aby uzyskać więcej informacji, zobacz Omówienie usługi Azure Load Balancer.

Nie blokuj sondy kondycji. Sonda kondycji modułu równoważenia obciążenia jest wysyłana ze znanego adresu IP 168.63.129.16. Nie blokuj ruchu do ani z tego adresu IP w żadnych zasadach zapory ani regułach sieciowej grupy zabezpieczeń. Zablokowanie sondy kondycji spowodowałoby usunięcie maszyny wirtualnej z rotacji przez moduł równoważenia obciążenia.

Włącz rejestrowanie modułu równoważenia obciążenia. Dzienniki pokazują, ile maszyn wirtualnych na zapleczu nie odbiera ruchu sieciowego z powodu nieudanych odpowiedzi sondy. Aby uzyskać więcej informacji, zobacz Log Analytics for Azure Load Balancer (Analiza dzienników dla usługi Azure Load Balancer).