Oracle Haute-Disponibilité

Infrastructure Oracle de haute disponibilité

Oracle Haute-DisponibilitéDans les productions informatiques d’aujourd’hui, il est inconcevable de perdre des données. Pourtant, les problèmes matériels et/ou erreurs utilisateurs peuvent toujours exister. Et là… c’est le drame !

Nous savons que nous devons faire des sauvegardes régulières afin de pouvoir retrouver nos données mais s’il faut restaurer les données, cela se traduit par une indisponibilité du service (au moins partielle) tant que la restauration n’est pas terminée.

Il existe plusieurs solutions pour permettre de récupérer rapidement une information et nous allons nous intéresser aux solutions d’infrastructure de résistance aux pannes proposées par Oracle.

Corruption de données

C’est l’erreur que nous craignons tous : un disque dur qui lâche, une partition qui disparaît, un fichier qui ne s’enregistre pas correctement… Même les systèmes de niveau professionnels ne sont pas épargnés. Oracle propose des solutions pour éviter de tout perdre.

  • S.A.M.E. : Stripe And Mirror Everything

Architecture mise en avant par Oracle (notamment) qui a pour principe de copier toutes les données (pour la sécurité) et de les répartir sur différents disques (pour la vitesse). Le RAID 5 répond à ce principe. Oracle propose sa solution : ASM (Automatic Storage Management) qui a pour avantage de répartir des données selon les accès à la base.
Exemple : chaque table sera répartie sur tous les disques disponibles ; les fichiers de REDO qui sont écrit de façon séquentielle ne seront pas répartis.

Remarque : Oracle propose ici une solution logicielle de résistance aux pannes qui fonctionne sur les mêmes principes que le RAID. En RAID, il existe des solutions matérielles qui sont certainement plus performantes.

  • Corruption à l’écriture

Pour éviter les écritures sur disque qui ne sont pas valides ; Oracle propose un mécanisme de “checksum”. Avant chaque écriture sur disque, Oracle va calculer une valeur de hachage pour le bloc en mémoire ; puis après écriture, il recalcule le hachage à partir du bloc sur disque. Si la valeur de hachage est différent, l’écriture a échouée et Oracle va la ré-écrire. Cette solution peut être couteuse en CPU selon l’activité de la base.

Défaillance serveur

Face à une indisponibilité serveur, il semble très difficile de pouvoir assurer une continuité de service. Dans un environnement peu contraignant, on utilise les sauvegardes pour recréer un serveur équivalent puis le service est à nouveau ouvert. Pour un environnement de haute disponibilité, le service ne doit pas être interrompu et Oracle propose une architecture pour répondre à ce besoin : RAC.

RAC signifie Real Application Cluster : Application Réelle de Cluster (Cluster : ensemble de serveurs). Sous cet acronyme provocateur, Oracle propose la seule solution base de données qui permet de partager les données disque et mémoire sur plusieurs machines physiques. L’ensemble des autres systèmes de gestion de base de données ne propose qu’un partage des données sur disque.

Architecture RAC

L’architecture RAC repose sur un partage des disques durs. Les deux serveurs ont ainsi accès à l’ensemble des données de la base. La spécificité d’Oracle est le partage de la mémoire.

Lorsqu’un utilisateur se connecte, on lui attribue un serveur (serveur A). Quand il va modifier des données, le serveur A va lire les informations sur disque puis les inscrire en mémoire (pour diminuer les temps d’accès). L’utilisateur pourra ensuite les modifier; il ne travaille que sur des blocs en mémoire du serveur A.

Mais si un second utilisateur se connecte sur le serveur B, et qu’il accède aux mêmes informations, le serveur B va chercher les données non pas sur disque (puisque elles ont été modifiées depuis) mais dans la mémoire du serveur A.

Oracle RAC met en place un système complexe de validation des données qui permet une synchronisation totale des informations sur les différents serveurs RAC. Grâce à cette architecture distribuée, le service peut être assuré même en cas de dysfonctionnement serveur puisque les autres serveurs peuvent prendre le relais étant donné qu’ils ont accès aux mêmes informations.

On trouve différentes façon de mettre en place RAC :
– Load-balancing : tous les serveurs sont utilisés ;
– Fail-over : les serveurs de secours prennent le relais en cas de besoin (ils sont démarrés) ;
– One-Node (depuis Oracle 11g) : un serveur de secours peut être démarré en cas de crash ;

Remarque : L’architecture de Failover RAC fonctionne sur les mêmes principes qu’un cluster logiciel (HP ServiceGuard, RedHat Cluster etc…) ; avec le RAC en Load-Balancing, aucun logiciel tiers ne peut proposer cela puisqu’il faut s’intégrer dans les couches Oracle.

Désastre sur site

Cas critique de haute disponibilité : quelles sont les solutions pour faire face à une catastrophe d’un site informatique (incendie de la salle machine, tremblements de terre etc…) ?

Ici la solution se trouve dans une synchronisation des données au travers d’un réseau grande distance (contrairement à RAC). Pour cela, la base de données, écrit dans un fichier toutes les modifications faîtes (fichier REDO). Quand ce fichier attend une certaine taille (ou au bout d’un certain temps), Oracle le copie sur un autre serveur. Dès lors, le second serveur peut lire le fichier pour synchroniser les données. C’est l’architecture Data Guard.

Architecture DataGuard

Le serveur B est généralement à une distance importante du A (en banque et assurance, on connait la règle des 50km). Il faut donc un lien réseau performant pour transférer toutes les modifications d’un site à l’autre.

Depuis Oracle 11G, le site de secours (serveur B) peut être rendu accessible en lecture seule aux utilisateurs.

Remarque : Cette solution est à comparer avec une copie système de baie à baie (SRDF/A) puisque chaque bloc écrit sur un serveur sera copié sur le second. L’avantage de la solution Oracle est qu’on peut lire la base sur le serveur B en lecture seule et on peut aussi appliquer un délai avant l’exécution sur le serveur B. Exemple : un délais de 3h permettra de lire les données sur le serveur B jusqu’à 3h après qu’elles aient été supprimées sur le serveur A (récupération après erreur humaine).

Erreur humaine

Souvent oubliée, l’exécution d’une mauvaise requête SQL peut avoir des conséquences désastreuses. Généralement, votre DBA préféré ne pourra pas faire grand chose pour vous sortir de ce mauvais pas sauf si des options ont été mises en place.

  • La “recycle bin”

Depuis Oracle 10G, la base de données contient une « corbeille » qui fonctionne sur le même principe que la corbeille Windows. Lorsqu’une table, un index ou un objet quelconque de la base de données est supprimé (DROP), il est en fait placé dans un espace corbeille. Si l’opérateur réalise que la suppression de l’objet est une erreur, il peut demander au DBA d’annuler la suppression ; l’objet est ainsi sorti de la corbeille pour le replacer à son emplacement d’origine.

  • Le mode FlashBack

Oracle conserve les informations contenues dans les tables avant chaque modification (INSERT, UPDATE, DELETE, TRUNCATE etc…).

La zone disque utilisée pour la mise en place de la Flashback étant énorme, Oracle a mis en place un système de « zone de Flashback ». Cette zone est un espace disque dédié à la Flashback qui commence par une taille nulle et qui a une taille maximale définie par le DBA. Quand une ligne d’une table est modifiée, les anciennes valeurs sont placées dans la zone de Flashback. Si la zone n’a pas atteint sa taille limite, elle grossit ; sinon, Oracle détermine un objet qui est le plus vieux dans la Flashback et le supprime (oublie les anciennes valeurs).

Cette espace est mutualisé entre tous les utilisateurs de la base de données ; il se peut donc que lorsque vous êtes seul sur la base, vous puissiez remonter dans le temps de 5h alors que si d’autres utilisateurs font des modifications, vous ne puissiez remonter que de quelques minutes.

L’utilisation de la Flashback est très intéressante car elle peut aussi être requêtée : il est ainsi possible d’obtenir les données d’une table telles qu’elles étaient il y a 2h sans pour autant modifier cette table ; les autres utilisateurs ne sont donc absolument pas au courant de la manipulation.

Conclusion

Nous avons vu tout un panel de fonctionnalités et architectures proposées par Oracle pour atteindre un très bon niveau de disponibilité.

Que ce soit des problèmes matériels ou des erreurs humaines, Oracle propose des solutions puissantes et fonctionnelles.

Nombre de vue : 738

COMMENTAIRES 1 commentaire

  1. Zakaria EL HAMDAOUI dit :

    Bonjour,
    Je vous remercie tout d’abord pour l’article. C’est très intéressant.

    Par ailleurs, je me demande si vous pensez poster un article pour la mise en place d’un RAC, et ce de A à Z.

    Je vous remercie d’avance.

AJOUTER UN COMMENTAIRE