Niezawodność w elastycznej sieci SAN
W tym artykule opisano obsługę niezawodności w usłudze Azure Elastic SAN i opisano zarówno odporność regionalną ze strefami dostępności, jak i odzyskiwaniem po awarii oraz ciągłością działania.
Obsługa strefy dostępności
Strefy dostępności platformy Azure to co najmniej trzy fizycznie oddzielne grupy centrów danych w każdym regionie świadczenia usługi Azure. Centra danych w każdej strefie są wyposażone w niezależną infrastrukturę zasilania, chłodzenia i sieci. W przypadku awarii strefy lokalnej strefy strefy dostępności są zaprojektowane tak, aby w przypadku wystąpienia problemu z jedną strefą usługi regionalne, pojemność i wysoka dostępność są obsługiwane przez pozostałe dwie strefy.
Awarie mogą wahać się od awarii oprogramowania i sprzętu po zdarzenia, takie jak trzęsienia ziemi, powodzie i pożary. Tolerancja awarii jest osiągana z nadmiarowością i logiczną izolacją usług platformy Azure. Aby uzyskać bardziej szczegółowe informacje na temat stref dostępności na platformie Azure, zobacz Regiony i strefy dostępności.
Usługi z obsługą stref dostępności platformy Azure zostały zaprojektowane w celu zapewnienia odpowiedniego poziomu niezawodności i elastyczności. Można je skonfigurować na dwa sposoby. Mogą być strefowo nadmiarowe, z automatyczną replikacją między strefami lub strefami, z wystąpieniami przypiętymi do określonej strefy. Możesz również połączyć te podejścia. Aby uzyskać więcej informacji na temat architektury strefowej i strefowo nadmiarowej, zobacz Rekomendacje na potrzeby korzystania ze stref dostępności i regionów.
Usługa Azure Elastic SAN obsługuje wdrażanie strefy dostępności z magazynem lokalnie nadmiarowym (LRS) i wdrożeniem regionalnym z magazynem strefowo nadmiarowym (ZRS).
Wymagania wstępne
Magazyn LRS i elastyczna sieć SAN ZRS są obecnie dostępne tylko w podzestawie regionów. Aby uzyskać listę regionów, zobacz Cele skalowania dla elastycznej sieci SAN.
Tworzenie zasobu przy użyciu stref dostępności
Aby utworzyć elastyczną sieć SAN z włączoną strefą dostępności, zobacz Wdrażanie elastycznej sieci SAN.
Środowisko strefowe w dół
W przypadku wdrażania elastycznej sieci SAN w przypadku wybrania opcji nadmiarowości magazynu strefowego sieci SAN platforma nie będzie obsługiwana przez platformę bez ręcznej interwencji. Elastyczna sieć SAN korzystająca z magazynu ZRS jest przeznaczona do samonaleczenia i ponownego równoważenia w celu automatycznego korzystania ze stref w dobrej kondycji.
W przypadku wdrożenia elastycznej sieci SAN LRS może być konieczne wdrożenie nowej sieci SAN przy użyciu migawek wyeksportowanych na dyski zarządzane.
Projekt o małych opóźnieniach
Różnice opóźnienia między elastyczną siecią SAN w magazynach LRS i elastyczną siecią SAN w magazynach ZRS nie są szczególnie wysokie. Jednak w przypadku obciążeń wrażliwych na skoki opóźnień należy wziąć pod uwagę elastyczną sieć SAN w magazynach LRS, ponieważ oferuje najmniejsze opóźnienie.
Migracja strefy dostępności
Aby przeprowadzić migrację elastycznej sieci SAN na LRs do magazynu ZRS, należy utworzyć migawki woluminów elastycznej sieci SAN, wyeksportować je do migawek dysków zarządzanych, wdrożyć elastyczną sieć SAN w magazynach ZRS, a następnie utworzyć woluminy w sieci SAN w usłudze ZRS przy użyciu tych migawek dysków. Aby dowiedzieć się, jak używać migawek (wersja zapoznawcza), zobacz Snapshot Azure Elastic SAN volumes (wersja zapoznawcza).
Ciągłość biznesowa i odzyskiwanie po awarii
Odzyskiwanie po awarii dotyczy odzyskiwania po wystąpieniu zdarzeń o dużym wpływie, takich jak klęski żywiołowe lub nieudane wdrożenia, które powodują przestoje i utratę danych. Niezależnie od przyczyny najlepszym rozwiązaniem dla awarii jest dobrze zdefiniowany i przetestowany plan odzyskiwania po awarii oraz projekt aplikacji, który aktywnie obsługuje odzyskiwanie po awarii. Zanim zaczniesz myśleć o tworzeniu planu odzyskiwania po awarii, zobacz Rekomendacje na potrzeby projektowania strategii odzyskiwania po awarii.
Jeśli chodzi o odzyskiwanie po awarii, firma Microsoft korzysta z modelu wspólnej odpowiedzialności. W modelu wspólnej odpowiedzialności firma Microsoft zapewnia dostępność infrastruktury bazowej i usług platformy. Jednocześnie wiele usług platformy Azure nie replikuje automatycznie danych ani nie wraca z regionu, w którym wystąpił błąd, aby przeprowadzić replikację krzyżową do innego regionu z włączoną obsługą. W przypadku tych usług ponosisz odpowiedzialność za skonfigurowanie planu odzyskiwania po awarii, który działa dla obciążenia. Większość usług uruchamianych na platformie Azure jako usługa (PaaS) oferuje funkcje i wskazówki dotyczące obsługi odzyskiwania po awarii. Funkcje specyficzne dla usługi umożliwiają szybkie odzyskiwanie w celu ułatwienia opracowania planu odzyskiwania po awarii.
Odzyskiwanie po awarii w jednym i wielu regionach
W przypadku usługi Azure Elastic SAN odpowiadasz za środowisko odzyskiwania po awarii. Możesz wykonywać migawki woluminów i eksportować je do migawek dysków zarządzanych. Następnie możesz skopiować migawkę przyrostową do nowego regionu w celu przechowywania danych w regionie innym niż region, w którym znajduje się elastyczna sieć SAN. Należy wyeksportować do regionów, które są geograficznie odległe od regionu podstawowego, aby zmniejszyć prawdopodobieństwo wystąpienia awarii wielu regionów.
Wykrywanie, powiadamianie i zarządzanie awariami
Deklaracje awarii można znaleźć w usłudze Service Health — Microsoft Azure.
Wydajność i proaktywna odporność odzyskiwania po awarii
Firma Microsoft i jej klienci działają w ramach modelu wspólnej odpowiedzialności. Wspólna odpowiedzialność oznacza, że w przypadku odzyskiwania po awarii z obsługą klienta (usług odpowiedzialnych za klienta) należy rozwiązać problem z odzyskiwaniem po awarii dla każdej wdrożonej usługi i kontroli. Należy wstępnie określić wszystkie wdrożone usługi, które będą współdziałać z elastyczną siecią SAN. Aby zagwarantować, że odzyskiwanie jest aktywne, należy zawsze wstępnie wdrażać pomocnicze, ponieważ nie ma gwarancji zdolności produkcyjnych w czasie wpływu na tych, którzy nie wstępnie przydzielili.