Des topologies préparées
Les modèles de cluster assemblent les composants et leur configuration initiale. Votre équipe part d’une architecture concrète à vérifier et à adapter.
← Cloud applicatifRépartissez votre application
Clusters applicatifs
Répartissez votre application
sur plusieurs nœuds.
Déployez des topologies qui répartissent le trafic et organisent la réplication. Des modèles automatisent l’assemblage ; vous choisissez le niveau de redondance et les réglages adaptés à votre application.
Calcul et mémoire0,004 € HT / cloudlet / hTarif réservé de 1 à 8 cloudlets. Stockage, IP et trafic selon consommation.
Migration offerte · SSL et sauvegardes inclus
VOTRE PROJET, CONNECTÉ
Clusters automatisésUn environnement à votre mesure
01Votre code
02Application
03Données
Ressources ajustables CPU · RAM · Disque
Le trafic mieux réparti
Les load balancers orientent les requêtes vers les instances de l’application. Les contrôles de santé se définissent selon le moteur et le service.
Une croissance organisée
Ajoutez de la capacité sur les couches qui en ont besoin. La réplication et la découverte des nœuds dépendent du modèle choisi.
Découvrez la console
Configurez les couches de votre cluster.
Ajoutez un répartiteur, plusieurs serveurs applicatifs et une base de données. Chaque couche se dimensionne séparément dans la même topologie.
Environnement Node.js
Fonctionnalités
Configurez, déployez, puis suivez vos services.
Load balancing applicatif
Choisissez le répartiteur adapté au protocole et à vos besoins. NGINX et HAProxy permettent notamment de distribuer les requêtes entre plusieurs backends.
Contrôles de santé
Configurez les vérifications utiles à votre service. Un port accessible et une application capable de répondre correctement ne sont pas toujours la même chose.
Réplication des bases
Les modèles de bases proposent leurs topologies propres : principal et répliques ou autres modes disponibles selon le moteur. Choisissez en fonction des lectures et des écritures.
Fichiers partagés
Un stockage partagé permet aux nœuds applicatifs d’accéder au même contenu lorsque l’application l’exige. Ses besoins de disponibilité doivent aussi être étudiés.
Scaling par couche
Faites évoluer les instances applicatives, le cache ou les données selon leur rôle. Les mécanismes automatiques du modèle accompagnent les opérations compatibles.
Déploiements progressifs
Redémarrez ou redéployez les nœuds l’un après l’autre, avec un délai réglable. Pour une bascule entre deux environnements, préparez aussi le trafic et les données.
Du serveur seul à l’architecture distribuée
Préparez le trafic, l’état et la reprise.
Multiplier les serveurs applicatifs est un début. Une application disponible dépend aussi du chemin réseau, des fichiers et de ses données.
- 01
Répartissez les requêtes
Placez un load balancer devant plusieurs serveurs et définissez les vérifications permettant d’écarter une instance indisponible.
- 02
Préparez l’état partagé
Organisez les sessions, les fichiers et les accès aux bases pour que plusieurs instances puissent servir les mêmes utilisateurs.
- 03
Testez les scénarios de panne
Validez le comportement quand une instance s’arrête, quand une base bascule et quand la charge revient sur les nœuds restants.
Penser au prochain déploiement
Préparez le fonctionnement en cas de panne.
Un cluster réduit certaines dépendances à une instance unique. Sa continuité réelle repose sur l’ensemble de l’architecture et sur la façon dont votre application réagit aux incidents.
Des composants adaptés
Les modes de réplication et de bascule varient entre les moteurs. Une topologie SQL ne fonctionne pas comme un cache distribué ou un cluster applicatif.
De la capacité en réserve
Les nœuds restants doivent pouvoir absorber la charge après une défaillance. Dimensionnez aussi cette situation, pas uniquement le fonctionnement nominal.
Des sauvegardes indépendantes
La réplication peut propager une suppression ou une erreur logique. Conservez une stratégie de sauvegarde et testez le retour à un état exploitable.
La redondance, la bascule et le placement dépendent de la topologie retenue. Les licences commerciales éventuelles sont à vérifier selon les composants.
Usages
Pour les projets que vous développez.
Une boutique sollicitée
Séparez la distribution du trafic, l’application et les données pour accompagner les pics et préparer les opérations de maintenance.
Une application d’entreprise
Étudiez la continuité des composants dont dépend votre activité et définissez des procédures de bascule compréhensibles.
Une plateforme SaaS
Faites évoluer les couches de votre service et organisez les déploiements successifs avec une architecture testable.
Tarifs PaaS
Vous payez les ressources
de votre environnement.
Le choix d’un langage ou d’un moteur n’ajoute pas de forfait. Le prix comprend la capacité réservée, les ressources dynamiques consommées et les options utilisées. Les licences commerciales restent facturées séparément.
Consulter la grille et calculer mon budget Nous contacter- Mémoire réservée
- 0,5 GiB
- Complément dynamique utilisé
- 0 cloudlet
- Disque inclus
- 10 Go
- IPv4 publique dédiée
- Aucune
- Trafic externe
- 1 Go / heure
Ce montant couvre la configuration ci-dessus. Chaque nœud, la consommation dynamique, le disque au-delà de 10 Go, les IP publiques et le trafic supplémentaire s’ajoutent selon la grille PaaS.
Quelques repères
Vos questions, nos réponses.
Un cluster est-il forcément réparti sur trois datacenters ?
Non. Plusieurs nœuds ne signifient pas automatiquement plusieurs zones ou plusieurs sites. Le placement et la topologie de disponibilité doivent être définis explicitement selon votre projet.
Quelle différence avec l’autoscaling ?
Le cluster organise plusieurs composants pour répartir le travail ou les données. L’autoscaling ajuste leur capacité ou leur nombre selon des règles. Un cluster peut fonctionner avec un nombre fixe de nœuds.
La réplication remplace-t-elle les sauvegardes ?
Non. La réplication vise notamment la continuité et peut recopier une erreur. Une sauvegarde permet de revenir à un état précédent, selon son périmètre et sa rétention.
Toutes les bases utilisent-elles le même mode de bascule ?
Non. Le comportement dépend du moteur, du modèle de cluster et de la configuration. Les mécanismes de réplication, de quorum et de routage doivent être choisis ensemble.
Puis-je faire évoluer un environnement existant ?
Oui, selon les composants et la topologie. Nous vous aidons à définir les étapes utiles : adaptation de l’application, partage des données, ajout d’instances et validation des scénarios de fonctionnement.
À découvrir aussi
La suite de votre architecture.
Migration offerte
Parlons de votre application.
Décrivez votre projet, ses composants et sa charge actuelle. Nous vous aidons à choisir l’architecture et à préparer le transfert.