1. Introduction
Selon les dernières statistiques d'ARM, les expéditions cumulées des partenaires de puces ARM ont atteint environ 240 milliards de puces d'ici 2022. En raison des capacités riches des puces ARM, telles qu'une consommation d'énergie réduite, un faible coût et une conception extensible, qui ont été utilisées dans divers domaines (par exemple, décodeurs, téléphones intelligents, ordinateurs et serveurs). Pour le domaine des serveurs, en utilisant des technologies de virtualisation, les puces ARM ont été utilisées pour créer divers services cloud, notamment la téléphonie mobile cloud, les jeux cloud et l'ordinateur cloud. Associé à celui-ci, le cloud ARM implique des technologies de virtualisation du CPU, de la mémoire, du GPU, du réseau et du stockage.
Principalement, le processeur, la mémoire et les E/S pourraient être virtualisés en utilisant un hyperviseur (également appelé moniteur de machine virtuelle, VMM) [1] ou un middleware de conteneur [2]-[4] : (1) Pour le modèle d'hyperviseur, les appareils essentiels, y compris le processeur , mémoire, IO, interruption, horloge, etc. doivent avoir des fonctionnalités de virtualisation matérielle essentielles [5], qui pourraient contribuer à la réalisation des fonctions d'hyperviseur. Une réalisation typique est basée sur un modèle ARM/KVM, prenant comme exemples les puces de serveur Phytium (par exemple, FT-2000+/64) pour illustrer [6], dont les principales fonctionnalités de virtualisation sont réalisées à l'aide des capacités de virtualisation matérielle correspondantes, telles que en tant que CPU fournissant un environnement d'exécution séparé EL2 pour l'hyperviseur, et une mémoire gérée par une MMU prenant en charge les transformations de table de pages à deux niveaux, et une intégration d'E/S avec un IOMMU pour prendre en charge l'allocation de périphérique et l'accès direct. En outre, sur la plate-forme de serveur FT-2000+/64 configurée avec des doubles cœurs, les statistiques de référence montrent que les taux de perte moyens de calcul du processeur et d'accès à la mémoire sont tous deux d'environ 3 %. De plus, certains chercheurs ont mené des recherches sur la virtualisation ARM/KVM sur la plateforme ARM-v8 (Firefly-RK3399). Huang et coll. [7] se concentrent sur le déploiement d'un système d'exploitation invité via le mécanisme de compilation croisée UEFI et sur la réalisation d'un affichage sur double écran en modifiant les codes du dispositif d'affichage QEMU. Les résultats montrent que les performances des utilisateurs ne sont pas bonnes, en raison de la contrainte d'un matériel peu performant. Ma [8] souligne que la solution ARM/KVM est meilleure que Docker en termes d'intégrité fonctionnelle et de copie de fichiers. (2) Pour le modèle de conteneur, divers produits permettant de conteneuriser les invités Linux ou Android sont dérivés. Pour fournir des conteneurs Linux, il existe des conteneurs LXC, Docker, LXD, Kata, Linux VServer, Singularity, Rkt, gVisor. Dans ce cadre, LXC, Docker et LXD prennent en charge de bonnes fonctionnalités de stockage, les conteneurs Kata ont de bonnes fonctionnalités d'isolation [9]. Les comparaisons entre LXC, Docker et LXD, comme indiqué dans le tableau 1.
Pour proposer des conteneurs Android, qui peuvent fournir une variété de services SaaS (par exemple, téléphonie mobile cloud, jeux cloud, tests cloud). Les solutions typiques sont : Ubuntu Touch [11] est un système d'exploitation mobile publié par Canonical et conçu pour les appareils mobiles Touch tels que les smartphones et les tablettes, et ses conteneurs Android (instanciés en utilisant la technologie LXC) fonctionnent sur Ubuntu. Anbox [12], [13] résume l'accès matériel et intègre les services système de base dans un système GNU/Linux, qui utilise les technologies Linux (par exemple, USER, PID, UTS, NET) pour séparer le système d'exploitation Android de l'hôte ; de plus, une solution dérivée nommée xDroid d'Anbox est née. Huawei a lancé une solution de téléphonie mobile basée sur le cloud nommée Monbox [14], qui propose des tests de simulation, des promotions d'essai, des jeux dans le cloud et un bureau mobile. Tencent propose un mobile Android basé sur le cloud nommé VMI (Virtual Mobile Infrastructure), composé d'un serveur (y compris des conteneurs Android et des démons dockdroid correspondants) et d'un client. Le projet Condroid [15]-[17] est lancé par Arclab, Université du Zhejiang, qui utilise les outils LXC pour conteneuriser les invités Android sur un système d'exploitation hôte Android, et des supports périphériques sont implémentés. Inspirée de Condroid, une solution nommée Clondroid [18] est développée par ITRI, Taiwan. Comparaisons des fonctionnalités clés entre l'hyperviseur et le conteneur, comme indiqué dans le tableau 2.
Deuxièmement, avec l’augmentation spectaculaire des applications graphiques, les ressources GPU sont également indispensables. Pour la virtualisation GPU, les technologies de GPU virtuel (vGPU) ou de pass-through GPU ou d'API à distance sont généralement exploitées. Huawei Monbox fournit des ressources GPU en utilisant la technologie pass-through [14], et le pilote GPU correspondant doit être transplanté dans le système d'exploitation Android, le cadre de rendu Android doit donc être adapté. Le ReDroid (Remote-anDroid) [23] fournit un conteneur Android avec une fonction d'accélération GPU, qui utilise la bibliothèque graphique mesa3D pour réaliser l'accélération GPU. Certains fabricants de jeux utilisent les serveurs Ampere et la technologie vGPU de Nvidia pour créer des solutions de jeux en cloud.
De plus, NV (Network Virtualization), NFV (Network Function Virtualization) et SDN (Software Defined Networking) pourraient être exploités pour construire un environnement de réseau virtuel ; LVM (Logical Volume Manager) et le cloud du système de stockage distribué (par exemple, Ceph, GlusterFS) doivent être utilisés pour fournir des pools de ressources de stockage ; Basé sur NFV et SDN, la propriété du service de sécurité « Encapsuler plusieurs dispositifs de sécurité en un seul » peut être réalisée.
De plus, la gestion des quotas pour les ressources virtualisées est un élément indispensable : après l'initialisation d'une appliance virtuelle (par exemple, une VM ou un conteneur), si son quota de ressources n'est pas défini ou si trop de ressources sont configurées, le serveur sera surchargé. À l’inverse, si trop peu de ressources sont allouées, des ressources seront gaspillées et la qualité de service du conteneur en sera affectée. La simple définition de la limite supérieure du quota de ressources rend difficile l'utilisation complète des ressources du serveur (par exemple, le système de quota OpenStack, qui fixe des limites sur les ressources telles que la quantité de CPU qu'un projet peut utiliser).
Enfin, la transmission à distance est un élément essentiel de la fourniture de services dans les environnements cloud. Contrairement au scénario traditionnel de simple contrôle à distance présenté dans le tableau 3, avec le développement rapide des technologies de réseau (par exemple, 5G, réseau à fibre optique) et de divers types de services cloud, les utilisateurs sont aujourd'hui préoccupés par deux indicateurs : la qualité de l'image. [24] et temporisation. Selon les statistiques, le délai d'accès de bout en bout de la solution Huawei Monbox est d'environ 100 ms. Tencent VMI transfère les images d'affichage au client utilisateur à une fréquence d'images spécifiée. (Les représentants typiques des protocoles de transmission commerciaux sur la plate-forme x86 sont Citrix ICA, VMWare PCoIP, Microsoft RDP, RemoteFX, HP RGS, NoMachine NX, Huawei HDP, etc.)
Dans l'ensemble, les efforts de recherche existants se concentrent davantage sur un segment spécifique de la création du cloud ARM (par exemple, le modèle d'hyperviseur ARM ou l'utilisation d'Android comme système d'exploitation hôte), et il existe moins d'informations détaillées et d'expériences publiques sur la création d'une solution complète. Afin de fournir des références pour la construction d'un cloud basé sur ARM, les techniques et solutions correspondantes sont étudiées, comparées et réalisées dans Sect. 1, qui contient des indicateurs sur les aspects technologiques et économiques. Insecte. 2, le cadre cloud ARM est défini formellement et les solutions ou produits typiques sont résumés. Insecte. 3, une plate-forme cloud spécifique basée sur ARM est implémentée en utilisant des technologies de conteneur, de pass-through GPU et d'API à distance, ainsi que de transmission à distance. Les expériences et discussions sont données dans la Sect. 4. Le résumé et les perspectives de recherche de cet article sont discutés dans la Sect. 5.
2. Définition formelle du cadre de virtualisation
2.1 Définition
Dans le but de fournir une description conceptuelle et concise des systèmes ou solutions de virtualisation existants, et de proposer des composants essentiels du système (pour le moment, il n'y a pas de discussion sur les états détaillés et les transitions des divers éléments du système), un cadre de virtualisation a été formellement conçu et défini.
Le cadre labellisé \(F\) est défini formellement comme un quatre-uplet : \(F=(\textit{Hardware}, \textit{HostOS}, \textit{Middleware}, \textit{GuestOS})\),
- \(\textit{Hardware}\): un type spécifique de plateforme matérielle (incluant x86 et ARM), \(\textit{Hardware}=\left\{hw_{x86},hw_{ARM}\right\}\).
- \(\textit{HostOS}\): un type d'OS de l'OS hôte (notamment Linux, Android, Windows, MacOS), \(\textit{HostOS}=\left\{\mathit{hos}_{\textit{Linux}},\mathit{hos}_{\textit{Android}}, \mathit{hos}_{\textit{Windows}},\mathit{hos}_{\textit{MacOS}}\right\}\).
- \(\textit{Middleware}\): un modèle de virtualisation (comprenant un modèle d'hyperviseur tel que Xen, KVM, VirtualBox etc., et un modèle de conteneur tel que LXC, LXD, Docker etc.), \(\textit{Middleware}=\{\textit{Hypervisor},\textit{Container}\}\), \(\textit{Hypervisor}=\{h_{\mathit{Xen}}, h_{\mathit{KVM}}, h_{\textit{VirtualBox}}, h_{\textit{Commercial}}\}\), \(\textit{Container}=\{c_{\mathit{LXC}}\), \(c_{\mathit{LXD}}\), \(c_{\textit{Docker}}\), \(c_{\textit{commercial}}\}\), \(h_{\textit{commercial}}\) et \(c_{\textit{commercial}}\) représentent des produits exclusifs de \(\textit{Hypervisor}\) et \(\textit{Container}\) respectivement.
- \(\textit{GuestOS}\): un type d'OS de l'OS invité (notamment Linux, Android et Windows), \(\textit{GuestOS}=\left\{\mathit{gos}_{\textit{Linux}}, \mathit{gos}_{\textit{Android}}, \mathit{gos}_{\textit{Windows}}\right\}\).
- Tout élément dans \(F\) peut être attribué comme \(\mathit{NULL}\), ce qui signifie que cet élément n'est pas assemblé (par exemple, produits partiels sans utiliser de technologies de virtualisation, qui utilisent des clusters ARM physiques).
- Pour un serveur physique spécifié \(i\), qui satisfaisait aux contraintes spécifiques suivantes :
(une) \(hw_{i}\in \textit{Hardware}\), \(\mathit{hos}_i\in\textit{HostOS}\) et \(\left(\mathit{hos}_{x86}\right)_i\neq \left(\mathit{hos}_{ARM}\right)_i\).
(B) \(\textit{Middleware}_i=\left\{h_i,c_i\right\}\), \(h_i\in\textit{Hypervisor}\), \(c_i\in \textit{Container}\). Si \(h_i\neq \mathit{NULL}\) et \(c_i\neq \mathit{NULL}\), puis \(\exists \left(h_i\wedge c_i\right) \neq \mathit{NULL}\), ce qui signifie qu'il existe des technologies de virtualisation d'hyperviseur et des technologies de conteneurs compatibles. Par exemple, dans un environnement hôte doté de la technologie de virtualisation KVM, la technologie de conteneur LXC ou LXD ou Docker peut continuer à être déployée.
Selon les définitions ci-dessus et les contraintes spécifiques, les caractéristiques suivantes de \(F\) pourrait être obtenu.
(1) En employant la contrainte (a), les serveurs dotés d'architectures de processeur différentes peuvent raisonnablement installer des systèmes d'exploitation hôtes adaptés à leur propre matériel (x86 ou ARM), de manière à réaliser la gestion de base et la planification des ressources du matériel sous-jacent.
(2) En employant la contrainte (b), la compatibilité des différentes technologies de virtualisation peut être garantie, améliorant ainsi la diversité et la flexibilité de la mise en commun des ressources du serveur.
(3) En fournissant différents systèmes invités, divers besoins commerciaux peuvent être satisfaits. De plus, lorsque des machines virtuelles ou des conteneurs sont instanciés, les exigences d'isolation entre eux pourraient être satisfaites en employant le mécanisme de contrôle d'accès aux communications [19].
2.2 ARM VMM et cadre de conteneurs
D'après ci-dessus \(F\) définition et la réalisation typique de l'hyperviseur ARM est \(\mathit{ARM/KVM}\), quel cadre \(F_{\mathit{ARM/KVM}}=(\mathit{hw}_{\mathit{ARM}}\), \(\{\mathit{hos}_{\textit{Linux}}\), \(\mathit{hos}_{\textit{Android}}\}\), \(h_{\mathit{KVM}}\), \(\{\mathit{gos}_{\textit{Linux}}\), \(\mathit{gos}_{\textit{Android}}\})\). La réalisation typique d'ARM/KVM, comme le montre la figure 1.
De plus, pour offrir des services de conteneurs (par exemple, conteneur Linux, conteneur Android), le cadre est \(F=(\mathit{hw}_{\mathit{ARM}}\), \(\{\mathit{hos}_{\textit{Linux}}\), \(\mathit{hos}_{\textit{Android}}\}\), \(\textit{Container}\), \(\{\mathit{gos}_{\textit{Linux}}\), \(\mathit{gos}_{\textit{Android}}\})\). Quand \(\textit{GuestOS}=\mathit{gos}_{\textit{Android}}\), \(F\) peut offrir un téléphone mobile cloud, un service de jeu cloud, etc.
Actuellement, des produits représentatifs partiels ou des solutions (open source) de l'hyperviseur, du conteneur et de la ferme Android, comme indiqué dans le tableau 4, qui montre les éléments essentiels de chaque cadre de réalisation et les fonctionnalités importantes.
3. Un framework Android conteneurisé
Pour discuter du processus de construction et des technologies clés du cloud ARM, conformément au tableau 1 et à la compatibilité avec les principales normes de virtualisation, un cadre cloud ARM pour les jeux et les tests Android dans le cloud est construit, comme le montre la figure 2. Le modèle de conteneur basé sur ARM est le meilleur choix avec le plus grand potentiel et Docker est choisi ; et le système d'exploitation Ubuntu Linux peut être bien compatible avec les normes de virtualisation traditionnelles en tant que système d'exploitation hôte, ce qui présente l'avantage d'intégrer facilement des outils de gestion unifiés (par exemple, K8S) ; et les défis tels que la virtualisation de Binder (qui est un mécanisme de communication inter-processus fourni par le système Android), l'isolation de Binder et la virtualisation d'affichage sont éliminés de manière inhérente.
Le cadre proposé se compose d'un cloud ARM et de terminaux qui communiquent entre eux via un sous-système de transmission à distance. Le cloud utilise quatre couches hiérarchiques : une couche matérielle, une couche noyau, une couche middleware et une couche conteneur. La couche physique fournit des ressources de CPU physique, de mémoire, de stockage, de réseau et de GPU. Ensuite, un noyau Linux et un middleware sont construits dessus pour conteneuriser les instances Android. En outre, un agent et un client sont respectivement déployés dans un conteneur Android et un terminal, qui sont responsables de la transmission mutuelle de l'image de l'écran, des données audio et des événements d'entrée (par exemple, pression sur le clavier, toucher de l'écran).
Dans l'ensemble, le framework cloud ARM peut être divisé en trois parties clés à mettre en œuvre : (1) Sous-système de conteneur Android : sur le serveur ARM, Ubuntu et Docker sont utilisés pour créer un environnement de conteneur de base. Ensuite, un algorithme adapté à l'ajustement dynamique des ressources partielles du conteneur est implémenté et intégré dans un middleware de virtualisation. (2) Sous-système de partage GPU : les principes, avantages et inconvénients des deux méthodes (API remoting et GPU pass-through) sont discutés et implémentés dans l'environnement de test. (3) Sous-système de transmission à distance : en prenant un terminal Android comme exemple, un sous-système de transmission à distance composé d'un client et d'un serveur est implémenté. Dans le même temps, les raisons et les avantages de la mise en œuvre du serveur et du client à différents niveaux du système Android sont analysés.
Le cadre de réalisation est formellement décrit comme : \(F=(\mathit{hw}_{ARM}, \mathit{hos}_{\textit{Linux} (\textit{Ubuntu})}, c_{\textit{Docker}}, \mathit{gos}_{\textit{Android}})\).
3.1 Sous-système de conteneur Android
En plus de la gestion habituelle du cycle de vie des conteneurs (par exemple, créer, exécuter, mettre en pause, supprimer) et de la gestion des images en utilisant Docker, pour une utilisation plus efficace des ressources du serveur, un mécanisme d'allocation dynamique des ressources a été conçu.
Le mécanisme contient trois modules : (1) Module de surveillance des ressources : un outil statistique basé sur Telegraf, InluxDB et Grafana, qui est chargé de collecter régulièrement la charge d'exécution du système hôte et des conteneurs ; (2) Module de quota de ressources : il est responsable du calcul des exigences de quota de ressources du conteneur et de la génération de politiques de quota de ressources ; (3) Module de définition de quotas : il est responsable de la mise en œuvre et de l'exécution des politiques.
Les trois modules ci-dessus sont réalisés et déployés dans la couche middleware de la figure 2, ce qui présente les avantages d'une fiabilité et d'une sécurité élevées du modèle de surveillance externe. Lors de l'obtention des informations de charge de ressources spécifiques, Telegraf peut obtenir les informations de charge correspondantes du serveur hôte en utilisant divers plug-ins (par exemple, CPU, réseau, disque) ; Avec le plug-in Docker (par exemple, appelez 'statistiques de docker' API pour récupérer l'utilisation des ressources du conteneur, notamment le processeur, la mémoire, les E/S réseau, etc.), nous pouvons obtenir les informations de charge du conteneur Docker. Ensuite, les données sont stockées dans InluxDB et visualisées à l'aide de Grafana.
L'algorithme d'ajustement des ressources est décrit comme l'algorithme 1 et les notations utilisées comme suit :
- \(C_{\textit{Total}}\): tous les conteneurs (\(ci\)) exécuté sur un serveur ARM, \(C_{\textit{Total}}=\left\{c1,\ldots ,ci,\ldots ,cn\right\}\).
- \(p_{ci}\): une politique de quota de ressources du conteneur \(c_{i}\), qui est un double-uplet : \(p_{ci}=(cr_{\textit{MiniReq}},cr_{\textit{Capping}})_{ci}\). Les deux éléments représentent des indices de ressources minimales requises et de plafonnement des quotas de ressources pour \(c_{i}\) respectivement.
- \(P_{\textit{Total}}\): un ensemble de politiques de quota de ressources de \(C_{\textit{Total}}\), \(P_{\textit{Total}}=\{p_{c1},\ldots ,p_{ci},\ldots ,p_{cn}\}= \{\ldots,(cr_{\textit{MiniReq}},cr_{\textit{Capping}})_{ci},\ldots \}\).
- \(\mathit{THR}_{\mathit{Idle}}\): un coefficient de détermination, qui permet de déterminer si la ressource restante d'un serveur est suffisante. Selon l'expérience de l'industrie, \(\mathit{THR}_{\mathit{Idle}}\) est défini sur 0.5.
- \(\mathit{THR}_{\textit{Efficient}}\): un coefficient de ressource effectif. D'après l'expérience, \(\mathit{THR}_{\textit{Efficient}}\) est défini sur 0.9.
- \(\mathit{PR}_{\textit{Capping}}\): un plafonnement des ressources d'un serveur, \(\mathit{PR}_{\textit{Capping}}=(\mathit{PR}_{\textit{Physical}}\times \mathit{THR}_{\textit{Efficient}})\) et \(\mathit{PR}_{\textit{Physical}}\) représente les ressources d'un serveur (y compris le processeur, la mémoire, le réseau et les disques).
- \(T_{\textit{Interval}}\): un cycle de collecte d'intervalles du module de surveillance des ressources, \(T_{\textit{Interval}}\) est réglé sur 10 secondes.
- \(\mathit{CR}_{\textit{ConUsage}}\): selon \(T_{\textit{Interval}}\), un ensemble d'utilisation des ressources des conteneurs dans \(C_{\textit{Total}}\) sont collectés et notés comme \(\mathit{CR}_{\textit{ConUsage}}=\{\mathit{res}_{c1},\ldots,\mathit{res}_{ci},\ldots, \mathit{res}_{cn}\}_{{T_{\textit{Inverval}}}}\).
- \(\mathit{CRS}_{{T_{\textit{Interval}}}}\): selon \(T_{\textit{Interval}}\), \(C_{\textit{Total}}\) la charge des ressources pourrait être notée comme \(\mathit{CRS}_{T_{\textit{Interval}}}=(\sum_{i=1}^n \mathit{res}_{ci})_{T_{\textit{Interval}}}\).
- Le conteneur \(ck\) sans fixer de valeur de plafonnement des ressources, autrement dit, \((p_{ck}\otimes cr_{\textit{Capping}})=\mathit{NULL}\) est satisfait.
En tenant compte de l'expérience utilisateur, dans un environnement de serveur ARM avec des ressources massives, telles que des centaines de cœurs de processeur (par exemple, les processeurs Dual Ampere Altra Max), le coefficient de détermination des ressources inutilisées \(\mathit{THR}_{\mathit{Idle}}\) peut être encore réduit et le coefficient de ressource effectif \(\mathit{THR}_{\textit{Efficient}}\) peut encore être amélioré. Lors de la création d'un conteneur, des stratégies de restriction de ressources configurables facultatives pour le conteneur sont disponibles. Si le conteneur n'est pas configuré avec une limite d'utilisation des ressources (la valeur lui est attribuée à \(\mathit{NULL}\)), lorsque des programmes malveillants à l'intérieur du conteneur consomment continuellement des ressources, les ressources correspondantes sur l'hôte seront épuisées, ce qui affectera également le fonctionnement normal des autres conteneurs sur le même hôte.
3.2 Sous-système de partage de GPU
Les cadres du sous-système de partage GPU et la comparaison des deux méthodes (API à distance et GPU pass-through) sont présentés dans la figure 3.
Les ressources GPU sont le facteur essentiel pour garantir le bon fonctionnement des applications 3D et la lecture vidéo plus fluide. Pour fournir des ressources GPU (à l'aide d'une carte graphique GPU Nvidia ou AMD et des pilotes correspondants) au conteneur Android, deux méthodes sont explorées : (1) la méthode d'accès à distance de l'API (étiquetée Méthode I) et la méthode d'intercommunication GPU (Méthode II).
3.2.1 Méthode I : API à distance
Basé sur les bibliothèques OpenGL ES, les bibliothèques OpenGL et les pilotes GPU, pour réaliser le partage des ressources GPU en mode de transfert API, le processus de transmission suivant du flux d'instructions est réalisé : Lorsque des applications 3D (par exemple, un jeu) sont lancées dans un conteneur Android, une série de flux d'instructions d'OpenGL ES sera d'abord codée ; Ensuite, ils seront transmis aux exécutions de Processing-Engine à l’intérieur du système d’exploitation hôte via un canal à grande vitesse. Enfin, les instructions codées seront décodées, traduites en instructions OpenGL, exécutées dans la séquence d'origine et renvoyées les résultats d'exécution. En raison des exigences de fourniture du flux d'instructions OpenGL ES au middleware à grande vitesse, nous avons utilisé le mécanisme de mémoire partagée pour réaliser le canal de communication comme le montre la figure 4.
Plus précisément, lorsque les processus de service système (processus surfaceflinger, processus system_server, processus gralloc, etc.) dans Android et les applications sont démarrés, l'API liée aux graphiques sera appelée via libEGL.so. Ensuite, selon les paramètres des propriétés Android, les fonctions correspondantes dans libEGL_emulation.so, libGLESv1_CM_emulation.so et libGLESv2_emulation.so seront appelées. Après cela, l'appel de fonction sera codé via libOpenglSystemCommon.so et envoyé au Processing-Engine sur l'hôte via le canal IPC haut débit. Enfin, le module Processing-Engine décode l'appel de fonction et appelle le pilote GPU à exécuter.
L'avantage de la méthode I est qu'une large gamme de GPU peut être prise en charge et sans risque de verrouillage du fournisseur de GPU, qui dépend uniquement des fonctionnalités OpenGL prises en charge par les GPU et les pilotes correspondants. Mais la couche intermédiaire entraîne une certaine perte de performances.
3.2.2 Méthode II : Pass-Through GPU
Le relais x86 traditionnel distribue principalement le GPU désigné directement à la VM désignée pour une utilisation indépendante ; et le périphérique PCI est directement transmis à la VM, qui est responsable de l'initialisation, de la lecture-écriture et d'autres opérations du périphérique, et l'ensemble du périphérique est monopolisé par la VM. Cependant, dans un environnement conteneurisé, il n’existe aucun processus d’initialisation du périphérique ; chaque système Android utilise les ressources de la carte GPU sous la forme d'une application, ce qui équivaut à plusieurs applications utilisant une carte GPU en même temps pour réaliser le partage des ressources. De plus, grâce à la méthode GPU pass-through, un périphérique GPU doit être attribué à un conteneur Android par la technologie pass-through, et son pilote est porté dans le conteneur pour interagir avec le cadre de rendu d'Android.
Plus précisément, cela est similaire au processus d'accès à distance à l'API. Prenons l'exemple de la carte graphique AMD. Lorsque les processus de service système et les applications sous Android sont démarrés, les fonctions correspondantes dans libEGL_mesa.so, libGLESv1_CM_mesa.so et libGLESv2_mesa.so de Mesa seront appelées via libEGL.so selon les paramètres des propriétés Android, et alors ces fonctions seront exécutées directement sur le GPU AMD via le pilote correspondant.
Pour réaliser le partage des ressources GPU en mode pass-through, les travaux suivants ont été effectués : L'accent est mis sur la compilation de Mesa et son installation dans le conteneur Android, qui provient de la base de code AOSP (Android Open Source Project), et sur la stabilité du programme. est amélioré (par exemple, élimination du problème de plantage des processus Android lors de l'exécution de certaines applications).
L'approche présente une efficacité et des performances plus élevées car il n'y a pas de couche intermédiaire pour la redirection des instructions, alors qu'elle nécessite un pilote correspondant dans chaque conteneur spécifique. De manière pessimiste, les progrès actuels en matière d'adaptation sont décourageants : il faut beaucoup de temps aux fournisseurs pour développer et modifier divers pilotes GPU (non open source). De plus, la méthode facture en fonction du nombre d'instances de conteneur, ce qui constitue également un problème de coût économique inévitable. Par exemple, en fonction de l'investissement du vGPU (GPU virtuel) de NVIDIA dans le scénario VDI, l'investissement global d'une instance (y compris le matériel et logiciel) est très cher, ce qui coûte équivalent ou plus qu'un PC, mais entraîne de mauvaises performances et une pire expérience utilisateur. C'est également une incitation importante à la naissance d'une solution agricole.
3.3 Sous-système de transmission à distance
Nous avons pris un terminal Android comme exemple pour construire le sous-système de transmission, comme le montre la figure 5. Le cadre comporte deux modules : (1) Un Agent : Service module exécuté dans le conteneur, qui est chargé de capturer et d'encoder les images d'écran, les audios et d'injecter des signaux de contrôle (par exemple, clavier, souris, manette de jeu) ; (2) Un Agent : Client module fonctionnant dans le terminal, conçu pour décoder la vidéo et le son et intercepter les signaux de contrôle ci-dessus.
Les deux modules ont été déployés à différentes couches en fonction des considérations suivantes :
(1) Le Agent : Service Le module a été déployé dans la couche du cadre d'application Android.
- Capture d'image d'écran : les données d'image du bureau ou de l'interface d'application peuvent être capturées dans cette couche en accédant à «GraphiqueBuffer" objet et "Image_getLockedImage()", qui présente les avantages d'un délai minimal et est transparente pour la couche application.
- Capture audio : l'audio peut être capturé en accédant à «Enregistrement audio» objecte directement.
- Injection de signaux de contrôle : après réception des signaux de contrôle, la conservation du format sera effectuée selon les spécifications de format de données entre différentes couches.
(2) Le Agent : Client Le module a été placé dans la couche application du terminal.
- Affichage d'images : obtenez les flux vidéo encodés pour le décodage, le rendu et l'affichage ; il y a l'avantage d'une compatibilité optimale dans cette couche.
- Lecture audio : récupérez les flux audio envoyés par Agent : Serveur et décodez-le.
- Interception des signaux de contrôle : appelez les classes correspondantes de la bibliothèque système pour intercepter directement les événements d'entrée (par exemple, clavier, souris, toucher), ce qui présente l'avantage d'être le moins complexe possible.
4. Expériences
Selon la figure 2, nous utilisons deux serveurs ARM, des commutateurs Gigabit Ethernet, des cartes réseau Gigabit et des GPU pour créer une plate-forme cloud ARM. Les principaux paramètres matériels et logiciels sont indiqués dans les tableaux 5 et 6. D'autres paramètres essentiels seront indiqués dans les sous-sections correspondantes.
4.1 Fonctions du conteneur
Un conteneur a été initialisé sur le serveur I avec une carte Nvidia GTX 1650 et les paramètres clés du conteneur étaient : 2 processeurs, 8 Go de capacité de mémoire, 256 Go d'espace disque ; la qualité de l'image du conteneur a été réglée sur 720P à 60 ips ; Le système d’exploitation du conteneur est Android 9 (Pie). L'AIDA64 a été utilisé pour vérifier les caractéristiques GPU du conteneur sans/avec ressource GPU, comme le montrent respectivement les figures 6 et 7, le conteneur avec ressources GPU peut prendre en charge une version supérieure d'OpenGL ES (version : 3.0) et davantage de fonctionnalités.
Ensuite, l'outil de référence AnTuTu a été utilisé pour tester les performances du conteneur, car la version d'OpenGL ES prise en charge par le conteneur sans GPU n'est que 1.0, AnTuTu ne fonctionnait pas correctement, alors qu'il pouvait fonctionner correctement dans le conteneur avec GPU, comme le montre la Fig. 8 (pour des raisons de droits d'auteur commerciaux et de licence, cette section ne discute pas des pratiques détaillées des conteneurs avec GPU pass-through NVIDIA à ce stade, et prend les GPU AMD comme alternatives à discuter dans la section 4.3.).
De plus, le jeu mobile Anonymous Me pour Android a été sélectionné comme échantillon de jeu, les terminaux étant des téléphones mobiles Google Pixel et Huawei. Les principaux paramètres codés de la vidéo et de l’audio sont :
- Vidéo: "Préréglage : réglage ultra-rapide : profil à latence nulle : contrôle de débit principal : ABR, débit binaire : 4000 4000, vbv_buffer_size : XNUMX XNUMX";
- L'audio: "opus 44.1 kHz stéréo VBR ».
Selon les statistiques, le débit binaire consommé par le cloud gaming était d'environ 4 Mbps, et le SSIM (similarité structurelle) et le PSNR (rapport signal/bruit de pointe) entre les images source dans le conteneur et les images décodées dans le terminal sont illustrés aux figures 9 et 10. Les valeurs moyennes de SSIM et PSNR sont respectivement d'environ 96 % et 38.3 dB ; le délai moyen est d'environ 50 ms dans notre environnement de test LAN.
4.2 Ajustement des ressources du conteneur
Nous avons appliqué l'algorithme proposé dans la Sect. 3.1 au scénario suivant : initialisez 9 conteneurs Android dans le serveur I et les quotas de processeur ont été configurés trop grands et entraîneraient une surcharge du serveur. Le cycle de surveillance \(T_{\textit{Interval}}=10\ \textit{seconds}\); le système d'exploitation du conteneur est Android 9. Les paramètres spécifiques au conteneur, comme indiqué dans le tableau 7.
Comme le montre la figure 11, tous les conteneurs et le serveur ont fonctionné à pleine charge en exécutant 'Test de stress Android' outil à l'intérieur de chaque conteneur. Après avoir activé l'algorithme d'ajustement de la configuration des ressources au cours du 30ème cycle de surveillance, c8 avec la charge la plus importante a été choisi pour être migré, et la charge du serveur a été réduite à moins de 90 %, et il restait des ressources CPU comme le montre la figure 12. De plus, un événement de demande de rafale de ressources est simulé du conteneur c1 entre le 31e et le 38e cycle de surveillance, qui nécessite 8 CPU supplémentaires ; à ce stade, selon l'algorithme proposé, pour c1, une nouvelle politique \(p_{\textit{c1}}=\left(cr_{\textit{MiniReq}},cr_{\textit{Capping}}+\Delta cr_{\textit{c1}}\right)_{\textit{c1}}\) sera généré et exécuté, ce qui allouerait des ressources à c1 à partir de ressources gratuites. Comme le montre la figure 12, \(p_{\textit{c1}}\) sera mis à jour de manière itérative dans un nombre limité de cycles de surveillance. Le résultat final est : Dans la plage de charge de 90 % du serveur \(\textit{THR}_{\textit{Efficient}}\), la demande de ressources de c1 était satisfait au maximum.
De plus, la définition des intervalles de temps de surveillance des ressources doit être évaluée de manière globale en fonction des applications métier spécifiques et du temps d'attente tolérable de l'utilisateur, comme les différents délais tolérés de trois scénarios d'applications distantes dans le tableau 3. Si un intervalle de temps très court est défini , cela entraînera une surcharge de calcul plus importante et une moins bonne expérience utilisateur.
La recherche technologique actuelle se concentre sur les goulots d'étranglement d'une ressource unique, tels que la planification des ressources CPU pour les tâches gourmandes en calcul dans le scénario de test. La méthode peut être étendue à la planification des ressources pour les tâches gourmandes en réseau et les tâches gourmandes en E/S disque, car l'ajustement dynamique des ressources (augmentation ou réduction) ne provoque pas d'exceptions de processus de conteneur. Cependant, pour la gestion des ressources mémoire, seule une opération d'extension de mémoire en ligne est généralement effectuée. Si une réduction de la mémoire en ligne est effectuée, cela déclenchera 'Mémoire insuffisante' exception.
Selon les pratiques industrielles, afin de réduire la difficulté de gestion du système, de planifier plus facilement le matériel et de réduire la difficulté de gestion des pannes du système, la grande majorité des plateformes cloud ont tendance à déployer le même type de tâches informatiques sur le même serveur. L’ordonnancement de ressources d’un seul type constitue donc la première étape de notre recherche. Avec l’amélioration des performances des serveurs, la planification dynamique complète des ressources multidimensionnelles sera également au centre des prochaines recherches.
4.3 Performances parallèles
Plusieurs conteneurs Android ont été initialisés sur Server II et les paramètres clés étaient : 4 processeurs, 8 Go de capacité de mémoire, 256 Go d'espace disque ; Le système d’exploitation du conteneur est Android 12 (S) ; le jeu mobile'Anonyme Moi' pour Android a été sélectionné. Les données détaillées d'un scénario de test (720 * 1280 60 à 13 ips), comme indiqué dans la figure 8 et le tableau XNUMX.
Dans le test de performances de concurrence des scénarios de jeu, en raison d'exigences graphiques plus élevées, Android 12 a été sélectionné comme système d'exploitation du conteneur. Cependant, pour les facteurs suivants : (1) Pour le mode Pass-through, le GPU NVIDIA ne dispose pas de pilotes adaptés à Android 12 qui ne peuvent être fournis que par NVIDIA ; (2) Pour le mode API à distance, dans l'environnement du système d'exploitation hôte d'Ubuntu aarch64, AMD ne fournit pas de pilote officiel ; Les pilotes actuellement disponibles sont des pilotes Mesa compilés par la communauté, qui ne peuvent pas répondre aux exigences de réalisation. Par conséquent, nous choisissons AMD RX 590 et NVIDIA GTX 1650 avec des performances similaires à celles des GPU pour le test comparatif des deux modes : le mode Pass-through utilise AMD RX 590 et le mode API Remote utilise NVIDIA GTX 1650. Les statistiques résumées comme indiqué dans Tableau 9.
Les statistiques de test montrent que le mode pass-through a des performances plus élevées : en raison du mode d'accès à distance de l'API, cela entraînera la perte de nombreuses fonctionnalités du GPU ; et limité par l'ouverture du fabricant de la carte graphique envers le pilote. Quel que soit le mode utilisé, pour obtenir un parallélisme plus élevé, il est nécessaire de mener des recherches et des optimisations en combinaison avec le matériel, les pilotes et les applications 3D.
5. Conclusions et travaux futurs
Des serveurs et des terminaux basés sur ARM ont été déployés dans l'industrie du cloud computing (par exemple, cloud gaming, cloud mobile, cloud computing/cloud desktop). Dans cet article, afin de fournir une référence complète pour la création d'un cloud basé sur ARM, les solutions traditionnelles et les technologies clés ont été étudiées et comparées : pour la virtualisation générale des ressources informatiques, les technologies et les solutions traditionnelles du modèle d'hyperviseur (par exemple, solution Phytium, ARM/KVM) et le modèle de conteneur (par exemple, LXC, Docker, LXD, Ubuntu Touch, Anbox, Monbox, ReDroid) ont été discutés ; un algorithme adapté à l'ajustement dynamique des ressources partielles du conteneur a été mis en œuvre, axé sur les goulots d'étranglement d'une ressource unique ; pour la virtualisation GPU, les technologies GPU pass-through et API remoting ont été recherchées. Ensuite, la transmission à distance en tant qu'élément essentiel de la fourniture de services cloud a été analysée en détail (y compris des scénarios de contrôle à distance simple, d'infrastructure de bureau virtuel et de jeux dans le cloud). En outre, une plate-forme cloud spécifique basée sur ARM a été mise en œuvre en utilisant des technologies de conteneur, de pass-through GPU et d'API à distance. Enfin, les pratiques pertinentes ont été mises en œuvre et les statistiques ont prouvé l'efficacité du cadre et des techniques.
Étant donné que la plate-forme IaaS est composée de serveurs physiques indépendants, en utilisant le cadre et les méthodes de réalisation proposés dans cet article, une plate-forme répondant aux exigences de ressources massives pourrait être construite par des serveurs physiques en expansion horizontale. De plus, la division des domaines de sécurité avec une capacité de défense en profondeur pour les différents réseaux d'entreprise doit être envisagée.
La description formelle de l'article se concentre actuellement principalement sur les composants du système, dans le but de fournir une description conceptuelle et concise des systèmes ou solutions existants, et de proposer des composants essentiels du système. À l’heure actuelle, il n’y a aucune discussion sur les états détaillés des différents éléments du système. Ensuite, nous mènerons des recherches approfondies sur la transition d'état du cycle de vie de chaque élément du modèle (comme la construction d'une machine à états finis et d'un diagramme de transition d'état pour chaque élément), les contraintes de sécurité, la vérification ou la réduction formelle, etc.
À l'instar du développement écologique des puces à architecture X86, le succès de la virtualisation basée sur ARM (par exemple, le taux d'adoption élevé, la large gamme d'applications) dépend principalement du facteur coût-performance (rapport prix-performance), qui est déterminé par facteurs liés au prix de l'appareil, à l'efficacité de la virtualisation et au nombre d'instances parallèles, en particulier pour les ressources GPU. Avec la prise en charge de la technologie des conteneurs, les performances parallèles des serveurs cloud ARM (la rentabilité du service cloud monocanal) sont principalement limitées par la gestion et l'allocation des ressources GPU. Pour différents scénarios, la mise en œuvre d'une technologie de virtualisation fine à partir des cœurs GPU (cœurs CUDA) et de la mémoire GPU sont des méthodes d'optimisation réalisables, de manière à améliorer l'efficacité énergétique et l'expérience utilisateur pour les scènes informatiques à usage général et de rendu graphique respectivement, alors qu'elles nécessitent le support des fabricants de cartes graphiques. De plus, dans des scénarios graphiques interactifs tels que le cloud gaming et la conception cloud, en introduisant une carte d'encodage dédiée, le GPU n'a plus qu'à effectuer le travail de rendu, puis la densité des services cloud du serveur ARM est encore augmentée. À l'avenir, nous mènerons des travaux de recherche connexes dans les domaines ci-dessus.
Remerciements
Ce travail a été soutenu en partie par le projet de démonstration de l’industrie des services scientifiques et technologiques de la province chinoise du Sichuan sous la subvention n° 2021GFW023 et en partie par le projet de recherche conjoint Arm Technology (Chine) sous la subvention n° CMA-CLA-01337.
Références
[1] J.P. Huai, Q. Li, and C.M. Hu, “Research and design on hypervisor based virtual computing environment,” J. Software, vol.18, no.8, pp.2016-2026, Aug. 2007. DOI: 10.1360/jos182016
CrossRef
[2] B.H. Yang, W.J. Dai, and Y.L. Cao, Docker Primer, pp.4-9, China Machine Press, Beijing, China, 2018.
[3] Y.H. Chen, “Development of container-based virtualization technology,” ICT Journal, vol.1, no.167, pp.11-16, Sept. 2016.
[4] Wikipedia, “OS-level virtualization,” https://en.wikipedia.org/wiki/OS-level_virtualization, accessed Feb. 2. 2023.
URL
[5] H. Yin, “Research on virtualization technology based on the server made in China,” Electron. World, vol.23, no.1, pp.103-104, Feb. 2020.
[6] Phytium, OpenGCC, From Terminal to Cloud: Full Stack Solution White Paper Based on Phytium Platform, 2nd ed., pp.1-81, Phytium, Tianjin, China, 2020.
[7] Y.F. Huang, “Virtualization on ARM machine platform,” M.S. thesis, Dept. Computer Science & Technology, Huazhong Sci.& Tec., Hubei, China, 2019. DOI: 10.27157/d.cnki.ghzku.2019.003846
CrossRef
[8] H.Y. Ma, “Experiments about the performance of full virtualization and containers on ARM-v8 platform,” Proc. 2019 ITEEE, Sanya, China, pp.394-403, 2019. DOI: 10.12783/DTCSE/ITEEE2019/28777
CrossRef
[9] F. Olivier, M. Fabien, and N. Florent, “A review of native container security for running applications,” Proc. 17th MobiSPC, pp.157-164, Leuven, Belgium, 2020. DOI: 10.1016/j.procs.2020.07.025
CrossRef
[10] E. Alexia, “Infographic: LXD Machine containers from Ubuntu,” https://ubuntu.com/blog/infographic-lxd-machine-containers-from-ubuntu, accessed Feb. 2. 2023.
URL
[11] Faun., “Container Architecture,” https://wiki.ubuntu.com/Touch/ContainerArchitecture, accessed Feb. 2. 2023.
URL
[12] AMPERE, NETINT, Android in the cloud on ARM native servers, 1st ed., London, United Kingdom, Canonical, 2020.
[13] F. Simon, “Anbox,” https://github.com/anbox/anbox, accessed Feb. 2. 2023.
URL
[14] J.D. Chen, “Huawei cloud: Kunpeng cloud mobile phone architecture decryption,” Proc. HDC Together, pp.1-16. Guangdong, China, 2020.
[15] W.Z. Chen, L. Xu, G.X. Li, and Y. Xiang, “A light-weight virtualization solution for Android devices,” IEEE Trans. Comput., vol.64, no.10, pp.2741-2751, Oct. 2015.
CrossRef
[16] K.M. Shi, “The design and implementation of Android desktop cloud system based on LXC,” M.S. thesis, Dept. Computer Science & Technology, Zhejiang University, Hangzhou, China, 2018.
[17] Arclab, “Condroid,” http://condroid.github.io/, accessed Feb. 2. 2023.
URL
[18] T. Ian, iFan, H. Victor, “Android Containerization,” https://github.com/clondroid, accessed Feb. 2. 2023.
URL
[19] X.Y. Yin, X.S. Chen, L. Chen, G. Shao, H. Li, and S. Tao, “Research of security as a service for VMs in IaaS platform,” IEEE Access, vol.6, pp.29158-29172, 2018. DOI: 10.1109/ACCESS.2018.2837039
CrossRef
[20] X.Y. Yin, X.S. Chen, L. Chen, and H. Li, “Extension of research on security as a service for VMs in IaaS platform,” Security and Communication Networks, vol.2020, pp.1-16, 2020. DOI: 10.1155/2020/8538519
CrossRef
[21] B. Peng, P. Yang, Z.C. Ma, and J.G. Yao, “Performance measurement and analysis of ARM embedded platform using Docker container,” Journal of Computer Applications, vol.37, no.S1, pp.325-330, June 2017.
[22] L. Xu, Z.H. Wang, and W.Z. Chen, “The study and evaluation of ARM-based mobile virtualization,” International Journal of Distributed Sensor Networks, vol.2015, no.1, pp.1-11, Oct. 2014.
CrossRef
[23] Z.Y. Zhou, “Remote-android,” https://github.com/remote-android, accessed Feb. 2. 2023.
URL
[24] K. Su, “Research on virtualization techniques for cloud desktop services,” Ph.D. dissertation, Dept. Computer Science & Technology, Zhejiang University, Hangzhou, China, 2017.