When VMware became fully aware of the scale of the RAM shortage, VCF 9.1 was already largely finalized, according to one employee reacting to a topic that has been drawing attention in the community: the rising hardware requirements for management services.

VCF 9.0 had already hinted at a shift toward a more centralized experience built around VCF Operations. With VCF 9.1, VMware continues in that direction, but the back end is evolving in ways that increase the footprint. One example is the introduction of a headless appliance acting as a license server. This VM is added to each VCF Operations instance used to manage licenses, and customers can deploy just one—or several, notably to maintain availability on sites with unreliable connectivity.

The bigger change concerns VCF Management Services, VMware’s effort to unify management services around a single runtime. That runtime is heavy: it requires at least 40 vCPU and 82 GB of RAM. In production environments, which are VMware’s main target, that is less of an issue. The problem is more acute in labs, especially as RAM prices continue to rise.

The runtime is installed in the first VCF instance and includes fleet-level components such as log management and policy engines, as well as instance-level functions such as configuration enforcement and identity brokering. It can also be deployed in an additional instance to run instance-level components. The high-availability model uses three control nodes plus a number of workers that varies depending on deployment size.

Lorsque VMware a pleinement pris conscience de l’ampleur de la pénurie de RAM, VCF 9.1 était déjà largement finalisé…

Ainsi s’exprime un de ses employés, en réaction à un sujet qui anime la communauté : l’accroissement des exigences matérieles pour les services de gestion.

VCF 9.0 avait laissé entrevoir un recentrage de l’expérience sur VCF Operations. Avec VCF 9.1, VMware maintient le cap, mais fait évoluer le back-end… dont l’empreinte s’accroît. Par exemple avec l’introduction d’une appliance headless faisant office de serveur de licence.

Cette VM est ajoutée à chaque instance VCF Operations utilisée pour gérer des licences. Il est possible de n’en déployer qu’une… ou plusieurs, notamment pour assurer une disponibilité sur les sites à la connectivité non fiable.

Les services de gestion VCF, unifiés sur un runtime… gourmand

Chacun de ces serveurs nécessite 2 vCPU et 8 Go de RAM. Mais le véritable « gros morceau » s’appelle VCF Management Services. Sous cette bannière, VMware unifie ses services de gestion autour d’un runtime. Lequel consomme au moins 40 vCPU et 82 Go de RAM.

Dans les environnements de production, en tout cas ceux que cible VMware, c’est une moindre contrainte. Il en est autrement dans les labs, à l’heure où le prix de la RAM continue à enfler.

Le runtime s’installe dans la première instance VCF, avec des composants de niveau flotte (gestion de logs, moteur de politiques..) et de niveau instance (application des configurations, courtage d’identités…). On peut éventuellement le déployer dans une instance supplémentaire pour exécuter des composants de niveau instance. Le modèle haute disponibilité utilise 3 nœuds de contrôle et un nombre de workers dépendant de la taille du déploiement.

Modèle de déploiement mono-instance

Modèle de déploiement sur instance supplémentaire

Á consulter en complément :

VMware exclut l’UE de la marché forcée vers VCF

De VMware à Hyper-V : Microsoft tend une perche de plus

AWS rejoint Azure et Google Cloud sur la virtualisation imbriquée

La Cnam fait plier VMware avec un référé

Illustration © ZayNyi – Adobe Stock

The post Les exigences matérielles de VCF 9.1 interpellent appeared first on Silicon.fr.