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 Azure App Service

Unikaj skalowania w górę lub w dół. Zamiast tego wybierz warstwę i rozmiar wystąpienia, który spełnia wymagania dotyczące wydajności w ramach typowego obciążenia, a następnie skaluj wystąpienia w poziomie 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. Użyj ustawień aplikacji, aby przechowywać ustawienia konfiguracji jako ustawienia aplikacji. Zdefiniuj ustawienia w szablonach 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 Azure App Service.

Utwórz oddzielne plany 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 App Service współdzielą te same wystąpienia maszyn wirtualnych. Jeśli umieścisz wdrożenia produkcyjne i testowe 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ż rozdzielenie ich na oddzielne aplikacje 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 App Service, aby można je było skalować niezależnie. Jeśli na początku nie potrzebujesz takiego poziomu skalowalności, możesz wdrożyć aplikacje w tym samym planie i przenieść je do oddzielnych planów później, w razie potrzeby.

Unikaj używania funkcji tworzenia kopii zapasowych App Service do tworzenia kopii zapasowych Azure SQL baz danych. Zamiast tego należy użyć SQL Database automatycznych kopii zapasowych. App Service kopii zapasowej eksportuje bazę danych do pliku BACPAC SQL, który kosztuje jednostki DTU.

Wdrażanie 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 również, że wszystkie wystąpienia są rozgrzane przed zamianą na środowisko produkcyjne. Wiele aplikacji ma znaczący czas rozgrzewki i zimnego uruchamiania. Aby uzyskać więcej informacji, zobacz Konfigurowanie środowisk przejściowych dla aplikacji internetowych w Azure App Service.

Utwórz miejsce wdrożenia do przechowywania ostatniego znanego dobrego 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 Azure App 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 Insights , 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łównych przyczyn błędów.

Azure Load Balancer

Wybierz usługa Load Balancer w warstwie Standardowa jednostki SKU w warstwie Standardowa zapewnia wymiar niezawodności, którego nie ma w warstwie Podstawowa — stref dostępności i odporności stref. Oznacza to, że gdy strefa ulegnie awarii, strefowo nadmiarowe usługa Load Balancer w warstwie Standardowa nie będzie miało to 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, zapewniając, że aplikacja nie ma wpływu na awarie regionów.

Aprowizuj co najmniej dwa wystąpienia Wdrażanie modułu 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 skompilowania na potrzeby skalowania warto sparować moduł równoważenia obciążenia z Virtual Machine Scale Sets.

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

Application Gateway

Aprowizuj co najmniej dwa wystąpienia. Wdrażanie 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 SLA, musisz aprowizować co najmniej dwa średnie lub większe wystąpienia.

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 w regionie zapisu wystąpi błąd, 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ć swoje bieżące położenie 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 odbiorca zdarzenia 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ę komunikatu później, zastosować transakcję wyrównowczą lub podjąć inną akcję. Należy pamiętać, że usługa Event Hubs nie ma wbudowanych funkcji kolejki utraconych komunikatów. Za pomocą usługi Azure Queue Storage lub Service Bus można zaimplementować kolejkę utraconych komunikatów lub użyć Azure Functions lub innego mechanizmu zdarzeń.

Zaimplementuj odzyskiwanie po awarii, przechodząc w tryb failover do pomocniczej przestrzeni nazw usługi Event Hubs. Aby uzyskać więcej informacji, zobacz Azure Event Hubs Odzyskiwanie po awarii geograficznej.

Azure Cache for Redis

Konfigurowanie replikacji geograficznej. Replikacja geograficzna zapewnia mechanizm łączenia dwóch wystąpień Azure Cache for Redis warstwy 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 Jak skonfigurować replikację geograficzną dla Azure Cache for Redis

Konfigurowanie trwałości danych. Trwałość usługi Redis umożliwia utrwalanie danych przechowywanych w usłudze Redis. Możesz 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 Jak skonfigurować trwałość danych dla Azure Cache for Redis warstwy Premium

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

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.

Skonfiguruj indeksatory dla wdrożeń w wielu regionach. Jeśli masz wdrożenie obejmujące wiele regionów, rozważ opcje ciągłości indeksowania.

  • Jeśli źródło danych jest replikowane geograficznie, zazwyczaj należy wskazać każdy indeksator każdego regionalnego usługa wyszukiwania platformy Azure do repliki lokalnego ź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. Powodem jest to, że usługa Azure Search nie może wykonywać indeksowania przyrostowego z replik pomocniczych 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 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ługi Azure Search 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 w warstwie Premium usługi Service Bus zapewnia dedykowane i zarezerwowane zasoby przetwarzania oraz pojemność pamięci w celu zapewnienia przewidywalnej wydajności i przepływności. Warstwa Obsługi komunikatów w warstwie Premium zapewnia również dostęp do nowych funkcji, które są dostępne tylko dla klientów w warstwie 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 nie powiedzie się natychmiast po wysłaniu komunikatu lub wystąpi 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 to zezwalać na maksymalnie 9 prób ponawiania prób i czekać przez 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 wiadomości. Jeśli nie można przetworzyć ani dostarczyć komunikatu do żadnego odbiorcy po wielu ponownych próbach, zostanie przeniesiony do kolejki utraconych wiadomości. Zaimplementuj proces odczytywania komunikatów z kolejki utraconych wiadomości, inspekcji ich i korygowania problemu. W zależności od scenariusza możesz ponowić próbę ponowienia komunikatu, 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 Geo-Disaster Recovery. Odzyskiwanie po awarii geograficznej gwarantuje, że przetwarzanie danych będzie nadal działać w innym regionie lub w innym 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 Azure Service Bus Odzyskiwanie po awarii geograficznej.

Storage

W przypadku danych aplikacji użyj magazynu geograficznie nadmiarowego dostępu do odczytu (RA-GRS). Magazyn RA-GRS replikuje dane do regionu pomocniczego i zapewnia dostęp tylko do odczytu z regionu pomocniczego. Jeśli w regionie podstawowym występuje awaria magazynu, aplikacja może odczytać dane z regionu pomocniczego. Aby uzyskać więcej informacji, zobacz Replikacja 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 magazynu, aplikacja może użyć kolejki kopii zapasowej, dopóki region podstawowy nie stanie się ponownie dostępny. W ten sposób aplikacja może nadal przetwarzać nowe żądania.

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 SQL Database opcje i wydajność.

Włącz inspekcję 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żywanie aktywnej replikacji geograficznej Użyj aktywnej Geo-Replication, aby utworzyć pomocniczą czytelną w innym regionie. Jeśli podstawowa baza danych ulegnie awarii lub po prostu musi zostać przełączony 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 aktywne replikacji geograficznej.

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 Scaling out with Azure SQL Database (Skalowanie w górę za pomocą bazy danych Azure SQL).

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 przy użyciu automatycznych kopii zapasowych bazy danych.

Użyj przywracania geograficznego, aby odzyskać odzyskiwanie 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 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 co 24 godziny na potrzeby odzyskiwania po awarii. Nie zaleca się wyłączania tej funkcji. Aby uzyskać więcej informacji, zobacz Geo-backups (Kopie zapasowe geograficzne).

SQL Server uruchomione na maszynie wirtualnej

Replikuj bazę danych. Użyj SQL Server zawsze włączonych grup dostępności, aby replikować bazę danych. Zapewnia wysoką dostępność, jeśli jedno wystąpienie SQL Server zakończy się niepowodzeniem. Aby uzyskać więcej informacji, zobacz Run Windows VMs for an N-tier application (Uruchamianie maszyn wirtualnych z systemem Windows dla aplikacji N-warstwowej)

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

Traffic Manager

Wykonaj ręczne powrót po awarii. Po przejściu do trybu failover usługi Traffic Manager wykonaj ręczne powrót po awarii, a nie automatycznie 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ę z powrotem 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 jest niedostępna. Nie zgłaszaj jednak błędów dla usług niekrytycznych. W przeciwnym razie sonda kondycji może wyzwolić tryb failover, gdy nie jest to konieczne, 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. Pojedyncze wdrożenie maszyny wirtualnej nie jest odporne na planowaną lub nieplanowaną konserwację. Zamiast tego należy umieścić 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ń klienta.

Replikowanie maszyn wirtualnych przy użyciu usługi Azure Site Recovery. Podczas replikacji maszyn wirtualnych platformy Azure przy użyciu Site Recovery wszystkie dyski maszyn wirtualnych są stale replikowane do regionu docelowego asynchronicznie. Punkty odzyskiwania są tworzone co kilka minut. Daje 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 karty sieciowej 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.

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

Użyj Azure Backup do tworzenia kopii zapasowych maszyn wirtualnych. 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ć awarię 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 od 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. Load Balancer sondy kondycji 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 Azure Load Balancer.

Nie blokuj sondy kondycji. Sonda kondycji Load Balancer 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 Load Balancer. Dzienniki pokazują, ile maszyn wirtualnych na zapleczu nie odbiera ruch sieciowy z powodu nieudanych odpowiedzi sondy. Aby uzyskać więcej informacji, zobacz Log Analytics for Azure Load Balancer(Analiza dzienników dla Azure Load Balancer).