Share via

Dokumentacja dotycząca niezawodności platformy Azure

  • Artykuł

Niezawodność składa się z dwóch zasad: odporności i dostępności. Celem odporności jest uniknięcie awarii i, jeśli nadal wystąpią, aby przywrócić aplikację do w pełni funkcjonalnego stanu. Celem dostępności jest zapewnienie spójnego dostępu do aplikacji lub obciążenia. Ważne jest, aby zaplanować proaktywną niezawodność na podstawie wymagań aplikacji.

Platforma Azure obejmuje wbudowane usługi niezawodności, których można używać i zarządzać w zależności od potrzeb biznesowych. Niezależnie od tego, czy jest to awaria jednego węzła sprzętowego, awaria na poziomie stojaka, awaria centrum danych, czy awaria regionalna na dużą skalę, platforma Azure oferuje rozwiązania zwiększające niezawodność. Na przykład zestawy dostępności zapewniają dystrybucję maszyn wirtualnych wdrożonych na platformie Azure w wielu izolowanych węzłach sprzętowych w klastrze. Strefy dostępności chronią aplikacje i dane klientów przed awariami centrum danych w wielu lokalizacjach fizycznych w regionie. Regiony i strefy dostępności są kluczowe dla strategii projektowania i odporności aplikacji i zostały szczegółowo omówione w dalszej części tego artykułu.

Dokumentacja niezawodności platformy Azure zawiera wskazówki dotyczące niezawodności usług platformy Azure. Te wskazówki obejmują informacje na temat obsługi strefy dostępności, wskazówek dotyczących odzyskiwania po awarii i dostępności usług.

Aby uzyskać szczegółowe wskazówki dotyczące niezawodności specyficzne dla usługi, w tym strefy dostępności, odzyskiwanie po awarii lub wysoka dostępność, zobacz Omówienie wskazówek dotyczących niezawodności specyficznych dla usługi platformy Azure.

Aby uzyskać informacje na temat zasad niezawodności i niezawodności oraz architektury w usługach platformy Microsoft Azure, zobacz Microsoft Azure Well-Architected Framework: Reliability (Struktura dobrze zaprojektowana przez platformę Microsoft Azure: niezawodność).

Wymagania dotyczące niezawodności

Wymagany poziom niezawodności dla dowolnego rozwiązania platformy Azure zależy od kilku zagadnień. Umowa SLA dotycząca dostępności i opóźnień oraz inne wymagania biznesowe napędzają wybór architektury i poziom odporności i należy je najpierw rozważyć. Wymagania dotyczące dostępności wahają się od tego, ile przestojów jest akceptowalny — i ile kosztuje firma — do ilości pieniędzy i czasu, które można realistycznie zainwestować w zapewnienie wysokiej dostępności aplikacji.

Tworzenie systemów niezawodności na platformie Azure jest wspólną odpowiedzialnością. Firma Microsoft jest odpowiedzialna za niezawodność platformy w chmurze, w tym jej globalną sieć i centra danych. Klienci i partnerzy platformy Azure są odpowiedzialni za odporność aplikacji w chmurze przy użyciu najlepszych rozwiązań dotyczących architektury na podstawie wymagań poszczególnych obciążeń. Podczas gdy platforma Azure stale dąży do największej możliwej odporności w umowie SLA dla platformy w chmurze, musisz zdefiniować własne docelowe umowy SLA dla każdego obciążenia w rozwiązaniu. Umowa SLA umożliwia ocenę, czy architektura spełnia wymagania biznesowe. W miarę dążenia do wyższych wartości procentowych gwarantowanego czasu pracy umowy SLA koszt i złożoność w celu osiągnięcia tego poziomu dostępności rośnie. Czas pracy wynoszący 99,99% przekłada się na około pięć minut całkowitego przestoju miesięcznie. Czy warto uzyskać więcej złożoności i kosztów, aby osiągnąć ten procent? Odpowiedź zależy od indywidualnych wymagań biznesowych. Podejmując decyzję o końcowych zobowiązaniach SLA, zapoznaj się z obsługiwanymi umowami SLA firmy Microsoft. Każda usługa platformy Azure ma własną umowę SLA.

Diagram showing the shared responsibility model for Azure business continuity.

W tradycyjnym modelu lokalnym cała odpowiedzialność za zarządzanie sprzętem obliczeniowym, magazynem i siecią spada na Ciebie. Należy zaplanować różne typy awarii i radzić sobie z nimi, tworząc strategię odzyskiwania po awarii. Dzięki usłudze IaaS dostawca usług w chmurze jest odpowiedzialny za podstawową odporność infrastruktury, w tym magazyn, sieć i zasoby obliczeniowe. W miarę przechodzenia z usług IaaS do PaaS, a następnie do saaS, przekonasz się, że odpowiadasz za mniej, a dostawca usług w chmurze jest odpowiedzialny za więcej.  

Aby uzyskać więcej informacji na temat zasad niezawodności, zobacz Dokumentację dotyczącą niezawodności struktury dobrze zaprojektowanej.  

Niezawodność tworzenia

Na początku planowania należy zdefiniować wymagania dotyczące niezawodności aplikacji. Jeśli wiesz, które aplikacje nie potrzebują 100% wysokiej dostępności w określonych okresach czasu, możesz zoptymalizować koszty w tych okresach niekrytycznych. Zidentyfikuj typ awarii, które może wystąpić aplikacja, oraz potencjalny wpływ każdej awarii. Plan odzyskiwania powinien obejmować wszystkie usługi krytyczne, finalizując strategię odzyskiwania na poszczególnych składnikach i ogólnym poziomie aplikacji. Zaprojektuj strategię odzyskiwania, aby chronić przed awariami strefowymi, regionalnymi i aplikacjami. Przetestuj kompleksowe środowisko aplikacji, aby zmierzyć niezawodność aplikacji i odzyskiwanie przed nieoczekiwanym niepowodzeniem.

Poniższa lista kontrolna obejmuje zakres planowania niezawodności.

Planowanie niezawodności
Zdefiniuj cele dostępności i odzyskiwania, aby spełnić wymagania biznesowe.
Projektowanie funkcji niezawodności aplikacji na podstawie wymagań dotyczących dostępności.
Dopasuj aplikacje i platformy danych, aby spełnić wymagania dotyczące niezawodności.
Skonfiguruj ścieżki połączeń, aby podwyższyć dostępność.
Użyj stref dostępności i planowania odzyskiwania po awarii, jeśli ma to zastosowanie, aby zwiększyć niezawodność i zoptymalizować koszty.
Upewnij się, że architektura aplikacji jest odporna na błędy.
Dowiedz się, co się stanie, jeśli wymagania umowy SLA nie zostaną spełnione.
Zidentyfikuj możliwe punkty awarii w systemie. Projekt aplikacji powinien tolerować awarie zależności przez wdrożenie przerwania obwodu.
Twórz aplikacje, które działają w przypadku braku ich zależności.

Cel czasu odzyskiwania i cel punktu odzyskiwania

Dwoma ważnymi metrykami, które należy wziąć pod uwagę, są cel czasu odzyskiwania i cel punktu odzyskiwania, ponieważ odnoszą się one do odzyskiwania po awarii.  Aby uzyskać więcej informacji na temat wymagań projektowych funkcjonalnych i niefunkcjonalnych, zobacz Dobrze zaprojektowane struktury funkcjonalne i niefunkcjonalne wymagania.

  • Cel czasu odzyskiwania (RTO) to maksymalny dopuszczalny czas, przez który aplikacja może być niedostępna po incydencie.

  • Cel punktu odzyskiwania (RPO) to maksymalny czas trwania utraty danych, który jest dopuszczalny podczas awarii.

Cel czasu odzyskiwania i cel punktu odzyskiwania to wymagania niefunkcjonalne systemu i powinny być podyktowane wymaganiami biznesowymi. Aby uzyskać te wartości, dobrze jest przeprowadzić ocenę ryzyka i jasno zrozumieć koszt przestoju lub utraty danych.  

Regiony i strefy dostępności

Regiony i strefy dostępności stanowią dużą część równania niezawodności. Regiony mają wiele stref dostępności rozdzielonych fizycznie. Te strefy dostępności są połączone przez sieć o wysokiej wydajności z mniejszym opóźnieniem niż 2 ms między strefami fizycznymi. Małe opóźnienie ułatwia synchronizowanie danych i ich dostępność, gdy coś pójdzie nie tak. Tej infrastruktury można używać strategicznie podczas tworzenia architektury aplikacji i infrastruktury danych, która automatycznie replikuje i dostarcza nieprzerwane usługi między strefami i między regionami.

Usługi platformy Microsoft Azure obsługują strefy dostępności i umożliwiają obsługę operacji w chmurze przy optymalnej wysokiej dostępności przy jednoczesnym wspieraniu potrzeb strategii odzyskiwania między regionami i ciągłości działania.

W przypadku planowania odzyskiwania po awarii regiony sparowane z innymi regionami oferują replikację między regionami i zapewniają ochronę przez asynchroniczne replikowanie danych w innych regionach świadczenia usługi Azure. Regiony bez pary są zgodne z wytycznymi dotyczącymi rezydencji danych i oferują wysoką dostępność ze strefami dostępności oraz magazynem lokalnie nadmiarowym lub strefowo nadmiarowym. Klienci będą musieli zaplanować odzyskiwanie po awarii w wielu regionach na podstawie potrzeb celu punktu odzyskiwania/celu punktu odzyskiwania.

Wybierz najlepszy region dla Twoich potrzeb w oparciu o zagadnienia techniczne i prawne — możliwości usług, miejsce przechowywania danych, wymagania dotyczące zgodności, opóźnienie i rozpocznij rozwijanie strategii niezawodności. Aby uzyskać więcej informacji, zobacz Regiony platformy Azure i strefy dostępności.

Zależności usług platformy Azure

Usługi platformy Microsoft Azure są dostępne globalnie, aby napędzać operacje w chmurze na optymalnym poziomie.

Usługi platformy Azure wdrożone w regionach platformy Azure są wyświetlane na stronie globalnych produktów infrastruktury platformy Azure. Aby lepiej zrozumieć regiony i Strefy dostępności na platformie Azure, zobacz Regiony i Strefy dostępności na platformie Azure.

Usługi platformy Azure są tworzone pod kątem niezawodności, w tym wysokiej dostępności i odzyskiwania po awarii. Brak usług zależnych od pojedynczego logicznego centrum danych (aby uniknąć pojedynczych punktów awarii). Usługi inne niż regionalne wymienione w globalnych produktach infrastruktury platformy Azure to usługi, dla których nie ma zależności od określonego regionu świadczenia usługi Azure. Usługi inne niż regionalne są wdrażane w co najmniej dwóch regionach i jeśli wystąpi awaria regionalna, wystąpienie usługi w innym regionie kontynuuje obsługę klientów. Niektóre usługi inne niż regionalne umożliwiają klientom określenie regionu, w którym zostanie wdrożona podstawowa maszyna wirtualna. Na przykład usługa Azure Virtual Desktop umożliwia klientom określenie lokalizacji regionu, w którym znajduje się maszyna wirtualna. Wszystkie usługi platformy Azure, które przechowują dane klienta, umożliwiają klientowi określenie określonych regionów, w których będą przechowywane ich dane. Wyjątkiem jest microsoft Entra ID, który ma położenie geograficzne (takie jak Europa lub Ameryka Północna). Aby uzyskać więcej informacji na temat rezydencji magazynu danych, zobacz mapę Miejsca przechowywania danych.

Jeśli musisz zrozumieć zależności między usługami platformy Azure, aby lepiej zaprojektować aplikacje i usługi, możesz poprosić o dokumentację zależności usług platformy Azure, kontaktując się z przedstawicielem działu sprzedaży lub klienta firmy Microsoft. Ten dokument zawiera listę zależności dla usług platformy Azure, w tym zależności od wszystkich typowych usług wewnętrznych, takich jak usługi płaszczyzny sterowania. Aby uzyskać tę dokumentację, musisz być klientem firmy Microsoft i mieć odpowiednią umowę o zachowaniu poufności (NDA) z firmą Microsoft.

Następne kroki