# Concepts ## 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. {% hint style="success" %} Pour une "bonne" description générale, nous vous recommandons {% endhint %} 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 ![HA Strategy Actif / Passif variante Workers](/files/DV9VV3RWuyzJBBlc34vK) #### 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). ![HA Strategy Actif / Passif variante Workers](/files/8Dup8JvOLBhaCqSv12uE) {% hint style="info" %} Cette variante utilise une fonctionnalité du driver PostgreSQL qui est capable de se connecter au premier Cluster PostgreSQL disponible en lecture écriture. {% endhint %} 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). ![HA Strategy Actif / Actif](/files/SORskazPxzWcUM8k79B0) {% hint style="success" %} 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). {% endhint %} ## 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é. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.muppy.io/guides/muppy-pack/concepts.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.