Haute disponibilité pour NFS sur les machines virtuelles Azure sur SUSE Linux Enterprise Server
Notes
Nous vous recommandons de déployer l’un des services NFS tiers Azure : NFS sur Azure Files ou des volumes ANF NFS pour stocker des données partagées dans un système SAP hautement disponible. Sachez que nous mettons l’accent sur les architectures de référence SAP, en utilisant des clusters NFS.
Cet article décrit comment déployer les machines virtuelles, les configurer, installer l’infrastructure du cluster et installer un serveur NFS hautement disponible pouvant être utilisé pour stocker les données partagées d’un système SAP hautement disponible. Ce guide décrit comment configurer un serveur NFS à haute disponibilité qui est utilisé par deux systèmes SAP, NW1 et NW2. Les noms des ressources (par exemple les machines virtuelles, les réseaux virtuels) de l’exemple partent du principe que vous avez utilisé le modèle de serveur de fichiers SAP avec le préfixe de ressource prod.
Remarque
Cet article contient des références à des termes que Microsoft n’utilise plus. Quand ces termes seront supprimés du logiciel, nous les supprimerons de cet article.
Commencez par lire les notes et publications SAP suivantes
Note SAP 1928533, qui contient :
- 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
La 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 2205917 contient des paramètres de système d’exploitation recommandés pour SUSE Linux Enterprise Server pour les applications SAP
La note SAP 1944799 contient des instructions SAP HANA pour SUSE Linux Enterprise Server pour les applications SAP
La note SAP 2178632 contient des informations détaillées sur toutes les métriques de surveillance rapportées pour SAP sur Azure.
La note SAP 2191498 contient la version requise de l’agent hôte SAP pour Linux sur Azure.
La note SAP 2243692 contient des informations sur les licences SAP sur Linux dans Azure.
La note SAP 1984787 contient des informations sur SUSE Linux Enterprise Server 12.
La note SAP 1999351 contient des informations de dépannage supplémentaires pour l’extension d’analyse Azure améliorée pour SAP.
Le 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 (cet article)
Déploiement SGBD de machines virtuelles Azure pour SAP sur Linux
Guides des meilleures pratiques pour SUSE Linux Enterprise Server pour applications SAP 12 SP5
Notes de publication pour SUSE Linux Enterprise Server pour applications SAP 12 SP5
Vue d’ensemble
Pour obtenir une haute disponibilité, SAP NetWeaver nécessite un serveur NFS. Le serveur NFS est configuré dans un cluster distinct et peut être utilisé par plusieurs systèmes SAP.
Le serveur NFS utilise un nom d’hôte virtuel dédié et des adresses IP virtuelles pour chacun des systèmes SAP qui utilise ce serveur NFS. Sur Azure, un équilibreur de charge est nécessaire pour utiliser une adresse IP virtuelle. La configuration présentée montre un équilibreur de charge avec :
- Adresse IP frontale 10.0.0.4 pour NW1
- Adresse IP frontale 10.0.0.5 pour NW2
- Port de sonde pour 61000 pour NW1
- Port de sonde pour 61001 pour NW2
Configurer un serveur NFS à haute disponibilité
Déployer manuellement Linux via le portail Azure
Ce document part du principe que vous avez déjà déployé un groupe de ressources, un réseau virtuel Azure et un sous-réseau.
Déployez deux machines virtuelles pour les serveurs NFS. Choisissez une image SLES appropriée prise en charge par votre système SAP. Vous pouvez déployer une machine virtuelle dans l’une des options de disponibilité : groupe identique, zone de disponibilité ou groupe à haute disponibilité.
Configurer l’équilibrage de charge Azure
Suivez le guide Créer un équilibreur de charge afin de configurer un équilibreur de charge standard pour un serveur NFS à haute disponibilité. Pendant la configuration de l’équilibreur de charge, tenez compte des points suivants.
- Configuration d’adresse IP front-end : créez deux adresses IP front-end. Sélectionnez le même réseau virtuel et le même sous-réseau que votre serveur NFS.
- Pool de back-ends : créez un pool de back-ends et ajoutez des machines virtuelles de serveur NFS.
- Règles de trafic entrant : créez deux règles d’équilibrage de charge, une pour NW1 et une autre pour NW2. Suivez les mêmes étapes pour les deux règles d’équilibrage de charge.
- Adresse IP front-end : sélectionner l’adresse IP front-end
- Pool de back-ends : sélectionner un pool de back-ends
- Cocher « Ports à haute disponibilité »
- Protocole : TCP
- Sonde d’intégrité : créez une sonde d’intégrité avec les détails ci-dessous (s’applique à la fois à NW1 et NW2)
- Protocole : TCP
- Port : [par exemple : 61000 pour NW1, 61001 pour NW2]
- Intervalle : 5
- Seuil de la sonde : 2
- Délai d’inactivité (minutes) : 30
- Cocher « Activer l’adresse IP flottante »
Remarque
La propriété de configuration de la sonde d’intégrité numberOfProbes, appelé « Seuil de défaillance d’intégrité » dans le portail, n’est pas respectée. Donc, pour contrôler le nombre de sondes consécutives qui ont réussi ou échoué, définissez la propriété « probeThreshold » sur 2. Il n’est actuellement pas possible de définir cette propriété dans le portail Azure, donc utilisez l’interface Azure CLI ou une commande PowerShell.
Remarque
Lorsque des machines virtuelles sans adresse IP publique sont placées dans le pool principal d’Azure Standard Load Balancer interne (aucune adresse IP publique), il n’y a pas de connectivité Internet sortante, sauf si une configuration supplémentaire est effectuée pour autoriser le routage vers des points de terminaison publics. Pour savoir plus en détails comment bénéficier d’une connectivité sortante, voir Connectivité des points de terminaison publics pour les machines virtuelles avec Azure Standard Load Balancer dans les scénarios de haute disponibilité SAP.
Important
- N’activez pas les horodatages TCP sur les machines virtuelles Azure placées derrière Azure Load Balancer. L’activation des timestamps TCP entraîne l’échec des sondes d’intégrité. Définissez le paramètre
net.ipv4.tcp_timestamps
sur0
. Pour plus d’informations, consultez Sondes d’intégrité Load Balancer. - Pour empêcher que saptune redéfinisse sur
1
la valeurnet.ipv4.tcp_timestamps
qui avait été définie manuellement sur0
, vous devez mettre à jour saptune vers la version 3.1.1 ou ultérieure. Pour plus d’informations, consultez saptune 3.1.1 – Do I Need to Update?.
Créer le cluster Pacemaker
Suivez les étapes décrites à la page Configuration de Pacemaker sur SUSE Linux Enterprise Server dans Azure pour créer un cluster Pacemaker de base pour ce serveur NFS.
Configurer le serveur NFS
Les éléments suivants sont précédés de [A] (applicable à tous les nœuds), de [1] (applicable uniquement au nœud 1) ou de [2] (applicable uniquement au nœud 2).
[A] Configurer la résolution de nom d’hôte
Vous pouvez utiliser un serveur DNS ou modifier le fichier /etc/hosts sur tous les nœuds. Cet exemple montre comment utiliser le fichier /etc/hosts. Remplacez l’adresse IP et le nom d’hôte dans les commandes suivantes
sudo vi /etc/hosts
Insérez les lignes suivantes dans le fichier /etc/hosts. Modifiez l’adresse IP et le nom d’hôte en fonction de votre environnement
# IP address of the load balancer frontend configuration for NFS 10.0.0.4 nw1-nfs 10.0.0.5 nw2-nfs
[A] Activer le serveur NFS
Créer l’entrée d’exportation NFS racine
sudo sh -c 'echo /srv/nfs/ *\(rw,no_root_squash,fsid=0\)>/etc/exports' sudo mkdir /srv/nfs/
[A] Installer les composants drbd
sudo zypper install drbd drbd-kmp-default drbd-utils
[A] Créer une partition pour les appareils drbd
Répertorier tous les disques de données disponibles
sudo ls /dev/disk/azure/scsi1/ # Example output # lun0 lun1
Créer des partitions pour chaque disque de données
sudo sh -c 'echo -e "n\n\n\n\n\nw\n" | fdisk /dev/disk/azure/scsi1/lun0' sudo sh -c 'echo -e "n\n\n\n\n\nw\n" | fdisk /dev/disk/azure/scsi1/lun1'
[A] Créer des configurations LVM
Répertorier toutes les partitions disponibles
ls /dev/disk/azure/scsi1/lun*-part* # Example output # /dev/disk/azure/scsi1/lun0-part1 /dev/disk/azure/scsi1/lun1-part1
Créer des volumes LVM pour chaque partition
sudo pvcreate /dev/disk/azure/scsi1/lun0-part1 sudo vgcreate vg-NW1-NFS /dev/disk/azure/scsi1/lun0-part1 sudo lvcreate -l 100%FREE -n NW1 vg-NW1-NFS sudo pvcreate /dev/disk/azure/scsi1/lun1-part1 sudo vgcreate vg-NW2-NFS /dev/disk/azure/scsi1/lun1-part1 sudo lvcreate -l 100%FREE -n NW2 vg-NW2-NFS
[A] Configurer drbd
sudo vi /etc/drbd.conf
S’assurer que le fichier drbd.conf comporte les 2 lignes suivantes
include "drbd.d/global_common.conf"; include "drbd.d/*.res";
Modifier la configuration drbd globale
sudo vi /etc/drbd.d/global_common.conf
Ajouter les entrées suivantes aux sections handler et net.
global { usage-count no; } common { handlers { fence-peer "/usr/lib/drbd/crm-fence-peer.9.sh"; after-resync-target "/usr/lib/drbd/crm-unfence-peer.9.sh"; split-brain "/usr/lib/drbd/notify-split-brain.sh root"; pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f"; } startup { wfc-timeout 0; } options { } disk { md-flushes yes; disk-flushes yes; c-plan-ahead 1; c-min-rate 100M; c-fill-target 20M; c-max-rate 4G; } net { after-sb-0pri discard-younger-primary; after-sb-1pri discard-secondary; after-sb-2pri call-pri-lost-after-sb; protocol C; tcp-cork yes; max-buffers 20000; max-epoch-size 20000; sndbuf-size 0; rcvbuf-size 0; } }
[A] Créer les appareils NFS drbd
sudo vi /etc/drbd.d/NW1-nfs.res
Insérer la configuration pour le nouvel appareil drbd et quitter
resource NW1-nfs { protocol C; disk { on-io-error detach; } net { fencing resource-and-stonith; } on prod-nfs-0 { address 10.0.0.6:7790; device /dev/drbd0; disk /dev/vg-NW1-NFS/NW1; meta-disk internal; } on prod-nfs-1 { address 10.0.0.7:7790; device /dev/drbd0; disk /dev/vg-NW1-NFS/NW1; meta-disk internal; } }
sudo vi /etc/drbd.d/NW2-nfs.res
Insérer la configuration pour le nouvel appareil drbd et quitter
resource NW2-nfs { protocol C; disk { on-io-error detach; } net { fencing resource-and-stonith; } on prod-nfs-0 { address 10.0.0.6:7791; device /dev/drbd1; disk /dev/vg-NW2-NFS/NW2; meta-disk internal; } on prod-nfs-1 { address 10.0.0.7:7791; device /dev/drbd1; disk /dev/vg-NW2-NFS/NW2; meta-disk internal; } }
Créer l’appareil drbd et le démarrer
sudo drbdadm create-md NW1-nfs sudo drbdadm create-md NW2-nfs sudo drbdadm up NW1-nfs sudo drbdadm up NW2-nfs
[1] Ignorer la synchronisation initiale
sudo drbdadm new-current-uuid --clear-bitmap NW1-nfs sudo drbdadm new-current-uuid --clear-bitmap NW2-nfs
[1] Définir le nœud principal
sudo drbdadm primary --force NW1-nfs sudo drbdadm primary --force NW2-nfs
[1] Patienter jusqu’à ce que les nouveaux appareils drbd soient synchronisés
sudo drbdsetup wait-sync-resource NW1-nfs sudo drbdsetup wait-sync-resource NW2-nfs
[1] Créer des systèmes de fichiers sur les appareils drbd
sudo mkfs.xfs /dev/drbd0 sudo mkdir /srv/nfs/NW1 sudo chattr +i /srv/nfs/NW1 sudo mount -t xfs /dev/drbd0 /srv/nfs/NW1 sudo mkdir /srv/nfs/NW1/sidsys sudo mkdir /srv/nfs/NW1/sapmntsid sudo mkdir /srv/nfs/NW1/trans sudo mkdir /srv/nfs/NW1/ASCS sudo mkdir /srv/nfs/NW1/ASCSERS sudo mkdir /srv/nfs/NW1/SCS sudo mkdir /srv/nfs/NW1/SCSERS sudo umount /srv/nfs/NW1 sudo mkfs.xfs /dev/drbd1 sudo mkdir /srv/nfs/NW2 sudo chattr +i /srv/nfs/NW2 sudo mount -t xfs /dev/drbd1 /srv/nfs/NW2 sudo mkdir /srv/nfs/NW2/sidsys sudo mkdir /srv/nfs/NW2/sapmntsid sudo mkdir /srv/nfs/NW2/trans sudo mkdir /srv/nfs/NW2/ASCS sudo mkdir /srv/nfs/NW2/ASCSERS sudo mkdir /srv/nfs/NW2/SCS sudo mkdir /srv/nfs/NW2/SCSERS sudo umount /srv/nfs/NW2
[A] Configurer la détection de Split-Brain drbd
Lorsque vous utilisez drbd pour synchroniser les données entre 2 hôtes, un syndrome Split-Brain peut se produire. Il s’agit d’un scénario au cours duquel les 2 nœuds de cluster promeuvent l’appareil drbd en tant qu’instance principale et se désynchronisent. S’il s’agit d’un problème rare, vous avez tout intérêt à le résoudre dans les meilleurs délais. Par conséquent, il est important d’être prévenu de la survenue d’un Split-Brain.
Consultez la documentation officielle drbd pour savoir comment configurer une notification de Split-Brain.
Il est également possible de récupérer automatiquement à partir d’un scénario de Split-Brain. Pour plus d’informations, consultez la page Automatic split brain recovery policies (Stratégies de récupération automatique à partir des scénarios de Split-Brain).
Configurer le framework du cluster
[1] Ajouter les appareils drbd NFS pour le système SAP NW1 à la configuration de cluster
Important
Des tests récents ont révélé des cas où netcat cessait de répondre aux demandes en raison du backlog et de sa capacité à ne gérer qu’une seule connexion. La ressource netcat cesse d’écouter les demandes d’Azure Load Balancer et l’adresse IP flottante devient indisponible.
Pour les clusters Pacemaker existants, nous vous recommandons de remplacer netcat par socat. Actuellement, nous vous recommandons d'utiliser l'agent de ressources azure-lb, qui fait partie du package resource-agents, avec la configuration requise suivante pour la version du package :- Pour SLES 12 SP4/SP5, la version minimum est resource-agents-4.3.018.a7fb5035-3.30.1.
- Pour SLES 15/15 SP1, la version minimum est resource-agents-4.3.0184.6ee15eb2-4.13.1.
Notez que la modification nécessitera un bref temps d’arrêt.
Pour les clusters Pacemaker existants, si la configuration a déjà été modifiée pour utiliser socat comme décrit à la page Azure Load-Balancer Detection Hardening, il n’est pas nécessaire de passer immédiatement à l’agent de ressources azure-lb.sudo crm configure rsc_defaults resource-stickiness="200" # Enable maintenance mode sudo crm configure property maintenance-mode=true sudo crm configure primitive drbd_NW1_nfs \ ocf:linbit:drbd \ params drbd_resource="NW1-nfs" \ op monitor interval="15" role="Master" \ op monitor interval="30" role="Slave" sudo crm configure ms ms-drbd_NW1_nfs drbd_NW1_nfs \ meta master-max="1" master-node-max="1" clone-max="2" \ clone-node-max="1" notify="true" interleave="true" sudo crm configure primitive fs_NW1_sapmnt \ ocf:heartbeat:Filesystem \ params device=/dev/drbd0 \ directory=/srv/nfs/NW1 \ fstype=xfs \ op monitor interval="10s" sudo crm configure primitive nfsserver systemd:nfs-server \ op monitor interval="30s" sudo crm configure clone cl-nfsserver nfsserver sudo crm configure primitive exportfs_NW1 \ ocf:heartbeat:exportfs \ params directory="/srv/nfs/NW1" \ options="rw,no_root_squash,crossmnt" clientspec="*" fsid=1 wait_for_leasetime_on_stop=true op monitor interval="30s" sudo crm configure primitive vip_NW1_nfs IPaddr2 \ params ip=10.0.0.4 op monitor interval=10 timeout=20 sudo crm configure primitive nc_NW1_nfs azure-lb port=61000 \ op monitor timeout=20s interval=10 sudo crm configure group g-NW1_nfs \ fs_NW1_sapmnt exportfs_NW1 nc_NW1_nfs vip_NW1_nfs sudo crm configure order o-NW1_drbd_before_nfs inf: \ ms-drbd_NW1_nfs:promote g-NW1_nfs:start sudo crm configure colocation col-NW1_nfs_on_drbd inf: \ g-NW1_nfs ms-drbd_NW1_nfs:Master
[1] Ajouter les appareils drbd NFS pour le système SAP NW2 à la configuration de cluster
# Enable maintenance mode sudo crm configure property maintenance-mode=true sudo crm configure primitive drbd_NW2_nfs \ ocf:linbit:drbd \ params drbd_resource="NW2-nfs" \ op monitor interval="15" role="Master" \ op monitor interval="30" role="Slave" sudo crm configure ms ms-drbd_NW2_nfs drbd_NW2_nfs \ meta master-max="1" master-node-max="1" clone-max="2" \ clone-node-max="1" notify="true" interleave="true" sudo crm configure primitive fs_NW2_sapmnt \ ocf:heartbeat:Filesystem \ params device=/dev/drbd1 \ directory=/srv/nfs/NW2 \ fstype=xfs \ op monitor interval="10s" sudo crm configure primitive exportfs_NW2 \ ocf:heartbeat:exportfs \ params directory="/srv/nfs/NW2" \ options="rw,no_root_squash,crossmnt" clientspec="*" fsid=2 wait_for_leasetime_on_stop=true op monitor interval="30s" sudo crm configure primitive vip_NW2_nfs IPaddr2 \ params ip=10.0.0.5 op monitor interval=10 timeout=20 sudo crm configure primitive nc_NW2_nfs azure-lb port=61001 \ op monitor timeout=20s interval=10 sudo crm configure group g-NW2_nfs \ fs_NW2_sapmnt exportfs_NW2 nc_NW2_nfs vip_NW2_nfs sudo crm configure order o-NW2_drbd_before_nfs inf: \ ms-drbd_NW2_nfs:promote g-NW2_nfs:start sudo crm configure colocation col-NW2_nfs_on_drbd inf: \ g-NW2_nfs ms-drbd_NW2_nfs:Master
L’option
crossmnt
dans les ressources de clusterexportfs
est présente dans notre documentation pour la compatibilité descendante avec les anciennes versions de SLES.[1] Désactiver le mode de maintenance
sudo crm configure property maintenance-mode=false
Étapes suivantes
- Installer l’instance SAP ASCS et la base de données
- 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
- 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