VMware consolide vSphere dans le stockage, la sécurité et le multicloud

Le SDS vSAN Max étend le stockage indépendamment des VMs

Comparativement au SDS vSAN, qui est intégré au cluster de serveurs exécutant les machines virtuelles, le SDS vSAN Max sert à constituer un cluster uniquement dédié au stockage. Son intérêt est financier : il permet d’étendre la quantité de disques à partir de serveurs peu puissants, donc moins chers, là où vSAN impose de rajouter des serveurs avec la même puissance processeur.

En clair, vSAN avait été conçu pour pouvoir étendre facilement un projet, par l’ajout à l’envie de briques identiques, ce qui est le principe des infrastructures hyperconvergées. De son côté, vSAN Max est plus adapté aux scénarios dans lesquels les applications consomment au fil du temps plus de données, sans devoir elles-mêmes grimper en puissance. En l’occurrence, vSAN Max gère jusqu’à 8,6 Po de capacité. Et comme il est optimisé pour les SSD NVMe (le système conserve la même base technique que vSAN 8), il supporte, selon VMware, 3,6 millions d’IOPS par cluster dédié au stockage.

Commercialement parlant, vSAN Max n’est pas une extension de vSAN, mais un produit à part. Ainsi, vSAN est facturé au nombre de processeurs présents dans le cluster, tandis que vSAN Max est facturé selon la capacité de stockage qu’il gère. Dans les deux cas, ces systèmes simulent une baie de stockage à partir des disques durs présents dans chacun des serveurs d’un cluster.

« Vous pourriez vous dire que vSAN dans sa version Max n’est finalement qu’une baie de stockage comme celles que fournissent nos partenaires. Mais l’objectif de vSAN a toujours été de faciliter l’utilisation du stockage, via notre console d’administration vCenter qui gère aussi les machines virtuelles. Et c’est ce que nous continuons de faire avec la version Max », commente John Gilmartin, le directeur de VMware, responsable de la mise au point des produits de stockage.

 « Nous offrons un environnement d’administration qui résout pour vous les problèmes de stockage, en prenant en compte pour chaque volume les mêmes priorités que celles des machines virtuelles associées à ces volumes. C’est un environnement plébiscité par 30 à 35 000 entreprises qui ont jusqu’ici préféré investir dans vSAN plutôt que dans une autre solution de stockage. »

« L’autre point, surtout, est que nous revendiquons atteindre d’excellentes performances comparativement aux autres solutions SAN. Et cela a été rendu possible par la refonte totale que nous avions opérée lors de la mise au point de vSAN 8 », ajoute-t-il.

Restaurer plus vite l’activité dans le cloud en cas d’attaque

Concernant la fonction Ransomware Recovery, sa principale nouveauté est de mettre en production plusieurs copies de secours à la fois, au lieu de l’une après l’autre auparavant. Cette simple amélioration serait critique dans le sens où elle réduirait drastiquement la durée durant laquelle l’activité d’une entreprise est gelée.

Rappelons que la fonction Ransomware Recovery, lancée l’année dernière, détermine les sauvegardes saines de tout malware avant de les restaurer. C’est une version étendue de Disaster Recovery, un service plus ancien qui effectue des snapshots réguliers d’un cluster et qui, en cas de problème, restaure automatiquement les contenus de ces snapshots dans un cluster virtuel d’appoint chez AWS.

« La pertinence du système de snapshots est que, contrairement à une solution de sauvegarde, vous n’avez pas à extraire les données pour les remettre dans une forme opérationnelle. Avec les snapshots, vous transformez juste des blocs qui contiennent des copies de vos données à un instant T en blocs directement utilisables. C’est instantané, il faut juste redémarrer les machines virtuelles restaurées, ce dont s’occupe le service Ransomware Recovery », explique John Gilmartin.

En pratique, pour accéder à la fonction Ransomware Recovery, une entreprise doit détenir un compte sur le portail en ligne VMware Cloud (hébergé par AWS), puis souscrire au service VMware Disaster Recovery et, enfin, acheter l’option Ransomware Recovery.

À l’origine, seules les machines virtuelles en production sur site, via vSphere, ou exécutées par le service VMware Cloud d’AWS, pouvaient ainsi être sauvegardées et restaurées. À présent, ces fonctions s’appliquent aussi aux machines virtuelles qui sont exécutées sur le service VMware Cloud de GCP. VMware ne dit pas quand ces fonctions deviendront applicables aux VMs exécutées par le service VMware Cloud d’Azure. Toutefois, dans tous les cas, les restaurations se font pour l’heure exclusivement chez AWS.

D’ici à la fin de l’année, Ransomware Recovery bénéficiera en plus d’un nouveau système de fichier qui cloisonnera complètement les VMs ainsi restaurées du réseau infecté par une cyberattaque.

« Pour la suite, nous allons adapter notre système de fichiers pour que les restaurations soient possibles et imperméables dans d’autres clouds publics que celui d’AWS. Notre autre direction technique est de rendre plus productives les restaurations d’appoint, par exemple avec la mise en place de liens VPN pour permettre à différentes catégories d’utilisateurs de travailler », souffle, avec un certain mystère, John Gilmartin.

NSX+ pour unifier le réseau entre différents sites

Le but du moteur en ligne NSX+ est d’appliquer automatiquement le jeu de règles réseau d’un cluster source à toutes les répliques de ce cluster, qu’elles soient déployées sur un site distant comme dans un cloud, et que le cluster source soit composé de machines virtuelles, comme de containers.

« Nous faisons évoluer notre système de réseau virtuel NSX vers NSX+ pour simplifier le parcours de nos clients vers le multicloud. Les clients actuels de NSX peuvent facilement passer à NSX+ par le biais d’une mise à jour logicielle », explique Kit Colbert (tout à droite sur la photo), le directeur technique de VMware, entretenant quelque peu la confusion entre le service cloud NSX+ – que l’on acquiert par souscription – et le fait qu’il faille acheter la dernière version de NSX pour que le réseau virtuel d’un site interagisse avec NSX+. NSX+ correspond au projet anciennement évoqué sous le nom de NorthStar, lors des événements VMware Explore précédents.

NSX+ doit à terme être doté d’une console de supervision, baptisée NSX+ Intelligence, censée à la fois cartographier de manière très visuelle les déploiements de clusters vSphere sur plusieurs sites et mettre en exergue les failles, goulets d’étranglement et autres problèmes éventuels dont ils pourraient souffrir. NSX+ Intelligence proposerait des moyens de résoudre ces problèmes, sans toutefois le faire lui-même à la place des administrateurs réseau.

Pour l’heure, NSX+ s’attache à unifier les règles de routage, de droits d’accès et d’attribution d’ID au niveau de TCP/IP, pour les machines virtuelles et les containers. Kit Colbert laisse entendre que VMware planche sur une évolution de NSX+ qui prendra aussi en charge les réseaux Mesh des clusters Kubernetes, c’est-à-dire en gérant les API présentées par les containers.