Précisions sur les différences entre les tailles de VM Azure : Bande passante réseau

Outres les différences connues entre les type de VM Azure (taille mémoire, taille disque, nombre de coeur CPU), une autre caractéristique technique est différentiente : la bande passante réseau disponible. En effet, la vitesse de la connectivité réseau (bien que virtuelle) est différente en fonction de la taille de la VM. La règle est de 100Mbs par cœur de CPU, sauf pour l’ExtraSmall.

Extra small :     5Mbs          
Small : 100Mbs
Medium : 200Mbs    
Large : 400Mbs
ExtraLarge : 800Mbs        

 

En conséquence, si vous avez à effectuer des taches peu consommatrice en temps CPU mais nécessitant un gros débit réseau, il peut être judicieux de choisir des tailles de VM plus grosses. les VM ExtraSmall était clairement destiné à des petites applications ou pour faire du développement/test.

Azure : Baisse de prix depuis le 8 mars 2012

Outre les baisses de prix de SQL Azure annoncé le 15/02 (cf ce billet), Microsoft vient d’annoncer de nouvelles baisses de la tarifications sur d’autres services Azure :

• Azure Storage : le Gb passe à 0.0887€
• Azure Compute : les instances Extra Small voit leur prix divisé par 2 : au lieu d’être compatibilité comme 1/3 d’heure ‘Small’, elles sont comptabilisé comme 1/6 d’heure ‘Small’. (je rappelle de l’heure de VM Small est l’utilisation de comptabilisation du temps de calcul dans Azure Compute)

La baisse de prix des instance ExtraSmall est extrêmement intéressante pour 2 profils de consommateurs :

• site web à très faible montée en charge
• développeur (abonnement MSDN, …) : cette baisse de cout multiplie donc par 2 le nombre d’heure de vm “Extra Small” utilisable gratuitement dans le cadre de ses abonnements. De quoi se sentir moins à l’étroit pour ses tests

Le détail de la tarification se trouve ici : http://www.windowsazure.com/fr-fr/pricing/details/

Windows Azure SDK 1.5 et l’erreur “DevFC.exe stopped working”

Apres installation du SDK Azure 1.5 sur mon poste de développement, l’émulateur Azure (Windows Azure Compute Emulator) ne pouvait plus démarrer. Une boite de dialogue d’erreur “DevFC.exe stopped working” indiquait le crash de l’émulateur du Fabric Controller de l’émulateur.

Pourtant tout fonctionnait bien avec le SDK 1.4

Solution brute : je fais une VM pour mon Dev … mais je ne sais toujours pas ce qui coince sur mon poste de développement originel.

Solution finaude : Analyser les logs, et aimer la ligne de commande

Les logs du FabricControler de développement se trouve dans C:\Users\[VOTRE_USER_NAME]\AppData\Local\dftmp\DevFCLogs.

En analysant ce fichier, on trouve une exception :

Exception occurred when trying to open service host. {0}, {1}`Il existe déjà un écouteur sur le point de terminaison IP 127.0.0.1:12000. Vérifiez que vous n’essayez pas d’utiliser ce point de terminaison plusieurs fois dans votre application et qu’aucune autre application n’écoute sur ce point de terminaison.`

Tout est dans le message : un autre programme occupe le port IP 12000 que cherche à utiliser DevFC.exe. 

Pour savoir quel programme utilise ce port, ouvrez une invite de commande, et exécuter la commande “netstat –b –n –a” pour lister tous les ports IP utilisés sur le système et quel programme les utilise :

Et je découvre que le port 12000 est utilisé par le programme “htcUPCTloader.exe” … programme de gestion des terminaux Android HTC.

Je stoppe le programme avec le gestionnaire de tache, redémarre le “Compute emulator” … et tout marche à merveille, je peux déployer mes applications Azure dans le Compute Emulator.

 

Dans mon cas, il s’agissait du port 12000 occupé par htcUPCTLoader, pour d’autres cas recensés il s’agit du port 12001 occupé par VMWare. La procédure pour identifier l’origine reste la même.

 

Espérons que Microsoft corrige ce désagrément en mettant en place une sélection automatique des ports.