[AIX Solaris HP-UX Linux Windows][IBM i]

Clusters de secours

Les clusters de secours reflètent les clusters de serveurs principaux. Le support de clusters en miroir ne concerne que les demandes EJB (Enterprise JavaBeans).

Fonction obsolète Fonction obsolète: Les clusters de sauvegarde sont obsolètes dans WebSphere Application Server version 9. Plutôt que d'utiliser des Clusters de sauvegarde IIOP sur plusieurs cellules à l'aide de ponts intergroupes centraux, vous devez envisager d'encapsuler les fonctions EJB avec des interfaces REST. Utilisez ensuite l'équilibrage de charge frontal, par exemple avec un routeur On Demand, afin d'équilibrer la charge. depfeat

Quand aucun membre d'un cluster n'est plus disponible pour les demandes EJB (Enterprise JavaBeans) de service, les clients qui doivent interagir avec l'un des serveurs d'applications EJB (Enterprise JavaBeans) du cluster ne fonctionnent pas. Les clusters en miroir permettent à un cluster EJB (cluster principal) de faire appel à un autre EJB (cluster de secours) lorsqu'aucun serveur d'applications EJB du cluster principal n'est en mesure de servir une demande. Grâce au cluster de secours, le client peut continuer à fonctionner quand tous les membres du cluster principal sont indisponibles.

Le basculement est automatique. Il n'est pas nécessaire de l'initialiser sur le cluster principal après le redémarrage des serveurs qu'il contient. Le cluster de secours cesse de répondre aux demandes dès que le cluster principal est à nouveau disponible. Toutefois, tous les gestionnaires de déploiement doivent être fonctionnels pour autoriser la prise en charge du cluster de secours et le cluster principal doit être défini comme dispositif de secours du cluster de secours.

Pour que le cluster de secours traite efficacement les demandes de service, les conditions ci-dessous doivent être réunies.
  • Les objets et les ressources du cluster principal doivent être également disponibles sur le cluster de secours.
  • Vous devez utiliser le même nom de cluster, installer les mêmes applications, utiliser les mêmes noms d'application et définir les mêmes ressources sur les deux clusters.
  • Le cluster principal et le cluster de secours doivent résider dans des cellules séparées car chaque cluster doit porter un nom unique à l'intérieur d'une même cellule.
  • Le cluster principal et le cluster de secours sont cluster de secours de l'autre.

Comme les deux clusters résident dans des cellules différentes, avec la version courante du produit, les clusters résident également dans des groupes centraux différents. Vous devez configurer le service de passerelle du groupe central et activer la communication entre des groupes centraux. Ce service élimine la nécessité d'exécuter un gestionnaire de déploiement et un agent de noeud pour la prise en charge du cluster de secours. Dans la version précédente, si le gestionnaire de déploiement s'arrêtait, les nouvelles demandes ne pouvaient pas être envoyées au cluster de secours après la défaillance du cluster principal. Tout serveur de passerelle de groupe central configuré dans la cellule qui contient le cluster principal peut fournir des informations sur le cluster de secours. La prise en charge du cluster de secours n'échoue que si tous les serveurs de passerelle de groupe central d'une cellule ne sont pas en cours d'exécution.

La reprise de données (du cluster principal vers le cluster de secours ou inversement) ne peut fonctionner correctement que si tous les serveurs, dont le gestionnaire de déploiement, les agents de noeud et les serveurs d'applications, du cluster principal et du cluster de secours sont dotés de la même version et du même niveau de support de clusters en miroir.

Le support de clusters en miroir n'est pas configuré par défaut. Pour utiliser le support de clusters en miroir, vous devez spécifier des clusters de secours dans votre configuration. Chaque cluster ne peut posséder qu'un cluster de secours qui doit être configuré en tant que tel avant son utilisation.

Pour configurer un cluster de secours dans un cluster, vous devez indiquer une adresse d'amorçage du domaine. L'hôte d'amorçage est l'ordinateur contenant le gestionnaire de déploiement dans lequel le cluster de secours est configuré. Le port d'amorçage est celui du gestionnaire de déploiement.

Le cluster principal et le cluster de secours doivent résider dans des cellules séparées. Pour placer des clusters en miroir dans des cellules séparées, configurez l'adresse d'amorçage du domaine du cluster de secours approprié. L'hôte et le port d'amorçage du cluster de secours déterminent quelles cellules contiennent ce cluster.

Pour configurer un cluster de secours, vous pouvez utiliser la console d'administration ou le MBean (bean géré) ExtendedCluster. Pour configurer le cluster de secours à l'aide de la console d'administration, procédez comme suit :
  • Utilisez l'onglet Configuration de la page Adresse d'amorçage du domaine pour définir de manière statique le cluster de secours. La valeur statique est utilisée lors de chaque démarrage du gestionnaire de déploiement.
  • Utilisez l'onglet Exécution de la page Adresse d'amorçage du domaine pour définir le cluster de secours lorsque le cluster fonctionne. Lorsque le gestionnaire de déploiement s'arrête, les informations qui définissent le cluster de secours sont annulées.

Comme les deux clusters résident dans des cellules différentes, avec la version courante du produit, les clusters résident également dans des groupes centraux différents. Vous devez configurer le service de passerelle du groupe central et activer la communication entre des groupes centraux. Utilisez un groupe de points d'accès pour associer les deux groupes centraux. Dans le gestionnaire de déploiement de la cellule principale, configurez un groupe de points d'accès comportant le point d'accès du groupe central pour la cellule de secours comme point d'accès homologue. Dans le gestionnaire de déploiement de la cellule de secours, créez un groupe de points d'accès portant le même nom que le groupe de points d'accès créé dans la cellule principale. Ajoutez un point d'accès homologue faisant référence au point d'accès du groupe central dans la cellule principale.

Si vous configurez un cluster de secours à l'aide du MBean ExtendedCluster, vous ne pouvez modifier que la configuration d'exécution. La modification du MBean ne concerne pas la configuration statique. Pour modifier la configuration d'exécution, vous pouvez utiliser l'opération setBackup sur le MBean ExtendedCluster. Par exemple, le code Java ci-dessous permet de définir le cluster de secours du cluster principal :

ac.invoke(extendedCluster, "setBackup", new Object[] {
  backupClusterName, backupBootstrapHost, backupBootstrapPort},
  new String[] {
    "java.lang.String", "java.lang.String", "java.lang.Integer"});

Dans cet exemple, ac désigne le client d'administration (AdminClient), et extendedCluster est le nom d'objet de cluster étendu (ExtendedClusterObjectName) du cluster principal.

Le support du basculement entre clusters fonctionne dans les deux scénarios suivants.
  • Dans le premier scénario, le client adresse ses demandes au cluster principal, qui arrête de les traiter. Les demandes sont alors transférées vers le cluster de secours. Initialement, le client a envoyé des demandes au cluster principal, et de ce fait possède des informations sur celui-ci. Par conséquent, quand le cluster principal est à nouveau disponible, les demandes basculent du cluster de secours vers le cluster principal.
  • Dans le second scénario, le client ne commence à adresser des demandes qu'après l'arrêt du cluster principal, ce qui signifie qu'elles sont dirigées directement vers le cluster de secours. Dans ce cas, le client dispose d'informations sur le cluster de secours uniquement. Comme le client ne connaît que le cluster de secours, lorsque le cluster principal redémarre, les demandes émanant du client continuent à être acheminées vers le cluster de secours et le trafic ne bascule donc pas vers le cluster principal. Ce scénario intervient quand un objet est créé sur le cluster de secours. Dans ce cas, le cluster de secours devient cluster principal pour l'objet.
Ces deux scénarios peuvent se produire sur le même client simultanément, si celui-ci envoie des demandes à des objets existants et crée des objets après l'arrêt du cluster principal.

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_wlm_backupcluster
Nom du fichier : crun_wlm_backupcluster.html