Performances de reprise en ligne sous IBM i

Le temps nécessaire à la détection d'une instance de gestionnaire de files d'attente a échoué, puis la reprise du traitement sur une instance de secours peut varier entre des dizaines de secondes et quinze minutes ou plus en fonction de la configuration. Les performances doivent être une considération majeure lors de la conception et du test d'une solution à haute disponibilité.

Il existe des avantages et des inconvénients à prendre en compte lors de la configuration d'un gestionnaire de files d'attente multi-instance pour utiliser la réplication de journal ou un ASP indépendant. La mise en miroir nécessite que le gestionnaire de files d'attente écrive de manière synchrone dans un journal éloigné. D'un point de vue matériel, cela n'a pas besoin d'affecter les performances, mais du point de vue logiciel, il y a une plus grande longueur de chemin d'accès à l'écriture dans un journal éloigné que dans un journal local, ce qui peut réduire les performances d'un gestionnaire de files d'attente en cours d'exécution dans une certaine mesure. Toutefois, lorsque le gestionnaire de files d'attente de secours prend le relais, le délai de synchronisation de son journal local à partir du journal éloigné géré par l'instance active avant l'échec est généralement faible par rapport au temps nécessaire à IBM® i pour détecter et transférer l'ASP indépendant sur le serveur exécutant l'instance de secours du gestionnaire de files d'attente. Les temps de transfert de l'ASP indépendant peuvent atteindre jusqu'à dix à quinze minutes au lieu d'être terminés en secondes. Le temps de transfert de l'ASP indépendant dépend du nombre d'objets qui doivent être mis en fonction lorsque l'ASP indépendant est transféré sur le système de secours et de la taille des chemins d'accès, ou des index, qui doivent être fusionnés.

Lorsque le gestionnaire de files d'attente de secours prend le relais, le délai de synchronisation de son journal local à partir du journal éloigné géré par l'instance active avant l'échec est généralement faible par rapport au temps nécessaire à IBM i pour détecter et transférer l'ASP indépendant sur le serveur exécutant l'instance de secours du gestionnaire de files d'attente. Les temps de transfert de l'ASP indépendant peuvent aller jusqu'à dix à quinze minutes au lieu d'être effectués en secondes. La durée de transfert de l'ASP indépendant dépend du nombre d'objets qui doivent être mis en fonction lorsque l'ASP indépendant est transféré sur le système de secours et de la taille des chemins d'accès, ou des index, qui doivent être fusionnés.

Toutefois, le transfert du journal n'est pas le seul facteur qui influence le temps nécessaire à la reprise complète de l'instance de secours. Vous devez également prendre en compte le temps nécessaire au système de fichiers du réseau pour libérer le verrou sur les données du gestionnaire de files d'attente qui sont envoyées à l'instance de secours pour tenter de poursuivre son démarrage, ainsi que le temps nécessaire à la reprise des files d'attente à partir du journal afin que l'instance puisse recommencer à traiter les messages. Ces autres sources de retard s'ajoutent au temps nécessaire au démarrage d'une instance de secours. La durée totale du basculement comprend les composants suivants:

Heure de détection des incidents: Temps nécessaire à NFS pour libérer le verrou sur les données du gestionnaire de files d'attente et à l'instance de secours pour poursuivre son processus de démarrage.
Durée de transfert: Dans le cas d'un cluster à haute disponibilité, le temps nécessaire à IBM i pour transférer l'ASP indépendant du système hébergeant l'instance active vers l'instance de secours, et dans le cas de la réplication de journal, le temps nécessaire à la mise à jour du journal local sur la base de secours avec les données de la réplique distante.
Heure de redémarrage: Temps nécessaire à l'instance de gestionnaire de files d'attente nouvellement active pour régénérer ses files d'attente à partir du dernier point de contrôle dans son journal restauré et pour reprendre le traitement des messages.
Remarque :
Si l'instance de secours qui a pris le relais est configurée pour être répliquée de manière synchrone sur l'instance précédemment active, le démarrage peut être retardé. Il se peut que la nouvelle instance activée ne puisse pas être répliquée dans son journal distant, si le journal distant se trouve sur le serveur qui a hébergé l'instance active précédente et que le serveur ait échoué.

Le délai d'attente par défaut d'une réponse synchrone est d'une minute. Vous pouvez configurer le délai maximal avant l'expiration de la réplication. Vous pouvez également configurer des instances de secours pour commencer à utiliser la réplication asynchrone sur l'instance active qui a échoué. Vous basculez ensuite vers la réplication synchrone, lorsque l'instance ayant échoué s'exécute à nouveau sur la base de données de secours. Il en va de même pour l'utilisation de miroirs ASP indépendants synchrones.

Vous pouvez effectuer des mesures de référence distinctes pour ces composants pour vous aider à évaluer la durée globale de la reprise en ligne et à prendre en compte dans votre décision l'approche de configuration à utiliser. Pour prendre la meilleure décision de configuration, vous devez également tenir compte de la façon dont d'autres applications sur le même serveur basculeront et de la présence ou non de processus de sauvegarde ou de reprise après incident qui utilisent déjà l'ASP indépendant.

Les temps de transfert de l'ASP indépendant peuvent être raccourcis en optimisant la configuration de votre grappe:

Les profils utilisateur des systèmes du cluster doivent avoir le même ID groupe et le même ID utilisateur pour que le processus de mise en fonction n'ait pas besoin de modifier les ID groupe et les ID groupe.
Réduisez le nombre d'objets de base de données dans le système et les pools de stockage sur disque utilisateur de base, car ils doivent être fusionnés pour créer la table de références croisées pour le groupe de pools de stockage sur disque.
D'autres conseils sur les performances sont disponibles dans le document IBM Redbook, Implémentation PowerHA® for IBM i, SG24-7405.

Une configuration utilisant des ASP de base, la mise en miroir du journal et une configuration de petite taille doit basculer de l'ordre de plusieurs dizaines de secondes.