Mise à l'échelle en unités ou capsules

Bien que vous puissiez déployer une grille de données sur des milliers de machines virtuelles Java, vous pouvez envisager de scinder la grille de données en unités ou capsules pour améliorer la fiabilité et faciliter les tests de votre configuration. Une capsule est un groupe de serveurs qui exécute le même ensemble d'applications.

Déploiement d'une grille de données volumineuses unique

Les tests ont montré que eXtreme Scale peut s'étendre à plus de 1 000 machines virtuelles Java. Ces tests encouragent la création d'applications permettant de déployer des grilles de données uniques sur un grand nombre de machines. Bien qu'il soit possible d'effectuer cette opération, elle n'est pas recommandée, pour plusieurs raisons :

  1. Budget : votre environnement ne peut pas tester, à l'évidence, une grille de 1 000 serveurs. Cependant, il peut tester une grille de données beaucoup plus petite en tenant compte des raisons budgétaires, de sorte que vous n'avez pas besoin d'acheter deux fois le matériel, en particulier pour un si grand nombre de serveurs.
  2. Différentes versions d'application : l'utilisation d'un grand nombre de sous-systèmes de stockage pour chaque unité d'exécution de test n'est pas pratique. Le risque est de ne pas tester les mêmes facteurs que si vous étiez dans un environnement de production.
  3. Perte de données : l'exécution d'une base de données sur un lecteur de disque dur n'est pas fiable. Tout problème avec le disque dur peut entraîner la perte de données. L'exécution d'une application dont la taille augmente sur une grille de données unique est similaire. Il est probable que vous rencontriez des bogues dans votre environnement et vos applications. Le positionnement toutes les données sur un seul grand système mène souvent à la perte d'un grand nombre de données.

Fractionnement de la grille de données

Le fractionnement de la grille de données de l'application en capsules (unités) est une option plus fiable. Une capsule est un groupe de serveurs qui exécutent une pile d'applications homogènes. Les capsules peuvent avoir n'importe quelle taille, mais elles doivent idéalement se composer de 20 serveurs physiques. Au lieu d'avoir 500 serveurs physiques dans une grille de données unique, vous pouvez avoir 25 capsules de 20 serveurs physiques. Une seule version d'une pile d'applications doit s'exécuter dans une capsule donnée, mais les différentes capsules peuvent avoir leur propre version d'une pile d'applications.

Généralement, une pile d'applications prend en compte les niveaux des composants suivants.
  • système d'exploitation
  • matériel
  • machines virtuelles Java
  • version d'WebSphere eXtreme Scale
  • application
  • autres composants nécessaires

Une capsule est une unité de déploiement de taille adaptée aux tests. Dans le cadre des tests, il est plus pratique d'avoir 20 serveurs plutôt que plusieurs centaines. Vous continuez néanmoins de tester la même configuration que vous auriez en production. La production utilise des grilles de 20 serveurs maximum, chacune constituant une capsule. Vous pouvez effectuer des tests de contrainte sur une capsule, puis déterminer sa capacité, le nombre d'utilisateurs, la quantité de données et la capacité de traitement. Cela facilite la planification et permet une évolutivité et des coûts prévisibles.

Configuration d'un environnement basé sur capsule

Selon les cas, la capsule ne contient pas forcément 20 serveurs. La taille de la capsule doit être adaptée aux tests. La taille d'une capsule doit être telle que, si la capsule rencontre un problème en production, la quantité des transactions affectées est tolérable.

Dans l'absolu, un bogue affecte une seule capsule. Un bogue n'aurait un impact que sur quatre pourcent des transactions de l'application, au lieu de 100 %. De plus, les mises à niveau sont facilitées, car elles peuvent être appliquées à une seule capsule à la fois. De ce fait, si une mise à niveau vers une capsule crée des problèmes, l'utilisateur peut ramener la capsule au niveau antérieur. Les mises à niveau incluent toutes les modifications apportées à l'application, la pile d'applications ou les mises à jour système. Dans la mesure du possible, les mises à niveau doivent modifier un seul élément de la pile à la fois, afin de permettre un diagnostic plus précis des problèmes.

Pour implémenter un environnement, vous avez besoin d'une couche de routage au-dessus des capsules qui soit compatible avec les versions antérieures et ultérieures si les capsules reçoivent des mises à niveau de logiciel. Vous devez également créer un répertoire contenant les informations sur le contenu de chaque capsule. Vous pouvez utiliser une autre grille de données eXtreme Scale pour cela avec une base de données derrière, de préférence dans un scénario d'écriture différée. Cela génère une solution à deux niveaux. Le niveau 1 est le répertoire, et est utilisé pour déterminer quelle capsule gère quelle transaction. Le niveau 2 se compose des capsules. Lorsque le niveau 1 identifie une capsule, la configuration achemine chaque transaction vers le serveur approprié dans la capsule, qui est généralement le serveur contenant la partition pour les données utilisées par la transaction. Le cas échéant, vous pouvez également utiliser un cache proche sur le niveau 1 afin de minimiser l'impact généré par la recherche de la capsule adéquate.

L'utilisation de capsules est légèrement plus complexe que l'utilisation d'une grille de données unique, mais le fonctionnement, les tests et l'amélioration de la fiabilité en font un élément essentiel du test d'évolutivité.