SUSE Linux Enterprise High Availability 15 SP6

Démarrage rapide de l'installation et de la configuration #

Date de publication : 29 septembre 2024

Le présent document explique comment configurer une grappe très basique de deux noeuds à l'aide des scripts d'amorçage fournis par le shell crm. Ce processus inclut la configuration d'une adresse IP virtuelle en tant que ressource de grappe et l'utilisation d'un détecteur de vues de grappe divergentes (SBD pour Split Brain Detector) sur un stockage partagé en tant que mécanisme d'isolation de noeud.

Historique des versions: Documentation de SUSE Linux Enterprise High Availability

Il est autorisé de copier, distribuer et/ou modifier ce document conformément aux conditions de la licence de documentation libre GNU version 1.2 ou (à votre discrétion) 1.3, avec la section permanente qu'est cette mention de copyright et la licence. Une copie de la version de licence 1.2 est incluse dans la section intitulée « Licence de documentation libre GNU ».

Pour les marques commerciales SUSE, consultez le site Web https://www.suse.com/company/legal/. Toutes les marques commerciales de fabricants tiers appartiennent à leur propriétaire respectif. Les symboles de marque (®, ™, etc.) désignent des marques commerciales de SUSE et de ses sociétés affiliées. Des astérisques (*) désignent des marques commerciales de fabricants tiers.

Toutes les informations de cet ouvrage ont été regroupées avec le plus grand soin. Cela ne garantit cependant pas sa complète exactitude. Ni SUSE LLC, ni les sociétés affiliées, ni les auteurs, ni les traducteurs ne peuvent être tenus responsables des erreurs possibles ou des conséquences qu'elles peuvent entraîner.

1 Scénario d'utilisation #

Les procédures décrites dans le présent document permettent de configurer une grappe de base à deux noeuds présentant les caractéristiques suivantes :

Deux noeuds : alice (adresse IP : 192.168.1.1) et bob (adresse IP : 192.168.1.2), connectés entre eux via le réseau.
Une adresse IP virtuelle flottante (192.168.1.10), qui permet aux clients de se connecter au service quel que soit le noeud physique sur lequel il s'exécute. Cette adresse IP est utilisée pour se connecter à l'outil de gestion graphique Hawk2.
Un périphérique de stockage partagé, utilisé comme mécanisme d'isolation SBD. Cela évite les scénarios de grappes divergentes.
Un système de basculement des ressources d'un noeud vers l'autre en cas de défaillance de l'hôte actif (configuration active/passive).

La grappe à deux noeuds peut être utilisée à des fins de test ou comme une configuration de grappe minimale que vous pouvez étendre par la suite. Avant d'utiliser la grappe dans un environnement de production, consultez le Administration Guide pour la modifier celle-ci en fonction de vos besoins.

2 Configuration système requise #

Cette section décrit la configuration système minimale requise pour le scénario présenté dans la Section 1. Pour que la grappe puisse être utilisée dans un environnement de production, reportez-vous à la liste complète dans le Chapter 2, System requirements and recommendations.

2.1 Configuration matérielle requise #

Serveurs

Deux serveurs exécutant les logiciels spécifiés à la Section 2.2, « Configuration logicielle requise ».

Ces serveurs peuvent être des machines virtuelles ou sans système d'exploitation. Ils ne nécessitent pas une configuration matérielle identique (mémoire, espace disque, etc.), mais doivent avoir la même architecture. Les grappes multi plate-forme ne sont pas prises en charge.

Canaux de communication

Au moins deux médias de communication TCP/IP par noeud de grappe. L'équipement réseau doit prendre en charge le moyen de communication que vous souhaitez utiliser pour les communications au sein de la grappe, à savoir la multidiffusion ou la monodiffusion. Les médias de communication doivent prendre en charge un débit de données de 100 Mbit/s ou plus. La prise en charge d'une grappe requiert au moins deux chemins de communication redondants. Cette configuration peut être obtenue via :

une liaison de périphérique réseau (de préférence) ;
un deuxième canal de communication dans Corosync.

Isolation de noeud/STONITH

Périphérique d'isolation de noeuds (STONITH) pour éviter les scénarios de grappes divergentes. Il peut s'agir d'un périphérique physique (un bouton marche/arrêt) ou d'un mécanisme de type SBD associé à un système de surveillance (watchdog). Le mécanisme SBD peut être utilisé avec un stockage partagé ou en mode sans disque. Ce document décrit l'utilisation de SBD avec un stockage partagé. Les conditions suivantes doivent être remplies :

Un périphérique de stockage partagé. Pour plus d'informations sur la configuration du stockage partagé, reportez-vous au document Storage Administration Guide for SUSE Linux Enterprise Server. Si vous avez uniquement besoin d'un stockage partagé de base à des fins de test, reportez-vous à l'Annexe A, Stockage iSCSI de base pour SBD.
Le chemin d'accès au périphérique de stockage partagé doit être persistant et cohérent sur tous les noeuds de la grappe. Utilisez des noms de périphériques stables, tels que /dev/disk/by-id/dm-uuid-part1-mpath-abcedf12345.
Le périphérique SBD ne doit pas utiliser de RAID, LVM ou DRBD* basé sur l'hôte.

Pour plus d'informations sur STONITH, reportez-vous au Chapter 12, Fencing and STONITH. Pour plus d'informations sur SBD, reportez-vous au Chapter 13, Storage protection and SBD.

2.2 Configuration logicielle requise #

Tous les noeuds nécessitent au moins les modules et extensions suivants :

Basesystem Module 15 SP6
Server Applications Module 15 SP6
SUSE Linux Enterprise High Availability 15 SP6

2.3 Autres conditions requises et recommandations #

Synchronisation horaire

Les noeuds de la grappe doivent se synchroniser avec un serveur NTP situé en dehors de la grappe. Depuis SUSE Linux Enterprise High Availability 15, chrony est l'implémentation par défaut du protocole NTP. Pour plus d'informations, reportez-vous au manuel Administration Guide for SUSE Linux Enterprise Server 15 SP6.

La grappe peut ne pas fonctionner correctement si les noeuds ne sont pas synchronisés, ou même s'ils sont synchronisés mais présentent des fuseaux horaires différents. En outre, les fichiers journaux et les rapports de grappe sont très difficiles à analyser en l'absence de synchronisation. Si vous utilisez les scripts d'amorçage, le système vous avertira si un service NTP n'est pas encore configuré.

Nom d'hôte et adresse IP

Utilisez des adresses IP statiques.
Seule l'adresse IP principale est prise en charge.
Répertoriez tous les noeuds de la grappe, avec leur nom d'hôte complet et leur nom d'hôte abrégé, dans le fichier /etc/hosts. Il est essentiel que les membres de la grappe puissent se trouver sur la base de leurs noms. Si les noms ne sont pas disponibles, la communication interne au sein de la grappe ne fonctionnera pas.

SSH

Tous les noeuds de la grappe doivent pouvoir accéder les uns aux autres via le protocole SSH. Des outils tels que crm report (pour le dépannage) et l'explorateur d'historique de Hawk2 requièrent un accès SSH sans mot de passe entre les noeuds, faute de quoi ils peuvent uniquement collecter des données du noeud actif.

Si vous utilisez les scripts d'amorçage pour configurer la grappe, les clés SSH sont automatiquement créées et copiées.

3 Présentation des scripts d'amorçage #

Les commandes suivantes exécutent des scripts d'amorçage qui ne nécessitent qu'un minimum de temps et d'effort manuel.

Le script crm cluster init permet de définir les paramètres de base nécessaires pour la communication au sein de la grappe. À ce moment-là, vous disposez d'une grappe opérationnelle comportant un seul noeud.
Le script crm cluster join vous permet d'ajouter des noeuds à votre grappe.
Le script crm cluster remove vous permet de supprimer des noeuds de votre grappe.

Les options définies par les scripts d'amorçage peuvent ne pas être les mêmes que les paramètres par défaut de Pacemaker. Vous pouvez vérifier les paramètres modifiés par les scripts d'amorçage dans /var/log/crmsh/crmsh.log. Toutes les options définies au cours du processus d'amorçage peuvent être modifiées ultérieurement à l'aide du module de cluster YaST. Pour plus de détails, reportez-vous au Chapter 4, Using the YaST cluster module.

Le script d'amorçage crm cluster init vérifie et configure les composants suivants :

NTP

Vérifie si NTP est configuré pour se lancer au moment du démarrage. Si ce n'est pas le cas, un message apparaît.

SSH

Crée les clés SSH nécessaires pour que les noeuds de la grappe puissent accéder les uns aux autres sans mot de passe.

Csync2

Configure Csync2 de manière à répliquer les fichiers de configuration sur tous les noeuds d'une grappe.

Corosync

Configure le système de communication de la grappe.

SBD/surveillance

Vérifie si un système de surveillance existe et vous demande si vous souhaitez configurer SBD comme mécanisme d'isolation de noeud.

Adresse IP virtuelle flottante

Vous demande si vous souhaitez configurer une adresse IP virtuelle pour l'administration de la grappe à l'aide de Hawk2.

Pare-feu

Ouvre les ports du pare-feu qui sont nécessaires pour les communications de grappe.

Nom de la grappe

Définit un nom pour la grappe. Par défaut, il s'agit de hacluster. Ce nom est facultatif et principalement utile pour les grappes géographiques. En règle générale, le nom de la grappe reflète l'emplacement géographique et facilite la distinction d'un site à l'intérieur d'une grappe Geo.

QDevice/QNetd

Vous demande si vous souhaitez configurer QDevice/QNetd pour participer aux décisions de quorum. Nous vous recommandons d'utiliser QDevice et QNetd pour les grappes avec un nombre pair de noeuds, et en particulier pour les grappes à deux noeuds.

Cette configuration n'est pas abordée ici, mais vous pouvez la définir ultérieurement comme décrit dans le Chapter 14, QDevice and QNetd.

Note : configuration de grappe pour différentes plates-formes

Le script crm cluster init détecte l'environnement système (par exemple, Microsoft Azure) et ajuste certains paramètres de grappe en fonction du profil de cet environnement. Pour plus d'informations, reportez-vous au fichier /etc/crm/profiles.yml.

4 Installation des paquets Haute disponibilité #

Les paquet de configuration et de gestion d'une grappe sont inclus dans le modèle d'installation High Availability. Ce modèle n'est disponible qu'après l'installation de SUSE Linux Enterprise High Availability.

Vous pouvez vous enregistrer auprès du SUSE Customer Center et installer SUSE Linux Enterprise High Availability lors de l'installation de SUSE Linux Enterprise Server ou après l'installation. Pour plus d'informations, reportez-vous au manuel Deployment Guide pour SUSE Linux Enterprise Server.

Procédure 1 : Installation du modèle Haute disponibilité #

Installez le modèle Haute disponibilité à partir de la ligne de commandes :
```
# zypper install -t pattern ha_sles
```
Installez le modèle Haute disponibilité sur toutes les machines qui feront partie de votre grappe.
Note : installation des paquets logiciels sur tous les noeuds
Pour procéder à une installation automatisée de SUSE Linux Enterprise Server 15 SP6 et de SUSE Linux Enterprise High Availability 15 SP6, utilisez AutoYaST pour cloner des noeuds existants. Pour plus d'informations, reportez-vous au Section 3.2, “Mass installation and deployment with AutoYaST”.

5 Utilisation de SBD pour l'isolation des noeuds #

Avant de pouvoir configurer SBD avec le script d'amorçage, vous devez activer une surveillance (watchdog) sur chaque noeud. SUSE Linux Enterprise Server est livré avec plusieurs modules de noyau qui fournissent des pilotes de surveillance spécifiques au matériel. SUSE Linux Enterprise High Availability utilise le daemon SBD comme composant logiciel pour « alimenter » le système de surveillance.

La procédure suivante utilise la surveillance softdog.

Important : limites de la surveillance softdog

Le pilote softdog part du principe qu'au moins un processeur est toujours en cours d'exécution. Si tous les processeurs sont bloqués, le code dans le pilote softdog qui devrait redémarrer le système ne sera jamais exécuté. En revanche, les systèmes de surveillance matérielle continuent à travailler même si tous les processeurs sont bloqués.

Avant d'utiliser la grappe dans un environnement de production, il est vivement recommandé de remplacer le module softdog par le module matériel qui correspond le mieux à votre matériel.

Toutefois, si aucun système de surveillance ne correspond à votre matériel, softdog peut être utilisé en tant que module de surveillance de noyau.

Procédure 2 : Activation de la surveillance softdog pour SBD #

Sur chaque noeud, activez la surveillance logicielle (softdog) :

# echo softdog > /etc/modules-load.d/watchdog.conf
# systemctl restart systemd-modules-load

Vérifiez si le module de surveillance logicielle est chargé correctement :
```
# lsmod | grep dog
softdog           16384  1
```

6 Configuration du premier noeud #

Configurez le premier noeud à l'aide du script crm cluster init. Cette opération ne nécessite qu'un minimum de temps et d'effort manuel.

Procédure 3 : Configuration du premier noeud (alice) à l'aide du script crm cluster init #

Connectez-vous au premier noeud de la grappe en tant qu'utilisateur root ou en tant qu'utilisateur disposant de privilèges sudo.
Important : accès à la clé SSH
La grappe utilise un accès SSH sans mot de passe pour la communication entre les noeuds. Le script crm cluster init vérifie les clés SSH et les génère si elles n'existent pas déjà.
Dans la plupart des cas, les clés SSH de l'utilisateur root ou sudo doivent exister (ou être générées) sur le noeud.
Les clés SSH d'un utilisateur sudo peuvent également exister sur une machine locale et être transmises au noeud via le réacheminement de l'agent SSH. Cela nécessite une configuration supplémentaire qui n'est pas décrite pour cette configuration minimale. Pour plus d'informations, reportez-vous au Section 5.5.1, “Logging in”.
Lancez le script d'amorçage :
```
# crm cluster init --name CLUSTERNAME
```
Remplacez la marque de réservation CLUSTERNAME par un nom pertinent, comme l'emplacement géographique de votre grappe (par exemple, amsterdam). Cela est particulièrement utile pour créer un Geo Cluster ultérieurement, car cela simplifie l'identification d'un site.
Si vous avez besoin de la multidiffusion plutôt que la monodiffusion (par défaut) pour la communication de votre grappe, utilisez l'option --multicast (ou -U).
Le script vérifie la configuration NTP et la présence d'un service de surveillance matérielle. Le cas échéant, il génère les clés SSH publiques et privées utilisées pour l'accès SSH et la synchronisation Csync2, et démarre les services respectifs.
Configurez la couche de communication de grappe (Corosync) :
1. Spécifiez une adresse réseau pour la liaison. Par défaut, le script propose l'adresse réseau de eth0. Vous pouvez également spécifier une autre adresse réseau, par exemple bond0.
2. Acceptez le port proposé (5405) ou entrez-en un autre.
Configurez SBD comme mécanisme d'isolation de noeud :
1. Spécifiez y pour confirmer que vous souhaitez utiliser le SBD.
2. Entrez un chemin d'accès persistant à la partition du périphérique de blocs pour lequel vous souhaitez utiliser SBD. Le chemin doit être cohérent sur tous les noeuds de la grappe.
  Le script crée une petite partition sur le périphérique à utiliser pour SBD.
Configurez une adresse IP virtuelle pour l'administration de la grappe avec Hawk2 :
1. Spécifiez y pour confirmer que vous souhaitez configurer une adresse IP virtuelle.
2. Spécifiez une adresse IP inutilisée que vous souhaitez employer comme adresse IP d'administration pour Hawk2 : 192.168.1.10.
  Au lieu de vous connecter à un noeud de grappe individuel avec Hawk2, vous pouvez vous connecter à l'adresse IP virtuelle.
Choisissez de configurer QDevice et QNetd. Pour la configuration minimale décrite dans ce document, refusez pour le moment avec l'option n. Vous pouvez configurer QDevice et QNetd ultérieurement, comme décrit dans le Chapter 14, QDevice and QNetd.

Enfin, le script démarre les services de grappe pour mettre en ligne la grappe et activer Hawk2. L'URL à utiliser pour Hawk2 apparaît à l'écran.

Vous disposez maintenant d'une grappe opérationnelle comportant un seul noeud. Pour visualiser son état, procédez comme suit :

Procédure 4 : Connexion à l'interface Web de Hawk2 #

Sur une machine, démarrez un navigateur Web et assurez-vous que JavaScript et les cookies sont activés.
En tant qu'URL, entrez l'adresse IP virtuelle que vous avez configurée avec le script d'amorçage :
```
https://192.168.1.10:7630/
```
Note : avertissement de certificat
Si un avertissement de certificat s'affiche la première fois que vous tentez d'accéder à l'URL, un certificat auto-signé est utilisé. Par défaut, les certificats auto-signés ne sont pas considérés comme fiables.
Demandez à votre opérateur de grappe de vous fournir les informations relatives au certificat afin de vérifier ce dernier.
Pour continuer, vous pouvez ajouter une exception dans le navigateur afin d'ignorer l'avertissement.
Dans l'écran de connexion de Hawk2, spécifiez le Nom d'utilisateur et le Mot de passe de l'utilisateur qui a été créé par le script d'amorçage (utilisateur hacluster, mot de passe linux).
Important : mot de passe sécurisé
Remplacez dès que possible le mot de passe par défaut par un mot de passe sécurisé :
```
# passwd hacluster
```
Cliquez sur Se connecter. L'interface Web Hawk2 affiche l'écran État par défaut :
Figure 1 : état de la grappe à un noeud dans Hawk2 #

7 Ajout du deuxième noeud #

Ajoutez un deuxième noeud à la grappe avec le script d'amorçage crm cluster join. Le script nécessite uniquement un accès à un noeud de grappe existant et procède automatiquement à la configuration de base sur la machine actuelle.

Pour plus d'informations, reportez-vous à la commande crm cluster join --help.

Procédure 5 : ajout du deuxième noeud (bob) à l'aide du script crm cluster join #

Connectez-vous au second noeud en tant qu'utilisateur root ou en tant qu'utilisateur disposant de privilèges sudo.
Lancez le script d'amorçage :
Si vous configurez le premier noeud en tant qu'utilisateur root, vous pouvez exécuter cette commande sans paramètres supplémentaires :
```
# crm cluster join
```
Si vous configurez le premier noeud en tant qu'utilisateur sudo, vous devez spécifier cet utilisateur avec l'option -c :
```
> sudo crm cluster join -c USER@alice
```
Si NTP n'est pas configuré pour se lancer au moment du démarrage, un message s'affiche. Le script recherche également un périphérique de surveillance matériel. Vous êtes averti si aucun n'est présent.
Si vous n'avez pas encore spécifié alice avec -c, vous êtes invité à saisir l'adresse IP du premier noeud.
Si vous n'aviez pas encore configuré d'accès SSH sans mot de passe entre les deux machines, le système vous invite à spécifier le mot de passe du premier noeud.
Une fois connecté au noeud spécifié, le script copie la configuration Corosync, configure SSH et Csync2, met la machine actuelle en ligne en tant que nouveau noeud de grappe et démarre le service requis pour Hawk2.

Vérifiez l'état de la grappe dans Hawk2. Dans État › Noeuds, vous devriez voir deux noeuds présentant un état vert :

Figure 2 : état de la grappe à deux noeuds #

8 Test de la grappe #

Les tests suivants peuvent vous aider à identifier les problèmes liés à la configuration de la grappe. Cependant, un test réaliste implique des cas d'utilisation et des scénarios spécifiques. Avant d'utiliser la grappe dans un environnement de production, testez-la scrupuleusement en fonction de l'utilisation que vous comptez en faire.

La commande sbd -d DEVICE_NAME list liste tous les noeuds visibles par SBD. Pour la configuration décrite dans ce document, la sortie doit afficher à la fois alice et bob.
La Section 8.1, « Test du basculement des ressources » est un test simple qui permet de vérifier si la grappe déplace l'adresse IP virtuelle vers l'autre noeud lorsque le noeud qui exécute actuellement la ressource est mis en mode standby.
La Section 8.2, « Test à l'aide de la commande crm cluster crash_test » simule les échecs de grappe et signale les résultats.

8.1 Test du basculement des ressources #

La procédure ci-après permet d'effectuer un test rapide du basculement des ressources :

Procédure 6 : test du basculement des ressources #

Ouvrez un terminal et exécutez une commande ping sur l'adresse 192.168.1.10, autrement dit votre adresse IP virtuelle :
```
# ping 192.168.1.10
```
Connectez-vous à Hawk2.
Dans État › Ressources, vérifiez sur quel noeud s'exécute l'adresse IP virtuelle (ressource admin_addr). Cette procédure suppose que la ressource s'exécute sur alice.
Mettez alice en mode Veille :
Figure 3 : noeud alice en mode veille #
Cliquez sur État › Ressources. La ressource admin_addr a été migrée vers bob.

Pendant la migration, vous devriez normalement voir un flux continu de requêtes ping envoyées à l'adresse IP virtuelle. Cela montre que la configuration de grappe et l'adresse IP flottante fonctionnent correctement. Annulez la commande ping en appuyant sur Ctrl– C.

8.2 Test à l'aide de la commande `crm cluster crash_test` #

La commande crm cluster crash_test déclenche les dysfonctionnements de grappe afin de repérer les problèmes. Avant d'utiliser la grappe en production, il est recommandé d'appliquer cette commande pour vous assurer que tout fonctionne comme prévu.

La commande prend en charge les contrôles suivants :

--split-brain-iptables: Ce test simule un scénario de grappes divergentes en bloquant le port Corosync. Il vérifie si un noeud peut être délimité comme prévu.
--kill-sbd/--kill-corosync/ --kill-pacemakerd: Supprime les daemons pour SBD, Corosync et Pacemaker. Après avoir exécuté l'un de ces tests, vous pouvez trouver un rapport dans le répertoire /var/lib/crmsh/crash_test/. Le rapport comprend une description de cas de test, une consignation des opérations et une explication des résultats possibles.
--fence-node NODE: Ce test isole le noeud spécifique transmis par la ligne de commandes.

Pour plus d'informations, reportez-vous à la commande crm cluster crash_test --help.

Exemple 1 : Test de la grappe : isolation des noeuds #

# crm_mon -1
Stack: corosync
Current DC: alice (version ...) - partition with quorum
Last updated: Fri Mar 03 14:40:21 2020
Last change: Fri Mar 03 14:35:07 2020 by root via cibadmin on alice

2 nodes configured
1 resource configured

Online: [ alice bob ]
Active resources:

 stonith-sbd    (stonith:external/sbd): Started alice

# crm cluster crash_test --fence-node bob

==============================================
Testcase:          Fence node bob
Fence action:      reboot
Fence timeout:     60

!!! WARNING WARNING WARNING !!!
THIS CASE MAY LEAD TO NODE BE FENCED.
TYPE Yes TO CONTINUE, OTHER INPUTS WILL CANCEL THIS CASE [Yes/No](No): Yes
INFO: Trying to fence node "bob"
INFO: Waiting 60s for node "bob" reboot...
INFO: Node "bob" will be fenced by "alice"!
INFO: Node "bob" was successfully fenced by "alice"

Pour surveiller le changement d'état de bob au cours du test, connectez-vous à Hawk2 et accédez à État › Noeuds.

9 Étapes suivantes #

Les scripts d'amorçage constituent un moyen rapide pour configurer une grappe Haute disponibilité de base qui peut être utilisée à des fins de test. Toutefois, pour la développer en grappe Haute disponibilité fonctionnelle utilisable dans des environnements de production, d'autres étapes sont recommandées.

Étapes recommandées pour réaliser la configuration de la grappe Haute disponibilité #

Ajout de noeuds supplémentaires

Ajoutez d'autres noeuds à la grappe à l'aide de l'une des méthodes suivantes :

Pour les noeuds individuels, utilisez le script crm cluster join comme décrit à la Section 7, « Ajout du deuxième noeud ».
Pour l'installation en masse de plusieurs noeuds, utilisez AutoYaST comme décrit dans le Section 3.2, “Mass installation and deployment with AutoYaST”.

Une grappe normale peut contenir jusqu'à 32 noeuds. Avec le service pacemaker_remote, il est possible d'étendre les grappes Haute disponibilité pour inclure des noeuds supplémentaires au-delà de cette limite. Reportez-vous à l'Pacemaker Remote Quick Start pour plus de détails.

Configuration de QDevice

Si la grappe comporte un nombre pair de noeuds, configurez QDevice et QNetd pour participer aux décisions de quorum. QDevice fournit un nombre configurable de votes, ce qui permet à une grappe de supporter plus de défaillances de noeuds que ne le permettent les règles de quorum standard. Pour plus de détails, reportez-vous au Chapter 14, QDevice and QNetd.

Activation d'une surveillance (watchdog) matérielle

Avant d'utiliser la grappe dans un environnement de production, remplacez le module softdog par le module matériel qui correspond le mieux à votre matériel. Pour plus de détails, reportez-vous au Section 13.6, “Setting up the watchdog”.

10 Pour plus d'informations #

Pour plus de documentation sur ce produit, rendez-vous à l'adresse https://documentation.suse.com/sle-ha/. Pour des informations concernant d'autres tâches de configuration et d'administration, reportez-vous au manuel Administration Guide.