Haute disponibilité d’IBM Db2 LUW sur les machines virtuelles Azure sur SUSE Linux Enterprise Server avec Pacemaker
IBM Db2 pour Linux, UNIX et Windows (LUW) dans une configuration de haute disponibilité et reprise d’activité (HADR) est constitué d’un nœud qui exécute une instance de base de données primaire et d’au moins un nœud qui exécute une instance de base de données secondaire. Les modifications apportées à l’instance de base de données primaire sont répliquées vers une instance de base de données secondaire de façon synchrone ou asynchrone, selon votre configuration.
Remarque
Cet article contient des références à des termes que Microsoft n’utilise plus. Lorsque ces termes seront supprimés du logiciel, nous les supprimerons de cet article.
Cet article décrit comment déployer et configurer les machines virtuelles Azure, installer le framework de cluster, et installer IBM Db2 LUW avec la configuration HADR.
L’article n’explique pas comment installer et configurer IBM Db2 LUW avec l’installation des logiciels SAP ou HADR. Pour vous aider à accomplir ces tâches, nous fournissons des références aux manuels d’installation SAP et IBM. Cet article se concentre sur des composants qui sont spécifiques à l’environnement Azure.
Les versions IBM Db2 prises en charge sont 10.5 et ultérieures, comme décrit dans la note SAP 1928533.
Avant de commencer une installation, consultez les notes SAP suivantes et la documentation :
| Note SAP | Description |
|---|---|
| 1928533 | Applications SAP sur Azure : Produits et types de machines virtuelles pris en charge |
| 2015553 | SAP sur Azure : Prérequis pour la prise en charge |
| 2178632 | Métriques de supervision clés pour SAP sur Azure |
| 2191498 | SAP sur Linux avec Azure : Surveillance améliorée |
| 2243692 | Linux sur une machine virtuelle Azure (IaaS) : problèmes de licence SAP |
| 1984787 | SUSE LINUX Enterprise Server 12 Notes d'installation |
| 1999351 | Résolution des problèmes de la surveillance Azure améliorée pour SAP |
| 2233094 | DB6 : applications SAP sur Azure qui utilisent IBM Db2 pour Linux, UNIX et Windows - informations supplémentaires |
| 1612105 | DB6 : forum aux questions sur Db2 avec HADR |
Vue d’ensemble
Pour obtenir une haute disponibilité, IBM Db2 LUW avec HADR est installé sur au moins deux machines virtuelles Azure, qui sont déployées dans un groupe de machines virtuelles identiques avec une orchestration flexible sur des zones de disponibilité ou dans un groupe à haute disponibilité.
Les graphiques suivants illustrent une configuration de deux machines virtuelles Azure de serveur de base de données. Les deux machines virtuelles Azure de serveur de base de données sont associées à leur propre système de stockage et sont opérationnelles. Dans HADR, une instance de base de données dans l’une des machines virtuelles Azure a le rôle de l’instance primaire. Tous les clients sont connectés à cette instance primaire. Toutes les modifications dans les transactions de base de données sont conservées localement dans le journal des transactions Db2. Comme les enregistrements du journal des transactions sont conservés localement, les enregistrements sont transférés via TCP/IP à l’instance de base de données sur le second serveur de base de données, le serveur de secours ou une instance de secours. L’instance de secours met à jour la base de données locale en restaurant par progression les enregistrements du journal des transactions transférés. De cette façon, le serveur de secours est synchronisé avec le serveur principal.
HADR est uniquement une fonctionnalité de réplication. Elle n’assure pas la détection des défaillances et n’a aucune fonction de prise de contrôle ou basculement automatique. Une prise de contrôle ou un transfert vers le serveur de secours doit être lancé manuellement par un administrateur de base de données. Pour obtenir une prise de contrôle automatique et une détection des défaillances, vous pouvez utiliser la fonctionnalité de clustering Linux Pacemaker. Pacemaker supervise les deux instances de serveur de base de données. Lorsque l’instance de serveur de base de données primaire plante, Pacemaker lance une prise de contrôle HADR automatique par le serveur de secours. Pacemaker garantit également que l’adresse IP virtuelle est affectée au nouveau serveur principal.
Pour que les serveurs d’applications SAP se connectent à la base de données primaire, vous avez besoin d’un nom d’hôte virtuel et d’une adresse IP virtuelle. Après un basculement, les serveurs d’applications SAP se connectent à la nouvelle instance de base de données primaire. Dans un environnement Azure, un équilibreur de charge Azure est nécessaire pour utiliser une adresse IP virtuelle de la façon requise pour HADR d’IBM Db2.
Pour vous aider à mieux comprendre comment IBM Db2 LUW avec HADR et Pacemaker s’adapte à une configuration de système SAP hautement disponible, l’image suivante présente une vue d’ensemble d’une configuration hautement disponible d’un système SAP basé sur une base de données IBM Db2. Cet article couvre uniquement IBM Db2, mais il fournit des références à d’autres articles sur la façon de configurer d’autres composants d’un système SAP.
Vue d’ensemble globale des étapes à suivre
Pour déployer une configuration IBM Db2, vous devez procéder comme suit :
- Planifiez votre environnement.
- Déployez les machines virtuelles.
- Mettez à jour SUSE Linux et configurez des systèmes de fichiers.
- Installez et configurez Pacemaker.
- Installez un système NFS à haute disponibilité.
- Installez ASCS/ERS sur un cluster séparé.
- Installez la base de données IBM Db2 avec l’option Distributed/High Availability (Distribué/Haute disponibilité) (SWPM).
- Installez et créez une instance et un nœud de base de données secondaire, et configurez HADR.
- Vérifiez que HADR fonctionne.
- Appliquez la configuration Pacemaker pour contrôler IBM Db2.
- Configurez Azure Load Balancer.
- Installez des serveurs d’applications principal et de boîte de dialogue.
- Vérifiez et adaptez la configuration des serveurs d’applications SAP.
- Effectuez des tests de basculement et de prise de contrôle.
Planifier l’infrastructure Azure pour l’hébergement d’IBM Db2 LUW avec HADR
Terminez le processus de planification avant d’exécuter le déploiement. La planification génère la base pour le déploiement d’une configuration de Db2 avec HADR dans Azure. Les éléments clés qui doivent faire partie de la planification d’IMB Db2 LUW (partie base de données de l’environnement SAP) sont listés dans le tableau suivant :
| Rubrique | Description courte |
|---|---|
| Définir des groupes de ressources Azure | Groupes de ressources sur lesquels vous déployez la machine virtuelle, le réseau virtuel, Azure Load Balancer et d’autres ressources. Ils peuvent être nouveaux ou existants. |
| Définition de sous-réseau/réseau virtuel | Endroit où des machines virtuelles pour IBM Db2 et Azure Load Balancer sont déployées. Elles peuvent être existantes ou récemment créées. |
| Machines virtuelles hébergeant IBM Db2 LUW | Taille de machine virtuelle, stockage, mise en réseau, adresse IP. |
| Nom d’hôte virtuel et adresse IP virtuelle pour la base de données IBM Db2 | Adresse IP virtuelle ou nom d’hôte utilisé pour la connexion des serveurs d’applications SAP. db-virt-hostname, db-virt-ip. |
| Délimitation Azure | Délimitation Azure ou isolation SBD (hautement recommandée). Méthode permettant d’éviter les situations de Split-Brain. |
| Machine virtuelle SBD | Taille de la machine virtuelle SBD, stockage, réseau. |
| Azure Load Balancer | Utilisation du niveau Standard (recommandé), port de la sonde pour la base de données Db2 (notre recommandation est 62500) probe-port. |
| Résolution de noms | Fonctionnement de la résolution de noms dans l’environnement. Le service DNS est fortement recommandé. Le fichier d’hôte local peut être utilisé. |
Pour plus d’informations sur Linux Pacemaker dans Azure, consultez Configurer Pacemaker sur SUSE Linux Enterprise Server dans Azure.
Important
Pour db2 versions 11.5.6 et ultérieures, nous vous recommandons vivement d’utiliser la solution intégrée à l’aide de Pacemaker d’IBM.
Déploiement sur SUSE Linux
L’agent de ressource pour IBM Db2 LUW est inclus dans SUSE Linux Enterprise Server pour applications SAP. Pour la configuration qui est décrite dans ce document, vous devez utiliser SUSE Linux Server pour applications SAP. La Place de marché Azure contient une image de SUSE Enterprise Server pour applications SAP 12 que vous pouvez utiliser pour déployer de nouvelles machines virtuelles Azure. Soyez conscient des différents modèles de prise en charge ou service proposés par SUSE via la Place de marché Azure quand vous choisissez une image de machine virtuelle dans la Place de marché de machines virtuelles Azure.
Hôtes : Mises à jour de DNS
Dressez la liste de tous les noms d’hôte, y compris les noms des hôtes virtuels, et mettez à jour vos serveurs DNS afin d’activer une adresse IP appropriée pour la résolution de nom d’hôte. S’il n’existe aucun serveur DNS ou que vous ne pouvez pas mettre à jour et créer des entrées DNS, vous devez utiliser les fichiers d’hôte local des machines virtuelles individuelles qui font partie de ce scénario. Si vous utilisez des entrées des fichiers d’hôte, assurez-vous que les entrées sont appliquées à toutes les machines virtuelles dans l’environnement du système SAP. Toutefois, nous vous recommandons d’utiliser votre serveur DNS qui, dans l’idéal, s’étend à Azure
Déploiement manuel
Vérifiez que le système d’exploitation sélectionné est pris en charge par IBM/SAP pour IBM Db2 LUW. La liste des versions de système d’exploitation prises en charge pour les machines virtuelles Azure et les versions Db2 est disponible dans la note SAP 1928533. La liste des versions de système d’exploitation par version Db2 individuelle est disponible dans le tableau de disponibilité des produits SAP. Nous recommandons vivement SLES 12 SP4 au minimum en raison d’améliorations des performances liées à Azure dans cette version ou une version SUSE Linux ultérieure.
- Créez ou sélectionnez un groupe de ressources.
- Créez ou sélectionnez un réseau virtuel et un sous-réseau.
- Choisissez un type de déploiement approprié pour des machines virtuelles SAP. Un groupes de machines virtuelles identiques à orchestration flexible en général.
- Créez la machine virtuelle 1.
- Utilisez l’image SLES pour SAP dans la Place de marché Azure.
- Sélectionnez le groupe identique, la zone de disponibilité ou le groupe à haute disponibilité créé à l’étape 3.
- Créez la machine virtuelle 2.
- Utilisez l’image SLES pour SAP dans la Place de marché Azure.
- Sélectionnez le groupe identique, la zone de disponibilité ou le groupe à haute disponibilité créé à l’étape 3 (zone différente de celle de l’étape 4).
- Ajoutez des disques de données aux machines virtuelles et vérifiez ensuite la suggestion sur la configuration d’un système de fichiers dans l’article Déploiement SGBD de machines virtuelles Azure IBM Db2 pour charge de travail SAP.
Installer l’environnement SAP et IBM Db2 LUW
Avant de commencer l’installation d’un environnement SAP basé sur IBM Db2 LUW, passez en revue la documentation suivante :
- Documentation Azure
- Documentation SAP
- Documentation IBM
Des liens vers cette documentation sont fournis dans la section d’introduction de cet article.
Consultez les guides d’installation SAP sur l’installation d’applications basées sur NetWeaver sur IBM Db2 LUW.
Vous pouvez trouver les guides dans le portail d’aide SAP à l’aide de SAP Installation Guide Finder.
Vous pouvez réduire le nombre de guides affichés dans le portail en définissant les filtres suivants :
- Je souhaite : « Installer un nouveau système »
- Ma base de données : « IBM Db2 pour Linux, UNIX et Windows »
- Filtres supplémentaires pour les versions SAP NetWeaver, la configuration de pile ou le système d’exploitation
Conseils d’installation pour la configuration d’IBM Db2 LUW avec HADR
Pour configurer l’instance de base de données IBM Db2 LUW primaire :
- Utilisez l’option Distributed ou High Availability (Distribué ou Haute disponibilité).
- Installez SAP ASCS/ERS et l’instance de base de données.
- Effectuez une sauvegarde de la base de données nouvellement installée.
Important
Notez le « port de communication de la base de données » qui est défini lors de l’installation. Ce doit être le même numéro de port pour les deux instances de base de données 
Pour configurer le serveur de base de données de secours à l’aide de la procédure de copie de système homogène SAP, exécutez ces étapes :
Sélectionnez l’option System copy (Copie du système)>Target systems (Systèmes cibles) >Distributed (Distribué) >Database instance (Instance de base de données).
Comme méthode de copie, sélectionnez Homogeneous System (Système homogène) afin que vous puissiez utiliser la copie de sauvegarde pour restaurer une sauvegarde sur l’instance de serveur de secours.
Lorsque vous atteignez la dernière étape pour restaurer la base de données pour la copie de système homogène, quittez le programme d’installation. Restaurez la base de données à partir d’une sauvegarde de l’hôte principal. Toutes les phases d’installation suivantes ont déjà été exécutées sur le serveur de base de données principal.
Configurez HADR pour IBM Db2.
Notes
Pour une installation et une configuration spécifiques à Azure et Pacemaker : Au cours de la procédure d’installation via SAP Software Provisioning Manager, une question explicite se pose sur la haute disponibilité pour IBM Db2 LUW :
- Ne sélectionnez pas IBM Db2 pureScale.
- Ne sélectionnez pas Install IBM Tivoli System Automation for Multiplatforms (Installer IBM Tivoli System Automation pour plusieurs plateformes).
- Ne sélectionnez pas Generate cluster configuration files (Générer des fichiers de configuration de cluster).
Lorsque vous utilisez un appareil SBD pour Linux Pacemaker, définissez les paramètres HADR Db2 suivants :
- HADR peer window duration (seconds) (HADR_PEER_WINDOW) = 300
- HADR timeout value (HADR_TIMEOUT) = 60
Lorsque vous utilisez un agent de délimitation Azure Pacemaker, définissez les paramètres suivants :
- HADR peer window duration (seconds) (HADR_PEER_WINDOW) = 900
- HADR timeout value (HADR_TIMEOUT) = 60
Nous vous recommandons les paramètres précédents d’après les tests de basculement/prise de contrôle initiaux. Il est obligatoire de tester le bon fonctionnement du basculement et de la prise de contrôle avec ces paramètres. Étant donné que les configurations individuelles peuvent varier, les paramètres peuvent nécessiter un ajustement.
Important
Propre à IBM Db2 avec une configuration HADR et un démarrage normal : l’instance de base de données secondaire ou de secours doit être opérationnelle avant de pouvoir démarrer l’instance de base de données primaire.
À des fins de démonstration et pour les procédures décrites dans cet article, l’ID de sécurité de la base de données est PTR.
Vérification HADR IBM Db2
Une fois que vous avez configuré HADR et que l’état est PEER et CONNECTED sur les nœuds principal et de secours, effectuez la vérification suivante :
Execute command as db2<sid> db2pd -hadr -db <SID>
#Primary output:
# Database Member 0 -- Database PTR -- Active -- Up 1 days 01:51:38 -- Date 2019-02-06-15.35.28.505451
#
# HADR_ROLE = PRIMARY
# REPLAY_TYPE = PHYSICAL
# HADR_SYNCMODE = NEARSYNC
# STANDBY_ID = 1
# LOG_STREAM_ID = 0
# HADR_STATE = PEER
# HADR_FLAGS = TCP_PROTOCOL
# PRIMARY_MEMBER_HOST = azibmdb02
# PRIMARY_INSTANCE = db2ptr
# PRIMARY_MEMBER = 0
# STANDBY_MEMBER_HOST = azibmdb01
# STANDBY_INSTANCE = db2ptr
# STANDBY_MEMBER = 0
# HADR_CONNECT_STATUS = CONNECTED
# HADR_CONNECT_STATUS_TIME = 02/05/2019 13:51:47.170561 (1549374707)
# HEARTBEAT_INTERVAL(seconds) = 15
# HEARTBEAT_MISSED = 0
# HEARTBEAT_EXPECTED = 6137
# HADR_TIMEOUT(seconds) = 60
# TIME_SINCE_LAST_RECV(seconds) = 13
# PEER_WAIT_LIMIT(seconds) = 0
# LOG_HADR_WAIT_CUR(seconds) = 0.000
# LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000025
# LOG_HADR_WAIT_ACCUMULATED(seconds) = 434.595
# LOG_HADR_WAIT_COUNT = 223713
# SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
# SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 374400
# PRIMARY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
# STANDBY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
# HADR_LOG_GAP(bytes) = 0
# STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000280.LOG, 15571, 27902548040
# STANDBY_RECV_REPLAY_GAP(bytes) = 0
# PRIMARY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
# STANDBY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
# STANDBY_REPLAY_LOG_TIME = 02/06/2019 15:34:39.000000 (1549467279)
# STANDBY_RECV_BUF_SIZE(pages) = 2048
# STANDBY_RECV_BUF_PERCENT = 0
# STANDBY_SPOOL_LIMIT(pages) = 0
# STANDBY_SPOOL_PERCENT = NULL
# STANDBY_ERROR_TIME = NULL
# PEER_WINDOW(seconds) = 300
# PEER_WINDOW_END = 02/06/2019 15:40:25.000000 (1549467625)
# READS_ON_STANDBY_ENABLED = N
#Secondary output:
# Database Member 0 -- Database PTR -- Standby -- Up 1 days 01:46:43 -- Date 2019-02-06-15.38.25.644168
#
# HADR_ROLE = STANDBY
# REPLAY_TYPE = PHYSICAL
# HADR_SYNCMODE = NEARSYNC
# STANDBY_ID = 0
# LOG_STREAM_ID = 0
# HADR_STATE = PEER
# HADR_FLAGS = TCP_PROTOCOL
# PRIMARY_MEMBER_HOST = azibmdb02
# PRIMARY_INSTANCE = db2ptr
# PRIMARY_MEMBER = 0
# STANDBY_MEMBER_HOST = azibmdb01
# STANDBY_INSTANCE = db2ptr
# STANDBY_MEMBER = 0
# HADR_CONNECT_STATUS = CONNECTED
# HADR_CONNECT_STATUS_TIME = 02/05/2019 13:51:47.205067 (1549374707)
# HEARTBEAT_INTERVAL(seconds) = 15
# HEARTBEAT_MISSED = 0
# HEARTBEAT_EXPECTED = 6186
# HADR_TIMEOUT(seconds) = 60
# TIME_SINCE_LAST_RECV(seconds) = 5
# PEER_WAIT_LIMIT(seconds) = 0
# LOG_HADR_WAIT_CUR(seconds) = 0.000
# LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000023
# LOG_HADR_WAIT_ACCUMULATED(seconds) = 434.595
# LOG_HADR_WAIT_COUNT = 223725
# SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 46080
# SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 372480
# PRIMARY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
# STANDBY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
# HADR_LOG_GAP(bytes) = 0
# STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000280.LOG, 15574, 27902562173
# STANDBY_RECV_REPLAY_GAP(bytes) = 155
# PRIMARY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
# STANDBY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
# STANDBY_REPLAY_LOG_TIME = 02/06/2019 15:37:34.000000 (1549467454)
# STANDBY_RECV_BUF_SIZE(pages) = 2048
# STANDBY_RECV_BUF_PERCENT = 0
# STANDBY_SPOOL_LIMIT(pages) = 0
# STANDBY_SPOOL_PERCENT = NULL
# STANDBY_ERROR_TIME = NULL
# PEER_WINDOW(seconds) = 300
# PEER_WINDOW_END = 02/06/2019 15:43:19.000000 (1549467799)
# READS_ON_STANDBY_ENABLED = N
Configurer Azure Load Balancer
Pendant la configuration de la machine virtuelle, vous avez la possibilité de créer ou de sélectionner un équilibreur de charge existant dans la section réseau. Suivez les étapes ci-dessous pour configurer l’équilibreur de charge standard pour la configuration de la haute disponibilité de la base de données DB2.
Suivez les étapes dans Créer un équilibreur de charge pour configurer un équilibreur de charge standard pour un système SAP à haute disponibilité à l’aide du portail Azure. Pendant la configuration de l’équilibreur de charge, tenez compte des points suivants :
- Configuration d’une adresse IP front-end : créez une adresse IP front-end. Sélectionnez le même nom de réseau virtuel et de sous-réseau que vos machines virtuelles de base de données.
- Pool back-end : créez un pool back-end et ajoutez des machines virtuelles de base de données.
- Règles de trafic entrant : créez une règle d’équilibrage de charge. Suivez les mêmes étapes pour les deux règles d’équilibrage de charge.
- Adresse IP front-end : sélectionnez une adresse IP front-end.
- Pool back-end : sélectionnez un pool back-end.
- Ports haute disponibilité : sélectionnez cette option.
- Protocole : sélectionnez TCP.
- Sonde d’intégrité : créez une sonde d’intégrité avec les détails suivants :
- Protocole : sélectionnez TCP.
- Port : par exemple, 625<numéro-instance>.
- Intervalle : entrez 5.
- Seuil de sonde : entrez 2.
- Délai d'inactivité (minutes) : entrez 30.
- Activer l’adresse IP flottante : sélectionnez cette option.
Remarque
La propriété de configuration de la sonde d’intégrité numberOfProbes, également appelée Seuil de défaillance sur le plan de l’intégrité dans le portail, n’est pas respectée. Pour contrôler le nombre de sondes consécutives qui aboutissent ou qui échouent, définissez la propriété probeThreshold sur 2. Il n’est actuellement pas possible de définir cette propriété à l’aide du portail Azure. Utilisez donc l’interface Azure CLI ou la commande PowerShell.
Remarque
Lorsque des machines virtuelles sans adresse IP publique sont placées dans le pool back-end d’une instance interne d’Azure Load Balancer Standard (sans adresse IP publique), il n’y a pas de connectivité Internet sortante à moins qu’une configuration supplémentaire soit effectuée pour permettre le routage vers des points de terminaison publics. Pour plus d’informations sur la façon de bénéficier d’une connectivité sortante, consultez Connectivité de point de terminaison public pour les machines virtuelles avec Azure Standard Load Balancer dans les scénarios de haute disponibilité SAP.
Important
N’activez pas les horodateurs TCP sur les machines virtuelles Azure placées derrière l’Équilibreur de charge Azure. L’activation de timestamps TCP peut entraîner l’échec des sondes d’intégrité. Affectez au paramètre net.ipv4.tcp_timestampsla valeur 0. Pour plus d’informations, consultez Sondes d’intégrité Load Balancer.
Créez le cluster Pacemaker
Pour créer un cluster Pacemaker de base pour ce serveur IBM Db2, consultez Configurer Pacemaker sur SUSE Linux Enterprise Server dans Azure.
Configuration Pacemaker de Db2
Lorsque vous utilisez Pacemaker pour le basculement automatique en cas de défaillance d’un nœud, vous devez configurer vos instances Db2 et Pacemaker en conséquence. Cette section décrit ce type de configuration.
Les éléments suivants sont précédés de :
- [A] : applicable à tous les nœuds
- [1] : applicable uniquement au nœud 1
- [2] : applicable uniquement au nœud 2
[A] Prérequis pour la configuration Pacemaker :
- Arrêtez les deux serveurs de base de données avec l’utilisateur db2<sid> avec db2stop.
- Remplacez l’environnement d’interpréteur de commandes pour l’utilisateur db2<sid> par /bin/ksh. Nous vous recommandons d’utiliser l’outil Yast.
Configuration Pacemaker
Important
Des tests récents ont révélé des cas où netcat cessait de répondre aux demandes en raison du backlog et de sa capacité à ne gérer qu’une seule connexion. La ressource netcat cesse d’écouter les demandes d’Azure Load Balancer et l’adresse IP flottante devient indisponible. Pour les clusters Pacemaker existants, nous vous recommandons de remplacer netcat par socat. Actuellement, nous vous recommandons d'utiliser l'agent de ressources azure-lb, qui fait partie du package resource-agents, avec la configuration requise suivante pour la version du package :
- Pour SLES 12 SP4/SP5, la version minimum est resource-agents-4.3.018.a7fb5035-3.30.1.
- Pour SLES 15/15 SP1, la version minimum est resource-agents-4.3.0184.6ee15eb2-4.13.1.
Notez que la modification nécessitera un bref temps d’arrêt.
Pour les clusters Pacemaker existants, si la configuration a déjà été modifiée pour utiliser socat comme décrit à la page Azure Load-Balancer Detection Hardening, il n’est pas nécessaire de passer immédiatement à l’agent de ressources azure-lb.
[1] Configuration Pacemaker spécifique à HADR IBM Db2 :
# Put Pacemaker into maintenance mode sudo crm configure property maintenance-mode=true[1] Créez des ressources IBM Db2 :
# Replace **bold strings** with your instance name db2sid, database SID, and virtual IP address/Azure Load Balancer. sudo crm configure primitive rsc_Db2_db2ptr_PTR db2 \ params instance="db2ptr" dblist="PTR" \ op start interval="0" timeout="130" \ op stop interval="0" timeout="120" \ op promote interval="0" timeout="120" \ op demote interval="0" timeout="120" \ op monitor interval="30" timeout="60" \ op monitor interval="31" role="Master" timeout="60" # Configure virtual IP - same as Azure Load Balancer IP sudo crm configure primitive rsc_ip_db2ptr_PTR IPaddr2 \ op monitor interval="10s" timeout="20s" \ params ip="10.100.0.10" # Configure probe port for Azure load Balancer sudo crm configure primitive rsc_nc_db2ptr_PTR azure-lb port=62500 \ op monitor timeout=20s interval=10 sudo crm configure group g_ip_db2ptr_PTR rsc_ip_db2ptr_PTR rsc_nc_db2ptr_PTR sudo crm configure ms msl_Db2_db2ptr_PTR rsc_Db2_db2ptr_PTR \ meta target-role="Started" notify="true" sudo crm configure colocation col_db2_db2ptr_PTR inf: g_ip_db2ptr_PTR:Started msl_Db2_db2ptr_PTR:Master sudo crm configure order ord_db2_ip_db2ptr_PTR inf: msl_Db2_db2ptr_PTR:promote g_ip_db2ptr_PTR:start sudo crm configure rsc_defaults resource-stickiness=1000 sudo crm configure rsc_defaults migration-threshold=5000[1] Démarrez les ressources IBM Db2 :
Sortez Pacemaker du mode de maintenance.
# Put Pacemaker out of maintenance-mode - that start IBM Db2 sudo crm configure property maintenance-mode=false[1] Vérifiez que l’état du cluster est OK et que toutes les ressources sont démarrées. Le nœud sur lequel les ressources s’exécutent n’a aucune importance.
sudo crm status # 2 nodes configured # 5 resources configured # Online: [ azibmdb01 azibmdb02 ] # Full list of resources: # stonith-sbd (stonith:external/sbd): Started azibmdb02 # Resource Group: g_ip_db2ptr_PTR # rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb02 # rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb02 # Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR] # Masters: [ azibmdb02 ] # Slaves: [ azibmdb01 ]
Important
Vous devez gérer l’instance Db2 en cluster Pacemaker à l’aide des outils Pacemaker. Si vous utilisez des commandes db2, telles que db2stop, Pacemaker détecte l’action comme un échec de ressource. Si vous effectuez une maintenance, vous pouvez placer les nœuds ou les ressources en mode de maintenance. Pacemaker suspend la supervision des ressources et vous pouvez alors utiliser les commandes d’administration db2 normales.
Apporter des modifications aux profils SAP afin d’utiliser l’adresse IP virtuelle pour la connexion
Pour se connecter à l’instance primaire de la configuration HADR, la couche d’application SAP doit utiliser l’adresse IP virtuelle que vous avez définie et configurée pour Azure Load Balancer. Les modifications suivantes sont requises :
/sapmnt/<SID>/profile/DEFAULT.PFL
SAPDBHOST = db-virt-hostname
j2ee/dbhost = db-virt-hostname
/sapmnt/<SID>/global/db6/db2cli.ini
Hostname=db-virt-hostname
Installer des serveurs d’applications principal et de boîte de dialogue
Lors de l’installation des serveurs d’applications principal et de boîte de dialogue sur une configuration Db2 HADR, utilisez le nom d’hôte virtuel que vous avez choisi pour la configuration.
Si vous avez effectué l’installation avant de créer la configuration HADR Db2, apportez les modifications comme décrit dans la section précédente et comme suit pour les piles SAP Java.
Vérification de l’URL JDBC des systèmes de piles Java ou ABAP+Java
Utilisez l’outil de configuration J2EE pour vérifier ou mettre à jour l’URL JDBC. Étant donné que l’outil de configuration J2EE est un outil graphique, le serveur X doit être installé :
Connectez-vous au serveur d’applications principal de l’instance J2EE et exécutez :
sudo /usr/sap/*SID*/*Instance*/j2ee/configtool/configtool.shDans le cadre de gauche, choisissez Security store (Magasin de sécurité).
Dans le cadre de droite, choisissez la clé jdbc/pool/<SAPSID>/url.
Remplacez le nom d’hôte dans l’URL JDBC par le nom d’hôte virtuel.
jdbc:db2://db-virt-hostname:5912/TSP:deferPrepares=0Sélectionnez Ajouter.
Pour enregistrer vos modifications, sélectionnez l’icône en forme de disque en haut à gauche.
Fermez l’outil de configuration.
Redémarrez l’instance Java.
Configurer l’archivage des journaux pour la configuration HADR
Pour configurer l’archivage des journaux Db2 pour la configuration HADR, nous vous recommandons de configurer à la fois les bases de données primaire et de secours pour activer la fonctionnalité de récupération des journaux automatique à partir de tous les emplacements des archives des journaux. Les bases de données primaire et de secours doivent être en mesure de récupérer les fichiers d’archive des journaux à partir de tous les emplacements auxquels l’une ou l’autre des instances de base de données peut archiver des fichiers journaux.
L’archivage des journaux est effectué uniquement par la base de données primaire. Si vous modifiez les rôles HADR des serveurs de base de données ou si une défaillance se produit, la nouvelle base de données primaire est responsable de l’archivage des journaux. Si vous avez configuré plusieurs emplacements pour les archives des journaux, il est possible que vos journaux soient archivés à deux reprises. En cas d’une mise à jour locale ou distante, vous devrez peut-être également copier manuellement les journaux archivés à partir de l’ancien serveur principal à l’emplacement actif des journaux du nouveau serveur principal.
Nous vous recommandons de configurer un partage NFS commun dans lequel les journaux sont écrits à partir des deux nœuds. Le partage NFS doit être hautement disponible.
Vous pouvez utiliser des partages NFS hautement disponibles existants pour les transports ou un répertoire de profil. Pour plus d’informations, consultez l’article suivant :
- Haute disponibilité pour NFS sur les machines virtuelles Azure sur SUSE Linux Enterprise Server.
- Haute disponibilité pour SAP NetWeaver sur les machines virtuelles Azure sur SUSE Linux Enterprise Server avec Azure NetApp Files pour les Applications SAP.
- Azure NetApp Files (pour créer des partages NFS).
Tester la configuration du cluster
Cette section explique comment vous pouvez tester votre configuration HADR Db2. Chaque test suppose que vous êtes connecté en tant qu’utilisateur racine et que l’instance primaire IBM Db2 est exécutée sur la machine virtuelle azibmdb01.
L’état initial de tous les cas de test est expliqué ici : (crm_mon -r ou crm status)
- crm status est un instantané de l’état de Pacemaker au moment de l’exécution.
- crm_mon -r est la sortie continue de l’état de Pacemaker.
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Stopped
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
rsc_Db2_db2ptr_PTR (ocf::heartbeat:db2): Promoting azibmdb01
Slaves: [ azibmdb02 ]
L’état d’origine dans un système SAP est documenté dans Transaction DBACOCKPIT > Configuration > Vue d’ensemble, comme illustré dans l’image suivante :
Tester la prise de contrôle d’IBM Db2
Important
Avant de commencer le test, vérifiez les points suivants :
Pacemaker ne comporte pas d’action ayant échoué (crm status).
Il n’existe aucune contrainte d’emplacement (reliquats d’un test de migration).
La synchronisation HADR IBM Db2 fonctionne. Vérifiez auprès de l’utilisateur db2<sid>
db2pd -hadr -db <DBSID>
Migrez le nœud qui exécute la base de données Db2 primaire en exécutant la commande suivante :
crm resource migrate msl_Db2_db2ptr_PTR azibmdb02
Une fois la migration terminée, la sortie crm status ressemble à ce qui suit :
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb02
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb02 ]
Slaves: [ azibmdb01 ]
L’état d’origine dans un système SAP est documenté dans Transaction DBACOCKPIT > Configuration > Vue d’ensemble, comme illustré dans l’image suivante :
La migration de ressources avec « crm resource migrate » crée des contraintes d’emplacement. Les contraintes d’emplacement doivent être supprimées. Si les contraintes d’emplacement ne sont pas supprimées, la ressource ne peut pas effectuer une restauration automatique, ou vous pouvez subir des prises de contrôle indésirables.
Ramenez la ressource vers azibmdb01 et effacez les contraintes d’emplacement
crm resource migrate msl_Db2_db2ptr_PTR azibmdb01
crm resource clear msl_Db2_db2ptr_PTR
- crm resource migrate <res_name><host> : crée des contraintes d’emplacement et peut entraîner des problèmes de prise de contrôle
- crm resource clear <res_name> : efface les contraintes d’emplacement
- crm resource cleanup <res_name> : efface toutes les erreurs de la ressource
Tester l’isolation SBD
Dans ce cas, nous testons l’isolation SBD, qui est recommandée lorsque vous utilisez SUSE Linux.
azibmdb01:~ # ps -ef|grep sbd
root 2374 1 0 Feb05 ? 00:00:17 sbd: inquisitor
root 2378 2374 0 Feb05 ? 00:00:40 sbd: watcher: /dev/disk/by-id/scsi-36001405fbbaab35ee77412dacb77ae36 - slot: 0 - uuid: 27cad13a-0bce-4115-891f-43b22cfabe65
root 2379 2374 0 Feb05 ? 00:01:51 sbd: watcher: Pacemaker
root 2380 2374 0 Feb05 ? 00:00:18 sbd: watcher: Cluster
azibmdb01:~ # kill -9 2374
Le nœud de clusterazibmdb01 doit être redémarré. Le rôle HADR principal IBM Db2 va être déplacé vers azibmdb02. Quand azibmdb01 est de nouveau en ligne, l’instance Db2 prend le rôle d’une instance de base de données secondaire.
Si le service Pacemaker ne démarre pas automatiquement sur l’ancien nœud primaire redémarré, veillez à le démarrer manuellement avec :
sudo service pacemaker start
Tester une prise de contrôle manuelle
Vous pouvez tester une prise de contrôle manuelle en arrêtant le service Pacemaker sur le nœud azibmdb01 :
service pacemaker stop
status on azibmdb02
2 nodes configured
5 resources configured
Online: [ azibmdb02 ]
OFFLINE: [ azibmdb01 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb02
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb02 ]
Stopped: [ azibmdb01 ]
Après le basculement, vous pouvez redémarrer le service sur azibmdb01.
service pacemaker start
Arrêter le processus Db2 sur le nœud qui exécute la base de données primaire HADR
#Kill main db2 process - db2sysc
azibmdb01:~ # ps -ef|grep db2s
db2ptr 34598 34596 8 14:21 ? 00:00:07 db2sysc 0
azibmdb01:~ # kill -9 34598
L’instance Db2 va subir une défaillance et Pacemaker signalera l’état suivant :
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Stopped
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Slaves: [ azibmdb02 ]
Stopped: [ azibmdb01 ]
Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=157, status=complete, exitreason='',
last-rc-change='Tue Feb 12 14:28:19 2019', queued=40ms, exec=223ms
Soit Pacemaker redémarre l’instance de base de données primaire Db2 sur le même nœud, soit il bascule vers le nœud qui exécute l’instance de base de données secondaire et une erreur est signalée.
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb01
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb01 ]
Slaves: [ azibmdb02 ]
Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=157, status=complete, exitreason='',
last-rc-change='Tue Feb 12 14:28:19 2019', queued=40ms, exec=223ms
Arrêter le processus Db2 sur le nœud qui exécute l’instance de base de données secondaire
azibmdb02:~ # ps -ef|grep db2s
db2ptr 65250 65248 0 Feb11 ? 00:09:27 db2sysc 0
azibmdb02:~ # kill -9
Le nœud passe en état d’échec et une erreur est signalée
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb01
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
rsc_Db2_db2ptr_PTR (ocf::heartbeat:db2): FAILED azibmdb02
Masters: [ azibmdb01 ]
Failed Actions:
* rsc_Db2_db2ptr_PTR_monitor_30000 on azibmdb02 'not running' (7): call=144, status=complete, exitreason='',
last-rc-change='Tue Feb 12 14:36:59 2019', queued=0ms, exec=0ms
L’instance Db2 est redémarrée dans le rôle secondaire qu’elle avait auparavant.
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb01
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb01 ]
Slaves: [ azibmdb02 ]
Failed Actions:
* rsc_Db2_db2ptr_PTR_monitor_30000 on azibmdb02 'not running' (7): call=144, status=complete, exitreason='',
last-rc-change='Tue Feb 12 14:36:59 2019', queued=0ms, exec=0ms
Arrêter Db2 par le biais de db2stop force sur le nœud qui exécute l’instance de base de données primaire HADR
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb01
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb01 ]
Slaves: [ azibmdb02 ]
En tant qu’utilisateur db2<sid>, exécutez la commande db2stop force :
azibmdb01:~ # su - db2ptr
azibmdb01:db2ptr> db2stop force
Échec détecté
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Stopped
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Stopped
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
rsc_Db2_db2ptr_PTR (ocf::heartbeat:db2): FAILED azibmdb01
Slaves: [ azibmdb02 ]
Failed Actions:
* rsc_Db2_db2ptr_PTR_demote_0 on azibmdb01 'unknown error' (1): call=201, status=complete, exitreason='',
last-rc-change='Tue Feb 12 14:45:25 2019', queued=1ms, exec=150ms
L’instance de base de données secondaire de haute disponibilité et récupération d’urgence DB2 a été promue au rôle principal.
nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb01
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb02
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb02 ]
Stopped: [ azibmdb01 ]
Failed Actions:
* rsc_Db2_db2ptr_PTR_start_0 on azibmdb01 'unknown error' (1): call=205, stat
us=complete, exitreason='',
last-rc-change='Tue Feb 12 14:45:27 2019', queued=0ms, exec=865ms
Planter la machine virtuelle avec restart sur le nœud qui exécute l’instance de base de données primaire HADR
#Linux kernel panic - with OS restart
azibmdb01:~ # echo b > /proc/sysrq-trigger
Pacemaker promeut l’instance secondaire au rôle d’instance primaire. L’ancienne instance primaire va prendre le rôle secondaire une fois la machine virtuelle et tous les services entièrement restaurés après le redémarrage de la machine virtuelle.
nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb01
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb01 ]
Slaves: [ azibmdb02 ]
Planter la machine virtuelle qui exécute l’instance de base de données primaire HADR avec « halt »
#Linux kernel panic - halts OS
azibmdb01:~ # echo b > /proc/sysrq-trigger
Dans ce cas, Pacemaker détecte que le nœud qui exécute l’instance de base de données primaire ne répond pas.
2 nodes configured
5 resources configured
Node azibmdb01: UNCLEAN (online)
Online: [ azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb01
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb01
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb01 ]
Slaves: [ azibmdb02 ]
L’étape suivante consiste à rechercher une situation de Split-Brain. Une fois que le nœud restant a déterminé que le nœud qui a exécuté en dernier l’instance de base de données primaire est en panne, un basculement des ressources est exécuté.
2 nodes configured
5 resources configured
Online: [ azibmdb02 ]
OFFLINE: [ azibmdb01 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb02
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb02 ]
Stopped: [ azibmdb01 ]
En cas d’un « arrêt » du nœud, le nœud défaillant doit être redémarré à l’aide des outils de gestion Azure (dans le portail Azure, PowerShell ou l’interface de ligne de commande Azure). Une fois que le nœud défaillant est de nouveau en ligne, il démarre l’instance Db2 dans le rôle secondaire.
2 nodes configured
5 resources configured
Online: [ azibmdb01 azibmdb02 ]
Full list of resources:
stonith-sbd (stonith:external/sbd): Started azibmdb02
Resource Group: g_ip_db2ptr_PTR
rsc_ip_db2ptr_PTR (ocf::heartbeat:IPaddr2): Started azibmdb02
rsc_nc_db2ptr_PTR (ocf::heartbeat:azure-lb): Started azibmdb02
Master/Slave Set: msl_Db2_db2ptr_PTR [rsc_Db2_db2ptr_PTR]
Masters: [ azibmdb02 ]
Slaves: [ azibmdb01 ]