Cette semaine, dans l’épisode 114 du Cloud Cover Show, Nick Harris et Chris Risner sont accompagnés de Stephen Siciliano, Senior Program Manager sur Windows Azure Autoscale. 

image

Mais avant de parler des fonctionnalités de mise à l’échelle automatisée, d’alertes et et de journaux d’exploitation (operation logs), il est d’abord question de quelques nouvelles.

NB: je noterai [xx:yy] l’endroit de la vidéo où vous pouvez retrouver l’information dans la vidéo. Ex: l’image ci-dessus est à [00:28].

Les pages web suivantes sont commentées :

Après un interlude pour souhaiter la bienvenue à Chris Risner [06:35]
image,

 

place au sujet du jour [08:15]On commence par les alertes qui s’affichent en bas du portail

image

et qui amènent au service de gestion des alertes que l’on retrouve dans la rubrique Management Services du portail:

image

On voit ensuite comment créer une nouvelle alerte, qui sont disponibles actuellement pour les machines virtuelles (support de toutes les métriques disponibles, CPU, mémoire etc.)
image,

Cloud Services (support de toutes les métriques disponibles également), Mobile Services et Web Sites (support des métriques de points de terminaisons (endpoints) comme les temps de réponse ou la disponibilité)
image

Dans l’exemple ci-dessous (sur machines virtuelles), on veut une alerte si le % CPU est > 20% en moyenne sur les 5 dernières minutes. Quand l’alerte a lieu, on peut l’envoyer par mail. Ici on l’envoie aux administrateur et co-administrateurs, ainsi qu’à une adresse qu’on entre à la main.
image

Aujourd’hui, si on veut envoyer l’alerte à plus d’une adresse e-mail spécifique, comme on ne peut saisir qu’une adresse e-mail dans le champ, on peut choisir une liste de distribution des équipes d’exploitation. On peut aussi bien sûr utiliser cela pour envoyer des SMS (ou du paging, mais cela est plutôt américain comme outil Winking smile) pour peu qu’on dispose d’une adresse tel que numéro-de-mobile@operateur.telecom.

Après avoir cliqué dans le portail sur une alerte, on voit le détail comem ci-dessous:
image

POn y voit la valeur mesurée et le seuil de déclenchement de l’alerte

Sur une auytre alerte qui a déjà été déclenchée, on voit l’historique de ces déclenchements:
image
Ici, cela fait depuis 10h10 du matin que l’alerte a été déclenchée. Elle est actibe depuis 1h29.

Dans un cas comme celui-ci, c’est une bonne occasion pour utiliser la fonctionnalité de mise à l’échelle automatisée (autoscale), qui peut se configurer dans cet exemple depuis le tableau de bord du cloud service.
image

Ici, c’est configurée avec des régles différentes suivant le moment auquel on se situe (sheduled autoscale):
image

Par exemple, on peut régler ce qui doit se passer entre 9h00 et 17h00 (ex: on veut plus d’instances le jour que la nuit).
image

et combiner cela avec des paramètres tels que la CPU qui vont permettre d’osciller entre 3 et 5 instances
image

Alors que la nuit on veut entre 1 et 2 instances
image

Ces autres paramètres sont également expliqués (ils sont assez intuitifs)
image

Le moteur d‘autoscale tourne toutes les 5 minutes. Il évaluent toutes les conditions du service. La première chose qu’il regarde est s’il y a déjà une action de mise à l’échelle en cours. Si oui, il ne va pas plus loin, de façon à laisser cette action se terminer.

 

Au delà de la CPU, on peut aussi dans Cloud Services effectuer une mise à l’échelle en fonction de la longueur d’une queue (du stockage Windows Azure, ou du Service Bus). On choisit la queue et le nombre de message que chaque instance du Worker Role peut gérer.
 image

D’autres métriques pourraient être ajoutées dans le futur, comme la mémoire.

 

Le moteur de mise à l’échelle automatisée récupère ses informations du même endroit que le graphique avec les différentes métriques.
image

Il s’agit de comptes de stockages internes qui stockent ces métriques pour chaque service. NB: L’utilisateur peut aussi ajouter des métriques dans un de ses propres comptes de stockage.

Le graphique présenté par autoscale permet de voir comment ce derrnier s’est comporté dans le passé (ici sur les derniers jours où on avait demandé à avoir une instance la nuit et 3 instances le jour):
image

Ici le même écran indique que le gain lié à l’utilisation d’autoscale est de 40% (vs 3 instances tout le temps).
image

de la même façon si l’autoscale est à OFF, on peut avoir le même type de message pour indiquer qu’on pourrait gagner 40% si l’était à ON.

On retrouve ce même type d’information dans l’écran ci-dessous/

image

Il est à noter que l’administrateur voir des montants en $ (ou €) alors que les co-administrateurs qui n’ont pas accès aux informations de facturation de l’abonnement voient des pourcentages.

 

La mise à l’échelle automatisée dans Web Sites ne peut se faire qu’en mode standard (pas en Free, ni Shared) puisque c’est le seul mode où vous avez vos propres machines.

Le fonctionnement sur la CPU est sur le même principe que ce qui a été vu plus haut. NB: le nombre d’instances est toujours prioritaire sur le % de CPU. Ainsi, dans l’exemple ci-dessous, si le nombre d’instances est à 5 et que la CPU est au delà de 80%, on restera quand même à 5 instances (la limite haute).
image

Comme la montée en charge est rapide sur Web Sites, elle se fait toutes les 5 minutes. Pour la descente, comme cela a des implications sur les utilisateurs, elle en s’applique que toutes les 2 heures.

Pour Mobile Services, l’autoscale est disponible en Standard et Premium (pas Free). On n’a pas de notion de CPU, mais d’unité qui donnent un nombre d’appels d’API.
image

Cela est évalué par jour. Si dans la journée on est à 90% du nombre d’appels d’API autorisé, on augmente d’une unité, et cela autant de fois que nécessaire dans la journée, dans la limite de la plage fixée (3 ci-dessus). Le lendemain, le nombre d’unités est remis à sa valeur basse (1 dans l’exemple ci-dessus).

NB: vous trouverez le détail sur la façon dont est facturé Mobile Services à http://www.windowsazure.com/en-us/pricing/details/mobile-services/

image

 

Pour les machines virtuelles, on supporte la montée en charge automatisée. Mais cette mise à l’échelle se gère toujours au niveau du cloud service (NB: une machine virtuelle est toujours rattachée à un cloud service qui lui fournit par exemple son xxx.cloudapp.net). La mise à l’échelle peut se faire sur des machines virtuelles qui sont non seulement dans le même cloud service, mais également dans le même availability set.

Si on a deux VM déployées et qu’on configure l’autoscale, on a quelque chose comme cela:
image

Dans cet exemple, on ne peut pas mettre la valeur haute de la plage à plus de 2 instances parce que seules deux VM sont déployées et qu’on n’a pas les moyens d’instancier comme dans un Web Role ou Worker Role de nouvelles VMs. Donc, la façon dont cela fonctionne est qu’on peut allumer ou éteindre automatiquement des VMs déjà déployées (NB: une VM déployée, mais en mode STOPPED (deallocated) ne génère pas de facturation de type heures de calcul (compute hours)).

Par exemple, après avoir ajouté une troisième VM dans l’availability set, on peut passer comme ci-dessous la plage jusqu’à 3 VMs.
image

 

On peut voir l’historique de ce que l’autoscale a fait dans les différents services comme vu plus haut, mais aussi de façon centralisée au niveau de Management Services / Operations Logs qui retrace globalement les actions d’exploitation qui ont été prises. Actuellement le journal d’exploitation ne prend pas en charge tous les services Windows Azure, mais on a déjà Cloud Services, Storage, Virtual Machines, plus toute action prise par Autoscale quelque soit le service.
image

Aujourd’hui l’autoscale est en preview et n’est disponible que dans le portail, pas encore sous forme d’API mais c’est prévu pour très bientôt. Cela permettra des choses supplémentaires que l’interface utilisateur du portail ne permettent pas comme une règle sur plusieurs métriques. On cherche à garder l’interface utilisateur simple et utilisable pour des utilisateurs qui découvrent, et les power users pourront utiliser les API pour faire des choses plus avancées.

image

Sur chaque ligne, on peut avoir le détail de ce qui a été fait. Pour certaines lignes, le CALLER n’est pas disponible. C’est comme cela qu’on reconnaît les actions prises par le service d’autoscale.

 

Smile

Benjamin (@benjguin)