muppy.io
  • ⛏️Qu'est ce que muppy.io ?
  • ⚒️Concepts Muppy
  • Quickstarts
    • ✏️Introduction
  • Guides
    • ⛏️Muppy Core
      • Hosts
        • Création et enrôlement d'un Host
          • ✏️Server Types
          • ✏️Configuration réseaux spécifiques
        • ⚒️Host's Users
        • ⚒️Host's Network information
        • ⚒️Host's Metrics
      • Tasks et Fact Collectors
        • ⚒️Exécution des Tasks (Task Runs)
          • ⚒️Exécution asynchrone des Tasks (Launch as Job)
        • ⚒️Synchronisation des Tasks et Scripts
        • ⚒️Liste des Scripts
        • ⚒️Liste des Tasks
        • ⚒️Création de Task "Shell Script"
        • ⚒️Liste des Fact Definitions
      • ⛏️Firewall UFW
        • Désactiver UFW globalement
        • ✏️Page 1
      • SSH Keys
        • Gestion des SSH Keys
        • Gestion des "authorized_keys"
        • Extraction Clef Privée d'un User User
      • ⚒️Systemd Service Units
        • ⚙️Liste des Systemd Units
        • ➕Création de Systemd Units
        • 📰Systemctl status et log
        • ✏️Edition des Systemd Units
    • 🐘PostgreSQL
      • PostgreSQL Base
        • Installation de PostgreSQL
        • Gestion des Clusters
          • Création
          • Configuration
          • Contrôle
          • Administration (basique)
        • Backup, Restore et Copy de Databases
          • Databases Backups (pg_dump)
          • PostgreSQL Backup
          • pg_dump Restore
          • Database Copy
          • pg_restore Callback Task
        • Backups Planifiés
        • Gestion rétention des Backups
      • PostgreSQL Replication
        • Créer un RCS
        • Visualiser un RCS
        • Suivre la Replication
        • Ajouter des Standbys
        • Restructurer un RCS
        • Intégration d'un RCS
        • Reconfigurer un RCS
      • PostgreSQL HA
        • Configuration
        • Activation et Désactivation
        • Monitoring
        • pglookout Heartbeat
      • PostgreSQL PITR
        • Configuration de WAL-G
        • Lancement des Clusters Backups
        • Liste des Clusters Backups (WAL-G)
        • Purge des fichiers de Backup PITR
        • Monitoring du PITR
        • Objets S3 stockés par WAL-G
        • Restauration PITR
      • PostgreSQL Tools
        • pgBadger - log analysis
    • Muppy Pack
      • ⛏️Packs
      • Concepts
      • ⛏️Muppy Cluster
        • Cluster Security
        • PostgreSQL Cluster Resources
      • ⛏️Reverse Proxy
    • ✏️Configuration
      • 👫Gestion des Users Muppy
      • 🏬S3 Buckets
      • 💬Notifications Teams
      • ✏️Notifications Slack
    • ⛏️Odizy
      • Odizy Workflow
        • Test Servers
      • Accéder à vos serveurs
      • Restaurer un backup sur le serveur de staging
      • Activer un serveur Standby
      • ⛏️Configuration LXC CI/CD
      • Activate and Launch remote Code-Server (VS Code from coder.com)
    • ⚒️Kubernetes
      • ⚒️Installer Tailscale
      • ⚒️Installer un cluster microk8s
      • ⚒️Installer PostgrSQL
      • ⚒️Installer les packages d'infrastructures
  • 📡Muppy Enterprise
    • Introduction
    • ⛏️Configuer une Instance Muppy Enterprise
    • 🌡️Monitoring Muppy Enterprise
  • ⛏️Work in progress
    • ⛏️Code Server
    • ⛏️Muppy Development Servers
      • Move Development Server
Powered by GitBook
On this page
  • Availability Zone (AZ)
  • Resource Pools (Cluster Resource Pool)
  • Muppy Cluster (mCluster)
  • HA Strategy
  • Stratégie Actif / Passif
  • Stratégie Actif / Actif
  • Cluster Security
  1. Guides
  2. Muppy Pack

Concepts

Description de l'architecture technique et des concepts de Muppy Pack.

PreviousPacksNextMuppy Cluster

Last updated 3 years ago

Availability Zone (AZ)

L'objet Availability Zone de Muppy permet d'identifier les Zones de Disponibilité Clouds dans lesquelles sont hébergées des ressources systèmes.

Chaque Cloud ou Hébergeur a sa propre définition à laquelle il convient de se référer.

Pour une "bonne" description générale, nous vous recommandons

Muppy permet de créer autant de Availability Zones que nécessaire pour modéliser l'architecture des Data Centers que vous utilisez.

La notion de Availability Zone est étroitement liée à la notion de Region mais cette dernière n'est pas exploitée pour l'instant.

Resource Pools (Cluster Resource Pool)

Un Cluster Resource Pool ou plus simplement Pool est un ensemble de ressources interdépendantes, permettant d'exécuter des Muppy Applications.

Le Pool est l'unité de Haute Disponibilité des Muppy Packs.

Par construction, un Pool doit garantir que ses ressources interagissent avec des performances optimales. Aussi en générale, les ressources d'un Pool sont déployées dans la même Region d'un même Cloud (voir dans la même Availability Zone).

Les Pools ne sont pas utilisés directement mais au travers de Muppy Clusters (voir ci-après).

Les Pools gèrent 3 types de ressources:

  • Reverse Proxies ; Traefik

  • Compute Nodes ; LXD Hosts

  • Databases ; PostgreSQL Clusters

Muppy Pack permet d'exploiter d'autres types de systèmes (Stockage S3) mais ils ne sont pas gérés au niveau des Pools actuellement.

Les Pools sont conçus pour fonctionner facilement avec le produit "Load Balancer" de Cloudflare.

Muppy Cluster (mCluster)

Un Muppy Cluster est une abstraction qui permet de gérer un ensemble Pools afin d'obtenir des des Muppy Applications Hautement Disponibles.

En automatisant la réplication, le monitoring et la disponibilité des Pools entre différents Clouds et hébergeurs, les mClusters permettent d'obtenir le plus haut niveau de Haute Disponibilité et d'indépendance par rapport aux Cloud Providers.

Les Muppy Clusters permettent de gérer de manière cohérente des ressources déployées dans:

  • des Data Center privés

  • des Clouds Public

  • des fournisseurs d'infrastructure

  • des Cloud Privés

Les Muppy Clusters sont construits à partir de solutions Open Source dont la compréhension et la maitrise sont accessibles à un SysAdmin.

Les performances et la résilience des Muppy Clusters sont gérés avec une stratégie de Haute Disponibilité ou HA Strategy.

HA Strategy

Une HA Strategy définit:

  • comment les ressources d'un Muppy Meta Cluster sont interconnectées

  • comment elles sont "monitorées"

  • quelles actions (Muppy Task) doivent être lancées en cas de défaillance

Si le système de configuration avancé de Muppy (les SmartConfigs) permet une infinité de combinaisons de configuration entre les Reverse Proxies, LXD Hosts et PostgreSQL Clusters, Muppy propose en standard les HA Strategy suivantes:

  • Actif / Passif ; un seul Muppy Cluster est accessible publiquement à un instant

  • Actif / Actif ; tous les Muppy Clusters sont accessibles publiquement

Stratégie Actif / Passif

Cette stratégie est bien adaptée aux applications OLTP (Applications avec un pourcentage élevé de transactions en écritures et des requêtes simples).

Dans la version de base, les LXD de chaque mCluster sont connectés aux Clusters PostgreSQL et aux Reverse Proxy du même mCluster. Chaque mCluster Passif (il peut y en avoir plus d'un) est prêt à devenir le mCluster Actif moyennant:

  • une Promotion du cluster PostgreSQL en Primary

  • une reconfiguration des DNS

Variante 1 : Stratégie Actif / Passif avec Workers

Une variante consiste à connecter tous les LXD sur le PostgreSQL Primary Cluster. Les LXC du mCluster 2 peuvent alors prendre en charge des traitements asynchrones (workers).

Cette variante utilise une fonctionnalité du driver PostgreSQL qui est capable de se connecter au premier Cluster PostgreSQL disponible en lecture écriture.

La stratégie présentée ci-dessus, notamment la variante "Workers" permet de disposer d'une architecture véritablement multi Clouds / multi fournisseurs adaptée aux charges de type OLTP (mais pas forcément pour des applications Web).

Stratégie Actif / Actif

Dans un Muppy Meta Cluster cluster Actif / Actif, les Applications de tous les mCluster sont accessibles et connectés au Cluster PostgreSQL Primary. Dans cette architecture il est possible aussi de connecter les LXC sur le(s) Clusters PostgreSQL Standby (non représenté sur le schéma).

Cette architecture n'a de sens que si le pourcentage de requêtes en écriture et la latence entre les 2 mClusters sont faibles (même Region).

Cluster Security

Muppy gère la configuration des Firewall de toutes les Muppy Cluster Resources. Pour cela, Muppy permet de définir des Muppy Tasks spécialisées au niveau de chaque Resource.

Muppy est livré avec au moins une Tasks par défaut. Les utilisateurs peuvent en créer de nouvelles plus spécifiques à leurs besoins et exigences de sécurité.

https://docs.outscale.com/fr/userguide/%C3%80-propos-des-R%C3%A9gions-endpoints-et-Availability-Zones.html
HA Strategy Actif / Passif variante Workers
HA Strategy Actif / Passif variante Workers
HA Strategy Actif / Actif