ℹ️ À savoir · En bref
Autoscale allume et éteint les machines d'un groupe de mise à disposition selon une planification et la charge réelle. Dans un cloud, une machine éteinte (désallouée) ne coûte plus que son stockage : c'est le premier levier d'économie.
Il est désactivé par défaut sur un nouveau groupe de mise à disposition.
Objectifs de la fiche
- Comprendre comment Autoscale décide d'allumer ou d'éteindre.
- Régler planification, tampon et délais sans pénaliser les utilisateurs.
- Utiliser le drainage et les délais de session pour libérer les machines.
- Connaître les leviers de coût côté Azure.
La logique
| Notion | Définition |
|---|---|
| Planification | Nombre (ou pourcentage) de machines allumées par créneau horaire, par jour |
| Heures de pointe | Créneaux où un tampon plus large s'applique |
| Tampon de capacité | Capacité libre maintenue en plus de la charge : % de l'index de charge total (multisession) ou % des machines (mono-session) |
| Index de charge | 0 à 10 000 par machine multisession ; 10 000 = pleine (250 sessions par défaut si aucune règle de charge) |
| Délai d'arrêt | Temps avant d'éteindre une machine devenue inutile (30 min par défaut, 0 à 60) |
| Drainage | Machine en trop : plus de nouvelles sessions (sauf si plus rien d'autre), éteinte à 0 session |
💡 Astuce
Règle la stratégie de charge des serveurs (nombre maximal de sessions, CPU, mémoire) avant Autoscale : un index de charge réaliste rend le tampon fiable.
Selon le type de groupe
| Type | Ce qu'Autoscale pilote | À régler aussi |
|---|---|---|
| Multisession | Nombre de serveurs allumés selon l'index de charge et le tampon | Règles de charge, délais de session (déconnexion, inactivité) |
| Mono-session aléatoire | Machines libres disponibles (pool) | Arrêt après déconnexion / fermeture, tampon en % |
| Mono-session statique | Allumage aux heures de travail, arrêt ou suspension si non utilisée | Action si l'utilisateur ne se connecte pas après allumage |
Libérer les machines plus vite
- Délais de session dynamiques : des délais de déconnexion et d'inactivité plus courts s'appliquent aux machines en drainage, pour qu'elles se vident.
- Stratégies de limite de session : fermer les sessions déconnectées après un délai raisonnable (ex. 2 h) et prévenir les utilisateurs.
- Machines balisées pour le débordement (cloud burst) : allumées seulement quand les machines non balisées (par ex. sur site) sont pleines.
- Redémarrages planifiés en dehors des heures de pointe, coordonnés avec les mises à jour d'image (CTX-05).
PowerShell
# Activer Autoscale et régler un groupe (SDK Citrix)
Set-BrokerDesktopGroup -Name "DG-W25-Apps" -AutoscalingEnabled $true `
-PeakBufferSizePercent 15 -OffPeakBufferSizePercent 5 -PowerOffDelay 20
# Machines planifiées : lundi-vendredi, 8 h - 18 h en pointe
New-BrokerPowerTimeScheme -DesktopGroupUid (Get-BrokerDesktopGroup "DG-W25-Apps").Uid `
-Name "Semaine" -DaysOfWeek Weekdays `
-PeakHours (0..23 | ForEach-Object { $_ -ge 8 -and $_ -lt 18 }) `
-PoolSize (0..23 | ForEach-Object { if ($_ -ge 7 -and $_ -lt 19) { 4 } else { 1 } })
Leviers de coût dans Azure
| Levier | Effet |
|---|---|
| Désallocation | Une VM arrêtée par Citrix est désallouée : plus de facturation du calcul |
| Type de disque à l'arrêt | Passer le disque en HDD standard quand la VM est éteinte |
| Disque OS éphémère | Pas de disque géré à payer pour l'OS (non persistant, tailles compatibles) |
| Hibernation | Bureaux mono-session : économies hors usage avec reprise rapide |
| Réservations / plan d'économies | Pour le socle toujours allumé ; Autoscale pour la partie variable |
| Bonne taille de VM | Moins de grosses VM multisession plutôt que beaucoup de petites, selon la charge mesurée |
⚠️ Piège
Un tampon trop petit ou un démarrage trop tardif provoque des ouvertures de session lentes le matin (machines en cours de démarrage). Démarre le pool 30 à 60 min avant l'arrivée des utilisateurs et regarde la phase « Démarrage machine » dans Monitor.
Suivre et ajuster
- Autoscale insights (Monitor) : machines allumées vs utilisées, charge, alertes et économies estimées (à partir du coût horaire saisi).
- Ajuster chaque mois : pointe réelle, tampon, délai d'arrêt, sessions déconnectées qui bloquent l'arrêt.
- Comparer avec la facture du cloud (balises Azure par catalogue) pour vérifier les gains.
🔷 En contexte Citrix
Sur un parc multisession Azure, le trio gagnant : règles de charge réalistes, tampon de 10 à 20 % en pointe, délais de session dynamiques pour vider les serveurs le soir.
Pendant un Local Host Cache, aucune opération d'alimentation n'est possible (CTX-04) : garde un socle de machines allumées suffisant.
À retenir
- Autoscale = planification + charge + tampon ; désactivé par défaut.
- Index de charge 0-10 000 ; règles de charge à régler d'abord.
- Drainage puis arrêt après délai ; délais de session pour vider les machines.
- Azure : désallocation, disques, hibernation, réservations pour le socle.
- Autoscale insights pour mesurer et ajuster.
Auto-évaluation
Q1. Que signifie un index de charge de 10 000 ?
→ La machine multisession est pleine : elle n'accepte plus de nouvelles sessions.
Q2. Pourquoi une machine en drainage ne s'éteint-elle pas ?
→ Il reste des sessions (souvent déconnectées) : elle ne s'éteint qu'à 0 session. Délais de session dynamiques ou limites de déconnexion pour la vider.
Q3. À quoi servent les machines balisées dans Autoscale ?
→ Au débordement : elles ne sont allumées que lorsque les machines non balisées sont pleines (par ex. cloud en complément du sur site).
Q4. Les utilisateurs se plaignent de lenteurs à 8 h. Que vérifies-tu ?
→ La planification et le tampon du matin : les machines doivent être allumées avant l'arrivée ; phase « Démarrage machine » dans Monitor.