Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Personnalisation de la flotte
Type de flotte
Lors de la création d'une flotte, les clients doivent choisir un type de flotte. Chaque type de flotte offre des avantages différents en termes d'expérience utilisateur, de coûts et de frais de maintenance. Quel que soit le type de parc choisi, chaque option prend en charge les types de plateformes Windows et Linux, ainsi que la vue Desktop ou la vue Application.
Les clients peuvent désormais choisir parmi les types de flotte suivants :
-
Always-On— Ce type de flotte permet aux utilisateurs d'accéder instantanément à leurs applications. Toutes les instances actives de votre flotte vous seront facturées, même si aucun utilisateur n'utilise d'applications de streaming.
-
On-Demand— Sélectionnez ce type de flotte pour optimiser vos coûts de streaming. Avec une flotte à la demande, les utilisateurs bénéficieront d'une heure de début de session d'environ une à deux minutes. Toutefois, les frais d'instance de streaming ne vous seront facturés que lorsque les utilisateurs sont connectés, ainsi qu'un petit tarif horaire pour chaque instance du parc qui n'est pas une application de streaming.
-
Elastic — Les flottes élastiques peuvent être utilisées pour des applications qui ne nécessitent pas d'installation et peuvent être exécutées à partir d'un disque dur virtuel (VHD). Les flottes élastiques ne prennent pas en charge WorkSpaces les images d'applications et ne nécessitent pas de politiques de dimensionnement. Vous n'êtes facturé que pour la durée d'une session de streaming.
Tableau 2 — Types de flottes Amazon WorkSpaces Applications
| Type de flotte | Quand l’utiliser | Expérience utilisateur | Modèle de tarification | Remarques |
|---|---|---|---|---|
|
Always-On |
Vos utilisateurs ont besoin d'un accès instantané aux applications lorsqu'ils démarrent une session. Vous n'aurez pas de capacité excédentaire significative dans votre flotte, peut-être parce que vos habitudes d'utilisation sont prévisibles et que vous pouvez contrôler les coûts de manière fiable grâce à des politiques de dimensionnement. |
Accès instantané aux applications |
Vous payez le plein tarif pour chaque instance disponible dans votre parc (qu'elle soit utilisée ou non pour une session). |
Prend en charge les politiques d'image et de mise à l'échelle personnalisées. |
|
On-Demand |
Vous devez conserver une capacité excédentaire significative dans vos flottes. Vous souhaitez bénéficier de l'environnement le plus rentable possible et ne voulez pas payer le prix fort pour la capacité inutilisée. Vos utilisateurs peuvent attendre une à deux minutes pour accéder à leurs applications après avoir démarré une session. Vous utilisez des types d'instances plus importants. Le coût horaire d'une instance en cours d'exécution est bien plus élevé que le coût de l'instance arrêtée. |
Les utilisateurs attendent une à deux minutes pour accéder à leurs applications après le démarrage d'une session. |
Vous payez le plein tarif uniquement pour les instances de streaming avec une session active, puis un petit coût horaire pour les instances inactives. |
Prend en charge les politiques d'image et de mise à l'échelle personnalisées. |
|
Elasticité |
La taille de votre application et de ses dépendances est inférieure à 1,5 Go environ. Chaque fois qu'un utilisateur démarre une session dans un parc Elastic, le fichier de votre disque dur virtuel (VHD) doit être téléchargé depuis Amazon S3 dans la session. Par conséquent, des fichiers VHD plus volumineux (c'est-à-dire d'une taille supérieure à 1,5 Go) nuiront à l'expérience utilisateur final. Votre application est portable. En d'autres termes, votre application et toutes ses dépendances peuvent être placées sur un disque dur virtuel et lancées à partir d'instances de streaming associées à un domaine VHD.You ne nécessitant pas (la jonction de domaine n'est actuellement pas disponible avec les flottes Elastic). Vous souhaitez payer uniquement pour les sessions actives (c'est-à-dire ne pas payer pour la capacité inutilisée de votre flotte). Vos utilisateurs peuvent attendre 45 secondes ou plus pour accéder à leurs applications après le démarrage d'une session. Vous voulez qu'AWS gère le dimensionnement pour vous (aucune politique de dimensionnement à gérer). |
L'utilisateur attend entre 45 secondes et 3 minutes pour accéder aux applications après le démarrage de la session (le temps d'attente dépend de la taille du disque dur virtuel). |
Vous n'êtes facturé que pour la durée d'une session de streaming. Comme il n'existe aucun concept d'instances inactives dans les flottes Elastic, vous n'avez aucun frais à payer pour les instances non utilisées. |
Ne prend pas en charge les images personnalisées (le client fournit un VHD avec les applications) ni les politiques de dimensionnement. Supports |
Types de flotte, cas d'utilisation et exigences
Dimensionnement de la flotte
Capacité minimale et mise à l'échelle planifiée
Lors du dimensionnement de votre parc d' WorkSpaces applications, plusieurs facteurs se répercutent directement sur l'expérience utilisateur et les coûts. La valeur saisie pour la capacité minimale garantit que le nombre d'instances d' WorkSpaces applications sera rarement inférieur à cette valeur. Après la fin d'une session d' WorkSpaces applications, si le nombre total d'instances d' WorkSpaces applications est inférieur à la valeur de capacité minimale, une nouvelle instance de flotte démarre. Comme toujours, il est important de se rappeler qu'une instance d' WorkSpaces applications correspond directement à une session utilisateur, ce qui influence directement la valeur de la capacité minimale.
La saisie d'une valeur pour la capacité minimale supérieure à la simultanéité prévue entraîne une augmentation des coûts, bien que l'expérience utilisateur n'en soit pas affectée. Une valeur trop faible entraîne de faibles coûts, mais a un impact sur l'expérience utilisateur lorsque le nombre total de demandes dépasse la capacité disponible. Les administrateurs remarqueront des erreurs de « capacité insuffisante » dans ce type de situation. Par exemple, attendre de PendingCapacity devenir AvailableCapacity est une utilisation inefficace du temps de l'utilisateur lorsque le nombre de connexions prévues en début de journée est une valeur constante prévisible.
Commencez par une capacité minimale adaptée aux heures creuses habituelles, puis utilisez une politique de dimensionnement planifié pour réinitialiser efficacement la capacité minimale avant le début de la journée de travail. N'oubliez pas de créer une autre politique de dimensionnement planifié pour ramener la capacité minimale aux heures creuses. Pour plus d'informations sur les politiques de dimensionnement et sur la manière de les mettre en œuvre, reportez-vous à la section Stratégies d'auto-scaling de la flotte de ce document.
Capacité maximale et quotas de service
La définition de la capacité maximale peut sembler arbitraire, mais lorsqu'elle est correctement prévue et définie, elle optimise la consommation et le coût totaux des ressources. Une valeur saisie supérieure au quota de service pour le parc d' WorkSpaces applications de votre parc d'applications Compte AWS peut sembler valide, mais lorsque des événements de dimensionnement automatique tentent de dimensionner les ressources au maximum de leur capacité, ils ne sont pas lancés, car la valeur de capacité maximale dépasse le quota de service disponible. Assurez-vous qu'une demande de quota de service est déposée pour la capacité maximale souhaitée afin de garantir que le dimensionnement automatique fonctionne comme prévu par votre organisation.
Le coût est un autre élément important à prendre en compte lors de la définition d'une valeur de capacité maximale. Pour plus d'informations, reportez-vous à la section Optimisation des coûts avec le choix du type de flotte de ce document.
