Vous vous êtes déjà demandé ce qu'un scanner fait avec une station VDI ? Au départ, tout semble bien : il est reconnu comme un périphérique USB normal et est « transparent » depuis la machine virtuelle. Ensuite, l'utilisateur donne l'ordre de numérisation, et tout tombe à l'eau. Dans le meilleur des cas, c'est le pilote du scanner, dans le pire des cas, après quelques minutes, c'est le logiciel du scanner qui plante, et cela peut même affecter d'autres utilisateurs du cluster. Pourquoi ? Parce que, pour obtenir une image compressée de cinq mégaoctets, il faut envoyer via USB 2.0 deux à trois ordres de grandeur de données supplémentaires. La bande passante du bus est de 480 Mbit/s.
Il faut donc tester trois choses : l'UX, les périphériques et la sécurité - absolument. Il y a une différence dans la manière de tester. On peut installer des agents localement, sur chaque station de travail virtuelle. Cela reste relativement économique, mais cela ne montre pas la charge sur le canal et ne calcule pas très précisément la charge du processeur. La deuxième option consiste à se déployer ailleurs avec le nombre requis de robots émulateurs et à commencer à les connecter à des postes de travail réels comme de véritables utilisateurs. La charge due au protocole de transmission de flux vidéo (plus précisément, des pixels modifiés) viendra s'ajouter, ainsi que l'analyse et l'envoi de paquets réseau, ce qui permettra de comprendre les charges sur le canal. Le canal est en réalité très rarement vérifié.
L'UX, c’est la rapidité d'exécution des différentes actions par l'utilisateur final. Il existe des paquets de tests qui chargent l'installation avec des centaines d'utilisateurs et exécutent les actions typiques pour eux : lancer des suites bureautiques, lire des PDF, naviguer sur le web, regarder très rarement de la pornographie pendant les heures de travail, et ainsi de suite.
Un assez bon exemple de l'importance de ces tests à l'avance a eu lieu lors de la dernière installation. Là, mille utilisateurs passent à la VDI, ils ont un bureau, un navigateur et SAP. Le département informatique de l'entreprise est développé, il y a donc une culture de tests de charge avant les déploiements. À mon avis, il faut généralement convaincre le client de faire cela, car les coûts sont élevés et les bénéfices ne sont pas toujours évidents. Il existe des calculs où des erreurs peuvent se glisser ? En pratique, ces tests révèlent des points que l’on pensait identifiés, mais que l’on ne pouvait pas vérifier.
Installation
Six serveurs, la configuration est la suivante :
Nous n'avions pas accès au stockage de l'entreprise, il était déjà fourni sous forme d'espace en tant que service. Cependant, nous savons qu'il s'agit d'une solution tout flash. Quel type de tout flash exactement, nous ne le savons pas, mais il y a des partitions de 10 To. VDI — VMware, au choix du client, car l'équipe IT est déjà familiarisée avec cette technologie, et tout s'intègre assez harmonieusement dans une infrastructure cohérente. VMware a tendance à enfermer les utilisateurs dans son écosystème, mais si le budget d'achat est suffisant, on peut ne pas rencontrer de problèmes pendant des années. Mais c'est souvent un
Nous commençons les tests, car l'équipe IT ne déploie presque rien en production sans tests préalables. VDI n'est pas quelque chose que l'on peut lancer puis accepter. Les utilisateurs sont intégrés progressivement, et il est tout à fait possible de rencontrer des problèmes après six mois. Ce que, naturellement, personne ne souhaite.
450 utilisateurs en test, nous générons la charge localement. Les utilisateurs simulés effectuent différentes actions simultanément, nous mesurons le temps de chaque opération pendant plusieurs heures de travail :
Nous observons comment les serveurs et le stockage se comportent. VDI sera-t-il en mesure de créer le nombre nécessaire de postes de travail virtuels, etc. Étant donné que le client n'a pas opté pour l'hyperconvergence, mais a choisi un stockage flash, il était également nécessaire de vérifier la validité du dimensionnement.
En fait, si quelque chose ralentit quelque part, il faut ajuster les paramètres de la ferme VDI, notamment la répartition des ressources entre les utilisateurs de différentes catégories.
Périphériques
Il y a généralement trois situations concernant les périphériques :
- Le client dit simplement que nous ne connectons rien (à part les casques, qui généralement se connectent "en sortie de boîte"). Au cours des cinq dernières années, j'ai très rarement vu des casques qui ne s'étaient pas connectés d'eux-mêmes et qui n'avaient pas été pris en charge par VMware.
- La deuxième approche consiste à remplacer les périphériques dans le cadre du projet de déploiement VDI : nous utilisons des périphériques que nous avons testés et qui sont supportés par le client. C'est un cas, pour des raisons évidentes, assez rare.
- La troisième approche consiste à utiliser le matériel existant.
Vous êtes déjà au courant du problème avec les scanners : il est nécessaire d'installer un logiciel intermédiaire sur la station de travail (client léger), qui reçoit le flux USB, compresse l'image et l'envoie au VDI. En raison de certaines spécificités, cela n'est pas toujours possible : si tout fonctionne bien sur les clients Windows (ordinateurs personnels et clients légers), pour les distributions *nix, le fournisseur du VDI ne prend généralement en charge qu'une distribution spécifique, et cela devient compliqué, comme sur les clients Mac. À ma connaissance, peu de gens ont réussi à connecter des imprimantes locales à des installations Linux de manière à ce qu'elles fonctionnent sans incessants appels au support technique pendant la phase de débogage. Mais c'est déjà un progrès, car il y a quelque temps, il était même difficile de les faire fonctionner.
La visioconférence — tous les clients veulent tôt ou tard que cela fonctionne et que cela fonctionne bien. Si la ferme est correctement conçue, cela fonctionne bien, sinon nous nous retrouvons dans une situation où, pendant une audioconférence, la charge sur le canal augmente, de plus, il y a le problème de la mauvaise qualité d'image (pas en full HD, avec des visages de 9 à 16 pixels). Une forte latence supplémentaire se produit lorsqu'il y a une boucle entre le client, la station de travail VDI, le serveur de visioconférence, puis un deuxième VDI et un deuxième client. Il est préférable de se connecter directement du client au serveur de visioconférence, ce qui nécessite l'installation d'un composant supplémentaire.
Pour les clés USB, il n'y a pas de problème, les cartes intelligentes et similaires fonctionnent directement. Les difficultés se présentent avec les scanners de codes-barres, les imprimantes d'étiquettes, les machines (oui, cela s'est déjà produit) et les caisses. Mais tout peut être résolu. Avec des nuances et parfois des surprises, mais en fin de compte, cela se gère.
Lorsque l'utilisateur regarde YouTube depuis une station VDI, c'est la pire situation tant pour la charge que pour le canal. La plupart des solutions proposent un redirectionnement video HTML5. Un fichier compressé est envoyé au client, où il est affiché. Ou alors, un lien est fourni au client pour la connexion directe entre le navigateur et l'hébergeur vidéo (ce qui est moins fréquent).
Sécurité
La sécurité émerge généralement aux points de jonction des composants et sur les appareils des utilisateurs. Aux intersections d'un même écosystème, tout doit théoriquement bien fonctionner. En pratique, cela se passe dans 90 % des cas, et il y a toujours quelque chose à peaufiner. Ces dernières années, un autre achat de VMware s'est avéré très pratique : ils ont intégré l'MDM pour gérer les appareils au sein de l'entreprise. VMware a récemment introduit des équilibres de charge réseau intéressants (anciennement Avi Networks), qui permettent de résoudre la question de la distribution des flux un an après la livraison de VDI, par exemple. Une autre spécificité de VMware est une bonne optimisation des sites éloignés grâce à leur récente acquisition de VeloCloud, qui propose des SD-WAN pour les réseaux de succursales.
Du point de vue de l'utilisateur final, l'architecture et le fournisseur sont presque invisibles. L'important à l'échelle mondiale est qu'il existe un client pour tout appareil, qu'il s'agisse d'une tablette, d'un Mac ou d'un thin client Windows. Il y avait même des clients pour les téléviseurs, mais heureusement, ils ne sont plus disponibles maintenant.
Une caractéristique des installations VDI actuellement est que les utilisateurs finaux n'ont tout simplement pas d'ordinateurs à domicile. Il y a souvent une tablette Android peu performante (parfois même avec une souris ou un clavier), ou il se peut que l'on ait de la chance et que l'on obtienne un ordinateur sous Windows XP. Ce dernier, comme vous pouvez le deviner, n'a pas été mis à jour depuis un certain temps. Et il ne le sera jamais. Ou bien, il s'agit d'appareils très faibles où le client ne s'installe pas, les applications ne fonctionnent pas, et l'utilisateur ne peut pas travailler. Heureusement, même de très faibles dispositifs peuvent convenir (pas toujours confortablement, mais ils conviennent), et c'est considéré comme un grand avantage de VDI. En ce qui concerne la sécurité, il est nécessaire de tester la compromission des systèmes clients. Cela arrive assez souvent.
À la lumière des recommandations de Rospotrebnadzor concernant l'organisation du travail dans les entreprises en période de risque COVID-19, se connecter à ses postes de travail au bureau est très pertinent. Il semble que cette situation soit là pour durer, et oui, si vous envisagez VDI, vous pouvez commencer à tester. Cela sera utile. Les recommandations sont disponibles , des clarifications . Il est important de noter qu'avec VDI, il est également possible de réorganiser les espaces pour respecter les exigences. Le régulateur impose certaines normes de distanciation. Par exemple, dans un bureau de 50 m², il ne peut pas y avoir plus de cinq employés.
Si vous avez des questions concernant le VDI qui ne sont pas destinées aux commentaires, voici mon e-mail : SSkryl@croc.ru.
Source : habr.com
