Guide de configuration d'un scaling à la hausse sur un cluster à haute disponibilité pour SAP HANA sur SLES

Ce guide vous explique comment déployer et configurer un cluster à haute disponibilité (HA) SUSE Linux Enterprise Server (SLES) optimisé pour les performances pour un système SAP HANA pouvant évoluer à la hausse sur Google Cloud.

Ce guide comprend les étapes suivantes :

Ce guide comprend également les étapes de configuration de la réplication du système SAP HANA, mais reportez-vous à la documentation SAP pour obtenir les instructions définitives.

Pour déployer un système SAP HANA sans cluster Linux à haute disponibilité ni hôte de nœud de secours, suivez le guide de déploiement de SAP HANA.

Pour configurer un cluster à haute disponibilité pour SAP HANA sur Red Hat Enterprise Linux (RHEL), consultez le guide de configuration d'un cluster à haute disponibilité pour un système SAP HANA pouvant évoluer à la hausse sur RHEL.

Ce guide est destiné aux utilisateurs avancés de SAP HANA qui connaissent bien les configurations Linux à haute disponibilité pour SAP HANA.

Système déployé dans ce guide

En suivant ce guide, vous allez déployer deux instances SAP HANA et configurer un cluster à haute disponibilité sur SLES. Chacune de ces instances SAP HANA va être déployée sur des VM Compute Engine situées dans des zones différentes, mais au sein de la même région. Ce guide ne traite pas de l'installation à haute disponibilité de SAP NetWeaver.

Présentation d'un cluster Linux à haute disponibilité pour un système à évolutivité verticale SAP HANA à nœud unique

Le cluster déployé inclut les fonctions et fonctionnalités suivantes :

  • Deux VM hôtes, chacune avec une instance de SAP HANA
  • La réplication du système SAP HANA synchrone
  • Le gestionnaire de ressources de cluster à haute disponibilité Pacemaker
  • Un mécanisme de cloisonnement STONITH
  • Le redémarrage automatique de l'instance ayant échoué en tant que nouvelle instance secondaire

Ce guide utilise les modèles Cloud Deployment Manager fournis par Google Cloud pour déployer les machines virtuelles (VM) Compute Engine et les instances SAP HANA, ce qui garantit que les VM et les systèmes de base SAP HANA répondent aux exigences de compatibilité de SAP et sont conformes aux bonnes pratiques actuelles.

SAP HANA Studio est utilisé dans ce guide pour tester la réplication du système SAP HANA. Si vous préférez, vous pouvez utiliser SAP HANA Cockpit. Pour plus d'informations sur l'installation de SAP HANA Studio, consultez les pages suivantes :

Prérequis

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

Créer un réseau

Pour des raisons de sécurité, nous vous recommandons de créer un réseau, dont vous contrôlez les accès en ajoutant des règles de pare-feu ou toute autre méthode.

Si votre projet dispose d'un réseau VPC par défaut, ne l'utilisez pas. À la place, créez votre propre réseau VPC afin que les seules règles de pare-feu appliquées soient celles que vous créez explicitement.

Lors du déploiement, les instances de VM nécessitent généralement un accès à Internet pour télécharger l'agent Google Cloud pour SAP. Si vous utilisez l'une des images Linux certifiées SAP disponibles dans Google Cloud, l'instance de VM requiert également l'accès à Internet pour enregistrer la licence et accéder aux dépôts des fournisseurs d'OS. Une configuration comprenant une passerelle NAT et des tags réseau de VM permet aux VM cibles d'accéder à Internet même si elles ne possèdent pas d'adresses IP externes.

Pour configurer la mise en réseau, procédez comme suit :

Console

  1. Dans la console Google Cloud, accédez à la page Réseaux VPC.

    Accéder aux réseaux VPC

  2. Cliquez sur Créer un réseau VPC.
  3. Saisissez un Nom pour le réseau.

    Le nom doit respecter la convention d'attribution de noms. Les réseaux VPC utilisent la convention d'attribution de noms de Compute Engine.

  4. Dans le champ Mode de création du sous-réseau, sélectionnez Custom.
  5. Dans la section Nouveau sous-réseau, spécifiez les paramètres de configuration de sous-réseau suivants :
    1. Saisissez un nom pour le sous-réseau.
    2. Dans le champ Région, sélectionnez la région Compute Engine dans laquelle vous souhaitez créer le sous-réseau.
    3. Pour Type de pile IP, sélectionnez IPv4 (pile unique), puis saisissez une plage d'adresses IP au format CIDR, telle que 10.1.0.0/24.

      Il s'agit de la plage IPv4 principale du sous-réseau. Si vous envisagez d'ajouter plusieurs sous-réseaux, attribuez à chacun d'eux des plages d'adresses IP CIDR qui ne se chevauchent pas dans le réseau. Notez que chaque sous-réseau et ses plages d'adresses IP internes sont mappés sur une seule région.

    4. Cliquez sur OK.
  6. Pour ajouter d'autres sous-réseaux, cliquez sur Ajouter un sous-réseau et répétez les étapes ci-dessus. Vous pouvez ajouter d'autres sous-réseaux au réseau après sa création.
  7. Cliquez sur Créer.

gcloud

  1. Accédez à Cloud Shell.

    Accéder à Cloud Shell

  2. Pour créer un réseau en mode de sous-réseau personnalisé, exécutez la commande suivante : 
    gcloud compute networks create NETWORK_NAME --subnet-mode custom

    Remplacez NETWORK_NAME par le nom du nouveau réseau. Le nom doit respecter la convention d'attribution de noms. Les réseaux VPC utilisent la convention de dénomination de Compute Engine.

    Spécifiez --subnet-mode custom pour éviter d'utiliser le mode automatique par défaut, qui crée automatiquement un sous-réseau dans chaque région Compute Engine. Pour en savoir plus, consultez la section Mode de création du sous-réseau.

  3. Créez un sous-réseau, et spécifiez la région et la plage d'adresses IP : 
    gcloud compute networks subnets create SUBNETWORK_NAME \
    --network NETWORK_NAME --region REGION --range RANGE

    Remplacez les éléments suivants :

    • SUBNETWORK_NAME : nom du nouveau sous-réseau
    • NETWORK_NAME : nom du réseau que vous avez créé à l'étape précédente
    • REGION : région dans laquelle vous souhaitez créer le sous-réseau
    • RANGE : plage d'adresses IP spécifiée au format CIDR (par exemple, 10.1.0.0/24)

      Si vous envisagez d'ajouter plusieurs sous-réseaux, attribuez à chacun d'eux des plages d'adresses IP CIDR qui ne se chevauchent pas. Notez que chaque sous-réseau et ses plages d'adresses IP internes sont mappés sur une seule région.

  4. Si vous le souhaitez, répétez l'étape précédente et ajoutez des sous-réseaux.

Configurer une passerelle NAT

Si vous avez besoin de créer une ou plusieurs VM sans adresse IP publique, vous devez utiliser la traduction d'adresse réseau (NAT) pour permettre aux VM d'accéder à Internet. Utilisez Cloud NAT, un service géré distribué et défini par logiciel de Google Cloud, qui permet aux VM d'envoyer des paquets sortants vers Internet et de recevoir tous les paquets de réponses entrants établis correspondants. Vous pouvez également configurer une VM distincte en tant que passerelle NAT.

Pour créer une instance Cloud NAT pour votre projet, consultez la page Utiliser Cloud NAT.

Une fois que vous avez configuré Cloud NAT pour votre projet, vos instances de VM peuvent accéder en toute sécurité à Internet sans adresse IP publique.

Ajouter des règles de pare-feu

Par défaut, une règle de pare-feu implicite bloque les connexions entrantes provenant de l'extérieur de votre réseau VPC (Virtual Private Cloud, cloud privé virtuel). Pour autoriser les connexions entrantes, configurez une règle de pare-feu pour votre VM. Une fois qu'une connexion entrante est établie avec une VM, le trafic est autorisé dans les deux sens via cette connexion.

Vous pouvez également créer une règle de pare-feu pour autoriser l'accès externe à des ports spécifiés ou pour limiter l'accès entre plusieurs VM d'un même réseau. Si le type de réseau VPC default est utilisé, d'autres règles par défaut s'appliquent également, telles que la règle default-allow-internal, qui permet la connectivité entre les VM d'un même réseau sur tous les ports.

En fonction de la stratégie informatique applicable à votre environnement, vous devrez peut-être isoler votre hôte de base de données, ou en restreindre la connectivité, en créant des règles de pare-feu.

Selon votre scénario, vous pouvez créer des règles de pare-feu afin d'autoriser l'accès pour ce qui suit :

  • Ports SAP par défaut répertoriés dans le tableau listant les ports TCP/IP de tous les produits SAP.
  • Connexions à partir de votre ordinateur ou de votre environnement de réseau d'entreprise à votre instance de VM Compute Engine. Si vous ne savez pas quelle adresse IP utiliser, contactez l'administrateur réseau de votre entreprise.
  • Communication entre VM sur le sous-réseau SAP HANA, y compris la communication entre les nœuds d'un système à évolutivité horizontale SAP HANA ou la communication entre le serveur de base de données et les serveurs d'applications dans une architecture à trois niveaux. Pour activer la communication entre VM, vous pouvez créer une règle de pare-feu autorisant le trafic provenant du sous-réseau.

Pour créer une règle de pare-feu, procédez comme suit :

Console

  1. Dans la console Google Cloud, accédez à la page Pare-feu du réseau VPC.

    Accéder à la page "Pare-feu"

  2. En haut de la page, cliquez sur Créer une règle de pare-feu.

    • Dans le champ Réseau, sélectionnez le réseau sur lequel se trouve votre VM.
    • Dans le champ Cibles, spécifiez les ressources Google Cloud auxquelles cette règle s'applique. Par exemple, spécifiez Toutes les instances du réseau. Pour limiter la règle à des instances spécifiques sur Google Cloud, saisissez des tags dans le champ Tags cibles spécifiés.
    • Dans le champ Filtre source, sélectionnez l'une des options suivantes :
      • Plages IP pour autoriser le trafic entrant provenant d'adresses IP spécifiques. Indiquez la plage d'adresses IP dans le champ Plages d'adresses IP sources.
      • Sous-réseaux pour autoriser le trafic entrant depuis un sous-réseau particulier. Spécifiez le nom du sous-réseau dans le champ Sous-réseaux qui s'affiche. Utilisez cette option pour autoriser l'accès entre plusieurs VM dans une configuration à trois niveaux ou évolutive.
    • Dans la section Protocoles et ports, sélectionnez Protocoles et ports spécifiés, puis saisissez tcp:PORT_NUMBER.

  3. Cliquez sur Créer pour créer la règle de pare-feu.

gcloud

Créez une règle de pare-feu à l'aide de la commande suivante :

$ gcloud compute firewall-rules create FIREWALL_NAME
--direction=INGRESS --priority=1000 \
--network=NETWORK_NAME --action=ALLOW --rules=PROTOCOL:PORT \
--source-ranges IP_RANGE --target-tags=NETWORK_TAGS

Déployer les VM et SAP HANA

Avant de commencer à configurer le cluster à haute disponibilité, vous devez définir et déployer les instances de VM et les systèmes SAP HANA qui servent de nœuds principal et secondaire dans le cluster à haute disponibilité.

Pour définir et déployer les systèmes, utilisez le même modèle Cloud Deployment Manager que celui qui a servi à déployer un système SAP HANA dans le guide de déploiement de SAP HANA.

Toutefois, pour déployer deux systèmes au lieu d'un, vous devez ajouter la définition du second système au fichier de configuration en copiant et en collant la définition du premier système. Après avoir créé la seconde définition, vous devez modifier les noms des ressources et des instances dans celle-ci. Pour vous protéger contre une défaillance de zone, spécifiez une zone différente de la même région. Toutes les autres propriétés des deux définitions conservent la même valeur.

Une fois les systèmes SAP HANA déployés, définissez et configurez le cluster à haute disponibilité.

Les instructions suivantes utilisent Cloud Shell, mais sont généralement applicables à Google Cloud CLI.

  1. Vérifiez que vos quotas actuels pour les ressources, telles que les disques persistants et les processeurs, sont suffisants pour les systèmes SAP HANA que vous allez installer. Si vos quotas sont insuffisants, le déploiement échoue. Pour connaître les exigences en matière de quotas de SAP HANA, consultez la section Remarques relatives aux tarifs et aux quotas applicables à SAP HANA.

    Accéder à la page "Quotas"

  2. Ouvrez Cloud Shell ou, si vous avez installé gcloud CLI sur votre poste de travail local, ouvrez un terminal.

    Accéder à Cloud Shell

  3. Téléchargez dans votre répertoire de travail le modèle de fichier de configuration template.yaml pour le cluster SAP HANA à haute disponibilité. Pour ce faire, saisissez la commande suivante dans Cloud Shell ou gcloud CLI :

    wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/template.yaml

  4. Renommez éventuellement le fichier template.yaml pour identifier la configuration qu'il définit.

  5. Ouvrez le fichier template.yaml dans l'éditeur de code Cloud Shell ou, si vous utilisez gcloud CLI, dans l'éditeur de texte de votre choix.

    Pour ce faire, cliquez sur l'icône en forme de crayon située dans l'angle supérieur droit de la fenêtre du terminal Cloud Shell.

  6. Dans le fichier template.yaml, terminez la définition du système SAP HANA principal. Spécifiez les valeurs des propriétés en remplaçant les crochets et leur contenu par les valeurs de votre installation. Ces propriétés sont décrites dans le tableau ci-dessous.

    Pour créer des instances de VM sans installer SAP HANA, supprimez ou commentez toutes les lignes commençant par sap_hana_.

    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 Chaîne Nom de l'instance de VM en cours de définition. Spécifiez des noms différents dans les définitions des VM principale et secondaire. Ces noms ne doivent contenir que des lettres minuscules, des chiffres ou des traits d'union.
    instanceType Chaîne Type de machine virtuelle Compute Engine nécessaire à l'exécution de SAP HANA. Si vous avez besoin d'un type de VM personnalisé, spécifiez un type de VM prédéfini avec un nombre de processeurs virtuels le plus proche possible de la quantité dont vous avez besoin tout en étant légèrement supérieur. Une fois le déploiement terminé, modifiez le nombre de processeurs virtuels et la quantité de mémoire.
    zone Chaîne Zone Google Cloud dans laquelle déployer l'instance de VM que vous définissez. Spécifiez des zones différentes de la même région pour les définitions HANA principales et secondaires. Ces zones doivent se trouver dans la même région que celle que vous avez sélectionnée pour votre sous-réseau.
    subnetwork Chaîne Nom du sous-réseau que vous avez créé précédemment. Si vous procédez au déploiement sur un VPC partagé, spécifiez cette valeur en tant que [SHAREDVPC_PROJECT]/[SUBNETWORK]. Exemple :myproject/network1
    linuxImage Chaîne Nom de la famille d'images ou de l'image du système d'exploitation Linux que vous utilisez avec SAP HANA. Pour spécifier une famille d'images, ajoutez le préfixe family/ au nom de la famille. Exemple :family/sles-15-sp1-sap Pour spécifier une image spécifique, indiquez uniquement le nom de l'image. Pour obtenir la liste des images et des familles disponibles, consultez la page Images dans la console Google Cloud.
    linuxImageProject Chaîne Le projet Google Cloud qui contient l'image que vous allez utiliser. Ce projet peut être votre propre projet ou un projet d'image Google Cloud, tel que suse-sap-cloud. Pour en savoir plus sur les projets d'image Google Cloud, consultez la page Images dans la documentation Compute Engine.
    sap_hana_deployment_bucket Chaîne Nom du bucket Google Cloud Storage de votre projet contenant les fichiers d'installation et de révision de SAP HANA que vous avez importés précédemment. Tous les fichiers de révision de mise à niveau du bucket sont appliqués à SAP HANA au cours du processus de déploiement.
    sap_hana_sid Chaîne ID système (SID) SAP HANA. L'ID doit comporter trois caractères alphanumériques et commencer par une lettre. Les lettres doivent être saisies en majuscules.
    sap_hana_instance_number Entier Numéro d'instance (0 à 99) du système SAP HANA. La valeur par défaut est 0.
    sap_hana_sidadm_password Chaîne Mot de passe de l'administrateur du système d'exploitation (OS). Les mots de passe doivent comporter au moins huit caractères et inclure au moins une lettre majuscule, une lettre minuscule et un chiffre.
    sap_hana_system_password Chaîne Mot de passe du super-utilisateur de la base de données. Les mots de passe doivent comporter au moins huit caractères et inclure au moins une lettre majuscule, une lettre minuscule et un chiffre.
    sap_hana_sidadm_uid Entier La valeur par défaut pour l'ID utilisateur SID_LCadm est 900 afin d'éviter les conflits entre les groupes créés par les utilisateurs et SAP HANA. Vous pouvez modifier cette valeur si nécessaire.
    sap_hana_sapsys_gid Entier L'ID de groupe par défaut pour sapsys est 79. En spécifiant une valeur supérieure, vous pouvez remplacer cette valeur selon vos besoins.
    sap_hana_scaleout_nodes Entier Spécifiez 0. Ces instructions sont destinées uniquement aux systèmes avec scaling à la hausse SAP HANA.
    networkTag Chaîne Tag réseau qui représente votre instance de VM à des fins de routage ou d'établissement/application de règles de pare-feu. Si vous spécifiez publicIP: No et ne spécifiez pas de tag réseau, veillez à fournir un autre moyen d'accès à Internet.
    nic_type Chaîne Facultatif, mais recommandé si disponible pour la machine cible et la version de l'OS. Spécifie l'interface réseau à utiliser avec l'instance de VM. Vous pouvez spécifier la valeur GVNIC ou VIRTIO_NET. Pour utiliser une carte d'interface réseau virtuelle Google (gVNIC), vous devez spécifier une image de l'OS compatible avec gVNIC comme valeur de la propriété linuxImage. Pour obtenir la liste des images de l'OS, consultez la section Détails des systèmes d'exploitation.

    Si vous ne spécifiez pas de valeur pour cette propriété, l'interface réseau est automatiquement sélectionnée en fonction du type de machine que vous spécifiez pour la propriété instanceType.

    Cet argument est disponible dans les versions 202302060649 du modèle Deployment Manager ou ultérieures.
    publicIP Booléen Facultatif. Détermine si une adresse IP publique est ajoutée à votre instance de VM. La valeur par défaut est Yes.
    serviceAccount Chaîne Facultatif. Spécifie un compte de service destiné à être utilisé par les VM hôtes et par les programmes exécutés sur celles-ci. Spécifiez l'adresse e-mail du compte de service. Par exemple, svc-acct-name@project-id.iam.gserviceaccount.com. Par défaut, le compte de service Compute Engine par défaut est utilisé. Pour en savoir plus, consultez la page Gestion de l'authentification et des accès pour les programmes SAP sur Google Cloud.

  7. Créez la définition du système SAP HANA secondaire en copiant la définition du système SAP HANA principal et en collant la copie après la définition principale du système SAP HANA. Reportez-vous à l'exemple qui suit ces étapes.

  8. Dans la définition du système SAP HANA secondaire, spécifiez des valeurs différentes de celles spécifiées dans la définition principale du système SAP HANA pour les propriétés suivantes :

    • name
    • instanceName
    • zone

  9. Créez les instances :

    gcloud deployment-manager deployments create DEPLOYMENT_NAME --config TEMPLATE_NAME.yaml

    La commande ci-dessus appelle Deployment Manager, lequel déploie les VM, télécharge le logiciel SAP HANA à partir de votre bucket de stockage, puis l'installe, conformément aux spécifications de votre fichier template.yaml.

    Le processus de déploiement comprend deux étapes. Tout d'abord, Deployment Manager écrit son état dans la console. Ensuite, les scripts de déploiement écrivent leur état dans Cloud Logging.

Exemple de fichier de configuration template.yaml complet

L'exemple suivant montre un fichier de configuration template.yaml terminé qui déploie deux instances de VM avec un système SAP HANA installé.

Le fichier contient les définitions des deux ressources à déployer : sap_hana_primary et sap_hana_secondary. Chaque définition de ressource contient les définitions d'une VM et d'une instance SAP HANA.

La définition de la ressource sap_hana_secondary a été créée en copiant et en collant la première définition, puis en modifiant les valeurs des propriétés name, instanceName et zone. Les valeurs de toutes les autres propriétés dans les deux définitions de ressources sont identiques.

Les propriétés networkTag, serviceAccount, sap_hana_sidadm_uid et sap_hana_sapsys_gid proviennent de la section "Options avancées" du modèle de fichier de configuration. Les propriétés sap_hana_sidadm_uid et sap_hana_sapsys_gid sont incluses pour afficher leurs valeurs par défaut, qui sont utilisées car les propriétés sont commentées.

resources:
- name: sap_hana_primary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.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/yyyymmddhhmm/dm-templates/sap_hana/sap_hana.py
  #
  properties:
    instanceName: hana-ha-vm-1
    instanceType: n2-highmem-32
    zone: us-central1-a
    subnetwork: example-subnet-us-central1
    linuxImage: family/sles-15-sp1-sap
    linuxImageProject: suse-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Tempa55word
    sap_hana_system_password: Tempa55word
    sap_hana_scaleout_nodes: 0
    networkTag: cluster-ntwk-tag
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79

- name: sap_hana_secondary
  type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.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/yyyymmddhhmm/dm-templates/sap_hana/sap_hana.py
  #
  properties:
    instanceName: hana-ha-vm-2
    instanceType: n2-highmem-32
    zone: us-central1-c
    subnetwork: example-subnet-us-central1
    linuxImage: family/sles-15-sp1-sap
    linuxImageProject: suse-sap-cloud
    sap_hana_deployment_bucket: hana2-sp4-rev46
    sap_hana_sid: HA1
    sap_hana_instance_number: 22
    sap_hana_sidadm_password: Google123
    sap_hana_system_password: Google123
    sap_hana_scaleout_nodes: 0
    networkTag: cluster-ntwk-tag
    serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com
    # sap_hana_sidadm_uid: 900
    # sap_hana_sapsys_gid: 79

Créer des règles de pare-feu autorisant l'accès aux VM hôtes

Si vous ne l'avez pas déjà fait, créez des règles de pare-feu autorisant l'accès à chaque VM hôte à partir des sources suivantes :

  • À des fins de configuration, votre poste de travail local, un hôte bastion ou un serveur de saut
  • Pour l'accès entre les nœuds du cluster, les autres VM hôtes dans le cluster à haute disponibilité

Lorsque vous créez des règles de pare-feu VPC, vous spécifiez les tags réseau que vous avez définis dans le fichier de configuration template.yaml pour désigner vos VM hôtes comme cibles de la règle.

Pour vérifier le déploiement, définissez une règle autorisant les connexions SSH sur le port 22 à partir d'un hôte bastion ou de votre poste de travail local.

Pour l'accès entre les nœuds du cluster, ajoutez une règle de pare-feu qui autorise tous les types de connexion sur n'importe quel port d'autres VM du même sous-réseau.

Assurez-vous que les règles de pare-feu pour la vérification du déploiement et la communication au sein du cluster sont créées avant de passer à la section suivante. Pour obtenir des instructions, consultez la section Ajouter des règles de pare-feu.

Vérifier le déploiement des VM et de SAP HANA

Pour vérifier le déploiement, vérifiez les journaux de déploiement dans Cloud Logging, ainsi que les disques et les services sur les VM des hôtes principaux et secondaires.

  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 :

    Explorateur de journaux

    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 Quotas de IAM & Admin, augmentez les quotas qui ne répondent pas aux exigences de SAP HANA décrites dans le guide de planification SAP HANA.

      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 des VM et de SAP HANA

  1. Une fois le système SAP HANA déployé sans erreur, connectez-vous à chaque VM à l'aide du protocole SSH. Sur la page VM instances (Instances de VM) de Compute Engine, cliquez sur le bouton SSH de votre instance de VM ou utilisez la méthode SSH de votre choix.

    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. Sur chaque VM, assurez-vous que les répertoires /hana s'affichent, par exemple /hana/data.

    Filesystem                        Size  Used Avail Use% Mounted on
/dev/sda2                          30G  4.0G   26G  14% /
devtmpfs                          126G     0  126G   0% /dev
tmpfs                             126G     0  126G   0% /dev/shm
tmpfs                             126G   17M  126G   1% /run
tmpfs                             126G     0  126G   0% /sys/fs/cgroup
/dev/sda1                         200M  9.7M  191M   5% /boot/efi
/dev/mapper/vg_hana-shared        251G   49G  203G  20% /hana/shared
/dev/mapper/vg_hana-sap            32G  240M   32G   1% /usr/sap
/dev/mapper/vg_hana-data          426G  7.0G  419G   2% /hana/data
/dev/mapper/vg_hana-log           125G  4.2G  121G   4% /hana/log
/dev/mapper/vg_hanabackup-backup  512G   33M  512G   1% /hanabackup
tmpfs                              26G     0   26G   0% /run/user/900
tmpfs                              26G     0   26G   0% /run/user/899
tmpfs                              26G     0   26G   0% /run/user/1000

  4. Connectez-vous en tant qu'administrateur SAP en remplaçant SID_LC dans la commande suivante par l'ID système que vous avez spécifié dans le modèle de fichier de configuration. Utilisez des minuscules pour toutes les lettres.

    # su - SID_LCadm

  5. Assurez-vous que les services SAP HANA, tels que hdbnameserver, hdbindexserver et autres services, s'exécutent sur l'instance en saisissant la commande suivante :

    > HDB info

  6. Si vous utilisez RHEL pour SAP 9.0 ou une version ultérieure, assurez-vous que les packages chkconfig et compat-openssl11 sont installés sur votre instance de VM.

    Pour en savoir plus, consultez la note SAP 3108316 – Red Hat Enterprise Linux 9.x : installation et configuration.

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 suivante : 

    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

Configurer la surveillance pour SAP HANA

Vous pouvez éventuellement surveiller vos instances SAP HANA à l'aide de l'agent Google Cloud pour SAP. À partir de la version 2.0, vous pouvez configurer l'agent de sorte qu'il collecte les métriques de surveillance SAP HANA et les envoie à Cloud Monitoring. Cloud Monitoring vous permet de créer des tableaux de bord pour visualiser ces métriques, de configurer des alertes en fonction de seuils de métriques, etc.

Pour en savoir plus sur la collecte des métriques de surveillance SAP HANA à l'aide de l'agent Google Cloud pour SAP, consultez Collecte des métriques de surveillance SAP HANA.

Désactiver le démarrage automatique de SAP HANA

Pour chaque instance SAP HANA du cluster, assurez-vous que le démarrage automatique de SAP HANA est désactivé. Pour les basculements, Pacemaker gère le démarrage et l'arrêt des instances SAP HANA dans un cluster.

  1. Sur chaque hôte, en tant que SID_LCadm, arrêtez SAP HANA :

    > HDB stop

  2. Sur chaque hôte, ouvrez le profil SAP HANA à l'aide d'un éditeur, tel que vi :

    vi /usr/sap/SID/SYS/profile/SID_HDBINST_NUM_HOST_NAME

  3. Définissez la propriété Autostart sur 0 :

    Autostart=0

  4. Enregistrez le profil.

  5. Sur chaque hôte, en tant que SID_LCadm, démarrez SAP HANA :

    > HDB start

Activer le redémarrage rapide de SAP HANA

Google Cloud recommande fortement d'activer le redémarrage rapide SAP HANA pour chaque instance de SAP HANA, en particulier pour les instances de grande capacité. Le redémarrage rapide de SAP HANA réduit le temps de redémarrage en cas d'arrêt de SAP HANA, mais le système d'exploitation reste en cours d'exécution.

Comme configuré par les scripts d'automatisation fournis par Google Cloud, les paramètres du système d'exploitation et du noyau sont déjà compatibles avec le redémarrage rapide de SAP HANA. Vous devez définir le système de fichiers tmpfs et configurer SAP HANA.

Pour définir le système de fichiers tmpfs et configurer SAP HANA, vous pouvez suivre les étapes manuelles ou utiliser le script d'automatisation fourni par Google Cloud pour activer le redémarrage rapide de SAP HANA. Pour en savoir plus, consultez les pages suivantes :

Pour obtenir des instructions faisant autorité sur la fonction de redémarrage rapide SAP HANA, consultez la documentation sur les options de redémarrage rapide de SAP HANA.

Étapes manuelles

Configurer le système de fichiers tmpfs

Une fois les VM hôtes et les systèmes SAP HANA de base déployés, vous devez créer et installer des répertoires pour les nœuds NUMA du système de fichiers tmpfs.

Afficher la topologie NUMA de votre VM

Pour pouvoir mapper le système de fichiers tmpfs requis, vous devez connaître la quantité de nœuds NUMA dont dispose votre VM. Pour afficher les nœuds NUMA disponibles sur une VM Compute Engine, saisissez la commande suivante :

lscpu | grep NUMA

Par exemple, un type de VM m2-ultramem-208 comporte quatre nœuds NUMA, numérotés de 0 à 3, comme illustré dans l'exemple suivant :

NUMA node(s):        4
NUMA node0 CPU(s):   0-25,104-129
NUMA node1 CPU(s):   26-51,130-155
NUMA node2 CPU(s):   52-77,156-181
NUMA node3 CPU(s):   78-103,182-207
Créer les répertoires de nœuds NUMA

Créez un répertoire pour chaque nœud NUMA de votre VM et définissez les autorisations.

Par exemple, pour quatre nœuds NUMA numérotés de 0 à 3 :

mkdir -pv /hana/tmpfs{0..3}/SID
chown -R SID_LCadm:sapsys /hana/tmpfs*/SID
chmod 777 -R /hana/tmpfs*/SID
Installer les répertoires de nœuds NUMA dans tmpfs

Montez les répertoires du système de fichiers tmpfs et spécifiez une préférence de nœud NUMA pour chacun avec mpol=prefer :

SID : spécifiez le SID en majuscules.

mount tmpfsSID0 -t tmpfs -o mpol=prefer:0 /hana/tmpfs0/SID
mount tmpfsSID1 -t tmpfs -o mpol=prefer:1 /hana/tmpfs1/SID
mount tmpfsSID2 -t tmpfs -o mpol=prefer:2 /hana/tmpfs2/SID
mount tmpfsSID3 -t tmpfs -o mpol=prefer:3 /hana/tmpfs3/SID
Mettre à jour /etc/fstab

Pour vous assurer que les points d'installation sont disponibles après un redémarrage du système d'exploitation, ajoutez des entrées dans la table du système de fichiers, /etc/fstab :

tmpfsSID0 /hana/tmpfs0/SID tmpfs rw,relatime,mpol=prefer:0
tmpfsSID1 /hana/tmpfs1/SID tmpfs rw,relatime,mpol=prefer:1
tmpfsSID1 /hana/tmpfs2/SID tmpfs rw,relatime,mpol=prefer:2
tmpfsSID1 /hana/tmpfs3/SID tmpfs rw,relatime,mpol=prefer:3

Facultatif : définir des limites à l'utilisation de la mémoire

Le système de fichiers tmpfs peut augmenter ou diminuer de manière dynamique.

Pour limiter la mémoire utilisée par le système de fichiers tmpfs, vous pouvez définir une limite de taille pour un volume de nœuds NUMA en utilisant l'option size. Exemple :

mount tmpfsSID0 -t tmpfs -o mpol=prefer:0,size=250G /hana/tmpfs0/SID

Vous pouvez également limiter l'utilisation globale de la mémoire tmpfs pour tous les nœuds NUMA d'une instance SAP HANA donnée et d'un nœud de serveur donné en définissant le paramètre persistent_memory_global_allocation_limit dans la section [memorymanager] du fichier global.ini.

Configuration de SAP HANA pour le redémarrage rapide

Pour configurer SAP HANA pour le redémarrage rapide, mettez à jour le fichier global.ini et spécifiez les tables à stocker dans la mémoire persistante.

Mettre à jour la section [persistence] du fichier global.ini

Configurez la section [persistence] du fichier SAP HANA global.ini de manière à référencer les emplacements tmpfs. Séparez chaque emplacement tmpfs par un point-virgule :

[persistence]
basepath_datavolumes = /hana/data
basepath_logvolumes = /hana/log
basepath_persistent_memory_volumes = /hana/tmpfs0/SID;/hana/tmpfs1/SID;/hana/tmpfs2/SID;/hana/tmpfs3/SID

L'exemple précédent spécifie quatre volumes de mémoire pour quatre nœuds NUMA, ce qui correspond à m2-ultramem-208. Si vous l'exécutez sur m2-ultramem-416, vous devez configurer huit volumes de mémoire (de 0 à 7).

Redémarrez SAP HANA après avoir modifié le fichier global.ini.

SAP HANA peut désormais utiliser l'emplacement tmpfs comme espace de mémoire persistant.

Spécifier les tables à stocker en mémoire persistante

Spécifiez des tables ou partitions de colonne spécifiques à stocker en mémoire persistante.

Par exemple, pour activer la mémoire persistante pour une table existante, exécutez la requête SQL :

ALTER TABLE exampletable persistent memory ON immediate CASCADE

Pour modifier la valeur par défaut des nouvelles tables, ajoutez le paramètre table_default dans le fichier indexserver.ini. Exemple :

[persistent_memory]
table_default = ON

Pour en savoir plus sur le contrôle des colonnes et des tables ainsi que sur les vues de surveillance qui fournissent des informations détaillées, consultez la page Mémoire persistante SAP HANA.

Étapes automatisées

Le script d'automatisation fourni par Google Cloud pour activer le redémarrage rapide de SAP HANA apporte des modifications aux répertoires /hana/tmpfs*, au fichier /etc/fstab et à la configuration de SAP HANA. Lorsque vous exécuterez le script, vous devrez peut-être effectuer des étapes supplémentaires selon qu'il s'agit du déploiement initial de votre système SAP HANA ou que vous redimensionnez votre machine sur une autre taille NUMA.

Pour le déploiement initial de votre système SAP HANA ou le redimensionnement de la machine pour augmenter le nombre de nœuds NUMA, assurez-vous que SAP HANA est en cours d'exécution pendant l'exécution du script d'automatisation fourni par Google Cloud pour activer le redémarrage rapide de SAP HANA.

Lorsque vous redimensionnez votre machine pour réduire le nombre de nœuds NUMA, assurez-vous que SAP HANA est arrêté pendant l'exécution du script d'automatisation fourni par Google Cloud pour permettre le redémarrage rapide de SAP HANA. Une fois le script exécuté, vous devez mettre à jour manuellement la configuration SAP HANA pour terminer la configuration du redémarrage rapide de SAP HANA. Pour en savoir plus, consultez la section Configuration de SAP HANA pour le redémarrage rapide.

Pour activer le redémarrage rapide de SAP HANA, procédez comme suit :

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

  2. Passez en mode root : 

    sudo su -

  3. Téléchargez le script sap_lib_hdbfr.sh :

    wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/lib/sap_lib_hdbfr.sh

  4. Rendez le fichier exécutable :

    chmod +x sap_lib_hdbfr.sh

  5. Vérifiez que le script ne comporte aucune erreur :

    vi sap_lib_hdbfr.sh
./sap_lib_hdbfr.sh -help

    Si la commande renvoie une erreur, contactez le Cloud Customer Care. Pour en savoir plus sur la procédure à suivre pour contacter le service client, consultez la page Obtenir de l'aide concernant SAP sur Google Cloud.

  6. Exécutez le script après avoir remplacé l'ID système (SID) et le mot de passe SAP HANA de l'utilisateur système de la base de données SAP HANA. Pour fournir le mot de passe en toute sécurité, nous vous recommandons d'utiliser un secret dans Secret Manager.

    Exécutez le script en utilisant le nom d'un secret dans Secret Manager. Ce secret doit exister dans le projet Google Cloud qui contient votre instance de VM hôte.

    sudo ./sap_lib_hdbfr.sh -h 'SID' -s SECRET_NAME

    Remplacez les éléments suivants :

    • SID : spécifiez le SID en majuscules. Par exemple, AHA.
    • SECRET_NAME : spécifiez le nom du secret correspondant au mot de passe de l'utilisateur système de la base de données SAP HANA. Ce secret doit exister dans le projet Google Cloud qui contient votre instance de VM hôte.

    Vous pouvez également exécuter le script en utilisant un mot de passe en texte brut. Une fois le redémarrage rapide de SAP HANA activé, veillez à modifier votre mot de passe. L'utilisation d'un mot de passe en texte brut n'est pas recommandée, car celui-ci serait enregistré dans l'historique de ligne de commande de votre VM.

    sudo ./sap_lib_hdbfr.sh -h 'SID' -p 'PASSWORD'

    Remplacez les éléments suivants :

    • SID : spécifiez le SID en majuscules. Par exemple, AHA.
    • PASSWORD : spécifiez le mot de passe de l'utilisateur système de la base de données SAP HANA.

Dans le cas d'une exécution initiale réussie, vous devez obtenir une sortie semblable à celle-ci :

INFO - Script is running in standalone mode
ls: cannot access '/hana/tmpfs*': No such file or directory
INFO - Setting up HANA Fast Restart for system 'TST/00'.
INFO - Number of NUMA nodes is 2
INFO - Number of directories /hana/tmpfs* is 0
INFO - HANA version 2.57
INFO - No directories /hana/tmpfs* exist. Assuming initial setup.
INFO - Creating 2 directories /hana/tmpfs* and mounting them
INFO - Adding /hana/tmpfs* entries to /etc/fstab. Copy is in /etc/fstab.20220625_030839
INFO - Updating the HANA configuration.
INFO - Running command: select * from dummy
DUMMY
"X"
1 row selected (overall time 4124 usec; server time 130 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistence', 'basepath_persistent_memory_volumes') = '/hana/tmpfs0/TST;/hana/tmpfs1/TST;'
0 rows affected (overall time 3570 usec; server time 2239 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistent_memory', 'table_unload_action') = 'retain';
0 rows affected (overall time 4308 usec; server time 2441 usec)

INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'SYSTEM') SET ('persistent_memory', 'table_default') = 'ON';
0 rows affected (overall time 3422 usec; server time 2152 usec)

Configurer les clés SSH sur les VM principale et secondaire

Les clés du magasin sécurisé SAP HANA (SSFS) doivent être synchronisées entre les hôtes du cluster à haute disponibilité. Pour simplifier la synchronisation et autoriser la copie de fichiers tels que les sauvegardes entre les hôtes du cluster à haute disponibilité, ces instructions vous permettent de créer des connexions SSH racine entre les deux hôtes.

Votre organisation dispose probablement de consignes régissant les communications réseau internes. Si nécessaire, une fois le déploiement terminé, vous pouvez supprimer les métadonnées des VM et les clés du répertoire authorized_keys.

Si la configuration de connexions SSH directes ne respecte pas les consignes de votre organisation, vous pouvez synchroniser les clés SSFS et transférer des fichiers à l'aide d'autres méthodes, par exemple :

  • Transférez des fichiers plus petits via votre poste de travail local à l'aide des options de menu Importer un fichier et Télécharger un fichier de Cloud Shell. Consultez la page Gérer des fichiers avec Cloud Shell.
  • Échangez des fichiers à l'aide d'un bucket Google Cloud Storage. Consultez la page Travailler avec des objets dans la documentation Cloud Storage.
  • Utilisez l'agent Backint de Cloud Storage pour SAP HANA afin de sauvegarder et de restaurer des bases de données HANA. Consultez la section Agent Backint de Cloud Storage pour SAP HANA.
  • Utilisez une solution de stockage de fichiers telle que Filestore ou NetApp Cloud Volumes Service pour créer un dossier partagé. Consultez la section Options de serveur de fichiers.

Pour activer les connexions SSH entre les instances principale et secondaire, procédez comme indiqué ci-dessous.

  1. Sur la VM hôte principale :

    1. Connectez-vous en SSH à la VM.

    2. Passez en mode root :

    $ sudo su -

    1. Générez une clé SSH en mode root.

      # ssh-keygen

    2. Mettez à jour les métadonnées de la VM principale avec les informations sur la clé SSH de la VM secondaire.

      # gcloud compute instances add-metadata secondary-host-name \
--metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" --zone secondary-zone

    3. Autorisez la VM principale sur elle-même.

      # cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

  2. Sur la VM hôte secondaire :

    1. Connectez-vous en SSH à la VM.

    2. Passez en mode root :

    $ sudo su -

    1. Générez une clé SSH en mode root.

      # ssh-keygen

    2. Mettez à jour les métadonnées de la VM secondaire avec les informations sur la clé SSH de la VM principale.

      # gcloud compute instances add-metadata primary-host-name \
--metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" --zone primary-zone

    3. Autorisez la VM secondaire sur elle-même.

      # cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

    4. Afin de vérifier que les clés SSH sont configurées correctement, ouvrez une connexion SSH depuis le système secondaire vers le système principal.

      # ssh primary-host-name

  3. Sur la VM hôte principale, en mode root, confirmez la connexion en ouvrant une connexion SSH vers la VM hôte secondaire :

    # ssh secondary-host-name

Créer un utilisateur de base de données SAP HANA pour surveiller l'état du cluster

  1. Sur l'hôte principal, en tant que SID_LCadm, connectez-vous au terminal interactif de la base de données SAP HANA :

    > hdbsql -u system -p "system-password" -i inst_num

  2. Dans le terminal interactif, créez l'utilisateur de base de données slehasync :

    => CREATE USER slehasync PASSWORD "hdb-user-password";
=> GRANT CATALOG READ TO slehasync;
=> GRANT MONITOR ADMIN TO slehasync;
=> ALTER USER slehasync DISABLE PASSWORD LIFETIME;

  3. En tant que SID_LCadm, définissez la clé utilisateur SLEHALOC dans le magasin d'utilisateurs sécurisé de SAP HANA (hdbuserstore) :

    > PATH="$PATH:/usr/sap/SID/HDBinst_num/exe"
> hdbuserstore SET SLEHALOC localhost:3inst_num15 slehasync hdb-user-password

Sauvegarder les bases de données

Créez des sauvegardes de vos bases de données afin de lancer la journalisation des bases de données pour la réplication du système SAP HANA et créer un point de récupération.

Si vous avez plusieurs bases de données locataires dans une configuration MDC, sauvegardez chacune de ces bases de données.

Le modèle Deployment Manager utilise /hanabackup/data/SID comme répertoire de sauvegarde par défaut.

Pour créer des sauvegardes de nouvelles bases de données SAP HANA, procédez comme suit :

  1. Sur l'hôte principal, passez en SID_LCadm. Selon votre image de système d'exploitation, la commande peut être différente.

    sudo -i -u SID_LCadm

  2. Créez des sauvegardes de bases de données :

    • Pour un système à conteneur de bases de données unique SAP HANA :

      > hdbsql -t -u system -p SYSTEM_PASSWORD -i INST_NUM \
  "backup data using file ('full')"

      L'exemple suivant montre une réponse positive d'un nouveau système SAP HANA :

      0 rows affected (overall time 18.416058 sec; server time 18.414209 sec)

    • Pour un système à conteneurs de bases de données multiples (MDC, multi-database-container) SAP HANA, créez une sauvegarde de la base de données système ainsi que des bases de données locataires :

      > hdbsql -t -d SYSTEMDB -u system -p SYSTEM_PASSWORD -i INST_NUM \
  "backup data using file ('full')"
       
      > hdbsql -t -d SID -u system -p SYSTEM_PASSWORD -i INST_NUM \
  "backup data using file ('full')"

    L'exemple suivant montre une réponse positive d'un nouveau système SAP HANA :

    0 rows affected (overall time 16.590498 sec; server time 16.588806 sec)

  3. Vérifiez que le mode de journalisation est défini sur "normal" :

    > hdbsql -u system -p SYSTEM_PASSWORD -i INST_NUM \
  "select value from "SYS"."M_INIFILE_CONTENTS" where key='log_mode'"

    Vous devriez voir les éléments suivants :

    VALUE
"normal"

Activer la réplication du système SAP HANA

Dans le cadre de l'activation de la réplication du système SAP HANA, vous devez copier les données et les fichiers de clés pour les magasins sécurisés SAP HANA du système de fichiers (SSFS) de l'hôte principal vers l'hôte secondaire. La méthode utilisée dans cette procédure pour copier les fichiers n'est que l'une des méthodes possibles.

  1. Sur l'hôte principal, en tant que SID_LCadm, activez la réplication du système :

    > hdbnsutil -sr_enable --name=PRIMARY_HOST_NAME

  2. Sur l'hôte secondaire :

    1. En tant que SID_LCadm, arrêtez SAP HANA :

      > HDB stop

    2. En mode root, archivez les données SSFS et les fichiers de clés existants :

      # cd /usr/sap/SID/SYS/global/security/rsecssfs/
# mv data/SSFS_SID.DAT data/SSFS_SID.DAT-ARC
# mv key/SSFS_SID.KEY key/SSFS_SID.KEY-ARC

    3. Copiez le fichier de données de l'hôte principal :

      # scp -o StrictHostKeyChecking=no \
PRIMARY_HOST_NAME:/usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT \
/usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT

    4. Copiez le fichier de clé de l'hôte principal :

      # scp -o StrictHostKeyChecking=no \
PRIMARY_HOST_NAME:/usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY \
/usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

    5. Mettez à jour la propriété des fichiers :

      # chown SID_LCadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT
# chown SID_LCadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

    6. Mettez à jour les autorisations pour les fichiers :

      # chmod 644 /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT
# chmod 640 /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY

    7. En tant que SID_LCadm, enregistrez le système SAP HANA secondaire avec la réplication du système SAP HANA active :

      > hdbnsutil -sr_register --remoteHost=PRIMARY_HOST_NAME --remoteInstance=INST_NUM \
--replicationMode=syncmem --operationMode=logreplay --name=SECONDARY_HOST_NAME

    8. En tant que SID_LCadm, démarrez SAP HANA :

      > HDB start

Valider la réplication du système

Sur l'hôte principal, en tant que SID_LCadm, vérifiez que la réplication du système SAP HANA est active en exécutant le script Python suivant :

$ python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py

Si la réplication est correctement configurée, entre autres indicateurs, les valeurs suivantes s'affichent pour les services xsengine, nameserver et indexserver :

  • Secondary Active Status est défini sur YES.
  • Replication Status est défini sur ACTIVE.

En outre, overall system replication status affiche ACTIVE.

Activer les hooks de fournisseur HA/DR SAP HANA

SUSE vous recommande d'activer les hooks de fournisseur HA/DR (haute disponibilité/reprise après sinistre) SAP HANA, qui permet à SAP HANA d'envoyer des notifications pour certains événements et améliore la détection des défaillances. Les hooks de fournisseur de haute disponibilité/reprise après sinistre (HA/DR, High Availability/Disaster Recovery) nécessitent SAP HANA 2.0 SPS 03 ou une version ultérieure.

Sur le site principal et le site secondaire, procédez comme suit :

  1. En tant que SID_LCadm, arrêtez SAP HANA :

    > HDB stop

  1. En tant qu'utilisateur racine ou SID_LCadm, ouvrez le fichier global.ini pour le modifier :

    > vi /hana/shared/SID/global/hdb/custom/config/global.ini

  2. Ajoutez les définitions suivantes au fichier global.ini :

    [ha_dr_provider_SAPHanaSR]
provider = SAPHanaSR
path = /usr/share/SAPHanaSR/
execution_order = 1

[ha_dr_provider_suschksrv]
provider = susChkSrv
path = /usr/share/SAPHanaSR/
execution_order = 3
action_on_lost = stop

[trace]
ha_dr_saphanasr = info

  3. En tant qu'utilisateur racine, créez un fichier de configuration personnalisé dans le répertoire /etc/sudoers.d en exécutant la commande suivante. Ce nouveau fichier de configuration permet à l'utilisateur SID_LCadm d'accéder aux attributs de nœud du cluster lorsque la méthode de hook srConnectionChanged() est appelée.

    > sudo visudo -f /etc/sudoers.d/SAPHanaSR

  4. Dans le fichier /etc/sudoers.d/SAPHanaSR, ajoutez le texte suivant :

    Remplacez les éléments suivants :

    • SITE_A : nom du site du serveur SAP HANA principal
    • SITE_B : nom du site du serveur SAP HANA secondaire
    • SID_LC : SID, spécifié à l'aide de lettres minuscules
    Pour afficher les noms des sites, vous pouvez exécuter la commande crm_mon -A1 | grep site en tant qu'utilisateur racine, sur le serveur principal SAP HANA ou sur le serveur secondaire. 
    Cmnd_Alias SOK_SITEA = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_A -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias SFAIL_SITEA = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_A -v SFAIL -t crm_config -s SAPHanaSR
Cmnd_Alias SOK_SITEB = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_B -v SOK -t crm_config -s SAPHanaSR
Cmnd_Alias SFAIL_SITEB = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_B -v SFAIL -t crm_config -s SAPHanaSR
SID_LCadm ALL=(ALL) NOPASSWD: SOK_SITEA, SFAIL_SITEA, SOK_SITEB, SFAIL_SITEB

  5. Dans votre fichier /etc/sudoers, assurez-vous que le texte suivant est inclus :

    • Pour SLES pour SAP 15 SP3 et versions ultérieures : 

      @includedir /etc/sudoers.d

    • Pour les versions jusqu'à SLES pour SAP 15 SP2 : 

      #includedir /etc/sudoers.d

      Notez que # dans ce texte fait partie de la syntaxe et ne signifie pas que la ligne est un commentaire.

  6. En tant que SID_LCadm, démarrez SAP HANA :

    > HDB start

  7. Une fois la configuration du cluster SAP HANA terminée, vous pouvez vérifier que le hook fonctionne correctement lors d'un test de basculement, comme décrit dans les sections Dépannage du hook Python SAPHanaSR et La reprise du cluster à haute disponibilité prend trop de temps en cas de défaillance du serveur d'index HANA.

Configurer la prise en charge du basculement Cloud Load Balancing

Le service d'équilibrage de charge réseau passthrough interne avec prise en charge du basculement achemine le trafic vers l'hôte actif dans un cluster SAP HANA en fonction d'un service de vérification de l'état.

Réserver une adresse IP pour l'adresse IP virtuelle

L'adresse IP virtuelle, parfois appelée adresse IP flottante, suit le système SAP HANA actif. L'équilibreur de charge achemine le trafic envoyé à l'adresse IP virtuelle vers la VM qui héberge actuellement le système SAP HANA actif.

  1. Ouvrez Cloud Shell.

    Accéder à Cloud Shell

  2. Réservez une adresse IP pour l'adresse IP virtuelle. Il s'agit de l'adresse IP utilisée par les applications pour accéder à SAP HANA. Si vous omettez l'option --addresses, une adresse IP du sous-réseau spécifié est choisie pour vous :

    $ gcloud compute addresses create VIP_NAME \
  --region CLUSTER_REGION --subnet CLUSTER_SUBNET \
  --addresses VIP_ADDRESS

    Pour en savoir plus sur la réservation d'une adresse IP statique, consultez la page Réserver une adresse IP interne statique.

  3. Confirmez la réservation d'adresse IP :

    $ gcloud compute addresses describe VIP_NAME \
  --region CLUSTER_REGION

    Un résultat semblable aux lignes suivantes doit s'afficher :

    address: 10.0.0.19
addressType: INTERNAL
creationTimestamp: '2020-05-20T14:19:03.109-07:00'
description: ''
id: '8961491304398200872'
kind: compute#address
name: vip-for-hana-ha
networkTier: PREMIUM
purpose: GCE_ENDPOINT
region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1
selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/addresses/vip-for-hana-ha
status: RESERVED
subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-subnet-us-central1

Créer des groupes d'instances pour vos VM hôtes

  1. Dans Cloud Shell, créez deux groupes d'instances non gérés, puis attribuez la VM hôte maître principale à l'un et la VM hôte maître secondaire à l'autre :

    $ gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \
  --zone=PRIMARY_ZONE
$ gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \
  --zone=PRIMARY_ZONE \
  --instances=PRIMARY_HOST_NAME
$ gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \
  --zone=SECONDARY_ZONE
$ gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \
  --zone=SECONDARY_ZONE \
  --instances=SECONDARY_HOST_NAME

  2. Confirmez la création des groupes d'instances :

    $ gcloud compute instance-groups unmanaged list

    Un résultat semblable aux lignes suivantes doit s'afficher :

    NAME          ZONE           NETWORK          NETWORK_PROJECT        MANAGED  INSTANCES
hana-ha-ig-1  us-central1-a  example-network  example-project-123456 No       1
hana-ha-ig-2  us-central1-c  example-network  example-project-123456 No       1

Créer une vérification de l'état Compute Engine

  1. Dans Cloud Shell, créez la vérification de l'état. Pour le port utilisé par la vérification de l'état, choisissez un port situé dans la plage privée (49152-65535) afin d'éviter tout conflit avec d'autres services. Les valeurs de l'intervalle entre deux tests et du délai avant expiration sont légèrement supérieures aux valeurs par défaut afin d'augmenter la tolérance au basculement lors des événements de migration à chaud de Compute Engine. Vous pouvez ajuster les valeurs, si nécessaire :

    $ gcloud compute health-checks create tcp HEALTH_CHECK_NAME --port=HEALTHCHECK_PORT_NUM \
  --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
  --healthy-threshold=2

  2. Confirmez la création de la vérification de l'état :

    $ gcloud compute health-checks describe HEALTH_CHECK_NAME

    Un résultat semblable aux lignes suivantes doit s'afficher :

    checkIntervalSec: 10
creationTimestamp: '2020-05-20T21:03:06.924-07:00'
healthyThreshold: 2
id: '4963070308818371477'
kind: compute#healthCheck
name: hana-health-check
selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/hana-health-check
tcpHealthCheck:
 port: 60000
 portSpecification: USE_FIXED_PORT
 proxyHeader: NONE
timeoutSec: 10
type: TCP
unhealthyThreshold: 2

Créer une règle de pare-feu pour les vérifications d'état

Définissez une règle de pare-feu pour un port situé dans la plage privée qui permet d'accéder à vos VM hôtes à partir des plages d'adresses IP utilisées par les vérifications d'état de Compute Engine, 35.191.0.0/16 et 130.211.0.0/22. Pour en savoir plus, consultez la section Créer des règles de pare-feu pour les vérifications d'état.

  1. Si ce n'est pas déjà fait, ajoutez un tag réseau à vos VM hôtes. Ce tag réseau est utilisé par la règle de pare-feu pour les vérifications d'état.

    $ gcloud compute instances add-tags PRIMARY_HOST_NAME \
  --tags NETWORK_TAGS \
  --zone PRIMARY_ZONE
$ gcloud compute instances add-tags SECONDARY_HOST_NAME \
  --tags NETWORK_TAGS \
  --zone SECONDARY_ZONE

  2. Si vous n'en avez pas encore, créez une règle de pare-feu pour autoriser les vérifications de l'état :

    $ gcloud compute firewall-rules create RULE_NAME \
  --network NETWORK_NAME \
  --action ALLOW \
  --direction INGRESS \
  --source-ranges 35.191.0.0/16,130.211.0.0/22 \
  --target-tags NETWORK_TAGS \
  --rules tcp:HLTH_CHK_PORT_NUM

    Exemple :

    gcloud compute firewall-rules create  fw-allow-health-checks \
--network example-network \
--action ALLOW \
--direction INGRESS \
--source-ranges 35.191.0.0/16,130.211.0.0/22 \
--target-tags cluster-ntwk-tag \
--rules tcp:60000

Configurer l'équilibreur de charge et le groupe de basculement

  1. Créez le service de backend de l'équilibreur de charge :

    $ gcloud compute backend-services create BACKEND_SERVICE_NAME \
  --load-balancing-scheme internal \
  --health-checks HEALTH_CHECK_NAME \
  --no-connection-drain-on-failover \
  --drop-traffic-if-unhealthy \
  --failover-ratio 1.0 \
  --region CLUSTER_REGION \
  --global-health-checks

  2. Ajoutez le groupe d'instances principal au service de backend :

    $ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --instance-group PRIMARY_IG_NAME \
  --instance-group-zone PRIMARY_ZONE \
  --region CLUSTER_REGION

  3. Ajoutez le groupe d'instances de basculement secondaire au service de backend :

    $ gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --instance-group SECONDARY_IG_NAME \
  --instance-group-zone SECONDARY_ZONE \
  --failover \
  --region CLUSTER_REGION

  4. Créez une règle de transfert. Pour l'adresse IP, spécifiez celle que vous avez réservée pour l'adresse IP virtuelle : Si vous devez accéder au système SAP HANA en dehors de la région spécifiée ci-dessous, incluez l'indicateur --allow-global-access dans la définition :

    $ gcloud compute forwarding-rules create RULE_NAME \
  --load-balancing-scheme internal \
  --address VIP_ADDRESS \
  --subnet CLUSTER_SUBNET \
  --region CLUSTER_REGION \
  --backend-service BACKEND_SERVICE_NAME \
  --ports ALL

    Pour en savoir plus sur l'accès interrégional à votre système SAP HANA à haute disponibilité, consultez la page Équilibrage de charge TCP/UDP interne.

Tester la configuration de l'équilibreur de charge

Même si vos groupes d'instances backend ne seront considérés comme opérationnels que plus tard, vous pouvez tester la configuration de l'équilibreur de charge en configurant un écouteur pour répondre aux vérifications d'état. Une fois un écouteur configuré, si l'équilibreur de charge est correctement configuré, les groupes d'instances backend deviennent opérationnels.

Les sections suivantes présentent différentes méthodes que vous pouvez utiliser pour tester la configuration.

Tester l'équilibreur de charge avec l'utilitaire socat

Vous pouvez vous servir de l'utilitaire socat pour écouter temporairement le port de vérification de l'état. Vous devez tout de même installer l'utilitaire socat, car vous l'utiliserez plus tard lors de la configuration des ressources du cluster.

  1. En tant qu'utilisateur racine, installez sur les deux VM hôtes l'utilitaire socat :

    # zypper install -y socat

  2. Démarrez un processus socat pour écouter le port de vérification de l'état pendant 60 secondes :

    # timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,fork

  3. Dans Cloud Shell, après avoir attendu quelques secondes pour que la vérification de l'état détecte l'écouteur, vérifiez l'état de vos groupes d'instances backend :

    $ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
  --region CLUSTER_REGION

    Le résultat doit être semblable à ceci :

    ---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
   ipAddress: 10.0.0.35
   port: 80
 kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2
   ipAddress: 10.0.0.34
   port: 80
 kind: compute#backendServiceGroupHealth

Tester l'équilibreur de charge à l'aide du port 22

Si le port 22 est ouvert pour les connexions SSH sur vos VM hôtes, vous pouvez modifier temporairement le vérificateur de l'état afin d'utiliser ce port, qui dispose d'un écouteur capable de lui répondre.

Pour utiliser temporairement le port 22, procédez comme suit :

  1. Cliquez sur votre vérification de l'état dans la console :

    Accéder à la page "Vérifications d'état"

  2. Cliquez sur Modifier.

  3. Dans le champ Port, remplacez le numéro de port par 22.

  4. Cliquez sur Enregistrer, puis patientez une minute ou deux.

  5. Dans Cloud Shell, vérifiez l'état de vos groupes d'instances backend :

    $ gcloud compute backend-services get-health BACKEND_SERVICE_NAME \
  --region CLUSTER_REGION

    Le résultat doit être semblable à ceci :

    ---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1
   ipAddress: 10.0.0.35
   port: 80
 kind: compute#backendServiceGroupHealth
---
backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2
status:
 healthStatus:
 ‐ healthState: HEALTHY
   instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2
   ipAddress: 10.0.0.34
   port: 80
 kind: compute#backendServiceGroupHealth

  6. Lorsque vous avez terminé, rétablissez le numéro de port d'origine de la vérification de l'état.

Configurer Pacemaker

La procédure suivante configure l'implémentation SUSE d'un cluster Pacemaker sur des VM Compute Engine pour SAP HANA.

Pour en savoir plus sur la configuration des clusters à haute disponibilité sur SLES, consultez la documentation de l'extension SUSE Linux Enterprise High Availability Extension correspondant à votre version de SLES.

Créer les fichiers de configuration Corosync

  1. Créez un fichier de configuration Corosync sur l'hôte principal :

    1. Créez le fichier suivant :

       vi /etc/corosync/corosync.conf

    2. Dans le fichier corosync.conf de l'hôte principal, ajoutez la configuration suivante en remplaçant le texte de variable en italique par vos valeurs :

      totem {
 version: 2
 secauth: off
 crypto_hash: sha1
 crypto_cipher: aes256
 cluster_name: hacluster
 clear_node_high_bit: yes
 token: 20000
 token_retransmits_before_loss_const: 10
 join: 60
 max_messages:  20
 transport: udpu
 interface {
   ringnumber: 0
   Bindnetaddr: static-ip-of-hdb-on-this-host
   mcastport: 5405
   ttl: 1
 }
}
logging {
 fileline:  off
 to_stderr: no
 to_logfile: no
 logfile: /var/log/cluster/corosync.log
 to_syslog: yes
 debug: off
 timestamp: on
 logger_subsys {
   subsys: QUORUM
   debug: off
 }
}
nodelist {
 node {
   ring0_addr: this-host-name
   nodeid: 1
 }
 node {
   ring0_addr: other-host-name
   nodeid: 2
 }
}
quorum {
 provider: corosync_votequorum
 expected_votes: 2
 two_node: 1
}

  2. Créez un fichier de configuration Corosync sur l'hôte secondaire en répétant les étapes que vous avez utilisées pour l'hôte principal. À l'exception de l'adresse IP statique du HDB sur la propriété Bindnetaddr et de l'ordre des noms d'hôte dans nodelist, les valeurs de propriété du fichier de configuration sont identiques pour chaque hôte.

Initialiser le cluster

  1. Sur l'hôte principal, en mode root :

    1. Effectuer le changement de mot de passe pour l'utilisateur hacluster :

      # passwd hacluster

    2. Initialisez le cluster :

      # corosync-keygen
# crm cluster init --yes ssh
# crm cluster init -y csync2

    3. Démarrez Pacemaker sur l'hôte principal :

      # systemctl enable pacemaker
# systemctl start pacemaker

  2. Sur l'hôte secondaire, en mode root :

    1. Effectuer le changement de mot de passe pour l'utilisateur hacluster :

      # passwd hacluster

    2. Associez l'hôte secondaire au cluster initialisé sur l'hôte principal :

      # crm cluster join --yes ssh
# crm cluster join -y -c primary-host-name csync2

    3. Démarrez Pacemaker sur l'hôte secondaire :

      # systemctl enable pacemaker
# systemctl start pacemaker

  3. Sur l'un de ces hôtes, en mode root, vérifiez que le cluster affiche les deux nœuds :

    # crm_mon -s

    Un résultat semblable à la ligne suivante doit s'afficher :

    CLUSTER OK: 2 nodes online, 0 resources configured

Configurer le cluster

Pour configurer le cluster, vous devez définir les propriétés générales du cluster et ses ressources primitives.

Activer le mode de maintenance

  1. Sur l'un des hôtes, en mode root, passez le cluster en mode de maintenance :

    # crm configure property maintenance-mode="true"

Configurer les propriétés générales du cluster

  1. Sur l'hôte principal :

    1. Définissez les propriétés générales du cluster :

      # crm configure property stonith-timeout="300s"
# crm configure property stonith-enabled="true"
# crm configure rsc_defaults resource-stickiness="1000"
# crm configure rsc_defaults migration-threshold="5000"
# crm configure op_defaults timeout="600"

Configurer le cloisonnement

Pour configurer le cloisonnement, vous devez définir une ressource de cluster avec un agent de cloisonnement pour chaque VM hôte.

Pour garantir la séquence correcte d'événements après une action de cloisonnement, vous devez également configurer le système d'exploitation pour retarder le redémarrage de Corosync après la fermeture d'une VM. Vous pouvez également ajuster le délai avant expiration de Pacemaker pour les redémarrages afin de tenir compte de ce délai.

Créer les ressources de l'appareil de cloisonnement

  1. Sur l'hôte principal, en tant qu'utilisateur racine, créez les ressources de cloisonnement :

    # crm configure primitive STONITH-"primary-host-name" stonith:fence_gce \
    op monitor interval="300s" timeout="120s" \
    op start interval="0" timeout="60s" \
    params port="primary-host-name" zone="primary-zone" project="project_id" \
    pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30
     
    # crm configure primitive STONITH-"secondary-host-name" stonith:fence_gce \
    op monitor interval="300s" timeout="120s" \
    op start interval="0" timeout="60s" \
    params port="secondary-host-name" zone="secondary-zone" project="project_id" \
    pcmk_reboot_timeout=300 pcmk_monitor_retries=4

  2. Définissez l'emplacement de chaque appareil de cloisonnement :

    # crm configure location LOC_STONITH_"primary-host-name" \
    STONITH-"primary-host-name" -inf: "primary-host-name"
     
    # crm configure location LOC_STONITH_"secondary-host-name" \
    STONITH-"secondary-host-name" -inf: "secondary-host-name"

Définir un délai pour le redémarrage de Corosync

  1. Sur les deux hôtes, en tant qu'utilisateur racine, créez un fichier de dépôt systemd qui retarde le démarrage de Corosync pour garantir le bon déroulement de la séquence d'événements après le redémarrage d'une VM cloisonnée :

    systemctl edit corosync.service

  2. Ajoutez les lignes suivantes au fichier :

    [Service]
ExecStartPre=/bin/sleep 60

  3. Enregistrez le fichier et quittez l'éditeur.

  4. Rechargez la configuration du gestionnaire systemd.

    systemctl daemon-reload

  5. Vérifiez que le fichier de dépôt a été créé :

    service corosync status

    Une ligne correspondant au fichier de dépôt doit s'afficher, comme illustré dans l'exemple suivant :

    ● corosync.service - Corosync Cluster Engine
   Loaded: loaded (/usr/lib/systemd/system/corosync.service; disabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/corosync.service.d
           └─override.conf
   Active: active (running) since Tue 2021-07-20 23:45:52 UTC; 2 days ago

Créer une ressource IP de cluster local pour l'adresse IP virtuelle

Pour configurer l'adresse IP virtuelle dans le système d'exploitation, créez une ressource IP de cluster locale pour l'adresse IP virtuelle que vous avez réservée précédemment :

# crm configure primitive rsc_vip_int-primary IPaddr2 \
     params ip=vip-address cidr_netmask=32 nic="eth0" op monitor interval=3600s timeout=60s

Configurer le service d'aide de vérification de l'état

L'équilibreur de charge utilise un écouteur sur le port de vérification de l'état de chaque hôte afin de déterminer où l'instance principale du cluster SAP HANA est exécutée.

Pour gérer les écouteurs dans le cluster, vous devez créer une ressource pour l'écouteur.

Ces instructions utilisent l'utilitaire socat comme écouteur.

  1. Sur les deux hôtes en mode root, installez socat utility :

    # zypper in -y socat

  2. Sur l'hôte principal :

    1. Créez une ressource pour le service de vérification d'état de l'outil d'aide :

      # crm configure primitive rsc_healthcheck-primary anything \
    params binfile="/usr/bin/socat" \
    cmdline_options="-U TCP-LISTEN:healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null" \
    op monitor timeout=20s interval=10s \
    op_params depth=0

Regrouper les ressources de l'adresse IP virtuelle et du service de vérification d'état de l'outil d'aide

Regroupez les ressources de l'adresse IP virtuelle et du service de vérification d'état de l'outil d'aide :

# crm configure group g-primary rsc_vip_int-primary rsc_healthcheck-primary

Créer la ressource primitive SAPHanaTopology

Vous définissez la ressource primitive SAPHanaTopology dans un fichier de configuration temporaire, que vous importez ensuite dans Corosync.

Sur l'hôte principal, en mode root :

  1. Créez un fichier de configuration temporaire pour les paramètres de configuration SAPHanaTopology :

    # vi /tmp/cluster.tmp

  2. Effectuez un copier/coller des définitions de ressources SAPHanaTopology dans le fichier /tmp/cluster.tmp :

    primitive rsc_SAPHanaTopology_SID_HDBinst_num ocf:suse:SAPHanaTopology \
 operations \$id="rsc_sap2_SID_HDBinst_num-operations" \
 op monitor interval="10" timeout="600" \
 op start interval="0" timeout="600" \
 op stop interval="0" timeout="300" \
 params SID="SID" InstanceNumber="inst_num"

clone cln_SAPHanaTopology_SID_HDBinst_num rsc_SAPHanaTopology_SID_HDBinst_num \
 meta clone-node-max="1" target-role="Started" interleave="true"

  3. Modifiez le fichier /tmp/cluster.tmp pour remplacer les variables par le SID et le numéro d'instance de votre système SAP HANA.

  4. Sur l'hôte principal, en mode root, chargez le contenu du fichier /tmp/cluster.tmp dans Corosync :

    crm configure load update /tmp/cluster.tmp

Créer la ressource primitive SAPHana

Vous définissez la ressource primitive SAPHana à l'aide de la même méthode que celle utilisée pour la ressource SAPHanaTopology, à savoir un fichier de configuration temporaire, que vous importez ensuite dans Corosync.

  1. Remplacez le fichier de configuration temporaire :

    # rm /tmp/cluster.tmp
# vi /tmp/cluster.tmp

  2. Effectuez un copier/coller des définitions de ressources SAPHana dans le fichier /tmp/cluster.tmp :

    primitive rsc_SAPHana_SID_HDBinst_num ocf:suse:SAPHana \
 operations \$id="rsc_sap_SID_HDBinst_num-operations" \
 op start interval="0" timeout="3600" \
 op stop interval="0" timeout="3600" \
 op promote interval="0" timeout="3600" \
 op demote interval="0" timeout="3600" \
 op monitor interval="60" role="Master" timeout="700" \
 op monitor interval="61" role="Slave" timeout="700" \
 params SID="SID" InstanceNumber="inst_num" PREFER_SITE_TAKEOVER="true" \
 DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="true"

ms msl_SAPHana_SID_HDBinst_num rsc_SAPHana_SID_HDBinst_num \
 meta notify="true" clone-max="2" clone-node-max="1" \
 target-role="Started" interleave="true"

colocation col_saphana_ip_SID_HDBinst_num 4000: g-primary:Started \
 msl_SAPHana_SID_HDBinst_num:Master
order ord_SAPHana_SID_HDBinst_num Optional: cln_SAPHanaTopology_SID_HDBinst_num \
 msl_SAPHana_SID_HDBinst_num

    Pour un cluster HA SAP HANA à niveaux multiples, si vous utilisez une version antérieure à SAP HANA 2.0 SP03, définissez AUTOMATED_REGISTER sur false. Cela permet d'empêcher une instance récupérée d'essayer de s'enregistrer automatiquement pour la réplication vers un système HANA sur lequel une cible de réplication est déjà configurée. Pour SAP HANA 2.0 SP03 ou pour les versions ultérieures, vous pouvez définir AUTOMATED_REGISTER sur true pour les configurations SAP HANA qui utilisent la réplication système à plusieurs niveaux. Pour en savoir plus, consultez les pages suivantes :

  3. Sur l'hôte principal, en mode root, chargez le contenu du fichier /tmp/cluster.tmp dans Corosync :

    crm configure load update /tmp/cluster.tmp

Vérifier que la réplication du système SAP HANA est active

  1. Sur l'hôte principal, en tant que SID_LCadm, connectez-vous au terminal interactif de la base de données SAP HANA :

    > hdbsql -u system -p "system-password" -i inst_num

  2. Dans le terminal interactif, vérifiez l'état de la réplication :

    => select distinct REPLICATION_STATUS from SYS.M_SERVICE_REPLICATION

    L'état REPLICATION_STATUS doit être défini sur "ACTIVE".

Vous pouvez également vérifier l'état de la réplication en exécutant le script Python suivant en tant que SID_LCadm :

# python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py

Activer le cluster

  1. Sur l'hôte principal, en mode root, désactivez le mode de maintenance pour le cluster :

    # crm configure property maintenance-mode="false"

    Si vous êtes invité à supprimer "maintenance", saisissez y.

  2. Patientez 15 secondes, puis vérifiez l'état du cluster sur l'hôte principal en mode root :

    # crm status

    Les exemples suivants montrent l'état d'un cluster actif et correctement configuré :

    Stack: corosync
Current DC: hana-ha-vm-1 (version 2.0.1+20190417.13d370ca9-3.9.1-2.0.1+20190417.13d370ca9) - partition with quorum
Last updated: Sun Jun  7 00:36:56 2020
Last change: Sun Jun  7 00:36:53 2020 by root via crm_attribute on hana-ha-vm-1

2 nodes configured
8 resources configured

Online: [ hana-ha-vm-1 hana-ha-vm-2 ]

Full list of resources:

STONITH-hana-ha-vm-1   (stonith:fence_gce):  Started hana-ha-vm-2
STONITH-hana-ha-vm-2   (stonith:fence_gce):  Started hana-ha-vm-1
Clone Set: cln_SAPHanaTopology_HA1_HDB22 [rsc_SAPHanaTopology_HA1_HDB22]
    Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
Resource Group: g-primary
    rsc_vip_int-primary        (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-1
    rsc_healthcheck-primary        (ocf::heartbeat:anything):      Started hana-ha-vm-1
Clone Set: msl_SAPHana_HA1_HDB22 [rsc_SAPHana_HA1_HDB22] (promotable)
    Masters: [ hana-ha-vm-1 ]
    Slaves: [ hana-ha-vm-2 ]

Tester le basculement

Testez votre cluster en simulant une défaillance sur l'hôte principal. Utilisez un système de test ou exécutez le test sur votre système de production avant de mettre le système en service.

Sauvegardez le système avant le test.

Vous pouvez simuler une défaillance de différentes manières, par exemple :

  • HDB stop
  • HDB kill
  • reboot (sur le nœud actif)
  • ip link set eth0 down pour les instances avec une seule interface réseau
  • iptables ... DROP pour les instances avec plusieurs interfaces réseau
  • echo c > /proc/sysrq-trigger

Ces instructions utilisent ip link set eth0 down ou iptables pour simuler une interruption du réseau entre vos deux hôtes du cluster. Exécutez la commande ip link sur une instance dotée d'une seule interface réseau, et la commande iptables sur les instances possédant une ou plusieurs interfaces réseau. Le test valide le basculement et le cloisonnement. Si plusieurs interfaces réseau sont définies sur vos instances, utilisez la commande iptables sur l'hôte secondaire pour abandonner le trafic entrant et sortant en fonction de l'adresse IP utilisée par l'hôte principal pour la communication des clusters, ce qui simule ainsi une perte de connexion réseau à l'instance principale.

  1. Sur l'hôte actif, en tant qu'utilisateur racine, déconnectez l'interface réseau :

    # ip link set eth0 down

    Ou, si plusieurs interfaces réseau sont actives, à l'aide de iptables sur l'hôte secondaire :

    # iptables -A INPUT -s PRIMARY_CLUSTER_IP -j DROP; iptables -A OUTPUT -d PRIMARY_CLUSTER_IP -j DROP

  2. Reconnectez-vous à l'un des hôtes à l'aide de SSH, puis connectez-vous en tant qu'utilisateur racine.

  3. Saisissez crm status pour vérifier que l'hôte principal est désormais actif sur la VM qui contenait l'hôte secondaire. Le redémarrage automatique est activé dans le cluster. Par conséquent, l'hôte arrêté redémarre et prend le rôle d'hôte secondaire, comme illustré dans l'exemple suivant.

    Stack: corosync
Current DC: hana-ha-vm-2 (version 2.0.1+20190417.13d370ca9-3.9.1-2.0.1+20190417.13d370ca9) - partition with quorum
Last updated: Fri Jun 12 16:46:07 2020
Last change: Fri Jun 12 16:46:07 2020 by root via crm_attribute on hana-ha-vm-2

2 nodes configured
8 resources configured

Online: [ hana-ha-vm-1 hana-ha-vm-2 ]

Full list of resources:

STONITH-hana-ha-vm-1   (stonith:fence_gce):  Started hana-ha-vm-2
STONITH-hana-ha-vm-2   (stonith:fence_gce):  Started hana-ha-vm-1

Clone Set: cln_SAPHanaTopology_HA1_HDB22 [rsc_SAPHanaTopology_HA1_HDB22]
    Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
Resource Group: g-primary
    rsc_vip_int-primary        (ocf::heartbeat:IPaddr2):       Started hana-ha-vm-2
    rsc_healthcheck-primary        (ocf::heartbeat:anything):      Started hana-ha-vm-2
Clone Set: msl_SAPHana_HA1_HDB22 [rsc_SAPHana_HA1_HDB22] (promotable)
    Masters: [ hana-ha-vm-2 ]
    Slaves: [ hana-ha-vm-1 ]

Configurer HANA actif/actif (lecture activée)

À partir de SAP HANA 2.0 SPS1, vous pouvez configurer HANA actif/actif (lecture activée) dans un cluster Pacemaker. Cette opération est facultative.

Pour configurer HANA actif/actif (lecture activée) dans un cluster Pacemaker, procédez comme suit :

Configurer la prise en charge du basculement Cloud Load Balancing pour l'hôte secondaire

Le service d'équilibrage de charge réseau passthrough interne avec prise en charge du basculement achemine le trafic vers l'hôte secondaire dans un cluster SAP HANA en fonction d'un service de vérification de l'état.

Pour configurer la prise en charge du basculement de l'hôte secondaire, procédez comme suit :

  1. Ouvrez Cloud Shell.

    Accéder à Cloud Shell

  2. Réservez une adresse IP pour l'adresse IP virtuelle en exécutant la commande suivante.

    L'adresse IP virtuelle (VIP) suit le système SAP HANA secondaire. Il s'agit de l'adresse IP utilisée par les applications pour accéder à votre système SAP HANA secondaire. L'équilibreur de charge achemine le trafic envoyé à l'adresse IP virtuelle vers l'instance de VM qui héberge actuellement le système secondaire.

    Si vous omettez l'option --addresses dans la commande suivante, une adresse IP du sous-réseau spécifié est choisie pour vous. Pour en savoir plus sur la réservation d'une adresse IP statique, consultez la page Réserver une adresse IP interne statique.

    $ gcloud compute addresses create secondary-vip-name \
  --region cluster-region --subnet cluster-subnet \
  --addresses secondary-vip-address

  3. Créez une vérification d'état Compute Engine en exécutant la commande suivante.

    Pour le port utilisé par la vérification d'état, choisissez un port situé dans la plage privée (49152-65535) afin d'éviter tout conflit avec d'autres services. Le port doit être différent de celui configuré pour la vérification d'état utilisée pour l'accès au système principal HANA. Les valeurs de l'intervalle entre deux tests et du délai avant expiration sont légèrement supérieures aux valeurs par défaut afin d'augmenter la tolérance au basculement lors des événements de migration à chaud de Compute Engine. Vous pouvez ajuster les valeurs si nécessaire.

    $ gcloud compute health-checks create tcp secondary-health-check-name \
  --port=secondary-healthcheck-port-num \
  --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \
  --healthy-threshold=2

  4. Configurez l'équilibreur de charge et le groupe de basculement en exécutant les commandes suivantes.

    Ici, vous créez un service de backend supplémentaire et utilisez les mêmes groupes d'instances que ceux créés précédemment pour le service de backend derrière l'équilibreur de charge TCP/UDP interne de votre système principal SAP HANA.

    1. Créez le service de backend de l'équilibreur de charge :

      $ gcloud compute backend-services create secondary-backend-service-name \
  --load-balancing-scheme internal \
  --health-checks secondary-health-check-name \
  --no-connection-drain-on-failover \
  --drop-traffic-if-unhealthy \
  --failover-ratio 1.0 \
  --region cluster-region \
  --global-health-checks

    2. Ajoutez le groupe d'instances principal au service de backend :

      $ gcloud compute backend-services add-backend secondary-backend-service-name \
  --instance-group primary-ig-name \
  --instance-group-zone primary-zone \
  --region cluster-region

    3. Ajoutez le groupe d'instances de basculement secondaire au service de backend :

      $ gcloud compute backend-services add-backend secondary-backend-service-name \
  --instance-group secondary-ig-name \
  --instance-group-zone secondary-zone \
  --failover \
  --region cluster-region

    4. Créez une règle de transfert.

      Pour l'option d'adresse IP, spécifiez celle que vous avez réservée pour l'adresse IP virtuelle. Si vous devez accéder au système secondaire HANA en dehors de la région spécifiée dans la commande suivante, incluez l'option --allow-global-access dans la définition de la règle de transfert.

      $ gcloud compute forwarding-rules create secondary-rule-name \
  --load-balancing-scheme internal \
  --address secondary-vip-name \
  --subnet cluster-subnet \
  --region cluster-region \
  --backend-service secondary-backend-service-name \
  --ports ALL

      Pour en savoir plus sur l'accès interrégional à votre système SAP HANA à haute disponibilité, consultez la page Équilibrage de charge TCP/UDP interne.

Activer HANA actif/actif (lecture activée)

Sur votre hôte secondaire, activez le mode actif/actif (lecture activée) pour la réplication du système SAP HANA en procédant comme suit :

  1. En tant qu'utilisateur racine, placez le cluster en mode de maintenance :

    # crm configure property maintenance-mode="true"

  2. En tant que SID_LCadm, arrêtez SAP HANA :

    > HDB stop

  3. En tant que SID_LCadm, réenregistrez le système secondaire HANA avec la réplication du système SAP HANA à l'aide du mode d'opération logreplay_readaccess :

    > hdbnsutil -sr_register --remoteHost=primary-host-name --remoteInstance=inst_num \
 --replicationMode=syncmem --operationMode=logreplay_readaccess --name=secondary-host-name

  4. En tant que SID_LCadm, démarrez SAP HANA :

    > HDB start

  5. En tant que SID_LCadm, confirmez que l'état de la synchronisation HANA est bien ACTIVE :

    > cdpy; python systemReplicationStatus.py --sapcontrol=1 | grep overall_replication_status

    Un résultat semblable à l'exemple suivant doit s'afficher :

    overall_replication_status=ACTIVE

Configurer Pacemaker

Configurez votre cluster à haute disponibilité Pacemaker en mode actif/actif (lecture activée) en exécutant les commandes suivantes en tant qu'utilisateur racine :

  1. Créez une ressource IP de cluster locale pour l'adresse IP virtuelle que vous avez réservée pour le système secondaire :

    # crm configure primitive rsc_vip_int-secondary IPaddr2 \
  params ip=secondary-vip-address cidr_netmask=32 nic="eth0" \
  op monitor interval=3600s timeout=60s

  2. Configurez le service de vérification d'état de l'outil d'aide en exécutant les commandes suivantes :

    L'équilibreur de charge utilise un écouteur sur le port de vérification de l'état de chaque hôte afin de déterminer où l'instance secondaire du cluster SAP HANA est exécutée.

    1. Pour gérer les écouteurs dans le cluster, vous devez créer une ressource pour l'écouteur. Ces instructions utilisent l'utilitaire socat comme écouteur. Créez une ressource pour le service de vérification d'état de l'outil d'aide :

      # crm configure primitive rsc_healthcheck-secondary anything \
 params binfile="/usr/bin/socat" \
 cmdline_options="-U TCP-LISTEN:secondary-healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null" \
 op monitor timeout=20s interval=10s \
 op_params depth=0

    2. Regroupez les ressources de l'adresse IP virtuelle et du service de vérification d'état de l'outil d'aide :

      # crm configure group g-secondary rsc_vip_int-secondary rsc_healthcheck-secondary

  3. Créez une contrainte de colocation :

    # crm configure colocation col_saphana_secondary 4000: g-secondary:Started \
  msl_SAPHana_SID_HDBinst_num:Slave

  4. Quittez le mode de maintenance du cluster :

    # crm configure property maintenance-mode="false"

  5. Vérifiez l'état du cluster :

    # crm status

    Les exemples suivants montrent l'état d'un cluster actif et correctement configuré pour la réplication du système SAP HANA en mode actif/actif (lecture activée). Un groupe de ressources supplémentaire doit s'afficher pour les ressources VIP du système secondaire. Dans l'exemple suivant, le nom de ce groupe de ressources est g-secondary.

    Cluster Summary:
  Stack: corosync
  Current DC: hana-ha-vm-1 (version 2.0.4+20200616.2deceaa3a-3.15.1-2.0.4+20200616.2deceaa3a) - partition with quorum
  Last updated: Fri Oct  7 21:52:46 2022
  Last change:  Fri Oct  7 21:51:42 2022 by root via crm_attribute on hana-ha-vm-1

  2 nodes configured
  10 resource instances configured

Node List:
  Online: [ hana-ha-vm-1 hana-ha-vm-2 ]

Active Resources:
  STONITH-hana-ha-vm-1  (stonith:fence_gce):   Started hana-ha-vm-2
  STONITH-hana-ha-vm-2  (stonith:fence_gce):   Started hana-ha-vm-1
  Resource Group: g-primary:
    rsc_vip_int-primary       (ocf::heartbeat:IPaddr2):        Started hana-ha-vm-1
    rsc_vip_hc-primary        (ocf::heartbeat:anything):       Started hana-ha-vm-1
  Clone Set: cln_SAPHanaTopology_HA1_HDB00 [rsc_SAPHanaTopology_HA1_HDB00]:
    Started: [ hana-ha-vm-1 hana-ha-vm-2 ]
  Clone Set: msl_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00] (promotable):
    Masters: [ hana-ha-vm-1 ]
    Slaves: [ hana-ha-vm-2 ]
  Resource Group: g-secondary:
    rsc_vip_int-secondary       (ocf::heartbeat:IPaddr2):        Started hana-ha-vm-2
    rsc_healthcheck-secondary   (ocf::heartbeat:anything):       Started hana-ha-vm-2

Évaluer votre charge de travail SAP HANA

Pour automatiser les vérifications de validation continues pour vos charges de travail à haute disponibilité SAP HANA exécutées sur Google Cloud, vous pouvez utiliser le gestionnaire de charges de travail.

Le gestionnaire de charges de travail vous permet d'analyser et d'évaluer automatiquement vos charges de travail SAP HANA à haute disponibilité par rapport aux bonnes pratiques des fournisseurs SAP, de Google Cloud et de système d'exploitation. Cela permet d'améliorer la qualité, les performances et la fiabilité de vos charges de travail.

Pour en savoir plus sur les bonnes pratiques compatibles avec le gestionnaire de charges de travail pour évaluer les charges de travail SAP HANA à haute disponibilité exécutées sur Google Cloud, consultez la page Bonnes pratiques pour le gestionnaire de charges de travail SAP. Pour en savoir plus sur la création et l'exécution d'une évaluation à l'aide du gestionnaire de charges de travail, consultez la page Créer et exécuter une évaluation.

Dépannage

Pour résoudre les problèmes liés aux configurations à haute disponibilité pour SAP HANA sur SLES, consultez la section Dépannage des configurations à haute disponibilité pour SAP.

Obtenir de l'aide concernant SAP HANA sur SLES

Si vous avez besoin d'aide pour résoudre un problème lié à des clusters à haute disponibilité pour SAP HANA sur SLES, rassemblez les informations de diagnostic requises et contactez Cloud Customer Care. Pour en savoir plus, consultez la page Informations de diagnostic sur les clusters à haute disponibilité SLES.

Assistance

Pour les problèmes liés à l'infrastructure ou aux services Google Cloud, contactez l'assistance Customer Care. Ses coordonnées sont disponibles sur la page de présentation de l'assistance dans la console Google Cloud. Si l'assistance Customer Care détecte un problème dans vos systèmes SAP, vous serez redirigé vers l'assistance SAP.

Pour les problèmes liés au produit SAP, entrez votre demande d'assistance avec l'outil de l'assistance SAP. SAP évalue la demande d'assistance puis, s'il semble s'agir d'un problème d'infrastructure Google Cloud, la transfère au composant Google Cloud approprié dans son système : BC-OP-LNX-GOOGLE ou BC-OP-NT-GOOGLE.

Exigences liées à l'assistance

Pour bénéficier d'une assistance pour les systèmes SAP ainsi que pour l'infrastructure et les services Google Cloud que ces systèmes utilisent, vous devez satisfaire aux exigences minimales de la formule d'assistance.

Pour en savoir plus sur les exigences minimales concernant l'assistance pour SAP sur Google Cloud, consultez les ressources suivantes :

Se connecter à SAP HANA

Si les VM hôtes ne disposent pas d'adresse IP externe pour SAP HANA, vous ne pouvez vous connecter aux instances SAP HANA que via l'instance bastion à l'aide de SSH ou via le serveur Windows à l'aide de SAP HANA Studio.

  • Pour vous connecter à SAP HANA via l'instance bastion, connectez-vous à l'hôte bastion, puis aux instances SAP HANA à l'aide du client SSH de votre choix.

  • Pour vous connecter à la base de données SAP HANA via SAP HANA Studio, utilisez un client Bureau à distance pour vous connecter à l'instance Windows Server. Une fois la connexion établie, installez SAP HANA Studio manuellement, puis accédez à votre base de données SAP HANA.

Tâches post-déploiement

Une fois le déploiement terminé, procédez comme suit :

  1. Modifiez les mots de passe temporaires de l'administrateur système et du super-utilisateur du système SAP HANA. Exemple :

    sudo passwd SID_LCadm

    Pour en savoir plus sur la modification du mot de passe, consultez la section Réinitialiser le mot de passe utilisateur SYSTEM du système de base de données.

  2. Avant d'utiliser votre instance SAP HANA, configurez et sauvegardez votre nouvelle base de données SAP HANA.

  3. Si votre système SAP HANA est déployé sur une interface réseau VirtIO, nous vous recommandons de vous assurer que la valeur du paramètre TCP /proc/sys/net/ipv4/tcp_limit_output_bytes est définie sur 1048576. Cette modification permet d'améliorer le débit réseau global sur l'interface réseau VirtIO sans affecter la latence du réseau.

Pour en savoir plus, consultez les pages suivantes :

Étapes suivantes

Obtenez davantage d'informations en consultant les ressources suivantes :

  • Réplication automatique du système SAP HANA avec scaling à la hausse dans un cluster Pacemaker
  • Guide de planification de haute disponibilité SAP HANA
  • Guide de planification de reprise après sinistre SAP HANA
  • Pour en savoir plus sur l'administration et la surveillance des VM, consultez le guide d'utilisation de SAP HANA.