Rapport d`architecture logiciel Bases de données : haute
publicité
Rapport d'architecture logiciel Bases de données : haute disponibilité et load balancing, quels mécanismes ? 09/11/2012 Amha Bekele Esraa Maher Ghazi Ochi Vincent Verdier Table des matières Introduction...................................................................................................................................... 1 1 La haute disponibilité..................................................................................................................... 2 1.1 Réplication............................................................................................................................. 2 1.1.1 Réplication synchrone....................................................................................................2 1.1.1.1 Réplication synchrone asymétrique........................................................................3 1.1.1.2 Réplication Synchrone symétrique..........................................................................4 1.1.2 Réplication asynchrone (Lazy replication)......................................................................4 1.1.2.1 La réplication asynchrone asymétrique...................................................................4 1.1.2.2 La réplication asynchrone symétrique.....................................................................4 1.1.3 La diffusion des modifications........................................................................................5 1.2 Failover.................................................................................................................................. 5 1.3 Cluster................................................................................................................................... 6 2 Équilibrage des charges................................................................................................................ 7 2.1 Pourquoi le Load Balancing?.................................................................................................7 2.2 Les différentes solutions du load balancing............................................................................7 2.2.1 Base de données réparties.............................................................................................8 2.2.2 Base de données fédérées.............................................................................................9 2.2.3 La fragmentation............................................................................................................ 9 2.2.4 Les algorithmes............................................................................................................ 11 2.2.4.1 Round-robin.......................................................................................................... 11 2.2.4.2 Least connection...................................................................................................12 2.2.4.3 First response.......................................................................................................12 2.2.4.4 Random................................................................................................................ 12 3 Nouvelles techniques.................................................................................................................. 13 3.1 NoSql................................................................................................................................... 13 3.2 Cache.................................................................................................................................. 15 3.3 L'importance du facteur matériel..........................................................................................15 3.4 Consistent Hashing.............................................................................................................. 16 3.4.1 Problématique.............................................................................................................. 16 3.4.2 Solution........................................................................................................................ 16 Conclusion..................................................................................................................................... 18 Sources.......................................................................................................................................... 19 Architecture logiciel 09/11/2012 Introduction Chaque jour, les besoins des entreprises en termes de stockage de données augmentent, de même les utilisateurs et le marché sont de plus en plus exigeant en termes de disponibilité. La haute disponibilité consiste à assurer un taux de disponibilité qui se rapproche des 100%. L’indisponibilité d’un système peut coûter très cher à une entreprise, comme on peut le voir cidessous. Pour assurer un taux de disponibilité convenable, les entreprises sont donc contraintes d’assurer le bon fonctionnement de toutes les couches qui composent leurs systèmes informatiques. Et les bases de données représentent un élément clé dans la composition de tous système. Par exemple, le géant Google, qui doit satisfaire plus d’un milliard de requêtes par jour, est obligé d’assurer une haute disponibilité de son système d’accès aux données. En effet, il doit être capable de trouver une information rapidement dans une volumétrie considérable. Étant donné l’importance de l'accès aux données dans tout système informatique, on peut se demander quelles sont les solutions pour assurer une disponibilité convenable au sein d’un système de gestion de bases de données. Nous verrons dans une première partie quels sont les mécanismes pour la haute disponibilité en termes de base de données. Dans une seconde partie, nous expliquerons en détail un mécanisme incontournable : l’équilibrage des charges. Et enfin on verra dans une dernière partie quelles solutions se développent pour faire face aux mécanismes dites classiques. Page 1 Architecture logiciel 09/11/2012 1 La haute disponibilité Dans cette partie, nous détaillerons les principales techniques à mettre en oeuvre pour garantir la disponibilité des bases de données. Nous verrons que ces solutions combinent souvent des aspects matériels et logiciels. 1.1 Réplication On peut définir la réplication comme la copie d’un ensemble de données. On distingue généralement un site primaire appelé maître (ou référence), d’un site secondaire appelé esclave (ou cible). Le système de gestion de base de données (SGBD) ou le réplicateur s’occupe de la mise à jour des données. Site primaire Site secondaire Types d’accès des applications Lecture/écriture Lecture Ordres Select, Delete Insert, Update, Select La réplication permet de se prémunir de plusieurs problèmes qui peuvent nuire à la haute disponibilité. En effet, un SGBD, sans réplication, entraîne une surcharge et une dégradation du temps de réponse car toutes les applications accèdent au même système. De plus l’unicité de la base de données fait qu’il y a une très faible tolérance à la panne. La principale motivation de la réplication serait donc une amélioration des performances et de la disponibilité. Une amélioration des performances, dans la mesure où on évite un goulot d’étranglement en faisant appel à une copie plus ou moins proche. Une amélioration de la disponibilité, car dans le cas où il y aurait une panne on peut se replier sur une copie. Supposons que l’on possède deux copies avec risque de panne de 3%, alors la disponibilité est de 99,91% car : Disponibilité =1- risque de panne ^ nombre de copies La mise en place d’une réplication suppose le maintien à jours des copies, même si les copies peuvent être différentes à un instant donné. On définit en général 4 grandes techniques de réplication, chacune de ses méthodes a ses avantages que ce soit en terme de coût ou d’efficacité. Selon le budget et le type d’application, le choix peut-être différent. 1.1.1 Réplication synchrone La réplication synchrone consiste à ce qu’une transaction met à jour toutes les copies des données modifiées, cette technique à l’avantage de s’effectuer en temps réel. Cependant elle engendre un coût relativement élevé et souvent les entreprises dont l’exigence en temps réel est réduite choisissent la solution asynchrone. Page 2 Architecture logiciel 09/11/2012 1.1.1.1 Réplication synchrone asymétrique La réplication synchrone asymétrique est composée d’un maitre qui accepte les écritures et d’ esclaves qui sont accédés en lecture. On utilise un mécanisme de « two phase commit ». Si ce mécanisme n’est pas mis en place, la présence de plusieurs bases fait que si une base tombe en panne, et qu’une transaction est enclenchée, le principe d’intégrité ne sera plus respecté. Le « two phase commit » consiste comme son nom l’indique en deux phases, une première dite de scrutation (ou de vote) et une deuxième de décision. Phase de scrutation Le coordinateur envoie les ordres à tous les sites et demande s’ils peuvent valider la transaction. Dans le cas où un site répond de manière négative, il quitte la branche de la transaction. Le cas échéant, il se met en attente de la phase de décision. Phase de décision Si tous les sites participants sont en mesure d’effectuer la transaction, le coordinateur leur indique qu’ils peuvent faire un COMMIT. Si un des serveurs, n’est pas en mesure d’effectuer la transaction, le coordinateur force tous les sites à faire un ROLLBACK. Page 3 Architecture logiciel 09/11/2012 1.1.1.2 Réplication Synchrone symétrique Contrairement à la réplication synchrone asymétrique il n’existe pas de table maître : chaque table possède un trigger qui se déclenche lors d’une modification. Cette façon de faire nécessite d’une part un système de verrous le temps qu’une modification se propage, et d’autre part une gestion des priorités. 1.1.2 Réplication asynchrone (Lazy replication) Plus flexible que la manière synchrone il donne la possibilité de faire les mises à jour à des intervalles de synchronisation, par exemple à des moments de faible affluence. 1.1.2.1 La réplication asynchrone asymétrique Les transactions mettent à jour une copie dite primaire ( publisher ), les mises à jour de cette copie est envoyé aux autres copies( subscribers) ultérieurement. Le problème auquel on se heurte, est qu’à un instant T, les dernières modifications ne sont pas répercuté. Mais cela fait partie du compromis pour diminuer les coûts et le temps de réponse. Une banque par exemple ne pas se permettre un tel compromis. 1.1.2.2 La réplication asynchrone symétrique Les modifications sur une table sont stockées dans une file, pour être lancé de manière ultérieure. L’exemple classique est l’ordinateur portable du commercial qui n’a pas forcément accès à un réseaux lors de son déplacement. Le soir, en rentrant chez lui, un échange est effectué dans les deux sens, de la base locale du commercial vers la base centrale et vice-versa. Ce type de réplication entraîne de forte incohérence, car il se peut qu’il y ait plusieurs versions “copie” de la base primaire. La réplication asynchrone symétrique nécessite donc un moyen de réconciliation des conflits. La règle de Thomas permet de s’assurer que les copies convergent. Cette règle consiste à estampiller (cacheter) chaque entrée , par exemple en utilisant l’heure exacte + le site concerné. Une transaction met à jour l’entrée et son estampille, l’estampille est toujours croissante. La mise à jour est appliquée si et seulement si l’estampille de la mise à jour est supérieur à celle de l’entrée. Page 4 Architecture logiciel 09/11/2012 1.1.3 La diffusion des modifications Lors de la réplication, le résultat peut être diffusé de deux manières : – Le résultat de la requête est directement envoyé, ce qui permet de ne pas faire l’opération plusieurs fois. Cependant cela nécessite que l’on s’assure que les mises à jour soient identiques sur tous les sites. – L’opération est envoyée à chaque site, et chacun effectue l’opération. Cette technique a le mérite d’être plus flexible, en revanche il y a un risque d’incohérence avec les opérations non-déterministe de type random(). 1.2 Failover Lors d'une défaillance, d'un arrêt programmé ou d'une surcharge de requêtes, le failover assure la continuité d'une ressource matériel via un système de secours tel qu'un serveur redondant. Ce basculement peut avoir lieu de façon automatique ou être déclenché par une action manuel. Au niveau des serveurs matériels, l’automatisation du basculement est généralement réalisée à l’aide d’un logiciel de surveillance de disponibilité tel que “Heartbeat” issue du projet “LinuxHA”. Ce programme permet de surveiller l’activité d’un serveur via un ou des signaux qui sont régulièrement émis par le serveur à surveiller. Ces “battements de coeur” peuvent être prévus de différentes façons : connexion par port série, connexion ethernet UDP/IP broadcast, unicast, ping... Dans le cadre de la haute disponibilité en matière de base de données, on utilise généralement la technique du failover sur des disques durs partagés par un cluster de serveurs. On peut également l'appliquer à un ensemble de base de données. Lors d'une opération de failover la base données secondaire devient alors la base de données primaire. Ce mécanisme comporte toutefois certains désavantages. En effet, le basculement provoque l'annulation de toutes les transactions en cours de traitement. Le failover doit donc plutôt être déclenché en cas de défaillance grave tel qu'une panne matériel. Page 5 Architecture logiciel 09/11/2012 1.3 Cluster Les clusters (ou grappe de serveurs en français) sont un ensemble d'ordinateurs (nœuds du cluster), connectés entre eux via un réseau local à très haute vitesse et qui fonctionnent comme s'il s'agissait d'un seul système. Ils sont principalement utilisés en calcul distribués ainsi qu'en stockage grâce aux systèmes de gestion de bases de données réparties. Il existe plusieurs configurations de clusters : Actif/Actif Dans cette configuration, tous les nœuds fonctionnent ensembles pour fournir le même service. On a l’avantage de pouvoir faire du load-balancing. De plus, on utilise un système de fichier distribué ce qui rend le basculement totalement transparent. Actif/Passif Cette approche est couramment utilisé dans le cadre du failover. Elle consiste à laisser en attente un nœud redondant pour chaque nœud du cluster afin qu'ils prennent le relais des nœuds actifs en cas de défaillance. On parle de noeuds maîtres et esclaves. Les données du noeud maître sont automatiquement répliquées sur l’esclave et ce dernier prend le rôle de maître en cas de défaillance. N+1 Un nœud supplémentaire prend le relais en cas de panne. Dans le cas d'un environnement de serveurs hétérogènes, ce nœud supplémentaire doit être capable d'assumer n'importe quel rôle. N+M Même chose que pour N+1 mais avec M serveurs. Page 6 Architecture logiciel 09/11/2012 2 Équilibrage des charges Dans cette partie, nous expliquerons les avantages et les mises en place possibles de la répartition des charges. La répartion des charges consiste à effectuer une distribution des travail à différentes machines. En fonction de la disponibilité des serveurs, mettre en place le load balancing permet de rediriger les consommateurs de services adéquatement. L’équilibrage permet d’adapter la méthode de redirection des services en suivant des algorithmes qui ont dèjà fait leurs preuves ( Round Robin, Random, Least Resources). 2.1 Pourquoi le Load Balancing? Les avantages de l’équilibrage de charge sont multiples. En effet, mettre en place ce genre de technique permet de distribuer le travail entre différents ordinateurs. Cela permet d’obtenir des dispositifs très performants. Le load balancing permet d’améliorer la qualité, la disponibilité des données et l’évolutivité d’une infrastructure. Mettre en oeuvre un équilibrage des charges permet d’augmenter la qualité des services. Ainsi, en séparant les différentes tâches à un pool de machines, le temps de réponse des services fonctionnels est plus court et la capacité à pallier la défaillance d’une ou plusieurs machines est meilleure. L’équilibrage des charges est aussi très intéressant pour une entreprise qui a un potentiel de croissance ainsi qu’un risque de charge accrue (lorsque beaucoup de ressources utilisent de nombreux services). En effet, répartir les charges augmente la scalabilité et la disponibilité des serveurs : cela permet donc de maintenir ses fonctionnalités et ses performances en cas de forte demande. La gestion de la scalabilité permet de lutter contre les pannes et l’arrêt temporaire des services. Aussi, l’évolutivité de l’architecture est renforcée avec la possibilité d’ajouter des serveurs sans interrompre le fonctionnement et la continuité des services. Le load balancing favorise une meilleure gestion des données puisque la haute disponibilité des serveurs diminue les risques de défaillance ou d’arrêts planifiés des systèmes d’exploitation qui pourraient nuire à l’accès aux données. Les données sont donc accessibles plus de temps. Les données sont mieux protégées car il y a moins de risques associés à la perte et à la non-disponibilité des données. Enfin la disponibilité des données et des serveurs rend le système plus fiable. 2.2 Les différentes solutions du load balancing Au niveau des bases de données, le but du load balancing est d’optimiser au mieux la répartition des données afin d’avoir les meilleurs performances possibles (suivant des critères de volume de données, temps de réponses, disponibilité ou fiabilité des données). Page 7 Architecture logiciel 09/11/2012 2.2.1 Base de données réparties Une base de données est gérée par un seul système de gestion de bases de données et est stockée totalement dans un unique espace physique. Par opposition, Les bases de données réparties sont stockées dans différents endroits. En effet, plusieurs unités coopèrent pour gérer les informations et les traitements sont séparés. Les objectifs sont multiples : • Limiter le transfert d'information (en nombre et en volume) en répartissant les données là où elles sont le plus utilisées • Accroître les performances par la répartition de la charge de travail sur plusieurs unités de traitement opérant en parallèle • Augmenter la fiabilité (en faisant effectuer le même traitement par plusieurs ordinateurs et en dupliquant les données sur différents sites) • La disponibilité des informations en dupliquant l’information Le principe d’une base de données répartie : Une base de données répartie est une base dont différentes parties sont stockées sur des sites, généralement géographiquement distants. Les sites sont néanmoins reliés par un réseau. Un système de bases de données réparties est normalement conçu pour gérer la concurrence, la fiabilité, l’optimisation des requêtes ou transactions sur des données gérées par les différents SGBD sur plusieurs sites. Utilisation d'une base de données répartie Le principe fondamental des bases de données réparties doit être la transparence pour l'utilisateur. Cette transparence s'exprime sous trois formes : • La transparence de localisation, les utilisateurs accèdent à la base de données normalement (en utilisant le schéma conceptuel ou des vues externes) mais ne choisissent pas le site sur lequel il souhaite recevoir les données. • Transparence de partitionnement, les utilisateurs ne doivent pas savoir que les données sont fractionnées et ne se soucie pas de la réunification. Page 8 Architecture logiciel • 09/11/2012 Transparence de duplication, lors de l’ajout ou de la modification d’une information, c’est le système qui se charge de dupliquer les données. Les problèmes de la répartition : • Complexité de la répartition puisque les données sont fragmentées, dupliquées ou éloignées. • La mise en place des schémas locaux à partir du schéma global peut être compliquée. 2.2.2 Base de données fédérées Une base de données fédérée a pour but de donner aux utilisateurs une vue unique des données présentes dans plusieurs systèmes : Objectifs : Les intérêts de fédérer une base de données peuvent être multiples. Premièrement, on améliore les performances de la base en séparant les traitements sur chaque base locale. Ensuite, l’utilisateur a une vue unique des données implémentées sur plusieurs plate-formes ou SGBD. Troisièmement, la fédération d’une base permet de faire cohabiter différents systèmes tout en leur permettant d’interagir ensemble. Les problèmes de la fédération : • Hétérogénéité sémantique (BD) et syntaxique (SGBD, communications) • Le besoin des schémas locaux pour créer un schéma global. 2.2.3 La fragmentation Le partitionnement de données permet d’améliorer les performances de la base de données en réduisant la taille des fichiers en allégeant les traitements. La Fragmentation horizontale : La fragmentation horizontale consiste à découper une table en sous-tables. On utilise alors les prédicats pour sélectionner des tuples appartenant à chaque fragment. La reconstitution de la relation initiale se fait grâce à l'union des sous-relations. Page 9 Architecture logiciel 09/11/2012 Exemple : Fragments définies par sélection : Client1 = select * from Client where ville = "Marseille" Client2 = select * from Client where ville <> "Marseille" Client Client 1 Client 2 NoCli NomCli VilleCli C1 Dupond Marseille C2 Durant Lyon C3 Duval Paris C4 Dupeye Marseille NoCli NomCli VilleCli C1 Dupond Marseille C4 Dupeye Marseille NoCli NomCli VilleCli C2 Durant Lyon C3 Duval Paris La Fragmentation verticale : C’est le découpage d'une table en sous tables par projection de colonnes. Chaque fragment est composé d’une partie de la relation initiale. La relation initiale doit donc pouvoir être recomposée par la jointure des fragments. Exemples Fragments définies par projection : Client1 = select NoCli, VilleCli from Client Client2 = select NoCli, NomCli from Client Page 10 Architecture logiciel Client 09/11/2012 NoCli NomCli VilleCli C1 Dupond Marseille C2 Durant Lyon C3 Duval Paris C4 Dupeye Marseille Client 1 Client 2 NoCli VilleCli C1 Marseille C2 Lyon C3 Paris C4 Marseille NoCli NomCli C1 Dupond C2 Durant C3 Duval C4 Dupeye 2.2.4 Les algorithmes 2.2.4.1 Round-robin La technique de répartition la plus simple et la plus couramment utilisée est celle du DNS RoundRobin, ou DNS-RR. Round-robin est un algorithme d’ordonnancement courant dans les systèmes d’exploitation. Il permet une répartition des charges équitable entre serveurs d'une ferme informatique (cluster). Chaque processus a un temps égal aux autres. Le Round-robin est souvent apparenté au tourniquet d’un parc : chaque processus passe devant le tourniquet et s’exécute en un temps fini. Principe : Les processus sont gérés dans une liste et tous les nouveaux processus sont ajoutés en fin de liste. Le processeur contrôle le temps de passage de chaque processus et ne leur permet pas de dépasser un temps fini (pour éviter les possibilités de famines). Dès qu’un processus ne fini pas son traitement mais que son temps accordé est écoulé, il arrête d'utiliser le processeur et est placé en fin de liste. Page 11 Architecture logiciel 09/11/2012 Un processus qui a terminé son travail est sorti de la liste, par conséquent le temps d'attente pour les autres processus diminue. 2.2.4.2 Least connection Principe : L’algorithme least connection fournit une connexion au serveur qui a le plus petit nombre de connexions courantes. Il fonctionne mieux dans un système où les serveurs ont des capacités similaires. Toutefois, il faut faire attention avec cette méthode car un serveur peut être considéré comme chargé (beaucoup de connexions) alors que les processus sont en attente d’une requête vers une base de données. 2.2.4.3 First response Principe : Les requêtes clients sont envoyées simultanément à tous les serveurs et le premier qui répond sera chargé de la connexion. 2.2.4.4 Random Principe Les requêtes sont envoyées à un serveur au hasard. Cette méthode n’est cependant jamais utilisée en général. Page 12 Architecture logiciel 09/11/2012 3 Nouvelles techniques Face aux limites des solutions dites “classiques” d’autres solutions se développent comme le NoSql, toutefois il ne faut pas négliger l’impact du matérielle et de l’humain dans cette recherche de haute disponibilité. 3.1 NoSql NoSql (“Not Only SQL”, en Français “Pas seulement SQL”) constitue une nouvelle approche dans les systèmes de gestion de base de données. Apparu début 2009, ce mouvement propose une alternative au “tout relationnel” qu’on trouvait partout jusqu’à présent. Le fonctionnement de ces bases s’appuie sur des concepts plus simples tel que le stockage de paires clé/valeur. Les bases NoSQL permettent donc de répondre avant tout aux besoins de performances provoqué par l’explosion du Web 2.0. En effet, leur modèle de données réduit permet de grandement optimiser les opérations de recherche et d’insertion. On peut donc supporter une charge de trafic beaucoup plus importante qu’avec les SGBDR classiques. SQL vs. NoSql Les bases de données NoSQL sont orientés colonnes : c’est-à-dire que l'on peut ajouter des colonnes à chaque enregistrement aussi facilement qu'on ajoute des lignes (par INSERT/UPDATE) dans le modèle relationnel. L’évolution d’une base NoSQL peut donc se faire aussi bien sur le nombre de colonnes que de lignes. En effet, le NoSQL est beaucoup plus rapide grâce à la façon dont on traite les colonnes variables. Par exemple, imaginons que nous avons à gérer le trafic d’un aéroport. Dans un SGBDR, la table avec la liste des vols prendrait la forme suivante : Étant donné que le nombre de passager d’un vol est variable, on ne peut pas avoir une colonne pour chacun d’entre eux. Sinon la table contiendrait de nombreuses valeurs nulles et la rapidité des recherches en seraient gravement affecté. Dans un modèle de données relationnel classique, on résoudrait le problème en créant une table de jointure entre les vols et les passages : Cette table contiendrait donc à la fois tous les vols et tous les noms de passagers. Page 13 Architecture logiciel 09/11/2012 Une ligne de table NoSQL quand à elle aurait la forme suivante : Ici, le nombre de colonnes pour chaque vol dépend du nombre de passagers. Cela permet d’accélérer la recherche d’un passager précis tout en facilitant la mise à jour des données. Cependant, l’augmentation des performances se fait au prix d’une perte de fonctionnalités. En effet, le théorème de CDP (par Eric Brewen) dit qu’il est impossible pour un cluster de garantir en même temps les trois contraintes suivantes : – Cohérence : chaque noeud possède la même vision des données – Disponibilité : toutes les requêtes reçoivent une réponse – Tolérance au partitionnement : pas de “single point of failure” D’après ce théorème, un système de calcul distribué ne peut garantir que deux de ces contraintes à un même instant T. Les SGBD NoSql ne respectent donc que partiellement les contraintes ACID. Cela leur confèrent par contre une grande tolérance aux pannes, ce qui constitue un avantage certain pour la haute disponibilité. On peut notamment évoquer le projet Apache Cassandra qui s’appuie sur les principes suivants : haute disponibilité et tolérance au partitionnement. De plus, leur fonctionnement décentralisé et hautement distribué permet d'orchestrer facilement la réparation des charges. Preuve de leur grande efficacité à manipuler de gros volumes de données, on retrouve ce type de bases dans de grands systèmes tel que Twitter, Facebook ou LinkedIn. Enfin, sauf rares exceptions (VoltDB et SQLFire par exemple), ces systèmes ne disposent pas d’un langage de requêtes structurés comparable à SQL. Exemple : Bigtable: système de bases de données distribué version Google Chaque jour, Google fait face à 2 contraintes majeures. La 1ère est la satisfaction de plus d’un milliard de requêtes par jour et la seconde est le temps de réponse qui doit être très rapide pour pour satisfaire les internautes. En effet, Les SGBDR traditionnelles ne suffisent plus pour satisfaire de tels besoins puisqu’on parle des volumétries d’ordre de Petabytes (1 Petabyte = 1024 Terabytes). La solution chez Google est d’utiliser le BigTable qui a été développé et utilisé chez Google depuis l’année 2005. C’est un système de base de données distribué à haute performance de type NoSQL. Page 14 Architecture logiciel 09/11/2012 Exemple : structure d’enregistrement de la table Webtable Cette structure sert à référencer les pages Web. L’index est constitué d’une URL inversée, la colonne ‘contents’ contient plusieurs versions du code source d’une page et les colonnes de clés (ici ‘anchor:…)’ contiennent des termes ou clés qui référencent la page. Les t? sont les horodatages. On constate que les clés ne possèdent qu’une version chacune (t9 et t8) alors que la colonne ‘content’ en contient 3 (t3,t5 et t6). Ceci permet de référencer plusieurs versions d’une même page Web. 3.2 Cache Le principe de la mémoire cache est de copier temporairement des données sur un support plus rapide afin de permettre un accès ultérieure plus rapide. Les serveurs SQL utilisent la mémoire RAM comme cache pour améliorer les temps d'accès par rapport à l'utilisation du disque dur. Cependant, les performances se dégradent vite dès que le volume de la base de données dépasse la capacité de la mémoire RAM. Il est possible d'utiliser un système de cache distribué afin de pallier ce problème. Cela permet de répartir les données sur la mémoire RAM de plusieurs serveurs au lieu d'un seul. Impensable il y a une dizaine d'années, cette solution est devenu possible en raison de la contraction des coûts la mémoire et de la généralisation des réseaux à 1Gbit/s voir 10Gbit/s. Memcached est un logiciel libre permettant de mettre en place un système de cache distribué. Il fonctionne sur le principe de stockage par clé/valeur comme une table de hash. Ce système permet par exemple à Facebook de créer un espace logique de 28 To, réparties sur plus de 800 serveurs. 3.3 L'importance du facteur matériel Nous avons vu plus haut plusieurs techniques qui permettent d’assurer une disponibilité convenable des données tout en conservant une cohérence. Toutefois la disponibilité d’un système informatique ne pas se résumé qu’aux solutions exposés plus haut. En effet, si une ressource matérielle critique tombe en panne, cela peut mettre en péril l’ensemble du système. On appel Single Point Of Failure la chute d’une ressource critique qui affecte tous le système, par exemple : le disque dur d’accès aux donnée, l’alimentation… Il convient donc d’assurer que le système est abrité dans des locaux adaptés (climatisation, groupe électrogène en cas de coupure de courant) et que les données sont sécurisés en utilisant Page 15 Architecture logiciel 09/11/2012 un matériel de stockage adapté. En effet l’utilisation d’un NAS ou d’un SAN peut s’avérer être un excellent moyen d’assurer une haute disponibilité. NAS (Network Attached Storage), il désigne un serveur de fichier autonome et indépendant des serveurs d’application, dédié au stockage, accessible à des utilisateurs autorisés. Il a l’avantage de coûter moins cher qu’un SAN. En effet comme le NAS autorise des accès provenant de serveurs multiples on peut facilement implémenter des systèmes de répartition de charge et de tolérance aux pannes. Pour sécuriser les données il utilise la technologie RAID, qui pour faire simple désigne les techniques permettant de répartir des données sur plusieurs disques. SAN (Storage Area Network), à la différence du NAS , c’est un réseau de stockage . Il possède un réseau très hauts débit (Fibre le plus souvent), un ensemble d'équipement d’interconnexion et des disques de stockage. Il a pour avantage principale de permettre le partage d'énormes quantités de données entre plusieurs ordinateurs sans affecter les performances du système, puisque il possède son propre réseau. Par ailleurs, sa capacité de stockage peut-être étendu à l’infini. Cependant, son prix d’acquisition est souvent cher et n’est pas adapté à des petites structures. 3.4 Consistent Hashing 3.4.1 Problématique Le modèle classique de répartition de charge utilise un “load balancer” (français : Équilibreur de Charge) qui distribue (aiguille) le trafic sur les serveurs disponibles en utilisant une formule statique comme le « hash ». En effet, c’est la clé de l’entrée, modulo le nombre de serveurs (N) qui permet de faire l’aiguillage. Du coup, Lorsqu’on ajoute un nouveau serveur pour faire face contre l’augmentation de trafic, on sera obligé à faire une réorganisation des données (car N a changé). Cela rend l’ajout de ressource vraiment coûteuse. 3.4.2 Solution L’algorithme Consistent Hashing ( Français : Hachage Uniforme) permet de répondre a cette problématique en se basant sur une fonction de hachage qui utilise la fonction SHA-1 (secure hash algorithm) qui dispose d'un espace bits de 2 ^ 160. Page 16 Architecture logiciel 09/11/2012 Lorsqu’un nœud rejoint le cluster, il choisit un nombre aléatoire, et ce nombre détermine les données dont il va être responsable. Avantages : • • • Réplication : un nouveau nœud choisit simplement les partitions dont il sera chargé, et une autre pile de partitions pour faire une réplique. Scalability : lorsqu’on assigne un partitionnement a un nouveau nœud, il demande aux nœuds voisins de diviser les données entre eux (équilibrage de charge). Availablity : On peut facilement ajouter ou enlever des nœuds. En effet, la réplication et le scalability permet d’assurer une meilleure disponibilité et de tolérance aux pannes. Il est a note que le consistent hashing est aujourd’hui bien implémentées dans les load-balancer web mais pas encore dans les load-balancer pour répartir les requêtes sql, memcache ou autre… Page 17 Architecture logiciel 09/11/2012 Conclusion Nous avons vu donc que de nos jours la haute disponibilité devient incontournable dans les systèmes informatiques. Même si cela présente souvent un coût considérable, les périodes d’indisponibilités font perdre beaucoup plus d’argent que l’investissement nécessaire assurer la haute disponibilité des infrastructures informatiques. De plus, des géants comme Google qui font face à l’augmentation du volume des données sont contraint de développer de nouvelles techniques de gestion de base de données. Cependant, il est évident que tout système humain est faillible. On peut certes parler de haute disponibilité mais jusqu’à qu’elle taux ? En effet, il semble impossible pour le moment de parvenir à des taux de 100% de disponibilité. Concernant l’équilibrage des charges, nous avons pu observer que ce principe s’applique aussi au domaine des bases de données. En effet, il existe des mécanismes qui permettent de bien regrouper les informations, de séparer les données pour obtenir un système de requêtage plus performant. En effet, bien organiser sa base de données permet d’avoir des informations plus disponibles et mieux situées. Depuis peu, de nouvelles techniques tentent de résoudre les problèmes qui persistent avec les technologies actuelles de haute-disponibilité et de load-balancing : NoSql, systèmes de caches distribuées, nouveaux algorithmes... Il est intéressant de noter que ces mécanismes pleins de promesses sont déjà mis en oeuvre avec succès par certains géants de l’informatique comme Facebook, Google ou encore Twitter. On peut donc penser que la haute-disponibilité et le loadbalancing continuera d’évoluer dans ce sens au cours des prochaines années. Page 18 Architecture logiciel 09/11/2012 Sources http://blog.neoxia.com/nosql-5-minutes-pour-comprendre/ http://home.nordnet.fr/~ericleleu/cours/nfe107/Haute%20Disponibilite.pdf https://fr.wikipedia.org/wiki/Serveur_de_stockage_en_r%C3%A9seau http://msdn.microsoft.com/en-us/magazine/dd942840.aspx https://www.facebook.com/note.php?note_id=39391378919 http://msdn.microsoft.com/en-us/magazine/dd942840.aspx http://en.wikipedia.org/wiki/Computer_cluster http://www.lsis.org/espinasseb/Supports/BDA-2010/BDrepartiesFederees-2010-4p.pdf http://www.learnlinux.org.za/courses/build/internals/ch04s02.html http://www.commentcamarche.net/contents/surete-fonctionnement/san.php3 http://www.dalibo.org/_media/articles/postgresql_ha.pdf http://nosql.mypopescu.com/post/870237816/google-bigtable-paper-summarized http://docs.huihoo.com/cloud-computing/Google-Cluster-Computing-Module-7-Other-GoogleTechnologies.pdf http://www.haute-disponibilite.net/2010/10/03/optimiser-la-repartition-de-charge-avec-le-consistenthashing/ http://www.paperplanes.de/2011/12/9/the-magic-of-consistent-hashing.html http://www.mikeperham.com/2009/01/14/consistent-hashing-in-memcache-client/ http://www.tomkleinpeter.com/2008/03/17/programmers-toolbox-part-3-consistent-hashing/ http://www.scriptol.fr/programmation/nosql.php http://www.inzecloud.fr/bigtable-systeme-de-bases-de-donnees-distribue-version-google/ http://jimbojw.com/wiki/index.php?title=Understanding_Hbase_and_BigTable http://ehcache.org/documentation/get-started/about-distributed-cache http://en.wikipedia.org/wiki/Distributed_cache Page 19
