Journal cluster linux

Posté par  .
Étiquettes : aucune
0
23
mar.
2004
Cher journal,

J'aurais besoin de tes connaisances, mais surtout de ton experience. Pourrais tu me conseiller sur une architecture de cluster (fail over uniquement, pas de répartition de charge) (plusieurs cluster à mettre en place, ftp, web, mail...)
Mon principal problème est le suivant : je ne peux utiliser de baie de disques partagée entre les différents noeuds de mes clusters (mon chef n'a pas encore gagné au lotto...). Un petit tour par Google et plusieurs solution s'offrent à moi afin de palier à mon problème :

- drbd
- nbd
- enbd

- d'autres propositions ?

Ce que je voudrais surtout savoir, c'est, en cas de crash d'un des noeuds du cluster, lequel de ces outils est le plus "efficace" (perte de données ? - synchro entre les noeuds ...).

Aurais tu déjà une experience sur ce sujet à me faire partager ?
  • # Re: cluster linux

    Posté par  . Évalué à 3.

    Cher Fouyaya,

    Je te conseille d'aller acheter le LinuxMag' Hors-Série n°18 sur la haute disponibilité dont on parle ici http://linuxfr.org/2004/03/17/15691.html(...)

    Ton journal qui t'aime
    • [^] # Re: cluster linux

      Posté par  . Évalué à 1.

      mon journal me dit de lire un journal ?! Je vais le faire des ce soir...

      Mais dans mon cas précis, j'aurais voulu avoir des retour d'experience... Je ne veux pas savoir comment ca marche quand ca marche bien (je sais lire une doc), je veux juste avoir des infos sur :
      si ca crash, tu perds (ou pas) une partie des donée, il te faut 1h ou 1 jour pour refaire une synchro de tes logs...

      Merci beaucoup toutefois pour ton info.
  • # Re: cluster linux

    Posté par  (site web personnel) . Évalué à 2.

    High-Availability Linux Project
    http://www.linux-ha.org/(...)
  • # Re: cluster linux

    Posté par  . Évalué à 0.

    Demande à Pierre Tramo, c'est lui le pro à ce niveau... Administrateur d'un cluster hétérogène de 3000 SuSE, non ?
  • # Solution cluster linux "progressive"

    Posté par  . Évalué à 2.

    Le linux mag' H.S cité ici http://linuxfr.org/comments/376813.html(...) fait effectivement un tour exhaustif de la question...

    De mon point de vue, la manière la plus fiable d'assurer une redondance reste de doubler tous les équipements et de synchroniser au travers d'un lien dédié (type fibre optique). Malheureusement, il n'y a pas de secret. Un seul obstacle mais de taille : le coût, d'autant plus si tu fais appel à des solutions matérielles dédiées/spécialisées...
    Mais avant cette extrême, il existe des possibilités plus accessibles.

    Quant à l'aspect de l'efficacité/coût, tu cites que tu "ne peux utiliser de baie de disques partagée entre les différents noeuds de mes clusters"...
    Dans tous les cas, cela ne résoud pas ton problème car la baie peut crasher et doit assurer elle aussi un minimum de redondance.

    Pour une solution "petit budget" que j'ai evoquée, je te conseillerai :
    + un stockage centralisé en RAID 1 minimum (0+1 ou 5 serait préférable) qui peuvent être envisagés en logiciel de façon triviale ou en matérielle (mais cela devient un poil moins accessible).
    ++ un serveur dédié robuste (minimum channel bonding avec 2-3 cartes réseaux -accessible-, éventuellement en Gigabyte -plus cher-, une alim redondante -abordable-)
    +++ des périphériques hotplug
    ++++ une baie externe (désolé mais on y vient) qui permettrait de switcher physiquement vers un serveur de secours en cas de crash du premier...

    Selon ton budget, tu peux donc monter progressivement en charges et en moyens du RAID logiciel 1 avec de l'IDE jusqu'au RAID 0+1/5 matériel en SCSI/SATA hot-plug.
    Tout dépend étroitement du duo budget/continuité de service.

    En ce qui me concerne, une solution budget mini consiste à avoir un serveur "lourd" en RAID logiciel 0 (2x2 disques IDE de données web, mail, nfs/samba) + disques systèmes et un serveur "léger" partiellement synchronisé qui assure des services restreints en cas d'indisponibilité (mail + web) le temps de la réparation.
    Le switch se réalise en 2s en reconfigurant le DNS si un problème survient mais cela nécessite une intervention humaine (bien que cela puisse être automatisé avec une surveillance + remontée d'alerte)...
    Pour la petite histoire, cette solution a déjà fait ses preuves pour une défaillance du serveur ou pour ses périodes de maintenance mais il y a deux jours, c'est le modem ADSL qui a lâché... et je n'avais pas prévu ce cas. Trop injuste...
    • [^] # Re: Solution cluster linux "progressive"

      Posté par  . Évalué à 1.

      Juste pour préciser : ce que je propose ici n'offre pas une solution cluster à proprement parlé bien mais, dans le cadre d'un budget restreint, je ne vois pas trop l'intérêt de répartir sur plusieurs noeuds des données uniquement pour prévenir une défaillance matérielle (dans le cadre d'une répartition de charges, cela aurait été différent).
      A mon sens, il vaut mieux "sécuriser" le serveur qui deviendra potentiellement un noeud par la suite puis passer à une redondance distribuée type cluster (dupliquer les serveurs distribués)...
      Une solution "cluster" à priori s'adresse à plutôt à des budgets plus importants.
      • [^] # Re: Solution cluster linux "progressive"

        Posté par  . Évalué à 1.

        Merci de ta réponse.

        Pour mon cas, disons que l'interruption de service (mail, ftp et web) ne _doit_ plus avoir lieu (=> cluster fail over).
        J'aurais donc une "grosse" machine (raid 5 hard - scsi + hot spare quivabien et carte reseau redondante avec ) et une plus petite machine qui devrra prendre le relais si la première tombe (ou si la première est en cours de maintenance). La qualité de service serait un peu amoindrit, mais il n'y aurait plus de coupure de service. Le seul hic, c'est que des petites machines, on en a, les gros serveurs de prod sont deja bien étudier, mais ya pu de sous pour les baies :'(

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.