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 à des 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 :
- Documentation Azure NetApp Files
- La note SAP 1928533 comprend :
- une liste des tailles de machines virtuelles Azure prises en charge pour le déploiement de logiciels SAP
- des informations importantes sur la capacité en fonction de la taille des machines virtuelles Azure
- les logiciels SAP pris en charge et les combinaisons entre système d’exploitation et base de données
- la version du noyau SAP requise pour Windows et Linux sur Microsoft Azure
- Note SAP 2015553 : répertorie les conditions préalables au déploiement de logiciels SAP pris en charge par SAP sur Azure
- La note SAP [2002167] recommande des paramètres de système d’exploitation pour Red Hat Enterprise Linux
- La note SAP 2009879 conseille sur SAP HANA pour Red Hat Enterprise Linux
- La note SAP 3108302 contient des recommandations SAP HANA pour Red Hat Enterprise Linux 9.x.
- Note SAP 2178632 : contient des informations détaillées sur toutes les métriques de supervision rapportées pour SAP dans Azure
- Note SAP 2191498 : contient la version requise de l’agent hôte SAP pour Linux dans Azure
- Note SAP 2243692 : contient des informations sur les licences SAP sur Linux dans Azure
- Note SAP 1999351 : contient des informations supplémentaires relatives à la résolution des problèmes pour l’extension d’analyse Azure améliorée pour SAP
- Note SAP 1900823 : contient des informations sur les exigences de stockage SAP HANA
- Wiki de la communauté SAP : contient toutes les notes SAP requises pour Linux
- Planification et implémentation de machines virtuelles Azure pour SAP sur Linux
- Déploiement de machines virtuelles Azure pour SAP sur Linux
- Déploiement SGBD de machines virtuelles Azure pour SAP sur Linux
- Documentation RHEL générale
- Documentation RHEL spécifique à Azure :
- Volumes NFS v4.1 sur Azure NetApp Files pour SAP HANA
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.
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/26storage
10.9.3.0/26hana
10.9.2.0/26anf
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
Lorsque vous créez vos volumes Azure NetApp Files pour les scale-out SAP HANA avec un scénario de nœuds en mode stand-by, 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.
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.
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.
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.
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 :
Créez les sous-réseaux du réseau virtuel Azure dans votre réseau virtuel Azure.
Déployez les machines virtuelles.
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
ethana
).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.
Créez un groupe à haute disponibilité pour SAP HANA. Veillez à définir un domaine de mise à jour maximal.
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.
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).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).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
ethana
.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.
Activez la mise en réseau accélérée pour les interfaces réseau supplémentaires pour les sous-réseaux
storage
ethana
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
ethana
.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
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 :
[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
[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 queeth1
est l’interface réseau de stockage.
Tout d’abord, déterminez le nom de connexion pour leeth1
d’appareil. Dans cet exemple, le nom de connexion pour leeth1
d’appareil estWired 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.
[A] Installer le package client NFS.
yum install nfs-utils
[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
[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.
[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
[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
[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
[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
[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 quenobody
.sudo cat /etc/idmapd.conf # Example [General] Domain = defaultv4iddomain.com [Mapping] Nobody-User = nobody Nobody-Group = nobody
[A] Vérifiez
nfs4_disable_idmapping
. Cette option doit avoir la valeur Y. Pour créer la structure de répertoire où se trouvenfs4_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.[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 sinconnect
est pris en charge par Azure NetApp Files sur votre version Linux.[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
[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
[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
[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
[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
root
passwd
.[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
[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
[2], [3] Modifiez la propriété de SAP HANA des répertoires
data
etlog
pour hn1adm.# Execute as root sudo chown hn1adm:sapsys /hana/data/HN1 sudo chown hn1adm:sapsys /hana/log/HN1
[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] 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
[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
etlisteninterface
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éseauhana
.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
[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
[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
[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.
[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
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
128async_read_submit
onasync_write_submit_active
onasync_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.
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
.
Test de basculement SAP HANA
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.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
- Planification et implémentation de machines virtuelles Azure pour SAP
- Déploiement de machines virtuelles Azure pour SAP
- Déploiement SGBD de machines virtuelles Azure pour SAP
- Volumes NFS v4.1 sur Azure NetApp Files pour SAP HANA
- Pour savoir comment établir une haute disponibilité et planifier la récupération d’urgence de SAP HANA sur des machines virtuelles Azure, consultez Haute disponibilité de SAP HANA sur des machines virtuelles Azure.