Un site de secours opérationnel sur le papier n’est pas nécessairement prêt à être mis en production.
Dans de nombreux environnements, les données sont bien répliquées, mais les ressources nécessaires pour absorber la charge réelle des applications font défaut.
Le jour du basculement, le site de secours devient un nouveau point de défaillance.
SOLUTION COURANTE
Chez de nombreux clients, le site de secours est principalement conçu pour :
- Héberger une réplique des données (Data Guard, sauvegardes, réplication) ;
- Communiquer uniquement avec le site principal, sans être exposé aux flux applicatifs ou aux utilisateurs.
Dans ce contexte, le site de secours n’évolue pas toujours au même rythme que la production. Ainsi, plusieurs actions critiques réalisées sur le site principal ne sont pas systématiquement répercutées sur ce site.
Le site de secours reste synchronisé en termes de données, mais est désynchronisé techniquement par rapport à la production.
RECOMMANDATION
Pour garantir à la fois la disponibilité et des performances minimales acceptables en cas de bascule, assurez-vous que :
- les évolutions physiques sont systématiquement répliquées ;
Toute extension de stockage, toute modification d’architecture ou tout ajustement de capacité appliqué en production doit être implémenté sur le site de secours.
La capacité en termes de disque, de processeur, de mémoire et d’E/S doit rester cohérente avec la charge attendue.
- Les politiques de sécurité sont alignées.
Les recommandations de sécurité appliquées en production doivent également être déployées sur le site de secours.
Toute divergence de sécurité peut non seulement bloquer les applications lors du basculement, mais aussi laisser des failles de sécurité actives sur des applications critiques une fois le site de secours devenu site de production.
- Les applications sont prêtes à basculer.
Toutes les applications connectées à la production doivent :
- soit pouvoir se connecter directement au site de secours ;
- soit disposer de copies à jour et testées sur le site de secours.
Le bon fonctionnement de l’ensemble des applications doit être validé, et pas uniquement celui de la base de données.
- Les utilisateurs et les clients peuvent se connecter.
Tous les clients finaux (agences, sites distants, utilisateurs) qui accèdent à la production doivent pouvoir :
- se connecter au site de secours ;
- sans reconfiguration lourde ni intervention d’urgence.
La continuité du service dépend autant des accès que des données.
✨ EN BONUS
Sur un site de secours synchronisé avec Oracle Data Guard, il faut prêter attention à:
L’indisponibilité prolongée du site de secours
En cas d’indisponibilité du site de secours, la gestion des archivelogs devient critique, car ils sont essentiels pour assurer la synchronisation entre le site de production et le site de secours.
Sans anticipation, une indisponibilité prolongée peut entraîner :
- une accumulation massive des archivelogs sur la production ;
- une saturation du Fast Recovery Area (FRA) ;
- et, dans le pire des cas, un arrêt complet de la base de données de production.
Plusieurs stratégies sont généralement mises en œuvre pour gérer cette situation.
Option 1 : Suppression des archivelogs après application sur le site de secours
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY;Option 2 : Sauvegarde et externalisation automatique des archivelogs
Option 3 : Mise en place d’un Far Sync
La saturation du FRA sur le site de secours
Une saturation du Fast Recovery Area du site de secours entraîne l’arrêt de celui-ci. Vous devez mettre en place sur le site de secours les mêmes mécanismes de contrôle du FRA que sur le site de production.
La réplication et sauvegarde des wallets
Les clés de chiffrement (TDE, RMAN) doivent être synchronisées et protégées sur le site de secours, car une base de données protégée par TDE ne pourra pas être ouverte sur ce site si les clés ne sont pas disponibles.
Tests avec snapshot standby
Exploiter les snapshot standby pour tester le fonctionnement et les performances de l’application sans interrompre la réplication.