Quel est le meilleur design (logiciel / matériel, sauvegardes) pour deux servers fournissant des machines virtuelles en colo

J'ai actuellement un ancien server qui fournit des machines virtuelles utilisant Xen sur CentOS. Bien qu'il ne s'agisse pas d'un monstre, il prend en charge les extensions VT et dispose d'une configuration matérielle RAID1 de 1 To configurée. Je cherche à append un autre server plus récent, en gardant l'ancien pour les sauvegardes mutuelles et, potentiellement, pour dissortingbuer la charge de travail.

Jusqu'à présent, les suggestions ont impliqué des SAN ou d'autres types d'ajouts de matériel coûteux que je ne peux pas me permettre. Donc, count tenu du matériel, des objectives opérationnels et des contraintes, quel est le meilleur design? (qui minimise les coûts et les time d'arrêt et maximise la disponibilité, la performance et la stabilité)

Matériel

  • Serveur Poweredge 850 1U avec 8 Go de RAM, support CPU VT et 1TB RAID1
  • Serveur supplémentaire
    • pas encore acheté, donc c'est flexible – pensez less de 3000 $
    • en considérant un R410 avec double quad xeons, 16 Go de RAM et 4x1TB SATA dans RAID5 pour 2.8TB

Exigences opérationnelles

  • Les servers doivent fournir des machines virtuelles
    • Utilisation actuelle de Xen sur CentOS 5
    • Regardé Cisortingx XenServer, VMware Server et ESXi, KVM, sans tête VirtualBox
  • Le server plus récent et plus puissant devrait probablement être le «principal», héberger des machines virtuelles qui font toutes sortes de choses, y compris le service Web et de messagerie
  • Le but de l'obtention d'un 2ème server est d'get une redondance – si quelque chose arrive à l'un, l'autre peut prendre le relais pendant un certain time (pensez à l'alimentation soufflée et au timeout de garantie sur place pour le prochain jour)
  • Lorsqu'une sauvegarde de la VM est sauvegardée, elle doit être disponible en continu ou le time d'arrêt devrait être négligeable (c.-à-d., Le time nécessaire pour mettre en pause, démarrer instantané / clone / copyr, dépanner)

Contraintes et considérations

  • Je ne suis intéressé que par des solutions gratuites (open source préféré, mais pas ssortingctement requirejs)
  • L'espace au colo est facturé par U, donc l'ajout de 1U est préférable sur les servers plus grands. Un matériel plus grand ne sera considéré que si la solution est particulièrement résistante.
  • Le nombre de machines virtuelles et la taille de leurs disques rendent impossible le transfert hors site régulièrement sur Internet en raison des coûts de bande passante
  • Les deux servers peuvent être mis en réseau directement set, donc les transferts entre eux sont très rapides et ne coûtent rien
  • La garantie sur le server ancien est payée pendant 2 ans et ça marche bien, alors ne le remplacez pas inutilement (les solutions réellement superbes, qui incluent le rlocation de l'ancien server, seraient logiques pour nous)
  • Ne considérant pas vraiment une solution de stockage au lieu d'un 2ème server car un server doit pouvoir prendre le relais pour l'autre si quelque chose devait arriver. Si j'ai seulement un server et une solution de stockage, j'ai 2 points d'échec au lieu de 1.

Recherche précédente

  • La version Xen fournie avec CentOS (et sur la plupart des dissortingbutions de dom0) est assez ancienne et crue
  • Expérience actuelle avec Xen
    • Les disques VM conservent des volumes logiques
    • dd est lent et comprend également de l'espace libre
    • Le assembly du système de files dans dom0 et rsyncing nécessite que dom0 connaisse la disposition FS du dom, et qu'il soit vraiment très difficile si le domU utilise également LVM. Difficile à automatiser et ne nécessite pas nécessairement une image rapidement réutilisable sur le 2ème server.
    • L'instantané LVM -> sauvegarde -> supprimer le process d'instantané permet aux machines virtuelles d'être disponibles lors de sauvegardes incrémentielles. Grand plus!
  • Cisortingx XenServer
    • Il est plus facile de regrouper les ressources, mais nécessite un stockage partagé et les processeurs sont fondamentalement les mêmes. À less d'avoir un autre ancien server correspondant à mon ancien server actuel, je ne satisfais pas aux exigences de XenMotion.
    • Je ne sais pas si XenMotion fonctionne vraiment pour les sauvegardes de toute façon. Je comprends que, une fois que la machine virtuelle migre, elle a été déplacée, non copiée, vers l'autre server.
    • Snapshot + export instantané semble prometteur .
  • Le transfert de VMware VM entre les hyperviseurs en cours nécessite le paiement de la vmotion
    • encore une fois, vmotion n'est probablement pas destiné à des sauvegardes
  • KVM est la solution dont je connais le less, mais semble être très similaire à Xen en ce qui concerne la façon dont elle gère le stockage: files d'image locaux, volumes logiques ou SAN / iSCSI partagés

Phew! Merci d'avance pour vos commentaires! Faites-moi savoir si vous avez besoin de plus d'informations: P

Vous pouvez configurer DRBD entre les deux servers pour héberger les images VM et les files de configuration.

Je crois que cette configuration permettra la migration en direct entre les deux hôtes. Si ce n'est pas, il devrait vous permettre de commencer une machine virtuelle sur l'un ou l'autre server, si l'un d'entre eux devait tomber. Cela pourrait être automatisé un peu en utilisant des battements cardiaques pour exécuter des scripts pour redémarrer les VM si l'un des hôtes est en panne. Cet article semble le faire avec la migration en direct et LVM.

Nous avons un cluster à deux nœuds construit il y a environ un an avec CentOS 5.2, Xen 3.2, LVM et DRBD 8.2.6 … J'ai utilisé ce mode d'emploi comme guide pour configurer tout, même si le guide lui-même est pour Ubuntu Hardy, mais le support Xen de CentOS est beaucoup plus stable IMO.