Comment on page
Concepts
Description de l'architecture technique et des concepts de Muppy Pack.
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 https://docs.outscale.com/fr/userguide/%C3%80-propos-des-R%C3%A9gions-endpoints-et-Availability-Zones.html
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.
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.
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.
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
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
HA Strategy Actif / Passif variante 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).
HA Strategy Actif / Passif variante 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).
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).
HA Strategy Actif / Actif
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).
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é.
Last modified 1yr ago