Haute disponibilité d’Oracle database sous Windows : et pourquoi pas Fail Safe ?

Quand on évoque le besoin de haute disponibilité d’instances de bases de données Oracle (mais comme pour tout SGBD), il y a au moins deux axes:

• la protection des données et notre capacité de reprise de celles-ci en cas de “désastre”.
• et la disponibilité du service en cas de défaillance, quelle qu’elle soit.

Parmi moult solutions proposées par Oracle, on pense communément à Data Guard pour la protection des données et les bases de données en cluster Oracle RAC sous clusterware “Grid Infrastructure” pour la disponibilité du service. Par ailleurs, cette combinaison est historiquement celle proposée par Oracle pour aller vers les architectures dites de maximum disponibilité (Maximum Availability Architecture, ou “MAA”). Cela va sans le dire, et ce n’est pas l’objet de cet article, la dimension du coût entre vite en ligne de compte. Un objectif MAA sera probablement sous licence “enterprise edition” sur tous les serveurs entrant dans l’architecture et avec de possibles options payantes selon les choix d’implémentation. Rappelons juste qu’Oracle RAC reste accessible en édition standard à condition d’utiliser ASM et sous une limite de deux sockets sur la totalité de l’architecture, soit deux serveurs et un socket par serveur (limitation de la licence Standard Edition 2 ou”SE2″).

La solution de bases de données en cluster RAC sous grid insfrastructure serait une forme de panacée, en tout cas d’idéal en matière d’architecture de bases de données en cluster. En effet, son atout majeur par rapport à la plupart des offres “cluster de SGBD” réside dans sa capacité à mettre en œuvre une seule base de données en cluster mais disponible simultanément sur minimum deux serveurs, donc deux instances ouvertes et accessibles à travers des services de connexion. Ainsi, en plus de permettre la disponibilité maximale d’un de ces services en cas de défaillance d’un des nœuds (minimum souhaité à travers un cluster), RAC permet d’avoir plusieurs instances actives autorisant la répartition de la charge en base (“load balancing”) et de l’évolutivité en matière de capacité  (“scalability”, traduit en français par “scalabilité”). Ces possibilités reposent, entre autres, sur l’usage d’un système de fichiers en cluster (systèmes CFS, le choix naturel étant Oracle ASM) et l’implémentation par Oracle de son cache global inter-instances utilisant l’interconnexion entre les nœuds. L’interconnexion sert en premier lieu à “Grid Infrastructure” pour la maintenance des nœuds au sein du cluster (heartbeat complémentaire à celui implémenté au niveau du stockage partagé via les disques de vote).

Le principe même de cluster est des plus vastes, celui-ci désignant avant tout le regroupement de plusieurs serveurs pour rendre un même service (cluster se traduisant par “grappe” de serveurs) et améliorer la résilience en cas de panne de l’un des serveurs. Ainsi et selon les SGBD, la base de données sous-jacente peut être unique, comme multiple, si la mise en cluster repose sur une solution de réplication multi-directionnelle ou encore de partitionnement (sharding)…

En matière de conseil, on ne saurait orienter un client vers la solution RAC sous le seul prétexte que c’est réputé solide, fiable et évolutif, sans mettre en exergue quelques contraintes. A titre d’exemple, ne retenons que celles-ci :

• L’application est-elle compatible avec le fonctionnement RAC en répartition de charge sur plusieurs instances ?
• A-t-on les compétences internes requises pour la mise en œuvre de l’architecture et sa maintenance (compétences système, stockage SAN, réseau et Oracle “grid infra” et RAC bien entendu) ?

Admettons que les compétences, moyennant un éventuel accompagnement, ne sont pas un souci (en sachant quand même que les déploiements de bases en RAC sur des infrastructures sous système Windows sont moins prisées). Il reste la compatibilité applicative et l’effort éventuel de mise en conformité. Pour pallier à cela et migrer en douceur, on peut créer des services d’accès à notre base de données en “preferred” sur une seule instance, et ainsi utiliser le cluster RAC en mode actif/passif à travers ces services.

Mais revenons au point de départ de tout projet de haute disponibilité : il faut se poser la question essentielle de l’objectif de notre architecture en cluster. Si celui-ci est avant tout et surtout de maximiser la disponibilité du “service de base de données”, de nombreuses solutions de clusterware “actif/passif” existent sur le marché et sont compatibles avec Oracle Database. Les points communs de ces solutions sont:

• Implémentation d’un Clusterware tiers à Oracle sachant gérer les composantes Oracle comme des ressources, à minima l’instance de base de données et un listener écoutant sur une adresse IP virtuelle (VIP). Le clusterware sait vérifier l’état d’une ressource, la stopper et la redémarrer localement ou sur un autre serveur du cluster.
• Pas besoin d’un système de fichiers cluster (CFS) dès lors que nous sommes en actif/passif et pas en accès concurrent aux données. La base de données utilise un système de fichiers classique supporté par le clusterware. Ses partitions de disques sont alors elles-mêmes configurées en ressources du clusterware, démontées du nœud actif, puis remontées sur l’autre nœud en cas de bascule du service sur incident (“failover”).
• Un lien d’interconnexion privé et des disques de vote restent essentiels au fonctionnement du cluster.

Sous système UNIX, les produits “clusterware” existant et supportant Oracle sont nombreux, citons par exemple Veritas et son cluster VCS, ou HP et son cluster Serviceguard.

Sous système MS Windows, Microsoft Failover Cluster (MSFC) est bien connu des DBA SQL Server, s’agissant de la couche cluster essentielle à la mise en œuvre de l’architecture de haute disponibilité “AlwaysOn” pour SQL Server.

Et qu’en est il du support de MSFC par Oracle?

Oracle supporte le clusterware “Failover Cluster” de Microsoft. Ainsi une instance de base de données Oracle peut être prise en charge par le clusterware sur un cluster de plusieurs serveurs/nœuds (typiquement deux) de sorte à ce que celle-ci puisse être redémarrée sur le second serveur en cas de défaillance sur le premier. Cependant, cela nécessite le composant Oracle Fail Safe, proposé par Oracle pour la compatibilité avec MSFC. Fail Safe permet l’intégration des produits du serveur Oracle en ressources gérés par MSFC, soit à minima:

• L’instance de base de données.
• Le LISTENER. Celui-ci écoute sur un port ouvert sur une adresse IP virtuelle (VIP), elle même ressource du cluster.

En plus de la VIP, les partitions de disque utilisées par la base de données sont elles-mêmes des ressources système (non-Oracle) gérées par MSFC, pouvant être démontées d’un nœud puis remontées sur le second en cas de défaillance. La dépendance des ressources système (partitions NTFS et VIP) avec les ressources Oracle est gérée par le couple MSFC/Fail Safe.

Fail Safe se présente comme une surcouche Oracle de MSFC, légère et facile à installer. Oracle maintient cette solution gratuite et peu connue. La dernière version 4.2.1 est compatible avec Oracle Database standard et enterprise, version 12cR2 bien sûr, mais aussi la toute dernière 18c (ce n’est pas formel sur la page du produit, mais certifié sur https://support.oracle.com).

Pour une telle architecture, il faut nécessairement disposer de deux serveurs configurés ainsi:

• Accès à un stockage partagé en réseau (classiquement un SAN).
• Une interface sur le réseau public.
• Une interface de réseau privé entre les serveurs.
• Une partition de disque NTFS configurée en Quorum du cluster (disque de vote).

Ces configurations sont mises en œuvre avec l’outil d’administration “Failover Cluster Manager” de Microsoft disponible par défaut sur les systèmes Windows en édition server: configuration des réseaux, création du Quorum (en “disk witness”), ajout de partitions de disques en ressources…

Un groupe de ressources appelé “rôle” permet de regrouper des ressources par affinité et leur conférer une gestion commune et une position nominale sur le cluster. Dans un même rôle, nous aurons ainsi un ensemble de disques, les instances de base de données les utilisant et leur LISTENER associé écoutant sur une adresse IP virtuelle, elle même dans ce groupe.

Les rôles auront été préalablement créé avec la console Microsoft Fail Safe Manager, avec pour chacun un nom, une adresse IP “client access point” correspondant à l’adresse IP virtuelle (VIP) réservée, et les disques parmi ceux ajoutés en ressources qui feront partie de ce groupe.

Quand le cluster est créé et proprement configuré avec Failover Cluster Manager, il s’agit d’installer les logiciels Oracle :

• Oracle Database sur chaque nœud (en édition standard par exemple),
• Puis Oracle Fail Safe avec application du dernier patchset connu.

Une fois votre base de données créée depuis le premier serveur, ainsi qu’un premier LISTENER local (écoutant sur l’interface physique et le port de votre choix), Fail Safe Manager vous permettra d’ajouter les ressources Oracle à celles gérées par MSFC:

• Valider la base de données créée.
• Ajouter l’instance de base de données en ressource du groupe de ressources du cluster en précisant son fichier de paramètres SPFILE. le groupe, terme utilisé par Fail Safe, correspond à un des rôles précédemment créés.

L’ajout d’une première instance de base de données à un groupe/rôle de ressources crée automatiquement un LISTENER sur l’adresse IP virtuelle du rôle, LISTENER lui-même ressource de ce groupe/rôle.

Les groupes/rôles autorisent une approche consolidée sur un même cluster. En effet, il est intéressant de songer à livrer plusieurs instances de bases de données sur un même cluster “MS Failover Cluster/Oracle Fail Safe” en les répartissant sur minimum deux rôles distincts, chacun ayant une position nominale sur deux nœuds distincts. La possibilité de basculement des ressources d’un rôle sur l’autre nœud oblige à réserver les ressources matérielles de sorte à ce que chaque nœud puisse supporter la charge de la totalité des instances à un instant T. Un avantage est de pouvoir rationaliser les partitions de disque partagées par les instances multiples du rôle.

J’ai accompagné un client suivant cette approche. Il souhaitait regrouper par affinité applicative ses bases 12c en édition SE2 ; et misait avant tout sur les objectifs de disponibilité élevée du service et de maintenances facilitées sur les serveurs. Les données, qui ne nécessitaient pas une solution “zero data loss”, étaient protégées par une infra RMAN(avec catalogue)+NetBackup et la possibilité de restauration sur un site de DRP géographique sans cluster (la copie temps réelle des sauvegardes étant configurée sur NetBackup).

Une autre approche peut aussi consister à vouloir isoler les services entièrement les uns des autres. Dans ce cas précis, on créera autant de rôles qu’il existe d’instances de bases de données avec leur propre IP virtuelle, leur LISTENER et leur propre ensemble de partitions de disque. Cette approche est la plus chère en terme de provision de ressources mais aussi la plus granuleuse et la plus fine en matière d’isolation et de maintenance. Une instance et ses ressources associées, à travers son rôle, peut basculer ou être déplacée sans entrainer toute autre instance et ses ressources propres avec elle.

En conclusion :

Une architecture “MS Failover Cluster/Oracle Fail Safe” est une bonne solution relativement aisée à mettre en œuvre, en particulier au sein des DSI qui ont les cluster Microsoft FC dans leur catalogue de solutions. C’est une réponse au besoin de disponibilité élevé du service associé à l’instance de base de données. Pas plus que la solution RAC, elle n’apporte de réponse la protection des données, un plan de sauvegarde avec réseau et infrastructure dédiés reste préconisée à minima et au mieux une solution de réplication. La capacité offerte par le RAC de répartir une charge “scalable” d’une même base de données sur plusieurs instances ouvertes n’est évidemment pas permise par un cluster “Fail Safe” (pas plus que sur tout autre clusterware de type actif/passif). Mais le bon usage des groupes de ressources (rôles) autorise une exploitation rationalisée et consolidée des ressources matérielles en installant plusieurs instances de bases de données que l’on répartit au mieux sur le cluster au sein de plusieurs groupes (à créer selon des affinités de services applicatifs par exemple).

Pour aller plus loin, le la documentation Oracle dont sont extraites les copies d’écran.

 

 

Continuez votre lecture sur le blog :

• Oracle 19c High Availabality : une solution de haute disponibilité à moindre coût. (Emmanuel RAMI) [Oracle]
• Groupe de disponibilité AlwaysOn multisubnet et problème de connectivité sous Windows 2008 R2 / 7 (Vincent Delabre) [Operating SystemSQL Server]
• Les Managed Service Account (MSA et gMSA) : se simplifier la vie pour gérer ses comptes de service SQL Server (Vincent Delabre) [Operating SystemSQL Server]
• Installation d’Oracle Database 18c sous Oracle Enterprise Linux (OEL) ou Red Hat Enterprise Linux (RHEL) par packages RPM (Capdata team) [Oracle]
• Installation Oracle 11gR2 64 bits sur Red Hat 5 Partie 1 (Capdata team) [Oracle]