Haute disponibilité et reprise après incident

Modifier en ligne

Pour activer la haute disponibilité (HA), définissez une installation Directory Sync secondaire avec la même configuration que l'installation principale, sauf que le processus Directory Sync secondaire ne doit pas être en cours d'exécution.

Le processus Directory Sync secondaire doit avoir accès à une copie à jour du fichier cookie.bin. Ce fichier contient l'état de synchronisation régulièrement sauvegardé par Directory Sync lors de la synchronisation d'Active Directory ou de LDAP avec Cloud Directory.

Une fois que Directory Sync a terminé l'envoi de chaque série de mises à jour vers IBM® Verify, il met à jour le fichier cookie avec les informations permettant d'identifier la dernière mise à jour synchronisée depuis Active Directory ou LDAP.

Si le processus Directory Sync principal s'arrête lors de la synchronisation d'un lot de modifications, le processus secondaire doit être démarré. Le processus secondaire peut être démarré manuellement ou par un système de surveillance automatisé. Il interroge Active Directory ou LDAP pour obtenir toutes les mises à jour basées sur les informations du cookie. Il tente de synchroniser la même série de modifications que celles traitées par le processus principal. Des erreurs peuvent être consignées pour les mises à jour qui ont déjà été envoyées à Verify.

Il existe plusieurs méthodes pour maintenir le fichier cookie.bin synchronisé entre le processus principal et le processus secondaire. Le stockage du cookie sur un système de fichiers partagé est une solution possible décrite dans l'exemple ci-dessous. Une autre solution possible consiste à utiliser un script OpenSSH scp et l'option de tâche planifiée de Windows™ (Schtasks).

Pour partager le fichier cookie.bin à l'aide d'un système de fichiers partagé, configurez le fichier cookie.bin sur un système de fichiers réseau (NFS) ou une unité sécurisée. Les deux processus Dir Sync principal et secondaire doivent avoir accès à l'unité partagée.

Par exemple, configurez le fichier cookie.bin sur un système de fichiers réseau (NFS) ou une unité sécurisée. Les deux processus Dir Sync principal et secondaire doivent avoir accès à l'unité partagée et être configurés pour l'utiliser. Pour la cohérence op_log, configurez également le fichier op_log sur l'unité partagée. Dans les exemples ci-dessous, le processus Dir Sync principal s'appelle sharehost, l'unité partagée est shared et les fichiers sont placés dans un répertoire sur le partage dirsync. Le chemin UNC du répertoire partagé est \\sharehost\shared\dirsync.

Utilisez l'option cookie-file pour configurer l'emplacement du fichier cookie.bin. Pour plus d'informations sur ces options, consultez la section « L'objet JSON cloud-bridge ».

"cloud-bridge": {
    "cookie-file": 
"\\\\sharehost\\shared\\dirsync\\cookie.bin",
    …

Utilisez l'option op-log-file pour configurer l'emplacement du fichier op_log.

"cloud-bridge": {
    "op-log-file": "\\\\sharehost\\shared\\dirsync\\op_log\\op_log.csv",    
…

Remarque : dans les exemples précédents, les \\sharehost\shared\dirsync répertoires et \\sharehost\shared\dirsync\op_log doivent exister. Le service Directory Sync doit être exécuté avec un compte utilisateur réel qui est autorisé à accéder au partage.

L'administrateur doit détecter manuellement la défaillance du processus principal et démarrer le processus secondaire ou mettre en place un système de surveillance automatique. IBM ne propose pas de système automatique de surveillance et de basculement. Comme indiqué précédemment, toute configuration de surveillance automatique et de reprise en ligne ne doit pas permettre l'exécution simultanée du processus principal et du processus secondaire.