Dossier : Des Data Grids hautement évolutifs (3/3)

Dans la suite et fin de ce dossier, nous nous intéresserons à la création de la grille de données.

Clustering sous Windows

Lorsque vous créez une grille de données d’entreprise, vous placez en gros deux serveurs ou plus au sein d’un cluster, généralement des machines propriétaires interconnectées par le clustering sous Windows. Mais il s’agit d’un cluster créé par le produit de grille de données.

Dans ce cas, tous les serveurs se perçoivent les uns et les autres. Ils font partie intégrante d’une grille de données et les informations peuvent être partagées entre eux. Ainsi, ils fournissent un seul stockage de données logique qui englobe de multiples serveurs.

Du point de vue des applications, vous pouvez avoir 20 serveurs dans la grille et la mémoire de tous est mutualisée (pool) pour créer une seule mémoire logique de grande taille. Les serveurs de la grille se chargent de distribuer les données sur différents serveurs et les répliquent dans certains cas, afin d’éviter des pertes de données si l’un d’eux venait à tomber en panne. Mais, pour l’essentiel, ils forment un cluster afin de se percevoir les uns et les autres.

Mise en place du Cluster

Une fois le cluster en place, certaines fonctionnalités spécifiques à cette approche sont nécessaires. La plus importante est la préservation d’un délai de bon fonctionnement de 100 %. Une grille de données est partagée par de nombreuses applications stratégiques, de sorte qu’il est inconscient de ne pas atteindre ce niveau de bon fonctionnement. La deuxième fonctionnalité est la possibilité d’effectuer des modifications, laquelle est associée aux 100 % de bon fonctionnement.

Vous devez être capable d’apporter en dynamique des modifications à la grille de données en cours d’exécution, sans arrêter quoi que ce soit. Vous devez être en mesure d’ajouter un nouveau serveur afin d’augmenter la capacité disponible ou d’en retirer un en vue de réduire la capacité ou pour des opérations de maintenance sur certains serveurs, tout en maintenant la grille opérationnelle.

Nombre total de lectures et écritures exécutables

La grille de données doit pouvoir croître de deux manières : sur le plan de la capacité de transactions de lecture-écriture/seconde et sur le plan de la capacité de stockage. En ajoutant plus de serveurs à la grille, vous ajoutez de la puissance de traitement et des cartes réseau afin de prendre en charge plus de connexions client, et vous accroissez le nombre total de lectures et écritures exécutables simultanément par tous les clients combinés.

Ce type d’évolution n’est pas facile à absorber par une base de données, alors qu’une grille de données peut le faire en toute transparence. En général, il est judicieux d’employer une plate-forme matérielle et logicielle 64 bits. Avec le 64 bits, vous pouvez facilement bénéficier de plus de 4 Go de mémoire dans chaque configuration, 16 Go à 32 Go constituant plutôt la norme. Les grilles de données prennent en charge une topologie de partitionnement. L’ensemble des données stockées dans la grille est partitionné automatiquement par celle-ci.

Gestion des partitions

Chaque partition réside sur un serveur distinct, de sorte que le nombre de partitions est égal au nombre de serveurs. Dès que vous ajoutez un serveur, il crée une nouvelle partition et celle-ci inclut plus d’espace de stockage.

Cette démarche vous permet de faire évoluer la capacité de stockage globale. Une autre topologie de stockage des données consiste à combiner le partitionnement et la réplication. Différents types de réplication sont possibles, mais la plus pertinente pour une grille de données d’entreprise est celle avec partitionnement. Autrement dit, chaque partition stockée sur un serveur d’une grille de données possède une réplique ou une sauvegarde sur un autre serveur de la grille. Il est possible d’avoir plusieurs sauvegardes, bien que ce soit rarement nécessaire.

Gestion de défaillances

Par conséquent, si votre grille de données comporte trois serveurs ayant chacun une partition (partitions 1, 2 et 3), chaque serveur conserve une partition et une sauvegarde d’une partition d’un autre serveur.

Ce faisant, la défaillance d’un serveur n’entraîne aucune perte de données, bien que la grille de données soit vulnérable pendant le court laps de temps nécessaire à la redistribution des partitions sur le nombre modifié de serveurs et à la création d’une sauvegarde actualisée de l’une des partitions.

Heureusement, cette période de vulnérabilité est brève et peut aller de quelques minutes à une heure si votre grille de données est extrêmement volumineuse.

Pendant ce laps de temps, si un deuxième serveur vient aussi à tomber en panne, vous pouvez perdre certaines données, mais la probabilité d’une double défaillance rapprochée est faible.

Des Data Grids hautement évolutifs (1/3)

https://www.itpro.fr/dossier-des-data-grids-hautement-evolutifs-1-3-5421/

Des Data Grids hautement évolutifs (2/3)
https://www.itpro.fr/dossier-des-data-grids-hautement-evolutifs-2-3-5422/

Des Data Grids hautement évolutifs (3/3)
https://www.itpro.fr/dossier-des-data-grids-hautement-evolutifs-3-3-5423/