Déployer un système Scale-out SAP HANA avec le nœud de secours sur des machines virtuelles Azure à l’aide d’Azure NetApp Files sur Red Hat Enterprise Linux

Cet article explique comment déployer un système SAP HANA à haut niveau de disponibilité dans une configuration Scale-out avec nœud de secours sur des machines virtuelles Azure Red Hat Enterprise Linux en utilisant Azure NetApp Files pour les volumes de stockage partagés.

Dans les exemples de configuration, de commandes d’installation, etc., l’instance HANA est 03 et l’ID de système HANA est HN1. Les exemples sont basés sur HANA 2.0 SP4 et Red Hat Enterprise Linux pour SAP 7.6.

Remarque

Cet article contient des références aux termes que Microsoft n’utilise plus. Lorsque ces termes seront supprimés du logiciel, nous les supprimerons de cet article.

Avant de commencer, reportez-vous aux notes et documents SAP suivants :

Vue d’ensemble

L’une des méthodes permettant d’obtenir une haute disponibilité HANA consiste à configurer le basculement automatique de l’hôte. Pour configurer le basculement automatique de l’hôte, vous devez ajouter une ou plusieurs machines virtuelles au système HANA et les configurer en tant que nœuds de secours. En cas de défaillance d’un nœud actif, un nœud de secours prend automatiquement le relais. Dans la configuration présentée avec les machines virtuelles Azure, vous obtenez un basculement automatique à l’aide de NFS sur Azure NetApp Files.

Notes

Le nœud de secours a besoin d’accéder à tous les volumes de base de données. Les volumes HANA doivent être montés en tant que volumes NFSv4. Le mécanisme amélioré de verrouillage basé sur les baux de fichiers dans le protocole NFSv4 est utilisé pour la délimitation I/O.

Important

Pour générer la configuration prise en charge, vous devez déployer les volumes de données et de journaux HANA en tant que volumes NFSv4.1 et les monter à l’aide du protocole NFSv4.1. La configuration du basculement automatique de l’hôte HANA avec le nœud de secours n’est pas prise en charge avec NFSv3.

SAP NetWeaver High Availability overview

Dans le diagramme ci-dessus, qui suit les recommandations de réseau SAP HANA, trois sous-réseaux sont représentés au sein d’un réseau virtuel Azure :

  • Pour la communication client
  • Pour la communication avec le système de stockage
  • Pour la communication interne HANA entre les nœuds

Les volumes Azure NetApp se trouvent dans un sous-réseau distinct, délégué à Azure NetApp Files.

Pour cet exemple de configuration, les sous-réseaux sont les suivants :

  • client 10.9.1.0/26
  • storage 10.9.3.0/26
  • hana 10.9.2.0/26
  • anf 10.9.0.0/26 (sous-réseau délégué à Azure NetApp Files)

Configurer l’infrastructure Azure NetApp Files

Avant de poursuivre la configuration de l’infrastructure Azure NetApp Files, familiarisez-vous avec la documentation Azure NetApp Files.

Azure NetApp Files est disponible dans plusieurs régions Azure. Vérifiez si la région Azure que vous avez sélectionnée est compatible avec Azure NetApp Files.

Pour plus d’informations sur la disponibilité d’Azure NetApp Files par région Azure, consultez Disponibilité d’Azure NetApp Files par région Azure.

Considérations importantes

Au fur et à mesure que vous créez vos volumes Azure NetApp Files pour le scale-out SAP HANA avec un scénario de nœuds, tenez compte des considérations importantes documentées dans les volumes NFS v4.1 sur Azure NetApp Files pour SAP HANA.

Dimensionnement de la base de données HANA sur Azure NetApp Files

Le débit d’un volume NetApp Azure Files est une fonction de la taille de volume et du niveau de service, comme décrit dans Niveau de service pour Azure NetApp Files.

Lors de la conception de l’infrastructure pour SAP HANA sur Azure avec Azure NetApp Files, tenez compte des recommandations contenues dans les volumes NFS v4.1 sur Azure NetApp Files pour SAP HANA.
La configuration de cet article est présentée avec des volumes Azure NetApp Files simples.

Important

Pour les systèmes de production, pour lesquels les performances sont essentielles, nous vous recommandons d’évaluer et d’envisager d’utiliser le groupe de volumes d’applications Azure NetApp Files pour SAP HANA.

Déployer des ressources Azure NetApp Files

Les instructions suivantes supposent que vous avez déjà déployé votre réseau virtuel Azure. Les ressources Azure NetApp Files et les machines virtuelles, où les ressources Azure NetApp Files seront montées, doivent être déployées dans le même réseau virtuel Azure ou dans des réseaux virtuels Azure appairés.

  1. Créez un compte NetApp dans la région Azure sélectionnée en suivant les instructions de la page Création d’un compte NetApp.

  2. Configurez un pool de capacité Azure NetApp Files en suivant les instructions de la page Configuration d’un pool de capacité Azure NetApp Files.

    L’architecture HANA présentée dans cet article utilise un seul pool de capacité Azure NetApp Files au niveau de service Ultra. Pour les charges de travail HANA sur Azure, nous vous recommandons d’utiliser un niveau de serviceUltra ou Premium d’Azure NetApp Files.

  3. Déléguez un sous-réseau à Azure NetApp Files, comme décrit dans les instructions de la page Déléguer un sous-réseau à Azure NetApp Files.

  4. Déployez des volumes Azure NetApp Files en suivant les instructions de la page Créer un volume NFS pour Azure NetApp Files.

    Lors du déploiement des volumes, veillez à sélectionner la version NFSv4.1, . Déployez les volumes dans le sous-réseau Azure NetApp Files désigné. Les adresses IP des volumes Azure NetApp sont attribuées automatiquement.

    Gardez à l’esprit que les ressources Azure NetApp Files et les machines virtuelles Azure doivent être dans le même réseau virtuel Azure ou dans des réseaux virtuels Azure appairés. Par exemple, HN1-data-mnt00001, HN1-log-mnt00001 et ainsi de suite sont les noms de volume et nfs://10.9.0.4/HN1-data-mnt00001, nfs://10.9.0.4/HN1-log-mnt00001 et ainsi de suite sont les chemin d’accès de fichiers pour les volumes Azure NetApp Files.

    • volume HN1-data-mnt00001 (nfs://10.9.0.4/HN1-data-mnt00001)
    • volume HN1-data-mnt00002 (nfs://10.9.0.4/HN1-data-mnt00002)
    • volume HN1-log-mnt00001 (nfs://10.9.0.4/HN1-log-mnt00001)
    • volume HN1-log-mnt00002 (nfs://10.9.0.4/HN1-log-mnt00002)
    • volume HN1-shared (nfs://10.9.0.4/HN1-shared)

    Dans cet exemple, nous avons utilisé un volume Azure NetApp Files distinct pour chaque volume de données et de journaux HANA. Pour une configuration plus économique sur des systèmes plus petits ou non productifs, il est possible de placer tous les Montages de données sur un volume unique et tous les Montages de journaux sur un volume unique différent.

Déployer des machines virtuelles Linux via le Portail Azure

Vous devez d’abord créer les volumes Azure NetApp Files. Effectuez ensuite les étapes suivantes :

  1. Créez les sous-réseaux du réseau virtuel Azure dans votre réseau virtuel Azure.

  2. Déployez les machines virtuelles.

  3. Créez des interfaces réseau supplémentaires et attachez-les aux machines virtuelles correspondantes.

    Chaque machine virtuelle a trois interfaces réseau, qui correspondent aux trois sous-réseaux de réseau virtuel Azure (client, storage et hana).

    Pour plus d’informations, consultez la documentation Créer une machine virtuelle Linux dans Azure avec plusieurs cartes d’interface réseau.

Important

Pour les charges de travail SAP HANA, une latence faible est critique. Pour atteindre une faible latence, collaborez avec votre représentant Microsoft pour vous assurer que les machines virtuelles et les volumes Azure NetApp Files soient déployés à proximité. Soumettez les informations nécessaires lorsque vous intégrez le nouveau système SAP HANA qui utilise SAP HANA Azure NetApp Files.

Les instructions suivantes supposent que vous avez déjà créé le groupe de ressources, le réseau virtuel Azure et les 3 sous-réseaux de réseau virtuel Azure : client, storage et hana. Lorsque vous déployez les machines virtuelles, sélectionnez le sous-réseau client, afin que l’interface réseau cliente soit l’interface principale sur les machines virtuelles. Vous devez également configurer un itinéraire explicite vers le sous-réseau délégué Azure NetApp Files via la passerelle de sous-réseau de stockage.

Important

Vérifiez que le système d’exploitation que vous sélectionnez est certifié SAP pour SAP HANA sur les types de machine virtuelle spécifiques que vous utilisez. Pour obtenir la liste des types de machines virtuelles certifiés SAP HANA et des versions de système d’exploitation correspondants, accédez au site SAP HANA Certified IaaS platforms. Cliquez sur les détails du type de machine virtuelle répertorié pour obtenir la liste complète des versions de système d’exploitation prises en charge par SAP HANA pour ce type.

  1. Créez un groupe à haute disponibilité pour SAP HANA. Veillez à définir un domaine de mise à jour maximal.

  2. Créez 3 machines virtuelles (hanadb1, hanadb2 et hanadb3) en procédant comme suit :

    a. Utilisez une image Red Hat Enterprise Linux de la galerie Azure prise en charge pour SAP HANA. Nous avons utilisé une image RHEL-SAP-HA 7.6 dans cet exemple.

    b. Sélectionnez le groupe à haute disponibilité créé précédemment pour SAP HANA.

    c. Sélectionnez le sous-réseau de réseau virtuel Azure client. Sélectionnez Mise en réseau accélérée.

    Lorsque vous déployez les machines virtuelles, le nom de l’interface réseau est généré automatiquement. Dans ces instructions, par soucis de simplicité, nous allons faire référence aux interfaces réseau générées automatiquement, qui sont attachées au sous-réseau de réseau virtuel Azure client, en tant que hanadb1-client, hanadb2-clientet hanadb3-client.

  3. Créez 3 interfaces réseau, une pour chaque machine virtuelle, pour le sous-réseau de réseau virtuel storage (dans cet exemple hanadb1-storage, hanadb2-storage et hanadb3-storage).

  4. Créez trois interfaces réseau, une pour chaque machine virtuelle, pour le sous-réseau du réseau virtuel hana (dans cet exemple, hanadb1-hana, hanadb2-hana et hanadb3-hana).

  5. Attachez les interfaces réseau virtuelles nouvellement créées aux machines virtuelles correspondantes en procédant comme suit :

    a. Accédez à la machine virtuelle sur le Portail Azure.

    b. Dans le volet gauche, sélectionnez Machines virtuelles. Filtrez sur le nom de la machine virtuelle (par exemple, hanadb1), puis sélectionnez la machine virtuelle.

    c. Dans le volet Vue d’ensemble, sélectionnez Arrêter pour libérer la machine virtuelle.

    d. Sélectionnez Mise en réseau, puis attachez l’interface réseau. Dans la liste déroulante sous Attacher l’interface réseau, sélectionnez les interfaces réseau déjà créées pour les sous-réseaux storage et hana.

    e. Sélectionnez Enregistrer.

    f. Répétez les étapes b à e pour les machines virtuelles restantes (dans notre exemple, hanadb2 et hanadb3).

    g. Laissez les machines virtuelles dans l’état arrêté pour l’instant. Ensuite, nous allons activer Mise en réseau accélérée pour toutes les interfaces réseau qui viennent d’être attachées.

  6. Activez la mise en réseau accélérée pour les interfaces réseau supplémentaires pour les sous-réseaux storage et hana en procédant comme suit :

    a. Ouvrez Azure Cloud Shell dans le Portail Azure.

    b. Exécutez les commandes suivantes pour activer la mise en réseau accélérée pour les interfaces réseau supplémentaires, qui sont attachées aux sous-réseaux storage et hana.

    
     az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hanadb1-storage --accelerated-networking true
     az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hanadb2-storage --accelerated-networking true
     az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hanadb3-storage --accelerated-networking true
    
     az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hanadb1-hana --accelerated-networking true
     az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hanadb2-hana --accelerated-networking true
     az network nic update --id /subscriptions/your subscription/resourceGroups/your resource group/providers/Microsoft.Network/networkInterfaces/hanadb3-hana --accelerated-networking true
    
     
  7. Démarrez les machines virtuelles en procédant comme suit :

    a. Dans le volet gauche, sélectionnez Machines virtuelles. Filtrez sur le nom de la machine virtuelle (par exemple, hanadb1), puis sélectionnez-le.

    b. Dans le volet Vue d’ensemble, sélectionnez Démarrer.

Configuration et préparation du système d’exploitation

Les instructions des sections suivantes sont précédées de l’un des éléments suivants :

  • [A] : applicable à tous les nœuds
  • [1] : applicable uniquement au nœud 1
  • [2] : applicable uniquement au nœud 2
  • [3] : applicable uniquement au nœud 3

Configurez et préparez votre système d’exploitation en procédant comme suit :

  1. [A] Conservez les fichiers hôtes sur les machines virtuelles. Incluez des entrées pour tous les sous-réseaux. Les entrées suivantes ont été ajoutées à /etc/hosts pour cet exemple.

    
     # Storage
     10.9.3.4   hanadb1-storage
     10.9.3.5   hanadb2-storage
     10.9.3.6   hanadb3-storage
     # Client
     10.9.1.5   hanadb1
     10.9.1.6   hanadb2
     10.9.1.7   hanadb3
     # Hana
     10.9.2.4   hanadb1-hana
     10.9.2.5   hanadb2-hana
     10.9.2.6   hanadb3-hana
     
  2. [A] Ajoutez un itinéraire réseau, de sorte que la communication avec Azure NetApp Files passe par l’interface réseau de stockage.

    Dans cet exemple, vous utiliserez Networkmanager pour configurer l’itinéraire réseau supplémentaire. Les instructions suivantes supposent que eth1 est l’interface réseau de stockage.
    Tout d’abord, déterminez le nom de connexion pour le eth1d’appareil. Dans cet exemple, le nom de connexion pour le eth1 d’appareil est Wired connection 1.

    
     # Execute as root
     nmcli connection
     # Result
     #NAME                UUID                                  TYPE      DEVICE
     #System eth0         5fb06bd0-0bb0-7ffb-45f1-d6edd65f3e03  ethernet  eth0
     #Wired connection 1  4b0789d1-6146-32eb-83a1-94d61f8d60a7  ethernet  eth1
     

    Configurez ensuite l’itinéraire supplémentaire vers le réseau délégué Azure NetApp Files via eth1.

    
     # Add the following route 
     # ANFDelegatedSubnet/cidr via StorageSubnetGW dev StorageNetworkInterfaceDevice
     nmcli connection modify "Wired connection 1" +ipv4.routes "10.9.0.0/26 10.9.3.1"
     

    Redémarrez la machine virtuelle pour activer les modifications.

  3. [A] Installer le package client NFS.

    
     yum install nfs-utils
     
  4. [A] Préparez l’OS pour l’exécution de SAP HANA sur Azure NetApp avec NFS, comme indiqué dans la note SAP 3024346 - Paramètres du noyau Linux pour NetApp avec NFS. Créez un fichier de configuration /etc/sysctl.d/91-NetApp-HANA.conf pour les paramètres de configuration de NetApp.

    
     vi /etc/sysctl.d/91-NetApp-HANA.conf
     # Add the following entries in the configuration file
     net.core.rmem_max = 16777216
     net.core.wmem_max = 16777216
     net.ipv4.tcp_rmem = 4096 131072 16777216
     net.ipv4.tcp_wmem = 4096 16384 16777216
     net.core.netdev_max_backlog = 300000 
     net.ipv4.tcp_slow_start_after_idle=0 
     net.ipv4.tcp_no_metrics_save = 1
     net.ipv4.tcp_moderate_rcvbuf = 1
     net.ipv4.tcp_window_scaling = 1
     net.ipv4.tcp_timestamps = 1
     net.ipv4.tcp_sack = 1
     
  5. [A] Créez un fichier de configuration /etc/sysctl.d/ms-az.conf avec les paramètres d’optimisation supplémentaires.

    
     vi /etc/sysctl.d/ms-az.conf
     # Add the following entries in the configuration file
     net.ipv6.conf.all.disable_ipv6 = 1
     net.ipv4.tcp_max_syn_backlog = 16348
     net.ipv4.conf.all.rp_filter = 0
     sunrpc.tcp_slot_table_entries = 128
     vm.swappiness=10
     

Conseil

Évitez de définir net.ipv4.ip_local_port_range et net.ipv4.ip_local_reserved_ports explicitement dans les fichiers config sysctl pour permettre à l’agent hôte SAP de gérer les plages de ports. Pour plus d’informations, consultez la note SAP 2382421.

  1. [A] Modifiez les paramètres de sunrpc, comme indiqué dans la note SAP 3024346 - Paramètres du noyau Linux pour NetApp avec NFS.

    
     vi /etc/modprobe.d/sunrpc.conf
     # Insert the following line
     options sunrpc tcp_max_slot_table_entries=128
     
  2. [A] Red Hat pour la configuration HANA.

    Configurez RHEL comme décrit dans les notes SAP 2292690, 2455582, 2593824, et la note Red Hat 2447641.

    Notes

    Si vous installez HANA 2.0 SP04, vous devez installer le package compat-sap-c++-7 comme décrit dans la note SAP 2593824, avant de pouvoir installer SAP HANA.

Monter les volumes Azure NetApp Files

  1. [A] Créez des points de montage pour les volumes de base de données HANA.

    
     mkdir -p /hana/data/HN1/mnt00001
     mkdir -p /hana/data/HN1/mnt00002
     mkdir -p /hana/log/HN1/mnt00001
     mkdir -p /hana/log/HN1/mnt00002
     mkdir -p /hana/shared
     mkdir -p /usr/sap/HN1
     
  2. [1] Créez des répertoires spécifiques aux nœuds pour /usr/sap sur partages HN1.

    
     # Create a temporary directory to mount HN1-shared
     mkdir /mnt/tmp
     # if using NFSv3 for this volume, mount with the following command
     mount 10.9.0.4:/HN1-shared /mnt/tmp
     # if using NFSv4.1 for this volume, mount with the following command
     mount -t nfs -o sec=sys,nfsvers=4.1 10.9.0.4:/HN1-shared /mnt/tmp
     cd /mnt/tmp
     mkdir shared usr-sap-hanadb1 usr-sap-hanadb2 usr-sap-hanadb3
     # unmount /hana/shared
     cd
     umount /mnt/tmp
     
  3. [A] Vérifiez le paramètre de domaine NFS. Assurez-vous que le domaine est configuré en tant que domaine par défaut Azure NetApp Files, par exemple defaultv4iddomain.com et que le mappage est défini sur nobody.

    Important

    Veillez à définir le domaine NFS dans /etc/idmapd.conf sur la machine virtuelle pour qu’elle corresponde à la configuration de domaine par défaut sur Azure NetApp Files : defaultv4iddomain.com . En cas d’incompatibilité entre la configuration de domaine sur le client NFS (c’est-à-dire la machine virtuelle) et le serveur NFS, par exemple la configuration Azure NetApp, les autorisations pour les fichiers sur les volumes Azure NetApp montés sur les machines virtuelles s’affichent en tant que nobody.

    
     sudo cat /etc/idmapd.conf
     # Example
     [General]
     Domain = defaultv4iddomain.com
     [Mapping]
     Nobody-User = nobody
     Nobody-Group = nobody
     
  4. [A] Vérifiez nfs4_disable_idmapping. Cette option doit avoir la valeur Y. Pour créer la structure de répertoire où se trouve nfs4_disable_idmapping, exécutez la commande de montage. Vous ne serez pas en mesure de créer manuellement le répertoire sous /sys/modules, car l’accès est réservé pour le noyau/les pilotes.

    
     # Check nfs4_disable_idmapping 
     cat /sys/module/nfs/parameters/nfs4_disable_idmapping
     # If you need to set nfs4_disable_idmapping to Y
     mkdir /mnt/tmp
     mount 10.9.0.4:/HN1-shared /mnt/tmp
     umount  /mnt/tmp
     echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping
     # Make the configuration permanent
     echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
     

    Pour plus d’informations sur la modification du paramètre nfs4_disable_idmapping, consultez https://access.redhat.com/solutions/1749883.

  5. [A] Montez les volumes Azure NetApp Files partagés.

    
     sudo vi /etc/fstab
     # Add the following entries
     10.9.0.4:/HN1-data-mnt00001 /hana/data/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
     10.9.0.4:/HN1-data-mnt00002 /hana/data/HN1/mnt00002  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
     10.9.0.4:/HN1-log-mnt00001 /hana/log/HN1/mnt00001  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
     10.9.0.4:/HN1-log-mnt00002 /hana/log/HN1/mnt00002  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
     10.9.0.4:/HN1-shared/shared /hana/shared  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
     # Mount all volumes
     sudo mount -a 
     

    Pour les charges de travail qui nécessitent un débit plus élevé, utilisez l’option de montage nconnect, comme indiqué dans Volumes NFS v4.1 sur Azure NetApp Files pour SAP HANA. Vérifiez si nconnect est pris en charge par Azure NetApp Files sur votre version Linux.

  6. [1] Montez les volumes spécifiques aux nœuds sur hanadb1.

    
     sudo vi /etc/fstab
     # Add the following entries
     10.9.0.4:/HN1-shared/usr-sap-hanadb1 /usr/sap/HN1  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
     # Mount the volume
     sudo mount -a 
     
  7. [2] Montez les volumes spécifiques aux nœuds sur hanadb2.

    
     sudo vi /etc/fstab
     # Add the following entries
     10.9.0.4:/HN1-shared/usr-sap-hanadb2 /usr/sap/HN1  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
     # Mount the volume
     sudo mount -a 
     
  8. [3] Montez les volumes spécifiques aux nœuds sur hanadb3.

    
     sudo vi /etc/fstab
     # Add the following entries
     10.9.0.4:/HN1-shared/usr-sap-hanadb3 /usr/sap/HN1  nfs   rw,nfsvers=4.1,hard,timeo=600,rsize=262144,wsize=262144,noatime,lock,_netdev,sec=sys  0  0
     # Mount the volume
     sudo mount -a 
     
  9. [A] Vérifiez que tous les volumes HANA sont montés avec la version de protocole NFS NFSv4.

    
    sudo nfsstat -m
    # Verify that flag vers is set to 4.1 
    # Example from hanadb1
    /hana/data/HN1/mnt00001 from 10.9.0.4:/HN1-data-mnt00001
     Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.9.3.4,local_lock=none,addr=10.9.0.4
    /hana/log/HN1/mnt00002 from 10.9.0.4:/HN1-log-mnt00002
     Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.9.3.4,local_lock=none,addr=10.9.0.4
    /hana/data/HN1/mnt00002 from 10.9.0.4:/HN1-data-mnt00002
     Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.9.3.4,local_lock=none,addr=10.9.0.4
    /hana/log/HN1/mnt00001 from 10.9.0.4:/HN1-log-mnt00001
    Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.9.3.4,local_lock=none,addr=10.9.0.4
    /usr/sap/HN1 from 10.9.0.4:/HN1-shared/usr-sap-hanadb1
     Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.9.3.4,local_lock=none,addr=10.9.0.4
    /hana/shared from 10.9.0.4:/HN1-shared/shared
     Flags: rw,noatime,vers=4.1,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.9.3.4,local_lock=none,addr=10.9.0.4
    

Installation

Dans cet exemple, pour le déploiement de SAP HANA dans une configuration Scale-out avec un nœud de secours à l’aide d’Azure, nous avons utilisé HANA 2.0 SP4.

Préparer l’installation de HANA

  1. [A] Avant l’installation de HANA, définissez le mot de passe racine. Vous pouvez désactiver le mot de passe racine une fois l’installation terminée. Exécutez en tant que commande rootpasswd.

  2. [1] Vérifiez que vous pouvez vous connecter via SSH sur hanadb2 et hanadb3 sans être invité à entrer un mot de passe.

    
     ssh root@hanadb2
     ssh root@hanadb3
     
  3. [A] Installez des packages supplémentaires, qui sont nécessaires pour HANA 2.0 SP4. Pour plus d’informations, consultez la note SAP 2593824.

    
     yum install libgcc_s1 libstdc++6 compat-sap-c++-7 libatomic1 
     
  4. [2], [3] Modifiez la propriété de SAP HANA des répertoires data et log pour hn1adm.

    
     # Execute as root
     sudo chown hn1adm:sapsys /hana/data/HN1
     sudo chown hn1adm:sapsys /hana/log/HN1
     
  5. [A] Désactivez temporairement le pare-feu, afin qu’il n’interfère pas avec l’installation de HANA. Vous pouvez le réactiver une fois l’installation terminée.

    
     # Execute as root
     systemctl stop firewalld
     systemctl disable firewalld
    

Installation de HANA

  1. [1] Installez SAP HANA en suivant les instructions fournies dans le Guide d’installation et de mise à jour de SAP HANA 2.0. Dans cet exemple, nous installons le Scale-out SAP HANA avec un maître, un Worker et un nœud de secours.

    a. Démarrez le programme hdblcm à partir du répertoire du logiciel d’installation HANA. Utilisez le paramètre internal_network et transmettez l’espace d’adressage pour le sous-réseau, qui est utilisé pour la communication interne HANA entre les nœuds.

    
     ./hdblcm --internal_network=10.9.2.0/26
     

    b. À l’invite, entrez les valeurs suivantes :

    • Pour Choisir une action : entrer 1 (pour l’installation)
    • Pour Composants supplémentaires pour l’installation : entrer 2, 3
    • Pour le chemin d’accès de l’installation : appuyer sur Entrée (utilise par défaut /hana/shared)
    • Pour Nom d’hôte local : appuyer sur Entrée pour accepter la valeur par défaut
    • Sous Voulez-vous ajouter des hôtes au système ? : entrer y
    • Pour Noms d’hôte séparés par un virgule à ajouter : entrer hanadb2, hanadb3
    • Pour Nom d’utilisateur racine [racine] : appuyer sur Entrée pour accepter la valeur par défaut
    • Pour les rôles pour l’hôte hanadb2 : entrez 1 (pour Worker)
    • Pour Groupe de basculement hôte pour l’hôte hanadb2 [par défaut] : appuyer sur Entrée pour accepter la valeur par défaut
    • Pour Numéro de partition de stockage pour l’hôte hanadb2 [<<attribuer automatiquement>>] : appuyez sur Entrée pour accepter la valeur par défaut.
    • Pour Groupe Worker pour l’hôte hanadb2 [par défaut] : appuyer sur Entrée pour accepter la valeur par défaut
    • Pour Sélectionner des rôles pour l’hôte hanadb3 : entrer 2 (pour le serveur de secours)
    • Pour Groupe de basculement hôte pour l’hôte hanadb3 [par défaut] : appuyer sur Entrée pour accepter la valeur par défaut
    • Pour Groupe Worker pour l’hôte hanadb3 [par défaut] : appuyer sur Entrée pour accepter la valeur par défaut
    • Pour ID système SAP HANA : entrer HN1
    • Pour Numéro d’instance [00] : entrer 03
    • Pour Groupe Worker hôte local [par défaut] : appuyer sur Entrée pour accepter la valeur par défaut
    • Pour Sélectionner Utilisation du système/Entrer l’index [4] : entrer 4 (pour personnalisé)
    • Pour Emplacement des volumes de données [/hana/data/HN1] : appuyer sur Entrée pour accepter la valeur par défaut
    • Pour Emplacement des volumes de journaux [/hana/log/HN1] : appuyer sur Entrée pour accepter la valeur par défaut
    • Pour Restreindre l’allocation de mémoire maximale ? [n] : entrez n.
    • Pour Nom d’hôte du certificat pour l’hôte hanadb1 [hanadb1] : appuyer sur Entrée pour accepter la valeur par défaut
    • Pour Nom d’hôte du certificat pour l’hôte hanadb2 [hanadb2] : appuyer sur Entrée pour accepter la valeur par défaut
    • Pour Nom d’hôte du certificat pour l’hôte hanadb3 [hanadb3] : appuyer sur Entrée pour accepter la valeur par défaut
    • Pour Mot de passe de l’administrateur système (hn1adm) : entrer le mot de passe
    • Pour Mot de passe utilisateur de la base de données système (système) : entrer le mot de passe du système
    • Pour Confirmer le mot de passe utilisateur de la base de données système (système) : entrer le mot de passe du système
    • Pour Redémarrer le système après le redémarrage de la machine ? [n] : entrez n.
    • Pour Voulez-vous continuer (y/n) : valider le résumé et si tout semble correct, entrer y
  2. [1] vérifier global. ini

    Affichez global.ini et assurez-vous que la configuration de la communication interne SAP HANA entre les nœuds est en place. Vérifiez la section communication. Elle doit comporter un espace d’adressage pour le sous-réseau hana et listeninterface doit être défini sur .internal. Vérifiez la section internal_hostname_resolution. Elle doit comporter les adresses IP des machines virtuelles HANA qui appartiennent au sous-réseau hana.

    
     sudo cat /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
     # Example 
     #global.ini last modified 2019-09-10 00:12:45.192808 by hdbnameserve
     [communication]
     internal_network = 10.9.2.0/26
     listeninterface = .internal
     [internal_hostname_resolution]
     10.9.2.4 = hanadb1
     10.9.2.5 = hanadb2
     10.9.2.6 = hanadb3
    
  3. [1] Ajoutez le mappage de l’hôte pour vous assurer que les adresses IP du client sont utilisées pour les communications des clients. Ajoutez la section public_host_resolution, puis les adresses IP correspondantes à partir du sous-réseau client.

    
     sudo vi /usr/sap/HN1/SYS/global/hdb/custom/config/global.ini
     #Add the section
     [public_hostname_resolution]
     map_hanadb1 = 10.9.1.5
     map_hanadb2 = 10.9.1.6
     map_hanadb3 = 10.9.1.7
    
  4. [1] Redémarrez SAP HANA pour activer les modifications.

    
     sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem HDB
     sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem HDB
    
  5. [1] Vérifiez que l’interface client utilise les adresses IP du sous-réseau client pour les communications.

    
     # Execute as hn1adm
     /usr/sap/HN1/HDB03/exe/hdbsql -u SYSTEM -p "password" -i 03 -d SYSTEMDB 'select * from SYS.M_HOST_INFORMATION'|grep net_publicname
     # Expected result
     "hanadb3","net_publicname","10.9.1.7"
     "hanadb2","net_publicname","10.9.1.6"
     "hanadb1","net_publicname","10.9.1.5"
    

    Pour plus d’informations sur la vérification de la configuration, consultez la note SAP 2183363 – Configuration du réseau interne SAP HANA.

  6. [A] Réactivez le pare-feu.

    • Arrêtez HANA

      
         sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StopSystem HDB
        
    • Réactivez le pare-feu.

      
         # Execute as root
         systemctl start firewalld
         systemctl enable firewalld
        
    • Ouvrez les ports de pare-feu nécessaires.

      Important

      Créez des règles de pare-feu pour autoriser le trafic client et de communication entre nœuds HANA. Les ports indispensables sont répertoriés ici : Ports TCP/IP de tous les produits SAP. Les commandes suivantes sont simplement des exemples. Dans ce scénario avec le numéro de système 03 utilisé.

      
         # Execute as root
         sudo firewall-cmd --zone=public --add-port={30301,30303,30306,30307,30313,30315,30317,30340,30341,30342,1128,1129,40302,40301,40307,40303,40340,50313,50314,30310,30302}/tcp --permanent
         sudo firewall-cmd --zone=public --add-port={30301,30303,30306,30307,30313,30315,30317,30340,30341,30342,1128,1129,40302,40301,40307,40303,40340,50313,50314,30310,30302}/tcp
        
    • Démarrez HANA

      
         sudo -u hn1adm /usr/sap/hostctrl/exe/sapcontrol -nr 03 -function StartSystem HDB
        
  7. Afin d’optimiser SAP HANA pour le stockage Azure NetApp Files sous-jacent, définissez les paramètres SAP HANA suivants :

    • max_parallel_io_requests128
    • async_read_submiton
    • async_write_submit_activeon
    • async_write_submit_blocksall

    Pour plus d’informations, consultez Configuration de la pile d’E/S pour SAP HANA.

    À partir des systèmes SAP HANA 2.0, vous pouvez définir les paramètres dans global.ini. Pour plus d’informations, consultez la note SAP 1999930.

    Pour les systèmes SAP HANA 1.0, versions SPS12 et antérieures, ces paramètres peuvent être définis lors de l’installation, comme décrit dans la note SAP 2267798.

  8. Le stockage utilisé par Azure NetApp Files présente une taille de fichier limitée à 16 To. SAP HANA n’est pas implicitement au courant de la limite de stockage et ne crée pas automatiquement de nouveau fichier de données lorsque la limite de taille de fichier de 16 To est atteinte. Comme SAP HANA tente d’augmenter le fichier au-delà de 16 To, cette tentative génère des erreurs et finit par provoquer un incident sur le serveur d’index.

    Important

    Pour empêcher SAP HANA d’augmenter la taille des fichiers de données au-delà de la limite des 16 To du sous-système de stockage, définissez les paramètres suivants dans global.ini.

    • datavolume_striping = true
    • datavolume_striping_size_gb = 15000 Pour plus d’informations, consultez la note SAP 2400005. Tenez compte de la note SAP 2631285.

Test de basculement SAP HANA

  1. Simulez un incident de nœud sur un nœud Worker SAP HANA. Effectuez les actions suivantes :

    a. Avant de simuler l’incident du nœud, exécutez les commandes suivantes en tant que hn1adm pour capturer l’état de l’environnement :

    
     # Check the landscape status
     python /usr/sap/HN1/HDB03/exe/python_support/landscapeHostConfiguration.py
     | Host    | Host   | Host   | Failover | Remove | Storage   | Storage   | Failover | Failover | NameServer | NameServer | IndexServer | IndexServer | Host    | Host    | Worker  | Worker  |
     |         | Active | Status | Status   | Status | Config    | Actual    | Config   | Actual   | Config     | Actual     | Config      | Actual      | Config  | Actual  | Config  | Actual  |
     |         |        |        |          |        | Partition | Partition | Group    | Group    | Role       | Role       | Role        | Role        | Roles   | Roles   | Groups  | Groups  |
     | ------- | ------ | ------ | -------- | ------ | --------- | --------- | -------- | -------- | ---------- | ---------- | ----------- | ----------- | ------- | ------- | ------- | ------- |
     | hanadb1 | yes    | ok     |          |        |         1 |         1 | default  | default  | master 1   | master     | worker      | master      | worker  | worker  | default | default |
     | hanadb2 | yes    | ok     |          |        |         2 |         2 | default  | default  | master 2   | slave      | worker      | slave       | worker  | worker  | default | default |
     | hanadb3 | yes    | ignore |          |        |         0 |         0 | default  | default  | master 3   | slave      | standby     | standby     | standby | standby | default | -       |
    
     # Check the instance status
     sapcontrol -nr 03  -function GetSystemInstanceList
     GetSystemInstanceList
     OK
     hostname, instanceNr, httpPort, httpsPort, startPriority, features, dispstatus
     hanadb2, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
     hanadb1, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
     hanadb3, 3, 50313, 50314, 0.3, HDB|HDB_STANDBY, GREEN
    

    b. Pour simuler un incident de nœud, exécutez la commande suivante en tant que racine sur le nœud Worker, en l’occurrence hanadb2 :

    
     echo b > /proc/sysrq-trigger
    

    c. Surveillez le système pour la fin du basculement. Une fois le basculement terminé, capturez l’état, lequel doit ressembler à ce qui suit :

    
     # Check the instance status
     sapcontrol -nr 03  -function GetSystemInstanceList
     GetSystemInstanceList
     OK
     hostname, instanceNr, httpPort, httpsPort, startPriority, features, dispstatus
     hanadb1, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
     hanadb2, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GRAY
     hanadb3, 3, 50313, 50314, 0.3, HDB|HDB_STANDBY, GREEN
     # Check the landscape status
     python /usr/sap/HN1/HDB03/exe/python_support/landscapeHostConfiguration.py
     | Host    | Host   | Host   | Failover | Remove | Storage   | Storage   | Failover | Failover | NameServer | NameServer | IndexServer | IndexServer | Host    | Host    | Worker  | Worker  |
     |         | Active | Status | Status   | Status | Config    | Actual    | Config   | Actual   | Config     | Actual     | Config      | Actual      | Config  | Actual  | Config  | Actual  |
     |         |        |        |          |        | Partition | Partition | Group    | Group    | Role       | Role       | Role        | Role        | Roles   | Roles   | Groups  | Groups  |
     | ------- | ------ | ------ | -------- | ------ | --------- | --------- | -------- | -------- | ---------- | ---------- | ----------- | ----------- | ------- | ------- | ------- | ------- |
     | hanadb1 | yes    | ok     |          |        |         1 |         1 | default  | default  | master 1   | master     | worker      | master      | worker  | worker  | default | default |
     | hanadb2 | no     | info   |          |        |         2 |         0 | default  | default  | master 2   | slave      | worker      | standby     | worker  | standby | default | -       |
     | hanadb3 | yes    | info   |          |        |         0 |         2 | default  | default  | master 3   | slave      | standby     | slave       | standby | worker  | default | default |
    

    Important

    Lorsqu’un nœud subit une panique du noyau, évitez les retards de basculement SAP HANA en paramétrant kernel.panic sur 20 secondes sur toutes les machines virtuelles HANA. La configuration est effectuée dans /etc/sysctl. Redémarrez les machines virtuelles pour activer la modification. Si cette modification n’est pas effectuée, le basculement peut prendre 10 minutes ou plus lorsqu’un nœud subit une panique du noyau.

  2. Tuez le serveur de noms en procédant comme suit :

    a. Avant le test, vérifiez l’état de l’environnement en exécutant les commandes suivantes en tant que hn1adm :

    
     #Landscape status 
     python /usr/sap/HN1/HDB03/exe/python_support/landscapeHostConfiguration.py
     | Host    | Host   | Host   | Failover | Remove | Storage   | Storage   | Failover | Failover | NameServer | NameServer | IndexServer | IndexServer | Host    | Host    | Worker  | Worker  |
     |         | Active | Status | Status   | Status | Config    | Actual    | Config   | Actual   | Config     | Actual     | Config      | Actual      | Config  | Actual  | Config  | Actual  |
     |         |        |        |          |        | Partition | Partition | Group    | Group    | Role       | Role       | Role        | Role        | Roles   | Roles   | Groups  | Groups  |
     | ------- | ------ | ------ | -------- | ------ | --------- | --------- | -------- | -------- | ---------- | ---------- | ----------- | ----------- | ------- | ------- | ------- | ------- |
     | hanadb1 | yes    | ok     |          |        |         1 |         1 | default  | default  | master 1   | master     | worker      | master      | worker  | worker  | default | default |
     | hanadb2 | yes    | ok     |          |        |         2 |         2 | default  | default  | master 2   | slave      | worker      | slave       | worker  | worker  | default | default |
     | hanadb3 | yes    | ignore |          |        |         0 |         0 | default  | default  | master 3   | slave      | standby     | standby     | standby | standby | default | -       |
     # Check the instance status
     sapcontrol -nr 03  -function GetSystemInstanceList
     GetSystemInstanceList
     OK
     hostname, instanceNr, httpPort, httpsPort, startPriority, features, dispstatus
     hanadb2, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
     hanadb3, 3, 50313, 50314, 0.3, HDB|HDB_STANDBY, GREEN
     hanadb1, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
    

    b. Exécutez les commandes suivantes en tant que hn1adm sur le nœud principal actif, en l’occurrence hanadb1 :

    
         hn1adm@hanadb1:/usr/sap/HN1/HDB03> HDB kill
     

    Le nœud de secours hanadb3 prend la forme d’un nœud principal. Voici l’état des ressources après la fin du test de basculement :

    
      # Check the instance status
      sapcontrol -nr 03  -function GetSystemInstanceList
      GetSystemInstanceList
      OK
      hostname, instanceNr, httpPort, httpsPort, startPriority, features, dispstatus
      hanadb2, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
      hanadb3, 3, 50313, 50314, 0.3, HDB|HDB_STANDBY, GREEN
      hanadb1, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GRAY
      # Check the landscape status
      python /usr/sap/HN1/HDB03/exe/python_support/landscapeHostConfiguration.py
      | Host    | Host   | Host   | Failover | Remove | Storage   | Storage   | Failover | Failover | NameServer | NameServer | IndexServer | IndexServer | Host    | Host    | Worker  | Worker  |
      |         | Active | Status | Status   | Status | Config    | Actual    | Config   | Actual   | Config     | Actual     | Config      | Actual      | Config  | Actual  | Config  | Actual  |
      |         |        |        |          |        | Partition | Partition | Group    | Group    | Role       | Role       | Role        | Role        | Roles   | Roles   | Groups  | Groups  |
      | ------- | ------ | ------ | -------- | ------ | --------- | --------- | -------- | -------- | ---------- | ---------- | ----------- | ----------- | ------- | ------- | ------- | ------- |
      | hanadb1 | no     | info   |          |        |         1 |         0 | default  | default  | master 1   | slave      | worker      | standby     | worker  | standby | default | -       |
      | hanadb2 | yes    | ok     |          |        |         2 |         2 | default  | default  | master 2   | slave      | worker      | slave       | worker  | worker  | default | default |
      | hanadb3 | yes    | info   |          |        |         0 |         1 | default  | default  | master 3   | master     | standby     | master      | standby | worker  | default | default |
     

    c. Redémarrez l’instance HANA sur hanadb1 (c’est-à-dire sur la même machine virtuelle où le serveur de noms a été tué). Le nœud hanadb1 rejoindra l’environnement et conservera son rôle de secours.

    
     hn1adm@hanadb1:/usr/sap/HN1/HDB03> HDB start
    

    Une fois que SAP HANA a démarré sur hanadb1, attendez-vous à l’état suivant :

    
     # Check the instance status
     sapcontrol -nr 03  -function GetSystemInstanceList
     GetSystemInstanceList
     OK
     hostname, instanceNr, httpPort, httpsPort, startPriority, features, dispstatus
     hanadb2, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
     hanadb3, 3, 50313, 50314, 0.3, HDB|HDB_STANDBY, GREEN
     hanadb1, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
     # Check the landscape status
     python /usr/sap/HN1/HDB03/exe/python_support/landscapeHostConfiguration.py
     | Host    | Host   | Host   | Failover | Remove | Storage   | Storage   | Failover | Failover | NameServer | NameServer | IndexServer | IndexServer | Host    | Host    | Worker  | Worker  |
     |         | Active | Status | Status   | Status | Config    | Actual    | Config   | Actual   | Config     | Actual     | Config      | Actual      | Config  | Actual  | Config  | Actual  |
     |         |        |        |          |        | Partition | Partition | Group    | Group    | Role       | Role       | Role        | Role        | Roles   | Roles   | Groups  | Groups  |
     | ------- | ------ | ------ | -------- | ------ | --------- | --------- | -------- | -------- | ---------- | ---------- | ----------- | ----------- | ------- | ------- | ------- | ------- |
     | hanadb1 | no     | info   |          |        |         1 |         0 | default  | default  | master 1   | slave      | worker      | standby     | worker  | standby | default | -       |
     | hanadb2 | yes    | ok     |          |        |         2 |         2 | default  | default  | master 2   | slave      | worker      | slave       | worker  | worker  | default | default |
     | hanadb3 | yes    | info   |          |        |         0 |         1 | default  | default  | master 3   | master     | standby     | master      | standby | worker  | default | default |
    

    d. Tuez à nouveau le serveur de noms sur le nœud principal actuellement actif (autrement dit, sur le nœud hanadb3).

    
     hn1adm@hanadb3:/usr/sap/HN1/HDB03> HDB kill
    

    Le nœud hanadb1 va reprendre le rôle du nœud principal. Une fois le test de basculement terminé, l’état se présente comme suit :

    
     # Check the instance status
     sapcontrol -nr 03  -function GetSystemInstanceList
     GetSystemInstanceList
     OK
     hostname, instanceNr, httpPort, httpsPort, startPriority, features, dispstatus
     hanadb2, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
     hanadb3, 3, 50313, 50314, 0.3, HDB|HDB_STANDBY, GRAY
     hanadb1, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
     # Check the landscape status
     python /usr/sap/HN1/HDB03/exe/python_support/landscapeHostConfiguration.py
     | Host    | Host   | Host   | Failover | Remove | Storage   | Storage   | Failover | Failover | NameServer | NameServer | IndexServer | IndexServer | Host    | Host    | Worker  | Worker  |
     |         | Active | Status | Status   | Status | Config    | Actual    | Config   | Actual   | Config     | Actual     | Config      | Actual      | Config  | Actual  | Config  | Actual  |
     |         |        |        |          |        | Partition | Partition | Group    | Group    | Role       | Role       | Role        | Role        | Roles   | Roles   | Groups  | Groups  |
     | ------- | ------ | ------ | -------- | ------ | --------- | --------- | -------- | -------- | ---------- | ---------- | ----------- | ----------- | ------- | ------- | ------- | ------- |
     | hanadb1 | yes    | ok     |          |        |         1 |         1 | default  | default  | master 1   | master     | worker      | master      | worker  | worker  | default | default |
     | hanadb2 | yes    | ok     |          |        |         2 |         2 | default  | default  | master 2   | slave      | worker      | slave       | worker  | worker  | default | default |
     | hanadb3 | no     | ignore |          |        |         0 |         0 | default  | default  | master 3   | slave      | standby     | standby     | standby | standby | default | -       |
    

    e. Démarrez SAP HANA sur hanadb3, lequel sera prêt à faire office de nœud de secours.

    
     hn1adm@hanadb3:/usr/sap/HN1/HDB03> HDB start
    

    Une fois que SAP HANA a démarré sur hanadb3, l’état ressemble à ce qui suit :

    
     # Check the instance status
     sapcontrol -nr 03  -function GetSystemInstanceList & python /usr/sap/HN1/HDB03/exe/python_support/landscapeHostConfiguration.py
     GetSystemInstanceList
     OK
     hostname, instanceNr, httpPort, httpsPort, startPriority, features, dispstatus
     GetSystemInstanceList
     OK
     hostname, instanceNr, httpPort, httpsPort, startPriority, features, dispstatus
     hanadb2, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
     hanadb3, 3, 50313, 50314, 0.3, HDB|HDB_STANDBY, GREEN
     hanadb1, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
     # Check the landscape status
     python /usr/sap/HN1/HDB03/exe/python_support/landscapeHostConfiguration.py
     | Host    | Host   | Host   | Failover | Remove | Storage   | Storage   | Failover | Failover | NameServer | NameServer | IndexServer | IndexServer | Host    | Host    | Worker  | Worker  |
     |         | Active | Status | Status   | Status | Config    | Actual    | Config   | Actual   | Config     | Actual     | Config      | Actual      | Config  | Actual  | Config  | Actual  |
     |         |        |        |          |        | Partition | Partition | Group    | Group    | Role       | Role       | Role        | Role        | Roles   | Roles   | Groups  | Groups  |
     | ------- | ------ | ------ | -------- | ------ | --------- | --------- | -------- | -------- | ---------- | ---------- | ----------- | ----------- | ------- | ------- | ------- | ------- |
     | hanadb1 | yes    | ok     |          |        |         1 |         1 | default  | default  | master 1   | master     | worker      | master      | worker  | worker  | default | default |
     | hanadb2 | yes    | ok     |          |        |         2 |         2 | default  | default  | master 2   | slave      | worker      | slave       | worker  | worker  | default | default |
     | hanadb3 | no     | ignore |          |        |         0 |         0 | default  | default  | master 3   | slave      | standby     | standby     | standby | standby | default | -       |
    

Étapes suivantes