Accueil › Serveur d'impression › RemoteFX vGPU mis au pâturage alors que Microsoft RDP grandit – Bien choisir son serveur d impression
Serveur d'impression

RemoteFX vGPU mis au pâturage alors que Microsoft RDP grandit – Bien choisir son serveur d impression

Par Titanfall , le 14 août 2019 - 16 minutes de lecture

En mai 2018, Microsoft a publié un document sur les fonctionnalités qu'ils supprimaient ou qu'il était prévu de remplacer à partir de Windows Server, version 1803. Ce document contenait une liste intitulée "Des fonctionnalités que nous ne développons plus. " La description se lisait comme suit: «Nous ne développons plus activement ces fonctionnalités et pouvons les supprimer d'une future mise à jour. Certaines fonctionnalités ont été remplacées par d'autres, alors que d'autres sont maintenant disponibles à partir de différentes sources. ”

Caché dans cette liste de fonctionnalités à déconseiller était:

  • “RemoteFX vGPU: Nous développons de nouvelles options d'accélération graphique pour les environnements virtualisés. Vous pouvez également utiliser l'assignation de périphérique discret (DDA) comme alternative. ”

BrianMadden.com a couvert RemoteFX de sa naissance à son évolution ultérieure, et nous avons estimé qu'il était juste de couvrir ses années crépusculaires tout en prenant la chance de passer en revue une partie de l'histoire et de l'évolution du marché, ainsi qu'une technologie permettant de rendre ce jeune chose obsolète.

Avant de commencer, nous devons préciser que Microsoft «vGPU» est très différent de NVIDIA «vGPU», qui est apparu plus tard. C’est juste que Microsoft a commencé à utiliser le terme en premier. Le terme «RemoteFX» désigne un ensemble de technologies et de fonctionnalités, «vGPU» étant la fonctionnalité permettant à plusieurs utilisateurs de renvoyer (à l’origine, quelques commandes) DirectX vers des GPU. Ces commandes étaient principalement celles utilisées par le système d'exploitation pour décharger les demandes de calcul de protocole distant.

D'autre part, NVIDIA utilise «vGPU» pour signifier que les applications de plusieurs VM peuvent réellement utiliser une tranche d'un GPU, via la virtualisation, la VM «voyant» ce qu'elle considère être un GPU physique.

Pourquoi vGPU?

Let's set the scene. En 2010, lors de la sortie de vGPU RemoteFX, les GPU n’étaient pas généralisés dans les salles de serveurs. Comme Brian Madden l'a observé lorsque Microsoft a annoncé ce qu'il faisait avec la technologie Calista, "je veux dire, bien sûr, personne n'a de GPU sur ses serveurs aujourd'hui, mais c'est parce qu'il n'y a jamais eu de raison de le faire."

À l'époque, les GPU constituaient le domaine des jeux et des stations de travail pro-vis robustes exécutant des applications de CAO / CAE. Les quelques solutions virtualisées utilisées étaient généralement des clients d’ingénierie extrêmement haut de gamme, tels que Boeing exécutant un utilisateur par serveur / lame avec GPU sur passerelle, ainsi que des protocoles payants de qualité supérieure tels que HDX 3D Pro ou Teradici. Il n’y avait tout simplement pas de fonctionnalités de partage de GPU hyperviseur disponibles.

À l'époque, les seules options de GPU étaient le PCIe Passthrough, dans lequel une seule VM obtenait le contrôle complet d'un GPU complet, avec les pilotes de GPU installés dans la VM. Citrix XenServer a utilisé le terme «passerelle», tandis que VMware ESXi l’a appelé «vDGA». Microsoft et Hyper-V n’ont toutefois pas emboîté le pas avec sa propre version; Alors que Citrix et VMware avaient des clients locaux sur site qui réclamaient des postes de travail CAO virtualisés, Microsoft était toujours plus concentré sur les utilisateurs Windows grand public et sur le cloud, où les problèmes liés au passage du processeur graphique l'emportaient généralement sur les avantages.

Maintenant, le GPU passthrough pose quelques problèmes:

  • Pour VDI, un ordinateur virtuel sur un GPU physique en fait une option coûteuse.
  • Certaines fonctionnalités d’hyperviseur d’entreprise ne peuvent pas être implémentées; par exemple, migration de machine virtuelle (c'est-à-dire XenMotion ou vMotion); ainsi que des instantanés en direct (et donc la surveillance des administrateurs de sauvegarde et de l'hyperviseur).
  • Passthrough présente des vulnérabilités en matière de sécurité car il n’ya pas de couche d’hyperviseur pour protéger la machine virtuelle.

Pour Microsoft, je soupçonne que le bloqueur de clé à transmettre était la sécurité.

Entrez vGPU

RemoteFX vGPU était une bonne idée. Face aux exigences croissantes des OS et des protocoles en matière de CPU, pourquoi ne pas décharger une partie du travail sur un GPU partagé destiné aux ordinateurs de bureau grand public? RemoteFX vGPU n’était pas conçu pour accélérer des applications 3D très graphiques ni pour fournir des ordinateurs virtuels de poste de travail. Il s’agissait de tirer parti des GPU en toute sécurité pour offrir une évolutivité accrue des serveurs et améliorer les performances de protocole pour les postes de travail et applications de bureau ordinaires.

Sans options de partage de virtualisation de GPU disponibles, Microsoft a adopté une approche avant-gardiste pour tirer parti des avantages d'un GPU sans les problèmes de passerelle de GPU, même si cela était inférieur au potentiel matériel brut du GPU. Cela impliquait essentiellement l’ajout de technologies d’interception d’API: lors de l’appel de certaines API (principalement celles prenant en charge les contraintes graphiques du système d’exploitation et du protocole), au lieu de passer directement au pilote GPU natif, une couche logicielle prenait le relais et les convertissait en appels vers le GPU.

Cela signifie que les machines virtuelles RemoteFX vGPU n’avaient pas de processeur graphique directement visible par une application à utiliser, mais en dehors de quelques applications de CAO / 3D, la plupart des applications n’avaient pas besoin de GPU. Certes, la couche d'interception signifiait que les avantages d'un processeur graphique étaient réduits et qu'elle ne procurait pas d'avantages considérables en termes d'expérience par utilisateur dans la plupart des configurations, mais elle était hautement évolutive, sans restriction du nombre d'utilisateurs.

VMware a suivi un cours assez similaire avec ses technologies de partage de GPU basées sur l'interception de l'API vSGA (Virtual Shared Graphics Acceleration). Cependant, avec NVIDIA vGPU et AMD MxGPU maintenant disponibles, VMware a cessé de développer vSGA et il est rare de le voir dans les nouveaux déploiements.

L'évolution (et la fin de la route) pour RemoteFX vGPU

Cette diapositive (tirée d’une présentation dont je parlerai dans une minute) comprend une belle diapositive de présentation des technologies de GPU de Microsoft et de leur évolution:

remotefx vgpu

Microsoft est essentiellement arrivé au bout de la route avec ce qui peut être fait pour améliorer vGPU RemoteFX. Ils ont fait un travail raisonnable de correction pour Windows Server 2016 à un moment où ils n’avaient pas d’alternative viable, améliorant les performances et ajoutant OpenCL / OpenGL, de sorte que les applications appelant ces bibliothèques en tiraient un avantage. Avec Windows Server 2016, ils ont enfin ajouté le relais PCIe (en tant que DDA ou affectation directe de périphérique), alors qu'un nombre croissant d'utilisateurs VDI utilisaient des applications nécessitant l'affichage d'un GPU.

Mais, tel qu'il est, À l'époque, lorsque VMware utilisait vSGA et Microsoft, RemoteFX, cela avait du sens car il n'y avait tout simplement pas d'alternative. Mais à présent, avec les alternatives disponibles, insérer une couche logicielle supplémentaire dans une pile de déchargement matériel n’a plus de sens.

Les technologies d'interception d'API, en particulier autour des GPU, sont à la fois une mauvaise idée et un cauchemar en pratique.

Rachel Berry

Pourquoi RemoteFX a fait son temps?

  • Les technologies d'interception d'API sont à la traîne et demandent beaucoup d'efforts pour rester en place; au fur et à mesure de la sortie des nouveaux pilotes GPU et des nouvelles versions d'OpenCL / OpenGL / DirectX, vous devez constamment mettre à jour et tester votre couche de traduction, ce qui entraîne invariablement des bogues et des incompatibilités coûteuses en ressources et en assistance.
  • L'utilisation d'une couche logicielle pour exploiter le matériel provoque un impact significatif sur les performances.
  • Il existe maintenant de nombreuses alternatives pour le partage de GPU, telles que NVIDIA GRID vGPU et AMD MxGPU sur des hyperviseurs non Microsoft tels que KVM, ESXi et XenServer. RemoteFX et Hyper-V ne peuvent pas apporter de réponse compétitive à ces questions, il est donc temps de passer à quelque chose de nouveau.

Avec Windows 2019, même si RemoteFX vGPU sera disponible pour la mise à niveau d'utilisateurs existants, il ne le sera pas pour les nouvelles installations…. Alors quelles sont les alternatives?

Grand progrès dans les PDR de base

Et après? Eh bien, la déclaration de désapprobation de Microsoft elle-même (à laquelle j'ai fait référence au début de cet article) est un peu étrange. DDA (PCIe Passthrough) n’est pas vraiment une alternative à RemoteFX, car l’existence même de RemoteFX a été une tentative pour aller au-delà des limites et des coûts associés au passthrough. La déclaration plutôt mystérieuse «Nous développons de nouvelles options d’accélération graphique pour les environnements virtualisés» indique quelque chose de beaucoup plus intéressant, si vous déterminez où chercher des informations charnues.

À la fin de juin 2018, Microsoft a organisé «Windows Server Summit», un événement en ligne sur les mises à jour de Windows Server. Les enregistrements des émissions et des platines sont en ligne et rangés sous la piste hybride. Il existe un enregistrement d'une présentation d'Ivan Mladenov (responsable de programme, Microsoft) intitulée "Piste hybride: services de bureau à distance sur site et Azure". Un gros morceau est dédié au protocole RDP et à la désapprobation de RemoteFX, mais cette présentation révèle quelques modifications très importantes pour RDP qui pourraient étendre considérablement l'attrait de Microsoft.

Points clés à surveiller:

Un remplacement de RemoteFX vGPU

La présentation (regarder de 9h08 à 13h33 environ) mentionne une nouvelle fonctionnalité de Windows Server 2019: GPU-P (P pour le partitionnement).

La formulation autour de GPU-P indique que cette approche est probablement très similaire à l'approche de virtualisation des E / S à racine unique (SR-IOV) adoptée pour le partage de GPU par AMD MxGPU. Bien que ces technologies aient été plus lentes sur le marché que d’autres technologies de partage de GPU, l’attrait de la standardisation de SR-IOV et de son modèle de sécurité scruté ouvert en font un outil populaire, en particulier pour les utilisateurs de cloud computing à grande échelle et de ségrégation des locataires.

Il est intéressant de noter que les technologies de partage et de virtualisation des GPU ont été attribuées aux fabricants de GPU (NVIDIA GRID vGPU, AMD MxGPU, Intel GVT-g), alors qu’elles appartenaient aux fabricants de GPU. Microsoft et Hyper-V sont-ils en train de s'approprier la nomenclature technologique?

Pour Windows 2019, la présentation révèle que Microsoft espère proposer GPU-P comme alternative à RemoteFX, dont l'inclusion est en cours d'évaluation (c'est-à-dire que les installations propres de Server 2019 ne prendront pas en charge vGPU RemoteFX). Les utilisateurs souhaitant participer à des essais doivent contacter Microsoft via gpup-pilot@microsoft.com.

La présentation va plus loin, en indiquant qu’à un moment donné, GPU-P sera remplacé par GPU-PV (PV pour les systèmes para-virtualisés).). GPU-PV "correspondra étroitement à ce que RemoteFX fait aujourd'hui", mais c’est tous les détails dont nous disposons à ce stade.

remotefx vgpu VDI tech

Stratégie d'encodage hybride et efficacité de la bande passante

Une étiquette attachée depuis longtemps à RDP a été «assez bonne». De récentes améliorations ont été apportées à de nombreux utilisateurs. Elle était configurée pour une qualité d’image qui leur permettrait d’avoir une bonne expérience (si vous avez la bande passante), mais pas l’efficacité de la bande passante de les approches de codec multiples privilégiées par Citrix HDX ou Teradici.

une stratégie de codage hybride (c'est-à-dire différentes régions de l'écran codées par différents codeurs); ils appellent cela «des améliorations de la classification des régions»). La diapositive de présentation aurait tout aussi bien pu être une diapositive HDX ou Teradici, car elle détaillait les améliorations importantes apportées à la bande passante par une approche hybride.

remotefx vgpu encoding

Avec les protocoles matures haut de gamme (notamment Citrix HDX et Teradici) qui suivent une stratégie hybride (et maintenant aussi RDP), j'espère que nous verrons une meilleure prise en charge des fournisseurs de GPU, car de nombreuses solutions d'encodage d'API de fournisseurs de GPU sont limitées en plein écran codecs H.264 / AVC.

Nous avons également détaillé quelques fonctionnalités intéressantes d’efficacité de la bande passante autour de l’affichage adaptatif, qui dépendent de la bande passante, d’un sous-échantillonnage 4K et d’un support DPI élevé.

Prise en charge RDP pour plusieurs GPU (mGPU-E)

RemoteFX a pris en charge plusieurs GPU. RDP sur le serveur 2019 prendre en charge plusieurs GPU (mGPU-E). Dans EUC, les principaux hyperviseurs ont . Il existe trois principaux cas où les utilisateurs demandent plusieurs GPU par ordinateur virtuel:

  • Pour VDI avec quelques applications (généralement) spécialisées CAD / 3D / VFX véritablement conçues pour utiliser plusieurs GPU en parallèle. De plus en plus nombreuses mais historiquement des applications où le cloud et la virtualisation ont été lents.
  • Où l'utilisateur VDI veut simplement un GPU plus grand que celui disponible sur le marché et veut que plusieurs GPU ressemblent à un seul; Ceci est généralement demandé aux gros utilisateurs de grands ensembles de données avec des applications telles que la CAO haut de gamme, Pétrel ou SIG. Avec l'augmentation de la taille des GPU sur les cartes de centre de données, cette demande devient moins fréquente. Techniquement, ce serait une solution terriblement inefficace d'essayer de gérer le framebuffer entre plusieurs cartes. La solution consiste généralement à utiliser une carte Workstation avec un très gros framebuffer (bien que quelques fournisseurs de GPU hésitent à le considérer comme une option généralement moins chère que leurs offres de centre de traitement des données, mais les OEM qui expédient les cartes le prennent souvent en charge et vous trouverez de telles cartes. figurant sur les listes de compatibilité matérielle de l'hyperviseur).
  • Pour les cas d’utilisation XenApp RDSH haute densité où, avec 50 à 150 utilisateurs par machine virtuelle, il n’est tout simplement pas possible de trouver un GPU suffisamment grand pour offrir à tous les utilisateurs une quantité importante de GPU. Citrix a en fait cherché à implémenter cette fonctionnalité à titre expérimental pendant de nombreuses années, mais cette solution a été retirée après un certain nombre de problèmes et il est apparu qu'elle était utilisée avec beaucoup de succès par quelques clients (très méchants!) Non pris en charge dans la production, notamment dans le secteur nu. scénarios.

En dehors de VDI, l’utilisation de plusieurs GPU profite à un grand nombre d’applications CAE, de calcul et AI / ML.

Fonctionnalités d'entreprise: impression et redirection de la caméra

Au-delà du protocole graphique et des fonctionnalités du processeur graphique, l’enregistrement au sommet de Windows couvre également les fonctionnalités d’impression et de redirection de la caméra (utiles pour les produits de communication unifiés tels que Skype for Business) pour Server 2019. RDP et donc Hyper-V sur un territoire VDI encore plus traditionnel. Il y a également quelques améliorations de HTML5 et de client Web.

En résumé

Ensemble, ces fonctionnalités permettent à Azure de lancer un produit ou un service similaire au cloud Amazon AWS Elastic GPU. Plutôt que d'acheter DaaS avec un seul GPU fixe, les utilisateurs pourraient se décharger sur une base pay-as-you-use et éventuellement accéder à une capacité de GPU «illimitée».

Les améliorations RDP existantes signifient qu’il est déjà suffisamment bon et efficace pour que davantage d’utilisateurs de Citrix / VMware envisagent d’autres solutions. Et avec de nombreux concurrents de Citrix / VMware (tels que Workspot) utilisant RDP, nous risquons de voir les produits VDI traditionnels perdre des parts de marché. plusieurs fronts. Si les améliorations promises sont bien mises en œuvre, cela ne peut qu’accélérer et je pense que nous devrons cesser d’utiliser le langage «assez bon» pour décrire RDP, car il s’agit maintenant d’un protocole sérieusement mûr et adulte.

Avec Windows 2019, il semble que Hyper-V obtiendra enfin un large éventail de technologies GPU. De nombreuses entreprises utilisant Hyper-V pour la majorité de leurs ordinateurs virtuels ont ajouté un peu de XenServer ou ESXi car elles étaient les seules options disponibles pour NVIDIA vGPU ou AMD MxGPU pour VDI capables d'exécuter des applications de CAO / 3D. Particulièrement dans le domaine de l’éducation avec les programmes de licence de Microsoft, je me demande si VMware / Citrix aura la tâche de garder bon nombre de ses premiers clients GPU.

Le focus de Microsoft sur Azure signifie également qu’ils pensent au-delà du DaaS EUC traditionnel, de la VM unique à un GPU (ou d’une partie d’un GPU) que nous avons vue dans la VDI commence à sembler plutôt dépassé. Un modèle où le système d'exploitation, les protocoles et les applications peuvent tous se décharger et accéder à la demande au processeur et aux GPU semble beaucoup plus logique.

(Note de bas de page: il y a eu beaucoup de rumeurs autour du remplacement de RDSH par un Windows 10 multi-utilisateurs. Du point de vue du protocole, j'imagine que les développements ci-dessus seront sous le capot de tout ce qui finira par être utilisé par RDSH. Le meilleur endroit pour se tenir au courant de l’état de la spéculation, des rumeurs et des faits révélés à ce sujet est presque certainement cette chronologie et cette collection de références, rassemblées par Bas Van Kaam.)

Click to rate this post!
[Total: 0 Average: 0]

Articles relatifs:

Titanfall

Voir les publications de l'auteur

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.