Présentation
Nous allons voir comment Installer une interface WEB pour la gestion du cluster
Le site Web est rattache au process pcsd
Ceci nous permettra d’avoir d’un coup d’œil l’état de santé de notre cluster
Règle de nommage des services Windows
Préambule
Nous pouvons dire merci à Mr Bill 😀 de nous avoir pondu un Os ayant des services dépendants de la langue choisie lors de l’installation ( et ça me donne du travail 😀 ).
Les conséquences un service SNMP s’appelera :
- Service SNMP en Français
- SNMP service en Anglais
- Je vous laisse imaginer dans les autres langues 😀
Cela à un impacte non négligeable dans la mise en supervision d’un serveur Windows.
Il va falloir créer un template Windows en fonction de la langue d’installation de l’Os. Et là on se dit WhouAAAAAA, il va falloir créer un template pour chaque langue ?
Et là, on se dit que cela va être galère si il faut gérer toutes les langues que Windows parle, mais c’est que la partie émergée de l’iceberg.
En effet ce n’est pas tout. En fonction de la version de ce super Os, certains services ont disparu, d’autres sont apparus.
L’expérience m’a monté que la supervision d’un serveur ZINDOWS (pour ceux qui auraient leur clavier en QWERTY 😀 ) nécessite de prendre en compte non seulement la version de l’Os mais aussi la langue dans laquelle il a été installé.
Merci de ne pas habité en Serbie ou en république Tchèque (gérer une langue en mode latin avec des caractères que je n’ai pas sur mon clavier et en cyrillique en plus 😀 ), j’ai que l’anglais et le français à gérer 🙂
Arrêtons les digressions et attaquons nous au vif du sujet.
Nous allons donc faire en sorte de prendre en compte les OS de la version 2000 à 2012 en français et en anglais ( j’ai eu des clients en NT4 même au 21ème siècle 😀 mais c’est pas le sujet).
Comment allons nous créer des Templates simple a maintenir et suffisamment flexibles pour ne pas avoir a faire des modifications dans tous les Templates afin d’avoir le résultat voulu.
Mise en place de la réplication des bases
Préparation du compte Mysql
Sur les 2 serveurs Mysql
- Arrêter les bases de données
- Modification du compte mysql
- Génération des clés ssh
- Echange des clés ssh entre les serveurs bases de données
- Copier le contenu de la clé publique du serveur DB1 sur DB2 et inversement dans le fichier ~/.ssh/authorized_keys
- Modifier les droits du fichier
- Tester les connexions
Configuration de MariaDB
- Ajouter les lignes suivantes dans le fichier /etc/my.cnf.d/centreon.cnf
- Penser à mettre 1 pour le master et 2 pour le slave
- Laisser le read_only commenté
Redémarrer le services sur les 2 serveurs
Installation d’un cluster à 4 nœuds
Prérequis
Compréhension
Connaissances Indispensables :
- Linux
- Shell
- Gestion des utilisateurs
- LVM
- Fonctionnement de centreon
Avant de suivre cette procédure, il est recommandé d’avoir un niveau de connaissance satisfaisant du système d’exploitation Linux, de Centreon et des outils de clustering Pacemaker-Corosync pour bien comprendre ce qui va être fait et savoir résoudre un éventuel incident. En pointillé sur les schémas ci-dessous les flux en attente.
Fonctionnement initial de la plateforme ( Site A)
Bascule sur le site secondaire (Site B)
Centreon Auto-discovery
Présentation
Centreon autodiscovery est un module centreon permettant la détection des disques, FS,interfaces réseau des équipements physiques.
Fonctionnement
- Un crontab sur le serveur central lance toutes les règles actives
- Centreon lance une commande snmpget pour déterminer les éléments à superviser
- Applique la règle de découverte :
- Rattache le bon template (Host ou Service) en fonction des éléments découverts
- Applique les différents filtres en fonction des paramétrages de la règle
Règle de nommage des services Linux
Préambule
Pour moi la supervision des serveurs linux est des plus intéressantes :
- C’est un système ouvert
- L’Os est suffisamment robuste pour permettre de prendre la main sur le serveur même si un service est défaillant
- Il n’y a pas ou très peu de boite noires
- Les fichiers de logs sont suffisamment parlant pour connaitre le hic 😀
- Avec une gestion par fichier, la gestion du serveur est relativement simple
La supervision d’un serveur Linux peut paraître simple.
Pour paraphraser la première phrase de « Linux pour les nuls » : Tout est fichier 😀
Une fois que l’on a dit cela, on a tout dit et rien dit non plus 😛
Essayons de comprendre le fonctionnement d’un serveur Linux.
Plusieurs aspects sont à prendre en compte :
- Le noyau de linux (je ne parlerais que des Os rencontrés en entreprise) :
- Façon Debian
- Façon RedHat
- Façon SuSe (même si c’est assez proche de RedHat)
- Gestion du démarrage du serveur en fonction de la version de l’OS
- Debian
- Depuis Debian 9 : systemD
- Avant Debian 8 : initD ou systemD
- Avant debian 8 : initD
- RedHat
- Depuis RedHat7 : SystemD
- Avant RedHat7 : initD
- Debian
Il faut prendre en compte également ces différents.
Par exemple :
- iptables est devenu firewalld
- Le nom des interfaces à changer
- Les outils de gestion des paquets diffèrent
- Debian : apt-get
- RedHat : yum
- SuSe : zipper ou yast2
- Et ce ne sont pas les seuls différences et ce n’est pas le sujet de l’article 😀
La supervision doit être capable de prendre en compte ces différents aspect, sans rendre la maintenance de la supervision plus complexe.
Dans la suite de l’article nous allons donc mettre en place les templates nécessaires pour la supervision d’un serveur linux en fonction du noyaux et de la version.
NB : Je ne parlerais donc pas des distributions « Exotiques » dans cet article 😀
Règle de nommage des services
Préambule
Nous allons voir dans cet article comment oraginiser ses templates de service et les indicateurs présentés dans la vue monitoring.
Règles de nommage des indicateurs
Comprendre les indicateurs
Règles de Nommage pour les services :
Les indicateurs sont organisés de la façon suivante de manière générale :
- Brique
- Famille
- Type
- Domaine
- Nom Indicateur
ci-dessous nous aurons :
- Le nom du template de service utilisé
- Le nom du service présenté dans la supervision
Un exemple lié à l’OS (Pour Linux)
TS_OS-Linux-Disk-/var-Usage –> Linux-Disk-/var-Usage
- Brique : OS
- Famille : Linux
- Type : Disk
- Domaine : <Nom du FS>
- Type Indicateur : Utilisation
TS_OS-Linux-Process-sshd-Status –> OS-Linux-Process-sshd-Status
- Brique : OS
- Famille : Linux
- Type : Process
- Domaine : <Nom du Process>
- Type Indicateur : Etat
TS_OS-Linux-SYS-Memory-Usage –> OS-Linux-SYS-Memory-Usage
- Brique : OS
- Famille : Linux
- Type : System
- Domaine : <Composant système>
- Type Indicateur : Utilisation
Un exemple applicatif
TS_App-DB-Oracle-Process-ora_pmon –> App-DB-Oracle-Process-ora_pmon
- Brique : APP(aplicatif)
- Famille : DB ( Database )
- Type : Oracle
- Domaine : Process(us)
- Nom Indicateur : ora_pmon
Règles de nommage des objets
Liste des forces en présence
Préambule
Il n’est pas rare d’avoir des pages Centreon avec une liste interminable d’indicateur.
Quand nous utilisons l’ascenseur de notre indicateur et que nous sommes en bas de la page le menu disparaît et c’est la cata 😀
Je vais donc vous présenter un méthode perfectible mais simple d’identifier l’objet que vous êtes en train de manipuler.
Le chois de préfixer les objets est simple.
Cela permet :
- De ne pas modifier les templates fournis par centreon ( facilitant les mise à jours de Centreon)
- De faire dépendre nos templates préfixés des templates Centreon en les surchargeant selon nos besoins et en prenant en compte les correctifs que les mises à jours pourraient apporter.
- De faciliter la maintenance des objets structurant permettant de déploiement des indicateurs
Organiser ces indicateurs dans la vue monitoring
But de cet article
Le but de cet article est de vous présenter comment vos indicateurs seront :
- Plus compréhensibles
- Regroupés par périmètre de supervision
- Plus visibles pour vos équipements que vous superviser
Dans mon travail de tous les jours, j’avoue que les règles que je vais vous présenter m’aident grandement.
Elles permettent :
- Pour novice en supervision, de comprendre l’objet de configuration qu’il est en train de manipuler sans ambiguïté.
- Faciliter la gestion des ACLs
- dans l’exploitation de la supervision :
- D’optimiser la compréhension des indicateurs qui sont présentés
- De comprendre le domaine d’application de l’indicateur
Sécuriser son serveur dédié proxmox avec iptables
Préambule
But de cet article
Dans cette article nous allons mettre en place une solution basée sur iptables-persistent et fail2ban afin de sécuriser notre serveur.
A la fin de l’article :
- Notre serveur hôte :
- Bloquera les différentes attaques du grand internet. Il faut le reconnaître qu’elles viennent souvent de Chine, de Russie ou d’Inde.
- Fera du NAT pour permettre de se connecter aux VM via internet.
- Permettra aux VM de se connecter à internet pour les mises à jour.
- Permettra aux VM de communiquer entre elles.
- Les VM :
- Auront accès à internet.
- Accepteront les connexion SSH sur un pour dédié pour l’administration