LinkedInTwitterFacebook

Optimisation du DRP TSM avec DB2 HADR

logo-ibm-db2 Dans ses versions TSM 6.x, IBM offre une nouvelle fonction de haute disponibilité inhérente à DB2 : la synchronisation de bases DB2 HADR (High Availability for Disaster Recovery).

Il s'agit d'une fonction classique et depuis longtemps éprouvée dans le monde DB2 de Log Shipping: capture des Logs générées sur une instance primaire pour les rejouer sur l'instance de Standby. Elle permet ainsi de maintenir synchrones 2 instances DB2 et donc 2 bases de données TSM situées par exemple sur des sites éloignés.

La fonction HADR permet ainsi de réduire le RTO (Recovery Time Objective) et les coûts de mise en œuvre dans le cadre d'un PRA et peut être implémentée sans licence supplémentaire si la réplication est mise en place entre 2 instances TSM.

Un simple lien réseau et l'ouverture de ports spécifiques entre les 2 sites suffisent pour permettre la mise en place d'HADR.

HADR_LIGHTSDS

Les étapes de mise en œuvre sont très simples :

HADRLIGHT3

Une fois la synchronisation établie entre les 2 instances, le suivi pourra se faire soit de manière graphique,

HADR1

soit au travers de commandes DB2 soit encore directement au travers de TSM:

HADR           

Une alarme pourra ainsi facilement être envoyée aux administrateurs en cas détection de perte du lien,  le status HADR passant à l'état DISCONNECTED.

Une fois activée, chacune des instances pourra redémarrer (pour des opération de maintenance par exemple) sans que la configuration HADR ne soit perdue. Après redémarrage de l'une ou l'autre des instances, la synchronisation est de nouveau et automatiquement active.

Il s’avère toutefois qu'avec la version TSM 6.3.3.0, le redémarrage du serveur TSM Primaire pose problème et soit bloqué par la configuration HADR. Ce problème peut-être contourné en forçant la variable DB2  OVERFLOWLOGPATH à NULL et sera corrigé dans une version à venir prochainement.

Dans le cadre d'un DRP, la procédure de bascule est aussi très simple. Il suffit de couper le lien entre les 2 instances en arrêtant TSM (si ce n'est déjà le cas en conséquence du sinistre) sur le serveur Primaire, en démarrant ensuite l'instance de Standby en mode Rollforward et enfin en démarrant le serveur TSM sur le serveur de Standby.

On dispose alors d'une base TSM sur le site de Standby quasi instantanément et sans aucune perte de données.

Reste alors à nous assurer que l'on dispose de médias aussi à jour sur le site de Standby.