Uzyskiwanie wysokiej dostępności za pomocą usługi Azure Cosmos DB
DOTYCZY: 
Nosql Mongodb Cassandra Gremlin Tabeli
Aby utworzyć rozwiązanie o wysokiej dostępności, należy ocenić charakterystykę niezawodności wszystkich jego składników. Usługa Azure Cosmos DB udostępnia funkcje i opcje konfiguracji, które ułatwiają osiągnięcie wysokiej dostępności rozwiązania.
W tym artykule są używane następujące terminy:
- Cel czasu odzyskiwania (RTO): czas między rozpoczęciem awarii, która ma wpływ na usługę Azure Cosmos DB i odzyskiwanie do pełnej dostępności.
- Cel punktu odzyskiwania (RPO): czas między ostatnim zapisem, który został poprawnie przywrócony, a czasem rozpoczęcia awarii, która ma wpływ na usługę Azure Cosmos DB.
Uwaga
Oczekiwane i maksymalne jednostki ŻĄDAŃ jednostki usługi i obiekty RTO zależą od rodzaju awarii, której dotyczy usługa Azure Cosmos DB. Na przykład awaria pojedynczego węzła różni się od oczekiwanego celu czasu odzyskiwania i celu punktu odzyskiwania niż awaria całego regionu.
W tym artykule szczegółowo opisano zdarzenia, które mogą mieć wpływ na dostępność usługi Azure Cosmos DB i odpowiednie opcje konfiguracji usługi Azure Cosmos DB.
Konserwacja repliki
Azure Cosmos DB to wielodostępna usługa, która w sposób przezroczysty zarządza wszystkimi szczegółami poszczególnych węzłów obliczeniowych. Użytkownicy nie muszą martwić się o jakiekolwiek stosowanie poprawek ani planowaną konserwację. Usługa Azure Cosmos DB gwarantuje umowy SLA dotyczące dostępności i opóźnienia P99 przez wszystkie operacje automatycznej konserwacji wykonywane przez system.
Awarie repliki
Awarie replik są awariami poszczególnych węzłów w klastrze usługi Azure Cosmos DB wdrożonym w regionie świadczenia usługi Azure.
Usługa Azure Cosmos DB automatycznie ogranicza awarie replik, gwarantując co najmniej trzy repliki danych w każdym regionie świadczenia usługi Azure dla konta w kworum z czterema replikami. Gwarantuje to, że cel czasu odzyskiwania 0 i cel punktu odzyskiwania 0 dla poszczególnych awarii węzłów bez konieczności wprowadzania zmian aplikacji lub konfiguracji.
W wielu regionach świadczenia usługi Azure można dystrybuować klaster usługi Azure Cosmos DB w różnych strefach dostępności. Strefy dostępności mogą zwiększyć umowy SLA, ponieważ są fizycznie oddzielone i zapewniają odrębne źródło zasilania, sieć i chłodzenie. Podczas wdrażania konta usługi Azure Cosmos DB przy użyciu stref dostępności usługa Azure Cosmos DB udostępnia cel czasu odzyskiwania równy 0 i cel punktu odzyskiwania równy 0, nawet w przypadku awarii strefy.
Podczas wdrażania w jednym regionie platformy Azure bez dodatkowych danych wejściowych użytkownika usługa Azure Cosmos DB jest odporna na awarie węzłów. Włączenie nadmiarowości w różnych strefach dostępności sprawia, że usługa Azure Cosmos DB jest odporna na awarie strefy kosztem zwiększonych opłat.
Nadmiarowość strefy można skonfigurować tylko podczas dodawania nowego regionu do konta usługi Azure Cosmos DB. W przypadku istniejących regionów można włączyć nadmiarowość strefy, usuwając region, a następnie dodając go z powrotem z włączoną nadmiarowością strefy. W przypadku konta z jednym regionem to podejście wymaga dodania regionu w celu tymczasowego przełączenie w tryb failover, a następnie usunięcie i dodanie żądanego regionu z włączoną nadmiarowością strefy.
Domyślnie konto usługi Azure Cosmos DB nie korzysta z wielu stref dostępności. Wdrożenie w wielu strefach dostępności można włączyć w następujący sposób:
Jeśli twoje konto usługi Azure Cosmos DB jest dystrybuowane w regionach N platformy Azure, będzie istnieć N x 4 kopie wszystkich danych. Aby uzyskać więcej informacji na temat replikowania danych w poszczególnych regionach w usłudze Azure Cosmos DB, zobacz Global distribution with Azure Cosmos DB (Dystrybucja globalna w usłudze Azure Cosmos DB). Posiadanie konta usługi Azure Cosmos DB w więcej niż dwóch regionach zwiększa dostępność aplikacji i zapewnia małe opóźnienia w skojarzonych regionach.
Awarie regionów
Awarie regionów to awarie wpływające na wszystkie węzły usługi Azure Cosmos DB w regionie świadczenia usługi Azure we wszystkich strefach dostępności. W rzadkich przypadkach awarii regionów można skonfigurować usługę Azure Cosmos DB tak, aby obsługiwała różne wyniki trwałości i dostępności.
Trwałość
Gdy konto usługi Azure Cosmos DB jest wdrażane w jednym regionie, zazwyczaj nie dochodzi do utraty danych. Dostęp do danych jest przywracany po odzyskaniu usług Azure Cosmos DB w danym regionie. Utrata danych może wystąpić tylko w przypadku nieodwracalnej awarii w regionie usługi Azure Cosmos DB.
Aby ułatwić ochronę przed całkowitą utratą danych, która może wynikać z katastroficznych awarii w regionie, usługa Azure Cosmos DB udostępnia dwa tryby tworzenia kopii zapasowych:
- Ciągłe kopie zapasowe są kopiami zapasowymi każdego regionu co 100 sekund. Umożliwiają one przywrócenie danych do dowolnego punktu w czasie przy użyciu 1-sekundowego stopnia szczegółowości. W każdym regionie kopia zapasowa jest zależna od danych zatwierdzonych w tym regionie.
- Okresowe kopie zapasowe w pełni tworzą kopię zapasową wszystkich partycji ze wszystkich kontenerów w ramach konta bez synchronizacji między partycjami. Minimalny interwał tworzenia kopii zapasowej to 1 godzina.
Po wdrożeniu konta usługi Azure Cosmos DB w wielu regionach trwałość danych zależy od poziomu spójności skonfigurowanego na koncie. W poniższej tabeli przedstawiono szczegóły dotyczące wszystkich poziomów spójności celu punktu odzyskiwania konta usługi Azure Cosmos DB wdrożonego w co najmniej dwóch regionach.
| Poziom spójności | Cel punktu odzyskiwania dla awarii regionu |
|---|---|
| Sesja, spójny prefiks, ostateczna | Mniej niż 15 minut |
| Powiązana nieaktualność | K i T |
| Silna | 0 |
K = liczba wersji (czyli aktualizacji) elementu.
T = przedział czasu od ostatniej aktualizacji.
W przypadku kont z wieloma regionami minimalna wartość K i T wynosi 100 000 operacji zapisu lub 300 sekund. Ta wartość definiuje minimalny cel punktu odzyskiwania dla danych, gdy używasz powiązanej nieaktualności.
Aby uzyskać więcej informacji na temat różnic między poziomami spójności, zobacz Poziomy spójności w usłudze Azure Cosmos DB.
Dostępność
Jeśli rozwiązanie wymaga ciągłej dostępności podczas awarii regionów, możesz skonfigurować usługę Azure Cosmos DB do replikowania danych w wielu regionach i przezroczystego przełączania w tryb failover do dostępnych regionów, jeśli jest to wymagane.
Konta z jednym regionem mogą utracić dostępność po awarii regionalnej. Aby zapewnić wysoką dostępność przez cały czas, zalecamy skonfigurowanie konta usługi Azure Cosmos DB przy użyciu jednego regionu zapisu i co najmniej drugiego regionu (odczytu) oraz włączenia trybu failover zarządzanego przez usługę.
Tryb failover zarządzany przez usługę umożliwia usłudze Azure Cosmos DB przełączanie w tryb failover w regionie zapisu konta z wieloma regionami w celu zachowania dostępności kosztem utraty danych zgodnie z opisem we wcześniejszej sekcji Trwałość . Regionalne przejścia w tryb failover są wykrywane i obsługiwane w kliencie usługi Azure Cosmos DB. Nie wymagają żadnych zmian w aplikacji. Aby uzyskać instrukcje dotyczące włączania wielu regionów odczytu i trybu failover zarządzanego przez usługę, zobacz Zarządzanie kontem usługi Azure Cosmos DB przy użyciu witryny Azure Portal.
Ważne
Jeśli wybrano konfigurację zapisu w jednym regionie z wieloma regionami odczytu, zdecydowanie zalecamy skonfigurowanie kont usługi Azure Cosmos DB używanych na potrzeby obciążeń produkcyjnych w celu włączenia trybu failover zarządzanego przez usługę. Ta konfiguracja umożliwia usłudze Azure Cosmos DB przełączanie baz danych kont w tryb failover do dostępnych regionów. W przypadku braku tej konfiguracji konto utraci dostępność zapisu przez cały czas trwania awarii regionu zapisu. Ręczne przejście w tryb failover nie powiedzie się z powodu braku łączności z regionem.
Ostrzeżenie
Nawet w przypadku włączenia trybu failover zarządzanego przez usługę częściowa awaria może wymagać ręcznej interwencji zespołu usługi Azure Cosmos DB. W tych scenariuszach przejście w tryb failover może potrwać do 1 godziny (lub więcej). Aby zapewnić lepszą dostępność zapisu podczas częściowych awarii, zalecamy włączenie stref dostępności oprócz trybu failover zarządzanego przez usługę.
Wiele regionów zapisu
Usługę Azure Cosmos DB można skonfigurować tak, aby akceptowała zapisy w wielu regionach. Ta konfiguracja jest przydatna do zmniejszenia opóźnienia zapisu w aplikacjach rozproszonych geograficznie.
Podczas konfigurowania konta usługi Azure Cosmos DB dla wielu regionów zapisu silna spójność nie jest obsługiwana, a mogą wystąpić konflikty zapisu. Aby uzyskać więcej informacji na temat rozwiązywania tych konfliktów, zobacz Typy konfliktów i zasady rozwiązywania problemów podczas korzystania z wielu regionów zapisu.
Ważne
Często aktualizowanie tego samego identyfikatora dokumentu (lub ponowne tworzenie tego samego identyfikatora dokumentu po TTL lub usunięciu) będzie miało wpływ na wydajność replikacji ze względu na większą liczbę konfliktów generowanych w systemie.
Region rozwiązywania konfliktów
Gdy konto usługi Azure Cosmos DB jest skonfigurowane z zapisami w wielu regionach, jeden z regionów będzie działać jako arbiter w konfliktach zapisu.
Najlepsze rozwiązania dotyczące zapisów w wielu regionach
Poniżej przedstawiono kilka najlepszych rozwiązań, które należy wziąć pod uwagę podczas pisania w wielu regionach.
Zachowaj ruch lokalny
W przypadku korzystania z zapisów w wielu regionach aplikacja powinna wystawiać ruch odczytu i zapisu pochodzący z regionu lokalnego ściśle do lokalnego regionu usługi Cosmos DB. Aby uzyskać optymalną wydajność, unikaj wywołań między regionami.
Aplikacja musi zminimalizować konflikty, unikając następujących antywzorców:
Wysyłanie tej samej operacji zapisu do wszystkich regionów w celu zwiększenia szans na uzyskanie szybkiego czasu odpowiedzi
Losowe określanie regionu docelowego dla operacji odczytu lub zapisu dla poszczególnych żądań
Używanie zasad działania okrężnego do określania regionu docelowego dla operacji odczytu lub zapisu dla poszczególnych żądań
Unikanie zależności od opóźnienia replikacji
Nie można skonfigurować kont zapisu w wielu regionach w celu zapewnienia silnej spójności. Region, który jest zapisywany w celu odpowiadania natychmiast po replikacji danych w usłudze Azure Cosmos DB lokalnie, a asynchronicznie replikuje dane globalnie.
Chociaż jest rzadko, opóźnienie replikacji może wystąpić na jednej lub kilku partycjach podczas replikacji geograficznej danych. Opóźnienie replikacji może wystąpić z powodu rzadkiego blip w ruchu sieciowym lub wyższych niż zwykle współczynników rozwiązywania konfliktów.
Na przykład architektura, w której aplikacja zapisuje dane w regionie A, ale odczyt z regionu B wprowadza zależność od opóźnienia replikacji między dwoma regionami. Jeśli jednak aplikacja odczytuje i zapisuje w tym samym regionie, wydajność pozostaje stała nawet w przypadku opóźnienia replikacji.
Ocena użycia spójności sesji dla operacji zapisu
W przypadku spójności sesji używasz tokenu sesji dla operacji odczytu i zapisu.
W przypadku operacji odczytu usługa Azure Cosmos DB wysyła buforowany token sesji do serwera z gwarancją odbierania danych odpowiadających określonemu (lub nowszemu) tokenowi sesji.
W przypadku operacji zapisu usługa Azure Cosmos DB wysyła token sesji do bazy danych z gwarancją utrwalania danych tylko wtedy, gdy serwer został przechwycony do podanego tokenu sesji. W przypadku kont zapisu w jednym regionie region zawsze gwarantuje się, że region zapisu jest uwikłany w token sesji. Jednak w przypadku kont zapisu w wielu regionach, region, do którego zapisujesz, może nie być w stanie przechwycić zapisów wystawionych w innym regionie. Jeśli klient zapisuje dane w regionie A przy użyciu tokenu sesji z regionu B, region A nie będzie mógł utrwalyć danych, dopóki nie dogoni zmiany wprowadzone w regionie B.
Najlepiej używać tokenów sesji tylko w przypadku operacji odczytu, a nie operacji zapisu podczas przekazywania tokenów sesji między wystąpieniami klienta.
Eliminowanie szybkich aktualizacji tego samego dokumentu
Aktualizacje serwera w celu rozwiązania lub potwierdzenia braku konfliktów mogą kolidować z zapisami wyzwalanymi przez aplikację, gdy ten sam dokument jest wielokrotnie aktualizowany. Powtarzające się aktualizacje w krótkim odstępie czasu do tego samego dokumentu mają większe opóźnienia podczas rozwiązywania konfliktów.
Mimo że sporadyczne wzrosty liczby powtarzających się aktualizacji tego samego dokumentu są nieuniknione, warto rozważyć eksplorowanie architektury, w której tworzone są nowe dokumenty, jeśli ruch w stałym stanie widzi szybkie aktualizacje tego samego dokumentu w dłuższym okresie.
Czego można oczekiwać podczas awarii regionu
Klienci kont z jednym regionem utracą dostępność odczytu i zapisu do czasu przywrócenia usługi.
Konta z wieloma regionami mają różne zachowania w zależności od następujących konfiguracji i typów awarii.
| Konfigurowanie | Awaria | Wpływ na dostępność | Wpływ trwałości | Postępowanie |
|---|---|---|---|---|
| Region pojedynczego zapisu | Awaria regionu odczytu | Wszyscy klienci automatycznie przekierowują odczyty do innych regionów. Nie ma utraty dostępności odczytu ani zapisu dla wszystkich konfiguracji. Wyjątkiem jest konfiguracja dwóch regionów z silną spójnością, która traci dostępność zapisu do czasu przywrócenia usługi. Lub jeśli włączysz tryb failover zarządzany przez usługę, usługa oznaczy region jako niepowodzenie i nastąpi przejście w tryb failover. | Brak utraty danych. | Podczas awarii upewnij się, że w pozostałych regionach jest wystarczająca liczba aprowizowania jednostek żądań (RU), aby obsługiwać ruch odczytu. Gdy awaria się skończyła, odpowiednio przesuń aprowizowane jednostki RU. |
| Region pojedynczego zapisu | Awaria regionu zapisu | Klienci przekierowują odczyty do innych regionów. Bez trybu failover zarządzanego przez usługę klienci doświadczają utraty dostępności zapisu. Przywracanie dostępności zapisu odbywa się automatycznie po zakończeniu awarii. W przypadku trybu failover zarządzanego przez usługę klienci doświadczają utraty dostępności zapisu, dopóki usługa nie zarządza trybem failover w wybranym regionie zapisu. |
Jeśli nie wybierzesz silnego poziomu spójności, usługa może nie replikować niektórych danych do pozostałych aktywnych regionów. Ta replikacja zależy od wybranego poziomu spójności. Jeśli region, którego dotyczy problem, ulegnie trwałej utracie danych, możesz utracić niereplikowane dane. | Podczas awarii upewnij się, że w pozostałych regionach jest wystarczająca liczba aprowizowanych jednostek RU, aby obsługiwać ruch odczytu. Nie wyzwalaj ręcznego przejścia w tryb failover podczas awarii, ponieważ nie może zakończyć się powodzeniem. Gdy awaria się skończyła, odpowiednio przesuń aprowizowane jednostki RU. Konta korzystające z interfejsu API dla noSQL mogą również odzyskać niereplikowane dane w regionie, w którym wystąpiły awarie, ze źródła danych powodujących konflikt. |
| Wiele regionów zapisu | Awaria regionalna | Istnieje możliwość tymczasowej utraty dostępności zapisu, która jest analogiczna do pojedynczego regionu zapisu z trybem failover zarządzanym przez usługę. Przejście w tryb failover w regionie rozwiązywania konfliktów może również spowodować utratę dostępności zapisu, jeśli w momencie awarii wystąpi duża liczba zapisów powodujących konflikt. | Ostatnio zaktualizowane dane w regionie, który zakończył się niepowodzeniem, mogą być niedostępne w pozostałych aktywnych regionach, w zależności od wybranego poziomu spójności. Jeśli region, którego dotyczy problem, ulegnie trwałej utracie danych, możesz utracić niereplikowane dane. | Podczas awarii upewnij się, że w pozostałych regionach jest wystarczająca liczba zaaprowizowanych jednostek RU, aby obsługiwać większy ruch. Gdy awaria się skończyła, możesz odpowiednio anulować aprowizowane jednostki RU. Jeśli to możliwe, usługa Azure Cosmos DB automatycznie odzyskuje niereplikowane dane w regionie, w którym wystąpił błąd. To automatyczne odzyskiwanie używa metody rozwiązywania konfliktów skonfigurowanej dla kont korzystających z interfejsu API dla noSQL. W przypadku kont korzystających z innych interfejsów API to automatyczne odzyskiwanie używa ostatnich zwycięstw zapisu. |
Dodatkowe informacje na temat awarii regionów odczytu
Region, którego dotyczy problem, jest odłączony i oznaczony w trybie offline. Zestawy SDK usługi Azure Cosmos DB przekierowują wywołania odczytu do następnego dostępnego regionu na liście preferowanych regionów.
Jeśli żadna z regionów na liście preferowanych regionów nie jest dostępna, wywołania automatycznie wracają do bieżącego regionu zapisu.
W kodzie aplikacji nie są wymagane żadne zmiany w celu obsługi awarii regionów odczytu. Gdy region odczytu, którego dotyczy problem, jest z powrotem w trybie online, synchronizuje się z bieżącym regionem zapisu i jest ponownie dostępny do obsługi żądań odczytu po jego pełnym przechwyceniu.
Dalsze operacje odczytu są przekierowywane do odzyskanego regionu bez konieczności wprowadzania jakichkolwiek zmian w kodzie aplikacji. Podczas przechodzenia w tryb failover i ponownego dołączania wcześniej nieudanego regionu usługa Azure Cosmos DB nadal przestrzega gwarancji spójności odczytu.
Nawet w rzadkim i niefortunnym przypadku, w którym region zapisu platformy Azure jest trwale nieodwracalny, nie ma utraty danych, jeśli konto usługi Azure Cosmos DB w wielu regionach jest skonfigurowane z silną spójnością. Konto usługi Azure Cosmos DB z wieloma regionami ma charakterystykę trwałości określoną wcześniej w sekcji Trwałość .
Dodatkowe informacje na temat awarii regionów zapisu
Podczas awarii regionu zapisu konto usługi Azure Cosmos DB promuje region pomocniczy jako nowy podstawowy region zapisu, gdy na koncie usługi Azure Cosmos DB skonfigurowano tryb failover zarządzany przez usługę. Przejście w tryb failover odbywa się do innego regionu w kolejności określonego priorytetu regionu.
Ręczne przejście w tryb failover nie powinno być wyzwalane i nie powiedzie się w przypadku awarii regionu źródłowego lub docelowego. Przyczyną jest to, że procedura trybu failover obejmuje sprawdzanie spójności, które wymaga łączności między regionami.
Gdy region, którego dotyczy problem, jest z powrotem w trybie online, wszystkie dane zapisu, które nie zostały zreplikowane, gdy region zakończył się niepowodzeniem, zostanie udostępniony za pośrednictwem kanału informacyjnego konfliktów. Aplikacje mogą odczytywać zestawienie konfliktów, rozwiązywać konflikty na podstawie logiki specyficznej dla aplikacji i zapisywać zaktualizowane dane z powrotem do kontenera usługi Azure Cosmos DB zgodnie z potrzebami.
Po odzyskaniu wcześniej objętego regionu zapisu będzie on wyświetlany jako "online" w witrynie Azure Portal i stanie się dostępny jako region odczytu. W tym momencie można bezpiecznie przełączyć się z powrotem do odzyskanego regionu jako regionu zapisu przy użyciu programu PowerShell, interfejsu wiersza polecenia platformy Azure lub witryny Azure Portal. Nie ma danych ani utraty dostępności przed, podczas lub po przełączeniu regionu zapisu. Aplikacja nadal jest wysoce dostępna.
Ostrzeżenie
W przypadku awarii regionu zapisu, w którym konto usługi Azure Cosmos DB promuje region pomocniczy jako nowy region zapisu podstawowego za pośrednictwem trybu failover zarządzanego przez usługę, oryginalny region zapisu nie zostanie podwyższony jako region zapisu automatycznie po odzyskaniu. Twoim zadaniem jest przełączenie się z powrotem do odzyskanego regionu jako regionu zapisu przy użyciu programu PowerShell, interfejsu wiersza polecenia platformy Azure lub witryny Azure Portal (po uzyskaniu bezpieczeństwa, zgodnie z powyższym opisem).
Umowy SLA
Poniższa tabela zawiera podsumowanie możliwości wysokiej dostępności różnych konfiguracji kont.
| KLUCZOWY WSKAŹNIK WYDAJNOŚCI (KPI) | Operacje zapisu w jednym regionie bez stref dostępności | Zapisy w jednym regionie ze strefami dostępności | Zapisy w wielu regionach bez stref dostępności | Zapisy w wielu regionach z jedną regionem ze strefami dostępności | Zapisy w wielu regionach z strefami dostępności lub bez tych operacji |
|---|---|---|---|---|---|
| Umowa SLA dotycząca dostępności zapisu | 99,99% | 99.995% | 99,99% | 99.995% | 99.999% |
| Umowa SLA dotycząca dostępności odczytu | 99,99% | 99.995% | 99.999% | 99.999% | 99.999% |
| Błędy strefy: utrata danych | Utrata danych | Brak utraty danych | Brak utraty danych | Brak utraty danych | Brak utraty danych |
| Błędy strefy: dostępność | Utrata dostępności | Brak utraty dostępności | Brak utraty dostępności | Brak utraty dostępności | Brak utraty dostępności |
| Awaria regionalna: utrata danych | Utrata danych | Utrata danych | Zależne od poziomu spójności. Aby uzyskać więcej informacji, zobacz Spójność, dostępność i kompromisy dotyczące wydajności. | Zależne od poziomu spójności. Aby uzyskać więcej informacji, zobacz Spójność, dostępność i kompromisy dotyczące wydajności. | Zależne od poziomu spójności. Aby uzyskać więcej informacji, zobacz Spójność, dostępność i kompromisy dotyczące wydajności. |
| Awaria regionalna: dostępność | Utrata dostępności | Utrata dostępności | Brak utraty dostępności dla błędu regionu odczytu, tymczasowy błąd regionu zapisu | Brak utraty dostępności dla błędu regionu odczytu, tymczasowy błąd regionu zapisu | Brak utraty dostępności odczytu, tymczasowa utrata dostępności zapisu w danym regionie |
| Cena (1) | Nie dotyczy | Aprowizowana liczba jednostek RU/s x 1,25 | Aprowizowane jednostki RU/s x N regionów | Aprowizowana liczba jednostek RU/s x 1,25 x regiony N (2) | Szybkość zapisu w wielu regionach x N |
1 W przypadku kont bezserwerowych jednostki RU są mnożone przez współczynnik 1,25.
2 Stawka 1,25 dotyczy tylko regionów, w których włączono strefy dostępności.
Wskazówki do tworzenia aplikacji o wysokiej dostępności
Zapoznaj się z oczekiwanym zachowaniem zestawów SDK usługi Azure Cosmos DB podczas zdarzeń i ich konfiguracji.
Aby zapewnić wysoką dostępność zapisu i odczytu, skonfiguruj konto usługi Azure Cosmos DB tak, aby obejmowało co najmniej dwa regiony (lub trzy, jeśli używasz silnej spójności). Aby dowiedzieć się więcej, zobacz Samouczek: konfigurowanie dystrybucji globalnej usługi Azure Cosmos DB przy użyciu interfejsu API dla noSQL.
W przypadku kont usługi Azure Cosmos DB z wieloma regionami skonfigurowanymi w jednym regionie zapisu włącz tryb failover zarządzany przez usługę przy użyciu interfejsu wiersza polecenia platformy Azure lub witryny Azure Portal. Po włączeniu trybu failover zarządzanego przez usługę po awarii regionalnej usługa Azure Cosmos DB przejdzie w tryb failover bez żadnych danych wejściowych użytkownika.
Nawet jeśli twoje konto usługi Azure Cosmos DB jest wysoce dostępne, aplikacja może nie być poprawnie zaprojektowana tak, aby zachować wysoką dostępność. Aby przetestować kompleksową wysoką dostępność aplikacji w ramach testowania aplikacji lub testowania po awarii (DR), tymczasowo wyłącz tryb failover zarządzany przez usługę dla konta. Wywołaj ręczne przejście w tryb failover przy użyciu programu PowerShell, interfejsu wiersza polecenia platformy Azure lub witryny Azure Portal, a następnie monitoruj aplikację. Po zakończeniu testu możesz wrócić po awarii do regionu podstawowego i przywrócić zarządzany przez usługę tryb failover dla konta.
Ważne
Nie należy wywoływać ręcznego przejścia w tryb failover podczas awarii usługi Azure Cosmos DB w regionie źródłowym lub docelowym. Ręczne przechodzenie w tryb failover wymaga łączności z regionem w celu zachowania spójności danych, więc nie powiedzie się.
W środowisku globalnej rozproszonej bazy danych istnieje bezpośrednia relacja między poziomem spójności a trwałością danych w obecności awarii całego regionu. Podczas opracowywania planu ciągłości działania należy zrozumieć maksymalny dopuszczalny czas, zanim aplikacja w pełni odzyska sprawność po wystąpieniu zdarzenia powodującego zakłócenia (czyli celu czasu odzyskiwania). Należy również zrozumieć maksymalny okres ostatnich aktualizacji danych, które aplikacja może tolerować utratę w przypadku odzyskiwania po wystąpieniu zdarzenia powodującego zakłócenia (czyli celu punktu odzyskiwania). Aby uzyskać więcej informacji na temat celu punktu odzyskiwania i celu punktu odzyskiwania, zobacz Poziomy spójności w usłudze Azure Cosmos DB.
Czego można oczekiwać podczas awarii regionu usługi Azure Cosmos DB
W przypadku kont z jednym regionem klienci tracą dostępność odczytu i zapisu podczas awarii regionu usługi Azure Cosmos DB. Konta z wieloma regionami mają różne zachowania, zgodnie z opisem w poniższej tabeli.
| Regiony zapisu | Tryb failover zarządzany przez usługę | Czego oczekiwać | Postępowanie |
|---|---|---|---|
| Region pojedynczego zapisu | Nie włączono | Jeśli w regionie odczytu wystąpi awaria, gdy nie używasz silnej spójności, wszyscy klienci będą przekierowywać do innych regionów. Brak utraty dostępności odczytu lub zapisu i nie ma utraty danych. W przypadku korzystania z silnej spójności awaria w regionie odczytu może mieć wpływ na dostępność zapisu, jeśli pozostanie mniej niż dwa regiony odczytu. Jeśli w regionie zapisu wystąpi awaria, klienci doświadczają utraty dostępności zapisu. Jeśli nie wybrano silnej spójności, usługa może nie replikować niektórych danych do pozostałych aktywnych regionów. Ta replikacja zależy od wybranego poziomu spójności. Jeśli region, którego dotyczy problem, ulegnie trwałej utracie danych, możesz utracić niereplikowane dane. Usługa Azure Cosmos DB przywraca dostępność zapisu po zakończeniu awarii. |
Podczas awarii upewnij się, że w pozostałych regionach jest wystarczająca liczba aprowizowanych jednostek RU, aby obsługiwać ruch odczytu. Nie wyzwalaj ręcznego przejścia w tryb failover podczas awarii, ponieważ nie może zakończyć się powodzeniem. Gdy awaria się skończyła, odpowiednio przesuń aprowizowane jednostki RU. |
| Region pojedynczego zapisu | Włączona | Jeśli w regionie odczytu wystąpi awaria, gdy nie używasz silnej spójności, wszyscy klienci będą przekierowywać do innych regionów. Brak utraty dostępności odczytu lub zapisu i nie ma utraty danych. Jeśli używasz silnej spójności, awaria regionu odczytu może mieć wpływ na dostępność zapisu, jeśli pozostanie mniej niż dwa regiony odczytu. Jeśli w regionie zapisu wystąpi awaria, klienci doświadczają utraty dostępności zapisu, dopóki usługa Azure Cosmos DB nie wybierze nowego regionu jako nowego regionu zapisu zgodnie z preferencjami. Jeśli nie wybrano silnej spójności, usługa może nie replikować niektórych danych do pozostałych aktywnych regionów. Ta replikacja zależy od wybranego poziomu spójności. Jeśli region, którego dotyczy problem, ulegnie trwałej utracie danych, możesz utracić niereplikowane dane. |
Podczas awarii upewnij się, że w pozostałych regionach jest wystarczająca liczba aprowizowanych jednostek RU, aby obsługiwać ruch odczytu. Nie wyzwalaj ręcznego przejścia w tryb failover podczas awarii, ponieważ nie może zakończyć się powodzeniem. Gdy awaria się skończyła, możesz przenieść region zapisu z powrotem do oryginalnego regionu i odpowiednio usunąć aprowizowane jednostki RU. Konta korzystające z interfejsu API dla noSQL mogą również odzyskać niereplikowane dane w regionie, w którym wystąpiły awarie, ze źródła danych powodujących konflikt. |
| Wiele regionów zapisu | Nie dotyczy | Ostatnio zaktualizowane dane w regionie, który zakończył się niepowodzeniem, mogą być niedostępne w pozostałych aktywnych regionach. Ostateczne, spójne prefiksy i poziomy spójności sesji gwarantują nieaktualność krótszą niż 15 minut. Powiązana nieaktualność gwarantuje mniej niż K aktualizacji lub T sekund w zależności od konfiguracji. Jeśli region, którego dotyczy problem, ulegnie trwałej utracie danych, możesz utracić niereplikowane dane. | Podczas awarii upewnij się, że w pozostałych regionach jest wystarczająca liczba zaaprowizowanych jednostek RU, aby obsługiwać większy ruch. Gdy awaria się skończyła, możesz odpowiednio anulować aprowizowane jednostki RU. Jeśli to możliwe, usługa Azure Cosmos DB odzyskuje niereplikowane dane w regionie, w którym wystąpił błąd. To odzyskiwanie korzysta z metody rozwiązywania konfliktów skonfigurowanej dla kont korzystających z interfejsu API dla noSQL. W przypadku kont korzystających z innych interfejsów API to odzyskiwanie używa ostatnich zwycięstw zapisu. |
Następne kroki
Następnie możesz przeczytać następujące artykuły: