Directives relatives à l'intégration des applications

Avant de mettre une application à la disposition des utilisateurs finaux via WorkSpaces Applications, vérifiez que l'application fonctionne correctement dans l'environnement cloud WorkSpaces des applications, vérifiez que l'application peut être diffusée en continu sans générer d'artefacts et dimensionnez votre parc de manière appropriée en fonction du profil de ressources de l'application. Cette page fournit une liste de contrôle d'intégration structurée que vous pouvez suivre pour chaque application que vous prévoyez de diffuser. Si vous envisagez d'utiliser plusieurs sessions, vous devez porter une attention particulière à la possibilité d'exécuter plusieurs versions de l'application sur le même hôte. Si vous envisagez d'utiliser le mode application native, vous devez vérifier que l'application ne présente aucun problème de compatibilité avec ce mode.

Ces directives s'appliquent que vous intégriez une nouvelle application ou que vous migriez une application existante depuis un autre modèle de livraison.

Vue d'ensemble du processus d'intégration

L'intégration d'une application dans WorkSpaces Applications s'effectue selon deux étapes parallèles :

• Validation de la compatibilité des applications : vérifiez que l'application se comporte correctement dans l'environnement de streaming pour toutes les fonctionnalités sur lesquelles comptent vos utilisateurs.

• Dimensionnement des instances et planification des capacités : choisissez un type d'instance et une politique de dimensionnement du parc qui correspondent au profil du processeur, de la mémoire et du processeur graphique de l'application et au nombre d'utilisateurs simultanés que vous attendez.

Nous vous recommandons d'effectuer d'abord la validation de compatibilité (sur un Image Builder et un parc pilote), puis d'utiliser les mesures issues de cette validation pour prendre des décisions concernant le dimensionnement des instances.

Partie 1 : Validation de la compatibilité des applications

Compatibilité générale

WorkSpaces Les applications établissent une session de streaming dans cet ordre :

1. Le client de l'utilisateur se connecte à une instance de streaming.

2. L'utilisateur est connecté à la session du système d'exploitation du serveur sur l'instance.

3. L'application est lancée.

4. La session de streaming commence, date à laquelle les paramètres d'environnement qui dépendent du client (par exemple, la résolution d'affichage du client, le DPI, le fuseau horaire du client et les périphériques redirigés par le client tels que les imprimantes) sont appliqués.

Les paramètres d'environnement dépendant du client étant appliqués après le démarrage de l'application, une application qui ne lit ces valeurs qu'une seule fois au démarrage ne réagira pas à la configuration client réelle de l'utilisateur. Validez les éléments suivants :

• L'application lit ou s'abonne pour afficher les modifications de résolution, de résolution, de résolution et de fuseau horaire après le démarrage, ou vous configurez l'instance de streaming avec des valeurs par défaut correspondant à votre population d'utilisateurs avant que le client ne se connecte.

• L'application tolère que le fuseau horaire local de l'utilisateur soit différent de celui de l'instance de streaming.

• L'application n'échoue pas et ne se bloque pas lorsque le client se déconnecte et se reconnecte en cours de session.

Multi-session compatibilité

Si vous prévoyez d'exécuter l'application sur un parc multisession, validez les éléments suivants sur un Image Builder et un parc pilote comprenant au moins deux utilisateurs simultanés :

• La licence de l'application autorise des sessions multi-utilisateurs simultanées sur une seule instance de serveur. Les licences par appareil ou par utilisateur de certaines applications interdisent explicitement cette configuration.

• Les profils utilisateur, les paramètres des applications et les données utilisateur sont isolés entre les sessions. Vérifiez qu'une modification apportée par un utilisateur n'est pas visible pour un autre utilisateur simultané.

• User-specific les données sont écrites dans des emplacements par utilisateur tels que %APPDATA% et %LOCALAPPDATA% non dans des répertoires partagés tels que C:\Program Files ouC:\ProgramData.

• L'application ne repose pas sur des services système partagés entre toutes les sessions, ou ces services peuvent gérer correctement plusieurs sessions simultanées.

• L'application ne contient pas de chemins codés en dur supposant un environnement mono-utilisateur.

• Les boîtes de dialogue des périphériques système énumèrent uniquement les périphériques redirigés par l'utilisateur actuel, tels que les scanners et les imprimantes, et non tous les périphériques visibles par le serveur.

• Les boîtes de dialogue d'ouverture et d'enregistrement de fichiers résolvent correctement les lecteurs clients mappés et les dossiers redirigés pour l'utilisateur actuel.

• Le programme d'installation, le programme de mise à jour et les processus en arrière-plan de l'application ne nécessitent pas d'accès administrateur interactif lorsque les utilisateurs sont connectés.

Note

Multi-session les flottes ne prennent actuellement pas en charge la webcam, le cadre d'application dynamique et l'authentification par carte à puce. Si vous avez besoin de l'une de ces fonctionnalités, nous vous recommandons d'utiliser des flottes mono-session.

Compatibilité avec le mode application natif

Le mode application native diffuse chaque application distante sous forme de fenêtre distincte sur l'appareil local de l'utilisateur, avec sa propre icône dans la barre des tâches. Les applications qui fonctionnent correctement en mode classique peuvent se comporter différemment en mode application native, car la gestion des fenêtres, le focus et le rendu sont gérés différemment. Pour un aperçu de cette fonctionnalité, voir Mode d'application native.

Validez les éléments suivants en mode application native sur un Image Builder et un parc pilote :

• Affichage des fenêtres : toutes les fenêtres des applications, y compris les boîtes de dialogue, les écrans de démarrage et les instructions modales, s'affichent correctement et peuvent être utilisées avec elles. Portez une attention particulière aux fenêtres dessinées manuellement plutôt qu'à l'aide des boîtes à outils standard de l'interface utilisateur Windows (par exemple, les écrans de démarrage personnalisés ou les boîtes de dialogue de démarrage qui apparaissent avant la fenêtre principale). Ils sont plus susceptibles de présenter des problèmes de compatibilité.

• Fenêtres transparentes ou non rectangulaires : recherchez les fenêtres comportant des zones transparentes ou présentant des formes arrondies ou non rectangulaires (par exemple, des pointes de ballons, des infobulles personnalisées ou des fenêtres écorchées). Ils risquent de ne pas s'afficher correctement en mode application native.

• Barre d'état système : les applications qui nécessitent la zone de notification Windows (barre d'état système) ne sont actuellement pas prises en charge en mode application native. Si votre application utilise une icône de barre d'état uniquement pour les fonctionnalités secondaires, vérifiez que le flux de travail principal fonctionne toujours lorsque le plateau n'est pas disponible.

• Sensibilisation au DPI : les sessions de streaming peuvent s'exécuter à des résolutions et à des paramètres DPI différents de ceux du client local. Si ce n'est pas le cas de l'application DPI-aware, Windows redimensionne lui-même la sortie, ce qui entraîne un rendu flou. Effectuez un test sur au moins un client dont l'échelle DPI est différente de 100 % (par exemple, un ordinateur portable haute résolution à 125 % ou 150 %).

• Multi-window flux de travail : testez les flux de travail qui s'étendent sur plusieurs fenêtres d'application (par exemple, passer d'une fenêtre principale à une boîte de dialogue modale, ou entre deux documents ouverts dans des fenêtres distinctes). Vérifiez que les transitions de focus et le fait de cliquer pour activer la barre des tâches se comportent comme prévu.

• Comportement des touches Alt+Tab et de la barre des tâches : passez de l'application à d'autres applications locales en utilisant Alt+Tab et en cliquant sur l'icône de la barre des tâches. L'application distante doit apparaître au premier plan sans entraîner de fenêtres distantes indépendantes.

• Boîtes de dialogue modales : lorsqu'une boîte de dialogue modale est ouverte dans l'application distante, la fenêtre distante sous-jacente doit correctement indiquer qu'elle est désactivée, et le fait de cliquer dessus doit clignoter ou activer le modal.

• Flux de travail d'impression : imprimez depuis l'application et vérifiez que la boîte de dialogue d'impression est visible (et non masquée derrière la fenêtre principale) et que les imprimantes redirigées sont énumérées. Les boîtes de dialogue d'impression affichées par certains pilotes d'imprimante peuvent être associées à la mauvaise fenêtre. Si vous observez cela, pensez à utiliser l'imprimante PDF DCV au lieu de Microsoft Print to PDF.

• Ancrage des onglets du navigateur : lorsque les utilisateurs essaient d'ancrer ou de déconnecter des onglets d'une fenêtre de navigateur dans des fenêtres distinctes au cours d'une session de diffusion en mode application native, le navigateur de diffusion à distance ne fonctionne pas de la même manière qu'un navigateur local. Les utilisateurs doivent appuyer sur la touche Alt jusqu'à ce que les onglets soient ancrés dans des fenêtres de navigateur distinctes. Si vos utilisateurs ont tendance à déconnecter fréquemment les onglets, planifiez une formation adaptée à ce comportement.

• Changement de mode : vérifiez que l'application continue de fonctionner si l'utilisateur bascule entre le mode application native et le mode classique au cours d'une session.

Nous vous recommandons de démarrer la validation du mode application native avec un groupe d'utilisateurs pilote et de documenter toutes les limitations spécifiques à l'application avant le déploiement complet. Le comportement et les performances des applications peuvent varier d'un mode de streaming à l'autre. Les tests en mode classique ne remplacent donc pas les tests en mode application natif.

Gestion et redirection de fichiers

• Ouvrez et enregistrez des fichiers depuis et vers des lecteurs clients mappés et des dossiers redirigés.

• Si l'application utilise des fichiers temporaires, vérifiez qu'ils sont écrits dans des répertoires temporaires par utilisateur.

• Testez les opérations sur les fichiers volumineux via le mécanisme de transfert de fichiers de la session si vos utilisateurs travaillent avec des fichiers dont la taille est supérieure à la taille habituelle traitée par la session de streaming.

Impression

• Testez l'impression sur chaque type d'imprimante redirigée que vos utilisateurs utiliseront (imprimantes réseau, Microsoft Print to PDF, pilotes d'imprimante PDF tels que l'imprimante PDF DCV et imprimantes redirigées tierces).

• Testez l'impression à partir de chaque application dotée d'un flux de travail d'impression, y compris les applications intégrant du contenu Web (comme des Chromium-based vues).

• Validez le comportement du dialogue d'impression en mode application natif (voir la section précédente).

Interactions avec les appareils locaux

• Entrée et sortie audio (microphone, haut-parleurs et casques).

• Webcam, si elle est utilisée par l'application.

• Redirection du périphérique USB, si elle est utilisée par l'application. Consultez la section Redirection de périphériques USB pour obtenir la liste des appareils pris en charge.

• Authentification par carte à puce, si l'application l'exige.

Performances réseau

• Mesurez la réactivité des applications via une connexion réseau représentative de votre pire utilisateur (par exemple, un utilisateur distant connecté à une connexion haut débit grand public avec un temps aller-retour de 100 ms). Les sessions de streaming sont sensibles au temps d'aller-retour et à la perte de paquets.

• Vérifiez que l'application tolère les brèves interruptions du réseau et les reconnexions de session.

Multi-monitor soutien

• Testez des flux de travail qui s'étendent sur plusieurs moniteurs du côté client.

• Si l'application lit la géométrie du moniteur, vérifiez qu'elle lit la disposition du moniteur du client, et non celle de l'instance de streaming.

Fonctionnalités audio et vidéo

Real-time les scénarios audio-vidéo (voix, visioconférence et outils de collaboration intégrés à l'application) nécessitent des fréquences d'images plus élevées et peuvent nécessiter un type d'instance plus important. Consultez Partie 2 : Dimensionnement des instances et planification des capacités.

Environnement de validation

Effectuez les vérifications décrites dans cette section sur un Image Builder d'abord, puis sur un parc pilote composé d'un petit groupe d'utilisateurs représentatifs, avant de diffuser l'image à l'ensemble de votre base d'utilisateurs. Ne vous fiez pas aux tests en mode classique pour remplacer les tests en mode application native.

Partie 2 : Dimensionnement des instances et planification des capacités

Choisissez une famille d'instances

Sélectionnez une famille d'instances en fonction du profil de ressources de l'application. Pour les spécifications matérielles et les tarifs, voir Familles WorkSpaces d'instances d'WorkSpaces applications et tarification des applications.

Profil de l'application	Famille d'instances recommandée
Office, navigateurs Web, plupart des applications métiers	Usage général
Compute-bound applications (calculs lourds côté client, analyses locales)	Calcul optimisé
Memory-intensive applications (grands ensembles de données en mémoire, bases de données en mémoire)	Mémoire optimisée
Applications graphiques utilisant DirectX, OpenGL ou OpenCL	Famille de cartes graphiques G4dn, G5 ou G6
Real-time audio-vidéo pour les scénarios à haute fréquence d'images	Augmentez la taille de l'instance au sein de la famille que vous avez choisie ; envisagez une instance de la famille Graphics si l'application utilise également l'accélération GPU

Chaque instance WorkSpaces Applications possède un lecteur C de taille fixe de 200 Go qui est supprimé après chaque session utilisateur. Ne vous fiez pas au stockage local de l'instance pour les données utilisateur ; utilisez les dossiers de base, les partages de fichiers ou la gestion des profils à des fins de persistance.

Dimensionner une instance pour un seul utilisateur

Avant de procéder au dimensionnement pour les utilisateurs simultanés, mesurez l'utilisation des ressources de l'application pour une seule session :

• Provisionnez un Image Builder de la plus petite taille d'instance de la famille que vous avez choisie et qui répond aux exigences minimales définies par l'application.

• Connectez-vous en tant qu'utilisateur unique et exécutez la charge de travail du représentant de bout en bout. Incluez toutes les dépendances qui seront exécutées dans la session de streaming (par exemple, les clients de synchronisation en arrière-plan, les agents de sécurité et les clients de gestion de profil).

• Mesurez, à l'aide de Windows Performance Monitor ou d'un outil équivalent : utilisation maximale et soutenue du processeur, utilisation maximale et soutenue de la mémoire du poste de travail (octets privés), I/O débit du disque et, le cas échéant, utilisation du processeur graphique et de la mémoire vidéo.

• Si la capacité maximale du processeur dépasse environ 80 % ou si la mémoire maximale dépasse environ 75 % de la capacité de l'instance pendant les flux de travail normaux, passez à la taille d'instance suivante.

• Laissez de la place au système d'exploitation Windows Server, à l'agent WorkSpaces Applications, à Amazon DCV, à l'anti-malware et à tout autre agent de gestion. En règle générale, il est recommandé de réserver environ 1 vCPU et 1 Go de mémoire pour la surcharge du système de base sur une instance mono-session.

Taille pour les flottes multi-sessions

Multi-session les flottes exécutent simultanément plusieurs utilisateurs sur une seule instance Windows Server. Le nombre maximum d'utilisateurs pris en charge par instance dépend de la taille de l'instance et du profil de ressources de l'application.

• Commencez par votre mesure pour un utilisateur unique (voir la section précédente).

• Appliquez un multiplicateur de simultanéité en fonction du comportement de l'application. Pour les applications dont le profil de ressources est principalement inactives (par exemple, les applications bureautiques utilisées de manière interactive), prévoyez que l'utilisation globale du processeur et de la mémoire évolue de manière à peu près linéaire en fonction du nombre d'utilisateurs, mais avec une réduction de 20 à 30 % en raison de la surcharge du système d'exploitation partagé. Pour les applications dont le profil de ressources est toujours actif (par exemple, les outils de traitement des données ou les navigateurs exécutant des applications Web lourdes), prévoyez une mise à l'échelle presque linéaire sans réduction.

• Calculez le nombre maximum d'utilisateurs par instance d'un candidat comme suit :

max_users_per_instance = min(
    (instance_vcpus - 1) / peak_single_user_vcpus_under_concurrency,
    (instance_memory_gb - 1) / peak_single_user_memory_gb_under_concurrency
)

• Validez la valeur candidate dans un véritable projet pilote multi-sessions. Exécutez un test avec le nombre candidat d'utilisateurs simultanés (par exemple, avec un outil de génération de charge ou avec de véritables utilisateurs pilotes). Surveillez l'utilisation du processeur (objectif inférieur à 80 % en pic, moins de 70 % maintenu), la mémoire disponible (objectif supérieur à 15 % du total au pic), la longueur de la file d'attente sur le disque (objectif inférieur à 2 % maintenu) et la réactivité des sessions DCV (subjective, la session semble-t-elle interactive ?).

• Si le pilote échoue à l'une de ces cibles, réduisez le nombre maximum d'utilisateurs par instance d'un et recommencez le test. Si le pilote réussit bien, vous pouvez augmenter le nombre maximum d'utilisateurs par instance d'un et retester, ou laisser une marge de manœuvre pour faire face à des pics de charge de travail.

Configurer le dimensionnement de la flotte

Une fois que vous connaissez le nombre maximum d'utilisateurs par instance, configurez le dimensionnement du parc en fonction du nombre d'utilisateurs simultanés attendu au fil du temps. Voir Fleet Auto Scaling for WorkSpaces Applications pour en savoir plus sur les mécanismes. Cette section résume les décisions que vous devez prendre dans le cadre de l'intégration.

• Capacité minimale. Défini en fonction du plus faible nombre attendu d'utilisateurs simultanés pendant les heures ouvrables, divisé par le nombre d'utilisateurs par instance. Le provisionnement prend plusieurs minutes par instance, de sorte qu'une capacité minimale de zéro ou une valeur trop faible peuvent amener les utilisateurs à attendre le lancement d'une instance au début de la journée de travail. Pour des augmentations matinales prévisibles, utilisez une politique de dimensionnement planifiée pour augmenter la capacité minimale avant le début de la journée de travail et la diminuer avant la fin de la journée de travail.

• Capacité maximale. Définissez une limite supérieure qui tient compte du nombre maximal d'utilisateurs simultanés et d'une marge de sécurité. Le pic est généralement de 1,2 à 1,5 fois la moyenne pendant les heures ouvrables, mais mesurez votre propre trafic pour le définir avec précision.

• Utilisation cible. Pour les flottes dont la demande est imprévisible, utilisez une politique de dimensionnement du suivi des cibles. Choisissez un taux d'utilisation cible qui 100% - target utilization dépasse le taux de rotation des utilisateurs (churn) attendu dans un délai de 15 minutes. Par exemple, si 10 % des utilisateurs démarrent et terminent des sessions dans un intervalle de 15 minutes, définissez l'objectif à 90 % ou moins. Pour plus de détails, consultez la section Meilleures pratiques pour la conception de politiques à grande échelle dans le livre blanc.

• InsufficientCapacityError alarme. Créez une CloudWatch alarme Amazon sur la InsufficientCapacityError métrique de chaque flotte, afin que les administrateurs soient avertis lorsque le dimensionnement automatique ne peut pas répondre à la demande.

Valider de bout en bout avec un pilote

Avant de déployer une application pour tous les utilisateurs, lancez un projet pilote avec 10 à 50 utilisateurs pendant au moins une semaine ouvrable complète. Pendant le projet pilote :

• Vérifiez que les résultats de validation de la compatibilité des applications de la partie 1 sont valables pour les charges de travail réelles des utilisateurs.

• Vérifiez que la taille d'instance choisie prend en charge le pic d'utilisateurs simultanés observé par instance.

• Vérifiez que la politique de dimensionnement de la flotte gère la réduction en début de journée et en fin de journée sans qu'aucun événement ne se produise. InsufficientCapacityError

• Recueillez les commentaires des utilisateurs pilotes sur la réactivité des sessions et le comportement des applications.

Liste de contrôle pour l'intégration

Utilisez cette liste de contrôle pour suivre l'état de chaque candidature que vous êtes en train d'intégrer.

Compatibilité des applications

• La licence de l'application autorise le déploiement prévu (session unique ou multisession, utilisateurs simultanés).

• Les contrôles de compatibilité généraux sont réussis (les paramètres dépendant du client sont appliqués après le démarrage de l'application).

• Multi-session les contrôles de compatibilité sont réussis (si vous ciblez des flottes multisessions).

• Les contrôles du mode application natif sont réussis (fenêtres, boîtes de dialogue, barre d'état, DPI, mise au point, impression et changement de mode).

• Les contrôles de gestion et de redirection des fichiers sont réussis.

• Flux de travail d'impression validés pour tous les types d'imprimantes redirigées que les utilisateurs utiliseront.

• Interactions locales avec les appareils (audio, webcam, clé USB et carte à puce) validées pour tous les appareils que les utilisateurs utiliseront.

• Multi-monitor flux de travail validés.

Dimensionnement et capacité des instances

• Famille d'instances choisie en fonction du profil des ressources de l'application.

• Single-user utilisation des ressources mesurée sur un Image Builder.

• Nombre maximum d'utilisateurs par instance calculé et validé dans un pilote multi-sessions (le cas échéant).

• Politique de dimensionnement du parc configurée (capacité minimale, capacité maximale, utilisation cible ou dimensionnement planifié).

• InsufficientCapacityErroralarme configurée.

Projet pilote et déploiement

• Exécution du projet pilote avec 10 à 50 utilisateurs pendant au moins une semaine ouvrable.

• Les commentaires des pilotes ont été examinés et tous les problèmes de blocage ont été résolus.

• Application documentée pour la formation des utilisateurs finaux (y compris tous les comportements connus du mode application natif, tels que l'ancrage des onglets du navigateur via la touche Alt).

• Plan de déploiement convenu avec les parties prenantes.