Forum Linux.debian/ubuntu Besoin de conseils pour la création d'un SAN

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
2
31
déc.
2013

Bonjour à tous,

Permettez-moi de me présenter, je m'appelle Guillaume. Je suis étudiant en première année de master (BAC +4) en école d'info et j'aurais besoin de vos précieux conseils pour un projet de fin d'année. Explication.

L'idée c'est de mettre en place une infrastructure devant accueillir une application type Dropbox. Je travaille avec des camarades développeurs et si nos choix techniques ont plus ou moins été pris concernant les clusters de serveurs web et de SGBD (PHP / Apache / MariaDB) je me pose des questions à propos du SAN, qui devra accueillir toutes les données de nos utilisateurs, ainsi que les bases de données.

L'idéal serait d'avoir un cluster de stockage à deux nœuds proposant de la haute-disponibilité et de la répartition de charge. J'étais parti sur un cluster DRBD Actif / Actif accessible via iSCSI + Multipath sur les initiators mais il semblerait que le développeur du cœur de DRBD le déconseille fortement (Voir ici aussi).

Depuis je parcours le web à la recherche d'idées mais je n'arrive pas à trouver de solution concrète… Comment faire pour avoir de la répartition de charge sur un cluster de stockage ? Comment font les géant du web comme Amazon, Google, OVH… pour gérer cette problématique ?

Je travaille de préférence avec Debian mais je ne suis pas allergique aux autres distributions !

Merci pour votre aide !
Guillaume.

  • # en posant la question en anglais à mon oncle americain

    Posté par  . Évalué à 3.

    il m'a donné ca : http://lmgtfy.com/?q=filesystem+cluster

    dont le premier lien m'envoie sur :
    http://en.wikipedia.org/wiki/Clustered_file_system

    qui explique les differents systemes existants
    avec quelques pistes entre "shared disk" (SAN) et "distributed filesystem"

  • # Commentaire supprimé

    Posté par  . Évalué à 1.

    Ce commentaire a été supprimé par l’équipe de modération.

  • # hum

    Posté par  (site web personnel) . Évalué à 1. Dernière modification le 01 janvier 2014 à 19:19.

    Pourquoi du SAN ?

    Si il s'agit d'une application type dropbox, pourquoi pas un système de stockage objet type Openstack Swift ?

    Si vraiment tu as besoin d'un stockage accessible en mode bloc, redondant reparti et qui fait le café, tu peux regarder du coté de Ceph/CephFS, je crois qu'il y a une couche ISci également, à vérifier …

    Is it a Bird? Is it a Plane?? No, it's Super Poil !!!

    • [^] # Re: hum

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

      Oui le projet Openstack est très intéressant mais malheureusement les fonctionnalités proposées par Swift sont des fonctionnalités faisant partie du barème d'évaluation et que les développeurs doivent… développer… (notamment sur la gestion de quotas, de droits d'accès ou de limitation de bande passante par exemple).

      Je vais aussi chercher du côté de CephFS, merci pour le conseil !

  • # Si tu utilises Mysql/Mariadb ou autre SGBDR ....

    Posté par  . Évalué à 3.

    Il faut bien préciser ou tu veux mettre la haute dispo et la répartition de charge. De plus tu aurais du te poser cette question lors du choix du SGBD, car il y a des choses qui peuvent être faites à son niveau.

    Niveau haute disponibilité, que voudrais-tu exactement ?

    1/ veux-tu un cluster de serveurs de base de données qui accèderaient à tes LUNs simultanément ? A ma connaissance, seul Oracle RAC permet de le faire (il y en a peut-être d'autres mais je ne les connais pas - si qqn a des infos à ce sujet, je suis preneur).

    2/ Ou alors voudrais-tu deux serveurs ou baies qui mettraient à dispo la volumétrie via iSCSI en permettant une écriture synchrone sur les deux serveurs (une sorte de raid1 entre les LUNs ?). Dans ce cas, c'est simple : deux machines exportant leur volumétrie : tu crées des LUNs identiques sur chaque machine, et ensuite tu fais un RAID1 LVM (ou autre) pour avoir la haute dispo au niveau des données. Par contre, pas de répartition de charge : les données sont écrites simultanément sur tes 2 UNS. Côté perfs, ça doit pas être génial …

    3/ tu pourrais simuler un actif/actif avec répartition de charge "manuelle" en utilisant deux machines qui aurait chacune une partie des données en actif, et qui répliqueraient celles-ci sur l'autre en mode passif, avec un cluster style heartbeat pour gérer la haute dispo.

    Sinon, si tu veux des idées, va Va voir ce slide. Je cherche la vidéo associée, mais je ne la trouve pas. Mais dans le slide tu trouveras quelques infos (qui pourront te servir de base de recherche) pour faire du mariadb distribué.

    • [^] # Re: Si tu utilises Mysql/Mariadb ou autre SGBDR ....

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

      Et ben ! Plus j'en apprends sur OpenStack et plus je me rends compte à quel point ce projet est incroyable !

      Pour résumer, voici le cahier des charges dans ses grandes lignes :

      Les développeurs doivent mettre en place une solution de type Dropbox. Ils planchent actuellement sur l'API qui permettra de gérer les utilisateurs, leurs fichiers, leurs droits d'accès, s'ils ont souscrit à des offres payantes, leurs quotas en bande passante et en stockage, etc.

      J'ai donc plusieurs choses à mettre en place au niveau infra pour supporter leur solution :

      • Un premier cluster pour héberger l'API, qui à priori reposera sur un frontend PHP / MySQL (ou MariaDB). (Haute-disponibilité et répartition de charge obligatoires sur ce cluster).
      • Un deuxième cluster web classique conçu pour héberger le client web (Interface web où les utilisateurs pourront gérer leurs fichiers, leur compte…) (LB obligatoire).
      • Un troisième cluster de stockage conçu pour héberger les données des utilisateurs (les documents qu'ils uploaderont sur ce dropbox-like) et la (les) base(s) de données nécessaire(s) à l'API (HA et LB obligatoires).

      Voilà comment je conçois l'infra actuellement mais je suis totalement libre dans le choix des technologies à utiliser et dans la manière de l'articuler. La seule limite étant les ressources physiques que j'ai à ma disposition… J'ai des camarades qui font tout le projet sous Windows par exemple…

      En tout cas merci pour votre aide !

      • [^] # Re: Si tu utilises Mysql/Mariadb ou autre SGBDR ....

        Posté par  . Évalué à 2.

        Ok, je vois un peu mieux …. Mais il me semble que tu as inversé "client web" et "serveur web" dans le point 2. Sinon, pour le stockage des données utilisateur, personnellement j'aurais plutôt opté pour du nosql style Hadoop, quitte à utiliser en parallèle un SGBDR pour l'API.

        Maintenant revenons à ton cluster de stockage : tu y stockeras 2 types de données si j'ai bien compris : fichiers "plats" (les données utilisateurs) et des bases de données. Pour les serveurs BDD, va voir ce que permet mysql cluster : ça a l'air de répondre à ton besoin. Il te reste cependant un SPOF: le proxy, mais tu pourrais le redonder par exemple en utilisant un cluster HeartBeat ou Redhat Cluster (il y a peut-être d'autres solutions) pour palier à sa défaillance. Je ne sais pas par contre si tu peux faire ça avec MariaDB.

        Pour la partie "fichiers utilisateurs", à mon avis (et comme dt par ailleurs) Texte du lien est le bon candidat.

        Après, tu n'es pas obligé d'utiliser un SAN pour tout ça : chaque serveur MySQL dispose de son stockage local, et chaque noeud glusterFS également. Si tu l'utilises, il te faudra au moins 2 baies pour assurer la redondance de tes données, créer tes LUNs et les affecter a tes machines (MySQL et noeuds de stockage GlusterFS) de façon à assurer la réplication sur les deux baies au niveau SGBD et/ou FS.

        Sinon, si tu veux utiliser un SAN, via iSCSI, je ne suis pas sur que tu aies besoin de Multipath : Vu que tu passes par TCP/IP, tu peux assurer la redondance et la répartition de charge sur ton réseau en agrégeant tes interfaces via bonding.

        Je ne sais pas si j'ai été clair, et si tout ce que je t'ai dit est réalisable (sur le papier j'ai l'impression que oui), mais en tout cas, c'est comme ça que je ferais si j'avais un truc de ce genre à implémenter. Par contre, côté perf, je ne sais pas ce que ça pourrait donner.

      • [^] # Re: Si tu utilises Mysql/Mariadb ou autre SGBDR ....

        Posté par  . Évalué à 2.

        Question (le sujet m'intéresse) : Est-ce que l'API sera publique ou seulement accessible par le cluster web ?

        • [^] # Re: Si tu utilises Mysql/Mariadb ou autre SGBDR ....

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

          API publique je pense car les développeurs doivent aussi bosser sur un client Android, iOS, Windows, Linux et peut-être Windows Phone / MacOS…

          Merci beaucoup pour tous ces précieux conseils. Mon projet est pour fin juin donc je continue mes recherches et mes tests avant de me lancer. Je reviens vers toi pour te donner des nouvelles :)

  • # Schéma de l'architecture

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

    C'est encore moi !

    Voilà ce qu'il est ressorti de ma tête (Schéma au format SVG)…

    La partie LVS / Répartition de charge n'est qu'au stade de brouillon. Je me pencherai sur ce problème en temps et en heure. Pour le moment il faut mettre en place le backend de stockage (GlusterFS) et MariaDB Galera.

    • [^] # Re: Schéma de l'architecture

      Posté par  . Évalué à 2.

      Vas-tu aussi utiliser des volumes SAN pour le cluster de BDD ?
      Autre chose: si tu passes par du iSCSI, et que tu peux dédier un réseau pour faire passer le stockage, n'hésite pas. Tu pourras ainsi faire un tuning adapté (je ne sais pas si la modification de la taille de MTU sur un iSCSI peut aider, il faudrait faire des recherches et des tests sur le sujet).

      Pour la répartition de charge et la redondance côté LVS, as-tu envisagé d'utiliser HAProxy ? Si tu l'as écarté, quelle en serait la raison ?

  • # Suivi de projet

    Posté par  (site web personnel) . Évalué à 1. Dernière modification le 29 janvier 2014 à 21:00.

    Bonjour à tous,

    J'ai bien avancé dans mon projet (en tout cas dans sa réflexion), GlusterFS tient ses promesses et j'attends la documentation de mon collègue pour vous parler de MariaDB Galera. Quoi qu'il en soit si mes aventures vous intéressent, je documente toutes mes expériences sur cette page.

    Merci encore à ceux qui m'auront aiguillé :)

Suivre le flux des commentaires

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