4 votes

Recommandation pour une petite infrastructure VM redondante ?

Nous disposons actuellement d'un cluster actif-actif de 2 nœuds exécutant des machines virtuelles. Chaque nœud possède deux disques, chaque disque est mis en miroir DRBD sur l'autre nœud. Chaque nœud exécute des machines virtuelles à partir de son dispositif drbd primaire, et le cluster pacemaker gère le basculement (si un nœud tombe en panne, l'autre devient primaire sur les deux dispositifs drbd et exécute toutes les machines virtuelles). Ce système est hébergé dans un centre de données, de sorte que nos coûts (en dehors de l'acquisition de matériel) dépendent du nombre d'unités de rack que nous occupons.

Lorsque vous commencez petit, c'est une excellente solution, elle tient dans 2U d'espace rack (en supposant que le(s) commutateur(s) ethernet est/sont déjà là) et elle est 100% redondante. Mais c'est aussi une configuration légèrement difficile à gérer et elle souffre lorsque la charge d'E/S devient trop élevée (je suppose que c'est juste à cause du faible nombre de broches).

Je me demande quelle serait la meilleure solution pour dépasser la capacité de notre matériel tout en restant rentable et en étant aussi redondant que possible :

  • continuer en ajoutant d'autres clusters à deux nœuds avec stockage interne, peut-être avec du matériel plus important (par exemple, des serveurs 2U avec plus de disques).
  • Toujours utiliser des clusters à deux nœuds mais avec un stockage externe en attachement direct (des boîtiers de disques 1U ou 2U avec des liens SAS) - voir la note ci-dessous.
  • séparer le stockage et les VM (par exemple, une paire de nœuds de stockage, mis en miroir par DRBD, qui exportent iSCSI et gèrent le basculement en déplaçant l'IP cible iSCSI, couplée à deux ou plusieurs nœuds sans disque qui exécutent les VM à partir de l'IP cible iSCSI statique) - cela semble être ce que d'autres font ?
  • utiliser quelque chose de différent des serveurs standards pour la partie stockage (solutions de stockage dédiées sur gigabit ethernet ?)
  • Autre chose ?

La séparation du stockage et des serveurs d'application me semble être la solution la plus flexible et la plus raisonnable. Nous pourrions facilement ajouter des nœuds de stockage supplémentaires en cas de besoin et continuer à utiliser les serveurs d'application actuels ou faire l'inverse lorsque nous atteignons les limites de capacité.

Quels sont, selon vous, les bons / mauvais choix ? Avez-vous déjà de l'expérience sur ce genre de choses sans gros budgets (j'ai tendance à exclure la fibre channel ou les appliances de stockage à 10000 euros) ?

EDIT : Pour être clair, l'idée est qu'en exploitant les logiciels modernes (et libres), vous pourriez mettre en place une redondance en ajoutant simplement plus de matériel "de base". Cela ne va pas être très rapide ni à très haute disponibilité, mais cela permettra à notre VM de fonctionner même si une carte mère tombe en panne pendant le temps qu'il faut pour amener une pièce de rechange au DC et la remplacer.

EDIT : J'ai supprimé la mention usb parce qu'elle ne va vraiment nulle part (et merci de l'avoir signalé dans les réponses). Je ne sais pas vraiment comment j'ai pu oublier les boîtiers SAS. À titre d'exemple tiré du site Web de Dell, un MD1000 est 2U avec des liens SAS. Deux boîtiers reliés à deux nœuds de stockage via SAS et ils pouvaient faire de la redondance et exporter iSCSI.

0 votes

Si une réplication de site à site est nécessaire (je n'ai pas vu cela dans la question originale, mais @TheCompWiz l'a fait apparemment), faites-le moi savoir et je mettrai à jour ma réponse si nécessaire.

0 votes

Caractéristiques, temps et coût : Choisissez un deux ils déterminent l'autre. Vous voulez HA (fonctionnalité), pour bon marché (coût), les moyens n'arriveront pas de sitôt.

2voto

JohnMcG Points 5062

Tout d'abord, les disques USB ne vous donneront jamais de bonnes performances.

Vous semblez vouloir deux choses qui ne vont généralement pas ensemble. Une solution hautement disponible et entièrement redondante pour un coût minime ou nul. La redondance est coûteuse, surtout si vous voulez plus d'options. Dans le bas de gamme des solutions redondantes, vous disposez de petites solutions de stockage EMC, NetApp et Dell Equallogic. Elles prennent toutes en charge iSCSI et fiber channel, ce qui vous permet de vous y connecter comme bon vous semble. Elles commencent toutes par une taille de 4 à 5U et progressent ensuite. Elles vous offrent une bonne plateforme de stockage autour de laquelle vous pouvez ensuite construire votre cluster virtuel.

La réplication de stockage basée sur l'hôte à partir de disques internes d'une boîte vers des disques internes d'une autre boîte n'est pas extensible très longtemps. Le réseau finira par manquer de bande passante ou les disques ne seront plus capables de supporter la charge que vous leur imposez. Et la réplication double la charge sur les disques, car chaque écriture sur les disques doit être lue puis transférée à travers le réseau vers l'autre hôte pour y être écrite. Plus tout le trafic de battement de coeur qui doit se produire aussi.

Si l'entreprise a besoin de mettre en place une solution de haute disponibilité, elle doit vraiment prévoir de la payer. Les solutions bon marché ne fonctionneront pas longtemps et finiront par vous coûter cher.

0 votes

+1 - Amen ! Si vous avez besoin de serveurs entièrement redondants, cela va coûter $$$$. Il n'y a pas deux façons de le faire.

0 votes

Je suis plutôt à la recherche d'une solution "à prix raisonnable et raisonnablement redondante". J'ai modifié la question pour mieux le préciser.

0 votes

OK, alors les solutions Dell, EMC AX4, NetApp seront probablement votre meilleure option. Elles sont assez bon marché par rapport à d'autres options qui existent. D'autres sociétés plus petites proposent également des solutions, mais elles n'offrent pas toutes une redondance aussi importante.

2voto

Johnnie Odom Points 1199

Il faut absolument séparer les disques et les machines virtuelles, car vous souhaitez que les nœuds de machines virtuelles accèdent à un stockage partagé (plutôt qu'à des miroirs séparés) afin que les opérations de basculement soient pratiquement transparentes. Je déconseillerais le clustering au niveau du système d'exploitation en faveur du clustering au niveau de la machine virtuelle car, d'après mon expérience, les magasins de données ont tendance à être des points plus vulnérables que le matériel et le système d'exploitation (à condition que le système d'exploitation ait été configuré pour la stabilité) et les problèmes au niveau du système d'exploitation affectant un nœud d'un cluster ont tendance à se reporter sur l'autre nœud (mauvaises mises à jour, problèmes de réseau, etc. Les machines virtuelles devraient avoir des disques locaux pour faire fonctionner les hyperviseurs, mais les disques des machines virtuelles devraient être sur le stockage partagé (et vous voudrez que ce stockage partagé soit au moins en RAID5 matériel). Placer les machines virtuelles dans un cluster de ressources partagées (à la VMWare) est la meilleure solution, car elle vous permet d'effectuer un équilibrage de charge automatique très granulaire. Avec cette configuration, l'ajout de nouveau matériel à la configuration devient une question d'ajouter le nouveau serveur VM au disque partagé, de mettre l'hyperviseur dessus et de le joindre au cluster.

Je n'ai pas de recommandations sur le type de stockage partagé, car les personnes qui connaissent le monde du stockage partagé et des VM ont généralement de très bonnes données et je m'en remets à leur jugement.

0 votes

Que voulez-vous dire exactement quand vous parlez de clustering au niveau de la VM par rapport au clustering au niveau du système d'exploitation ? parlez-vous d'exposer deux périphériques de stockage non redondants et de laisser la VM faire du raid logiciel ? ou autre chose ?

1 votes

Je veux dire qu'au lieu de mettre en cluster le système d'exploitation pour faire du clustering de basculement sur deux nœuds, il serait préférable d'exécuter une machine virtuelle non clusterisée dans un ensemble de serveurs VM qui sont mis en cluster pour le partage des ressources (comme le DRS de VM Ware) de sorte qu'en cas de panne matérielle, les machines VM migrent automatiquement vers l'autre matériel.

0 votes

Si j'ai bien compris, c'est exactement ce que je fais depuis quelques années : Je migre les VM entre les nœuds - et je prévois de continuer à le faire. À titre d'exemple, ma configuration actuelle ressemble à ceci code.google.com/p/linux-ha-examples/wiki/XenActiveActive

0voto

TheCompWiz Points 7329

La seule façon d'obtenir une amélioration significative de l'IO entre les centres de données... est d'investir dans des quantités folles de bande passante dédiée entre les centres de données. Les systèmes de fichiers en grappe dépendent fortement d'une latence minimale et d'une bande passante élevée pour être performants. Quand il y a de la latence... le goulot d'étranglement IO est exponentiellement pire. (1-10ms c'est bien pas mal... 10-30ms c'est pas génial... 30ms+ c'est plutôt mauvais).

Il existe plusieurs façons d'atténuer une partie de ces frais généraux... en utilisant autre des méthodes de stockage... comme le stockage S3... ou un simple système de fichiers répliqués.

L'inconvénient est que parce qu'ils sont répliqués... si un côté met à jour un fichier presque en même temps que l'autre ou si un côté met à jour des fichiers trop fréquemment... vous vous retrouvez avec une réplication.... disjointe qui peut être un cauchemar à trier. Ces types de stockage sont excellents si vous faites des commits peu fréquents... et beaucoup de lectures.

Essayer d'implémenter des choses comme EBS... ou S3 d'Amazon à bas prix est au mieux improbable. Ils disposent d'un budget beaucoup plus important et d'ÉNORMES quantités de bande passante entre leurs ordinateurs pour jouer avec.

0 votes

L'OP ne pose pas de question sur le fonctionnement multi-datacenter ?

0 votes

Non, je ne parle pas de multi-DC. Cela ne serait certainement pas bon marché :)

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X