Les serveurs à machine virtuelle sont-ils meilleurs que les serveurs à métal nu ?

Une partie de la stratégie d'hébergement d'applications d'un ISV Windows® consiste à choisir entre l'exécution de son application sur un serveur bare metal ou une machine virtuelle (VM) sur le service cloud de son fournisseur.

Quelle est la différence entre les serveurs Bare Metal et les serveurs VM ?

Les serveurs "bare metal" sont des machines physiques dédiées proposées par un fournisseur de services en nuage. L'intégralité de la machine est dédiée à l'ISV. Le système d'exploitation est chargé directement sur la machine, l'application de l'ISV fonctionne sur ce système d'exploitation et l'application a un accès exclusif à toutes les ressources informatiques de cette machine.

En revanche, les serveurs de machines virtuelles (VM) fonctionnent sur une machine physique, mais nécessitent l'installation d'un hyperviseur en plus du système d'exploitation. L'hyperviseur partitionne la machine physique en plusieurs VM, chacune exécutant son propre système d'exploitation. Bien que chaque VM fonctionne de manière indépendante, toutes les VM d'une machine physique partagent les ressources informatiques de cette machine.

Lorsqu'un fournisseur de services Internet propose son application aux utilisateurs à partir d'un serveur VM, les hyperviseurs nécessaires pour partitionner la machine physique en VM consomment 5 à 10 % des ressources du serveur, ce qui se traduit par une très légère latence. Pour la plupart des éditeurs de logiciels indépendants, cette latence a un impact négligeable sur l'expérience de l'utilisateur.

Mais si l'ISV utilise également une solution de bureau virtuel comme Citrix® pour fournir son application, la latence sera plus problématique. Pourquoi ?

La complexité de Citrix est source de latence.

Voici quelques exemples :

• Au départ, Windows n'est pas optimisé pour Citrix - les experts dénombrent au moins 100 optimisations possibles pour réduire la latence.
• Outre l'installation et la configuration de Citrix lui-même, la mise en œuvre d'un environnement Citrix nécessite la coordination de nombreux sous-systèmes, notamment SQL, le stockage et Microsoft® Active Directory. Toute mauvaise coordination affecte la latence.
• Des problèmes dans la conception générale, même minimes, peuvent ajouter de la latence ; par exemple, une VM qui est même légèrement sous-dimensionnée.
• Les profils d'utilisateurs mal configurés ont un impact négatif sur les performances de l'application.
• Placement physique de la passerelle Citrix : pour minimiser la latence, la passerelle doit être placée à proximité du serveur.
• Citrix NetScaler peut ralentir le trafic réseau en raison d'une mauvaise configuration ou de problèmes échappant au contrôle du service informatique, tels que des pics de CPU ou de mémoire et des dépassements de délais de retransmission.

Dans ce cas, pourquoi ne pas opter pour un serveur "bare metal" ?

L'argent.

Les serveurs bare metal sont considérablement plus chers que les serveurs VM, même si les serveurs ont des charges de travail identiques. Tout d'abord, si un ISV a opté pour le bare metal, il paiera pour l'ensemble de la machine, qu'il utilise ou non toutes les ressources de celle-ci. Pour ajouter du sel à la plaie, si l'ISV a besoin d'un serveur de secours à froid pour la reprise après sinistre (par exemple, un ISV qui a besoin d'un serveur de secours pour se conformer à la réglementation), il paiera pour cette machine, qu'il en ait besoin ou non.

De combien d'argent s'agit-il ? À l'heure où nous écrivons ces lignes, une instance virtuelle t3 large d'Amazon Web Services (AWS) (la plus grande instance virtuelle t3 proposée par AWS) est facturée 0,10 $ par heure. En revanche, une instance t3 dédiée AWS (c'est-à-dire un serveur physique dédié) est facturée 5,50 $ par heure.

Ainsi, sur une période de facturation de 30 jours (720 heures), un ISV paiera 720 $ pour une instance virtuelle t3 large et 3 960 $ pour une instance t3 dédiée. Bien qu'il ne s'agisse pas nécessairement d'une comparaison d'une pomme à l'autre - par exemple, nous manquons de détails sur le nombre d'utilisateurs pouvant être pris en charge sur chaque instance - il s'agit d'une différence de coût stupéfiante.

{{CTAEMBED_IDENTIFIER}}

Flexibilité, souplesse et évolutivité

Outre le surcoût, les éditeurs de logiciels qui utilisent des serveurs "bare metal" ne bénéficient pas de la souplesse et de l'agilité qu'offrent les serveurs VM. Un nouveau serveur VM peut être configuré et déployé en quelques minutes. Les machines virtuelles peuvent également être rapidement déplacées vers un nouvel environnement ou une nouvelle machine physique. En revanche, l'installation d'un nouveau serveur bare metal peut prendre des heures, voire des jours, si l'ISV a des exigences inhabituelles. Les éditeurs de logiciels qui utilisent des serveurs bare metal doivent planifier et prévoir avec soin leurs besoins en ressources ; les éditeurs de logiciels qui utilisent des serveurs VM peuvent être beaucoup plus réactifs et agiles.

Les serveurs VM présentent un avantage considérable en termes d'évolutivité par rapport aux machines "bare metal" en raison de leur flexibilité inhérente. Les éditeurs de logiciels indépendants peuvent ajuster leur environnement applicatif en redimensionnant les VM, en répartissant les charges de travail dynamiques entre les machines et en déplaçant les charges de travail, les applications et les données d'une VM à l'autre. En revanche, lorsqu'un ISV commence à dépasser les capacités d'un serveur bare metal, la seule option est d'ajouter du matériel, ce qui demande du temps et une planification minutieuse.

Exemple concret

Ici, chez GO-Global, nous avons rencontré cette situation avec un nouveau client ISV qui utilisait Citrix pour fournir ses applications aux institutions financières à partir d'un service de nuage public. En raison de la nature du logiciel, les clients de cet ISV s'attendaient à une latence proche de zéro, ce qui a conduit Citrix à recommander des serveurs bare metal pour répondre à cette attente.

Après des années passées à absorber le coût de l'utilisation de Citrix et de serveurs nus pour fournir un accès au nuage aux clients, l'équipe de gestion de l'infrastructure de l'ISV a commencé à chercher des moyens d'économiser et a trouvé GO-Global®.

GO-Global étant un éditeur d'applications, et non un VDI comme Citrix, il ne nécessite pas d'hyperviseur, ce qui élimine l'une des causes de latence au niveau du serveur.

À un niveau plus fondamental, GO-Global réduit la latence grâce à son protocole propriétaire et breveté RapidX Protocol (RXP), utilisé pour toutes les communications de données entre le client et l'hôte de GO-Global. Plutôt que de transmettre des bitmaps d'écran sur le réseau, RXP transfère des commandes de dessin individuelles, ce qui permet une transmission plus rapide et une meilleure compression des données que les autres solutions. Le protocole d'affichage RXP est presque entièrement asynchrone, ce qui signifie que l'hôte et le client attendent rarement une réponse de leur homologue. En comparaison, Citrix transmet les frappes au serveur d'application, qui redessine l'écran à chaque frappe.

En outre, contrairement à Citrix, GO-Global ne duplique pas les composants de l'infrastructure du nuage public et les caractéristiques d'évolutivité. Au lieu de cela, GO-Global exploite l'infrastructure existante et les caractéristiques d'évolutivité d'un service de nuage pour fournir une fonctionnalité similaire avec moins de complexité et moins de latence.

L'ISV mentionné ci-dessus se prépare actuellement à lancer sa nouvelle infrastructure de fourniture d'applications en utilisant GO-Global et des serveurs VM. Le passage à GO-Global a réduit ses coûts de licence de fourniture d'applications et lui permettra de maintenir une faible latence afin de répondre aux attentes des clients. Le passage des serveurs bare metal aux serveurs VM a également permis de réduire les coûts de manière significative.

En réponse à la question "Les serveurs à machines virtuelles sont-ils meilleurs que les serveurs à base de métal nu ?", la plupart des fournisseurs de services Internet se retrouvent à choisir entre un coût moindre avec les machines virtuelles et une latence moindre avec les serveurs à base de métal nu. Mais pour l'ISV dont il est question dans cet article, en passant à GO-Global avec des VM, il n'a pas eu à choisir l'un ou l'autre, il a obtenu à la fois des prix abordables et une excellente expérience utilisateur.

Si vous êtes un ISV Windows à la recherche d'une solution de publication d'applications qui utilise très efficacement les ressources informatiques, élimine la complexité inutile et réduit la latence, pensez à GO-Global. GO-Global est une solution de publication d'applications spécialement conçue pour publier des applications Windows à partir de n'importe quel nuage, de manière simple, facile et rentable.

Pour en savoir plus sur GO-Global, demandez une démonstration ici ou téléchargez une version d'essai gratuite de 30 jours.