Je trouve que lorsque les gens conçoivent l'architecture Oracle RAC, ils ne pensent souvent pas à la redondance N+1 dans leurs plans de mise en œuvre. Il y a deux raisons d'implémenter Oracle RAC, la disponibilité et l'évolutivité. Aux fins de cette discussion, je me concentre uniquement sur le côté disponibilité. Si vos déploiements RAC sont uniquement destinés à des raisons d'évolutivité, cette rubrique peut ne pas s'appliquer à vous.
Alors, qu'est-ce que la redondance N+1 ? En termes simples, si vous avez besoin de N unités de quelque chose, à des fins de redondance, vous devriez avoir N + 1 de cet élément. Regardons un serveur de base de données. Il doit avoir une alimentation électrique. C'est une exigence. Sans alimentation électrique en état de marche, le serveur ne fonctionnera pas du tout. Le nombre minimum d'alimentations est de 1. Si nous voulons que ce serveur ait un haut degré de disponibilité, nous veillerons à ce qu'il dispose d'alimentations N+1, ou dans ce cas, d'alimentations doubles. S'il n'y a qu'une seule alimentation et qu'elle tombe en panne, elle entraîne le serveur avec elle. Si nous avons une alimentation supplémentaire, une unité de rechange, la perte d'une alimentation ne fera pas tomber le serveur avec elle. La redondance est une excellente chose et un composant essentiel d'une infrastructure à haute disponibilité.
Lors de la conception d'un système Oracle RAC, le DBA doit déterminer le nombre de nœuds nécessaires pour répondre aux demandes de l'utilisateur final. Si le DBA détermine que 4 nœuds sont nécessaires et que ce cluster RAC doit présenter des caractéristiques de haute disponibilité, il est alors vital pour le DBA de créer un cluster de 5 nœuds (4+1). Si les demandes de ressources sont suffisantes pour occuper 4 nœuds et qu'un nœud est perdu, les 3 nœuds restants ne pourront pas suivre la charge de travail. Si le DBA construit le système RAC avec la capacité N+1 à l'esprit, la perte d'un nœud ne sera pas perceptible par les utilisateurs finaux. Si le DBA construit le cluster RAC sans redondance N + 1, la perte d'un nœud peut être si terrible pour les performances de l'utilisateur final que le cluster entier peut tout aussi bien être en panne. Lors de la conception de vos implémentations RAC, efforcez-vous d'obtenir une redondance N+1.
Je me souviens qu'il y a deux ans, j'avais un cluster RAC qui avait perdu un nœud. Pas de problème, nous avions encore deux nœuds disponibles. En observant les performances des deux nœuds restants, ils semblaient assez dépassés. Notre centre d'appel a commencé à recevoir des plaintes. J'ai travaillé avec d'autres administrateurs de l'équipe informatique pour remettre ce nœud en marche le plus rapidement possible, mais ce n'est pas toujours le cas si la raison de la panne est liée au matériel et que des pièces doivent être remplacées. Une fois le nœud remis en service, j'ai surveillé les performances du cluster pendant des semaines plus tard. Notre utilisation a augmenté depuis la conception initiale de ce système. Nous avions initialement conçu ce système en pensant à la redondance N+1, mais notre utilisation a augmenté et N est passé de 2 à 3. Notre cluster actuel à 3 nœuds n'était plus redondant N+1. J'ai donc travaillé avec la direction pour investir dans le budget de l'année prochaine suffisamment de fonds pour acheter un nouveau nœud et m'assurer qu'Oracle y était autorisé. Je dors beaucoup mieux la nuit sachant que je suis revenu à la redondance N+1.
Comme de nombreuses implémentations, mon système RAC n'est pas la seule fonctionnalité de haute disponibilité intégrée à notre infrastructure. Cette base de données RAC est une base de données principale d'une base de données de secours physique avec Oracle Data Guard. Je suis surpris lorsque je discute des bases de données de secours RAC avec d'autres DBA Oracle combien d'entre eux ne pensent pas à la capacité N + 1 pour leur veille. La base de données de secours physique est mon filet de sécurité au cas où le centre de données principal serait indisponible pour une raison quelconque. J'ai vu tant d'administrateurs de base de données Oracle implémenter une seule instance de secours pour un RAC principal à plusieurs nœuds. Aie! J'espère qu'ils n'auront jamais à échouer. L'ensemble de la charge de travail de leur cluster RAC multi-nœuds aura beaucoup de mal sur cette seule instance de secours. Ainsi, lorsque vous concevez vos implémentations RAC pour le primaire et le secours, tenez compte de vos implications de redondance N+1 sur la conception de l'architecture.
Là où je diffère probablement de beaucoup de gens, c'est que mes implémentations de secours physique ne sont pas capables de N + 1, mais plutôt de N. Je saute le nœud supplémentaire redondant pour mon secours physique. Pourquoi donc? Purement du point de vue des coûts. Ma réserve physique n'est qu'un filet de sécurité. Je veux qu'il fonctionne pour moi le jour où j'en ai besoin. Mais j'espère ne jamais en avoir besoin. La réserve physique est ma police d'assurance au cas où le risque deviendrait réalité. Pour moi, ce "+1" supplémentaire sur le site de secours est une surassurance. Je peux économiser sur le matériel physique et les licences Oracle.
Alors disons que le jour vient et que je bascule vers le standby. J'ai perdu mon licenciement N+1. Mais quelles sont les chances que je perde le centre de données principal *et* l'un des nœuds de mon cluster de secours ? Chances assez minces. La probabilité de pannes sur deux sites en même temps est assez faible. À ce stade, notre équipe informatique évalue pourquoi notre centre de données principal est perdu et quand nous pouvons très probablement retourner nos opérations à cette installation. Si le centre de données principal a perdu toute son alimentation et que la société de services publics déclare que le service sera rétabli d'ici demain, nous fonctionnerons simplement au centre de données de secours, même si nous n'avons que N nœuds pour la base de données RAC là-bas. Cependant, si le centre de données principal a été anéanti par un incendie, il faudra plusieurs mois avant qu'il ne soit à nouveau opérationnel. C'est à ce stade que je dois prévoir d'obtenir cette redondance physique jusqu'à N + 1, car notre temps d'utilisation de cette veille comme primaire sera beaucoup plus long. Nous nous précipitons donc pour commander un autre serveur et l'ajouter au cluster dès que possible. Je conçois donc ma base de données RAC de secours comme N, et non N + 1, en vue de l'augmenter rapidement à N + 1 si nous déterminons que nous utiliserons la veille pour de vrai pendant une plus longue période.
Il y a donc un autre cas particulier dont j'aimerais discuter. C'est là que le DBA détermine que N=1. Pour les exigences de charge de travail actuelles, un nœud suffit. Mais nous voulons avoir une haute disponibilité, nous concevons donc un cluster RAC à deux nœuds pour la base de données principale. Nous avons maintenant une redondance N+1 intégrée au primaire. Suite à mon dernier paragraphe, ma base de données de secours n'a besoin que d'un nœud. L'erreur que certaines personnes commettent est de créer la base de données de secours en tant que base de données à instance unique. Jusqu'à présent, leur logique a du sens. Le primaire est N+1 et le standby est N. Jusqu'ici tout va bien. Là où je diffère, c'est que je fais du standby un cluster RAC à un nœud, pas une pure implémentation à instance unique. La raison en est la croissance future. À un moment donné, le DBA peut constater que N n'est plus égal à 1 au primaire. L'utilisation a augmenté et N doit être 2 maintenant. Le DBA veut faire passer le nœud principal à 3 nœuds (2+1). Ceci est facilement interrompu sans temps d'arrêt pour ajouter un nouveau nœud au cluster et étendre la base de données RAC à ce nouveau nœud. Mais ce n'est pas si facile à faire au niveau du standby pour faire du standby un cluster à 2 nœuds si ce 1 nœud qui existe n'est pas activé par RAC. Si une seule instance de secours pure est tout ce qui existe, le DBA doit la supprimer et la déplacer vers un cluster à deux nœuds. Si l'administrateur de base de données a été prévoyant et a installé l'infrastructure de grille comme si la réserve physique était un cluster à nœud unique, tout ce que l'administrateur de base de données a à faire est d'ajouter un nouveau nœud, comme il l'a fait du côté principal.
Lorsque vous concevez vos implémentations RAC, pensez à vous assurer que vous avez la capacité N+1 sur le primaire et au moins N sur le standby. Si une entreprise détermine que la réserve est trop critique, elle peut également vouloir mettre en œuvre N+1 sur la réserve. Si le DBA détermine que N=1, envisagez de mettre en veille au moins un cluster RAC à un seul nœud.
