Udostępnij za pośrednictwem


Niezawodność w usłudze Azure AI Search

Na platformie Azure niezawodność oznacza odporność i dostępność w przypadku awarii lub obniżenia wydajności usługi. W usłudze Azure AI Search niezawodność można osiągnąć w ramach jednej usługi lub za pośrednictwem wielu usług wyszukiwania w oddzielnych regionach.

  • Wdróż pojedynczą usługę wyszukiwania i skaluj w górę w celu zapewnienia wysokiej dostępności. Możesz dodać wiele replik, aby obsługiwać wyższe obciążenia indeksowania i wykonywania zapytań. Jeśli usługa wyszukiwania obsługuje strefy dostępności, repliki są automatycznie aprowizowane w różnych fizycznych centrach danych w celu uzyskania dodatkowej odporności.

  • Wdrażanie wielu usług wyszukiwania w różnych regionach geograficznych. Wszystkie obciążenia wyszukiwania są w pełni zawarte w jednej usłudze, która działa w jednym regionie geograficznym, ale w scenariuszu obejmującym wiele usług masz opcje synchronizowania zawartości, aby była taka sama we wszystkich usługach. Możesz również skonfigurować rozwiązanie do równoważenia obciążenia w celu ponownego dystrybuowania żądań lub przełączania w tryb failover w przypadku awarii usługi.

Aby zapewnić ciągłość działania i odzyskiwanie po awariach na poziomie regionalnym, zaplanuj topologię między regionami składającą się z wielu usług wyszukiwania o identycznej konfiguracji i zawartości. Niestandardowy skrypt lub kod udostępnia mechanizm przełączania w tryb failover do alternatywnej usługi wyszukiwania, jeśli nagle stanie się niedostępny.

Wysoka dostępność

W usłudze Azure AI Search repliki są kopiami indeksu. Usługa wyszukiwania jest zlecona z co najmniej jedną repliką i może mieć maksymalnie 12 replik. Dodawanie replik umożliwia usłudze Azure AI Search ponowne uruchomienie maszyny i konserwację jednej repliki, podczas gdy wykonywanie zapytań jest kontynuowane w innych replikach.

W przypadku każdej indywidualnej usługi wyszukiwania firma Microsoft gwarantuje dostępność na poziomie co najmniej 99,9% dla konfiguracji spełniających następujące kryteria:

  • Dwie repliki w celu zapewnienia wysokiej dostępności obciążeń tylko do odczytu (zapytań)

  • Co najmniej trzy repliki w celu zapewnienia wysokiej dostępności obciążeń odczytu i zapisu (zapytań i indeksowania)

System ma wewnętrzne mechanizmy monitorowania kondycji repliki i integralności partycji. Jeśli aprowizujesz określoną kombinację replik i partycji, system zapewnia ten poziom pojemności usługi.

Dla warstwy Bezpłatna nie jest dostępna żadna umowa dotycząca poziomu usług (SLA). Aby uzyskać więcej informacji, zobacz umowa SLA dla usługi Azure AI Search.

Obsługa strefy dostępności

Strefy dostępności to funkcja platformy Azure, która dzieli centra danych regionu na odrębne grupy lokalizacji fizycznej w celu zapewnienia wysokiej dostępności w tym samym regionie. W usłudze Azure AI Search poszczególne repliki są jednostkami przypisania strefy. Usługa wyszukiwania działa w jednym regionie; jego repliki działają w różnych fizycznych centrach danych (lub strefach) w tym regionie.

Strefy dostępności są używane podczas dodawania co najmniej dwóch replik do usługi wyszukiwania. Każda replika jest umieszczana w innej strefie dostępności w regionie. Jeśli masz więcej replik niż dostępne strefy w regionie usługi wyszukiwania, repliki są dystrybuowane w strefach tak równomiernie, jak to możliwe. Nie ma żadnej konkretnej akcji ze swojej strony, z wyjątkiem tworzenia usługi wyszukiwania w regionie, który udostępnia strefy dostępności, a następnie skonfigurowania usługi pod kątem używania wielu replik.

Wymagania wstępne

  • Warstwa usługi musi być Standardowa lub wyższa
  • Region usługi musi znajdować się w regionie, w którym są dostępne strefy (wymienione w poniższej sekcji)
  • Konfiguracja musi zawierać wiele replik: dwa dla obciążeń zapytań tylko do odczytu, trzy dla obciążeń odczytu i zapisu, które obejmują indeksowanie

Obsługiwane regiony

Obsługa stref dostępności zależy od infrastruktury i magazynu. Obecnie następująca strefa ma niewystarczający magazyn i nie zapewnia strefy dostępności dla usługi Azure AI Search:

  • Japonia Zachodnia

W przeciwnym razie strefy dostępności usługi Azure AI Search są obsługiwane w następujących regionach:

Region (Region) Data wdrożenia
Australia Wschodnia 30 stycznia 2021 r. lub nowszego
Brazylia Południowa 2 maja 2021 r. lub nowszy
Kanada Środkowa 30 stycznia 2021 r. lub nowszego
Indie Centralne 20 stycznia 2022 r. lub nowszego
Środkowe stany USA 4 grudnia 2020 r. lub nowszy
Chiny Północne 3 7 września 2022 r. lub nowsze
Azja Wschodnia 13 stycznia 2022 r. lub nowszego
Wschodnie stany USA 27 stycznia 2021 r. lub nowszy
Wschodnie stany USA 2 30 stycznia 2021 r. lub nowszego
Francja Środkowa 23 października 2020 r. lub nowszy
Niemcy Środkowo-Zachodnie 3 maja 2021 r. lub nowsza
Izrael Środkowy 1 kwietnia 2024 r. lub nowszy
Włochy Północne 1 kwietnia 2024 r. lub nowszy
Japonia Wschodnia 30 stycznia 2021 r. lub nowszego
Korea Środkowa 20 stycznia 2022 r. lub nowszego
Europa Północna 28 stycznia 2021 r. lub nowszy
Norwegia Wschodnia 20 stycznia 2022 r. lub nowszego
Katar Środkowy 25 sierpnia 2022 r. lub nowszego
Północna Republika Południowej Afryki 7 września 2022 r. lub nowsze
South Central US 30 kwietnia 2021 r. lub nowszego
Azja Południowo-Wschodnia 31 stycznia 2021 r. lub nowszy
Szwecja Środkowa 21 stycznia 2022 r. lub nowszy
Szwajcaria Północna 7 września 2022 r. lub nowsze
Północne Zjednoczone Emiraty Arabskie 9 września 2022 r. lub nowszy
Południowe Zjednoczone Królestwo 30 stycznia 2021 r. lub nowszego
US Gov Wirginia 30 kwietnia 2021 r. lub nowszego
Europa Zachodnia 29 stycznia 2021 r. lub nowszego
Zachodnie stany USA 2 30 stycznia 2021 r. lub nowszego
Zachodnie stany USA 3 2 czerwca 2021 r. lub nowszy

Uwaga

Strefy dostępności nie zmieniają warunków umowy SLA. Nadal potrzebujesz co najmniej trzech replik w celu zapewnienia wysokiej dostępności zapytań.

Wiele usług w oddzielnych regionach geograficznych

Nadmiarowość usługi jest niezbędna, jeśli wymagania operacyjne obejmują:

  • Wymagania dotyczące ciągłości działania i odzyskiwania po awarii (BCDR). Usługa Azure AI Search nie zapewnia natychmiastowego przejścia w tryb failover, jeśli wystąpi awaria.

  • Szybka wydajność aplikacji rozproszonej globalnie. Jeśli żądania zapytań i indeksowania pochodzą z całego świata, użytkownicy, którzy znajdują się najbliżej centrum danych hosta, będą korzystać z szybszej wydajności. Tworzenie większej liczby usług w regionach z bliskim sąsiedztwem tych użytkowników może wyrównać wydajność dla wszystkich użytkowników.

Jeśli potrzebujesz co najmniej dwóch usług wyszukiwania, tworzenie ich w różnych regionach może spełniać wymagania aplikacji dotyczące ciągłości i odzyskiwania oraz szybsze czasy odpowiedzi dla globalnej bazy użytkowników.

Usługa Azure AI Search nie zapewnia zautomatyzowanej metody replikowania indeksów wyszukiwania w różnych regionach geograficznych, ale istnieją pewne techniki, które mogą ułatwić ten proces implementowania i zarządzania nimi. Te techniki opisano w kilku następnych sekcjach.

Celem rozproszonego geograficznie zestawu usług wyszukiwania jest posiadanie co najmniej dwóch indeksów dostępnych w co najmniej dwóch regionach, w których użytkownik jest kierowany do usługi Azure AI usługa wyszukiwania, która zapewnia najmniejsze opóźnienie:

Diagram przedstawiający krzyżowy widok usług według regionów.

Tę architekturę można zaimplementować, tworząc wiele usług i projektując strategię synchronizacji danych. Opcjonalnie możesz uwzględnić zasób, taki jak usługa Azure Traffic Manager na potrzeby routingu żądań.

Napiwek

Aby uzyskać pomoc dotyczącą wdrażania wielu usług wyszukiwania w wielu regionach, zobacz ten przykład Bicep w usłudze GitHub , który wdraża w pełni skonfigurowane, wieloregionalne rozwiązanie do wyszukiwania. W przykładzie przedstawiono dwie opcje synchronizacji indeksów i przekierowywanie żądań przy użyciu usługi Traffic Manager.

Synchronizowanie danych między wieloma usługami

Istnieją dwie opcje synchronizowania co najmniej dwóch odrębnych usług wyszukiwania:

Aby skonfigurować jedną z tych opcji, zalecamy użycie przykładowego skryptu Bicep w repozytorium azure-search-multiple-region , zmodyfikowanego w regionach i strategiach indeksowania.

Opcja 1. Używanie indeksatorów do aktualizowania zawartości w wielu usługach

Jeśli już używasz indeksatora w jednej usłudze, możesz skonfigurować drugi indeksator w drugiej usłudze tak, aby używał tego samego obiektu źródła danych, ściągając dane z tej samej lokalizacji. Każda usługa w każdym regionie ma własny indeksator i indeks docelowy (indeks wyszukiwania nie jest udostępniany, co oznacza, że każdy indeks ma własną kopię danych), ale każdy indeksator odwołuje się do tego samego źródła danych.

Poniżej przedstawiono ogólną wizualizację tego, jak wyglądałaby ta architektura.

Diagram przedstawiający pojedyncze źródło danych z rozproszonym indeksatorem i kombinacjami usług.

Opcja 2. Używanie interfejsów API REST do wypychania aktualizacji zawartości do wielu usług

Jeśli używasz interfejsu API REST usługi Azure AI Search do wypychania zawartości do indeksu wyszukiwania, możesz zachować synchronizację różnych usług wyszukiwania, wypychając zmiany do wszystkich usług wyszukiwania za każdym razem, gdy jest wymagana aktualizacja. W kodzie upewnij się, że obsługa przypadków, w których aktualizacja jednej usługi wyszukiwania kończy się niepowodzeniem, ale kończy się powodzeniem w przypadku innych usług wyszukiwania.

Przełączanie w tryb failover lub przekierowywanie żądań zapytań

Jeśli potrzebujesz nadmiarowości na poziomie żądania, platforma Azure oferuje kilka opcji równoważenia obciążenia:

  • Usługa Azure Traffic Manager służy do kierowania żądań do wielu witryn internetowych zlokalizowanych geograficznie, które są następnie wspierane przez wiele usług wyszukiwania.
  • Usługa Application Gateway służy do równoważenia obciążenia między serwerami w regionie w warstwie aplikacji.
  • Usługa Azure Front Door służy do optymalizowania globalnego routingu ruchu internetowego i zapewniania globalnego trybu failover.

Niektóre kwestie, o których należy pamiętać podczas oceniania opcji równoważenia obciążenia:

  • Wyszukiwanie to usługa zaplecza, która akceptuje żądania zapytań i indeksowania od klienta.

  • Żądania od klienta do usługi wyszukiwania muszą być uwierzytelnione. Aby uzyskać dostęp do operacji wyszukiwania, obiekt wywołujący musi mieć uprawnienia oparte na rolach lub podać klucz interfejsu API w żądaniu.

  • Punkty końcowe usługi są domyślnie dostępne za pośrednictwem publicznego połączenia internetowego. Jeśli skonfigurujesz prywatny punkt końcowy dla połączeń klienckich pochodzących z sieci wirtualnej, użyj usługi Application Gateway.

  • Usługa Azure AI Search akceptuje żądania skierowane do punktu końcowego <your-search-service-name>.search.windows.net . Jeśli osiągniesz ten sam punkt końcowy przy użyciu innej nazwy DNS w nagłówku hosta, na przykład CNAME, żądanie zostanie odrzucone.

Usługa Azure AI Search udostępnia przykład wdrożenia w wielu regionach, który używa usługi Azure Traffic Manager do przekierowywania żądań, jeśli podstawowy punkt końcowy zakończy się niepowodzeniem. To rozwiązanie jest przydatne podczas kierowania do klienta obsługującego wyszukiwanie, który wywołuje usługę wyszukiwania tylko w tym samym regionie.

Usługa Azure Traffic Manager jest używana głównie do routingu ruchu sieciowego między różnymi punktami końcowymi na podstawie określonych metod routingu (takich jak priorytet, wydajność lub lokalizacja geograficzna). Działa na poziomie DNS w celu kierowania żądań przychodzących do odpowiedniego punktu końcowego. Jeśli punkt końcowy obsługujący usługę Traffic Manager rozpoczyna odrzucanie żądań, ruch jest kierowany do innego punktu końcowego.

Usługa Traffic Manager nie zapewnia punktu końcowego dla bezpośredniego połączenia z usługą Azure AI Search, co oznacza, że nie można umieścić usługi wyszukiwania bezpośrednio za usługą Traffic Manager. Zamiast tego założeniem jest to, że żądania przepływają do usługi Traffic Manager, a następnie do klienta internetowego obsługującego wyszukiwanie, a na koniec do usługi wyszukiwania w zapleczu. Klient i usługa znajdują się w tym samym regionie. Jeśli jedna usługa wyszukiwania ulegnie awarii, klient wyszukiwania rozpocznie się niepowodzeniem, a usługa Traffic Manager przekierowuje do pozostałego klienta.

Diagram przedstawiający łączenie aplikacji wyszukiwania za pośrednictwem usługi Azure Traffic Manager.

Miejsce przechowywania danych we wdrożeniu w wielu regionach

Podczas wdrażania wielu usług wyszukiwania w różnych regionach geograficznych zawartość jest przechowywana w regionie wybrany dla każdej usługi wyszukiwania.

Usługa Azure AI Search nie przechowuje danych poza określonym regionem bez autoryzacji. Autoryzacja jest niejawna, gdy używasz funkcji zapisywanych w zasobie usługi Azure Storage: pamięci podręcznej wzbogacania, sesji debugowania, magazynu wiedzy. We wszystkich przypadkach konto magazynu jest podane w wybranym regionie.

Uwaga

Jeśli zarówno konto magazynu, jak i usługa wyszukiwania znajdują się w tym samym regionie, ruch sieciowy między wyszukiwaniem a magazynem używa prywatnego adresu IP i występuje w sieci szkieletowej firmy Microsoft. Ponieważ są używane prywatne adresy IP, nie można skonfigurować zapór ip ani prywatnego punktu końcowego na potrzeby zabezpieczeń sieci. Zamiast tego użyj wyjątku zaufanej usługi jako alternatywy, gdy obie usługi znajdują się w tym samym regionie.

Informacje o awariach usług i katastroficznych zdarzeniach

Zgodnie z umową SLA firma Microsoft gwarantuje wysoki poziom dostępności żądań zapytań dotyczących indeksu, gdy wystąpienie usługi Azure AI usługa wyszukiwania jest skonfigurowane z co najmniej dwiema replikami, a żądania aktualizacji indeksu, gdy wystąpienie usługi Azure AI usługa wyszukiwania jest skonfigurowane z co najmniej trzema replikami. Nie ma jednak wbudowanego mechanizmu odzyskiwania po awarii. Jeśli usługa ciągła jest wymagana w przypadku awarii katastrofanej poza kontrolą firmy Microsoft, zalecamy aprowizowanie drugiej usługi w innym regionie i wdrożenie strategii replikacji geograficznej w celu zapewnienia, że indeksy są w pełni nadmiarowe we wszystkich usługach.

Klienci, którzy używają indeksatorów do wypełniania i odświeżania indeksów, mogą obsługiwać odzyskiwanie po awarii za pośrednictwem indeksatorów specyficznych dla obszaru geograficznego, które pobierają dane z tego samego źródła danych. Dwie usługi w różnych regionach, z których każdy uruchamia indeksator, może indeksować to samo źródło danych, aby osiągnąć nadmiarowość geograficzną. Jeśli indeksujesz ze źródeł danych, które są również geograficznie nadmiarowe, pamiętaj, że indeksatory usługi Azure AI Search mogą wykonywać indeksowanie przyrostowe (scalanie aktualizacji z nowych, zmodyfikowanych lub usuniętych dokumentów) z replik podstawowych. W przypadku zdarzenia trybu failover pamiętaj, aby przekierować indeksator do nowej repliki podstawowej.

Jeśli nie używasz indeksatorów, użyj kodu aplikacji do wypychania obiektów i danych do różnych usług wyszukiwania równolegle. Aby uzyskać więcej informacji, zobacz Synchronizowanie danych między wieloma usługami.

Tworzenie kopii zapasowej i przywracanie alternatyw

Strategia ciągłości działania dla warstwy danych zwykle obejmuje krok przywracania z kopii zapasowej. Ponieważ usługa Azure AI Search nie jest podstawowym rozwiązaniem magazynu danych, firma Microsoft nie udostępnia formalnego mechanizmu samoobsługowego tworzenia kopii zapasowych i przywracania. Można jednak użyć przykładowego kodu index-backup-restore w tym przykładowym repozytorium .NET usługi Azure AI Search, aby utworzyć kopię zapasową definicji indeksu i migawki do serii plików JSON, a następnie użyć tych plików do przywrócenia indeksu, jeśli to konieczne. To narzędzie może również przenosić indeksy między warstwami usług.

W przeciwnym razie kod aplikacji używany do tworzenia i wypełniania indeksu jest de facto opcją przywracania w przypadku usunięcia indeksu przez pomyłkę. Aby ponownie skompilować indeks, należy go usunąć (zakładając, że istnieje), ponownie utworzyć indeks w usłudze i ponownie załadować, pobierając dane z podstawowego magazynu danych.