MODOP – Création d’un cluster Apache ZooKeeper. Celui-ci permet de maintenir des informations de configuration et ainsi fournir à ses clients des services synchronisés et des services de groupes. Dans notre cas il permettra de synchroniser les services de notre cluster sheepdog et éventuellement Qemu. Zookeeper est performant, simplissime à mettre en place mais surtout très scalable et résilient aux pannes. Il est souvent utilisé dans les solutions de cluster de service distribué.
Continuer la lectureCatégorie : Fichiers Distribué
MODOP – fichiers distribué
MODOP – QEMU HA – Partie 2 – Installation Cluster sheepdog
MODOP sur l’installation d’un cluster sheepdog délivrant un stockage distribué de type SDS. Ici, le cas d’usage est de stocker en mode bloc les machines virtuelles de Qemu. SheepDog se veut tolérant aux pannes, scalable à souhait et surtout rapide dans sa mise en production. Son avantage, tous les nœuds hébergent les chunks et les métadonnées ce qui rend son architecture très malléable et redimensionnable rapidement. Il faut impérativement le coupler à Zookeer pour gérer les services/messages des membres du cluster Sheepdog.
Continuer la lecture
MODOP – QEMU HA – Partie 3 – Test HA Disque Distribué sheepdog
MODOP – Test de résilience des données sur des machines virtuelles QEMU via Sheepdog. Le but est de rendre persistant toutes données inscrites sur une machine virtuelle via l’usage d’un stockage distribué SheepDog. Dans le cas présent, nous allons créer un fichier texte sur une machine VM (Qemu/Sheepdog) du node04 et nous vérifierons sur le node05 que cette donnée est préservée.
Continuer la lecture
MODOP – QEMU HA – Partie 4 – Installation HA Web Machine Sheepdog
MODOP – Test de résilience des services et données sur des machines virtuelles QEMU via Sheepdog/Zookeeper. Le but est de rendre HA « high availability » des applications web, données, DNS, etc via l’usage d’un stockage de type SDS. Dans le cas présent, nous déployons un script Bash Web permettant de redémarrer des machines virtuelles lors de la perte du node « maître » portant les machines VM et la VIP (KeepAllive).
Continuer la lecture
MODOP – Partie 1 – Server ATA over Ethernet RAID1
MODOP sur la mise en place d’un serveur AoE distribuant des Volumes Logiques (LV) à différent Système d’exploitation (Win10, Linux, BSD, etc) Dans le cas présent, le Volumes Groupe (VG) repose sur un RAID1 et assigne des Volumes Logiques (LV) via la couche OSI 2 sur des clients distants. AoE se comporte comme un SAN mais sa particularité est d’être basé sur les MAC Adresse et non les IP, le rendant Léger, rapide et économe. De plus, ce protocole n’est pas routable (OSI 2) et de fait non accessible via les réseaux internet.
Continuer la lecture
MODOP – Partie 2 – Server ATA over Ethernet RAID1 – Ubuntu Server
MODOP – Connexion d’un client Ubuntu server sur le serveur Aoe (Partie1) en lui assignant un volume logique (LV) nommé « /dev/mapper/storage–aoe-ubuntu ». Ce volume (LV) est défini sur le serveur AoE via le service vbladed en mappant le LV à une virtual EtherDrive permettant d’utiliser une « raw socket ». Le client AoE se connectera et ouvrira un flux réseau via le numéro de la virtual EtherDrive (e0.1) configurer sur AoE server.
Continuer la lecture
MODOP – Partie 3 – Server ATA over Ethernet RAID1 – Win Server 2022
MODOP – Connexion d’un client Windows server 2022 sur le serveur Aoe (Partie1) en lui assignant un volume logique (LV) nommé « /dev/mapper/storage–aoe-winserve22 ». Ce volume (LV) est défini sur le serveur AoE via le service vbladed en mappant le LV à une virtual EtherDrive permettant d’utiliser une « raw socket ». Le client AoE se connectera et ouvrira un flux réseau via le numéro de la virtual EtherDrive (e1.1) configurer sur AoE server.
Continuer la lecture
MODOP – Partie 4 – Server ATA over Ethernet RAID1 – Arch Linux
MODOP – Connexion d’un client Arch Linux sur le serveur Aoe (Partie1) en lui assignant un volume logique (LV) nommé « /dev/mapper/storage–aoe-arch ». Ce volume (LV) est défini sur le serveur AoE via le service vbladed en mappant le LV à une virtual EtherDrive permettant d’utiliser une « raw socket ». Le client AoE se connectera et ouvrira un flux réseau via le numéro de la virtual EtherDrive (e2.1) configurer sur AoE server.
Continuer la lecture
MODOP – Partie 5 – Server ATA over Ethernet RAID1 – Windows 10
MODOP – Connexion d’un client Windows 10 sur le serveur Aoe (Partie1) en lui assignant un volume logique (LV) nommé « /dev/mapper/storage–aoe-win10 ». Ce volume (LV) est défini sur le serveur AoE via le service vbladed en mappant le LV à une virtual EtherDrive permettant d’utiliser une « raw socket ». Le client AoE se connectera et ouvrira un flux réseau via le numéro de la virtual EtherDrive (e3.1) configurer sur AoE server.
Continuer la lecture
MODOP – Partie 6 – Server ATA over Ethernet RAID1 – Centos7
MODOP – Connexion d’un client Centos7 Linux sur le serveur Aoe (Partie1) en lui assignant un volume logique (LV) nommé « /dev/mapper/storage–aoe-centos7 ». Ce volume (LV) est défini sur le serveur AoE via le service vbladed en mappant le LV à une virtual EtherDrive permettant d’utiliser une « raw socket ». Le client AoE se connectera et ouvrira un flux réseau via le numéro de la virtual EtherDrive (e4.1) configurer sur AoE server.
Continuer la lecture