Betrouwbaarheid in Azure AI Search

Azure AI Search is een schaalbare zoekinfrastructuur die heterogene inhoud indexeert en het ophalen mogelijk maakt via API's, toepassingen en AI-agents. Het is geschikt voor zakelijke zoekscenario's en AI-gestuurde klantervaringen waarbij dynamische inhoud gegenereerd moet worden via chatvoltooiingsmodellen. Als Azure-service biedt AI Search een scala aan mogelijkheden ter ondersteuning van uw betrouwbaarheidsvereisten.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe u Azure AI Search tolerant maakt voor verschillende mogelijke storingen en problemen, waaronder tijdelijke fouten, storingen in de beschikbaarheidszone, regiostoringen en serviceonderhoud. Er wordt ook beschreven hoe u back-ups kunt gebruiken om van andere soorten problemen te herstellen, en enkele belangrijke punten over de Service Level Agreement (SLA) van Azure AI Search worden belicht.

Aanbevelingen voor productie-implementatie voor betrouwbaarheid

Voor productiewerkzaamheden raden we u aan het volgende te doen:

Gebruik een factureerbare laag met ten minste twee replica's. Deze configuratie maakt uw zoekservice toleranter voor tijdelijke fouten en onderhoudsbewerkingen. Het voldoet ook aan de SLA (Service Level Agreement) voor AI Search. De SLA vereist twee replica's voor alleen-lezen taken en drie of meer replica's voor lees- en schrijftaken.
Gebruik de gratis laag niet voor productiegebruik. AI Search biedt geen SLA voor de gratis laag, die beperkt is tot één replica.

Overzicht van betrouwbaarheidsarchitectuur

Wanneer u AI Search gebruikt, maakt u een zoekservice. Elke zoekservice ondersteunt veel zoekindexen die uw doorzoekbare inhoud opslaan.

AI Search is niet ontworpen als een primair gegevensarchief. In plaats daarvan gebruikt u indexeerfuncties om uw zoekservice te verbinden met externe gegevensbronnen. Een indexeerfunctie verkent de brongegevens, roept vaardigheden aan die verwerking en verrijking uitvoeren en vult uw index met de uitvoer van vaardigheden.

U configureert ook het aantal replica's voor uw service. In AI Search is een replica een kopie van de zoekmachine van uw service. U kunt een replica beschouwen als één virtuele machine (VM). Elke zoekservice kan tussen 1 en 12 replica's hebben.

Met de toevoeging van meerdere replica's kan AI Search het volgende doen:

Verhoog de beschikbaarheid van uw zoekservice.
Voer onderhoud uit op de ene replica terwijl query's op andere replica's blijven worden uitgevoerd.
Omgaan met hogere indexerings- en query-workloads.
Verbeter de tolerantie door replica's in verschillende beschikbaarheidszones in te richten als uw regio deze ondersteunt.

Met AI Search wordt automatisch een replica toegewezen als de primaire replica. Alle schrijfbewerkingen worden uitgevoerd op die replica. De andere replica's worden gebruikt voor leesbewerkingen.

In het volgende diagram ziet u hoe een zoekservice met drie replica's kan worden verdeeld over drie beschikbaarheidszones:

U kunt ook het aantal partities configureren, dat de opslag vertegenwoordigt die door de zoekindexen wordt gebruikt.

Het is belangrijk om inzicht te hebben in de impact van het toevoegen van replica's en partities, omdat ze elk op verschillende manieren van invloed zijn op de lees- en schrijfprestaties. Zie De capaciteit van een zoekservice schatten en beheren voor meer informatie over replica's en partities.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle in de cloud gehoste toepassingen moeten de richtlijnen voor tijdelijke foutafhandeling van Azure volgen wanneer ze communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

AI Search-indexeerfuncties hebben ingebouwde tijdelijke foutafhandeling. Als een gegevensbron kort niet beschikbaar is, is de indexeerfunctie ontworpen om te herstellen en opnieuw te proberen. Het maakt gebruik van wijzigingsopsporing om de indexering van het laatst met succes geïndexeerde document te hervatten.

Zoekservices kunnen tijdelijke fouten ondervinden tijdens standaard, ongeplande onderhoudsbewerkingen. Azure AI Search biedt geen voorafgaande melding of staat het plannen van onderhoud op specifieke momenten toe. Hoewel er alles aan wordt gedaan om downtime te minimaliseren, zelfs voor services met één replica, kunnen er nog korte onderbrekingen optreden. Om de tolerantie tegen deze tijdelijke fouten te verbeteren, raden we u aan twee of meer replica's te gebruiken.

Als u toepassingen bouwt die communiceren met AI Search, moeten ze tijdelijke fouten afhandelen. Gebruik een herhalingsstrategie met exponentiële terugval voor zowel lees- als schrijfbewerkingen.

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

AI Search is zone-redundant, dit betekent dat uw replica's worden verdeeld over meerdere beschikbaarheidszones binnen de regio van de zoekservice.

Wanneer u twee of meer replica's aan uw service toevoegt, probeert AI Search elke replica in een andere beschikbaarheidszone te plaatsen. Voor services met meer replica's dan beschikbare zones worden replica's zo gelijkmatig mogelijk verdeeld over zones.

In het volgende diagram ziet u hoe een voorbeeld van een zoekservice met vier replica's kan worden geïmplementeerd in drie beschikbaarheidszones:

Belangrijk

AI Search garandeert niet de exacte plaatsing van replica's. Plaatsing is onderhevig aan capaciteitsbeperkingen, schaalbewerkingen en andere factoren.

Behoeften

Zoneredundantie wordt automatisch ingeschakeld wanneer uw zoekservice voldoet aan alle volgende criteria:

Regioondersteuning: Ondersteuning voor beschikbaarheidszones is afhankelijk van infrastructuur en opslag. Zie Een regio kiezen voor AI Search voor een lijst met ondersteunde regio's.
Rang: Uw service moet zich in de Basic-laag of hoger bevinden
Aantal replica's: Uw service moet ten minste twee replica's hebben

Opmerking

AI Search probeert replica's over meerdere zones te distribueren wanneer u twee of meer replica's hebt. Voor lees- en schrijfworkloads moet u echter drie of meer replica's gebruiken, zodat u de hoogst mogelijke beschikbaarheid-SLA ontvangt.

Exemplaardistributie tussen zones

AI Search probeert replica's in verschillende beschikbaarheidszones te plaatsen. Er zijn echter soms situaties waarin alle replica's van een zoekservice in dezelfde beschikbaarheidszone kunnen worden geplaatst. Deze situatie kan optreden wanneer replica's uit uw service worden verwijderd, bijvoorbeeld wanneer u inschaalt door uw service zo te configureren dat er minder replica's worden gebruikt. Het verwijderen van een replica activeert de resterende replica's niet om zich te herverdelen over de beschikbaarheidszones.

Als u de kans wilt verkleinen dat al uw replica's in één beschikbaarheidszone worden geplaatst, kunt u handmatig een uitschaalbewerking activeren direct na een inschaalbewerking. Stel dat uw zoekservice 10 replica's heeft en u wilt inschalen naar 7 replica's. In plaats van één schaalbewerking uit te voeren, kunt u tijdelijk schalen naar 6 exemplaren en vervolgens onmiddellijk schalen naar 7 exemplaren om het opnieuw verdelen van zones te activeren.

Kosten

Elke zoekservice begint met één replica. Zoneredundantie vereist twee of meer replica's, waardoor de kosten voor het uitvoeren van de service worden verhoogd. Gebruik de prijscalculator om inzicht te krijgen in de gevolgen van de facturering van replica's.

Ondersteuning voor beschikbaarheidszones configureren

Als uw zoekservice voldoet aan de vereisten voor zoneredundantie, is er geen extra configuratie nodig. Waar mogelijk probeert AI Search uw replica's in verschillende beschikbaarheidszones te plaatsen.

Capaciteitsplanning en -beheer

Als u zich wilt voorbereiden op een fout in de beschikbaarheidszone, kunt u overwegen om het aantal replica's te overprovisioneren . Met overprovisioning kan de zoekservice enige capaciteitsverlies tolereren en blijven werken zonder verminderde prestaties. Het toevoegen van replica's tijdens een storing is lastig, dus overprovisioning helpt ervoor te zorgen dat uw zoekservice normale aanvraagvolumes kan verwerken, zelfs met verminderde capaciteit. Zie voor meer informatie Capaciteit beheren door overprovisioning.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer zoekservices zijn geconfigureerd voor zoneredundantie en alle beschikbaarheidszones operationeel zijn.

Verkeersroutering tussen zones: AI Search voert automatische taakverdeling van alle query's en schrijfbewerkingen uit op alle beschikbare replica's. AI Search kan leesbewerkingen verzenden naar elke replica in elke beschikbaarheidszone. Er worden schrijfbewerkingen verzonden naar één primaire replica die door de AI Search-service wordt geselecteerd.
Gegevensreplicatie tussen zones: Wijzigingen in gegevens worden automatisch gerepliceerd tussen replica's in beschikbaarheidszones. Replicatie vindt asynchroon plaats, wat betekent dat schrijfbewerkingen worden doorgevoerd naar één primaire replica voordat ze worden gerepliceerd naar andere replica's.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer zoekservices zijn geconfigureerd voor zoneredundantie en er een storing in de beschikbaarheidszone optreedt.

Detectie en reactie: AI Search is verantwoordelijk voor het detecteren van een fout in een beschikbaarheidszone. U hoeft niets te doen om een zonefailover te starten.

Melding: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. U kunt Azure Resource Health echter gebruiken om te controleren op de status van een afzonderlijke resource en u kunt Resource Health-waarschuwingen instellen om u op de hoogte te stellen van problemen. U kunt Azure Service Health ook gebruiken om inzicht te hebben in de algehele status van de service, inclusief eventuele zonefouten, en u kunt Service Health-waarschuwingen instellen om u op de hoogte te stellen van problemen.

Actieve aanvragen: Aanvragen die replica's verwerken in de mislukte zone, worden beëindigd. Clients moeten de aanvragen opnieuw proberen door de richtlijnen voor het afhandelen van tijdelijke fouten te volgen.
Verwachte gegevensverlies: Als de betrokken beschikbaarheidszone alleen leesreplica's bevat, wordt er geen gegevensverlies verwacht.

Als de primaire replica verloren gaat omdat deze zich in de betrokken zone bevindt, gaan schrijfbewerkingen die nog niet zijn gerepliceerd mogelijk verloren.
Verwachte downtime: In de meeste gevallen wordt van een zonefout niet verwacht dat er downtime optreedt voor uw zoekservice voor leesbewerkingen, omdat leesreplica's in andere beschikbaarheidszones aanvragen blijven verwerken.

Als de primaire replica verloren gaat omdat deze zich in de betrokken zone bevindt, bevordert AI Search automatisch een andere replica om de nieuwe primaire replica te worden, zodat schrijfbewerkingen kunnen worden hervat. Het duurt meestal een paar seconden voordat de replicapromotie plaatsvindt. Gedurende deze tijd slagen schrijfbewerkingen mogelijk niet. Zorg ervoor dat uw toepassingen zijn voorbereid door de richtlijnen voor het afhandelen van tijdelijke fouten te volgen.

Er zijn echter enkele onwaarschijnlijke situaties waarin alle replica's van uw zoekservice zich mogelijk in één beschikbaarheidszone bevinden. In dit scenario ondervindt u mogelijk downtime totdat de zone wordt hersteld. Zie Exemplaardistributie voor meer informatie en om een tijdelijke oplossing te begrijpen.
Verkeer omleiden: Wanneer een zone mislukt, detecteert AI Search de fout en stuurt aanvragen naar actieve replica's in de overlevende zones. Als de primaire replica verloren gaat, wordt een andere replica gepromoveerd tot de nieuwe primaire replica.

Zoneherstel

Wanneer de beschikbaarheidszone wordt hersteld, herstelt AI Search automatisch normale bewerkingen en begint met het routeren van verkeer naar beschikbare replica's in alle zones, inclusief de herstelde zone.

Testen op zonefouten

AI Search beheert verkeersroutering voor zone-redundante services. U hoeft geen zonefoutprocessen te initiëren of valideren.

Tolerantie voor storingen in de hele regio

AI Search is een service met één regio. Als de regio niet meer beschikbaar is, is uw zoekservice ook niet meer beschikbaar.

Aangepaste oplossingen voor meerdere regio's voor veerkracht

U kunt desgewenst meerdere AI Search-services in verschillende regio's implementeren. U bent verantwoordelijk voor het implementeren en configureren van afzonderlijke services in elke regio. Als u een identieke implementatie maakt in een secundaire Azure-regio die gebruikmaakt van een architectuur met meerdere regio's, is uw toepassing minder vatbaar voor een noodgeval met één regio.

Wanneer u deze aanpak volgt, moet u indexen synchroniseren tussen regio's om de laatste toepassingsstatus te herstellen. U moet ook taakverdelings- en failoverbeleid configureren.

Als u de prestaties van uw algehele oplossing wilt optimaliseren, zoekt u naar mogelijkheden om indexering uit te voeren op alleen-lezen replica's van uw gegevensbronnen. Sommige indexeerfuncties ondersteunen bijvoorbeeld het lezen van leesreplica's van een geografisch gedistribueerde gegevensbron.

Zie implementaties voor meerdere regio's in Azure AI Search voor meer informatie.

Backups en herstel

Omdat AI Search geen primaire oplossing voor gegevensopslag is, biedt het geen selfserviceopties voor back-up en herstel. U kunt het index-backup-restore voorbeeld voor .NET of Python echter gebruiken om een back-up te maken van uw indexdefinitie en de bijbehorende documenten naar een reeks JSON-bestanden, die vervolgens worden gebruikt om de index te herstellen.

Als u de index echter per ongeluk verwijdert en geen back-up hebt, kunt u de index opnieuw opbouwen. Herbouwen omvat het opnieuw maken van de index in uw zoekservice en het opnieuw laden ervan door gegevens op te halen uit uw primaire gegevensarchief.

Diensteniveauovereenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

In AI Search is de SLA voor beschikbaarheid van toepassing op zoekservices die:

Zijn geconfigureerd om een factureerbaar niveau te gebruiken.
Ten minste twee replica's hebben voor alleen-lezen workloads (opdrachten).
Ten minste drie replica's voor lees-/schrijfworkloads (query's en indexering).

Feedback

Is deze pagina nuttig?

Last updated on 2025-11-03