CPU à 100% sur des VMs Azure, Bug Azure Workload Backup, Lsass.exe et IaaSWLpluginSvc, Explication et Contournement

Hello les Techies !

Depuis fin février un problème est apparu chez plusieurs utilisateurs de Microsoft Azure, le CPU de certaines VMs montant à 100% d’un jour à l’autre ! la cause ? l’extension Azure Workload Backup !

J’ai moi même rencontré ce problème depuis le 27 février que plusieurs VMs Azure, je vous explique ce qui c’est passé et vous livre la solution de contournement proposée pas le support Microsoft 🙂

Pour l’instant pas de communication officielle du côté MS ni même de patch officiel mais le support a quand même pu livrer un Workaround comme on dit dans le milieu !

🔥 CPU à 100%, Lsass.exe et IaaSWLpluginSvc en cause ?

Voilà ce qu’il se passe le 27 février au matin sur des VMs Azure en production 😬

Autant vous dire, que les utilisateurs finaux des services hébergés sur ces VMs ressentent une dégradation et le fond savoir !!!

En plus de ça la VM contrôleur de domaine est elle aussi impactée avec le processus LSASS.exe qui consomme toute la ressource CPU ce qui provoque un forte latence sur les connexions utilisateurs !!!

🚒 Que faire ?

La charge CPU semble redescendre sur certaines VMs mais pas sur le contrôleur de domaine, est-ce lui qui part en vrille ? pas de mise à jour ni de modifications récente sur celui-ci pourtant !

Je monte un second contrôleur en urgence, SKU de VM différent ( très rapide avec un script PowerShell déjà fait pour déployer la VM et le rôle 😉 ) et je redirige certaines VM vers ce nouveau contrôleur à l’aide de règles NSG les obligeant à ce connecter sur celui-ci à la place du premier.

Le résultat est le même ! le processus LSASS.exe monte rapidement en charge sur le nouveau contrôleur et le CPU arrive à saturation comme sur le premier !!

💡 Le problème Azure Workload Backup

Je prend donc du recul sur la situation et je me pose un peu plus sur les journaux et le moniteur de ressources.

Je remarque qu’un trafic réseau anormal provient de certaines VMs et elle ont toute un point en commun ! ce sont des VMs hébergeant SQL server !

Le problème ne vient donc pas de LSASS.exe mais plutôt de l’autre processus, IaaSWLpluginSvc ! et que fait celui-ci ? c’est le processus installé par l’extension de machine virtuelle Azure Workload Backup.

Pourquoi/comment ?

Et bien quand on active la sauvegarde Azure pour les charges de travail dont SQL dans les machines virtuelles, une extension est automatiquement déployée sur les VM en question pour pouvoir se connecter aux instances SQL et les sauvegarder.

Je décide donc de désactiver la sauvegarde SQL + désinstaller l’extension sur une VM de test… et là miracle 🙏

OK on a trouvé l’origine du problème, un bug de l’extension Azure Workload Backup mais la sauvegarde dans tous ça ? et bien il n’y en a plus !!!

Ce n’est absolument pas envisageable d’appliquer ça sur les VMs de production !!! il nous faut donc attendre une solution côté Microsoft chez qui j’ai ouvert un ticket et je ne suis pas le seul à rencontrer ce problème en plus…

👍 La solution de contournement (10 jours plus tard…)

Après plusieurs jours à temporiser avec des backups désactivés sur les VM hors production, un autre contrôleur de domaine pour repartir la charge et une surveillance de tous les CPU de l’infra H24, enfin Microsoft répond avec une solution de contournement !

Le problème vient bien de l’extension Azure Workload Backup et plus précisément de la communication de celle-ci avec les autres processus (NamedPipes)

Les NamedPipes sont une fonctionnalité de Windows utilisée pour la communication inter-processus, permettant à différents processus sur la même machine ou sur des machines différentes de communiquer entre eux. Ils sont par exemple utilisés dans les applications réseau pour les échanges de données.

Et le correctif alors ?

Et bien il faut modifier la valeur du paramètre AllowCommunicationThroughNamedPipes pour passer de true à false

Dans le fichier PluginManifest.json qui se trouve dans C:\Program Files\Azure Workload Backup\bin\plugins\SQL

Ensuite dans le gestionnaire de tâches, arrêtez les services AzureWLBackupPluginSvc et AzureWLBackupInquirySvc.

Et pour finir redémarrez AzureWLBackupCoordinatorSvc !

Et puis voilà ! le CPU revient à la normale immédiatement ! et les sauvegardes SQL sont toujours fonctionnelles ! 👏

Conclusion

10 jours de tests et de supervision avec une petite pression client assaisonné de doutes et d’incertitudes pour au final confirmer la cause ! un problème MS…

Cela nous a permis de mieux connaitre le fonctionnement de l’extension Azure Workload Backup même si je m’en serais bien passé 😄

j’espère que cet article pourra vous servir si cela vous arrive ! n’hésitez pas à partager vos retours d’XP en commentaires !

A+ le Techies.