Journal HA & FS

Posté par  .
Étiquettes : aucune
0
17
jan.
2007
Bonjour,

Suite à mon journal d'hier [1] (et dans la même direction que celui la [2]) je continue mes recherches sur certaines solutions techniques pour la Haute Disponibilités.

Mon rêve:

Un système de fichier capable de répartir la charge sur plusieurs machines pour mutualiser l'espace dispo tout en permettant des fonctionnalités de type RAID 5 quand à la disponibilité si un membre du groupe est indisponible. Ce serait bien évidement en sacrifiant une partie de l'espace disque pour le fonctionnement, mais cette contrainte n'est pas un problème. De plus, lors de l'ajout d'une machine, le rééquilibrage de l'utlisation se ferait automatiquement (ou partiellement) pour libérer de l'espace disque sur les autres système, ajouter de l'espace disque supplémentaire globalement et toujours remplir les fonctionnalités d'intégrité.

J'ai trouvé la définition d'un tel système, à la fois distribué et tolérant aux pannes: "Distributed parallel fault tolerant file systems" [3].

A la différence des autres catégories que l'on trouve sur la page [3], celle ci comporte beaucoup de solutions propriétaires ou encore en developpement.

Bien qu'il y en ai une Open Source, Gfarm [4], j'ai le sentiment qu'elle est plus une grosse usine pour les scientifiques, qu'un outil pour mon projet.

J'ai parcouru la plupart des FS détaillés sur Wikipedia [3], sans réellement trouver mon bonheur. J'ai l'impression que Gfarm est une grosse usine pour ce que je souhaite faire.

Alors est ce que j'ai raté quelque chose dans Coda ? AFS ? etc... ?

Connaissez vous ou avez vous utilisez un tel systeme de fichier ?

Tout retour d'expérience est le bienvenue.

Merci.

* [1]: https://linuxfr.org/~DjinnS/23538.html
* [2]: http://linuxfr.org/forums/10/18373.html
* [3]: http://en.wikipedia.org/wiki/List_of_file_systems
* [4]: http://datafarm.apgrid.org/

  • # SAN ?

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

    Quels sont tes besoins au juste ? Pourquoi n'utiliserais-tu pas un SAN ?

    http://en.wikipedia.org/wiki/Storage_area_network
    http://fr.wikipedia.org/wiki/Storage_Area_Network

    À l'intérieur du SAN, tu fous tes disques en RAIDx, avec x = 0, 1, 5 ou 10 ; dans tes bécanes, tu fous un double attachement au SAN par des HBA en failover et load-balancing ; et entre les deux tu fous un zouli switch...

    • [^] # Re: SAN ?

      Posté par  . Évalué à 1.

      Oui ! J'ai oublié de parler de cette solution.

      En effet c'est une possibilité. Mais elle représente un coup trop important, même avec un SAN/NAS "maison". L'évolutivité n'est pas "top". Une fois les baies de disques pleines ... rajouter des disques dans les baies existantes, sur les volumes existants ... tout ceci est tres contraignant (période de maintenance, etc ...)

      Le systeme que j'ai décris peut être vu comme les "blade" d'IBM mais pour du stockage (et par réellement pour la puissance).

      La ou le système que je décris est "balaise" c'est que c'est parfait en terme d'évolution. Achat du machine, installation basique et ajout a l'archi. Le systeme fait le reste pour rendre la machine opérationnel.

      Je suis conscient que ce système n'existe peut être pas car il est relativement complexe. J'ai vu des choses similaire chez Sun, IBM & Co mais c'est largement au dessus des moyens du projet, et sans doute démesuré pour ce qu'il faut faire au final.

      Ma problématique est purement de type stockage: trouver à la fois un systeme évolutif et qui partage les données entre les machines pour délivrer le même contenu sur chaque machine (webfarm).

      • [^] # Re: SAN ? / Solution avec SVC

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

        Concernant le stockage, il y a plusieurs approches qui répondent à plusieurs besoin.

        Ton besoin apporte de fortes contraintes en terme de répartition I/O.

        IBM offre une solution qui s'appele SVC (SAN Volume Controller): http://www-5.ibm.com/storage/europe/fr/software/virtualization/svc/

        Cette solution permet d'ajouter une couche qui va caché/absorbé les flux et demande en I/O. De plus, tu peux ajouter des volumes aux volumes existants.

        C'est une solution extrêmement intéressante en terme d'évolutivité et de performances:
        - migration de volumes entre baies de stockage à chaud
        - différents niveaux de performances selon les baies de stockage
        - augmenter les volumes à la volée
        - augmenter les I/O avec l'ajout du nouveau noeud SVC

        Le SVC est une solution en cluster(sous Linux) qui a un certain coût mais qui a un réel interêt pour beaucoup d'entreprises voir des PME-PMI.

        • [^] # Re: SAN ? / Solution avec SVC

          Posté par  . Évalué à 1.

          Il existe aussi IPStor de la société FalconStor, concurrent de SVC. À toi de comparer, mais je pense que tu vas préférer IPStor.
          En gros, tu peux attacher du SAN, du NAS, peu importe le protocole (FC,iSCSI, DA, Infiniband, ...)
          Le soft s'installe sur un Linux.

      • [^] # Re: SAN ?

        Posté par  . Évalué à 2.

        solaris avec du zfs qui fait du nas, et un san en ata over ethernet [1] (pour pallier au manque de place sur une seule machine ;)
        L'intéret du AoE est que c'est un protocole léger, et qui doit etre utilisé que dans un point de vue local.

        rajouter du stockage : il suffit de rajouter un ordinateur avec n disques , qui les exportent aoe (ou un rack qui le fait).
        Les outils d'administrations de zfs permettent cela sans trop de probleme
        (zpool add ton_pool_de_stockage mirror|raidz|raidz2| tes_disques
        Cela t'ajoutera tes volumes en mirror|raid... directement (sa,s temps d'attente et autre). (le principe est en gros d'avoir une sorte de raid1 , et en dessous un systeme hétérogene (donc raid0 , équivalent raid5 ou 6 , ...) de taille variable

        Par contre ce qui est de la redondance ou du fail over si le serveur nas tombe en rade, ou pour faire du loadbalancing, je sais pas trop :'(
        les suncluster 3.2 [2] sont censés proposé cette solution avec du HA-ZFS , mais je sais pas si ce dernier sera proposé dans opensolaris :'(

        Et le principal problème dans ce genre d'architecture c'est le réseau qu'il y a derrière, il faut qu'il soit bien dimenssionné toussa ;)


        [1]:http://en.wikipedia.org/wiki/ATA_over_Ethernet
        [2]:http://docs.sun.com/app/docs/doc/819-6611/6n8k5u1mc?a=view#g(...)

        Si tu veux me pv , hésite pas ;) (meme si je m'y connais pas trop)

      • [^] # Re: SAN ?

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

        J'avais lu une news sur un type qui voulait monter un serveur de quelques centaines de tera octet. En gros, il as pris pas mal de mini serveur remplit de disque IDE. Chaque serveur était lié en e-scsi à un maitre. Le maitre pouvant lui-même exporter en e-scsi à un autre maitre. En combinant les partition e-scsi tu dois pouvoir faire du raid5 ou 6.

        "La première sécurité est la liberté"

  • # DRBD + Heartbeat

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

    Bonjour,
    Dans ma boite j'avais besoin de monter les serveurs en haute dispo. Le budget était assez limité donc pour ce qui était des solutions à base de NAS ou de SAN c'était grillé.
    La solution que j'ai utilisé c'est heartbeat+drbd. Drbd permet de faire du raid mirror par réseau. Hearteat s'occupe de toute la partie gestion des crash.
    En cas de problème sur le serveur maitre, heartbeat bascule l'IP virtuelle sur le serveur esclave, remonte la partition DRBD sur l'esclave, démarre les services réseau et me prévient par mail.
    Jusqu'à présent j'en suis pleinement satisfait. Ça remplit mes besoins en termes de simplicité de coût et de sécurité.
    L'inconvénient que je vois est que la partition drbd ne peut être montée que sur le noeud principal. Elle n'est même pas accessible en lecture sur l'esclave. Ceci dit, la version 0.8 qui devrait sortir sous peu devrait autoriser la cohabitation de plusieurs maitres, permettant donc de faire de l'équilibrage de charge entre les deux serveurs.

Suivre le flux des commentaires

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