Quelques temps après avoir déployé le Resource Provider App Service dans notre environnement Azure Stack, j’ai eu la mauvaise surprise de constater qu’il ne se chargeait plus et qu’il n’était plus possible de créer de nouvelles Web App :
Could not validate app name
Ni d'accéder aux propriétés de celles déjà créées :
La console de debug du navigateur (touche F12) permet d’observer un grand nombre d'erreurs 500 pour des requêtes vers https://management.<location>.<domaine> et vers https://api.appservice.<location>.<domaine> :
Dans le portail d’administration, le dashboard app service ne se charge plus non plus, et le message d’erreur donne un premier indice sur la cause du dysfonctionnement :
Failed to load App Service extension. Please check whether App Service resource provider and database is up and running
Allons donc voir du côté des VM « contrôleur » (CN0 et CN1) de l’environnement du Resource Provider. Il y est possible de s’y connecter en RDP à condition d’autoriser le port 3389 dans leur NSG.
Ces VM contiennent une console MMC Web Cloud Management (son raccourci se trouve sur le bureau) qui permet la gestion de tous les composants du RP (Front End, Workers…) et pourrait donc nous en apprendre plus, mais elle plante lors de son ouverture :
The Resource Metering Service has experienced an unhandled exception. Exception: 'Microsoft.Web.Hosting.WebHostingException: Login failed for user 'appservice_metering_Common'. ---> System.Data.SqlClient.SqlException: Login failed for user 'appservice_metering_Common'.)
Ce nouveau message d’erreur sembler confirmer un problème du côté de la base de données.
Cette dernière est hébergée sur un cluster Always On qui fait partie de l’environnement « backend » du Resource Provider : il a été déployé séparément, en utilisant le template « haute disponiblité » de référence Microsoft.
Il est possible de se connecter en RDP à un des nœud du cluster (aps-sql-0 ou 1) à partir d’une des VM « contrôleur » CN-VM sans modifier les règles NSG, à l’aide du compte admin du domaine utilisé pour déployer l’environnement backend.
Une fois connecté, on peut ouvrir SQL Management Studio sur les deux instances :
On constate alors qu'une seule des instance dispose des bases de données nécessaires au fonctionnement du Resource Provider.
La raison en est simple : c'est parce que le template de déploiement du backend fourni par Microsoft ne configure pas automatiquement l'availability group always on. C'est d'ailleurs rappelé dans les release notes du Resource provider, il faut le configurer manuellement… mais il est facile de manquer ce détail, et la procédure n’est pas détaillée.
Commençons donc par sauvegarder les bases, puis identifions le serveur qui est configuré comme « Primary » dans l’Availability Group Always On :
La procédure d’ajout des bases ne peut être réalisée que sur le nœud « primary », mais il doit aussi être celui qui possède les bases; ce n’est pas le cas ici (les bases sont sur le nœud « secondary », il faut donc commencer par réaliser un failover de l'availability group.
Nous pouvons ensuite y rajouter les bases :
Faites un clic-droit sur Availability Databases puis sélectionnez Add Database.
Cochez les bases à ajouter :
Cliquez sur connect pour ouvrir la connexion vers l'autre noeud
Sélectionnez une synchronisation « Full » puis terminez l’assistant.
Les bases sont très petites et la synchronisation est donc quasi-instantanée.
Une fois terminée, la MMC Web Cloud doit maintenant se lancer sans erreur et le Resource Provider est à nouveau fonctionnel!