Résolution des exceptions FabricInternalServerError et ServiceAllocationFailure lors du déploiement d’un service cloud (classique) sur Azure
Important
Cloud Services (classique) est désormais déconseillé pour tous les clients depuis le 1er septembre 2024. Depuis octobre 2024, tous les déploiements en cours d’exécution ont été arrêtés par Microsoft et les données ont été définitivement perdues. Les nouveaux déploiements doivent utiliser le nouveau modèle de déploiement basé sur Azure Resource Manager Azure Cloud Services (support étendu) .
Dans cet article, vous dépannez les échecs d’allocation lors desquels l’allocation effectuée par le contrôleur de structure n’aboutit pas lors du déploiement d’un service cloud Azure (classique).
Lorsque vous déployez des instances sur un service cloud ou ajoutez de nouvelles instances de rôle Web ou de rôle de travail, Microsoft Azure alloue des ressources de calcul.
Vous pouvez parfois recevoir des erreurs durant ces opérations avant même d’avoir atteint la limite de votre abonnement Azure.
Conseil
Les informations qu’il contient peuvent également vous être utiles dans le cadre de la planification du déploiement de vos services.
Symptôme
Dans le portail Azure, accédez à votre service cloud (classique), puis, dans la barre latérale, sélectionnez Journal des opérations (classique) pour afficher les journaux.
Quand vous inspectez les journaux de votre service cloud (classique), vous constatez l’exception suivante :
| Exception | Message d’erreur |
|---|---|
| FabricInternalServerError | L’opération a échoué avec le code d’erreur « InternalError » et le message d’erreur « Le serveur a rencontré une erreur interne. Réessayez la demande. » |
| ServiceAllocationFailure | L’opération a échoué avec le code d’erreur « InternalError » et le message d’erreur « Le serveur a rencontré une erreur interne. Réessayez la demande. » |
Cause
FabricInternalServerError et ServiceAllocationFailure sont des exceptions qui peuvent se produire lorsque le contrôleur de structure ne parvient pas à allouer des instances dans le cluster. La cause racine varie selon que le service cloud est épinglé ou non épinglé.
- Non épinglé : Échecs d’un premier déploiement d’un nouveau service cloud
- Épinglé : Échecs d’un service cloud existant
Notes
Lorsque la première instance est déployée sur un service cloud (de préproduction ou de production), celui-ci est épinglé à un cluster.
Au fil du temps, les ressources de ce pool de ressources peuvent devenir entièrement utilisées. Si un service cloud effectue une demande d’allocation pour des ressources supplémentaires alors que les ressources disponibles dans le pool de ressources épinglé sont insuffisantes, la demande entraîne un échec d’allocation.
Solution
Suivez les instructions relatives aux échecs d’allocation dans les scénarios suivants.
Non épinglé à un cluster
Lors du premier déploiement d’un service cloud (classique), le cluster n’est pas sélectionné. Le service cloud n’est donc pas épinglé. Azure risque de présenter un échec de déploiement pour les raisons suivantes :
- Vous avez sélectionné une taille particulière qui n’est pas disponible dans la région.
- La combinaison des tailles nécessaires à travers différents rôles n’est pas disponible dans la région.
En cas d’erreur d’allocation dans ce scénario, la procédure recommandée consiste à vérifier les tailles disponibles dans la région et à modifier la taille spécifiée précédemment.
Pour connaître les tailles disponibles dans une région, consultez la page Produits de service cloud (classique).
Notes
La page Produits n’affiche pas la capacité disponible. Pour toute nouvelle allocation, Azure doit être en mesure de sélectionner le cluster optimal dans votre région à ce moment précis.
Mettez à jour le fichier de définition de votre service cloud (classique) pour spécifier une autre taille de produit de votre région.
Épinglé à un cluster
Les services cloud existants sont épinglés à un cluster. Tout déploiement ultérieur du service cloud (classique) s’effectue dans le même cluster.
Lorsque vous rencontrez une erreur d’allocation dans ce scénario, la procédure recommandée consiste à opérer un redéploiement vers un nouveau service cloud (classique) (et à mettre à jour l’enregistrement CNAME).
Conseil
Cette solution est celle qui a le plus de chances de réussir car elle permet à la plateforme de choisir parmi tous les clusters de cette région.
Notes
Cette solution ne devrait pas entraîner de temps d'arrêt.
Déployez la charge de travail vers un nouveau service cloud (classique).
- Pour d’autres instructions, consultez le guide Comment créer et déployer un service cloud (classique).
Avertissement
Si vous ne souhaitez pas perdre l’adresse IP associée à cet emplacement de déploiement, vous pouvez utiliser la Solution 3 : Conserver l’adresse IP.
Mettez à jour l’enregistrement CNAME ou A pour faire pointer le trafic vers le nouveau service cloud (classique).
- Pour d’autres instructions, consultez le guide Configuration d’un nom de domaine personnalisé pour un service cloud Azure.
Une fois que l’ancien ne reçoit plus de trafic, vous pouvez supprimer l’ancien service cloud (classique).
- Pour d’autres instructions, consultez le guide Supprimer des déploiements et un service cloud (classique).
- Pour voir le trafic réseau dans votre service cloud (classique), consultez Introduction à la surveillance de service cloud (classique).
Pour d’autres étapes de correction, consultez Résolution des problèmes d’échecs d’allocation de service cloud (classique) | Microsoft Docs.
Étapes suivantes
Pour d’autres solutions en lien avec les échecs d’allocation et des informations générales :
Si votre problème Azure n’est pas traité dans cet article, rendez-vous sur les forums Azure sur le Microsoft Developer Network (MSDN) et Stack Overflow. Vous pouvez publier votre problème sur ces forums ou sur @AzureSupport sur X. Vous pouvez également envoyer une demande de support Azure. Pour envoyer une demande de support sur la page Prise en charge Azure, sélectionnez Obtenir de l’aide.