Ce guide travaille les concepts du 402. Les plateformes cloud, extensions et versions imposent des prérequis à vérifier avant déploiement.
Une capacité supplémentaire n’est pas un service complet
Le cloud bursting utilise temporairement un environnement supplémentaire pour absorber un besoin de capacité. La mobilité concerne le déplacement ou l’utilisation d’une application entre environnements. Les deux exigent de décrire ce qui doit rester cohérent pour le service : identité, données, secrets et configuration.
Le programme 402 associe ces notions à la conception et à l’automatisation. Le pattern Google Cloud fournit une référence d’architecture hybride ; il ne constitue pas une procédure universelle BIG-IP. Les choix techniques doivent être vérifiés dans l’environnement retenu.
Sources : Google Cloud, Cloud bursting pattern ; F5, Blueprint 402 — Cloud Solutions.
Identifier l’état qui ne suit pas l’instance
Une application sans état local peut simplifier la mise à l’échelle, mais conserve souvent des dépendances externes. Pour une application avec sessions ou fichiers locaux, le déplacement demande une stratégie explicite. La création d’un serveur ne transfère pas automatiquement les sessions ni les données.
Le routage doit diriger le trafic vers une capacité prête et retirer une capacité qui ne doit plus être utilisée. Le DNS, les caches et connexions existantes influencent cette transition. Un déclencheur de scaling ne démontre pas que les ressources ajoutées peuvent déjà servir les utilisateurs.
Sources : Google Cloud, Cloud bursting pattern ; F5, Blueprint 402 — Cloud Solutions.
Définir déclenchement et retrait
Décrivez la métrique, la durée d’observation, les étapes de préparation et le critère d’ajout au service. La métrique doit correspondre à une ressource réellement limitante. Ajouter des frontends ne résout pas nécessairement une saturation de base de données.
Préparez aussi le retrait : arrêt des nouvelles affectations, fin des échanges, conservation des données et suppression des ressources. Documentez les coûts et contraintes sans attribuer une économie automatique au modèle. Les erreurs doivent produire un état connu et une possibilité de reprise.
| Étape | Critère à établir |
|---|---|
| Déclenchement | Signal pertinent et durée |
| Préparation | Infrastructure, configuration et dépendances |
| Ajout | Service prêt et surveillance active |
| Retrait | Échanges terminés et données conservées |
| Clôture | Ressources supprimées et accès retirés |
Sources : Google Cloud, Cloud bursting pattern ; F5, Blueprint 402 — Cloud Solutions ; F5, F5 BIG-IP Application Services 3 Extension Documentation.
Exercice : une pointe qui vient des données
Le frontend utilise peu de CPU mais les réponses ralentissent à cause de la base. Expliquez pourquoi une extension de frontends peut aggraver ou laisser intact le symptôme. Proposez les mesures nécessaires pour localiser la limite avant de définir un scaling.
Le compte rendu doit relier métrique, dépendance et action. Poursuivez avec les architectures multi-tier et le workflow de provisioning pour préparer l’extension et son retrait.
Sources : Google Cloud, Cloud bursting pattern ; F5, Blueprint 402 — Cloud Solutions.
Sources et portée
Références consultées le . Les exemples utilisent des noms et adresses de documentation à remplacer. Les commandes de lecture affichent l’existant ; les captures et requêtes de diagnostic sont à limiter au périmètre autorisé.
- Google Cloud — Cloud bursting pattern · Référence officielle ; vérifier le périmètre de version · consulté le 3 octobre 2026.
- F5 — Blueprint 402 — Cloud Solutions · Blueprint 402.42019 · consulté le 3 octobre 2026.
- F5 — F5 BIG-IP Application Services 3 Extension Documentation · Référence officielle ; vérifier le périmètre de version · consulté le 3 octobre 2026.
Retrouver le parcours de lecture F5 402