Spolehlivost ve službě Azure AI Search

  • Článek

Spolehlivost napříč Azure znamená odolnost a dostupnost, pokud dojde k výpadku nebo snížení výkonu služby. Ve službě Azure AI Search je možné dosáhnout spolehlivosti v rámci jedné služby nebo prostřednictvím několika vyhledávacích služeb v samostatných oblastech.

  • Nasaďte jednu vyhledávací službu a vertikálně navyšte kapacitu pro zajištění vysoké dostupnosti. Můžete přidat více replik pro zpracování vyššího indexování a dotazování úloh. Pokud vaše vyhledávací služba podporuje zóny dostupnosti, repliky se automaticky zřídí v různých fyzických datových centrech kvůli větší odolnosti.

  • Nasaďte více vyhledávacích služeb napříč různými geografickými oblastmi. Všechny úlohy vyhledávání jsou plně obsažené v jedné službě, která běží v jedné geografické oblasti, ale ve scénáři s více službami máte možnosti pro synchronizaci obsahu tak, aby byla stejná ve všech službách. Pokud dojde k výpadku služby, můžete také nastavit řešení vyrovnávání zatížení pro redistribuci požadavků nebo převzetí služeb při selhání.

V případě kontinuity podnikových procesů a zotavení po haváriích na regionální úrovni naplánujte multiregionální topologii, která se skládá z více vyhledávacích služeb s identickou konfigurací a obsahem. Váš vlastní skript nebo kód poskytuje mechanismus převzetí služeb při selhání alternativní vyhledávací službě, pokud se náhle stane nedostupným.

Vysoká dostupnost

Ve službě Azure AI Search jsou repliky kopie vašeho indexu. Vyhledávací služba je zprovozněna s alespoň jednou replikou a může mít až 12 replik. Přidání replik umožňuje službě Azure AI Search provádět restartování počítače a údržbu na jedné replice, zatímco spouštění dotazů pokračuje na jiných replikách.

U každé jednotlivé služby Search Microsoft zaručuje minimálně 99,9% dostupnost, pokud konfigurace splňuje tato kritéria:

  • Dvě repliky pro zajištění vysoké dostupnosti úloh jen pro čtení (dotazy)

  • Tři nebo více replik pro zajištění vysoké dostupnosti úloh pro čtení i zápis (dotazy a indexování)

Systém má interní mechanismy pro monitorování stavu repliky a integrity oddílů. Pokud zřídíte konkrétní kombinaci replik a oddílů, systém zajistí tuto úroveň kapacity pro vaši službu.

Pro úroveň Free neposkytujeme žádnou smlouvu SLA. Další informace najdete ve sla pro Azure AI Search.

Podpora zón dostupnosti

Zóny dostupnosti jsou funkce platformy Azure, která rozděluje datová centra oblasti do různých skupin fyzických umístění, aby poskytovala vysokou dostupnost ve stejné oblasti. Ve službě Azure AI Search jsou jednotlivé repliky jednotkami přiřazení zóny. Vyhledávací služba běží v jedné oblasti; jeho repliky běží v různých fyzických datových centrech (nebo zónách) v dané oblasti.

Zóny dostupnosti se používají při přidávání dvou nebo více replik do vyhledávací služby. Každá replika se umístí do jiné zóny dostupnosti v rámci oblasti. Pokud máte v oblasti vyhledávací služby více replik než dostupné zóny, repliky se distribuují napříč zónami co nejrovnoměrněji. Na vaší straně není žádná konkrétní akce, s výjimkou vytvoření vyhledávací služby v oblasti, která poskytuje zóny dostupnosti, a pak nakonfigurovat službu tak, aby používala více replik.

Požadavky

  • Úroveň služby musí být Standard nebo vyšší.
  • Oblast služby musí být v oblasti, která má dostupné zóny (uvedené v následující části).
  • Konfigurace musí obsahovat více replik: dvě pro úlohy dotazů jen pro čtení, tři pro úlohy čtení i zápisu, které zahrnují indexování.

Podporované oblasti

Podpora zón dostupnosti závisí na infrastruktuře a úložišti. V současné době dvě zóny, které byly oznámeny v říjnu 2023, nemají dostatek úložiště a neposkytují zónu dostupnosti pro Azure AI Search:

  • Izrael - střed
  • Itálie - sever

V opačném případě se zóny dostupnosti pro Azure AI Search podporují v následujících oblastech:

Oblast Zavedení
Austrálie – východ 30. ledna 2021 nebo novější
Brazílie – jih 2. května 2021 nebo novější
Kanada – střed 30. ledna 2021 nebo novější
Indie – střed 20. ledna 2022 nebo novější
USA – střed 4. prosince 2020 nebo novější
Čína – sever 3 7. září 2022 nebo novější
Východní Asie 13. ledna 2022 nebo novější
USA – východ 27. ledna 2021 nebo novější
USA – východ 2 30. ledna 2021 nebo novější
Francie – střed 23. října 2020 nebo novější
Německo – středozápad 3. května 2021 nebo novější
Japonsko – východ 30. ledna 2021 nebo novější
Jižní Korea – střed 20. ledna 2022 nebo novější
Severní Evropa 28. ledna 2021 nebo novější
Norsko – východ 20. ledna 2022 nebo novější
Střední Katar 25. srpna 2022 nebo novější
Jižní Afrika – sever 7. září 2022 nebo novější
Středojižní USA 30. dubna 2021 nebo novější
Jihovýchodní Asie 31. ledna 2021 nebo novější
Švédsko – střed 21. ledna 2022 nebo novější
Švýcarsko – sever 7. září 2022 nebo novější
Spojené arabské emiráty – sever 9. září 2022 nebo novější
Velká Británie – jih 30. ledna 2021 nebo novější
US Gov – Virginie 30. dubna 2021 nebo novější
Západní Evropa 29. ledna 2021 nebo novější
USA – západ 2 30. ledna 2021 nebo novější
USA – západ 3 2. června 2021 nebo novější

Poznámka:

Zóny dostupnosti nemění podmínky smlouvy o úrovni služeb Azure AI Search. Stále potřebujete tři nebo více replik pro zajištění vysoké dostupnosti dotazů.

Více služeb v samostatných geografických oblastech

Redundance služeb je nezbytná, pokud vaše provozní požadavky zahrnují:

  • Požadavky na provozní kontinuitu a zotavení po havárii (BCDR) (Azure AI Search neposkytuje okamžité převzetí služeb při selhání, pokud dojde k výpadku).

  • Rychlý výkon pro globálně distribuovanou aplikaci Pokud požadavky na dotazy a indexování pocházejí z celého světa, uživatelé, kteří jsou nejblíže hostitelskému datovému centru, mají rychlejší výkon. Vytváření dalších služeb v oblastech s blízkostí těchto uživatelů může rovnat výkonu pro všechny uživatele.

Pokud potřebujete dvě nebo více vyhledávacích služeb, může jejich vytvoření v různých oblastech splňovat požadavky aplikace na kontinuitu a obnovení a rychlejší doby odezvy globální uživatelské základny.

Azure AI Search neposkytuje automatizovanou metodu replikace indexů vyhledávání napříč geografickými oblastmi, ale existuje několik technik, které tento proces můžou usnadnit implementaci a správu. Tyto techniky jsou popsány v následujících několika částech.

Cílem geograficky distribuované sady vyhledávacích služeb je mít k dispozici dva nebo více indexů ve dvou nebo více oblastech, kde se uživatel přesměruje do azure AI Search, která poskytuje nejnižší latenci:

Cross-tab of services by region

Tuto architekturu můžete implementovat tak, že vytvoříte několik služeb a navrhnete strategii synchronizace dat. Volitelně můžete zahrnout prostředek, jako je Azure Traffic Manager pro žádosti o směrování.

Tip

Nápovědu k nasazení více vyhledávacích služeb napříč několika oblastmi najdete v této ukázce Bicep na GitHubu , která nasadí plně nakonfigurované víceregionální řešení vyhledávání. Ukázka nabízí dvě možnosti synchronizace indexů a přesměrování požadavků pomocí Traffic Manageru.

Synchronizace dat napříč několika službami

Existují dvě možnosti synchronizace dvou nebo více jedinečných vyhledávacích služeb:

  • Načtení aktualizací obsahu do indexu vyhledávání pomocí indexeru
  • Nasdílejte obsah do indexu pomocí rozhraní REST API pro přidání nebo aktualizaci dokumentů nebo ekvivalentního rozhraní API sady Azure SDK.

Pokud chcete nakonfigurovat některou z možností, doporučujeme použít ukázkový skript Bicep v úložišti azure-search-multiple-region změněný na vaše oblasti a strategie indexování.

Možnost 1: Použití indexerů k aktualizaci obsahu ve více službách

Pokud už indexer používáte v jedné službě, můžete ve druhé službě nakonfigurovat druhý indexer tak, aby používal stejný objekt zdroje dat a načítá data ze stejného umístění. Každá služba v každé oblasti má svůj vlastní indexer a cílový index (index vyhledávání není sdílený, což znamená, že každý index má vlastní kopii dat), ale každý indexer odkazuje na stejný zdroj dat.

Tady je základní vizuál toho, jak by tato architektura vypadala.

Single data source with distributed indexer and service combinations

Možnost 2: Použití rozhraní REST API pro nabízení aktualizací obsahu ve více službách

Pokud k odesílání obsahu do indexu vyhledávání používáte rozhraní REST API služby Azure AI Search, můžete zajistit synchronizaci různých vyhledávacích služeb tak, že při každé aktualizaci nasdílíte změny do všech vyhledávacích služeb. V kódu nezapomeňte zpracovávat případy, kdy aktualizace jedné vyhledávací služby selže, ale u jiných vyhledávacích služeb bude úspěšná.

Převzetí služeb při selhání nebo přesměrování požadavků na dotazy

Pokud potřebujete redundanci na úrovni požadavku, Azure nabízí několik možností vyrovnávání zatížení:

  • Azure Traffic Manager, který se používá ke směrování požadavků na několik geograficky umístěných webů, které pak využívají více vyhledávacích služeb.
  • Application Gateway, která se používá k vyrovnávání zatížení mezi servery v oblasti v aplikační vrstvě.
  • Azure Front Door, který slouží k optimalizaci globálního směrování webového provozu a zajištění globálního převzetí služeb při selhání.

Při vyhodnocování možností vyrovnávání zatížení je potřeba mít na paměti některé body:

  • Vyhledávání je back-endová služba, která přijímá požadavky na dotazy a indexování od klienta.

  • Požadavky z klienta do vyhledávací služby musí být ověřeny. Pro přístup k operacím vyhledávání musí volající mít oprávnění založená na rolích nebo zadat klíč rozhraní API v požadavku.

  • Koncové body služby jsou ve výchozím nastavení dostupné prostřednictvím veřejného připojení k internetu. Pokud nastavíte privátní koncový bod pro připojení klientů, která pocházejí z virtuální sítě, použijte Application Gateway.

  • Azure AI Search přijímá požadavky adresované koncovému <your-search-service-name>.search.windows.net bodu. Pokud se dostanete ke stejnému koncovému bodu pomocí jiného názvu DNS v hlavičce hostitele, například CNAME, požadavek se odmítne.

Azure AI Search poskytuje ukázku nasazení ve více oblastech, která pro přesměrování požadavků používá Azure Traffic Manager, pokud primární koncový bod selže. Toto řešení je užitečné při směrování do klienta s podporou vyhledávání, který volá pouze vyhledávací službu ve stejné oblasti.

Azure Traffic Manager se primárně používá ke směrování síťového provozu napříč různými koncovými body na základě konkrétních metod směrování (například priority, výkonu nebo geografického umístění). Funguje na úrovni DNS a směruje příchozí požadavky na příslušný koncový bod. Pokud koncový bod, který služba Traffic Manager obsluhuje, začne odmítat požadavky, provoz se směruje do jiného koncového bodu.

Traffic Manager neposkytuje koncový bod pro přímé připojení ke službě Azure AI Search, což znamená, že vyhledávací službu nemůžete umístit přímo za Traffic Manager. Místo toho se předpokládá, že se vyžaduje tok do Traffic Manageru, pak do webového klienta s podporou vyhledávání a nakonec do vyhledávací služby v back-endu. Klient a služba se nacházejí ve stejné oblasti. Pokud dojde k výpadku jedné vyhledávací služby, spustí se selhání vyhledávacího klienta a Traffic Manager přesměruje na zbývajícího klienta.

Search apps connecting through Azure Traffic Manager

O rezidenci dat v nasazení ve více oblastech

Když nasadíte více vyhledávacích služeb v různých geografických oblastech, váš obsah se uloží v oblasti, kterou jste zvolili pro každou vyhledávací službu.

Azure AI Search nebude ukládat data mimo zadanou oblast bez vaší autorizace. Autorizace je implicitní, když používáte funkce, které zapisují do prostředku služby Azure Storage: mezipaměť rozšiřování, ladicí relace, úložiště znalostí. Ve všech případech je účet úložiště, který zadáte, v oblasti podle vašeho výběru.

Poznámka:

Pokud je účet úložiště i vyhledávací služba ve stejné oblasti, síťový provoz mezi vyhledáváním a úložištěm používá privátní IP adresu a vyskytuje se přes páteřní síť Microsoftu. Protože se používají privátní IP adresy, nemůžete nakonfigurovat brány firewall protokolu IP ani privátní koncový bod pro zabezpečení sítě. Místo toho jako alternativu použijte výjimku důvěryhodné služby, pokud jsou obě služby ve stejné oblasti.

O výpadkech služeb a katastrofických událostech

Jak je uvedeno ve smlouvě o úrovni služeb (SLA), Microsoft zaručuje vysokou dostupnost požadavků na dotazy indexu, když je instance Azure AI Search nakonfigurovaná se dvěma nebo více replikami, a žádosti o aktualizaci indexu při konfiguraci instance Azure AI Search se třemi nebo více replikami. Neexistuje však žádný integrovaný mechanismus pro zotavení po havárii. Pokud je v případě závažného selhání mimo kontrolu Microsoftu vyžadována nepřetržitá služba, doporučujeme zřídit druhou službu v jiné oblasti a implementovat strategii geografické replikace, aby se zajistilo, že jsou indexy plně redundantní napříč všemi službami.

Zákazníci, kteří používají indexery k naplnění a aktualizaci indexů, můžou zpracovávat zotavení po havárii prostřednictvím indexerů specifických pro konkrétní geografické oblasti, které načítají data ze stejného zdroje dat. Dvě služby v různých oblastech, z nichž každý spouští indexer, by mohly indexovat stejný zdroj dat, aby bylo možné dosáhnout geografické redundance. Pokud indexujete ze zdrojů dat, které jsou také geograficky redundantní, mějte na paměti, že indexery Azure AI Search můžou provádět přírůstkové indexování (slučování aktualizací z nových, upravených nebo odstraněných dokumentů) z primárních replik. V případě převzetí služeb při selhání nezapomeňte indexer přesměrovat na novou primární repliku.

Pokud indexery nepoužíváte, použijete kód aplikace k paralelnímu nabízení objektů a dat do různých vyhledávacích služeb. Další informace najdete v tématu Zachování synchronizace dat napříč několika službami.

Alternativy zálohování a obnovení

Strategie provozní kontinuity pro datovou vrstvu obvykle zahrnuje krok obnovení ze zálohy. Protože Azure AI Search není primárním řešením úložiště dat, Microsoft neposkytuje formální mechanismus pro samoobslužné zálohování a obnovení. Vzorový kód pro obnovení záloh indexu v tomto ukázkovém úložišti Azure AI Search .NET však můžete použít k zálohování definice a snímku indexu do řady souborů JSON a pak tyto soubory použít k obnovení indexu v případě potřeby. Tento nástroj může také přesouvat indexy mezi úrovněmi služby.

V opačném případě je kód aplikace použitý k vytvoření a naplnění indexu možností de facto obnovení, pokud index odstraníte omylem. Pokud chcete znovu vytvořit index, odstraňte ho (za předpokladu, že existuje), znovu vytvořte index ve službě a znovu načtěte data z primárního úložiště dat.

Další kroky