![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a><\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a>Quand on \u00e9voque le besoin de haute disponibilit\u00e9 d’instances de bases de donn\u00e9es Oracle (mais comme pour tout SGBD), il y a au moins deux axes:<\/p>\n
Parmi moult solutions propos\u00e9es par Oracle, on pense commun\u00e9ment \u00e0 Data Guard pour la protection des donn\u00e9es et les bases de donn\u00e9es en cluster Oracle RAC sous clusterware “Grid Infrastructure” pour la disponibilit\u00e9 du service. Par ailleurs, cette combinaison est historiquement celle propos\u00e9e par Oracle pour aller vers les architectures dites de maximum disponibilit\u00e9 (Maximum Availability Architecture, ou “MAA”). Cela va sans le dire, et ce n’est pas l’objet de cet article, la dimension du co\u00fbt 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\u00e9mentation. Rappelons juste qu’Oracle RAC reste accessible en \u00e9dition standard \u00e0 condition d’utiliser ASM et sous une limite de deux sockets sur la totalit\u00e9 de l’architecture, soit deux serveurs et un socket par serveur (limitation de la licence Standard Edition 2 ou”SE2″).<\/p>\n
La solution de bases de donn\u00e9es en cluster RAC sous grid insfrastructure serait une forme de panac\u00e9e, en tout cas d’id\u00e9al en mati\u00e8re d’architecture de bases de donn\u00e9es en cluster. En effet, son atout majeur par rapport \u00e0 la plupart des offres “cluster de SGBD” r\u00e9side dans sa capacit\u00e9 \u00e0 mettre en \u0153uvre une seule base de donn\u00e9es en cluster mais disponible simultan\u00e9ment sur minimum deux serveurs, donc deux instances ouvertes et accessibles \u00e0 travers des services de connexion. Ainsi, en plus de permettre la disponibilit\u00e9 maximale d’un de ces services en cas de d\u00e9faillance d’un des n\u0153uds (minimum souhait\u00e9 \u00e0 travers un cluster), RAC permet d’avoir plusieurs instances actives autorisant la r\u00e9partition de la charge en base (“load balancing”) et de l’\u00e9volutivit\u00e9 en mati\u00e8re de capacit\u00e9\u00a0 (“scalability”, traduit en fran\u00e7ais par “scalabilit\u00e9”). Ces possibilit\u00e9s reposent, entre autres, sur l’usage d’un syst\u00e8me de fichiers en cluster (syst\u00e8mes CFS, le choix naturel \u00e9tant Oracle ASM) et l’impl\u00e9mentation par Oracle de son cache global inter-instances utilisant l’interconnexion entre les n\u0153uds. L’interconnexion sert en premier lieu \u00e0 “Grid Infrastructure” pour la maintenance des n\u0153uds au sein du cluster (heartbeat compl\u00e9mentaire \u00e0 celui impl\u00e9ment\u00e9 au niveau du stockage partag\u00e9 via les disques de vote).<\/p>\n
Le principe m\u00eame de cluster est des plus vastes, celui-ci d\u00e9signant avant tout le regroupement de plusieurs serveurs pour rendre un m\u00eame service (cluster se traduisant par “grappe” de serveurs) et am\u00e9liorer la r\u00e9silience en cas de panne de l’un des serveurs. Ainsi et selon les SGBD, la base de donn\u00e9es sous-jacente peut \u00eatre unique, comme multiple, si la mise en cluster repose sur une solution de r\u00e9plication multi-directionnelle ou encore de partitionnement (sharding)…<\/p>\n
En mati\u00e8re de conseil, on ne saurait orienter un client vers la solution RAC sous le seul pr\u00e9texte que c’est r\u00e9put\u00e9 solide, fiable et \u00e9volutif, sans mettre en exergue quelques contraintes. A titre d’exemple, ne retenons que celles-ci :<\/p>\n
Admettons que les comp\u00e9tences, moyennant un \u00e9ventuel accompagnement, ne sont pas un souci (en sachant quand m\u00eame que les d\u00e9ploiements de bases en RAC sur des infrastructures sous syst\u00e8me Windows sont moins pris\u00e9es). Il reste la compatibilit\u00e9 applicative et l’effort \u00e9ventuel de mise en conformit\u00e9. Pour pallier \u00e0 cela et migrer en douceur, on peut cr\u00e9er des services d’acc\u00e8s \u00e0 notre base de donn\u00e9es en “preferred” sur une seule instance, et ainsi utiliser le cluster RAC en mode actif\/passif \u00e0 travers ces services.<\/p>\n
Mais revenons au point de d\u00e9part de tout projet de haute disponibilit\u00e9 :<\/strong> 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\u00e9 du “service de base de donn\u00e9es”, de nombreuses solutions de clusterware “actif\/passif” existent sur le march\u00e9 et sont compatibles avec Oracle Database. Les points communs de ces solutions sont:<\/p>\n Sous syst\u00e8me UNIX, les produits “clusterware” existant et supportant Oracle sont nombreux, citons par exemple Veritas <\/strong>et son cluster VCS<\/strong>, ou HP<\/strong> et son cluster Serviceguard<\/strong>.<\/p>\n Sous syst\u00e8me MS Windows, Microsoft Failover Cluster (MSFC)<\/strong> est bien connu des DBA SQL Server, s’agissant de la couche cluster essentielle \u00e0 la mise en \u0153uvre de l’architecture de haute disponibilit\u00e9 “AlwaysOn” pour SQL Server<\/strong>.<\/p>\n Et qu’en est il du support de MSFC par Oracle?<\/strong><\/p>\n Oracle supporte le clusterware “Failover Cluster” de Microsoft. Ainsi une instance de base de donn\u00e9es Oracle peut \u00eatre prise en charge par le clusterware sur un cluster de plusieurs serveurs\/n\u0153uds (typiquement deux) de sorte \u00e0 ce que celle-ci puisse \u00eatre red\u00e9marr\u00e9e sur le second serveur en cas de d\u00e9faillance sur le premier. Cependant, cela n\u00e9cessite le composant Oracle Fail Safe<\/strong>, propos\u00e9 par Oracle pour la compatibilit\u00e9 avec MSFC. Fail Safe permet l’int\u00e9gration des produits du serveur Oracle en ressources g\u00e9r\u00e9s par MSFC, soit \u00e0 minima:<\/p>\n En plus de la VIP, les partitions de disque utilis\u00e9es par la base de donn\u00e9es sont elles-m\u00eames des ressources syst\u00e8me (non-Oracle) g\u00e9r\u00e9es par MSFC, pouvant \u00eatre d\u00e9mont\u00e9es d’un n\u0153ud puis remont\u00e9es sur le second en cas de d\u00e9faillance. La d\u00e9pendance des ressources syst\u00e8me (partitions NTFS et VIP) avec les ressources Oracle est g\u00e9r\u00e9e par le couple MSFC\/Fail Safe<\/strong>.<\/p>\n Fail Safe se pr\u00e9sente comme une surcouche Oracle de MSFC, l\u00e9g\u00e8re et facile \u00e0 installer. Oracle maintient cette solution gratuite et peu connue. La derni\u00e8re version 4.2.1 est compatible avec Oracle Database standard et enterprise, version 12cR2<\/a> bien s\u00fbr, mais aussi la toute derni\u00e8re 18c (ce n’est pas formel sur la page du produit, mais certifi\u00e9 sur https:\/\/support.oracle.com).<\/p>\n Pour une telle architecture, il faut n\u00e9cessairement disposer de deux serveurs configur\u00e9s ainsi:<\/p>\n Ces configurations sont mises en \u0153uvre avec l’outil d’administration “Failover Cluster Manager”<\/strong> de Microsoft disponible par d\u00e9faut sur les syst\u00e8mes Windows en \u00e9dition server: configuration des r\u00e9seaux, cr\u00e9ation du Quorum (en “disk witness”), ajout de partitions de disques en ressources…<\/p>\n Un groupe de ressources appel\u00e9 “r\u00f4le<\/strong>” permet de regrouper des ressources par affinit\u00e9 et leur conf\u00e9rer une gestion commune et une position nominale sur le cluster. Dans un m\u00eame r\u00f4le, nous aurons ainsi un ensemble de disques, les instances de base de donn\u00e9es les utilisant et leur LISTENER associ\u00e9 \u00e9coutant sur une adresse IP virtuelle, elle m\u00eame dans ce groupe.<\/p>\n Les r\u00f4les auront \u00e9t\u00e9 pr\u00e9alablement cr\u00e9\u00e9 avec la console Microsoft Fail Safe Manager, avec pour chacun un nom, une adresse IP “client access point” correspondant \u00e0 l’adresse IP virtuelle (VIP) r\u00e9serv\u00e9e, et les disques parmi ceux ajout\u00e9s en ressources qui feront partie de ce groupe.<\/p>\n Quand le cluster est cr\u00e9\u00e9 et proprement configur\u00e9 avec Failover Cluster Manager, il s’agit d’installer les logiciels Oracle :<\/p>\n Une fois votre base de donn\u00e9es cr\u00e9\u00e9e depuis le premier serveur, ainsi qu’un premier LISTENER local (\u00e9coutant sur l’interface physique et le port de votre choix), Fail Safe Manager<\/strong> vous permettra d’ajouter les ressources Oracle \u00e0 celles g\u00e9r\u00e9es par MSFC:<\/p>\n L’ajout d’une premi\u00e8re instance de base de donn\u00e9es \u00e0 un groupe\/r\u00f4le de ressources cr\u00e9e automatiquement un LISTENER sur l’adresse IP virtuelle du r\u00f4le, LISTENER lui-m\u00eame ressource de ce groupe\/r\u00f4le.<\/p>\n Les groupes\/r\u00f4les autorisent une approche consolid\u00e9e sur un m\u00eame cluster.<\/strong> En effet, il est int\u00e9ressant de songer \u00e0 livrer plusieurs instances de bases de donn\u00e9es sur un m\u00eame cluster “MS Failover Cluster\/Oracle Fail Safe” en les r\u00e9partissant sur minimum deux r\u00f4les distincts, chacun ayant une position nominale sur deux n\u0153uds distincts. La possibilit\u00e9 de basculement des ressources d’un r\u00f4le sur l’autre n\u0153ud oblige \u00e0 r\u00e9server les ressources mat\u00e9rielles de sorte \u00e0 ce que chaque n\u0153ud puisse supporter la charge de la totalit\u00e9 des instances \u00e0 un instant T. Un avantage est de pouvoir rationaliser les partitions de disque partag\u00e9es par les instances multiples du r\u00f4le.<\/p>\n J’ai accompagn\u00e9 un client suivant cette approche. Il<\/span> souhaitait regrouper par affinit\u00e9 applicative<\/span> ses bases 12c en \u00e9dition SE2 ; et misait avant tout sur les objectifs de disponibilit\u00e9 \u00e9lev\u00e9e du service et de maintenances facilit\u00e9es sur les serveurs. Les donn\u00e9es, qui ne n\u00e9cessitaient pas une solution “zero data loss”, \u00e9taient prot\u00e9g\u00e9es par une infra RMAN(avec catalogue)+NetBackup et la possibilit\u00e9 de restauration sur un site de DRP g\u00e9ographique sans cluster (la copie temps r\u00e9elle des sauvegardes \u00e9tant configur\u00e9e sur NetBackup).<\/p>\n Une autre approche peut aussi consister \u00e0 vouloir isoler les services enti\u00e8rement les uns des autres.<\/strong> Dans ce cas pr\u00e9cis, on cr\u00e9era autant de r\u00f4les qu’il existe d’instances de bases de donn\u00e9es avec leur propre IP virtuelle, leur LISTENER et leur propre ensemble de partitions de disque. Cette approche est la plus ch\u00e8re en terme de provision de ressources mais aussi la plus granuleuse et la plus fine en mati\u00e8re d’isolation et de maintenance. Une instance et ses ressources associ\u00e9es, \u00e0 travers son r\u00f4le, peut basculer ou \u00eatre d\u00e9plac\u00e9e sans entrainer toute autre instance et ses ressources propres avec elle.<\/p>\n Exemple de ressources r\u00e9parties dans deux r\u00f4les vus comme des serveurs virtuels.<\/p><\/div>\n En conclusion :<\/strong><\/p>\n Une architecture “MS Failover Cluster\/Oracle Fail Safe”<\/strong> est une bonne solution relativement ais\u00e9e \u00e0 mettre en \u0153uvre, en particulier au sein des DSI qui ont les cluster Microsoft FC dans leur catalogue de solutions. C’est une r\u00e9ponse au besoin de disponibilit\u00e9 \u00e9lev\u00e9 du service associ\u00e9 \u00e0 l’instance de base de donn\u00e9es. Pas plus que la solution RAC, elle n’apporte de r\u00e9ponse la protection des donn\u00e9es, un plan de sauvegarde avec r\u00e9seau et infrastructure d\u00e9di\u00e9s reste pr\u00e9conis\u00e9e \u00e0 minima et au mieux une solution de r\u00e9plication. La capacit\u00e9 offerte par le RAC de r\u00e9partir une charge “scalable” d’une m\u00eame base de donn\u00e9es sur plusieurs instances ouvertes n’est \u00e9videmment 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\u00f4les) autorise une exploitation rationalis\u00e9e et consolid\u00e9e des ressources mat\u00e9rielles en installant plusieurs instances de bases de donn\u00e9es que l’on r\u00e9partit au mieux sur le cluster au sein de plusieurs groupes (\u00e0 cr\u00e9er selon des affinit\u00e9s de services applicatifs par exemple).<\/span><\/p>\n Pour aller plus loin, le la documentation Oracle<\/a> dont sont extraites les copies d’\u00e9cran.<\/em><\/strong><\/p>\n <\/p>\n <\/p>\n Quand on \u00e9voque le besoin de haute disponibilit\u00e9 d’instances de bases de donn\u00e9es Oracle (mais comme pour tout SGBD), il y a au moins deux axes: la protection des donn\u00e9es et notre capacit\u00e9 de reprise de celles-ci en cas de… Continuer la lecture \n
\n
\n
\n
\n
![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/01\/failsafemanager-1.png\")
<\/p>\n![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/01\/ressources-cluster.png\")
<\/a><\/a><\/a>","protected":false},"excerpt":{"rendered":"