Ce guide vous explique comment déployer et configurer un cluster à haute disponibilité (HA) SUSE Linux Enterprise Server (SLES) optimisé pour les performances pour un système SAP HANA pouvant évoluer à la hausse sur Google Cloud.
Ce guide comprend les étapes suivantes :
- Configurer un équilibreur de charge réseau passthrough interne pour réacheminer le trafic en cas de défaillance
- Configurer un cluster Pacemaker sur SLES pour gérer les systèmes SAP et d'autres ressources lors d'un basculement
Ce guide comprend également les étapes de configuration de la réplication du système SAP HANA, mais reportez-vous à la documentation SAP pour obtenir les instructions définitives.
Pour déployer un système SAP HANA sans cluster Linux à haute disponibilité ni hôte de nœud de secours, suivez le guide de déploiement de SAP HANA.
Pour configurer un cluster à haute disponibilité pour SAP HANA sur Red Hat Enterprise Linux (RHEL), consultez le guide de configuration d'un cluster à haute disponibilité pour un système SAP HANA pouvant évoluer à la hausse sur RHEL.
Ce guide est destiné aux utilisateurs avancés de SAP HANA qui connaissent bien les configurations Linux à haute disponibilité pour SAP HANA.
Système déployé dans ce guide
En suivant ce guide, vous allez déployer deux instances SAP HANA et configurer un cluster à haute disponibilité sur SLES. Chacune de ces instances SAP HANA va être déployée sur des VM Compute Engine situées dans des zones différentes, mais au sein de la même région. Ce guide ne traite pas de l'installation à haute disponibilité de SAP NetWeaver.
Le cluster déployé inclut les fonctions et fonctionnalités suivantes :
- Deux VM hôtes, chacune avec une instance de SAP HANA
- La réplication du système SAP HANA synchrone
- Le gestionnaire de ressources de cluster à haute disponibilité Pacemaker
- Un mécanisme de cloisonnement STONITH
- Le redémarrage automatique de l'instance ayant échoué en tant que nouvelle instance secondaire
Ce guide utilise les modèles Cloud Deployment Manager fournis par Google Cloud pour déployer les machines virtuelles (VM) Compute Engine et les instances SAP HANA, ce qui garantit que les VM et les systèmes de base SAP HANA répondent aux exigences de compatibilité de SAP et sont conformes aux bonnes pratiques actuelles.
SAP HANA Studio est utilisé dans ce guide pour tester la réplication du système SAP HANA. Si vous préférez, vous pouvez utiliser SAP HANA Cockpit. Pour plus d'informations sur l'installation de SAP HANA Studio, consultez les pages suivantes :
- Installer SAP HANA Studio sur une VM Compute Engine pour Windows
- Guide d'installation et de mise à jour de SAP HANA Studio
Prérequis
Avant de créer le cluster à haute disponibilité SAP HANA, assurez-vous que les conditions préalables suivantes sont remplies :
- Vous avez lu le guide de planification SAP HANA et le guide de planification de la haute disponibilité pour SAP HANA.
- Vous ou votre organisation disposez d'un compte Google Cloud et avez créé un projet pour le déploiement de SAP HANA. Pour en savoir plus sur la création de comptes et de projets Google Cloud, consultez la section Configurer votre compte Google dans le guide de déploiement de SAP HANA.
- Si vous souhaitez que votre charge de travail SAP s'exécute conformément aux exigences liées à la résidence des données, au contrôle des accès, au personnel d'assistance ou à la réglementation, vous devez créer le dossier Assured Workloads requis. Pour en savoir plus, consultez la page Contrôles de conformité et de souveraineté pour SAP sur Google Cloud.
Le support d'installation de SAP HANA se trouve dans un bucket Cloud Storage disponible dans votre projet et votre région de déploiement. Pour savoir comment importer le support d'installation de SAP HANA dans un bucket Cloud Storage, consultez la section relative au téléchargement de SAP HANA dans le Guide de déploiement de SAP HANA.
Si OS Login est activé dans les métadonnées de votre projet, vous devrez le désactiver temporairement jusqu'à la fin du déploiement. Pour le déploiement, cette procédure configure les clés SSH dans les métadonnées d'instance. Lorsque OS Login est activé, les configurations de clé SSH basées sur les métadonnées sont désactivées et le déploiement échoue. Une fois le déploiement terminé, vous pouvez réactiver OS Login.
Pour en savoir plus, consultez les pages suivantes :
Si vous utilisez un DNS interne de VPC, la valeur de la variable
vmDnsSetting
dans les métadonnées de votre projet doit êtreGlobalOnly
ouZonalPreferred
afin de permettre la résolution des noms de nœuds entre zones. La valeur par défaut devmDnsSetting
estZonalOnly
. Pour en savoir plus, consultez les pages suivantes :
Créer un réseau
Pour des raisons de sécurité, nous vous recommandons de créer un réseau, dont vous contrôlez les accès en ajoutant des règles de pare-feu ou toute autre méthode.
Si votre projet dispose d'un réseau VPC par défaut, ne l'utilisez pas. À la place, créez votre propre réseau VPC afin que les seules règles de pare-feu appliquées soient celles que vous créez explicitement.
Lors du déploiement, les instances de VM nécessitent généralement un accès à Internet pour télécharger l'agent Google Cloud pour SAP. Si vous utilisez l'une des images Linux certifiées SAP disponibles dans Google Cloud, l'instance de VM requiert également l'accès à Internet pour enregistrer la licence et accéder aux dépôts des fournisseurs d'OS. Une configuration comprenant une passerelle NAT et des tags réseau de VM permet aux VM cibles d'accéder à Internet même si elles ne possèdent pas d'adresses IP externes.
Pour configurer la mise en réseau, procédez comme suit :
Console
- Dans Google Cloud Console, accédez à la page Réseaux VPC.
- Cliquez sur Créer un réseau VPC.
- Saisissez un Nom pour le réseau.
Le nom doit respecter la convention d'attribution de noms. Les réseaux VPC utilisent la convention d'attribution de noms de Compute Engine.
- Dans le champ Mode de création du sous-réseau, sélectionnez Custom.
- Dans la section Nouveau sous-réseau, spécifiez les paramètres de configuration de sous-réseau suivants :
- Saisissez un nom pour le sous-réseau.
- Dans le champ Région, sélectionnez la région Compute Engine dans laquelle vous souhaitez créer le sous-réseau.
- Pour Type de pile IP, sélectionnez IPv4 (pile unique), puis saisissez une plage d'adresses IP au format CIDR, telle que
10.1.0.0/24
.Il s'agit de la plage IPv4 principale du sous-réseau. Si vous envisagez d'ajouter plusieurs sous-réseaux, attribuez à chacun d'eux des plages d'adresses IP CIDR qui ne se chevauchent pas dans le réseau. Notez que chaque sous-réseau et ses plages d'adresses IP internes sont mappés sur une seule région.
- Cliquez sur OK.
- Pour ajouter d'autres sous-réseaux, cliquez sur Ajouter un sous-réseau et répétez les étapes ci-dessus. Vous pouvez ajouter d'autres sous-réseaux au réseau après sa création.
- Cliquez sur Create (Créer).
gcloud
- Accédez à Cloud Shell.
- Pour créer un réseau en mode de sous-réseau personnalisé, exécutez la commande suivante :
gcloud compute networks create NETWORK_NAME --subnet-mode custom
Remplacez
NETWORK_NAME
par le nom du nouveau réseau. Le nom doit respecter la convention d'attribution de noms. Les réseaux VPC utilisent la convention de dénomination de Compute Engine.Spécifiez
--subnet-mode custom
pour éviter d'utiliser le mode automatique par défaut, qui crée automatiquement un sous-réseau dans chaque région Compute Engine. Pour en savoir plus, consultez la section Mode de création du sous-réseau. - Créez un sous-réseau, et spécifiez la région et la plage d'adresses IP :
gcloud compute networks subnets create SUBNETWORK_NAME \ --network NETWORK_NAME --region REGION --range RANGE
Remplacez les éléments suivants :
SUBNETWORK_NAME
: nom du nouveau sous-réseauNETWORK_NAME
: nom du réseau que vous avez créé à l'étape précédenteREGION
: région dans laquelle vous souhaitez créer le sous-réseauRANGE
: plage d'adresses IP spécifiée au format CIDR (par exemple,10.1.0.0/24
)Si vous envisagez d'ajouter plusieurs sous-réseaux, attribuez à chacun d'eux des plages d'adresses IP CIDR qui ne se chevauchent pas. Notez que chaque sous-réseau et ses plages d'adresses IP internes sont mappés sur une seule région.
- Si vous le souhaitez, répétez l'étape précédente et ajoutez des sous-réseaux.
Configurer une passerelle NAT
Si vous avez besoin de créer une ou plusieurs VM sans adresse IP publique, vous devez utiliser la traduction d'adresse réseau (NAT) pour permettre aux VM d'accéder à Internet. Utilisez Cloud NAT, un service géré distribué et défini par logiciel de Google Cloud, qui permet aux VM d'envoyer des paquets sortants vers Internet et de recevoir tous les paquets de réponses entrants établis correspondants. Vous pouvez également configurer une VM distincte en tant que passerelle NAT.
Pour créer une instance Cloud NAT pour votre projet, consultez la page Utiliser Cloud NAT.
Une fois que vous avez configuré Cloud NAT pour votre projet, vos instances de VM peuvent accéder en toute sécurité à Internet sans adresse IP publique.
Ajouter des règles de pare-feu
Par défaut, une règle de pare-feu implicite bloque les connexions entrantes provenant de l'extérieur de votre réseau VPC (Virtual Private Cloud, cloud privé virtuel). Pour autoriser les connexions entrantes, configurez une règle de pare-feu pour votre VM. Une fois qu'une connexion entrante est établie avec une VM, le trafic est autorisé dans les deux sens via cette connexion.
Vous pouvez également créer une règle de pare-feu pour autoriser l'accès externe à des ports spécifiés ou pour limiter l'accès entre plusieurs VM d'un même réseau. Si le type de réseau VPC default
est utilisé, d'autres règles par défaut s'appliquent également, telles que la règle default-allow-internal
, qui permet la connectivité entre les VM d'un même réseau sur tous les ports.
En fonction de la stratégie informatique applicable à votre environnement, vous devrez peut-être isoler votre hôte de base de données, ou en restreindre la connectivité, en créant des règles de pare-feu.
Selon votre scénario, vous pouvez créer des règles de pare-feu afin d'autoriser l'accès pour ce qui suit :
- Ports SAP par défaut répertoriés dans le tableau listant les ports TCP/IP de tous les produits SAP.
- Connexions à partir de votre ordinateur ou de votre environnement de réseau d'entreprise à votre instance de VM Compute Engine. Si vous ne savez pas quelle adresse IP utiliser, contactez l'administrateur réseau de votre entreprise.
- Communication entre VM sur le sous-réseau SAP HANA, y compris la communication entre les nœuds d'un système à évolutivité horizontale SAP HANA ou la communication entre le serveur de base de données et les serveurs d'applications dans une architecture à trois niveaux. Pour activer la communication entre VM, vous pouvez créer une règle de pare-feu autorisant le trafic provenant du sous-réseau.
Pour créer une règle de pare-feu, procédez comme suit :
Console
Dans la console Google Cloud, accédez à la page Pare-feu du réseau VPC.
En haut de la page, cliquez sur Créer une règle de pare-feu.
- Dans le champ Réseau, sélectionnez le réseau sur lequel se trouve votre VM.
- Dans le champ Cibles, spécifiez les ressources Google Cloud auxquelles cette règle s'applique. Par exemple, spécifiez Toutes les instances du réseau. Pour limiter la règle à des instances spécifiques sur Google Cloud, saisissez des tags dans le champ Tags cibles spécifiés.
- Dans le champ Filtre source, sélectionnez l'une des options suivantes :
- Plages IP pour autoriser le trafic entrant provenant d'adresses IP spécifiques. Indiquez la plage d'adresses IP dans le champ Plages d'adresses IP sources.
- Sous-réseaux pour autoriser le trafic entrant depuis un sous-réseau particulier. Spécifiez le nom du sous-réseau dans le champ Sous-réseaux qui s'affiche. Utilisez cette option pour autoriser l'accès entre plusieurs VM dans une configuration à trois niveaux ou évolutive.
- Dans la section Protocoles et ports, sélectionnez Protocoles et ports spécifiés, puis saisissez
tcp:PORT_NUMBER
.
Cliquez sur Créer pour créer la règle de pare-feu.
gcloud
Créez une règle de pare-feu à l'aide de la commande suivante :
$
gcloud compute firewall-rules create FIREWALL_NAME
--direction=INGRESS --priority=1000 \
--network=NETWORK_NAME --action=ALLOW --rules=PROTOCOL:PORT \
--source-ranges IP_RANGE --target-tags=NETWORK_TAGS
Déployer les VM et SAP HANA
Avant de commencer à configurer le cluster à haute disponibilité, vous devez définir et déployer les instances de VM et les systèmes SAP HANA qui servent de nœuds principal et secondaire dans le cluster à haute disponibilité.
Pour définir et déployer les systèmes, utilisez le même modèle Cloud Deployment Manager que celui qui a servi à déployer un système SAP HANA dans le guide de déploiement de SAP HANA.
Toutefois, pour déployer deux systèmes au lieu d'un, vous devez ajouter la définition du second système au fichier de configuration en copiant et en collant la définition du premier système. Après avoir créé la seconde définition, vous devez modifier les noms des ressources et des instances dans celle-ci. Pour vous protéger contre une défaillance de zone, spécifiez une zone différente de la même région. Toutes les autres propriétés des deux définitions conservent la même valeur.
Une fois les systèmes SAP HANA déployés, définissez et configurez le cluster à haute disponibilité.
Les instructions suivantes utilisent Cloud Shell, mais sont généralement applicables à Google Cloud CLI.
Vérifiez que vos quotas actuels pour les ressources, telles que les disques persistants et les processeurs, sont suffisants pour les systèmes SAP HANA que vous allez installer. Si vos quotas sont insuffisants, le déploiement échoue. Pour connaître les exigences en matière de quotas de SAP HANA, consultez la section Remarques relatives aux tarifs et aux quotas applicables à SAP HANA.
Ouvrez Cloud Shell ou, si vous avez installé gcloud CLI sur votre poste de travail local, ouvrez un terminal.
Téléchargez dans votre répertoire de travail le modèle de fichier de configuration
template.yaml
pour le cluster SAP HANA à haute disponibilité. Pour ce faire, saisissez la commande suivante dans Cloud Shell ou gcloud CLI :wget https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/template.yaml
Renommez éventuellement le fichier
template.yaml
pour identifier la configuration qu'il définit.Ouvrez le fichier
template.yaml
dans l'éditeur de code Cloud Shell ou, si vous utilisez gcloud CLI, dans l'éditeur de texte de votre choix.Pour ce faire, cliquez sur l'icône en forme de crayon située dans l'angle supérieur droit de la fenêtre du terminal Cloud Shell.
Dans le fichier
template.yaml
, terminez la définition du système SAP HANA principal. Spécifiez les valeurs des propriétés en remplaçant les crochets et leur contenu par les valeurs de votre installation. Ces propriétés sont décrites dans le tableau ci-dessous.Pour créer des instances de VM sans installer SAP HANA, supprimez ou commentez toutes les lignes commençant par
sap_hana_
.Valeur Type de données Description type Chaîne Spécifie l'emplacement, le type et la version du modèle Deployment Manager à utiliser lors du déploiement.
Le fichier YAML comprend deux spécifications
type
, dont l'une est laissée en commentaire. La spécificationtype
qui est active par défaut spécifie la version du modèle en tant quelatest
. La spécificationtype
qui est laissée en commentaire spécifie une version de modèle spécifique avec un horodatage.Si tous vos déploiements doivent utiliser la même version de modèle, utilisez la spécification
type
qui inclut l'horodatage.instanceName
Chaîne Nom de l'instance de VM en cours de définition. Spécifiez des noms différents dans les définitions des VM principale et secondaire. Ces noms ne doivent contenir que des lettres minuscules, des chiffres ou des traits d'union. instanceType
Chaîne Type de machine virtuelle Compute Engine nécessaire à l'exécution de SAP HANA. Si vous avez besoin d'un type de VM personnalisé, spécifiez un type de VM prédéfini avec un nombre de processeurs virtuels le plus proche possible de la quantité dont vous avez besoin tout en étant légèrement supérieur. Une fois le déploiement terminé, modifiez le nombre de processeurs virtuels et la quantité de mémoire. zone
String Zone Google Cloud dans laquelle déployer l'instance de VM que vous définissez. Spécifiez des zones différentes de la même région pour les définitions HANA principales et secondaires. Ces zones doivent se trouver dans la même région que celle que vous avez sélectionnée pour votre sous-réseau. subnetwork
Chaîne Nom du sous-réseau que vous avez créé précédemment. Si vous procédez au déploiement sur un VPC partagé, spécifiez cette valeur en tant que [SHAREDVPC_PROJECT]/[SUBNETWORK]
. Exemple :myproject/network1
linuxImage
Chaîne Nom de la famille d'images ou de l'image du système d'exploitation Linux que vous utilisez avec SAP HANA. Pour spécifier une famille d'images, ajoutez le préfixe family/
au nom de la famille. Exemple :family/sles-15-sp1-sap
Pour spécifier une image spécifique, indiquez uniquement le nom de l'image. Pour obtenir la liste des images et des familles disponibles, consultez la page Images dans la console Google Cloud.linuxImageProject
String Le projet Google Cloud qui contient l'image que vous allez utiliser. Ce projet peut être votre propre projet ou un projet d'image Google Cloud, tel que suse-sap-cloud
. Pour en savoir plus sur les projets d'image Google Cloud, consultez la page Images dans la documentation Compute Engine.sap_hana_deployment_bucket
String Nom du bucket Google Cloud Storage de votre projet contenant les fichiers d'installation et de révision de SAP HANA que vous avez importés précédemment. Tous les fichiers de révision de mise à niveau du bucket sont appliqués à SAP HANA au cours du processus de déploiement. sap_hana_sid
Chaîne ID système (SID) SAP HANA. L'ID doit comporter trois caractères alphanumériques et commencer par une lettre. Les lettres doivent être saisies en majuscules. sap_hana_instance_number
Entier Numéro d'instance (0 à 99) du système SAP HANA. La valeur par défaut est 0. sap_hana_sidadm_password
Chaîne Mot de passe de l'administrateur du système d'exploitation (OS). Les mots de passe doivent comporter au moins huit caractères et inclure au moins une lettre majuscule, une lettre minuscule et un chiffre. sap_hana_system_password
Chaîne Mot de passe du super-utilisateur de la base de données. Les mots de passe doivent comporter au moins huit caractères et inclure au moins une lettre majuscule, une lettre minuscule et un chiffre. sap_hana_sidadm_uid
Integer La valeur par défaut pour l'ID utilisateur SID_LCadm
est900
afin d'éviter les conflits entre les groupes créés par les utilisateurs et SAP HANA. Vous pouvez modifier cette valeur si nécessaire.sap_hana_sapsys_gid
Entier L'ID de groupe par défaut pour sapsys est 79
. En spécifiant une valeur supérieure, vous pouvez remplacer cette valeur selon vos besoins.sap_hana_scaleout_nodes
Entier Spécifiez 0
. Ces instructions sont destinées uniquement aux systèmes avec scaling à la hausse SAP HANA.networkTag
Chaîne Tag réseau qui représente votre instance de VM à des fins de routage ou d'établissement/application de règles de pare-feu. Si vous spécifiez publicIP: No
et ne spécifiez pas de tag réseau, veillez à fournir un autre moyen d'accès à Internet.nic_type
String Facultatif, mais recommandé si disponible pour la machine cible et la version de l'OS. Spécifie l'interface réseau à utiliser avec l'instance de VM. Vous pouvez spécifier la valeur GVNIC
ouVIRTIO_NET
. Pour utiliser une carte d'interface réseau virtuelle Google (gVNIC), vous devez spécifier une image de l'OS compatible avec gVNIC comme valeur de la propriétélinuxImage
. Pour obtenir la liste des images de l'OS, consultez la section Détails des systèmes d'exploitation.Si vous ne spécifiez pas de valeur pour cette propriété, l'interface réseau est automatiquement sélectionnée en fonction du type de machine que vous spécifiez pour la propriété
Cet argument est disponible dans les versionsinstanceType
.202302060649
du modèle Deployment Manager ou ultérieures.publicIP
Booléen Facultatif. Détermine si une adresse IP publique est ajoutée à votre instance de VM. La valeur par défaut est Yes
.serviceAccount
Chaîne Facultatif. Spécifie un compte de service destiné à être utilisé par les VM hôtes et par les programmes exécutés sur celles-ci. Spécifiez l'adresse e-mail du compte de service. Par exemple, svc-acct-name@project-id.iam.gserviceaccount.com. Par défaut, le compte de service Compute Engine par défaut est utilisé. Pour en savoir plus, consultez la page Gestion de l'authentification et des accès pour les programmes SAP sur Google Cloud. Créez la définition du système SAP HANA secondaire en copiant la définition du système SAP HANA principal et en collant la copie après la définition principale du système SAP HANA. Reportez-vous à l'exemple qui suit ces étapes.
Dans la définition du système SAP HANA secondaire, spécifiez des valeurs différentes de celles spécifiées dans la définition principale du système SAP HANA pour les propriétés suivantes :
name
instanceName
zone
Créez les instances :
gcloud deployment-manager deployments create DEPLOYMENT_NAME --config TEMPLATE_NAME.yaml
La commande ci-dessus appelle Deployment Manager, lequel déploie les VM, télécharge le logiciel SAP HANA à partir de votre bucket de stockage, puis l'installe, conformément aux spécifications de votre fichier
template.yaml
.Le processus de déploiement comprend deux étapes. Tout d'abord, Deployment Manager écrit son état dans la console. Ensuite, les scripts de déploiement écrivent leur état dans Cloud Logging.
Exemple de fichier de configuration template.yaml
complet
L'exemple suivant montre un fichier de configuration template.yaml
terminé qui déploie deux instances de VM avec un système SAP HANA installé.
Le fichier contient les définitions des deux ressources à déployer : sap_hana_primary
et sap_hana_secondary
. Chaque définition de ressource contient les définitions d'une VM et d'une instance SAP HANA.
La définition de la ressource sap_hana_secondary
a été créée en copiant et en collant la première définition, puis en modifiant les valeurs des propriétés name
, instanceName
et zone
. Les valeurs de toutes les autres propriétés dans les deux définitions de ressources sont identiques.
Les propriétés networkTag
, serviceAccount
, sap_hana_sidadm_uid
et sap_hana_sapsys_gid
proviennent de la section "Options avancées" du modèle de fichier de configuration. Les propriétés sap_hana_sidadm_uid
et sap_hana_sapsys_gid
sont incluses pour afficher leurs valeurs par défaut, qui sont utilisées car les propriétés sont commentées.
resources: - name: sap_hana_primary type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.py # # By default, this configuration file uses the latest release of the deployment # scripts for SAP on Google Cloud. To fix your deployments to a specific release # of the scripts, comment out the type property above and uncomment the type property below. # # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/yyyymmddhhmm/dm-templates/sap_hana/sap_hana.py # properties: instanceName: hana-ha-vm-1 instanceType: n2-highmem-32 zone: us-central1-a subnetwork: example-subnet-us-central1 linuxImage: family/sles-15-sp1-sap linuxImageProject: suse-sap-cloud sap_hana_deployment_bucket: hana2-sp4-rev46 sap_hana_sid: HA1 sap_hana_instance_number: 22 sap_hana_sidadm_password: Tempa55word sap_hana_system_password: Tempa55word sap_hana_scaleout_nodes: 0 networkTag: cluster-ntwk-tag serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com # sap_hana_sidadm_uid: 900 # sap_hana_sapsys_gid: 79 - name: sap_hana_secondary type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/latest/dm-templates/sap_hana/sap_hana.py # # By default, this configuration file uses the latest release of the deployment # scripts for SAP on Google Cloud. To fix your deployments to a specific release # of the scripts, comment out the type property above and uncomment the type property below. # # type: https://storage.googleapis.com/cloudsapdeploy/deploymentmanager/yyyymmddhhmm/dm-templates/sap_hana/sap_hana.py # properties: instanceName: hana-ha-vm-2 instanceType: n2-highmem-32 zone: us-central1-c subnetwork: example-subnet-us-central1 linuxImage: family/sles-15-sp1-sap linuxImageProject: suse-sap-cloud sap_hana_deployment_bucket: hana2-sp4-rev46 sap_hana_sid: HA1 sap_hana_instance_number: 22 sap_hana_sidadm_password: Google123 sap_hana_system_password: Google123 sap_hana_scaleout_nodes: 0 networkTag: cluster-ntwk-tag serviceAccount: limited-roles@example-project-123456.iam.gserviceaccount.com # sap_hana_sidadm_uid: 900 # sap_hana_sapsys_gid: 79
Créer des règles de pare-feu autorisant l'accès aux VM hôtes
Si vous ne l'avez pas déjà fait, créez des règles de pare-feu autorisant l'accès à chaque VM hôte à partir des sources suivantes :
- À des fins de configuration, votre poste de travail local, un hôte bastion ou un serveur de saut
- Pour l'accès entre les nœuds du cluster, les autres VM hôtes dans le cluster à haute disponibilité
Lorsque vous créez des règles de pare-feu VPC, vous spécifiez les tags réseau que vous avez définis dans le fichier de configuration template.yaml
pour désigner vos VM hôtes comme cibles de la règle.
Pour vérifier le déploiement, définissez une règle autorisant les connexions SSH sur le port 22 à partir d'un hôte bastion ou de votre poste de travail local.
Pour l'accès entre les nœuds du cluster, ajoutez une règle de pare-feu qui autorise tous les types de connexion sur n'importe quel port d'autres VM du même sous-réseau.
Assurez-vous que les règles de pare-feu pour la vérification du déploiement et la communication au sein du cluster sont créées avant de passer à la section suivante. Pour obtenir des instructions, consultez la section Ajouter des règles de pare-feu.
Vérifier le déploiement des VM et de SAP HANA
Pour vérifier le déploiement, vérifiez les journaux de déploiement dans Cloud Logging, ainsi que les disques et les services sur les VM des hôtes principaux et secondaires.
Dans la console Google Cloud, ouvrez Cloud Logging pour surveiller la progression de l'installation et rechercher les erreurs.
Filtrez les journaux :
Logs Explorer
Sur la page Explorateur de journaux, accédez au volet Requête.
Dans le menu déroulant Ressource, sélectionnez Global, puis cliquez sur Ajouter.
Si l'option Global n'apparaît pas, saisissez la requête suivante dans l'éditeur de requête :
resource.type="global" "Deployment"
Cliquez sur Exécuter la requête.
Ancienne visionneuse de journaux
- Sur la page Ancienne visionneuse de journaux, dans le menu de sélection de base, sélectionnez Global comme ressource de journalisation.
Analysez les journaux filtrés :
- Si
"--- Finished"
s'affiche, le traitement du déploiement est terminé, et vous pouvez passer à l'étape suivante. Si vous rencontrez une erreur de quota :
Sur la page Quotas de IAM & Admin, augmentez les quotas qui ne répondent pas aux exigences de SAP HANA décrites dans le guide de planification SAP HANA.
Sur la page Déploiements de Deployment Manager, supprimez le déploiement pour nettoyer les VM et les disques persistants de l'installation ayant échoué.
Réexécutez le déploiement.
- Si
Vérifier la configuration des VM et de SAP HANA
Une fois le système SAP HANA déployé sans erreur, connectez-vous à chaque VM à l'aide du protocole SSH. Sur la page VM instances (Instances de VM) de Compute Engine, cliquez sur le bouton SSH de votre instance de VM ou utilisez la méthode SSH de votre choix.
Connectez-vous en tant qu'utilisateur racine.
$
sudo su -À l'invite de commande, saisissez
df -h
. Sur chaque VM, assurez-vous que les répertoires/hana
s'affichent, par exemple/hana/data
.Filesystem Size Used Avail Use% Mounted on /dev/sda2 30G 4.0G 26G 14% / devtmpfs 126G 0 126G 0% /dev tmpfs 126G 0 126G 0% /dev/shm tmpfs 126G 17M 126G 1% /run tmpfs 126G 0 126G 0% /sys/fs/cgroup /dev/sda1 200M 9.7M 191M 5% /boot/efi /dev/mapper/vg_hana-shared 251G 49G 203G 20% /hana/shared /dev/mapper/vg_hana-sap 32G 240M 32G 1% /usr/sap /dev/mapper/vg_hana-data 426G 7.0G 419G 2% /hana/data /dev/mapper/vg_hana-log 125G 4.2G 121G 4% /hana/log /dev/mapper/vg_hanabackup-backup 512G 33M 512G 1% /hanabackup tmpfs 26G 0 26G 0% /run/user/900 tmpfs 26G 0 26G 0% /run/user/899 tmpfs 26G 0 26G 0% /run/user/1000
Connectez-vous en tant qu'administrateur SAP en remplaçant
SID_LC
dans la commande suivante par l'ID système que vous avez spécifié dans le modèle de fichier de configuration. Utilisez des minuscules pour toutes les lettres.#
su - SID_LCadmAssurez-vous que les services SAP HANA, tels que
hdbnameserver
,hdbindexserver
et autres services, s'exécutent sur l'instance en saisissant la commande suivante :>
HDB infoSi vous utilisez RHEL pour SAP 9.0 ou une version ultérieure, assurez-vous que les packages
chkconfig
etcompat-openssl11
sont installés sur votre instance de VM.Pour en savoir plus, consultez la note SAP 3108316 – Red Hat Enterprise Linux 9.x : installation et configuration.
Vérifier l'installation de l'agent Google Cloud pour SAP
Après avoir déployé une VM et installé le système SAP, vérifiez que l'agent Google Cloud pour SAP fonctionne correctement.
Vérifier que l'agent Google Cloud pour SAP est en cours d'exécution
Pour vérifier que l'agent est en cours d'exécution, procédez comme suit :
Établissez une connexion SSH avec votre instance de VM hôte.
Exécutez la commande ci-dessous :
systemctl status google-cloud-sap-agent
Si l'agent fonctionne correctement, la sortie contient
active (running)
. Exemple :google-cloud-sap-agent.service - Google Cloud Agent for SAP Loaded: loaded (/usr/lib/systemd/system/google-cloud-sap-agent.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2022-12-02 07:21:42 UTC; 4 days ago Main PID: 1337673 (google-cloud-sa) Tasks: 9 (limit: 100427) Memory: 22.4 M (max: 1.0G limit: 1.0G) CGroup: /system.slice/google-cloud-sap-agent.service └─1337673 /usr/bin/google-cloud-sap-agent
.
Si l'agent n'est pas en cours d'exécution, redémarrez-le.
Vérifier que l'agent hôte SAP reçoit les métriques
Pour vérifier que les métriques d'infrastructure sont collectées par l'agent Google Cloud pour SAP et envoyées correctement à l'agent hôte SAP, procédez comme suit :
- Dans votre système SAP, saisissez la transaction
ST06
. Dans le volet de synthèse, vérifiez la disponibilité et le contenu des champs suivants pour vous assurer de la configuration de façon correcte et complète de l'infrastructure de surveillance SAP et Google :
- Fournisseur cloud :
Google Cloud Platform
- Accès à la surveillance améliorée :
TRUE
- Détails de la surveillance améliorée :
ACTIVE
- Fournisseur cloud :
Configurer la surveillance pour SAP HANA
Vous pouvez éventuellement surveiller vos instances SAP HANA à l'aide de l'agent Google Cloud pour SAP. À partir de la version 2.0, vous pouvez configurer l'agent de sorte qu'il collecte les métriques de surveillance SAP HANA et les envoie à Cloud Monitoring. Cloud Monitoring vous permet de créer des tableaux de bord pour visualiser ces métriques, de configurer des alertes en fonction de seuils de métriques, etc.
Pour en savoir plus sur la collecte des métriques de surveillance SAP HANA à l'aide de l'agent Google Cloud pour SAP, consultez Collecte des métriques de surveillance SAP HANA.
Désactiver le démarrage automatique de SAP HANA
Pour chaque instance SAP HANA du cluster, assurez-vous que le démarrage automatique de SAP HANA est désactivé. Pour les basculements, Pacemaker gère le démarrage et l'arrêt des instances SAP HANA dans un cluster.
Sur chaque hôte, en tant que SID_LCadm, arrêtez SAP HANA :
>
HDB stopSur chaque hôte, ouvrez le profil SAP HANA à l'aide d'un éditeur, tel que vi :
vi /usr/sap/SID/SYS/profile/SID_HDBINST_NUM_HOST_NAME
Définissez la propriété
Autostart
sur0
:Autostart=0
Enregistrez le profil.
Sur chaque hôte, en tant que SID_LCadm, démarrez SAP HANA :
>
HDB start
Activer le redémarrage rapide de SAP HANA
Google Cloud recommande fortement d'activer le redémarrage rapide SAP HANA pour chaque instance de SAP HANA, en particulier pour les instances de grande capacité. Le redémarrage rapide de SAP HANA réduit le temps de redémarrage en cas d'arrêt de SAP HANA, mais le système d'exploitation reste en cours d'exécution.
Comme configuré par les scripts d'automatisation fournis par Google Cloud, les paramètres du système d'exploitation et du noyau sont déjà compatibles avec le redémarrage rapide de SAP HANA.
Vous devez définir le système de fichiers tmpfs
et configurer SAP HANA.
Pour définir le système de fichiers tmpfs
et configurer SAP HANA, vous pouvez suivre les étapes manuelles ou utiliser le script d'automatisation fourni par Google Cloud pour activer le redémarrage rapide de SAP HANA. Pour en savoir plus, consultez les pages suivantes :
- Étapes manuelles : Activer le redémarrage rapide de SAP HANA
- Étapes automatisées : Activer le redémarrage rapide de SAP HANA
Pour obtenir des instructions faisant autorité sur la fonction de redémarrage rapide SAP HANA, consultez la documentation sur les options de redémarrage rapide de SAP HANA.
Étapes manuelles
Configurer le système de fichiers tmpfs
Une fois les VM hôtes et les systèmes SAP HANA de base déployés, vous devez créer et installer des répertoires pour les nœuds NUMA du système de fichiers tmpfs
.
Afficher la topologie NUMA de votre VM
Pour pouvoir mapper le système de fichiers tmpfs
requis, vous devez connaître la quantité de nœuds NUMA dont dispose votre VM. Pour afficher les nœuds NUMA disponibles sur une VM Compute Engine, saisissez la commande suivante :
lscpu | grep NUMA
Par exemple, un type de VM m2-ultramem-208
comporte quatre nœuds NUMA, numérotés de 0 à 3, comme illustré dans l'exemple suivant :
NUMA node(s): 4 NUMA node0 CPU(s): 0-25,104-129 NUMA node1 CPU(s): 26-51,130-155 NUMA node2 CPU(s): 52-77,156-181 NUMA node3 CPU(s): 78-103,182-207
Créer les répertoires de nœuds NUMA
Créez un répertoire pour chaque nœud NUMA de votre VM et définissez les autorisations.
Par exemple, pour quatre nœuds NUMA numérotés de 0 à 3 :
mkdir -pv /hana/tmpfs{0..3}/SID chown -R SID_LCadm:sapsys /hana/tmpfs*/SID chmod 777 -R /hana/tmpfs*/SID
Installer les répertoires de nœuds NUMA dans tmpfs
Montez les répertoires du système de fichiers tmpfs
et spécifiez une préférence de nœud NUMA pour chacun avec mpol=prefer
:
SID : spécifiez le SID en majuscules.
mount tmpfsSID0 -t tmpfs -o mpol=prefer:0 /hana/tmpfs0/SID mount tmpfsSID1 -t tmpfs -o mpol=prefer:1 /hana/tmpfs1/SID mount tmpfsSID2 -t tmpfs -o mpol=prefer:2 /hana/tmpfs2/SID mount tmpfsSID3 -t tmpfs -o mpol=prefer:3 /hana/tmpfs3/SID
Mettre à jour /etc/fstab
Pour vous assurer que les points d'installation sont disponibles après un redémarrage du système d'exploitation, ajoutez des entrées dans la table du système de fichiers, /etc/fstab
:
tmpfsSID0 /hana/tmpfs0/SID tmpfs rw,relatime,mpol=prefer:0 tmpfsSID1 /hana/tmpfs1/SID tmpfs rw,relatime,mpol=prefer:1 tmpfsSID1 /hana/tmpfs2/SID tmpfs rw,relatime,mpol=prefer:2 tmpfsSID1 /hana/tmpfs3/SID tmpfs rw,relatime,mpol=prefer:3
Facultatif : définir des limites à l'utilisation de la mémoire
Le système de fichiers tmpfs
peut augmenter ou diminuer de manière dynamique.
Pour limiter la mémoire utilisée par le système de fichiers tmpfs
, vous pouvez définir une limite de taille pour un volume de nœuds NUMA en utilisant l'option size
.
Exemple :
mount tmpfsSID0 -t tmpfs -o mpol=prefer:0,size=250G /hana/tmpfs0/SID
Vous pouvez également limiter l'utilisation globale de la mémoire tmpfs
pour tous les nœuds NUMA d'une instance SAP HANA donnée et d'un nœud de serveur donné en définissant le paramètre persistent_memory_global_allocation_limit
dans la section [memorymanager]
du fichier global.ini
.
Configuration de SAP HANA pour le redémarrage rapide
Pour configurer SAP HANA pour le redémarrage rapide, mettez à jour le fichier global.ini
et spécifiez les tables à stocker dans la mémoire persistante.
Mettre à jour la section [persistence]
du fichier global.ini
Configurez la section [persistence]
du fichier SAP HANA global.ini
de manière à référencer les emplacements tmpfs
. Séparez chaque emplacement tmpfs
par un point-virgule :
[persistence] basepath_datavolumes = /hana/data basepath_logvolumes = /hana/log basepath_persistent_memory_volumes = /hana/tmpfs0/SID;/hana/tmpfs1/SID;/hana/tmpfs2/SID;/hana/tmpfs3/SID
L'exemple précédent spécifie quatre volumes de mémoire pour quatre nœuds NUMA, ce qui correspond à m2-ultramem-208
. Si vous l'exécutez sur m2-ultramem-416
, vous devez configurer huit volumes de mémoire (de 0 à 7).
Redémarrez SAP HANA après avoir modifié le fichier global.ini
.
SAP HANA peut désormais utiliser l'emplacement tmpfs
comme espace de mémoire persistant.
Spécifier les tables à stocker en mémoire persistante
Spécifiez des tables ou partitions de colonne spécifiques à stocker en mémoire persistante.
Par exemple, pour activer la mémoire persistante pour une table existante, exécutez la requête SQL :
ALTER TABLE exampletable persistent memory ON immediate CASCADE
Pour modifier la valeur par défaut des nouvelles tables, ajoutez le paramètre table_default
dans le fichier indexserver.ini
. Exemple :
[persistent_memory] table_default = ON
Pour en savoir plus sur le contrôle des colonnes et des tables ainsi que sur les vues de surveillance qui fournissent des informations détaillées, consultez la page Mémoire persistante SAP HANA.
Étapes automatisées
Le script d'automatisation fourni par Google Cloud pour activer le redémarrage rapide de SAP HANA apporte des modifications aux répertoires /hana/tmpfs*
, au fichier /etc/fstab
et à la configuration de SAP HANA. Lorsque vous exécuterez le script, vous devrez peut-être effectuer des étapes supplémentaires selon qu'il s'agit du déploiement initial de votre système SAP HANA ou que vous redimensionnez votre machine sur une autre taille NUMA.
Pour le déploiement initial de votre système SAP HANA ou le redimensionnement de la machine pour augmenter le nombre de nœuds NUMA, assurez-vous que SAP HANA est en cours d'exécution pendant l'exécution du script d'automatisation fourni par Google Cloud pour activer le redémarrage rapide de SAP HANA.
Lorsque vous redimensionnez votre machine pour réduire le nombre de nœuds NUMA, assurez-vous que SAP HANA est arrêté pendant l'exécution du script d'automatisation fourni par Google Cloud pour permettre le redémarrage rapide de SAP HANA. Une fois le script exécuté, vous devez mettre à jour manuellement la configuration SAP HANA pour terminer la configuration du redémarrage rapide de SAP HANA. Pour en savoir plus, consultez la section Configuration de SAP HANA pour le redémarrage rapide.
Pour activer le redémarrage rapide de SAP HANA, procédez comme suit :
Établissez une connexion SSH avec votre VM hôte.
Passez en mode root :
sudo su -
Téléchargez le script
sap_lib_hdbfr.sh
:wget https://storage.googleapis.com/cloudsapdeploy/terraform/latest/terraform/lib/sap_lib_hdbfr.sh
Rendez le fichier exécutable :
chmod +x sap_lib_hdbfr.sh
Vérifiez que le script ne comporte aucune erreur :
vi sap_lib_hdbfr.sh ./sap_lib_hdbfr.sh -help
Si la commande renvoie une erreur, contactez le Cloud Customer Care. Pour en savoir plus sur la procédure à suivre pour contacter le service client, consultez la page Obtenir de l'aide concernant SAP sur Google Cloud.
Exécutez le script après avoir remplacé l'ID système (SID) et le mot de passe SAP HANA de l'utilisateur système de la base de données SAP HANA. Pour fournir le mot de passe en toute sécurité, nous vous recommandons d'utiliser un secret dans Secret Manager.
Exécutez le script en utilisant le nom d'un secret dans Secret Manager. Ce secret doit exister dans le projet Google Cloud qui contient votre instance de VM hôte.
sudo ./sap_lib_hdbfr.sh -h 'SID' -s SECRET_NAME
Remplacez les éléments suivants :
SID
: spécifiez le SID en majuscules. Par exemple,AHA
.SECRET_NAME
: spécifiez le nom du secret correspondant au mot de passe de l'utilisateur système de la base de données SAP HANA. Ce secret doit exister dans le projet Google Cloud qui contient votre instance de VM hôte.
Vous pouvez également exécuter le script en utilisant un mot de passe en texte brut. Une fois le redémarrage rapide de SAP HANA activé, veillez à modifier votre mot de passe. L'utilisation d'un mot de passe en texte brut n'est pas recommandée, car celui-ci serait enregistré dans l'historique de ligne de commande de votre VM.
sudo ./sap_lib_hdbfr.sh -h 'SID' -p 'PASSWORD'
Remplacez les éléments suivants :
SID
: spécifiez le SID en majuscules. Par exemple,AHA
.PASSWORD
: spécifiez le mot de passe de l'utilisateur système de la base de données SAP HANA.
Dans le cas d'une exécution initiale réussie, vous devez obtenir une sortie semblable à celle-ci :
INFO - Script is running in standalone mode ls: cannot access '/hana/tmpfs*': No such file or directory INFO - Setting up HANA Fast Restart for system 'TST/00'. INFO - Number of NUMA nodes is 2 INFO - Number of directories /hana/tmpfs* is 0 INFO - HANA version 2.57 INFO - No directories /hana/tmpfs* exist. Assuming initial setup. INFO - Creating 2 directories /hana/tmpfs* and mounting them INFO - Adding /hana/tmpfs* entries to /etc/fstab. Copy is in /etc/fstab.20220625_030839 INFO - Updating the HANA configuration. INFO - Running command: select * from dummy DUMMY "X" 1 row selected (overall time 4124 usec; server time 130 usec) INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistence', 'basepath_persistent_memory_volumes') = '/hana/tmpfs0/TST;/hana/tmpfs1/TST;' 0 rows affected (overall time 3570 usec; server time 2239 usec) INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM') SET ('persistent_memory', 'table_unload_action') = 'retain'; 0 rows affected (overall time 4308 usec; server time 2441 usec) INFO - Running command: ALTER SYSTEM ALTER CONFIGURATION ('indexserver.ini', 'SYSTEM') SET ('persistent_memory', 'table_default') = 'ON'; 0 rows affected (overall time 3422 usec; server time 2152 usec)
Configurer les clés SSH sur les VM principale et secondaire
Les clés du magasin sécurisé SAP HANA (SSFS) doivent être synchronisées entre les hôtes du cluster à haute disponibilité. Pour simplifier la synchronisation et autoriser la copie de fichiers tels que les sauvegardes entre les hôtes du cluster à haute disponibilité, ces instructions vous permettent de créer des connexions SSH racine entre les deux hôtes.
Votre organisation dispose probablement de consignes régissant les communications réseau internes. Si nécessaire, une fois le déploiement terminé, vous pouvez supprimer les métadonnées des VM et les clés du répertoire authorized_keys
.
Si la configuration de connexions SSH directes ne respecte pas les consignes de votre organisation, vous pouvez synchroniser les clés SSFS et transférer des fichiers à l'aide d'autres méthodes, par exemple :
- Transférez des fichiers plus petits via votre poste de travail local à l'aide des options de menu Importer un fichier et Télécharger un fichier de Cloud Shell. Consultez la page Gérer des fichiers avec Cloud Shell.
- Échangez des fichiers à l'aide d'un bucket Google Cloud Storage. Consultez la page Travailler avec des objets dans la documentation Cloud Storage.
- Utilisez l'agent Backint de Cloud Storage pour SAP HANA afin de sauvegarder et de restaurer des bases de données HANA. Consultez la section Agent Backint de Cloud Storage pour SAP HANA.
- Utilisez une solution de stockage de fichiers telle que Filestore ou NetApp Cloud Volumes Service pour créer un dossier partagé. Consultez la section Options de serveur de fichiers.
Pour activer les connexions SSH entre les instances principale et secondaire, procédez comme indiqué ci-dessous.
Sur la VM hôte principale :
Connectez-vous en SSH à la VM.
Passez en mode root :
$
sudo su -Générez une clé SSH en mode root.
#
ssh-keygenMettez à jour les métadonnées de la VM principale avec les informations sur la clé SSH de la VM secondaire.
#
gcloud compute instances add-metadata secondary-host-name \ --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" --zone secondary-zoneAutorisez la VM principale sur elle-même.
#
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
Sur la VM hôte secondaire :
Connectez-vous en SSH à la VM.
Passez en mode root :
$
sudo su -Générez une clé SSH en mode root.
#
ssh-keygenMettez à jour les métadonnées de la VM secondaire avec les informations sur la clé SSH de la VM principale.
#
gcloud compute instances add-metadata primary-host-name \ --metadata "ssh-keys=$(whoami):$(cat ~/.ssh/id_rsa.pub)" --zone primary-zoneAutorisez la VM secondaire sur elle-même.
#
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keysAfin de vérifier que les clés SSH sont configurées correctement, ouvrez une connexion SSH depuis le système secondaire vers le système principal.
#
ssh primary-host-name
Sur la VM hôte principale, en mode root, confirmez la connexion en ouvrant une connexion SSH vers la VM hôte secondaire :
#
ssh secondary-host-name
Créer un utilisateur de base de données SAP HANA pour surveiller l'état du cluster
Sur l'hôte principal, en tant que
SID_LCadm
, connectez-vous au terminal interactif de la base de données SAP HANA :>
hdbsql -u system -p "system-password" -i inst_numDans le terminal interactif, créez l'utilisateur de base de données
slehasync
:=>
CREATE USER slehasync PASSWORD "hdb-user-password";=>
GRANT CATALOG READ TO slehasync;=>
GRANT MONITOR ADMIN TO slehasync;=>
ALTER USER slehasync DISABLE PASSWORD LIFETIME;En tant que
SID_LCadm
, définissez la clé utilisateurSLEHALOC
dans le magasin d'utilisateurs sécurisé de SAP HANA (hdbuserstore
) :>
PATH="$PATH:/usr/sap/SID/HDBinst_num/exe">
hdbuserstore SET SLEHALOC localhost:3inst_num15 slehasync hdb-user-password
Sauvegarder les bases de données
Créez des sauvegardes de vos bases de données afin de lancer la journalisation des bases de données pour la réplication du système SAP HANA et créer un point de récupération.
Si vous avez plusieurs bases de données locataires dans une configuration MDC, sauvegardez chacune de ces bases de données.
Le modèle Deployment Manager utilise /hanabackup/data/SID comme répertoire de sauvegarde par défaut.
Pour créer des sauvegardes de nouvelles bases de données SAP HANA, procédez comme suit :
Sur l'hôte principal, passez en
SID_LCadm
. Selon votre image de système d'exploitation, la commande peut être différente.sudo -i -u SID_LCadm
Créez des sauvegardes de bases de données :
Pour un système à conteneur de bases de données unique SAP HANA :
>
hdbsql -t -u system -p SYSTEM_PASSWORD -i INST_NUM \ "backup data using file ('full')"L'exemple suivant montre une réponse positive d'un nouveau système SAP HANA :
0 rows affected (overall time 18.416058 sec; server time 18.414209 sec)
Pour un système à conteneurs de bases de données multiples (MDC, multi-database-container) SAP HANA, créez une sauvegarde de la base de données système ainsi que des bases de données locataires :
>
hdbsql -t -d SYSTEMDB -u system -p SYSTEM_PASSWORD -i INST_NUM \ "backup data using file ('full')">
hdbsql -t -d SID -u system -p SYSTEM_PASSWORD -i INST_NUM \ "backup data using file ('full')"
L'exemple suivant montre une réponse positive d'un nouveau système SAP HANA :
0 rows affected (overall time 16.590498 sec; server time 16.588806 sec)
Vérifiez que le mode de journalisation est défini sur "normal" :
>
hdbsql -u system -p SYSTEM_PASSWORD -i INST_NUM \ "select value from "SYS"."M_INIFILE_CONTENTS" where key='log_mode'"Vous devriez voir les éléments suivants :
VALUE "normal"
Activer la réplication du système SAP HANA
Dans le cadre de l'activation de la réplication du système SAP HANA, vous devez copier les données et les fichiers de clés pour les magasins sécurisés SAP HANA du système de fichiers (SSFS) de l'hôte principal vers l'hôte secondaire. La méthode utilisée dans cette procédure pour copier les fichiers n'est que l'une des méthodes possibles.
Sur l'hôte principal, en tant que
SID_LCadm
, activez la réplication du système :>
hdbnsutil -sr_enable --name=PRIMARY_HOST_NAMESur l'hôte secondaire :
En tant que
SID_LCadm
, arrêtez SAP HANA :>
HDB stopEn mode root, archivez les données SSFS et les fichiers de clés existants :
#
cd /usr/sap/SID/SYS/global/security/rsecssfs/#
mv data/SSFS_SID.DAT data/SSFS_SID.DAT-ARC#
mv key/SSFS_SID.KEY key/SSFS_SID.KEY-ARCCopiez le fichier de données de l'hôte principal :
#
scp -o StrictHostKeyChecking=no \ PRIMARY_HOST_NAME:/usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT \ /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DATCopiez le fichier de clé de l'hôte principal :
#
scp -o StrictHostKeyChecking=no \ PRIMARY_HOST_NAME:/usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEY \ /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEYMettez à jour la propriété des fichiers :
#
chown SID_LCadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT#
chown SID_LCadm:sapsys /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEYMettez à jour les autorisations pour les fichiers :
#
chmod 644 /usr/sap/SID/SYS/global/security/rsecssfs/data/SSFS_SID.DAT#
chmod 640 /usr/sap/SID/SYS/global/security/rsecssfs/key/SSFS_SID.KEYEn tant que SID_LCadm, enregistrez le système SAP HANA secondaire avec la réplication du système SAP HANA active :
>
hdbnsutil -sr_register --remoteHost=PRIMARY_HOST_NAME --remoteInstance=INST_NUM \ --replicationMode=syncmem --operationMode=logreplay --name=SECONDARY_HOST_NAMEEn tant que SID_LCadm, démarrez SAP HANA :
>
HDB start
Valider la réplication du système
Sur l'hôte principal, en tant que SID_LCadm
, vérifiez que la réplication du système SAP HANA est active en exécutant le script Python suivant :
$
python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py
Si la réplication est correctement configurée, entre autres indicateurs, les valeurs suivantes s'affichent pour les services xsengine
, nameserver
et indexserver
:
Secondary Active Status
est défini surYES
.Replication Status
est défini surACTIVE
.
En outre, overall system replication status
affiche ACTIVE
.
Activer les hooks de fournisseur HA/DR SAP HANA
SUSE vous recommande d'activer les hooks de fournisseur HA/DR (haute disponibilité/reprise après sinistre) SAP HANA, qui permet à SAP HANA d'envoyer des notifications pour certains événements et améliore la détection des défaillances. Les hooks de fournisseur de haute disponibilité/reprise après sinistre (HA/DR, High Availability/Disaster Recovery) nécessitent SAP HANA 2.0 SPS 03 ou une version ultérieure.
Sur le site principal et le site secondaire, procédez comme suit :
En tant que
SID_LCadm
, arrêtez SAP HANA :>
HDB stop
En tant qu'utilisateur racine ou
SID_LCadm
, ouvrez le fichierglobal.ini
pour le modifier :>
vi /hana/shared/SID/global/hdb/custom/config/global.iniAjoutez les définitions suivantes au fichier
global.ini
:[ha_dr_provider_SAPHanaSR] provider = SAPHanaSR path = /usr/share/SAPHanaSR/ execution_order = 1 [ha_dr_provider_suschksrv] provider = susChkSrv path = /usr/share/SAPHanaSR/ execution_order = 3 action_on_lost = stop [trace] ha_dr_saphanasr = info
En tant qu'utilisateur racine, créez un fichier de configuration personnalisé dans le répertoire
/etc/sudoers.d
en exécutant la commande suivante. Ce nouveau fichier de configuration permet à l'utilisateurSID_LCadm
d'accéder aux attributs de nœud du cluster lorsque la méthode de hooksrConnectionChanged()
est appelée.>
sudo visudo -f /etc/sudoers.d/SAPHanaSRDans le fichier
/etc/sudoers.d/SAPHanaSR
, ajoutez le texte suivant :Remplacez les éléments suivants :
SITE_A
: nom du site du serveur SAP HANA principalSITE_B
: nom du site du serveur SAP HANA secondaireSID_LC
: SID, spécifié à l'aide de lettres minuscules
crm_mon -A1 | grep site
en tant qu'utilisateur racine, sur le serveur principal SAP HANA ou sur le serveur secondaire.Cmnd_Alias SOK_SITEA = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_A -v SOK -t crm_config -s SAPHanaSR Cmnd_Alias SFAIL_SITEA = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_A -v SFAIL -t crm_config -s SAPHanaSR Cmnd_Alias SOK_SITEB = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_B -v SOK -t crm_config -s SAPHanaSR Cmnd_Alias SFAIL_SITEB = /usr/sbin/crm_attribute -n hana_SID_LC_site_srHook_SITE_B -v SFAIL -t crm_config -s SAPHanaSR SID_LCadm ALL=(ALL) NOPASSWD: SOK_SITEA, SFAIL_SITEA, SOK_SITEB, SFAIL_SITEB
Dans votre fichier
/etc/sudoers
, assurez-vous que le texte suivant est inclus :Pour SLES pour SAP 15 SP3 et versions ultérieures :
@includedir /etc/sudoers.d
Pour les versions jusqu'à SLES pour SAP 15 SP2 :
#includedir /etc/sudoers.d
Notez que
#
dans ce texte fait partie de la syntaxe et ne signifie pas que la ligne est un commentaire.
En tant que
SID_LCadm
, démarrez SAP HANA :>
HDB startUne fois la configuration du cluster SAP HANA terminée, vous pouvez vérifier que le hook fonctionne correctement lors d'un test de basculement, comme décrit dans les sections Dépannage du hook Python SAPHanaSR et La reprise du cluster à haute disponibilité prend trop de temps en cas de défaillance du serveur d'index HANA.
Configurer la prise en charge du basculement Cloud Load Balancing
Le service d'équilibrage de charge réseau interne à stratégie directe avec prise en charge du basculement achemine le trafic vers l'hôte actif dans un cluster SAP HANA en fonction d'un service de vérification de l'état.
Réserver une adresse IP pour l'adresse IP virtuelle
L'adresse IP virtuelle, parfois appelée adresse IP flottante, suit le système SAP HANA actif. L'équilibreur de charge achemine le trafic envoyé à l'adresse IP virtuelle vers la VM qui héberge actuellement le système SAP HANA actif.
Ouvrez Cloud Shell.
Réservez une adresse IP pour l'adresse IP virtuelle. Il s'agit de l'adresse IP utilisée par les applications pour accéder à SAP HANA. Si vous omettez l'option
--addresses
, une adresse IP du sous-réseau spécifié est choisie pour vous :$
gcloud compute addresses create VIP_NAME \ --region CLUSTER_REGION --subnet CLUSTER_SUBNET \ --addresses VIP_ADDRESSPour en savoir plus sur la réservation d'une adresse IP statique, consultez la page Réserver une adresse IP interne statique.
Confirmez la réservation d'adresse IP :
$
gcloud compute addresses describe VIP_NAME \ --region CLUSTER_REGIONUn résultat semblable aux lignes suivantes doit s'afficher :
address: 10.0.0.19 addressType: INTERNAL creationTimestamp: '2020-05-20T14:19:03.109-07:00' description: '' id: '8961491304398200872' kind: compute#address name: vip-for-hana-ha networkTier: PREMIUM purpose: GCE_ENDPOINT region: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1 selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/addresses/vip-for-hana-ha status: RESERVED subnetwork: https://www.googleapis.com/compute/v1/projects/example-project-123456/regions/us-central1/subnetworks/example-subnet-us-central1
Créer des groupes d'instances pour vos VM hôtes
Dans Cloud Shell, créez deux groupes d'instances non gérés, puis attribuez la VM hôte maître principale à l'un et la VM hôte maître secondaire à l'autre :
$
gcloud compute instance-groups unmanaged create PRIMARY_IG_NAME \ --zone=PRIMARY_ZONE$
gcloud compute instance-groups unmanaged add-instances PRIMARY_IG_NAME \ --zone=PRIMARY_ZONE \ --instances=PRIMARY_HOST_NAME$
gcloud compute instance-groups unmanaged create SECONDARY_IG_NAME \ --zone=SECONDARY_ZONE$
gcloud compute instance-groups unmanaged add-instances SECONDARY_IG_NAME \ --zone=SECONDARY_ZONE \ --instances=SECONDARY_HOST_NAMEConfirmez la création des groupes d'instances :
$
gcloud compute instance-groups unmanaged listUn résultat semblable aux lignes suivantes doit s'afficher :
NAME ZONE NETWORK NETWORK_PROJECT MANAGED INSTANCES hana-ha-ig-1 us-central1-a example-network example-project-123456 No 1 hana-ha-ig-2 us-central1-c example-network example-project-123456 No 1
Créer une vérification de l'état Compute Engine
Dans Cloud Shell, créez la vérification de l'état. Pour le port utilisé par la vérification de l'état, choisissez un port situé dans la plage privée (49152-65535) afin d'éviter tout conflit avec d'autres services. Les valeurs de l'intervalle entre deux tests et du délai avant expiration sont légèrement supérieures aux valeurs par défaut afin d'augmenter la tolérance au basculement lors des événements de migration à chaud de Compute Engine. Vous pouvez ajuster les valeurs, si nécessaire :
$
gcloud compute health-checks create tcp HEALTH_CHECK_NAME --port=HEALTHCHECK_PORT_NUM \ --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \ --healthy-threshold=2Confirmez la création de la vérification de l'état :
$
gcloud compute health-checks describe HEALTH_CHECK_NAMEUn résultat semblable aux lignes suivantes doit s'afficher :
checkIntervalSec: 10 creationTimestamp: '2020-05-20T21:03:06.924-07:00' healthyThreshold: 2 id: '4963070308818371477' kind: compute#healthCheck name: hana-health-check selfLink: https://www.googleapis.com/compute/v1/projects/example-project-123456/global/healthChecks/hana-health-check tcpHealthCheck: port: 60000 portSpecification: USE_FIXED_PORT proxyHeader: NONE timeoutSec: 10 type: TCP unhealthyThreshold: 2
Créer une règle de pare-feu pour les vérifications d'état
Définissez une règle de pare-feu pour un port situé dans la plage privée qui permet d'accéder à vos VM hôtes à partir des plages d'adresses IP utilisées par les vérifications d'état de Compute Engine, 35.191.0.0/16
et 130.211.0.0/22
. Pour en savoir plus, consultez la section Créer des règles de pare-feu pour les vérifications d'état.
Si ce n'est pas déjà fait, ajoutez un tag réseau à vos VM hôtes. Ce tag réseau est utilisé par la règle de pare-feu pour les vérifications d'état.
$
gcloud compute instances add-tags PRIMARY_HOST_NAME \ --tags NETWORK_TAGS \ --zone PRIMARY_ZONE$
gcloud compute instances add-tags SECONDARY_HOST_NAME \ --tags NETWORK_TAGS \ --zone SECONDARY_ZONESi vous n'en avez pas encore, créez une règle de pare-feu pour autoriser les vérifications de l'état :
$
gcloud compute firewall-rules create RULE_NAME \ --network NETWORK_NAME \ --action ALLOW \ --direction INGRESS \ --source-ranges 35.191.0.0/16,130.211.0.0/22 \ --target-tags NETWORK_TAGS \ --rules tcp:HLTH_CHK_PORT_NUMExemple :
gcloud compute firewall-rules create fw-allow-health-checks \ --network example-network \ --action ALLOW \ --direction INGRESS \ --source-ranges 35.191.0.0/16,130.211.0.0/22 \ --target-tags cluster-ntwk-tag \ --rules tcp:60000
Configurer l'équilibreur de charge et le groupe de basculement
Créez le service de backend de l'équilibreur de charge :
$
gcloud compute backend-services create BACKEND_SERVICE_NAME \ --load-balancing-scheme internal \ --health-checks HEALTH_CHECK_NAME \ --no-connection-drain-on-failover \ --drop-traffic-if-unhealthy \ --failover-ratio 1.0 \ --region CLUSTER_REGION \ --global-health-checksAjoutez le groupe d'instances principal au service de backend :
$
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \ --instance-group PRIMARY_IG_NAME \ --instance-group-zone PRIMARY_ZONE \ --region CLUSTER_REGIONAjoutez le groupe d'instances de basculement secondaire au service de backend :
$
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \ --instance-group SECONDARY_IG_NAME \ --instance-group-zone SECONDARY_ZONE \ --failover \ --region CLUSTER_REGIONCréez une règle de transfert. Pour l'adresse IP, spécifiez celle que vous avez réservée pour l'adresse IP virtuelle : Si vous devez accéder au système SAP HANA en dehors de la région spécifiée ci-dessous, incluez l'indicateur
--allow-global-access
dans la définition :$
gcloud compute forwarding-rules create RULE_NAME \ --load-balancing-scheme internal \ --address VIP_ADDRESS \ --subnet CLUSTER_SUBNET \ --region CLUSTER_REGION \ --backend-service BACKEND_SERVICE_NAME \ --ports ALLPour en savoir plus sur l'accès interrégional à votre système SAP HANA à haute disponibilité, consultez la page Équilibrage de charge TCP/UDP interne.
Tester la configuration de l'équilibreur de charge
Même si vos groupes d'instances backend ne seront considérés comme opérationnels que plus tard, vous pouvez tester la configuration de l'équilibreur de charge en configurant un écouteur pour répondre aux vérifications d'état. Une fois un écouteur configuré, si l'équilibreur de charge est correctement configuré, les groupes d'instances backend deviennent opérationnels.
Les sections suivantes présentent différentes méthodes que vous pouvez utiliser pour tester la configuration.
Tester l'équilibreur de charge avec l'utilitaire socat
Vous pouvez vous servir de l'utilitaire socat
pour écouter temporairement le port de vérification de l'état. Vous devez tout de même installer l'utilitaire socat
, car vous l'utiliserez plus tard lors de la configuration des ressources du cluster.
En tant qu'utilisateur racine, installez sur les deux VM hôtes l'utilitaire
socat
:#
zypper install -y socatDémarrez un processus
socat
pour écouter le port de vérification de l'état pendant 60 secondes :#
timeout 60s socat - TCP-LISTEN:HLTH_CHK_PORT_NUM,forkDans Cloud Shell, après avoir attendu quelques secondes pour que la vérification de l'état détecte l'écouteur, vérifiez l'état de vos groupes d'instances backend :
$
gcloud compute backend-services get-health BACKEND_SERVICE_NAME \ --region CLUSTER_REGIONLe résultat doit être semblable à ceci :
--- backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1 status: healthStatus: ‐ healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1 ipAddress: 10.0.0.35 port: 80 kind: compute#backendServiceGroupHealth --- backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2 status: healthStatus: ‐ healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2 ipAddress: 10.0.0.34 port: 80 kind: compute#backendServiceGroupHealth
Tester l'équilibreur de charge à l'aide du port 22
Si le port 22 est ouvert pour les connexions SSH sur vos VM hôtes, vous pouvez modifier temporairement le vérificateur de l'état afin d'utiliser ce port, qui dispose d'un écouteur capable de lui répondre.
Pour utiliser temporairement le port 22, procédez comme suit :
Cliquez sur votre vérification de l'état dans la console :
Cliquez sur Modifier.
Dans le champ Port, remplacez le numéro de port par 22.
Cliquez sur Enregistrer, puis patientez une minute ou deux.
Dans Cloud Shell, vérifiez l'état de vos groupes d'instances backend :
$
gcloud compute backend-services get-health BACKEND_SERVICE_NAME \ --region CLUSTER_REGIONLe résultat doit être semblable à ceci :
--- backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instanceGroups/hana-ha-ig-1 status: healthStatus: ‐ healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-a/instances/hana-ha-vm-1 ipAddress: 10.0.0.35 port: 80 kind: compute#backendServiceGroupHealth --- backend: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instanceGroups/hana-ha-ig-2 status: healthStatus: ‐ healthState: HEALTHY instance: https://www.googleapis.com/compute/v1/projects/example-project-123456/zones/us-central1-c/instances/hana-ha-vm-2 ipAddress: 10.0.0.34 port: 80 kind: compute#backendServiceGroupHealth
Lorsque vous avez terminé, rétablissez le numéro de port d'origine de la vérification de l'état.
Configurer Pacemaker
La procédure suivante configure l'implémentation SUSE d'un cluster Pacemaker sur des VM Compute Engine pour SAP HANA.
Pour en savoir plus sur la configuration des clusters à haute disponibilité sur SLES, consultez la documentation de l'extension SUSE Linux Enterprise High Availability Extension correspondant à votre version de SLES.
Télécharger les scripts d'agent de ressources
En mode root sur les hôtes principal et secondaire, téléchargez les scripts d'agent de ressources requis :
#
mkdir -p /usr/lib64/stonith/plugins/external#
curl https://storage.googleapis.com/cloudsapdeploy/pacemaker-gcp/gcpstonith -o /usr/lib64/stonith/plugins/external/gcpstonith#
chmod +x /usr/lib64/stonith/plugins/external/gcpstonith
Créer les fichiers de configuration Corosync
Créez un fichier de configuration Corosync sur l'hôte principal :
À l'aide de l'éditeur de texte de votre choix, créez le fichier suivant :
/etc/corosync/corosync.conf
Dans le fichier
corosync.conf
de l'hôte principal, ajoutez la configuration suivante en remplaçant le texte de variable en italique par vos valeurs :totem { version: 2 secauth: off crypto_hash: sha1 crypto_cipher: aes256 cluster_name: hacluster clear_node_high_bit: yes token: 20000 token_retransmits_before_loss_const: 10 join: 60 max_messages: 20 transport: udpu interface { ringnumber: 0 Bindnetaddr: static-ip-of-hdb-on-this-host mcastport: 5405 ttl: 1 } } logging { fileline: off to_stderr: no to_logfile: no logfile: /var/log/cluster/corosync.log to_syslog: yes debug: off timestamp: on logger_subsys { subsys: QUORUM debug: off } } nodelist { node { ring0_addr: this-host-name nodeid: 1 } node { ring0_addr: other-host-name nodeid: 2 } } quorum { provider: corosync_votequorum expected_votes: 2 two_node: 1 }
Créez un fichier de configuration Corosync sur l'hôte secondaire en répétant les étapes que vous avez utilisées pour l'hôte principal. À l'exception de l'adresse IP statique du HDB sur la propriété
Bindnetaddr
et de l'ordre des noms d'hôte dansnodelist
, les valeurs de propriété du fichier de configuration sont identiques pour chaque hôte.
Initialiser le cluster
Sur l'hôte principal, en mode root :
Initialisez le cluster :
#
corosync-keygen#
ha-cluster-init -y csync2Démarrez Pacemaker sur l'hôte principal :
#
systemctl enable pacemaker#
systemctl start pacemaker
Sur l'hôte secondaire, en mode root :
Associez l'hôte secondaire au cluster initialisé sur l'hôte principal :
#
ha-cluster-join -y -c primary-host-name csync2Démarrez Pacemaker sur l'hôte secondaire :
#
systemctl enable pacemaker#
systemctl start pacemaker
Sur l'un de ces hôtes, en mode root, vérifiez que le cluster affiche les deux nœuds :
#
crm_mon -sUn résultat semblable à la ligne suivante doit s'afficher :
CLUSTER OK: 2 nodes online, 0 resources configured
Configurer le cluster
Pour configurer le cluster, vous devez définir les propriétés générales du cluster et ses ressources primitives.
Activer le mode de maintenance
Sur l'un des hôtes, en mode root, passez le cluster en mode de maintenance :
#
crm configure property maintenance-mode="true"
Configurer les propriétés générales du cluster
Sur l'hôte principal :
Définissez les propriétés générales du cluster :
#
crm configure property stonith-timeout="300s"#
crm configure property stonith-enabled="true"#
crm configure rsc_defaults resource-stickiness="1000"#
crm configure rsc_defaults migration-threshold="5000"#
crm configure op_defaults timeout="600"
Configurer le cloisonnement
Pour configurer le cloisonnement, vous devez définir une ressource de cluster avec un agent de cloisonnement pour chaque VM hôte.
Pour garantir la séquence correcte d'événements après une action de cloisonnement, vous devez également configurer le système d'exploitation pour retarder le redémarrage de Corosync après la fermeture d'une VM. Vous pouvez également ajuster le délai avant expiration de Pacemaker pour les redémarrages afin de tenir compte de ce délai.
Créer les ressources de l'appareil de cloisonnement
Sur l'hôte principal, en tant qu'utilisateur racine, créez les ressources de cloisonnement :
#
crm configure primitive STONITH-"primary-host-name" stonith:external/gcpstonith \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s" \ params instance_name="primary-host-name" gcloud_path="/usr/bin/gcloud" logging="yes" \ pcmk_reboot_timeout=300 pcmk_monitor_retries=4 pcmk_delay_max=30#
crm configure primitive STONITH-"secondary-host-name" stonith:external/gcpstonith \ op monitor interval="300s" timeout="120s" \ op start interval="0" timeout="60s" \ params instance_name="secondary-host-name" gcloud_path="/usr/bin/gcloud" logging="yes" \ pcmk_reboot_timeout=300 pcmk_monitor_retries=4Définissez l'emplacement de chaque appareil de cloisonnement :
#
crm configure location LOC_STONITH_"primary-host-name" \ STONITH-"primary-host-name" -inf: "primary-host-name"#
crm configure location LOC_STONITH_"secondary-host-name" \ STONITH-"secondary-host-name" -inf: "secondary-host-name"
Définir un délai pour le redémarrage de Corosync
Sur les deux hôtes, en tant qu'utilisateur racine, créez un fichier de dépôt
systemd
qui retarde le démarrage de Corosync pour garantir le bon déroulement de la séquence d'événements après le redémarrage d'une VM cloisonnée :systemctl edit corosync.service
Ajoutez les lignes suivantes au fichier :
[Service] ExecStartPre=/bin/sleep 60
Enregistrez le fichier et quittez l'éditeur.
Rechargez la configuration du gestionnaire systemd.
systemctl daemon-reload
Vérifiez que le fichier de dépôt a été créé :
service corosync status
Une ligne correspondant au fichier de dépôt doit s'afficher, comme illustré dans l'exemple suivant :
● corosync.service - Corosync Cluster Engine Loaded: loaded (/usr/lib/systemd/system/corosync.service; disabled; vendor preset: disabled) Drop-In: /etc/systemd/system/corosync.service.d └─override.conf Active: active (running) since Tue 2021-07-20 23:45:52 UTC; 2 days ago
Créer une ressource IP de cluster local pour l'adresse IP virtuelle
Pour configurer l'adresse IP virtuelle dans le système d'exploitation, créez une ressource IP de cluster locale pour l'adresse IP virtuelle que vous avez réservée précédemment :
#
crm configure primitive rsc_vip_int-primary IPaddr2 \
params ip=vip-address cidr_netmask=32 nic="eth0" op monitor interval=3600s timeout=60s
Configurer le service d'aide de vérification de l'état
L'équilibreur de charge utilise un écouteur sur le port de vérification de l'état de chaque hôte afin de déterminer où l'instance principale du cluster SAP HANA est exécutée.
Pour gérer les écouteurs dans le cluster, vous devez créer une ressource pour l'écouteur.
Ces instructions utilisent l'utilitaire socat
comme écouteur.
Sur les deux hôtes en mode root, installez
socat utility
:#
zypper in -y socatSur l'hôte principal :
Créez une ressource pour le service de vérification d'état de l'outil d'aide :
#
crm configure primitive rsc_healthcheck-primary anything \ params binfile="/usr/bin/socat" \ cmdline_options="-U TCP-LISTEN:healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null" \ op monitor timeout=20s interval=10s \ op_params depth=0
Regrouper les ressources de l'adresse IP virtuelle et du service de vérification d'état de l'outil d'aide
Regroupez les ressources de l'adresse IP virtuelle et du service de vérification d'état de l'outil d'aide :
#
crm configure group g-primary rsc_vip_int-primary rsc_healthcheck-primary
Créer la ressource primitive SAPHanaTopology
Vous définissez la ressource primitive SAPHanaTopology dans un fichier de configuration temporaire, que vous importez ensuite dans Corosync.
Sur l'hôte principal, en mode root :
Créez un fichier de configuration temporaire pour les paramètres de configuration SAPHanaTopology :
#
vi /tmp/cluster.tmpEffectuez un copier/coller des définitions de ressources SAPHanaTopology dans le fichier
/tmp/cluster.tmp
:primitive rsc_SAPHanaTopology_SID_HDBinst_num ocf:suse:SAPHanaTopology \ operations \$id="rsc_sap2_SID_HDBinst_num-operations" \ op monitor interval="10" timeout="600" \ op start interval="0" timeout="600" \ op stop interval="0" timeout="300" \ params SID="SID" InstanceNumber="inst_num" clone cln_SAPHanaTopology_SID_HDBinst_num rsc_SAPHanaTopology_SID_HDBinst_num \ meta clone-node-max="1" target-role="Started" interleave="true"
Modifiez le fichier
/tmp/cluster.tmp
pour remplacer les variables par le SID et le numéro d'instance de votre système SAP HANA.Sur l'hôte principal, en mode root, chargez le contenu du fichier
/tmp/cluster.tmp
dans Corosync :crm configure load update /tmp/cluster.tmp
Créer la ressource primitive SAPHana
Vous définissez la ressource primitive SAPHana à l'aide de la même méthode que celle utilisée pour la ressource SAPHanaTopology, à savoir un fichier de configuration temporaire, que vous importez ensuite dans Corosync.
Remplacez le fichier de configuration temporaire :
#
rm /tmp/cluster.tmp#
vi /tmp/cluster.tmpEffectuez un copier/coller des définitions de ressources SAPHana dans le fichier
/tmp/cluster.tmp
:primitive rsc_SAPHana_SID_HDBinst_num ocf:suse:SAPHana \ operations \$id="rsc_sap_SID_HDBinst_num-operations" \ op start interval="0" timeout="3600" \ op stop interval="0" timeout="3600" \ op promote interval="0" timeout="3600" \ op demote interval="0" timeout="3600" \ op monitor interval="60" role="Master" timeout="700" \ op monitor interval="61" role="Slave" timeout="700" \ params SID="SID" InstanceNumber="inst_num" PREFER_SITE_TAKEOVER="true" \ DUPLICATE_PRIMARY_TIMEOUT="7200" AUTOMATED_REGISTER="true" ms msl_SAPHana_SID_HDBinst_num rsc_SAPHana_SID_HDBinst_num \ meta notify="true" clone-max="2" clone-node-max="1" \ target-role="Started" interleave="true" colocation col_saphana_ip_SID_HDBinst_num 4000: g-primary:Started \ msl_SAPHana_SID_HDBinst_num:Master order ord_SAPHana_SID_HDBinst_num Optional: cln_SAPHanaTopology_SID_HDBinst_num \ msl_SAPHana_SID_HDBinst_num
Pour un cluster HA SAP HANA à niveaux multiples, si vous utilisez une version antérieure à SAP HANA 2.0 SP03, définissez
AUTOMATED_REGISTER
surfalse
. Cela permet d'empêcher une instance récupérée d'essayer de s'enregistrer automatiquement pour la réplication vers un système HANA sur lequel une cible de réplication est déjà configurée. Pour SAP HANA 2.0 SP03 ou pour les versions ultérieures, vous pouvez définirAUTOMATED_REGISTER
surtrue
pour les configurations SAP HANA qui utilisent la réplication système à plusieurs niveaux. Pour en savoir plus, consultez les pages suivantes :Sur l'hôte principal, en mode root, chargez le contenu du fichier
/tmp/cluster.tmp
dans Corosync :crm configure load update /tmp/cluster.tmp
Vérifier que la réplication du système SAP HANA est active
Sur l'hôte principal, en tant que
SID_LCadm
, connectez-vous au terminal interactif de la base de données SAP HANA :>
hdbsql -u system -p "system-password" -i inst_numDans le terminal interactif, vérifiez l'état de la réplication :
=>
select distinct REPLICATION_STATUS from SYS.M_SERVICE_REPLICATIONL'état
REPLICATION_STATUS
doit être défini sur"ACTIVE"
.
Vous pouvez également vérifier l'état de la réplication en exécutant le script Python suivant en tant que SID_LCadm
:
#
python $DIR_INSTANCE/exe/python_support/systemReplicationStatus.py
Activer le cluster
Sur l'hôte principal, en mode root, désactivez le mode de maintenance pour le cluster :
#
crm configure property maintenance-mode="false"Si vous êtes invité à supprimer "maintenance", saisissez
y
.Patientez 15 secondes, puis vérifiez l'état du cluster sur l'hôte principal en mode root :
#
crm statusLes exemples suivants montrent l'état d'un cluster actif et correctement configuré :
Stack: corosync Current DC: hana-ha-vm-1 (version 2.0.1+20190417.13d370ca9-3.9.1-2.0.1+20190417.13d370ca9) - partition with quorum Last updated: Sun Jun 7 00:36:56 2020 Last change: Sun Jun 7 00:36:53 2020 by root via crm_attribute on hana-ha-vm-1 2 nodes configured 8 resources configured Online: [ hana-ha-vm-1 hana-ha-vm-2 ] Full list of resources: STONITH-hana-ha-vm-1 (stonith:external/gcpstonith): Started hana-ha-vm-2 STONITH-hana-ha-vm-2 (stonith:external/gcpstonith): Started hana-ha-vm-1 Clone Set: cln_SAPHanaTopology_HA1_HDB22 [rsc_SAPHanaTopology_HA1_HDB22] Started: [ hana-ha-vm-1 hana-ha-vm-2 ] Resource Group: g-primary rsc_vip_int-primary (ocf::heartbeat:IPaddr2): Started hana-ha-vm-1 rsc_healthcheck-primary (ocf::heartbeat:anything): Started hana-ha-vm-1 Clone Set: msl_SAPHana_HA1_HDB22 [rsc_SAPHana_HA1_HDB22] (promotable) Masters: [ hana-ha-vm-1 ] Slaves: [ hana-ha-vm-2 ]
Tester le basculement
Testez votre cluster en simulant une défaillance sur l'hôte principal. Utilisez un système de test ou exécutez le test sur votre système de production avant de mettre le système en service.
Sauvegardez le système avant le test.
Vous pouvez simuler une défaillance de différentes manières, par exemple :
HDB stop
HDB kill
reboot
(sur le nœud actif)ip link set eth0 down
pour les instances avec une seule interface réseauiptables ... DROP
pour les instances avec plusieurs interfaces réseauecho c > /proc/sysrq-trigger
Ces instructions utilisent ip link set eth0 down
ou iptables
pour simuler une interruption du réseau entre vos deux hôtes du cluster. Exécutez la commande ip link
sur une instance dotée d'une seule interface réseau, et la commande iptables
sur les instances possédant une ou plusieurs interfaces réseau. Le test valide le basculement et le cloisonnement. Si plusieurs interfaces réseau sont définies sur vos instances, utilisez la commande iptables
sur l'hôte secondaire pour abandonner le trafic entrant et sortant en fonction de l'adresse IP utilisée par l'hôte principal pour la communication des clusters, ce qui simule ainsi une perte de connexion réseau à l'instance principale.
Sur l'hôte actif, en tant qu'utilisateur racine, déconnectez l'interface réseau :
#
ip link set eth0 downOu, si plusieurs interfaces réseau sont actives, à l'aide de
iptables
sur l'hôte secondaire :#
iptables -A INPUT -s PRIMARY_CLUSTER_IP -j DROP; iptables -A OUTPUT -d PRIMARY_CLUSTER_IP -j DROPReconnectez-vous à l'un des hôtes à l'aide de SSH, puis connectez-vous en tant qu'utilisateur racine.
Saisissez
crm status
pour vérifier que l'hôte principal est désormais actif sur la VM qui contenait l'hôte secondaire. Le redémarrage automatique est activé dans le cluster. Par conséquent, l'hôte arrêté redémarre et prend le rôle d'hôte secondaire, comme illustré dans l'exemple suivant.Stack: corosync Current DC: hana-ha-vm-2 (version 2.0.1+20190417.13d370ca9-3.9.1-2.0.1+20190417.13d370ca9) - partition with quorum Last updated: Fri Jun 12 16:46:07 2020 Last change: Fri Jun 12 16:46:07 2020 by root via crm_attribute on hana-ha-vm-2 2 nodes configured 8 resources configured Online: [ hana-ha-vm-1 hana-ha-vm-2 ] Full list of resources: STONITH-hana-ha-vm-1 (stonith:external/gcpstonith): Started hana-ha-vm-2 STONITH-hana-ha-vm-2 (stonith:external/gcpstonith): Started hana-ha-vm-1 Clone Set: cln_SAPHanaTopology_HA1_HDB22 [rsc_SAPHanaTopology_HA1_HDB22] Started: [ hana-ha-vm-1 hana-ha-vm-2 ] Resource Group: g-primary rsc_vip_int-primary (ocf::heartbeat:IPaddr2): Started hana-ha-vm-2 rsc_healthcheck-primary (ocf::heartbeat:anything): Started hana-ha-vm-2 Clone Set: msl_SAPHana_HA1_HDB22 [rsc_SAPHana_HA1_HDB22] (promotable) Masters: [ hana-ha-vm-2 ] Slaves: [ hana-ha-vm-1 ]
Configurer HANA actif/actif (lecture activée)
À partir de SAP HANA 2.0 SPS1, vous pouvez configurer HANA actif/actif (lecture activée) dans un cluster Pacemaker. Cette opération est facultative.
Pour configurer HANA actif/actif (lecture activée) dans un cluster Pacemaker, procédez comme suit :
Configurer la prise en charge du basculement Cloud Load Balancing pour l'hôte secondaire
Le service d'équilibrage de charge réseau interne à stratégie directe avec prise en charge du basculement achemine le trafic vers l'hôte secondaire dans un cluster SAP HANA en fonction d'un service de vérification de l'état.
Pour configurer la prise en charge du basculement de l'hôte secondaire, procédez comme suit :
Ouvrez Cloud Shell.
Réservez une adresse IP pour l'adresse IP virtuelle en exécutant la commande suivante.
L'adresse IP virtuelle (VIP) suit le système SAP HANA secondaire. Il s'agit de l'adresse IP utilisée par les applications pour accéder à votre système SAP HANA secondaire. L'équilibreur de charge achemine le trafic envoyé à l'adresse IP virtuelle vers l'instance de VM qui héberge actuellement le système secondaire.
Si vous omettez l'option
--addresses
dans la commande suivante, une adresse IP du sous-réseau spécifié est choisie pour vous. Pour en savoir plus sur la réservation d'une adresse IP statique, consultez la page Réserver une adresse IP interne statique.$
gcloud compute addresses create secondary-vip-name \ --region cluster-region --subnet cluster-subnet \ --addresses secondary-vip-addressCréez une vérification d'état Compute Engine en exécutant la commande suivante.
Pour le port utilisé par la vérification de l'état, choisissez un port situé dans la plage privée (49152-65535) afin d'éviter tout conflit avec d'autres services. Le port doit être différent de celui configuré pour la vérification d'état utilisée pour l'accès au système principal HANA. Les valeurs d'intervalle entre deux tests et de délai avant expiration sont légèrement supérieures aux valeurs par défaut afin d'augmenter la tolérance au basculement lors des événements de migration à chaud de Compute Engine. Vous pouvez ajuster les valeurs si nécessaire.
$
gcloud compute health-checks create tcp secondary-health-check-name \ --port=secondary-healthcheck-port-num \ --proxy-header=NONE --check-interval=10 --timeout=10 --unhealthy-threshold=2 \ --healthy-threshold=2Configurez l'équilibreur de charge et le groupe de basculement en exécutant les commandes suivantes.
Ici, vous créez un service de backend supplémentaire et utilisez les mêmes groupes d'instances que ceux créés précédemment pour le service de backend derrière l'équilibreur de charge TCP/UDP interne de votre système principal SAP HANA.
Créez le service de backend de l'équilibreur de charge :
$
gcloud compute backend-services create secondary-backend-service-name \ --load-balancing-scheme internal \ --health-checks secondary-health-check-name \ --no-connection-drain-on-failover \ --drop-traffic-if-unhealthy \ --failover-ratio 1.0 \ --region cluster-region \ --global-health-checksAjoutez le groupe d'instances principal au service de backend :
$
gcloud compute backend-services add-backend secondary-backend-service-name \ --instance-group primary-ig-name \ --instance-group-zone primary-zone \ --region cluster-regionAjoutez le groupe d'instances de basculement secondaire au service de backend :
$
gcloud compute backend-services add-backend secondary-backend-service-name \ --instance-group secondary-ig-name \ --instance-group-zone secondary-zone \ --failover \ --region cluster-regionCréez une règle de transfert.
Pour l'option d'adresse IP, spécifiez celle que vous avez réservée pour l'adresse IP virtuelle. Si vous devez accéder au système secondaire HANA en dehors de la région spécifiée dans la commande suivante, incluez l'option
--allow-global-access
dans la définition de la règle de transfert.$
gcloud compute forwarding-rules create secondary-rule-name \ --load-balancing-scheme internal \ --address secondary-vip-name \ --subnet cluster-subnet \ --region cluster-region \ --backend-service secondary-backend-service-name \ --ports ALLPour en savoir plus sur l'accès interrégional à votre système SAP HANA à haute disponibilité, consultez la page Équilibrage de charge TCP/UDP interne.
Activer HANA actif/actif (lecture activée)
Sur votre hôte secondaire, activez le mode actif/actif (lecture activée) pour la réplication du système SAP HANA en procédant comme suit :
En tant qu'utilisateur racine, placez le cluster en mode de maintenance :
#
crm configure property maintenance-mode="true"En tant que
SID_LCadm
, arrêtez SAP HANA :>
HDB stopEn tant que
SID_LCadm
, réenregistrez le système secondaire HANA avec la réplication du système SAP HANA à l'aide du mode d'opérationlogreplay_readaccess
:>
hdbnsutil -sr_register --remoteHost=primary-host-name --remoteInstance=inst_num \ --replicationMode=syncmem --operationMode=logreplay_readaccess --name=secondary-host-nameEn tant que
SID_LCadm
, démarrez SAP HANA :>
HDB startEn tant que
SID_LCadm
, confirmez que l'état de la synchronisation HANA est bienACTIVE
:>
cdpy; python systemReplicationStatus.py --sapcontrol=1 | grep overall_replication_statusUn résultat semblable à l'exemple suivant doit s'afficher :
overall_replication_status=ACTIVE
Configurer Pacemaker
Configurez votre cluster à haute disponibilité Pacemaker en mode actif/actif (lecture activée) en exécutant les commandes suivantes en tant qu'utilisateur racine :
Créez une ressource IP de cluster locale pour l'adresse IP virtuelle que vous avez réservée pour le système secondaire :
#
crm configure primitive rsc_vip_int-secondary IPaddr2 \ params ip=secondary-vip-address cidr_netmask=32 nic="eth0" \ op monitor interval=3600s timeout=60sConfigurez le service de vérification d'état de l'outil d'aide en exécutant les commandes suivantes :
L'équilibreur de charge utilise un écouteur sur le port de vérification de l'état de chaque hôte afin de déterminer où l'instance secondaire du cluster SAP HANA est exécutée.
Pour gérer les écouteurs dans le cluster, vous devez créer une ressource pour l'écouteur. Ces instructions utilisent l'utilitaire socat comme écouteur. Créez une ressource pour le service de vérification d'état de l'outil d'aide :
#
crm configure primitive rsc_healthcheck-secondary anything \ params binfile="/usr/bin/socat" \ cmdline_options="-U TCP-LISTEN:secondary-healthcheck-port-num,backlog=10,fork,reuseaddr /dev/null" \ op monitor timeout=20s interval=10s \ op_params depth=0Regroupez les ressources de l'adresse IP virtuelle et du service de vérification d'état de l'outil d'aide :
#
crm configure group g-secondary rsc_vip_int-secondary rsc_healthcheck-secondary
Créez une contrainte de colocation :
#
crm configure colocation col_saphana_secondary 4000: g-secondary:Started \ msl_SAPHana_SID_HDBinst_num:SlaveQuittez le mode de maintenance du cluster :
#
crm configure property maintenance-mode="false"Vérifiez l'état du cluster :
#
crm statusLes exemples suivants montrent l'état d'un cluster actif et correctement configuré pour la réplication du système SAP HANA en mode actif/actif (lecture activée). Un groupe de ressources supplémentaire doit s'afficher pour les ressources VIP du système secondaire. Dans l'exemple suivant, le nom de ce groupe de ressources est
g-secondary
.Cluster Summary: Stack: corosync Current DC: hana-ha-vm-1 (version 2.0.4+20200616.2deceaa3a-3.15.1-2.0.4+20200616.2deceaa3a) - partition with quorum Last updated: Fri Oct 7 21:52:46 2022 Last change: Fri Oct 7 21:51:42 2022 by root via crm_attribute on hana-ha-vm-1 2 nodes configured 10 resource instances configured Node List: Online: [ hana-ha-vm-1 hana-ha-vm-2 ] Active Resources: STONITH-hana-ha-vm-1 (stonith:external/gcpstonith): Started hana-ha-vm-2 STONITH-hana-ha-vm-2 (stonith:external/gcpstonith): Started hana-ha-vm-1 Resource Group: g-primary: rsc_vip_int-primary (ocf::heartbeat:IPaddr2): Started hana-ha-vm-1 rsc_vip_hc-primary (ocf::heartbeat:anything): Started hana-ha-vm-1 Clone Set: cln_SAPHanaTopology_HA1_HDB00 [rsc_SAPHanaTopology_HA1_HDB00]: Started: [ hana-ha-vm-1 hana-ha-vm-2 ] Clone Set: msl_SAPHana_HA1_HDB00 [rsc_SAPHana_HA1_HDB00] (promotable): Masters: [ hana-ha-vm-1 ] Slaves: [ hana-ha-vm-2 ] Resource Group: g-secondary: rsc_vip_int-secondary (ocf::heartbeat:IPaddr2): Started hana-ha-vm-2 rsc_healthcheck-secondary (ocf::heartbeat:anything): Started hana-ha-vm-2
Évaluer votre charge de travail SAP HANA
Pour automatiser les vérifications de validation continues pour vos charges de travail à haute disponibilité SAP HANA exécutées sur Google Cloud, vous pouvez utiliser le gestionnaire de charges de travail.
Le gestionnaire de charges de travail vous permet d'analyser et d'évaluer automatiquement vos charges de travail SAP HANA à haute disponibilité par rapport aux bonnes pratiques des fournisseurs SAP, de Google Cloud et de système d'exploitation. Cela permet d'améliorer la qualité, les performances et la fiabilité de vos charges de travail.
Pour en savoir plus sur les bonnes pratiques compatibles avec le gestionnaire de charges de travail pour évaluer les charges de travail SAP HANA à haute disponibilité exécutées sur Google Cloud, consultez la page Bonnes pratiques pour le gestionnaire de charges de travail SAP. Pour en savoir plus sur la création et l'exécution d'une évaluation à l'aide du gestionnaire de charges de travail, consultez la page Créer et exécuter une évaluation.
Dépannage
Pour résoudre les problèmes liés aux configurations à haute disponibilité pour SAP HANA sur SLES, consultez la section Dépannage des configurations à haute disponibilité pour SAP.
Obtenir de l'aide concernant SAP HANA sur SLES
Si vous avez besoin d'aide pour résoudre un problème lié à des clusters à haute disponibilité pour SAP HANA sur SLES, rassemblez les informations de diagnostic requises et contactez Cloud Customer Care. Pour en savoir plus, consultez la page Informations de diagnostic sur les clusters à haute disponibilité SLES.
Assistance
Pour les problèmes liés à l'infrastructure ou aux services Google Cloud, contactez l'assistance Customer Care. Ses coordonnées sont disponibles sur la page de présentation de l'assistance dans la console Google Cloud. Si l'assistance Customer Care détecte un problème dans vos systèmes SAP, vous serez redirigé vers l'assistance SAP.
Pour les problèmes liés au produit SAP, entrez votre demande d'assistance avec l'outil de l'assistance SAP.
SAP évalue la demande d'assistance puis, s'il semble s'agir d'un problème d'infrastructure Google Cloud, la transfère au composant Google Cloud approprié dans son système : BC-OP-LNX-GOOGLE
ou BC-OP-NT-GOOGLE
.
Exigences liées à l'assistance
Pour bénéficier d'une assistance pour les systèmes SAP ainsi que pour l'infrastructure et les services Google Cloud que ces systèmes utilisent, vous devez satisfaire aux exigences minimales de la formule d'assistance.
Pour en savoir plus sur les exigences minimales concernant l'assistance pour SAP sur Google Cloud, consultez les ressources suivantes :
- Obtenir de l'aide concernant SAP sur Google Cloud
- Note SAP 2456406 – SAP sur Google Cloud Platform : prérequis pour l'assistance (un compte utilisateur SAP est requis)
Se connecter à SAP HANA
Si les VM hôtes ne disposent pas d'adresse IP externe pour SAP HANA, vous ne pouvez vous connecter aux instances SAP HANA que via l'instance bastion à l'aide de SSH ou via le serveur Windows à l'aide de SAP HANA Studio.
Pour vous connecter à SAP HANA via l'instance bastion, connectez-vous à l'hôte bastion, puis aux instances SAP HANA à l'aide du client SSH de votre choix.
Pour vous connecter à la base de données SAP HANA via SAP HANA Studio, utilisez un client Bureau à distance pour vous connecter à l'instance Windows Server. Une fois la connexion établie, installez SAP HANA Studio manuellement, puis accédez à votre base de données SAP HANA.
Tâches post-déploiement
Une fois le déploiement terminé, procédez comme suit :
Modifiez les mots de passe temporaires de l'administrateur système et du super-utilisateur du système SAP HANA. Exemple :
sudo passwd SID_LCadm
Pour en savoir plus sur la modification du mot de passe, consultez la section Réinitialiser le mot de passe utilisateur SYSTEM du système de base de données.
Avant d'utiliser votre instance SAP HANA, configurez et sauvegardez votre nouvelle base de données SAP HANA.
Si votre système SAP HANA est déployé sur une interface réseau VirtIO, nous vous recommandons de vous assurer que la valeur du paramètre TCP
/proc/sys/net/ipv4/tcp_limit_output_bytes
est définie sur1048576
. Cette modification permet d'améliorer le débit réseau global sur l'interface réseau VirtIO sans affecter la latence du réseau.
Pour en savoir plus, consultez les pages suivantes :
Étapes suivantes
Obtenez davantage d'informations en consultant les ressources suivantes :