Pourquoi ne pas utiliser des choses qui ont été vérifiées par des milliers d'utilisateurs et qui ont prouvé leur fiabilité ? Vous pouvez simplement déployer un serveur Hyper-V gratuit avec, par exemple, StarWind VSAN Free et obtenir une véritable haute disponibilité sans aucun problème. Consultez ce manuel :https://www.starwindsoftware.com/resource-library/starwind-virtual-san- scénario-hyperconvergé-à-2-nœuds-avec-hyper-v-server-2016
J'ai une installation très similaire avec la configuration que vous avez décrite :un serveur KVM avec une réplique de secours via DRBD actif/passif. Pour avoir un système aussi simple que possible (et pour éviter tout split-brain automatique, c'est-à-dire dû au fait que mon client perturbe le réseau du cluster), j'ai également abandonné le basculement automatique du cluster.
Le système a plus de 5 ans et ne m'a jamais posé de problème. Ma configuration de volume est la suivante :
- un volume RAID dédié pour le stockage des VM ;
- un petit volume superposé contenant les fichiers de configuration QEMU/KVM ;
- des volumes plus importants pour les disques virtuels ;
- des ressources DRBD gérant l'ensemble du périphérique de bloc de baie dédié.
J'ai écrit quelques scripts shell pour m'aider en cas de basculement. Vous pouvez les trouver ici
Veuillez noter que le système a été conçu pour des performances maximales, même au détriment de fonctionnalités telles que des instantanés rapides et des disques virtuels basés sur des fichiers (plutôt que sur des volumes).
En reconstruisant une configuration active/passive similaire maintenant, je pencherais fortement vers l'utilisation de ZFS et de la réplication asynchrone continue via send/recv . Il ne s'agit pas d'une réplication en temps réel basée sur des blocs, mais elle est plus que suffisante pour plus de 90 % des cas.
Si la réplication en temps réel est vraiment nécessaire, j'utiliserais DRBD au-dessus d'un ZVOL + XFS ; J'ai testé une telle configuration + interrupteur de stimulateur automatique dans mon laboratoire avec une grande satisfaction, en fait. Si l'utilisation de modules tiers (comme ZoL l'est) n'est pas possible, j'utiliserais des ressources DRBD en plus d'un lvmthin volume + XFS.
Vous pouvez totalement configurer DRBD et l'utiliser de manière purement manuelle. Le processus ne devrait pas être complexe du tout. Vous feriez simplement ce que fait un cluster Pacemaker ou Rgmanager, mais à la main. Essentiellement :
- Arrêter la VM sur le nœud actif
- Rétrograder DRBD sur le nœud actif
- Promouvoir DRBD sur le nœud pair
- Démarrer la VM sur le nœud pair
Naturellement, cela nécessitera que les deux nœuds aient les packages appropriés installés, et que les configurations et la définition de la VM existent sur les deux nœuds.
Je peux assurer que la pile Linux HA (corosync et stimulateur cardiaque) est toujours activement développée et prise en charge. De nombreux guides sont anciens, le logiciel existe depuis 10 ans. Lorsque cela est fait correctement, il n'y a pas de problèmes ou de problèmes majeurs. Ce n'est pas abandonné, mais ce n'est plus "nouveau et passionnant".