Ajout de deux nouvelles nodes au serveur

proxmox/README.md

@@ -4,9 +4,9 @@ Vous trouverez ici toute la documentation relative au déploiement de Proxmox.
 # Table des matières
 1. [Introduction à la virtualisation](introduction_a_la_virtualisation.md)
 2. [Installation des hyperviseurs](installation_hyperviseurs.md)
-3. [Systèmes de fichiers](systeme_de_fichier.md)
+3. [Système de fichiers](systeme_de_fichier.md)
 4. [Système de sauvegarde](systeme_de_sauvegarde.md)
-5. [Cluster](cluster)
-6. [Haute Disponibilité](#)
+5. [Cluster](creation_cluster.md)
+6. [Haute Disponibilité](haute_disponibilite)
 7. [Gestion de l'authentification](#)
 8. [Sécurisation des conteneurs / VM](securisation)

proxmox/cluster/README.md

@@ -1,7 +0,0 @@
-# Mise en place du cluster
-
-Vous trouverez ici toute la documentation relative à la mise en place du multicast pour le corosync, du cluster Proxmox et de l'instance de quorum.
-
-# Table des matières
-1. [Montage du cluster](creation_cluster.md)
-2. [Instance de quorum](quorum.md)

proxmox/cluster/quorum.md

@@ -1,40 +0,0 @@
-# Respect du quorum avec seulement deux nodes
-
-La technologie corosync a besoin de 3 votes minimum pour avoir le quorum et éviter les risques de splitbrain en cas de crash d'une des nodes.
-
-Nous ne disposons que de deux nodes, nous allons donc mettre en place un "Corosync External Vote". Il suffit d'un conteneur sur une autre machine que nous appellerons instance de quorum.
-
-## Mise en place de l'instance de quorum
-
-#### Sur le conteneur de l'instance de quorum
-```
-apt-get install corosync-qnetd
-systemctl enable corosync-qnetd
-systemctl start corosync-qnetd
-```
-
-#### Sur nos deux nodes
-```
-apt-get install corosync-qdevice
-systemctl enable corosync-qdevice
-systemctl start corosync-qdevice
-```
-
-#### Depuis chacune de nos nodes
-```
-ssh-copy-id -i /root/.ssh/id_rsa root@ip_autre_node
-ssh-copy-id -i /root/.ssh/id_rsa root@ip_instance_quorum
-```
-## Ajout de l'instance au cluster sigma depuis Alpha
-
-Maintenant que notre instance de quorum est configurée, nous allons l'ajouter au cluster Sigma
-```
-pvecm qdevice setup <ip_instance_quorum>
-```
-
-On vérifie que notre cluster contienne nos deux nodes et une instance de quorum
-```
-pvecm status
-```
-
-Nous avons maintenant trois votes, il y a donc suffisamment d'instances pour éviter le split-brain en cas de crash d'une node car, même avec une node en moins, le quorum sera respecté.

proxmox/haute_disponibilite.md

@@ -0,0 +1,42 @@
+# Haute Disponibilité
+
+Nous allons utiliser deux types de Hautes Disponibilité (HA) :
+- La solution de HA proposé par Proxmox qui permet de migrer des conteneurs entre des nodes,
+- De la Haute Disponibilité via une IP Virtuelle grâce à Keep-alived.
+
+Pour les services vitaux (HAProxy, NGINX, LDAP...) nous utiliserons une IP virtuelle, les services seront déjà présent sur toute les nodes c'est keepalived qui s'occupera de toujours rendre accessible le service.
+
+Pour les services moins important (Cloud, Git...) nous utiliserons la solution proposé par Proxmox.
+
+Nous avons fait cette distinction car ZFS ne permet pas la migration instantanée d'un conteneur en cas de chute d'une node, surtout s'il doit migrer plusieurs conteneurs en même temps.
+
+Les services redondés et utilisant keepalived seront :
+- HAProxy : un conteneur sur chaque node, celui de Alpha sera Master,
+- NGINX : un conteneur sur chaque node load-balancing par HAProxy,
+- LDAP : un conteneur sur chaque node, réplication des données grâce à slapd et accessibilité / loadbalancing via Keepalived,
+- Redis : un conteneur sur Alpha, un sur Sigma,
+- Service Mail : un conteneur sur Alpha, un sur Sigma,
+- DNS : un conteneur sur Alpha un sur Sigma.
+
+
+## Répartition non exhaustive des conteneurs entre les nodes
+
+OPNSense -> Alpha, Beta et Sigma
+HAProxy -> Alpha, Beta et Sigma
+NGINX -> Alpha, Beta et Sigma
+Redis -> Alpha et Sigma
+LDAP -> Alpha et Sigma
+Git -> Alpha
+Mattermost -> Alpha
+NextCloud -> Beta
+Mail -> Alpha et Sigma
+CTF -> Beta (3 services)
+LDAPUI -> Alpha
+DNS -> Beta
+Proxy interne -> Beta
+Ansible -> Alpha
+Site Web KRKN -> Sigma
+Wiki KRKN -> Beta
+Etat des services -> Alpha
+
+Possibilité d'héberger des VPS d'autres Club sur la node Sigma (VLAN dédié) si accord et si stabilité.

proxmox/installation_hyperviseurs.md

@@ -1,8 +1,8 @@
 # Installation des hyperviseurs
 
-Proxmox étant un hyperviseur de type 1, nous allons l'installer sur les deux nodes du serveur.
+Proxmox étant un hyperviseur de type 1, nous allons l'installer sur les quatres nodes du serveur.
 
-Pour cette installation, nous partons du principe que les deux nodes ont accès à internet soit via une IP publique soit via un réseau privé. Cela ne change rien car nous modifierons la configuration réseau par la suite.
+Pour cette installation, nous partons du principe que les quatres nodes ont accès à internet soit via une IP publique soit via un réseau privé. Cela ne change rien car nous modifierons la configuration réseau par la suite.
 
 Pour l'installation il faut :
 - Une clé USB,
@@ -53,8 +53,14 @@ Vérifier la cohérence et lancer l'installation.
 ### Sur la deuxième node (Beta)
 Même procédure, dans "Management Network Configuration" il faut juste remplacer le Hostname par **beta.krhacken.org**
 
+### Sur la troisième node (Gamma)
+Même procédure, dans "Management Network Configuration" il faut juste remplacer le Hostname par **gamma.krhacken.org**
+
+### Sur la deuxième node (Delta)
+Même procédure, dans "Management Network Configuration" il faut juste remplacer le Hostname par **delta.krhacken.org**
+
 ## Préparation des hyperviseurs
-La procédure est la même sur les deux nodes. Elle peut être faite via SSH (recommandé) ou sur l'interface d'administration **https://IP:8006**
+La procédure est la même sur les quatres nodes. Elle peut être faite via SSH (recommandé) ou sur l'interface d'administration **https://IP:8006**
 
 ### Mise à jour
 ```

proxmox/introduction_a_la_virtualisation.md

@@ -4,7 +4,7 @@ Proxmox est un hyperviseur de type 1 (bare metal). C’est une plateforme de vir
 
 Contrairement à un hyperviseur de type 2 (VirtualBox par exemple), Proxmox ne s'exécute pas dans un autre OS mais dispose de son propre OS (basé sur Debian) adapté à la virtualisation.
 
-Donc, Proxmox permet la virtualisation de plusieurs machines au sein d’un seul serveur. Proxmox nous permettra aussi des mettre les deux nodes du rack en cluster permettant entre autre de migrer des contenants d'une node à l'autre en cas de chute de l'une d'elles grâce aux fonctions de Haute Disponibilité de Proxmox.
+Donc, Proxmox permet la virtualisation de plusieurs machines au sein d’un seul serveur. Proxmox nous permettra aussi des mettre les quatres nodes du serveur en cluster permettant entre autre de migrer des contenants d'une node à l'autre en cas de chute de l'une d'elles grâce aux fonctions de Haute Disponibilité de Proxmox.
 
 ## Technologie de virtualisation
 

proxmox/systeme_de_fichier.md

@@ -4,7 +4,7 @@ On a quatres nodes dont 3 d'entre elle en production il faut donc limiter au max
 
 Nous avons choisi d'avoir 4 pools ZFS indépendante pour que la réplication des données soit indépendante d'une node à l'autre.
 
-## Avantage de ZFS
+## Avantages de ZFS
 
 
 ## Mise en place des pools

proxmox/systeme_de_sauvegarde.md

@@ -1,4 +1,4 @@
-# Système de sauvegarde
+# Système de sauvegarde
 
 Afin de limiter encore plus le risque de perte de données nous allons mettre en place un système de sauvegarde de tout les conteneurs / VMs. Nous allons utilisé BorgBackup, le réseau de sauvegarde est un réseau local, en effet la quatrième node sera dédié au système de sauvegarde. De ce fait elle ne sera pas dans le cluster, au niveau du système de fichier nous utiliserons la encore un RAID-1 ZFS. Les sauvegardes passerons par la VLAN 100 du switch administration (10.1.0.0/24).