La Haute Disponibilité et les environnements Oracle – partie 1

Les environnements informatiques modernes doivent permettre une Haute Disponibilité des applications.  Notre blog entame une série de billets visant à approfondir la notion de Haute Disponibilité et à vous aider à déterminer vos besoins spécifiques. Puis, nous examinerons lesBest Practices Oracle pour déployer un environnement de base de données de Haute Disponibilité.

Qu'est-ce que la Haute Disponibilité ?

On appelle disponibilité le degré avec lequel une application, un service ou une fonction est accessible sur demande. La disponibilité est mesurée par la perception d’un utilisateur de l’application. Les utilisateurs supportent mal la non-disponibilité des données ou un fonctionnement anormal de l’informatique, que ce soit dû à la panne d’un composant ou à une surcharge d’activité.

Si les utilisateurs veulent disposer de façon certaine de l’informatique à des périodes convenues, ils ont besoin de Haute Disponibilité. Cette Haute Disponibilité doit parfois aller jusque 24h/24 et365j/365. Des périodes d’arrêt pour maintenance système planifiée sont parfois possibles.

Une solution Hautement Disponible répond à 4 critères :

• La fiabilité : Tant le matériel que le logiciel (base de données, serveurs d’applications, applications) doivent être fiables dans une configuration de Haute Disponibilité. La résilience(capacité d’un système ou d’une architecture réseau à continuer de fonctionner en cas de panne) est possible même avec des matériels à faible coût, en utilisant des logiciels comme Oracle Real Application Clusters (RAC).
  .
• La capacité à récupérer d’un échec : Il peut y avoir plusieurs façons de récupérer d’un échec. Ceci nécessite de déterminer quels types de pannes peuvent se produire et comment récupérer de ces échecs dans un délai compatible avec les besoins de votre entreprise. Par exemple, si une table critique est accidentellement supprimée de la base de données, quelles mesures faut-il prendre pour la récupérer? Votre architecture vous permet-elle de la récupérer dans un délai compatible avec le niveau de service négocié (SLA)?
  .
• La détection rapide des erreurs : Si un composant de votre architecture est en échec, alors la détection rapide est essentielle pour surmonter cet échec inattendu. Un temps de détection trop long d’un problème peut être incompatible avec le SLA. La mise en place d’un système desurveillance avec envoi d’alertes est donc essentielle.
  .
• Une continuité des opérations : Il est capital de donner un accès continu à vos données lorsqu’il ne peut pratiquement pas y avoir d’arrêt production pour maintenance. Dans ce cas, des tâches telles que déplacer une table à un autre endroit de la base, ou ajouter des processeurs à votre matériel, devraient être transparentes pour l’utilisateur final dans une architecture de haute disponibilité.
  .

Plus précisément, une architecture haute disponibilité devrait avoir les 9 caractéristiques suivantes:

1. Tolérer les échecs ou pannes tout en faisant en sorte que la production continue, avec peu ou pas d’interruption
2. Être transparente (ou tolérante) avec les évolutions de systèmes, de données ou d’applications
3. Prévoir des dispositions intégrées préventives
4. Fournir une surveillance active et une détection rapide des défaillances
5. Faciliter une récupération rapide
6. Automatiser la détection d’incidents et leur récupération
7. Protéger les données pour minimiser ou éviter la perte de données
8. Mettre en œuvre les meilleures pratiques opérationnelles pour gérer votre environnement
9. Atteindre les objectifs fixés dans les contrats SLA (par exemple, des objectifs de temps de récupération (RTO) et les objectifs de point de récupération (RPO)) pour le plus bas coût possible de TC0 (Total Cost of Ownership)

(Cette série d’articles utilisera, entre autres, des informations publiées dans des manuels Oracle)

Contactez-nous ici pour de plus amples informations.