Partage via

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 SUSE Linux Enterprise Server

  • Article

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 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 SUSE Linux Enterprise Server pour SAP 12 SP4.

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.

Vue d’ensemble de la haute disponibilité SAP NetWeaver

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.23.0.0/24
  • storage 10.23.2.0/24
  • hana 10.23.3.0/24
  • anf 10.23.1.0/26

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

Lorsque vous créez votre architecture de haute disponibilité Azure NetApp Files pour SAP NetWeaver sur SUSE, 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.

Lorsque vous concevez 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, . Actuellement, l’accès à NFSv4.1 nécessite d’être ajouté à une liste verte. 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.23.1.5/HN1-data-mnt00001, nfs://10.23.1.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.23.1.5/HN1-data-mnt00001)
    • volume HN1-data-mnt00002 (nfs://10.23.1.6/HN1-data-mnt00002)
    • volume HN1-log-mnt00001 (nfs://10.23.1.4/HN1-log-mnt00001)
    • volume HN1-log-mnt00002 (nfs://10.23.1.6/HN1-log-mnt00002)
    • volume HN1-shared (nfs://10.23.1.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 et tous les montages de journaux sur un volume unique.

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 SLES4SAP de la galerie Azure prise en charge pour SAP HANA.

    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 :

    1. Accédez à la machine virtuelle sur le Portail Azure.
    2. 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.
    3. Dans le volet Vue d’ensemble, sélectionnez Arrêter pour libérer la machine virtuelle.
    4. 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.
    5. Cliquez sur Enregistrer.
    6. Répétez les étapes b à e pour les machines virtuelles restantes (dans notre exemple, hanadb2 et hanadb3).
    7. 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 :

    1. Ouvrez Azure Cloud Shell dans le Portail Azure.

    2. 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 :

    1. Dans le volet gauche, sélectionnez Machines virtuelles. Filtrez sur le nom de la machine virtuelle (par exemple, hanadb1), puis sélectionnez-le.
    2. 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.23.2.4   hanadb1-storage
 10.23.2.5   hanadb2-storage
 10.23.2.6   hanadb3-storage
 # Client
 10.23.0.5   hanadb1
 10.23.0.6   hanadb2
 10.23.0.7   hanadb3
 # Hana
 10.23.3.4   hanadb1-hana
 10.23.3.5   hanadb2-hana
 10.23.3.6   hanadb3-hana

  2. [A] Modifiez les paramètres de configuration DHCP et de cloud pour l’interface réseau du stockage afin d’éviter les modifications involontaires du nom d’hôte.

    Les instructions suivantes supposent que eth1 est l’interface réseau de stockage.

    vi /etc/sysconfig/network/dhcp 
# Change the following DHCP setting to "no"
DHCLIENT_SET_HOSTNAME="no"

vi /etc/sysconfig/network/ifcfg-eth1
# Edit ifcfg-eth1 
#Change CLOUD_NETCONFIG_MANAGE='yes' to "no"
CLOUD_NETCONFIG_MANAGE='no'

  3. [A] Ajoutez un itinéraire réseau, de sorte que la communication avec Azure NetApp Files passe par l’interface réseau de stockage.

    Les instructions suivantes supposent que eth1 est l’interface réseau de stockage.

    vi /etc/sysconfig/network/ifroute-eth1

# Add the following routes 
# RouterIPforStorageNetwork - - -
# ANFNetwork/cidr RouterIPforStorageNetwork - -
10.23.2.1 - - -
10.23.1.0/26 10.23.2.1 - -

    Redémarrez la machine virtuelle pour activer les modifications.

  4. [A] Préparez l’OS pour l’exécution de SAP HANA sur les systèmes 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 de configuration Microsoft Azure.

    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

    [!TIP] É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.

  6. [A] Modifiez les paramètres de sunrpc pour les volumes NFSv3, 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

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.23.1.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.23.1.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]
Verbosity = 0
Pipefs-Directory = /var/lib/nfs/rpc_pipefs
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.23.1.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

  5. [A] Créez manuellement le groupe et l’utilisateur SAP HANA. Les ID pour le groupe sapsys et l’utilisateur hn1adm doivent être définis sur les mêmes ID que ceux fournis lors de l’intégration. (Dans cet exemple, les ID sont définis sur 1001.) Si les ID ne sont pas définis correctement, vous ne pourrez pas accéder aux volumes. Les ID pour le groupe sapsys et les comptes d’utilisateurs hn1adm et sapadm doivent être identiques sur toutes les machines virtuelles.

    # Create user group 
sudo groupadd -g 1001 sapsys

# Create  users 
sudo useradd hn1adm -u 1001 -g 1001 -d /usr/sap/HN1/home -c "SAP HANA Database System" -s /bin/sh
sudo useradd sapadm -u 1002 -g 1001 -d /home/sapadm -c "SAP Local Administrator" -s /bin/sh

# Set the password  for both user ids
sudo passwd hn1adm
sudo passwd sapadm

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

    sudo vi /etc/fstab

# Add the following entries
10.23.1.5:/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.23.1.6:/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.23.1.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.23.1.6:/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.23.1.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.

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

    sudo vi /etc/fstab

# Add the following entries
10.23.1.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

  8. [2] Montez les volumes spécifiques aux nœuds sur hanadb2.

    sudo vi /etc/fstab

# Add the following entries
10.23.1.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

  9. [3] Montez les volumes spécifiques aux nœuds sur hanadb3.

    sudo vi /etc/fstab

# Add the following entries
10.23.1.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

  10. [A] Vérifiez que tous les volumes HANA sont montés avec la version NFSv4.1 du protocole NFS.

    sudo nfsstat -m

# Verify that flag vers is set to 4.1 
# Example from hanadb1
/hana/data/HN1/mnt00001 from 10.23.1.5:/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.23.2.4,local_lock=none,addr=10.23.1.5
/hana/log/HN1/mnt00002 from 10.23.1.6:/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.23.2.4,local_lock=none,addr=10.23.1.6
/hana/data/HN1/mnt00002 from 10.23.1.6:/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.23.2.4,local_lock=none,addr=10.23.1.6
/hana/log/HN1/mnt00001 from 10.23.1.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.23.2.4,local_lock=none,addr=10.23.1.4
/usr/sap/HN1 from 10.23.1.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.23.2.4,local_lock=none,addr=10.23.1.4
/hana/shared from 10.23.1.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.23.2.4,local_lock=none,addr=10.23.1.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.

    sudo zypper install libgcc_s1 libstdc++6 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

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.

    1. 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.23.3.0/24

    2. À 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 Mot de passe de l’utilisateur racine : entrer le mot de passe de l’utilisateur racine
      • 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érifiez 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.23.3/24
listeninterface = .internal
[internal_hostname_resolution]
10.23.3.4 = hanadb1
10.23.3.5 = hanadb2
10.23.3.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.23.0.5
map_hanadb2 = 10.23.0.6
map_hanadb3 = 10.23.0.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.

    sudo -u 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.23.0.7"
"hanadb2","net_publicname","10.23.0.6"
"hanadb1","net_publicname","10.23.0.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. Afin d’optimiser SAP HANA pour le stockage Azure NetApp Files sous-jacent, définissez les paramètres SAP HANA suivants :

    • max_parallel_io_requests 128
    • async_read_submiton
    • async_write_submit_activeon
    • async_write_submit_blocks all

    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.

  7. 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

Remarque

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

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

    1. 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

    2. 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

    3. 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
hanadb3, 3, 50313, 50314, 0.3, HDB|HDB_STANDBY, GREEN
hanadb2, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GRAY

# Check the landscape status
/usr/sap/HN1/HDB03/exe/python_support> python 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 :

    1. 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 | no     | 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, GRAY

    2. 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
hanadb1, 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 | 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 |

    3. 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
hanadb1, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
hanadb2, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
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    | 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 |

    4. 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 & 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
hanadb1, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
hanadb2, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
hanadb3, 3, 50313, 50314, 0.3, HDB|HDB_STANDBY, 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 | 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 | -       |

    5. 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
hanadb1, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
hanadb2, 3, 50313, 50314, 0.3, HDB|HDB_WORKER, GREEN
hanadb3, 3, 50313, 50314, 0.3, HDB|HDB_STANDBY, 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 | 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