Co to jest nadmiarowość, replikacja i kopia zapasowa?

Często myślimy o chmurze jako globalnie rozproszonym, wszechobecnym systemie. Jednak w rzeczywistości chmura składa się ze sprzętu działającego w centrach danych. Odporność wymaga, aby uwzględnić niektóre zagrożenia związane z lokalizacjami fizycznymi, w których działają składniki hostowane w chmurze.

Ten artykuł zawiera ogólne wprowadzenie do nadmiarowości, replikacji i tworzenia kopii zapasowych, które są metodami używanymi do tworzenia obciążeń odpornych na zagrożenia fizyczne powodujące przerwy w działaniu usługi, awarii lub utracie danych.

Nadmiarowość to możliwość obsługi wielu identycznych kopii składnika usługi i używania tych kopii w sposób uniemożliwiający, że każdy składnik staje się pojedynczym punktem awarii.

Replikacja lub nadmiarowość danych to możliwość obsługi wielu kopii danych nazywanych replikami.

Tworzenie kopii zapasowej to możliwość tworzenia i przechowywania kopii danych z sygnaturą czasową, których można użyć do przywrócenia utraconych danych.

Z punktu widzenia niezawodności ważnym sposobem ograniczenia wielu zagrożeń jest uwzględnienie jakiejś formy nadmiarowości, replikacji lub tworzenia kopii zapasowych w planowaniu ciągłości działania.

Redundancja

Redundancja polega na wdrażaniu wielu wystąpieńkomponentu. Chociaż redundancja jest prosta do zrozumienia, w niektórych sytuacjach może stać się trudna do wdrożenia.

Gdy zaczynasz rozumieć nadmiarowość, najłatwiej jest rozważyć nadmiarowość w odniesieniu do składników bezstanowych, które nie przechowują żadnych danych. Chociaż większość rzeczywistych rozwiązań wymaga zarządzania stanem, w tej sekcji omawiamy nadmiarowość pod względem przykładowego bezstanowego interfejsu programowania aplikacji (API). Przykładowy interfejs API akceptuje dane wejściowe, działa na tych danych wejściowych, a następnie zwraca dane wyjściowe bez przechowywania żadnych danych. W kolejnej sekcji Replikacja: nadmiarowość danych dodamy zagadnienia dotyczące nadmiarowości stanowej.

Scenariusz: redundancja bezstanowa

W tym przykładzie składnik bezstanowego interfejsu API jest wdrażany na maszynie wirtualnej. Aby uniknąć przestoju komponentu API w przypadku awarii sprzętowej na hoście fizycznym, w przykładzie wdrażane jest nadmiarowe rozwiązanie, które:

• Wdraża liczne kopie wystąpienia interfejsu API.
• Implementuje moduł równoważenia obciążenia w celu dystrybuowania żądań między wystąpieniami interfejsu API.

Moduł równoważenia obciążenia monitoruje kondycję każdej instancji, aby móc wysyłać żądania tylko do zdrowych instancji.

Zagadnienia dotyczące nadmiarowości

Podczas implementowania nadmiarowych rozwiązań, takich jak w powyższym scenariuszu, należy wziąć pod uwagę następujące kwestie:

• Koszty zasobów. Z definicji nadmiarowość obejmuje posiadanie wielu kopii czegoś, co zwiększa całkowity koszt hostowania rozwiązania.

• Wydajność. Im szerszy obszar geograficzny obejmuje dystrybucja kopii elementów, tym więcej zagrożeń pomagasz zredukować. Jednak zapytania od klientów będą potrzebować więcej czasu na pokonanie dłuższych odległości, ponieważ muszą przejść przez bardziej rozbudowaną infrastrukturę sieci, co zwiększa opóźnienie sieci.

  W większości rzeczywistych sytuacji opóźnienie sieci jest niekonsekwencyjne w krótkich odległościach, takich jak w centrum danych, a nawet między centrami danych w całym mieście. Jednak jeśli dystrybuujesz kopie na dużą odległość, opóźnienie sieci może stać się bardziej znaczące.

• Spójność wystąpień. Ważne jest, aby wystąpienia były spójne ze sobą i unikać indywidualnego konfigurowania wystąpień, ponieważ mogą wystąpić przypadkowe różnice między wystąpieniami. Jeśli istnieją różnice między wystąpieniami, żądania mogą być przetwarzane inaczej w zależności od tego, które wystąpienie je obsługuje. Może to spowodować trudne do zdiagnozowania usterek i zachowań.

• Rozkład pracy. Jeśli masz wiele wystąpień składnika, musisz dystrybuować między nimi pracę. Możesz równomiernie rozłożyć pracę na wszystkie wystąpienia lub wysłać żądania do pojedynczego wystąpienia podstawowego i użyć tylko wystąpienia pomocniczego, jeśli wystąpienie podstawowe jest niedostępne.

  Dla składników, które odbierają żądania przychodzące, moduły równoważenia obciążenia są często stosowane, aby przekazywać te żądania do odpowiednich egzemplarzy. Jednak czasami składniki działają niezależnie i nie odbierają żądań od klientów, więc w takich sytuacjach wystąpienia mogą wymagać koordynowania pracy ze sobą.

• Monitorowanie kondycji. Stan każdej instancji decyduje, czy ta instancja może wykonywać swoją pracę, a monitorowanie stanu jest ważne, aby umożliwić szybkie przywracanie, jeśli wystąpi problem.

  Moduły równoważenia obciążenia zwykle wykonują monitorowanie kondycji. W przypadku składników, które nie zawierają modułu równoważenia obciążenia, może istnieć składnik zewnętrzny, który monitoruje kondycję wszystkich wystąpień, lub każde wystąpienie może monitorować kondycję innych wystąpień.

Lokalizacje fizyczne w chmurze

Konieczność nadmiarowości jest jasna, gdy rozumiesz, że nawet w środowisku chmury instancja lub fragment danych są przechowywane w określonej lokalizacji fizycznej.

Na przykład:

• Maszyna wirtualna jest uruchamiana w jednym miejscu fizycznym w dowolnym momencie.
• Dane są przechowywane w określonej lokalizacji fizycznej, na przykład na dysku półprzewodnikowym (SSD) lub dysku twardym podłączonym do serwerów.

Nawet jeśli istnieje wiele kopii danych lub wystąpień składnika, każda kopia jest powiązana z fizycznym sprzętem, na który jest przechowywany.

Fizyczna lokalizacja środowiska chmury jako całość może być zorganizowana w zakresy fizyczne. W każdym zakresie fizycznym istnieją potencjalne zagrożenia, które mogą naruszyć bezpieczeństwo składników lub danych w tym zakresie. Niewyczerpująca lista ryzyk, które można zdefiniować w zakresie fizycznym:

Z perspektywy niezawodności ważnym sposobem ograniczenia ryzyka związanego z zakresem fizycznym jest rozłożenie wystąpień składnika w różnych zakresach fizycznych. Usługi platformy Azure z wbudowaną nadmiarowością mogą oferować jeden lub więcej z poniższych trzech sposobów wdrożenia dodatkowych instancji:

• Lokalna nadmiarowość umieszcza wystąpienia w wielu częściach jednego centrum danych platformy Azure i chroni przed awariami sprzętowymi, które mogą mieć wpływ na pojedyncze wystąpienie. Nadmiarowość lokalna zwykle zapewnia najniższy koszt i opóźnienie. Jednak awaria centrum danych może oznaczać, że wszystkie wystąpienia są niedostępne.

• Redundancja strefowa rozkłada wystąpienia w wielu strefach dostępności w jednym regionie Azure. Nadmiarowość strefy chroni przed awariami centrum danych, a także awariami sprzętowymi.

• Nadmiarowość geograficzna umieszcza wystąpienia w wielu regionach świadczenia usługi Azure i zapewnia ochronę przed awariami regionalnymi na dużą skalę. Redundancja geograficzna wiąże się z wyższymi kosztami i wymaga rozważenia projektu całościowego rozwiązania oraz sposobu przełączania między wystąpieniami składników w każdym regionie. Należy również rozważyć opóźnienie opisane w temacie Replikacja synchroniczna i asynchroniczna.

Jak działa nadmiarowość na platformie Azure: usługi obliczeniowe

Nadmiarowość jest stosowana w prawie każdej części platformy Azure. Jako przykład sposobu implementowania nadmiarowości platformy Azure należy wziąć pod uwagę usługi, które uruchamiają obciążenia obliczeniowe.

Na platformie Azure pojedyncza maszyna wirtualna jest uruchamiana na jednym hoście fizycznym w centrum danych platformy Azure. Możesz podać instrukcje dla platformy Azure, aby upewnić się, że maszyna wirtualna działa w oczekiwanym miejscu, takim jak region i strefa dostępności, a w niektórych sytuacjach możesz nawet umieścić ją na hoście przeznaczonym dla Ciebie.

Często uruchamia się wiele wystąpień maszyny wirtualnej. W tym scenariuszu można wybrać opcję zarządzania nimi pojedynczo lub przy użyciu zestawu skalowania maszyn wirtualnych. W przypadku korzystania z zestawu skalowania nadal można zobaczyć poszczególne maszyny wirtualne, które są jej podstawą, ale zestaw skalowania zapewnia szereg możliwości ułatwiających zarządzanie nadmiarowymi maszynami wirtualnymi. Te możliwości obejmują automatyczne umieszczanie maszyn wirtualnych na podstawie określonych reguł, takich jak rozłożenie ich między domeny błędów w regionie lub strefie dostępności.

Istnieje wiele innych usług obliczeniowych platformy Azure, które polegają na maszynach wirtualnych do wykonywania zadań obliczeniowych. Usługi obliczeniowe zazwyczaj oferują różne ustawienia nadmiarowości, które określają sposób dystrybucji maszyn wirtualnych. Na przykład usługa może zapewnić ustawienie nadmiarowości strefy, które można włączyć w celu automatycznego rozmieszczania maszyn wirtualnych między strefami dostępności i konfigurowania równoważenia obciążenia.

Replikacja: nadmiarowość danych

Nadmiarowość, gdy jest stosowana do stanu (danych), jest nazywana replikacją. Dzięki replikacji, można utrzymywać wiele kopii danych na żywo w czasie rzeczywistym lub niemal w czasie rzeczywistym, nazywanych replikami. Aby zwiększyć odporność na zagrożenia, można dystrybuować repliki w różnych lokalizacjach. Jeśli jedna replika stanie się niedostępna, system może przejść w tryb failover , aby inna replika przejąła jego funkcję.

Istnieją różne typy replikacji, a każde z nich nakłada różne priorytety na spójność, wydajność i koszty danych. Każdy typ replikacji ma wpływ na dwie kluczowe metryki używane w dyskusjach na temat ciągłości działania: cel czasu odzyskiwania (RTO), który jest maksymalną ilością przestojów, które można tolerować w scenariuszu awarii, oraz cel punktu odzyskiwania (RPO), który jest maksymalną ilością utraty danych, które można tolerować w scenariuszu awarii. Aby dowiedzieć się więcej o tych metrykach i sposobie ich powiązania z ciągłością działania, zobacz Co to są ciągłość działalności biznesowej, wysoka dostępność i odzyskiwanie po awarii?.

Ze względu na znaczenie replikacji w spełnieniu wymagań funkcjonalnych i wydajności większość systemów baz danych i innych produktów i usług magazynu danych obejmuje pewnego rodzaju replikację jako ściśle zintegrowaną funkcję. Typy oferowanej przez nie replikacji są zwykle oparte na ich architekturze i sposobach ich użycia. Aby dowiedzieć się więcej o typach replikacji obsługiwanych przez usługi platformy Azure, zobacz Przewodniki dotyczące niezawodności usług platformy Azure.

Replikacja synchroniczna i asynchroniczna

Podczas replikowania danych wszelkie zmiany w tych danych muszą być synchronizowane między replikami. Podczas próby zachowania spójności podczas zmiany danych występuje kilka podstawowych wyzwań:

• Opóźnienie. Aktualizowanie repliki zajmuje trochę czasu, a im dalej od siebie znajdują się repliki, tym dłużej trwa przesyłanie danych na odległość między replikami i odbieranie potwierdzenia.

• Zarządzanie zmianami. Dane mogą ulec zmianie, gdy repliki są synchronizowane, a więc zarządzanie spójnością danych może stać się złożone.

Aby sprostać tym wyzwaniom, istnieją dwa główne sposoby replikowania zmian danych i zarządzania spójnością danych:

• Replikacja synchroniczna wymaga aktualizacji w wielu replikach, zanim aktualizacja zostanie uznana za ukończoną. Na poniższym diagramie przedstawiono sposób działania replikacji synchronicznej:

  

  W tym przykładzie wykonywana jest następująca sekwencja kroków:

  1. Klient zmienia dane, a żądanie jest wysyłane do repliki 1, która przetwarza żądanie i przechowuje zmienione dane.
  2. Replika 1 wysyła zmiany do repliki 2, która przetwarza żądanie i przechowuje zmienione dane.
  3. Replika 2 potwierdza zmianę z powrotem do repliki 1.
  4. Replika 1 potwierdza zmianę klientowi.

  Replikacja synchroniczna może zagwarantować spójność, co oznacza, że może obsługiwać RPO o wartości zero. Jednak wiąże się to z kosztem wydajności. Im większa geograficzna odległość między replikami i im więcej przeskoków sieciowych do pokonania, tym większe opóźnienie wprowadzi proces replikacji.

• Replikacja asynchroniczna odbywa się w tle. Na poniższym diagramie przedstawiono sposób działania replikacji asynchronicznej:

  

  W tym przykładzie wykonywana jest następująca sekwencja kroków:

  1. Klient zmienia dane, a żądanie jest wysyłane do repliki 1.
  2. Replika 1 przetwarza żądanie, przechowuje zmienione dane i natychmiast potwierdza zmianę z powrotem do klienta.
  3. W późniejszym czasie replika 1 zsynchronizuje zmianę z repliką 2.

  Ponieważ replikacja asynchroniczna odbywa się poza przepływami transakcji, usuwa replikację jako ograniczenie wydajności aplikacji. Jeśli jednak konieczne jest przełączenie w tryb failover do innej repliki, może nie zawierać najnowszych danych, dlatego cel punktu odzyskiwania musi być większy niż zero. Dokładny punkt odzyskiwania, który może obsługiwać replikacja asynchroniczna, zależy od częstotliwości replikacji.

Role repliki

W wielu systemach replikacji repliki mogą pełnić różne role, co pomaga koordynować zmiany danych i zmniejszać prawdopodobieństwo konfliktów. Istnieją dwa główne typy ról, aktywne i pasywne. Istnieją dwa typowe sposoby dystrybucji replik przy użyciu tych ról:

• Replikacja aktywna-pasywna oznacza, że masz jedną aktywną replikę, która jest odpowiedzialna za działanie jako źródło prawdy. Wszelkie zmiany wprowadzone w danych muszą być stosowane do tej repliki. Wszystkie inne repliki działają w roli pasywnej , co oznacza, że otrzymują aktualizacje danych z aktywnej repliki, ale nie przetwarzają zmian bezpośrednio z klientów. Repliki pasywne nie są używane do obsługi ruchu, chyba że nastąpi przejście w tryb failover i zmienią się role replik. Na poniższym diagramie przedstawiono system aktywny-pasywny z jedną repliką pasywną:

  

  W systemie aktywny-pasywny czas potrzebny na awaryjne przełączenie określa cel czasu odzyskiwania (RTO). Często RTO dla systemu aktywno-pasywnego jest mierzony w minutach.

  Niektóre rozwiązania replikacji obsługują również repliki tylko do odczytu, co umożliwia odczytywanie (ale nie zapisu) danych z replik pasywnych. Takie podejście może być przydatne w celu uzyskania większego wykorzystania z replik, takich jak w przypadku konieczności przeprowadzenia analizy lub raportowania danych bez wpływu na replikę podstawową używaną na potrzeby transakcyjnej pracy aplikacji. Kilka usług platformy Azure obsługuje repliki tylko do odczytu, w tym usługę Azure Storage z dostępem do odczytu GRS (RA-GRS) typu replikacji i aktywną replikację geograficzną usługi Azure SQL Database.

• Replikacja aktywna-aktywna umożliwia jednoczesne korzystanie z wielu aktywnych replik do obsługi ruchu na żywo, a każda replika może przetwarzać żądania.

  

  Replikacja aktywna-aktywna umożliwia wysoki poziom wydajności, ponieważ system może używać zasobów we wszystkich replikach. Replikacja aktywna-aktywna może umożliwiać osiągnięcie zerowego celu czasu odzyskiwania w niektórych sytuacjach. Jednak te korzyści wiążą się z komplikowaniem spójności danych, ponieważ jednoczesne konkurencyjne zmiany w wielu replikach mogą być uzgadniane asynchronicznie.

Złożone usługi danych mogą łączyć replikację aktywne-aktywne i aktywne-pasywne. Mogą na przykład wdrożyć jeden zestaw replik w jednym regionie świadczenia usługi Azure, a drugi w innym regionie. W każdym regionie pojedyncza aktywna replika obsługuje żądania, podczas gdy co najmniej jedna pasywna replika czeka w gotowości na przełączenie awaryjne. Tymczasem oba regiony działają w modelu aktywny-aktywny, co pozwala na dystrybucję ruchu między nimi.

Jak działa replikacja w usługach danych platformy Azure

Każda usługa platformy Azure, która przechowuje dane, oferuje jakąś formę replikacji. Jednak każda usługa może użyć innego podejścia specyficznego dla architektury usługi i zamierzonego użycia.

Na przykład usługa Azure Storage może zapewnić replikację synchroniczną i asynchroniczną za pomocą zestawu funkcji:

• Wiele kopii twoich danych jest replikowanych synchronicznie w regionie podstawowym. Możesz wybrać, czy umieścić repliki na innym sprzęcie fizycznym w jednym centrum danych w magazynie lokalnie nadmiarowym (LRS) lub rozłożyć je w wielu strefach dostępności dla magazynu strefowo nadmiarowego (ZRS).
• Jeśli region podstawowy jest sparowany i włączysz magazyn geograficznie nadmiarowy (GRS), dane są również replikowane do sparowanego regionu. Ponieważ sparowane regiony są geograficznie odległe, ta replikacja odbywa się asynchronicznie, aby zmniejszyć wpływ na przepływność aplikacji.
• Możesz skorzystać z przechowywania z nadmiarowością strefową i przechowywania z nadmiarowością geograficzną jednocześnie, używając warstwy przechowywania z nadmiarowością strefowo-geograficzną (GZRS). Dane w regionie są replikowane synchronicznie, a dane między regionami są replikowane asynchronicznie.

Aby uzyskać więcej informacji, zobacz Nadmiarowość usługi Azure Storage.

Innym przykładem jest usługa Azure Cosmos DB, która zapewnia również replikację. Wszystkie bazy danych usługi Azure Cosmos DB mają wiele replik. W przypadku globalnej dystrybucji replik obsługuje zapisy w wielu regionach jednocześnie, gdzie klienci mogą zapisywać dane do replik w dowolnym z tych regionów. Te operacje zapisu są synchronicznie replikowane w regionie, a następnie replikowane asynchronicznie w innych regionach. Usługa Azure Cosmos DB udostępnia mechanizm rozwiązywania konfliktów w przypadku wystąpienia konfliktów w różnych replikach. Aby dowiedzieć się więcej, zobacz Globalna dystrybucja danych za pomocą usługi Azure Cosmos DB — pod maską.

Jeśli używasz maszyn wirtualnych, możesz użyć usługi Azure Site Recovery do replikowania maszyn wirtualnych i ich dysków między strefami dostępności lub do innego regionu świadczenia usługi Azure.

Podczas projektowania rozwiązania platformy Azure zapoznaj się z przewodnikami dotyczącymi niezawodności dla każdej usługi , aby dowiedzieć się, w jaki sposób usługa zapewnia nadmiarowość i replikację, w tym w różnych lokalizacjach.

Kopia zapasowa

Kopia zapasowa pobiera kopię danych w określonym punkcie w czasie. Jeśli wystąpi problem, możesz przywrócić kopię zapasową później. Jednak wszelkie zmiany danych, które wystąpiły po utworzeniu kopii zapasowej, nie będą znajdować się w kopii zapasowej i mogą zostać utracone.

Korzystając z kopii zapasowych, możesz udostępnić rozwiązania do tworzenia kopii zapasowych i odzyskiwania danych w chmurze platformy Microsoft Azure lub do chmury platformy Microsoft Azure. Tworzenie kopii zapasowej może chronić cię przed różnymi zagrożeniami, w tym:

• Katastrofalne straty sprzętu lub innej infrastruktury.
• Uszkodzenie i usunięcie danych.
• Cyberataki, takie jak ransomware.

Jak kopia zapasowa wpływa na wymagania

W przypadku użycia w ramach strategii odzyskiwania po awarii kopie zapasowe zwykle obsługują RTO (cel czasu odzyskiwania) i RPO (cel punktu odzyskiwania) mierzone w godzinach:

• Czas celu odzyskiwania zależy od czasu potrzebnego do zainicjowania i zakończenia procesów odzyskiwania, w tym przywrócenia kopii zapasowej i potwierdzenia, że przywracanie zostało pomyślnie zakończone. W zależności od rozmiaru kopii zapasowej i liczby plików kopii zapasowej, z których trzeba odczytać, często trwa to kilka godzin lub nawet dłużej, aby w pełni przywrócić kopię zapasową.

• Na RPO wpływa częstotliwość procesu tworzenia kopii zapasowej. Jeśli kopie zapasowe są wykonywane częściej, oznacza to utratę mniejszej ilości danych w przypadku konieczności przywrócenia z kopii zapasowej. Jednak kopie zapasowe wymagają magazynu, a w niektórych sytuacjach mogą mieć wpływ na wydajność usługi podczas tworzenia kopii zapasowych. Z tego powodu należy wziąć pod uwagę częstotliwość tworzenia kopii zapasowych i znaleźć właściwą równowagę dla wymagań organizacji. Częstotliwość tworzenia kopii zapasowych powinna być brana pod uwagę podczas planowania ciągłości działania.

Niektóre systemy kopii zapasowych obsługują bardziej złożone wymagania dotyczące tworzenia kopii zapasowych, w tym wiele warstw kopii zapasowych z różnymi okresami przechowywania, oraz różnicowe lub przyrostowe kopie zapasowe, które są szybsze w celu zapisania i użycia mniejszej ilości miejsca do magazynowania.

Tworzenie kopii zapasowych w usługach platformy Azure

Wiele usług platformy Azure zapewnia możliwości tworzenia kopii zapasowych danych.

Azure Backup to dedykowane rozwiązanie do tworzenia kopii zapasowych dla kilku kluczowych usług platformy Azure, w tym maszyn wirtualnych, usługi Azure Storage i usługi Azure Kubernetes Service (AKS).

Ponadto wiele zarządzanych baz danych zapewnia własne możliwości tworzenia kopii zapasowych w ramach usługi, takie jak:

• Usługa Azure SQL Database udostępnia automatyczne kopie zapasowe.
• Usługa Azure Cosmos DB zapewnia zarówno funkcje ciągłej, jak i okresowej kopii zapasowej.
• Usługa Azure Key Vault umożliwia pobranie kopii zapasowej danych w magazynie.
• Usługa Azure App Service udostępnia automatyczne i niestandardowe kopie zapasowe dla aplikacji internetowych, a także umożliwia tworzenie kopii zapasowych baz danych.

Kopia zapasowa a replikacja

Każda kopia zapasowa i replikacja chroni przed różnymi zagrożeniami, a dwa podejścia uzupełniają się między sobą.

Replikacja obsługuje codzienną odporność i jest często używana w strategii wysokiej dostępności. Niektóre podejścia do replikacji wymagają niewielkiego lub wręcz braku przestojów oraz utraty danych i wspierają niski RTO i RPO. Jednak replikacja nie chroni przed zagrożeniami, które powodują utratę lub uszkodzenie danych.

Z kolei kopia zapasowa jest często ostatnią linią obrony przed katastrofalnym ryzykiem. Kopie zapasowe często wymagają stosunkowo wysokiego czasu odzyskiwania i punktu odzyskiwania, a sposób, w jaki je konfigurujesz, wpływa na to, jak wysokie będą te wartości. Całkowite przywracanie z kopii zapasowej jest często częścią planu odzyskiwania po awarii.

Przygotowywanie składników do zapewnienia redundancji

Podczas projektowania systemu, który korzysta z nadmiarowości w ramach jego architektury, ważne jest również, aby wziąć pod uwagę sposób:

• Duplikuj konfigurację zasobów pod kątem spójności.
• Zarządzaj pojemnością podczas awarii wystąpień przez zaopatrzenie w nadmiarowe zasoby.

Zduplikowana konfiguracja zasobu

W środowiskach w chmurze konfiguracja poszczególnych zasobów ma kluczowe znaczenie. Na przykład podczas tworzenia modułu równoważenia obciążenia sieciowego należy skonfigurować różne ustawienia wpływające na jego działanie; a podczas wdrażania funkcji przy użyciu usługi Azure Functions można skonfigurować ustawienia związane z ustawieniami zabezpieczeń, wydajności i konfiguracji aplikacji. Każdy zasób na platformie Azure ma jakąś konfigurację, która napędza jego zachowanie.

Podczas zarządzania nadmiarowymi kopiami zasobów w różnych miejscach ważne jest, aby kontrolować ich konfigurację. Wiele ustawień należy skonfigurować w taki sam sposób w każdej kopii, aby zasoby zachowywały się w taki sam sposób. Jednak niektóre ustawienia mogą się różnić między poszczególnymi kopiami, takimi jak odwołania do sieci wirtualnej określonego regionu.

Typowym podejściem do utrzymania spójności zasobów jest użycie infrastruktury jako kodu (IaC), takiego jak Bicep lub Terraform. Te narzędzia umożliwiają tworzenie plików definiujących zasób i ponowne użycie tych definicji dla każdego wystąpienia zasobu. Korzystając z IaC, można zmniejszyć obciążenie związane z tworzeniem i zarządzaniem wieloma wystąpieniami zasobów w celach zwiększenia odporności, a także istnieje wiele innych korzyści. Aby dowiedzieć się więcej, zobacz What is infrastructure as code (IaC)? (Co to jest infrastruktura jako kod)? i Zalecenia dotyczące używania infrastruktury jako kodu.

Zarządzanie pojemnością poprzez nadmierne przydzielanie zasobów

W przypadku awarii instancji ogólna pojemność systemu może różnić się od pojemności wymaganej podczas normalnej pracy. Załóżmy na przykład, że zazwyczaj masz sześć wystąpień serwera internetowego do przetwarzania przychodzącego ruchu internetowego, a wystąpienia te są równomiernie rozłożone między trzy strefy dostępności platformy Azure w regionie:

Jeśli w strefie dostępności wystąpi awaria, możesz tymczasowo utracić dwie instancje i pozostać z czterema serwerami. Jeśli aplikacja jest zwykle zajęta i wymaga, aby wszystkie sześć wystąpień nadążało za normalnym ruchem, działanie w ograniczonej pojemności może mieć wpływ na wydajność rozwiązania.

Aby przygotować się do awarii, możesz zapewnić dodatkową pojemność usługi. Nadmierna aprowizacja pozwala rozwiązaniu tolerować pewien stopień utraty pojemności i nadal działać bez obniżonej wydajności.

Aby nadmiarowo przydzielić zasoby wystąpień serwera sieciowego, uwzględniając możliwość awarii jednej strefy dostępności, wykonaj następujące kroki:

1. Określ liczbę wystąpień, których wymaga szczytowe obciążenie.
2. Pobierz liczbę wystąpień nadmiernej aprowizacji, mnożąc liczbę wystąpień obciążenia szczytowego przez współczynnik [(strefy/(strefy-1)].
3. Zaokrąglij wynik do najbliższej liczby całkowitej.

W poprzednim przykładzie szczytowe obciążenie wymaga sześciu wystąpień serwera internetowego, więc nadmierna aprowizacja wymaga łącznie dziewięciu wystąpień:

Następne kroki

Dowiedz się więcej o przejściu w tryb failover i powrotu po awarii.