Malgré tout le travail que nous avons consacré à VMware vSAN (contenu et tests), il peut paraître surprenant que nous n'ayons jamais utilisé vSAN en production. Le renouvellement de nos serveurs de laboratoire étant terminé (12 Dell EMC PowerEdge R740xd ), nous avons décidé de remédier à ce problème en réutilisant quelques serveurs PowerEdge R730 et des SSD supplémentaires dont nous disposions. Nous avons ainsi mis en place une configuration vSAN 6.6 modeste qui nous servira à héberger les machines virtuelles nécessaires aux tests, ainsi qu'à tester et à documenter les nouvelles fonctionnalités de vSAN. Ce déploiement soulève toutefois une question que se posent souvent les acheteurs de vSAN : comment migrer des charges de travail existantes vers vSAN ?
Comme dans la plupart des entreprises, notre stockage de laboratoire principal est un mélange de partages iSCSI et de stockage Fibre Channel, la plupart de nos données résidant sur des baies Dot Hill et un Fusion-io ION. Il existe différentes manières d'aborder cette migration, depuis le déplacement de machines virtuelles entre les magasins de données avec une commande SVMotion de base avec le stockage attaché localement à un hôte qui peut voir les deux magasins de données, ou une migration en deux étapes où l'hôte et le magasin de données changent.
Si vous avez une baie de stockage avec des LUN iSCSI, ce processus est assez simple. Ajoutez le périphérique de stockage iSCSI à l'un de vos hôtes vSAN si vous ne l'avez pas déjà fait, ajoutez la cible iSCSI à partir de votre baie de stockage et accédez rapidement à cette machine virtuelle à l'intérieur du cluster vSAN sans même avoir à migrer la banque de données pour le moment. Si vous disposez d'une baie de stockage qui communique via FC, vous pouvez soit tirer parti d'un HBA FC s'il en existe déjà un dans votre serveur, soit en ajouter un à l'hôte. Si le stockage FC ne sera pas beaucoup utilisé à l'avenir, le coût et les temps d'arrêt associés à l'installation du HBA pourraient ne pas en valoir la peine. Si tel est le cas, nous passons au processus en deux étapes.
Lorsque vous déplacez des machines virtuelles entre des hôtes ESXi où le calcul et le stockage changent dans le même mouvement, vous pouvez déplacer la machine virtuelle n'importe où dans votre environnement tant que les périphériques peuvent communiquer entre eux dans votre vCenter. C'est une option qui a le plus de compatibilité, mais peut ne pas être le chemin de transfert le plus rapide s'il en existe déjà un natif. Pour les machines virtuelles individuelles ou les petits groupes, cela peut ne pas poser de problème, mais avec des machines virtuelles assez volumineuses ou des lots volumineux, un chemin de transfert plus rapide peut être justifié.
Dans notre cas, nous pouvons voir que le transfert de la machine virtuelle n'a pris que quelques minutes, la liaison réseau 10G entre les deux hôtes aidant à pousser les vitesses jusqu'à environ 400 Mo/s. Dans l'ensemble, il s'agit de l'une des étapes les plus faciles associées à la mise en place et au fonctionnement de votre plate-forme vSAN, mais il existe plusieurs façons de l'aborder en fonction de vos besoins ou de vos capacités matérielles.
Dans cet article, nous avons longuement abordé la simplicité de la migration des VMDK VMware et des partages iSCSI existants vers vSAN. Dans toute organisation déjà virtualisée, ce processus est relativement simple. VMware propose également un outil pour les migrations bare metal ; nous avons utilisé VMware vCenter Converter pour virtualiser nos charges de travail existantes. Quelle que soit la méthode choisie, vSAN offre des gains considérables en termes d'efficacité opérationnelle et de réduction du coût total de possession (TCO) par rapport aux déploiements informatiques traditionnels. Nous sommes impatients de constater ces avantages dans notre laboratoire et de publier davantage de contenu basé sur des retours d'expérience concrets.
Amazon