Les bases de données telles que DB2/390 comportent un partitionnement intégré et il n'est pas toujours nécessaire de partitionner la base de données dans l'application.
Vous pouvez configurer un cluster extrêmement fiable pour exécuter l'application mais si ce cluster utilise une instance de base de données unique, celle-ci devient un point unique de défaillance et limite l'extension verticale. La base de données représente un point unique de défaillance car si elle n'est plus disponible, aucune tâche ne peut être effectuée dans le cluster. Cette configuration bloque l'extension verticale car la plupart des bases de données sont disposées de manière verticale pour effectuer les traitements plus rapidement. Vous devez donc acquérir un plus grand système.
Le schéma ci-dessous présente une architecture avec un serveur de base de données unique. Dans ce schéma, il y a deux systèmes WebSphere Application Server mais un seul serveur de base de données. Au fur et à mesure que des serveurs d'applications sont ajoutés, la base de données devient un goulet d'étranglement.
Vous pouvez décider d'utiliser des bases de données disposées de manière horizontale, qui n'arrêtent pas l'ensemble du cluster du serveur d'applications en cas de défaillance. De nombreuses applications acceptent que des défaillances temporaires affectent certains de leurs composants mais ne tolèrent pas un arrêt total.Ces architectures utilisent une conception fondée sur des bases de données partitionnées.
Par exemple, cette conception peut comprendre trois systèmes exécutant une base de données DB2 autonome. Le schéma des tables et le système de sécurité sont les mêmes pour les trois bases de données. Toutes les données de référence disponibles en lecture seule sont répliquées dans les trois bases de données à partir d'une instance DB2 maître des données de référence dont la haute disponibilité est assurée selon la procédure standard. Cette instance DB2 maître n'est pas un point de défaillance unique lors d'un fonctionnement normal car elle n'est pas utilisée directement par l'application.
Une fois que vous avez configuré plusieurs serveurs, l'étape suivante consiste à vous assurer que les données de l'application peuvent être partitionnées. Mappez les données d'une partition à une instance DB2 à l'aide d'une procédure de hachage simple, d'un mécanisme de définition de plages ou d'une table répliquée dans les bases de données. La table est mise en cache par le cluster du serveur d'applications et elle définit l'instance DB2 contenant les données d'une partition spécifique. Ce mécanisme permet de déplacer des données actives entre des bases de données sans entraîner le changement d'applications.
La partition associée à une table de l'instance DB2 est gérée par la base maître et répliquée sur les trois noeuds de bases de données. Un protocole d'application est nécessaire pour coordonner une partition d'une base de données avec une autre. Grâce au mécanisme de coordination, l'application peut ajouter une instance de base de données à l'ensemble des bases de données utilisées pour une extension horizontale. L'utilisation de trois instances de base de données indépendantes présente l'avantage d'offrir une plus grande disponibilité qu'une base de données en cluster standard, telle qu'Oracle RAC ou DB2 EEE. Les bases de données sont indépendantes et la défaillance de l'une d'entre elles entraîne uniquement l'indisponibilité des jeux de données qu'elle contient. L'application peut continuer à traiter les transactions pour les données résidant dans les autres instances de base de données actives.
Cette situation est préférable à une défaillance complète. Toutefois, l'administration est désormais plus complexe car il y a trois bases de données au lieu d'une seule. L'application utilise des transactions dirigées pour indiquer au serveur d'applications l'instance de base de données contenant l'ensemble des données pour la transaction suivante. Ce mécanisme permet une gestion extrêmement souple de la base de données, notamment lorsque la table MAPPER est utilisée pour indiquer à l'application le noeud de base de données qui contient les données d'une partition spécifique.
WebSphere Extended Deployment comporte une nouvelle fonction appelée "source de données proxy", qui permet à l'application d'indiquer la base de données à utiliser avant le début de la transaction. Lorsqu'un membre du cluster reçoit une demande destinée à une partition d'application spécifique, il peut demander à l'environnement d'exécution CMP d'ignorer la source de données avec laquelle les beans ont été déployés et faire appel à une source de données particulière au cours de la transaction suivante. Le mécanisme de transaction dirigée peut être utilisé avec l'application pour augmenter sa disponibilité et permettre aux infrastructures de bases de données de s'étendre horizontalement dans des environnements de serveurs de type "blade". Les applications peuvent également tirer parti du mécanisme de la table MAPPER pour gérer des données et déplacer des partitions.
Le schéma suivant présente la nouvelle architecture. Avec deux bases de données, l'EJB "EJB1" est déployé sur les deux serveurs. Dans une transaction, l'EJB "EJB1" situé sur le serveur du haut accède à la base de données 1. Dans une autre transaction, l'EJB "EJB2" situé sur le serveur du bas accède à la base de données 2. La charge des bases de données est donc répartie entre plusieurs serveurs de base de données au lieu d'un seul serveur.
Related concepts
Fonctions de partitionnement J2EE