[IBM i]

Haute disponibilité : accès permanent aux données d'application

Sans un accès permanent aux données d'applications, les serveurs d'applications ne pourront pas traiter les demandes client. Le produit garantit la disponibilité des données de plusieurs manières.

Si les données résident sur des serveurs IBM® i, vous pouvez utiliser l'une des options ci-dessous pour améliorer la disponibilité des données.

Réplication des données

Pour que tous les composants de l'environnement du serveur d'applications soient toujours disponibles, vous pouvez utiliser la réplication des données pour créer une copie de sauvegarde des données d'applications. La réplication des données utilise la mise en cluster, la journalisation à distance et un logiciel de réplication des données tiers afin de gérer deux copies distinctes des données d'applications. Cette fonction peut fournir des capacités de reprise pour les bases de données car les systèmes faisant partie du cluster peuvent être installés sur des sites distincts.

La mise en cluster fournit les bases pour la communication entre deux serveurs ou plus. Cette dernière est nécessaire pour sauvegarder les données sur une machine distincte.

La journalisation à distance permet de créer une copie de vos données d'application afin d'assurer une sauvegarde à chaud. Il existe deux types de journalisation à distance.
  • La journalisation à distance synchrone, dans laquelle les données sont enregistrées dans deux bases de données à la fois, une base de données principale et une base de données de secours. Avec ce type de journalisation, aucune entrée n'est perdue en cas de panne système. Cela peut cependant réduire sensiblement les performances de l'application en raison du délai d'attente nécessaire à l'enregistrement des données dans les deux bases de données.
  • La journalisation à distance asynchrone, dans laquelle les données de l'application sont directement enregistrées dans la base de données principale. Avec ce type de journalisation, l'application peut continuer à traiter les demandes client pendant que les données sont copiées sur le système de secours. Cela n'a aucune incidence sur les performances de l'application, mais les entrées les plus récentes risquent d'être perdues en cas de défaillance du système.

Permutation du disque

Cette technique utilise la mise en cluster, la journalisation en local et le pool de mémoire secondaire indépendant (IASP) afin de garantir la disponibilité des données d'application. Ces dernières sont stockées dans un pool IASP qui, en cas de défaillance, peut être basculé vers un autre noeud.

L'avantage de cette technique est qu'elle ne nécessite pas de réplication de données. La synchronisation des données est donc assurée. En revanche, la base de données devient un point unique de défaillance. De plus, le noeud de secours doit être installé à proximité du noeud principal. Ainsi, cette configuration n'assure pas la reprise après incident.

La permutation du disque utilise les composants et services ci-dessous.
  • Un cluster de serveurs. Vous devez avoir installé la fonction High Availability Switchable Resources (5761-SS1 ou 5770-SS1 Option 41) sur tous les noeuds du cluster.
  • La mise en cluster. Lorsque vous utilisez la permutation du disque, la mise en cluster fournit :
    • le service requis pour basculer le pool IASP ;
    • la surveillance des partitions de base de données du système dorsal.
  • La journalisation en local. La permutation de disque utilise la journalisation en local pour préserver les limites des transactions de base de données.
Elle est particulièrement efficace dans une topologie à cellules multiples présentant les caractéristiques ci-dessous.
  • Toutes les cellules traitent les demandes client comme indiqué dans la topologie à cellules multiples.
  • L'une des cellules héberge la base de données principale qui reçoit les données provenant des serveurs d'applications contenus dans les autres cellules.
  • La base de données principale se connecte à un pool IASP.
  • L'une des autres cellules héberge la base de données secondaire qui reste inactive tant que la base de données principale fonctionne normalement. Si cette dernière est défaillante, les données d'application sont dirigées vers la base de données secondaire contenue dans cette autre cellule et le pool IASP se connecte à cette deuxième base de données.

Icône indiquant le type de rubrique Rubrique de concept



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=crun_ha_datasource
Nom du fichier : crun_ha_datasource.html