RAID logiciel sous le datastore ESXi

ESXi n'est pas un système d'exploitation polyvalent et ne doit pas être considéré comme tel. Respectez absolument la liste de compatibilité matérielle et utilisez donc un adaptateur RAID matériel testé et approuvé. Si vous choisissez de faire autre chose, vous rejoindrez les nombreux autres utilisateurs qui prennent des raccourcis et reviennent ici en se plaignant que leurs systèmes ne fonctionnent pas ou qu'ils ont perdu des données - nous en recevons BEAUCOUP.

Cela semble un peu détourné, ai-je de meilleures options ?

Votre idée générale est très juste. Je suggérerais personnellement d'utiliser ZFS avec Solaris ou FreeBSD, mais mdadm pourrait également fonctionner. Cependant, vous n'obtiendrez peut-être pas tous les avantages dont je parle dans cet article, alors prenez cela comme un avertissement. Cet article sera assez long, je m'excuse par avance pour le mur de texte.

D'après mes recherches, le passage semble présenter de nombreux inconvénients, comme l'absence de suspension/reprise, etc.

Il y en a, notamment :

1. Ne fonctionne qu'avec le support vt-d (ou AMD IOMMU) sur le CPU (Intel) ou CPU+carte (AMD) : pas de problème, il est difficile d'obtenir un serveur sans cela aujourd'hui, car tous les CPU Intel sauf les Atoms l'ont (même dans les systèmes de base de HP, Dell et autres).
2. Il n'est pas possible de créer des instantanés VMware de toutes les VM avec des éléments passés : En théorie, c'est un problème, mais cela n'affecte que votre VM de stockage, dont la configuration est minimale et qui n'est utilisée que pour cela. Vous pouvez effectuer vos snapshots au niveau du stockage, où ils sont plus rapides, moins chers et ne ralentissent pas le système. En outre, vous pouvez faire des instantanés de toutes les autres VM sur l'hôte sans problème (et même les combiner avec des instantanés de système de fichiers pour des options de restauration puissantes et un archivage à long terme des états).
3. Votre complexité interne est accrue dans certains domaines : À première vue, c'est vrai - vous ajoutez une couche supplémentaire et vous devez gérer plus de choses, comme votre nouveau SAN interne (configuration réseau/VLAN dans VMware) ou votre VM de stockage elle-même (mises à jour, etc.). Mais d'un autre côté, vous bénéficiez également de la simplicité et de la flexibilité :
   • Des sauvegardes cohérentes des machines virtuelles en cours d'exécution peuvent être créées automatiquement avec quelques scripts simples et sont totalement gratuites. Elles peuvent également être stockées sur une autre machine, un disque ou un nuage (crypté), le tout sans solutions logicielles supplémentaires coûteuses.
   • En cas de décès de votre serveur, il vous suffit d'acheter un autre serveur de remplacement prêt à l'emploi, d'installer ESXi, d'activer le passthrough, de configurer votre réseau, d'ajouter vos disques et de démarrer votre VM de stockage. Une fois le système en place, scannez à nouveau votre stockage et c'est comme s'il n'y avait eu qu'une panne de courant, toutes vos données sont en sécurité et vous le savez (au lieu de cela avec le RAID HW, vous espérez qu'elles le soient).
   • Les exigences particulières peuvent être satisfaites avec un minimum de modifications en cas de besoin. L'entreprise possède une ancienne application qui nécessite des disques locaux pour les sauvegardes ? Il suffit de configurer iSCSI et de présenter votre stockage de manière transparente. L'entreprise connaît une croissance et a besoin de plus de stockage ? Il suffit d'augmenter le pool avec plus de disques et de les présenter soit directement sur iSCSI, soit via VMware (NFS ou iSCSI avec vmdk par-dessus). Ils veulent utiliser une base de données sur un serveur séparé et puissant ? Ouvrez simplement votre NFS sur un autre LAN/VLAN et fournissez-le au nouveau serveur comme un "vrai" SAN.
4. Le GPU passthrough ne fonctionne que pour les cartes Nvidia coûteuses et toutes les cartes AMD : C'est actuellement vrai, mais votre VM de stockage n'a de toute façon pas besoin d'un GPU dédié.

Il existe également des désagréments d'ordre général qui ne sont pas liés au passage :

1. Pour redémarrer la VM de stockage, toutes les autres VM qui en dépendent doivent d'abord être arrêtées : Ce problème évident est rarement évoqué, mais à mes yeux, il est le plus gênant. Bien sûr, les mises à jour d'ESXi lui-même nécessitent également un redémarrage complet, mais comme vous avez maintenant deux systèmes, les temps peuvent ne pas se synchroniser parfaitement. Je recommande d'utiliser un système d'exploitation stable et d'aligner les mises à jour non critiques entre les deux systèmes. En outre, vous devriez limiter la VM de stockage à son propre réseau local virtuel interne, ce qui réduit encore la nécessité d'appliquer les correctifs dès qu'ils sont publiés. Notez que cela s'applique également aux redémarrages accidentels de la VM de stockage à partir de l'interface graphique.
2. Les erreurs dans la pile sous-jacente rendent toute votre machine inopérante : Ce risque est accru par rapport à ESXi uniquement, car vous avez maintenant deux systèmes et deux piles de réseau entre eux. Du bon côté des choses, votre VM de stockage et ESXi devraient normalement être stables et les erreurs devraient être rares. Néanmoins, je conseille de planifier les mises à jour quelques jours/semaines après la sortie de la version afin de voir si d'autres personnes ont rencontré des problèmes. D'un autre côté, le fait de ne pas modifier la configuration signifie qu'elle est très stable, ce qui est un plus pour les PME (moins de support nécessaire).
3. La solution n'est pas connue du personnel d'assistance tiers : Il s'agit d'une configuration assez rare, de sorte que la probabilité que votre remplaçant aléatoire puisse la comprendre sans votre documentation dès le départ est faible - cela peut être un problème ou un avantage, en fonction de vos objectifs commerciaux. Ce problème peut être atténué par une documentation de base expliquant la structure de la configuration (utilisez des images/diagrammes !), la comparaison avec une configuration RAID traditionnelle et ce qu'il faut faire dans les cas de problèmes courants (sauvegarde, restauration, remplacement de disque, mises à jour, changements de réseau, expansion matérielle).

Au-delà des questions techniques, vous devez réfléchir à vos objectifs et aux moyens de les atteindre. Cela détermine la faisabilité de la solution que vous avez choisie, ses avantages et ses inconvénients, ainsi que votre résultat global (succès ou échec). Cela dépend en grande partie des besoins de l'entreprise elle-même. Quelques considérations pour ou contre la solution que vous proposez du point de vue de l'entreprise :

• Budget : Certaines entreprises peuvent justifier de payer plusieurs milliers de dollars par an pour un contrat d'assistance qui n'est presque jamais utilisé, car la seule fois où il l'est, il a beaucoup plus de valeur pour elles. D'autres entreprises ne peuvent payer que pour une valeur immédiate, et peuvent faire face à des temps d'arrêt inattendus de manière peu coûteuse et flexible, de sorte que l'argent serait gaspillé.
• Exigences de sécurité : Il existe des entreprises pour lesquelles un seul fichier détruit ou endommagé datant de 10 ans n'est pas envisageable, et d'autres pour lesquelles même une perte complète de toutes les données actuelles n'est qu'un inconvénient. Les besoins en matière de sauvegardes, d'instantanés, etc. changent en fonction de cela.
• Structure de soutien : Il y a des entreprises qui veulent acheter une machine, la configurer et l'utiliser (virtuellement) pour toujours sans aucun besoin de support, et d'autres qui veulent et ont besoin de changements continus, de mises à jour et de support direct de la part de personnes de confiance.
• Exigences de flexibilité : Certaines entreprises évoluent si rapidement que vous ne pourriez pas prévoir leurs besoins à l'avance, ce qui peut ou non constituer un argument en faveur d'une configuration plus souple. D'un autre côté, il y a celles qui ne changent jamais et qui privilégient la stabilité et la prévisibilité par-dessus tout.

Vous devez en tout cas garder ces points à l'esprit. Votre solution ne peut réussir que si vous atteignez les objectifs, peu importe le choix de la majorité, mais seulement ce qui est a) techniquement possible à mettre en œuvre, b) dans le cadre du budget, c) répondant aux objectifs de l'entreprise. Si tous ces points sont remplis et que vous devez encore décider, choisissez la solution la plus facile/moins compliquée (KISS). Si elles sont aussi faciles l'une que l'autre, choisissez celle qui vous apporte le plus d'argent et/ou de bonheur.

Consultez ce blog pour un exemple d'utilisation de ZFS comme magasin de sauvegarde. http://blog.laspina.ca/ubiquitous/encapsulating-vt-d-accelerated-zfs-storage-within-esxi

Cela dit, les avertissements concernant l'utilisation de matériel standard sont valables. ESXi est assez pointilleux.

" Je souhaite naturellement que le datastore soit tolérant aux pannes, mais je ne peux pas obtenir les fonds nécessaires pour une machine de stockage séparée, ni pour des solutions RAID matériel coûteux, j'aimerais donc utiliser un RAID logiciel (lvm/mdadm, probablement). probablement). Comment cela peut-il être mis en œuvre ?

esxi ne fonctionnera pas sans un RAID HW réel pour le Datastore. . Même le logiciel de raid basé sur le BIOS ne fonctionnera pas.

I run a HW backed 2x1TB SSD datastore for VMS

J'ai eu mon contrôleur raid Adaptec 6405e pour 100$ sur Ebay !

MAIS en ce qui concerne la partie suivante,

Ma seule idée jusqu'à présent serait de créer une VM qui a l'adaptateur de stockage en tant que passthrough, met un certain RAID logiciel sur les disques, puis présente les volumes résultants à l'hôte ESXi qui volumes résultants à l'hôte ESXi qui crée ensuite un datastore à partir duquel les à partir duquel d'autres VMs obtiennent leur stockage présenté".

Mon "FileServer" se compose de Disques durs de 4x5TB transmis directement à une VM . J'ai ensuite construit mdadm Raid 5 pour un total d'environ 14TB et exporté par NFS à tous mes VM's. Environ 15/20 à tout moment, avec 10/20 VM de développement qui sont éteintes à moins d'être utilisées. Cela a bien fonctionné pour moi, mais ce n'est pas avec un grand groupe d'utilisateurs. En fait, je suis vraiment le seul utilisateur local, mais j'héberge des sites Web qui génèrent un certain trafic, mais encore une fois, ils sont essentiellement statiques.

Une bonne question à poser dans ce scénario, si vous envisagez d'utiliser cette idée, est la suivante : à quoi sert le serveur de fichiers ?

Dans mon cas, 90% de mes VM, si ce n'est toutes, hébergent toutes les données nécessaires à l'intérieur de la VM (linux) et ont une taille inférieure à 20 Go. J'utilise le serveur de fichiers comme répertoire central pour les sauvegardes, et toutes les applications multimédia comme Plex lisent à partir du serveur de fichiers, et mon P2P enregistre directement sur le serveur de fichiers, mais aucun de mes hôtes n'a de base de données ou quoi que ce soit qui réside sur le serveur de fichiers. Ils font cependant toutes leurs sauvegardes sur le serveur de fichiers. Mon serveur de fichiers est ma seule VM qui héberge deux services, à savoir NFS pour les VM et SMB pour l'accès Windows via l'interface graphique. Cela a merveilleusement bien fonctionné pour moi. J'ai également monté le serveur de fichiers via NFS en tant que datastore et je peux monter des ISO sur de nouvelles VM à partir du datastore. Je sauvegarde également les snapshopts OVA via SMB dans Windows directement sur le serveur de fichiers. Exécuter des VM sur un raid logiciel NFS exporté serait fou, mais exporter un grand datastore NFS vers l'hôte esXi a de nombreux avantages.

La prise en charge du RAID logiciel existe dans ESXi pour le contrôleur Dynamic Smart Array de HPE. Je l'utilise sur un DL20 g9 avec des SSD Enterprise en miroir et cela fonctionne très bien.

http://www8.hp.com/us/en/products/servers/solutions.html?compURI=1499005#tab=TAB4

Cela dit, je viens d'acheter un Smart Array 440 sur eBay pour 200 $, qui est un RAID matériel sans autre raison que de toujours choisir le matériel quand on a le choix.