Guide de déploiement de cluster haute disponibilité IBM Db2 pour SAP

Ce guide explique comment configurer des ressources Google Cloud pour un cluster haute disponibilité (HA) IBM Db2 pour SAP sur le système d'exploitation Linux.

Ces instructions complètent celles fournies par SAP et IBM dans le guide IBM Db2 High Availability Solution: IBM Tivoli System Automation for Multiplatforms. Reportez-vous toujours à la documentation la plus récente fournie par SAP et IBM lors de l'installation et de la configuration d'un cluster haute disponibilité IBM Db2 sur Google Cloud.

Ces instructions concernent les clusters HA IBM Db2 utilisant le système IBM TSAMP (Tivoli System Automation for Multiplatforms) pour surveiller le système et prendre les mesures appropriées si le système ne répond plus. Le cluster utilise la fonction de récupération après sinistre haute disponibilité (HADR) IBM Db2 pour répliquer les modifications de données consignées dans la base de données en attente.

Le cluster utilise une adresse IP flottante mise en œuvre par Google Cloud à l'aide d'une route statique Google Cloud ou d'une adresse IP d'alias. Dans ce contexte, le terme "adresse IP flottante" est synonyme du terme "adresse IP virtuelle" utilisé dans la documentation SAP.

Ces instructions vous montrent comment configurer un cluster HA IBM Db2 composé d'un serveur IBM Db2 principal et d'un serveur IBM Db2 secondaire ou de secours, chacun étant déployé sur une machine virtuelle Compute Engine (VM) distincte.

Ce guide est destiné aux utilisateurs expérimentés SAP et IBM Db2 qui sont familiarisés avec les clusters à haute disponibilité.

Pour plus d'informations sur la planification d'un cluster HA Db2, consultez la section High-availability IBM Db2 clusters (Clusters à haute disponibilité IBM Db2) dans le guide de planification IBM Db2 pour SAP.

Documentation SAP requise

Les instructions d'installation et de configuration des composants SAP et IBM sont fournies par SAP dans le guide IBM Db2 High-Availability Solution: IBM Tivoli System Automation for Multiplatforms.

Lisez la documentation SAP et Google Cloud avant de commencer les procédures décrites dans ces instructions. À différentes étapes du déploiement, vous devrez peut-être consulter à la fois la documentation SAP et la documentation Google Cloud.

Prérequis

Avant de créer le cluster haute disponibilité IBM Db2, assurez-vous que les conditions préalables suivantes sont remplies :

  • Vous ou votre organisation possédez un compte Google Cloud et vous avez créé un projet pour le déploiement du cluster haute disponibilité IBM Db2. Pour en savoir plus sur la création de projets Google Cloud, consultez la section Prérequis du guide de déploiement d'IBM Db2 pour SAP.
  • Si vous souhaitez que votre charge de travail SAP s'exécute conformément aux exigences liées à la résidence des données, au contrôle des accès, au personnel d'assistance ou à la réglementation, vous devez créer le dossier Assured Workloads requis. Pour en savoir plus, consultez la page Contrôles de conformité et de souveraineté pour SAP sur Google Cloud.

  • Vous disposez d'un réseau cloud privé virtuel sur Google Cloud. Pour obtenir des instructions sur la configuration d'un réseau VPC et de règles de pare-feu, ainsi que sur la configuration d'une passerelle NAT ou d'un hôte bastion pour IBM Db2 pour SAP, consultez le guide de déploiement IBM Db2 pour SAP.

  • Si OS Login est activé dans les métadonnées de votre projet, vous devrez le désactiver temporairement jusqu'à la fin du déploiement. Pour le déploiement, cette procédure configure les clés SSH dans les métadonnées d'instance. Lorsque OS Login est activé, la configuration des clés SSH basée sur les métadonnées est désactivée. Une fois le déploiement terminé, vous pouvez réactiver OS Login.

    Pour en savoir plus, consultez les pages suivantes :

Déployer un cluster haute disponibilité IBM Db2 sur Google Cloud

Ces instructions vous expliquent comment déployer deux VM, définir une adresse IP flottante et configurer l'adresse IP d'alias ou les routes Google Cloud acceptant l'adresse IP flottante. Lorsque vous devez installer les composants IBM, référez-vous à la documentation SAP.

Les principaux services Google Cloud dont vous avez besoin pour configurer un cluster haute disponibilité IBM Db2 sont :

  • Un réseau et un sous-réseau VPC ;
  • Des règles de pare-feu (si vous n'utilisez pas une autre forme de contrôle d'accès au réseau) ;
  • Des VM Compute Engine et de l'espace de stockage sur disque persistant.

Vous téléchargez et utilisez également un script auxiliaire Google Cloud lorsque vous définissez la ressource personnalisée utilisée par TSAMP pour le basculement de l'adresse IP flottante entre les hôtes. Le script permet à TSAMP d'interagir avec les API Google Cloud.

À propos de Deployment Manager

Dans ces instructions, vous définissez les options de ressources pour votre installation dans un modèle de fichier de configuration Deployment Manager.

Deployment Manager traite toutes les ressources créées pour votre système SAP comme une seule entité appelée déploiement. Vous pouvez afficher et utiliser tous les déploiements de votre projet sur la page Déploiements dans la console Google Cloud.

Tenez compte des comportements suivants lorsque vous utilisez Deployment Manager :

  • La suppression d'un déploiement supprime toutes les ressources associées au déploiement, y compris les VM, les disques persistants et les systèmes SAP installés sur la VM.

  • Par défaut, Deployment Manager utilise la stratégie de création de ressources ACQUIRE. Si vous spécifiez un nom de VM déjà utilisé par une autre VM dans votre projet, Deployment Manager ne crée pas de VM, mais ajoute celle existante à votre nouveau déploiement. Si votre VM d'origine a été créée par une exécution précédente de Deployment Manager, cette VM est associée à deux déploiements.

    Si vous supprimez ensuite le nouveau déploiement, la VM acquise est supprimée du déploiement qui l'a créée initialement. Pour éviter un tel scénario, définissez la stratégie de ressources de Deployment Manager sur CREATE ou assurez-vous d'utiliser des noms de ressources uniques dans votre nouveau déploiement.

    Pour en savoir plus sur les stratégies que vous pouvez utiliser lors de la création de ressources avec Deployment Manager et sur la façon de les spécifier, consultez la documentation sur Deployment Manager.

Déployer les VM pour un cluster HA IBM Db2 avec Deployment Manager

  1. Dans Cloud Shell, téléchargez le modèle de fichier de configuration template_ha.yaml dans votre répertoire de travail :

    wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_db2/template_ha.yaml

  2. Pour ouvrir l'éditeur de code Cloud Shell, cliquez sur l'icône en forme de crayon () située dans l'angle supérieur droit de la fenêtre de terminal Cloud Shell.

  3. Renommez éventuellement le fichier template_ha.yaml pour identifier la configuration qu'il définit. Exemple :db2_ha_s123_dh1.yaml

  4. Pour ouvrir le fichier template_ha.yaml dans l'éditeur de code, double-cliquez dessus.

  5. Définissez les VM et les disques persistants dans le fichier template_ha.yaml. Le fichier template_ha.yaml contient deux sections : sap_db2_primary et sap_db2_secondary. Chaque section contient un ensemble de paires propriété-valeur suivies de commentaires incluant des propriétés moins fréquemment utilisées.

    Lorsque vous remplissez chaque section, à l'exception des propriétés instanceName, zone et otherHost, les définitions de chaque VM doivent être identiques.

    Le tableau suivant décrit les propriétés incluses dans chaque section. Pour utiliser une propriété, remplacez le texte d'espace réservé et les crochets par les valeurs de votre installation.

    Propriété Type de données Description
    type Chaîne

    Spécifie l'emplacement, le type et la version du modèle Deployment Manager à utiliser lors du déploiement.

    Le fichier YAML comprend deux spécifications type, dont l'une est laissée en commentaire. La spécification type qui est active par défaut spécifie la version du modèle en tant que latest. La spécification type qui est laissée en commentaire spécifie une version de modèle spécifique avec un horodatage.

    Si tous vos déploiements doivent utiliser la même version de modèle, utilisez la spécification type qui inclut l'horodatage.

    instanceName String Nom de l'instance de VM sur laquelle vous installez IBM Db2. Le nom doit comporter 13 caractères au maximum, spécifiés en lettres minuscules, chiffres ou traits d'union.
    instanceType String Type de VM Compute Engine sur laquelle vous installez IBM Db2. Spécifiez un type de machine avec deux processeurs virtuels ou plus. Exemple :n1-standard-4
    zone String Zone dans laquelle vous déployez l'instance IBM Db2. Doit être dans la même région que celle que vous avez sélectionnée pour votre sous-réseau.
    subnetwork String Nom du sous-réseau que vous avez créé à une étape précédente. Si vous procédez au déploiement sur un VPC partagé, spécifiez cette valeur en tant que shared-vpc-project/SUBNETWORK. Exemple :myproject/network1
    linuxImage String Nom de l'image du système d'exploitation Linux ou de la famille de l'image que vous utilisez avec IBM Db2. Pour spécifier une famille d'images, ajoutez le préfixe family/ au nom de la famille. Par exemple, family/rhel-7-sap-apps ou family/sles-12-sp3-sap. Pour spécifier une image, entrez simplement le nom de l'image. Pour obtenir la liste des familles d'images disponibles, consultez la page Images dans la console Google Cloud.
    linuxImageProject String Le projet Google Cloud qui contient l'image que vous allez utiliser. Il peut s'agir de votre propre projet ou d'un projet d'image Google Cloud, tel que rhel-sap-cloud ou suse-sap-cloud. Pour obtenir la liste des projets d'image Google Cloud, consultez la page Images dans la documentation Compute Engine.
    db2SID String ID de l'instance de base de données.
    db2sidSize Entier Taille en Go de /db2/DBSID, qui est le répertoire racine de l'instance de base de données. Les valeurs minimale et par défaut de db2sidSize sont toutes deux de 8 Go.
    db2homeSize Entier Taille en Go de /db2/db2db2sid, qui correspond au répertoire d'accueil de l'instance de base de données. Les valeurs minimale et par défaut de db2homeSize sont toutes deux de 8 Go.
    db2dumpSize Entier Taille en Go de /db2/DBSID/db2dump, qui contient les fichiers de vidage de DB2 utilisés pour diagnostiquer les problèmes. Les valeurs minimale et par défaut de db2dumpSize sont toutes deux de 8 Go.
    db2saptmpSize Entier Taille en Go de /db2/DBSID/saptmp, qui contient l'espace de table temporaire de la base de données. Les valeurs minimale et par défaut de db2saptmpSize sont toutes deux de 8 Go.
    db2sapdataSize Entier Taille de /sapdb/DBSID/sapdata, qui contient les fichiers de données de la base de données. Les valeurs minimale et par défaut de db2sapdataSize sont toutes deux de 30 Go.
    db2logSize Entier Taille de /db2/DBSID/logdir, qui contient les journaux de transaction de la base de données. Les valeurs minimale et par défaut de db2logSize sont toutes deux de 8 Go.
    db2backupSize Entier Taille du volume /db2backup. Cette propriété est facultative. Si vous la définissez sur 0 ou l'omettez, aucun disque n'est créé.
    db2sapdataSSD boolean Indique si le lecteur de données utilise un disque persistant SSD (Yes) ou un disque persistant HDD (No). Yes est la valeur par défaut.
    db2logSSD boolean Indique si le lecteur de journal utilise un disque persistant SSD (Yes) ou un disque persistant HDD (No). Yes est la valeur par défaut. L'utilisation d'un disque SSD est recommandée pour le disque de journalisation.
    usrsapSize Entier Requis uniquement si vous installez IBM Db2 pour une exécution avec SAP NetWeaver sur la même instance de VM.
    sapmntSize Entier Requis uniquement si vous installez IBM Db2 pour une exécution avec SAP NetWeaver sur la même instance de VM.
    swapSize Entier Requis uniquement si vous installez IBM Db2 pour une exécution avec SAP NetWeaver sur la même instance de VM.
    otherHost String Nom de l'autre instance de VM du cluster haute disponibilité IBM Db2. L'instance de VM doit être définie dans l'autre ensemble de propriétés dans le même fichier template_ha.yaml.
    networkTag String Facultatif. Tag réseau qui représente votre instance de VM à des fins de routage ou de pare-feu. Si vous spécifiez publicIP: No et n'utilisez pas de tag réseau, assurez-vous de fournir un autre moyen d'accès à Internet.
    publicIP boolean Facultatif. Détermine si une adresse IP publique est ajoutée à votre instance de VM. La valeur par défaut est Yes.
    serviceAccount String Facultatif. Si vous créez votre propre compte de service avec des autorisations verrouillées, entrez le nom du compte ici. Par défaut, les VM sont déployées à l'aide du compte de service de projet par défaut. Notez qu'un compte de service défini de manière incorrecte fait échouer le déploiement. Voici un exemple de compte de service personnalisé : myserviceuser@myproject.iam.gserviceaccount.com
    sap_deployment_debug boolean Facultatif. Si cette valeur est définie sur Yes, le déploiement génère des journaux de déploiement détaillés. N'activez ce paramètre que si un ingénieur de l'assistance Google vous demande d'activer le débogage.
    post_deployment_script String Facultatif. Spécifie l'emplacement d'un script à exécuter une fois le déploiement terminé. Le script doit être hébergé sur un serveur Web ou dans un bucket Cloud Storage. L'URL doit commencer par http://, https:// ou gs://. Notez que ce script est exécuté sur toutes les VM créées par le modèle. Pour l'exécuter seulement sur l'instance principale, cochez la case située en haut de votre script.

    Les exemples suivants de définitions de VM à partir d'un fichier de configuration template_ha.yaml créent deux VM pour un cluster IBM Db2 haute disponibilité. Pour chaque VM, le fichier de configuration demande à Deployment Manager de déployer une VM n1-standard-4 exécutant un système d'exploitation à partir de la famille d'images SLES 12 SP3. La VM comprend tous les répertoires requis pour exécuter un cluster HA IBM Db2. Deployment Manager ne crée pas les répertoires SAP NetWeaver, car les tailles des répertoires sont définies sur 0.

    resources:
- name: sap_db2_primary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_db2/sap_db2.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/202103310846/dm-templates/sap_db2/sap_db2.py
  #
  properties:
    instanceName: db2-ha-s1
    instanceType: n1-standard-4
    zone: us-central1-c
    subnetwork: example-sap-subnetwork
    linuxImage: family/sles-12-sp3-sap
    linuxImageProject: suse-sap-cloud
    db2SID: DH1
    db2sidSize: 16
    db2dumpSize: 16
    db2saptmpSize: 16
    db2sapdataSize: 50
    db2logSize: 16
    db2backupSize: 50
    db2sapdataSSD: Yes
    db2logSSD: Yes
    usrsapSize: 0
    sapmntSize: 0
    swapSize: 0
    otherHost: db2-ha-s2
#
# (Comment section omitted from example)
#
- name: sap_db2_secondary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_db2/sap_db2.py
  #
  # By default, this configuration file uses the latest release of the deployment
  # scripts for SAP on Google Cloud.  To fix your deployments to a specific release
  # of the scripts, comment out the type property above and uncomment the type property below.
  #
  # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/202103310846/dm-templates/sap_db2/sap_db2.py
  #
  properties:
    instanceName: db2-ha-s2
    instanceType: n1-standard-4
    zone: us-central1-f
    subnetwork: example-sap-subnetwork
    linuxImage: family/sles-12-sp3-sap
    linuxImageProject: suse-sap-cloud
    db2SID: DH1
    db2sidSize: 16
    db2dumpSize: 16
    db2saptmpSize: 16
    db2sapdataSize: 50
    db2logSize: 16
    db2backupSize: 50
    db2sapdataSSD: Yes
    db2logSSD: Yes
    usrsapSize: 0
    sapmntSize: 0
    swapSize: 0
    otherHost: db2-ha-s1

  6. Déployez l'instance de VM avec Deployment Manager.

    gcloud deployment-manager deployments create DEPLOYMENT-NAME --config TEMPLATE-NAME.yaml

    Où :

    • DEPLOYMENT-NAME représente le nom de votre choix pour le déploiement en cours. Ce nom permet d'identifier ce déploiement sur la page Déploiements de la console Google Cloud.
    • TEMPLATE-NAME représente le nom que vous avez donné au fichier de configuration ou, si vous n'avez pas modifié le nom du fichier par défaut, template_ha.yaml.

    Deployment Manager lit les spécifications dans le fichier template_ha.yaml et configure la VM et les disques persistants en conséquence. Ce processus peut prendre quelques minutes. Pour vérifier la progression du déploiement, suivez les étapes de la section suivante.

Valider le déploiement

Pour vérifier le déploiement, consultez les journaux de déploiement dans Cloud Logging et la configuration de la VM.

Vérifier les journaux

  1. Dans la console Google Cloud, ouvrez Cloud Logging pour surveiller la progression de l'installation et rechercher les erreurs.

    Accéder à CloudLogging

  2. Filtrez les journaux :

    Logs Explorer

    1. Sur la page Explorateur de journaux, accédez au volet Requête.

    2. Dans le menu déroulant Ressource, sélectionnez Global, puis cliquez sur Ajouter.

      Si l'option Global n'apparaît pas, saisissez la requête suivante dans l'éditeur de requête :

      resource.type="global"
"Deployment"

    3. Cliquez sur Exécuter la requête.

    Ancienne visionneuse de journaux

    • Sur la page Ancienne visionneuse de journaux, dans le menu de sélection de base, sélectionnez Global comme ressource de journalisation.

  3. Analysez les journaux filtrés :

    • Si "--- Finished" s'affiche, le traitement du déploiement est terminé, et vous pouvez passer à l'étape suivante.

    • Si vous rencontrez une erreur de quota :

      1. Sur la page Quota d'IAM et administration, augmentez le quota qui ne répond pas aux exigences de IBM DB2 répertoriées dans le Guide de planification IBM DB2 pour SAP.

      2. Sur la page Déploiements de Deployment Manager, supprimez le déploiement pour nettoyer les VM et les disques persistants de l'installation ayant échoué.

      3. Réexécutez le déploiement.

Vérifier la configuration de la VM

  1. Une fois le déploiement de VM terminé, connectez-vous à chaque VM à l'aide de ssh. Sur la page Instances de VM de Compute Engine, vous pouvez cliquer sur le bouton SSH pour chaque instance de VM ou utiliser votre méthode SSH préférée.

    Bouton SSH sur la page "VM instances" (Instances de VM) de Compute Engine

  2. Connectez-vous en tant qu'utilisateur racine.

    sudo su -

  3. À l'invite de commande, saisissez df -h. Assurez-vous d'obtenir un résultat semblable à celui-ci :

    db2-ha-s1:~ # df -h
Filesystem                     Size  Used Avail Use% Mounted on
devtmpfs                       7.4G     0  7.4G   0% /dev
tmpfs                           12G     0   12G   0% /dev/shm
tmpfs                          7.4G   18M  7.4G   1% /run
tmpfs                          7.4G     0  7.4G   0% /sys/fs/cgroup
/dev/sda1                       30G  2.2G   26G   8% /
/dev/mapper/vg_db2sid-vol       16G   33M   16G   1% /db2/DH1
/dev/mapper/vg_db2dump-vol      16G   33M   16G   1% /db2/DH1/db2dump
/dev/mapper/vg_db2sapdata-vol   50G   33M   50G   1% /db2/DH1/sapdata
/dev/mapper/vg_db2saptmp-vol    16G   33M   16G   1% /db2/DH1/saptmp
/dev/mapper/vg_db2log-vol       16G   33M   16G   1% /db2/DH1/log_dir
/dev/mapper/vg_db2home-vol      16G   33M   16G   1% /db2/db2dh1
/dev/mapper/vg_db2backup-vol    50G   33M   50G   1% /db2backup
tmpfs                          1.5G     0  1.5G   0% /run/user/1001

Si l'une des étapes de validation indique que l'installation a échoué, procédez comme suit :

  1. Corrigez l'erreur.
  2. Sur la page Déploiements, supprimez le déploiement pour nettoyer les VM et les disques persistants de l'installation défaillante.
  3. Réexécutez le déploiement.

Réserver une adresse IP flottante

Vous devez sélectionner une adresse IP à utiliser comme adresse IP flottante. Vous aurez besoin de cette adresse IP ultérieurement lorsque vous définissez les métadonnées de l'instance de VM hôte et lorsque vous installez et configurez IBM Db2 et le cluster haute disponibilité.

Selon que vous choisissez un type de mise en œuvre d'IP de routage ou d'alias pour votre adresse IP flottante, les conditions requises pour l'adresse IP flottante sont différentes.

Si vous utilisez la mise en œuvre de route statique pour votre adresse IP flottante, l'adresse IP doit être en dehors de la plage d'adresses IP de votre sous-réseau et ne peut être utilisée par aucun autre élément des réseaux étendus de votre entreprise. Consultez votre administrateur réseau pour déterminer l'adresse IP appropriée à utiliser.

Si vous utilisez la mise en œuvre d'adresse IP d'alias pour votre adresse IP flottante, vous devez réserver une adresse IP comprise dans la plage d'adresses IP du sous-réseau utilisé par les hôtes.

Pour les mise en œuvre d'adresse IP d'alias uniquement, réservez une adresse IP d'alias :

  1. Ouvrez un terminal sur une VM hôte ou ouvrez Cloud Shell.

    Accéder à Cloud Shell

  2. Réservez une adresse IP.

    gcloud compute addresses create vip-name --region region --subnet subnet-name \
  --addresses ip-addr-optional

    La spécification de la propriété "adresse" est facultative. Si vous ne saisissez pas d'adresse IP, Compute Engine sélectionne pour vous une adresse IP de votre sous-réseau.

  3. Affichez et notez l'adresse IP réservée à utiliser lorsque vous installez le serveur de base de données et configurez le cluster haute disponibilité.

    gcloud compute addresses describe vip-name --region=region

    Exemple : 

    db2-ha-s1:~ # gcloud compute addresses describe db2-ha-vip-dh1 --region=us-central1
address: 10.1.0.30
addressType: INTERNAL
creationTimestamp: '2018-11-28T11:34:14.478-08:00'
description: ''
id: '6558342813288977241'
kind: compute#address
name: db2-ha-vip-dh1
region: https://www.googleapis.com/compute/v1/projects/solutions-writers/regions/us-central1
selfLink: https://www.googleapis.com/compute/v1/projects/solutions-writers/regions/us-central1/addresses/db2-ha-vip-dh1
status: RESERVED
subnetwork: https://www.googleapis.com/compute/v1/projects/solutions-writers/regions/us-central1/subnetworks/example-sap-   subnetwork

Ajouter l'adresse IP flottante aux métadonnées de chaque instance de VM hôte

Vous spécifiez des informations sur votre adresse IP flottante, y compris votre type de mise en œuvre d'IP de route ou d'alias choisi, en tant que métadonnées personnalisées pour chaque instance de VM du cluster. Pour en savoir plus sur le choix d'un type de mise en œuvre pour votre adresse IP flottante, consultez la section Adresses IP flottantes pour les clusters IBM Db2 haute disponibilité sur Google Cloud.

Selon le type de votre mise en œuvre, les paramètres de métadonnées que vous définissez sont différents. Dans les deux sections suivantes, suivez les instructions de la section qui s'applique au type de mise en œuvre de votre adresse IP flottante.

Définir les métadonnées pour une mise en œuvre de route de l'adresse IP flottante

Si vous utilisez une mise en œuvre de route pour votre adresse IP flottante, utilisez les paramètres du tableau suivant et la procédure qui suit le tableau pour définir les métadonnées de l'instance.

Paramètre Valeur Usage
sap_ibm_vip_solution route Indique qu'il s'agit d'un déploiement multizone qui utilise un routage statique Google Cloud pour prendre en charge le basculement de l'adresse IP flottante entre les hôtes.
sap_ibm_db2_vip ip-address Spécifie l'adresse IP flottante que vous avez réservée à l'étape précédente.
sap_ibm_db2_routename route-name Spécifie un nom arbitraire pour la route statique. Par exemple, vous pouvez utiliser db2-dh1-vip-route
sap_ibm_db2_routenet vpc-network-name Indique le réseau VPC contenant le cluster HA IBM Db2.

Pour définir les métadonnées de votre instance pour une mise en œuvre de route statique de votre adresse IP flottante, procédez comme suit :

  1. Ouvrez un terminal sur une VM hôte ou ouvrez Cloud Shell.

    Accéder à Cloud Shell

  2. Pour chaque instance de VM hôte du cluster, spécifiez les mêmes métadonnées pour la mise en œuvre de la route de l'adresse IP flottante.

    gcloud compute instances add-metadata instance-name \
--metadata sap_ibm_vip_solution=route,sap_ibm_db2_vip=ip-address,\
sap_ibm_db2_routename=route-name,sap_ibm_db2_routenet=vpc-network-name \
--zone instance-zone

Définir les métadonnées pour une mise en œuvre d'adresse IP d'alias de l'adresse IP flottante

Si vous utilisez une mise en œuvre d'adresse IP d'alias pour votre adresse IP flottante, utilisez les paramètres du tableau suivant et la procédure qui suit le tableau pour définir les métadonnées de l'instance.

Paramètre Valeur Usage
sap_ibm_vip_solution alias Indique qu'il s'agit d'un déploiement à zone unique qui utilise une adresse IP d'alias Google Cloud pour permettre le basculement de l'adresse IP flottante entre des hôtes.
sap_ibm_db2_vip ip-address Spécifie l'adresse IP flottante que vous avez réservée à l'étape précédente.
sap_ibm_db2_vip_range alias-ip-range-name Spécifie éventuellement un nom arbitraire pour la plage d'adresses IP d'alias. Par exemple, vous pouvez utiliser db2-dh1-vip-alias. La valeur par défaut est le nom du sous-réseau.

Pour définir les métadonnées de votre instance pour une mise en œuvre d'adresse IP d'alias de votre adresse IP flottante, procédez comme suit :

  1. Ouvrez un terminal sur une VM hôte ou ouvrez Cloud Shell.

    Accéder à Cloud Shell

  2. Pour chaque instance de VM hôte du cluster, spécifiez les mêmes métadonnées pour la mise en œuvre d'adresse IP d'alias de l'adresse IP flottante.

    gcloud compute instances add-metadata instance-name \
--metadata sap_ibm_vip_solution=alias,sap_ibm_db2_vip=ip-address,\
sap_ibm_db2_vip_range=alias-ip-range-name --zone instance-zone

Revoir ou modifier vos métadonnées d'instance

Pour examiner les métadonnées de l'instance que vous avez définies, exécutez la commande suivante :

gcloud compute instances describe instance-name --zone instance-zone

Si vous devez modifier vos métadonnées personnalisées, exécutez la commande suivante :

gcloud compute instances add-metadata instance-name --metadata  parm-name=parm-value

Ajouter des noms d'hôte et des adresses IP à /etc/hosts

Lors de la configuration du cluster, l'outil de configuration du cluster SAP valide les noms d'hôte et les adresses IP internes de chaque VM hôte et de l'adresse IP flottante. Pour garantir la réussite de la validation, ajoutez l'adresse IP, le nom d'hôte et le nom DNS interne du VPC pour chaque VM hôte, ainsi que l'adresse IP flottante au fichier /etc/hosts sur chaque VM hôte en utilisant l'éditeur de votre choix.

Par exemple, en tant qu'utilisateur racine, l'exemple suivant met à jour /etc/hosts :

echo "#Db2 HA floating IP additions" >> /etc/hosts
echo 10.2.0.24 db2-ha-vip-dh1 db2-ha-vip-dh1.c.solutions-writers.internal >> /etc/hosts
echo 10.1.0.3 db2-ha-s1 db2-ha-s1.us-central1-c.c.db2-ha-project.internal >> /etc/hosts
echo 10.1.0.2 db2-ha-s2 db2-ha-s2.us-central1-f.c.db2-ha-project.internal >> /etc/hosts

Dans l'exemple précédent, la chaîne entre le nom d'hôte et >> sur chaque ligne est un nom DNS interne VPC, qui est utilisé par le service DNS interne VPC.

Les VM hôtes utilisent un nom DNS interne zonal, qui inclut un champ pour la zone. L'adresse IP flottante utilise un nom DNS interne global, qui n'inclut pas de champ de zone.

Pour une VM hôte, vous pouvez récupérer le nom DNS interne en entrant la commande suivante à partir d'un terminal de la VM hôte :

curl "http://metadata.google.internal/computeMetadata/v1/instance/hostname" \
-H "Metadata-Flavor: Google"

Pour une adresse IP flottante, vous pouvez le saisir vous-même en utilisant le format suivant :

vip-host-name.c.project-name.internal

Une fois le fichier /etc/hosts mis à jour, les informations pertinentes dans le fichier /etc/hosts doivent ressembler à l'exemple suivant :

#Db2 HA floating IP additions
10.2.0.24 db2-ha-vip-dh1 db2-ha-vip-dh1.c.solutions-writers.internal
10.1.0.3 db2-ha-s1 db2-ha-s1.us-central1-c.c.db2-ha-project.internal
10.1.0.2 db2-ha-s2 db2-ha-s2.us-central1-f.c.db2-ha-project.internal

Préparer le système d'exploitation

Après avoir créé votre VM, préparez le système d'exploitation pour le cluster HA IBM Db2.

Les conditions requises sont définies par SAP et IBM. La documentation SAP fait appel à l’installation de logiciels, tels que Perl et Korn Shell, qui ne sont peut-être pas préinstallés sur vos VM hôtes Compute Engine.

Consultez les documents suivants pour connaître les dernières conditions requises :

Installer le serveur de base de données et créer le cluster HA IBM Db2

Avant de suivre les instructions indiquées dans le guide IBM Db2 High availability solution: IBM Tivoli System Automation for Multiplatforms pour installer et configurer IBM Db2 et le cluster HA, passez en revue l'aperçu de la procédure suivante, en portant une attention particulière aux notes.

Pour installer SAP NetWeaver et le serveur d'applications principal, consultez la documentation SAP NetWeaver de Google Cloud et les guides d'installation SAP applicables disponibles dans le portail d'aide SAP.

Les étapes suivantes donnent un aperçu de la procédure d'installation. Reportez-vous à la documentation SAP pour plus de détails.

  1. Établissez une connectivité SSH basée sur des clés entre les instances principale et secondaire et entre chaque instance et elle-même, comme décrit dans la documentation SAP. SSH est utilisé par l'outil de configuration de cluster SAP. Testez toutes les connexions sur chaque hôte. Par exemple, sur db2-ha-s1, testez les deux éléments suivants.

    • ssh db2-ha-s1
    • ssh db2-ha-s2

  2. Téléchargez ou copiez le jeu complet de supports SAP pour Db2 sur votre VM à partir du portail d'assistance SAP.

  3. Sur la VM hôte principale, utilisez SWPM (SAP Software Provisioning Manager) pour installer le serveur de base de données IBM Db2.

  4. Sur la VM hôte secondaire, configurez la base de données de secours à l'aide d'une méthode telle que la copie de système homogène SAP.

  5. Sur les deux VM hôtes, installez les fichiers de licence pour IBM Db2 et IBM TSAMP. Pour plus d'informations sur l'installation des licences IBM obtenues auprès de SAP, consultez la note SAP Note 816773 - DB6: Installing an SAP OEM license.

  6. Sur les deux VM hôtes, installez la dernière version de TSAMP, compatible avec la version de votre base de données et la version de votre système d'exploitation.

  7. Sur la VM hôte principale, utilisez la dernière version de l'outil de configuration de cluster SAP sapdb2cluster.sh pour configurer et créer le cluster haute disponibilité IBM Db2.

  8. Une fois le cluster créé, sur l'hôte principal, utilisez l'utilitaire de configuration d'instance haute disponibilité DB2 (db2haicu) pour vérifier que le cluster peut basculer.

    1. Quittez l'outil de configuration de cluster SAP et Korn Shell.

    2. Sur l'instance principale, confirmez que le serveur de base de données principal est en ligne.

      lssam

      Dans l'exemple suivant, extrait de la sortie lssam, l'instance de base de données principale est en ligne :

      Online IBM.ResourceGroup:db2_db2dh1_db2dh1_DH1-rg Nominal=Online
        '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs
                |- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s1
                '- Offline IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s2

    3. Passez à l'utilisateur d'instance de base de données.

      sudo su - db2sid

    4. Lancez l'utilitaire db2haicu.

      db2haicusid

    5. Dans l'interface db2haicu, sélectionnez l'option 5 et suivez les instructions.

    6. Quittez l'utilitaire db2haicu.

    7. Sur l'hôte principal, vérifiez que l'hôte secondaire est maintenant en ligne.

      lssam

      Dans l'exemple suivant extrait du résultat lssam, l'instance de base de données secondaire est en ligne.

      Online IBM.ResourceGroup:db2_db2dh1_db2dh1_DH1-rg Nominal=Online
        '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs
                |- Offline IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s1
                '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s2

Pour terminer la configuration du cluster, suivez les instructions de la section suivante pour créer une ressource TSAMP personnalisée pour l'adresse IP flottante et l'associer dans TSAMP à la ressource d'instance IBM Db2.

Créer une ressource personnalisée TSAMP pour l'adresse IP flottante

Pour permettre à TSAMP de gérer l'adresse IP flottante, vous devez créer une ressource personnalisée TSAMP pour celle-ci. Pour permettre à TSAMP d'interagir avec Google Cloud tout en gérant la ressource d'adresse IP flottante, vous devez télécharger et configurer un script d'aide depuis Google Cloud.

Télécharger le script d'aide Google Cloud

Sur chaque hôte du cluster, téléchargez le script d'aide Google Cloud et définissez les autorisations.

  1. En tant qu'utilisateur racine, téléchargez le script à partir du répertoire /root de la VM principale sur les hôtes principal et de secours.

    wget https://storage.googleapis.com/sapdeploy/gceTSAMP/gcp_floating_ip.sh

  2. Sur les deux hôtes, définissez les autorisations sur le script.

    chmod 744 gcp_floating_ip.sh

Créer et configurer une ressource personnalisée TSAMP pour votre adresse IP flottante

Sur l'un des hôtes du cluster, créez et configurez des ressources personnalisées TSAMP pour l'adresse IP flottante.

  1. Sur n'importe quel hôte, utilisez la méthode de votre choix pour créer un fichier de configuration appelé cluster_res.conf et insérez le texte suivant dans ce fichier, après avoir mis à jour le paramètre NodeNameList avec vos noms d'hôte.

    PersistentResourceAttributes::
  Name="gcp_floating_ip-rs"
  ResourceType=1
  StartCommand="/root/gcp_floating_ip.sh start"
  StopCommand="/root/gcp_floating_ip.sh stop"
  MonitorCommand="/root/gcp_floating_ip.sh status"
  MonitorCommandPeriod=30
  MonitorCommandTimeout=30
  StartCommandTimeout=600
  StopCommandTimeout=600
  UserName="root"
  RunCommandsSync=1
  ProtectionMode=0
  NodeNameList={"host-1","host-2"}

  2. Sur l'hôte principal, en tant qu'utilisateur racine, créez la ressource personnalisée TSAMP à l'aide des commandes suivantes.

    export CT_MANAGEMENT_SCOPE=2
mkrsrc -f cluster_res.conf IBM.Application
mkrg -l None gcp_floating_ip-rg
chrg -o Online gcp_floating_ip-rg
addrgmbr -g gcp_floating_ip-rg -m F IBM.Application:gcp_floating_ip-rs
rgreq -o start gcp_floating_ip-rg

  3. Sur l'hôte principal, en tant qu'utilisateur racine, vérifiez que la ressource d'instance Db2 en ligne se trouve sur le même hôte que la ressource d'adresse IP flottante en ligne.

    lssam

    Dans le résultat, les ressources en ligne doivent toutes se trouver sur les mêmes VM hôtes.

    Online IBM.ResourceGroup:db2_db2dh1_db2dh1_DH1-rg Nominal=Online
        '- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs
                |- Online IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s1
                '- Offline IBM.Application:db2_db2dh1_db2dh1_DH1-rs:db2-ha-s2
Online IBM.ResourceGroup:gcp_floating_ip.sh_rg Nominal=Online
        '- Online IBM.Application:gcp_floating_ip.sh_rs
                |- Online IBM.Application:gcp_floating_ip.sh_rs:db2-ha-s1
                '- Offline IBM.Application:gcp_floating_ip.sh_rs:db2-ha-s2

    Si la ressource d'adresse IP flottante n'est pas en ligne sur le même hôte que l'instance de base de données, déplacez la ressource d'adresse IP flottante.

    rgreq -o move -n host-to-move-from gcp_floating_ip-rg

  4. En tant qu'utilisateur racine, sur l'hôte principal, établissez une relation dans TSAMP entre la ressource d'instance de base de données et la ressource d'adresse IP flottante.

    rgreq -o lock gcp_floating_ip-rg
rgreq -o lock db2_db2sid_db2sid_SID-rg
mkrel -o NoCondition -p Collocated \
  -S IBM.Application:gcp_floating_ip-rs -G IBM.Application:db2_db2sid_db2sid_SID-rs \
  db2hadr_colo_gcp_floating_ip
rgreq -o unlock db2_db2sid_db2sid_SID-rg
rgreq -o unlock gcp_floating_ip-rg

    Une fois que vous avez établi une relation entre la ressource d'instance de base de données et la ressource d'adresse IP flottante, vous pouvez à nouveau tester le basculement, comme décrit dans la section suivante.

Vérification du déploiement de votre cluster Db2 haute disponibilité pour SAP sur Google Cloud

Pour vérifier que le cluster HA IBM Db2 est correctement configuré, déclenchez un basculement et vérifiez que toutes les ressources en ligne passent d'une VM hôte à une autre.

Pour effectuer un test de basculement, procédez comme suit :

  1. Sur l'hôte principal en tant qu'utilisateur racine, notez sur quelle VM se trouvent les ressources en ligne.

    lssam

  2. Sur l'hôte principal, passez à l'utilisateur d'instance db2.

    sudo su - db2sid

  3. Lancez l'utilitaire db2haicu.

    db2haicu

  4. Dans l'interface de l'utilitaire db2haicu, déclenchez un basculement en sélectionnant l'option 5 et en suivant les instructions.

  5. Une fois le traitement de l'utilitaire db2haicu terminé, quittez-le.

  6. Passez à l'utilisateur racine.

    sudo su -

  7. Confirmez que les ressources en ligne ont été déplacées vers l'autre VM hôte.

Vérifier l'installation de l'agent Google Cloud pour SAP

Après avoir déployé une VM et installé le système SAP, vérifiez que l'agent Google Cloud pour SAP fonctionne correctement.

Vérifier que l'agent Google Cloud pour SAP est en cours d'exécution

Pour vérifier que l'agent est en cours d'exécution, procédez comme suit :

  1. Établissez une connexion SSH avec votre instance de VM hôte.

  2. Exécutez la commande ci-dessous. 

    systemctl status google-cloud-sap-agent

    Si l'agent fonctionne correctement, la sortie contient active (running). Exemple : 

    google-cloud-sap-agent.service - Google Cloud Agent for SAP
Loaded: loaded (/usr/lib/systemd/system/google-cloud-sap-agent.service; enabled; vendor preset: disabled)
Active:  active (running)  since Fri 2022-12-02 07:21:42 UTC; 4 days ago
Main PID: 1337673 (google-cloud-sa)
Tasks: 9 (limit: 100427)
Memory: 22.4 M (max: 1.0G limit: 1.0G)
CGroup: /system.slice/google-cloud-sap-agent.service
       └─1337673 /usr/bin/google-cloud-sap-agent

Si l'agent n'est pas en cours d'exécution, redémarrez-le.

Vérifier que l'agent hôte SAP reçoit les métriques

Pour vérifier que les métriques d'infrastructure sont collectées par l'agent Google Cloud pour SAP et envoyées correctement à l'agent hôte SAP, procédez comme suit :

  1. Dans votre système SAP, saisissez la transaction ST06.

  2. Dans le volet de synthèse, vérifiez la disponibilité et le contenu des champs suivants pour vous assurer de la configuration de façon correcte et complète de l'infrastructure de surveillance SAP et Google :

    • Fournisseur cloud : Google Cloud Platform
    • Accès à la surveillance améliorée : TRUE
    • Détails de la surveillance améliorée : ACTIVE

Effectuer des tâches post-déploiement

Avant d'utiliser votre système haute disponibilité IBM Db2 sur Google Cloud, nous vous recommandons d'effectuer toutes les activités de post-installation répertoriées dans le guide IBM Db2 high availability solution: IBM Tivoli System Automation for Multiplatforms, y compris les suivantes.

  1. La validation du cluster de base de données.

  2. La sauvegarde de la stratégie de base TSAMP.

  3. La mise à jour des groupes de correctifs de base de données.

  4. La mise à jour des connexions client Db2 afin qu'elles utilisent le nom d'hôte et l'adresse IP de l'adresse IP flottante. Par exemple, mettez à jour le fichier db2cli.ini sur les serveurs d'applications SAP ABAP.

Si vous utilisez une passerelle NAT avec votre cluster HA DB2, terminez la configuration de la passerelle NAT, comme décrit dans la section Completing the NAT gateway installation dans le guide de déploiement d'IBM Db2 pour SAP.