Recommandations pour High Availability

Utilisez exactement trois nœuds dédiés sur des machines distinctes, une adresse IP virtuelle réservée et un segment de couche 2 partagé ou un domaine de diffusion.

Assurez-vous que les trois nœuds répondent à la configuration système requise documentée.

Maintenez tous les nœuds sur le même VLAN dédié ou sur un autre segment de couche 2 isolé, et maintenez le trafic VRRP Keepalived sur ce segment.

Maintenez les horloges des nœuds synchronisées. Pour le provisionnement, l’écart entre les horloges des nœuds ne doit pas dépasser 1 seconde, et un écart de 5 secondes ou plus est déconseillé.

Utilisez l’adresse IP virtuelle comme seul point de terminaison pour les clients par navigateur, les clients OPC UA, les clients MQTT et les déploiements

FactoryTalk Optix

Studio.

Veillez à ce que les ports du projet soient alignés sur les ports du cluster. Par exemple, le port Web du cluster doit correspondre au port

MoteurDePrésentationWeb

du projet.

Ports préconfigurés

Nom de port	Port par défaut
Moteur de présentation Web (http)	80
Moteur de présentation Web (https)	443
Serveur OPC UA (opcua)	59100
Broker MQTT (mqtt)	8883

Configurez le stockage de rétentivité pour les modifications d’exécution qui doivent persister. Lorsque vous ajoutez le module HighAvailability, le stockage de rétentivité utilise automatiquement la base de données partagée du cluster.

Stockez les autres données critiques pour le basculement en dehors du dossier de fichiers de l’application. Les fichiers générés à l’exécution qui y sont écrits ne se synchronisent pas entre les nœuds, la synchronisation des bases de données intégrées n’est pas prise en charge, et l’architecture documentée prévoit une journalisation dans une base de données externe.

Pendant le basculement, l’application d’exécution s’arrête temporairement. Les opérations telles que la journalisation des données s’arrêtent également. Pendant la transition du nœud, une perte temporaire de connexion entre le client Web et l’application d’exécution se produit. Le temps de basculement varie en fonction du type de défaillance et de la taille de l’application.

Maintenez l’identité et la confiance OPC UA stables pendant le basculement. Fournissez un certificat de serveur et une clé privée dans l’archive du projet, et préremplissez le magasin de confiance avec les certificats client attendus.

Activez le chiffrement du disque sur chaque nœud avant l’installation du cluster. Sans chiffrement de disque, les volumes persistants sous

/var/lib/rancher/k3s/storage

ne sont pas chiffrés.

Utilisez uniquement l’authentification par clé SSH, limitez l’accès SSH au réseau de gestion, maintenez les mises à jour de sécurité automatiques activées, désactivez les services et packages inutiles, maintenez le démon d’audit en cours d’exécution, protégez les données K3s et les informations d’identification de l’agent, et appliquez les correctifs de sécurité du système d’exploitation et de K3s sur chaque nœud.

Configurez les règles de pare-feu de façon à n’autoriser que le trafic provenant de blocs CIDR de confiance vers les ports requis. Bloquez la plage NodePort provenant de sources externes et bloquez tout autre trafic entrant par défaut.

Utilisez les paramètres sécurisés documentés pour les services exposés. Configurez le moteur de présentation Web pour HTTPS, utilisez TLS lorsque MQTT est utilisé et appliquez un mode de sécurité OPC UA sur le serveur OPC UA d’exécution.

Confirmez les problèmes du cluster à l’aide de diagnostics et de journaux exportés avant d’apporter des modifications correctives.

Sauvegardez les données persistantes avant de désinstaller ou de reconstruire le cluster. La désinstallation du cluster supprime le stockage persistant, les données du projet et les données de base de données.