La virtualisation pour la résilience matérielle?

Quelqu'un peut-il me dire s'il est possible de regrouper plusieurs serveurs physiques pour exécuter un environnement de virtualisation résilient. Nos serveurs deviennent de plus en plus critiques pour nos clients et nous voulons faire tout notre possible pour améliorer la résilience en cas de panne matérielle. J'ai utilisé des machines virtuelles de bureau, mais je ne connais pas ce qui est possible dans les machines virtuelles de niveau entreprise.

L'idéal serait d'avoir quelques serveurs physiques dans notre datacenter. Certaines machines virtuelles seraient partagées entre elles pour exécuter un serveur Web, un serveur d'applications et un serveur de base de données. Si un serveur physique a échoué, les machines virtuelles doivent passer à l'un des autres serveurs et continuer à fonctionner sans aucune interruption.

Cela peut-il être accompli? Je me rends compte que même Google baisse de temps en temps, alors je ne cherche pas la perfection; Juste une solution optimale.

Cela peut être fait, et nous faisons quelque chose de similaire, juste sans la partie automatique.

Comme l'a indiqué Allen, la clé a un pool de stockage partagé qui est visible pour plusieurs serveurs hôtes, donc, si un hôte descend, cela n'a pas beaucoup d'importance, car un autre hôte peut prendre la relève. La mise en place du type de basculement automatique sans interruption et sans interruption dont vous posez la question n'est pas facile (ou pas cher), et franchement beaucoup plus de problèmes que cela vaut, du moins pour la grande majorité des cas d'utilisation. Le matériel moderne ne manque pas beaucoup, à moins qu'il ne soit bien configuré, de sorte que vous obtiendrez plus de kilométrage pour vous assurer qu'il est bien configuré et dans un environnement qui se trouve dans les gammes opérationnelles de l'équipement.

Nous utilisons les fonctions de fail-over et haute disponibilité de nos systèmes pour seulement deux choses, vraiment. Le premier est en cas de reprise après sinistre (si notre site principal perd de l'électricité ou fait exploser, ou ce que vous avez, les parties critiques sont reflétées dans une deuxième installation) et la seconde consiste à éviter les fenêtres de maintenance. Nous utilisons les serveurs lames et ESX / vSphere et entre avoir la possibilité d'échouer sur un site secondaire et la facilité d'utilisation de vMotion pour déplacer les machines virtuelles entre les hôtes, il y a très peu de choses que nous ne pouvons pas faire sans interruption du service.

Je voudrais me concentrer sur la mise en place d'abord – une fois que vous êtes capable (manuellement) d'échouer des choses partout, vous pouvez décider que le fait de fonctionner automatiquement est plus coûteux et difficile que sa valeur. Cela semble assez simple et génial en théorie, mais dans la pratique, il peut y avoir une véritable douleur pour que tout fonctionne correctement dans des grappes ou dans un système d'invité distribué.

C'est une excellente raison de virtualiser. Comme la disponibilité de l'application, plutôt que le temps de disponibilité individuel (physique) du serveur, devient plus important pour les entreprises, de nombreuses organisations trouvent qu'elles peuvent atteindre un niveau de fiabilité plus élevé grâce à la virtualisation.

J'utiliserai VMWare et Xen comme exemples, mais avec une forme de stockage partagé visible pour deux ou plusieurs systèmes hôtes, les invités virtualisés peuvent être distribués et équilibrés en charge sur les serveurs physiques. L'accent commence à être la qualité de la solution de stockage partagé, de la gestion et des réseaux / interconnexions dans l'environnement.

Cependant, un peu de prudence … Vous devriez évaluer quel type de matériel et situations environnementales constituent une menace. L'équipement de classe de serveur de qualité comprend de nombreuses redondances (ventilateurs, blocs d'alimentation, RAID, même RAM) … Le matériel moderne échoue souvent souvent. Évitez ainsi de réagir de manière excessive en créant un environnement inutilement complexe si les serveurs haut de gamme pourraient aider à éliminer 90% des problèmes potentiels.

Il semble que VMware FT pourrait être ce que vous recherchez. Il conserve une "instance d'ombre" de chaque machine virtuelle en mode verrouillage avec chaque source VM et permet un basculement instantané entre les deux instances. Plus ici:

http://www.vmware.com/products/fault-tolerance/overview.html

La partie de l'interruption est tout à fait une question, spécialement, aujourd'hui, vous allez de ce qui semble être des serveurs standard sans résilience?

La virtualisation est une option mais, dans l'intérêt de la divulgation complète, vous devez prendre une décision éclairée entre les éléments suivants,

  1. Petite interruption , de l'ordre de quelques minutes .
  2. Pas d'interruption (nous parlons de milles-secondes ).

(2) est normalement très,

  1. Cher , vous avez besoin de la capacité matérielle N + N. C'est-à-dire pour chaque serveur que vous exécutez, vous disposez d'un serveur de veille complet exécutant le même logiciel prêt à prendre en charge en cas de panne matérielle .
  2. Restrictif : le logiciel que vous utilisez pour cela garantit que les machines sont "en synchronisation", normalement par Ethernet. Cela signifie que si votre réseau ralentit, cela ralentira votre application afin de s'assurer que les choses restent dans le verrou. Pour s'assurer que cela ne se produit pas, ces machines doivent être dans le même Datacentre pour obtenir tout type de performance.

La virtualisation avec VMware-FT est en solution. Xen a son équivalent avec everRun, et il y a l'équivalent en métal nu (sans hyperviseur).

(1) peut bien être tout ce dont vous avez besoin ( regroupement )

  1. Selon l'application, cela peut offrir un échec égal à (2). Par exemple, les serveurs NFS comme NetApp peuvent offrir un basculement sans échec, et les clients continuent sans échecs et seulement une brève interruption.
  2. "Légèrement" plus tolérant pour les pannes de logiciels. Étant donné qu'aucune instruction CPU déterministe n'est en cours de mise en service, un certain nombre de bogues comme les conditions de course ne seront pas déclenchés.
  3. Peut vous permettre d'exécuter différentes versions du logiciel. Par exemple, la mise à niveau du nœud 1 du cluster au service pack 1 de Windows Server 2008, confirmez son ok, mettez le noeud 2 sur le Service Pack de Windows Server 2008.

Je ne veux pas vendre de clustering contre tolérance de panne, ni de métal nu contre hyperviseur, mais quand il s'agit de High Availability espérons que ce qui précède illustre un grand nombre de questions que vous devez répondre d'abord avant de l'implémenter.

  1. Quel est le temps d'arrêt maximal toléré par les utilisateurs (être réaliste)
  2. Quels sont les domaines de panne que vous tolérerez? Serveur physique? Logiciel? Réseau de couche 2? Couche 3? Centre de données?
  3. Quelles sont les exigences de performance de la demande? La virtualisation n'est pas pour tout, et très récemment, les applications sensibles à l'horloge comme Active Directory ont été complétées par des machines virtuelles (et ce n'est certes pas une pratique courante). Que vous utilisiez ou non l'hyperviseur et les chipsets, la virtualisation signifie toujours un succès sur la performance, le débit et la latence.
  4. Budget auquel vous devez travailler.

Ces exigences peuvent être traduites par des choses comme MTTF, et selon le budget et les compétences de votre équipe, certaines solutions seront tout simplement un non-aller.