Résoudre les problèmes liés aux liens privés partagés dans Recherche IA Azure

Note

Recherche Azure AI est disponible via le portail Azure, les API REST et les SDK Azure. Il sous-tend également Foundry IQ, la couche de connaissances managée qui transforme le contenu d’entreprise en bases de connaissances réutilisables et prenant en charge les autorisations pour les agents dans le portail Microsoft Foundry.

Une liaison privée partagée permet à Recherche Azure AI d’établir des connexions sortantes sécurisées sur un point de terminaison privé lors de l’accès aux ressources d’un client dans un réseau virtuel. Cet article peut vous aider à résoudre les erreurs qui peuvent se produire.

La création d’une liaison privée partagée est une opération du plan de contrôle du service de recherche. Vous pouvez créer une liaison privée partagée à l’aide du portail Azure ou d’une API REST de gestion. Pendant l’approvisionnement, l’état de la requête est Updating. Une fois l’opération terminée, l’état est Succeeded. Un point de terminaison privé pour la ressource, ainsi que toutes les zones et mappages DNS, sont créés. Ce point de terminaison est utilisé exclusivement par votre instance du service de recherche et est géré via Recherche Azure AI.

Étapes impliquées dans la création de ressources de liaison privée partagée

Voici les erreurs courantes qui se produisent pendant la phase de création.

Échecs de validation de requête

  • Référence SKU non prise en charge : les liaisons privées partagées sont prises en charge sur le niveau De base et niveaux supérieurs. Pour les indexeurs avec des ensembles de compétences, le niveau minimal est Standard 1 (S1). Pour plus d’informations, consultez Limites des ressources de liaison privée partagée.

  • Nom non valide : les règles d’affectation de noms pour une liaison privée partagée sont :

    • La longueur doit être comprise entre 1 et 60 caractères
    • Caractères alphanumériques
    • Les noms peuvent inclure le trait de soulignement _, le point . et le trait d’union -, à condition qu’il ne s’agisse pas du premier caractère du nom

  • ID de groupe non valide : Les ID de groupe sont sensibles à la casse et doivent correspondre à l'une des valeurs suivantes.

    Ressource Azure ID de groupe Première version de l’API disponible
    Stockage Azure - Blob (ou) ADLS Gen 2 blob 2020-08-01
    Stockage Azure - Tables table 2020-08-01
    Azure Cosmos DB for NoSQL Sql 2020-08-01
    Azure SQL Database sqlServer 2020-08-01
    Azure Database pour MySQL (préversion) mysqlServer 2020-08-01-Preview
    Azure Key Vault vault 2020-08-01
    Azure Functions (préversion) sites 2020-08-01-Preview

    Les ressources marquées avec « (preview) » doivent être créées à l’aide d’une préversion des versions de l’API REST de gestion.

  • Validation de type de privateLinkResourceId : comme groupId, Recherche Azure AI valide que le « bon » type de ressource est spécifié dans le privateLinkResourceId. Les types de ressource valides sont les suivants :

    Ressource Azure Type de ressource Première version de l’API disponible
    Stockage Azure Microsoft.Storage/storageAccounts 2020-08-01
    Base de données Azure Cosmos DB Microsoft.DocumentDb/databaseAccounts 2020-08-01
    Azure SQL Database Microsoft.Sql/servers 2020-08-01
    Azure Key Vault Microsoft.KeyVault/vaults 2020-08-01
    Azure Database pour MySQL (préversion) Microsoft.DBforMySQL/servers 2020-08-01-Preview
    Azure Functions (préversion) Microsoft.Web/sites 2020-08-01-Preview
    Azure SQL Managed Instance (préversion) Microsoft.Sql/managedInstance 2020-08-01-Preview

    En outre, le groupId spécifié doit être valide pour le type de ressource spécifié. Par exemple, groupId « blob » est valide pour le type Microsoft.Storage/storageAccounts, il ne peut pas être utilisé avec un autre type de ressource. Pour une version d’API de gestion de recherche donnée, les clients peuvent découvrir les détails des types de ressources et groupId pris en charge en utilisant l’ API Répertorier les ressources prises en charge.

  • Application de la limite de quota : les services de recherche ont des quotas imposés sur le nombre de ressources de liaison privée partagée qui peuvent être créées et le nombre de différents types de ressources cibles qui sont utilisés (selon groupId). Pour plus d’informations, consultez Limites des ressources de liaison privée partagée.

Échecs de déploiement

Un service de recherche lance la demande de création d’un lien privé partagé, mais Azure Resource Manager effectue le travail réel. Vous pouvez vérifier l'état du déploiement dans le portail Azure ou par requête, et corriger les erreurs qui pourraient se produire.

Les ressources de liaison privée partagée qui échouent dans le déploiement d’Azure Resource Manager s’affichent dans les appels d’API Liste et Get , mais elles ont un « État d’approvisionnement » de Failed. Une fois que la raison de l’échec du déploiement d’Azure Resource Manager est établie, supprimez la Failed ressource et recréez-la après avoir appliqué la résolution appropriée dans le tableau suivant.

Raison de l’échec de déploiement Descriptif Résolution
« LinkedAuthorizationFailed » Le message d’erreur indique que le client a l’autorisation de créer la liaison privée partagée sur le service de recherche, mais n’a pas l’autorisation d’effectuer l’action « privateEndpointConnectionApproval/action » sur l’étendue liée. Vérifiez à nouveau l’ID de liaison privée dans la requête pour vous assurer qu’il n’y a pas d’erreurs ou d’omissions dans l’URI. Si Recherche Azure AI et la ressource PaaS Azure se trouvent dans différents abonnements, et si vous utilisez REST ou une interface de ligne de commande, vérifiez que le compte Azure actif est la ressource PaaS Azure. Pour les clients REST, vérifiez que vous n’utilisez pas un jeton du porteur expiré et que le jeton est valide pour l’abonnement actif.
Fournisseur de ressources réseau non inscrit pour l’abonnement à la ressource cible Un point de terminaison privé (et ses mappages DNS associés) est créé pour la ressource cible (compte de stockage, Azure Cosmos DB, Azure SQL, etc.) par le biais du fournisseur de ressources (RP) Microsoft.Network. Si l’abonnement qui héberge la ressource cible (« abonnement cible ») n’est pas inscrit auprès du RP Microsoft.Network, le déploiement d’Azure Resource Manager peut échouer. Vous devez inscrire ce RP dans leur abonnement cible. Vous pouvez inscrire le fournisseur de ressources à l’aide du portail Azure, de PowerShell ou de l’interface CLI.
groupId non valide pour la ressource cible Lors de la création de comptes Azure Cosmos DB, vous pouvez spécifier le type d’API pour le compte de base de données. Si Azure Cosmos DB offre plusieurs types d’API différents, Recherche Azure AI prend en charge uniquement « SQL » comme groupId pour les ressources de liaison privée partagée. Lorsqu'une liaison privée partagée de type « Sql » est créée pour un privateLinkResourceId, pointant vers un compte de base de données non-Sql, le déploiement d'Azure Resource Manager échoue en raison de l'incompatibilité groupId. L’ID de ressource Azure d’un compte Azure Cosmos DB n’est pas suffisant pour déterminer le type d’API utilisé. Recherche Azure AI tente de créer le point de terminaison privé, mais Azure Cosmos DB le rejette ensuite. Vous devez vous assurer que le privateLinkResourceId de la ressource Azure Cosmos DB spécifiée est destiné à un compte de base de données de type API « SQL »
Ressource cible introuvable L’existence de la ressource cible spécifiée dans privateLinkResourceId est vérifiée uniquement au début du déploiement d’Azure Resource Manager. Si la ressource cible n’est plus disponible, le déploiement échoue. Vous devez vous assurer que la ressource cible est présente dans l’abonnement et le groupe de ressources spécifiés et qu’elle n’est pas déplacée/supprimée.
Erreurs temporaires/autres Le déploiement d’Azure Resource Manager peut échouer en cas de panne de l’infrastructure ou pour d’autres raisons inattendues. Cela doit être rare et indique généralement un état transitoire. Réessayez de créer cette ressource ultérieurement. Si le problème persiste, contactez le support Azure.

Problèmes d’approbation du point de terminaison privé de stockage

Un point de terminaison privé est créé dans la ressource Azure cible, comme spécifié dans la demande de création de liaison privée partagée. Il s’agit de l’une des dernières étapes de l’opération de déploiement asynchrone d’Azure Resource Manager, mais Recherche Azure AI doit lier l’adresse IP privée du point de terminaison privé dans le cadre de sa configuration réseau. Une fois ce lien terminé, la ressource provisioningState de liaison privée partagée passe à un état Succeededde réussite terminal. Les clients doivent uniquement approuver ou refuser (ou en général modifier la configuration du point de terminaison privé de stockage) après la transition de l’état vers Succeeded. La modification du point de terminaison privé d’une manière quelconque avant cela peut entraîner une opération de déploiement incomplète et peut entraîner la fin de la ressource de liaison privée partagée (soit immédiatement, soit généralement dans quelques heures) dans un état Failed.

Le changement de connectivité réseau du service Search est bloqué dans un état « Mise à jour »

Les liaisons privées partagées et les points de terminaison privés sont utilisés lorsque l’Accès au réseau public du service de recherche est Désactivé. En règle générale, la modification de la connectivité réseau doit réussir quelques minutes après l’acceptation de la demande. Dans certaines circonstances, Recherche Azure AI peut prendre plusieurs heures pour terminer l’opération de modification de la connectivité.

Capture d’écran de la modification de l’accès au réseau public sur Désactivé.

Si vous constatez que l’opération de modification de connectivité prend beaucoup de temps, attendez quelques heures. Les opérations de modification de connectivité impliquent des opérations telles que la mise à jour d’enregistrements DNS qui peuvent prendre plus de temps que prévu.

Si l’accès au réseau public est modifié, les liaisons privées partagées existantes et les points de terminaison privés peuvent ne pas fonctionner correctement. Si les liaisons privées partagées et les points de terminaison privés existants cessent de fonctionner pendant une opération de modification de connectivité, attendez quelques heures que l’opération se termine. S’ils ne fonctionnent toujours pas, essayez en les supprimant, puis en les recréant.

En règle générale, une ressource de liaison privée partagée doit passer à un état de terminal (Succeeded ou Failed) en quelques minutes après l’acceptation de la demande.

Dans de rares cas, Recherche Azure AI peut ne pas être en mesure de marquer correctement l’état de la ressource de liaison privée partagée sur un état terminal (Succeeded ou Failed). Cela se produit généralement en raison d’un échec inattendu. Les ressources de liaisons privées partagées sont automatiquement transitionnées vers un état Failed si elles sont « bloquées » dans un état non terminal depuis plus de quelques heures.

Si la ressource de liaison privée partagée ne passe pas à un état de terminal, attendez quelques heures pour vous assurer qu’elle devient Failed avant de pouvoir la supprimer et la recréer. Ou bien, au lieu d’attendre, vous pouvez essayer de créer une autre ressource de liaison privée partagée avec un nom différent (en conservant tous les autres paramètres).

Une ressource de liaison privée partagée existante peut être mise à jour à l’aide de l’API de création ou de mise à jour. La recherche n’autorise que les mises à jour restrictives de la ressource de liaison privée partagée. Seul le message de demande peut être modifié par le biais de cette API.

  • Il n’est pas possible de mettre à jour les propriétés « principales » d’une ressource de liaison privée partagée existante (comme privateLinkResourceId ou groupId), et cette opération ne sera jamais prise en charge. Si une autre propriété en plus du message de demande doit être modifiée, nous conseillons aux clients de supprimer et recréer la ressource de liaison privée partagée.

  • La mise à jour du message de demande d’une ressource de liaison privée partagée n’est possible que si elle atteint l’état d’approvisionnement de Succeeded.

Les clients peuvent supprimer une ressource de liaison privée partagée existante via l’API de suppression. Comme avec le processus de création (ou de mise à jour), il s’agit d’une opération asynchrone en quatre étapes :

  1. Vous demandez au service de recherche de supprimer la ressource de liaison privée partagée.

  2. Le service de recherche confirme que la ressource existe et qu’elle est dans un état valide pour la suppression. Si c’est le cas, il initie une opération de suppression d’Azure Resource Manager pour supprimer la ressource.

  3. Recherchez les requêtes pour la fin de l’opération (qui prend généralement quelques minutes). À ce stade, la ressource de lien privé partagé aurait un état d’approvisionnement de Deleting.

  4. Une fois l’opération terminée avec succès, le point de terminaison privé de sauvegarde et les mappages DNS associés sont supprimés. La ressource ne s’affiche pas dans le cadre de l’opération Liste et tente d’effectuer une opération Get sur cette ressource entraîne une erreur 404 Introuvable.

Étapes impliquées dans la suppression de ressources de liaison privée partagée

Voici les erreurs courantes qui se produisent pendant la phase de suppression.

Type d’échec Descriptif Résolution
La ressource est dans un état non déterministe Impossible de supprimer une ressource de liaison privée partagée qui ne se trouve pas dans un état terminal (Succeeded ou Failed). Il est possible (rare) qu’une ressource de liaison privée partagée soit bloquée dans un état non déterministe pendant jusqu’à 8 heures. Attendez que la ressource atteigne un état de terminal et réessayez la demande de suppression.
Échec de l’opération de suppression avec l’erreur « Conflit » L’opération Azure Resource Manager pour supprimer une ressource de liaison privée partagée arrive au fournisseur de ressources de la ressource cible spécifiée dans privateLinkResourceId (« RP cible ») avant de pouvoir supprimer le point de terminaison privé et les mappages DNS. Les clients peuvent utiliser des verrous de ressources Azure pour empêcher toute modification de leurs ressources. Lorsqu’Azure Resource Manager atteint le RP cible, le RP cible doit modifier l’état de la ressource cible (pour supprimer les détails sur le point de terminaison privé de ses métadonnées). Quand un verrou est configuré sur la ressource cible (ou son groupe de ressources/abonnement), l’opération Azure Resource Manager échoue avec un « Conflit » (et les détails appropriés). La ressource de liaison privée partagée n’est pas supprimée. Les clients doivent supprimer le verrou sur la ressource cible avant de retenter l’opération de suppression. Remarque : ce problème peut également se produire lorsque des clients essaient de supprimer un service de recherche avec des ressources de liaison privée partagée qui pointent vers des ressources cibles « verrouillées ».
L’opération de suppression a échoué L’opération de suppression Azure Resource Manager asynchrone peut échouer dans de rares cas. Lorsque cette opération échoue, l’interrogation de l’état de l’opération asynchrone présente un message d’erreur et des détails appropriés. Réessayez l’opération ultérieurement ou contactez le support Azure si le problème persiste.
La ressource est bloquée dans l’état « Suppression » Dans de rares cas, une ressource de liaison privée partagée peut être bloquée dans l’état « Suppression » pendant jusqu’à 8 heures, probablement en raison d’une défaillance catastrophique sur le RP de recherche. Attendez 8 heures, après quoi la ressource passera à l’état Failed, puis réexécutez la demande.

Étapes suivantes

En savoir plus sur les ressources de liaison privée partagée et sur leur utilisation pour sécuriser l’accès au contenu protégé.

  • Last updated on