J'ai récemment rencontré un certain nombre de questions sur les adresses IP virtuelles (VIP) pour Oracle RAC. J'espère que cet article de blog pourra aider à faire la lumière sur ce qu'est un VIP, comment il fonctionne et pourquoi Oracle RAC les exploite. Avant d'aller plus loin, je dois expliquer que je ne suis pas un spécialiste du réseau. En fait, la mise en réseau informatique est probablement mon point le plus faible de tout ce qui se passe dans les magasins informatiques. Alors ne m'enflammez pas si je n'obtiens pas entièrement les trucs de réseautage, précis à 100%. Je vais l'expliquer en termes qui m'ont bien servi dans ma carrière de DBA, en particulier en travaillant avec Oracle RAC.
La plupart des gens sont habitués à connecter n'importe quelle application, SQL*Plus ou autres, à un serveur de base de données à instance unique. Au final, leur demande de connexion est envoyée à une adresse IP spécifique. Dans notre schéma ci-dessous, l'utilisateur final souhaite se connecter à 192.168.1.1 pour accéder à la base de données. La requête réseau est acheminée vers le commutateur réseau auquel ce serveur de base de données est connecté. Ce commutateur transmet la demande au serveur qui possède l'adresse IP demandée.
La plupart des DBA Oracle n'ont aucun problème à comprendre ce concept. La vie devient un peu plus compliquée lorsque RAC est déployé car il y a plusieurs machines (nœuds) dans le cluster. Dans le diagramme suivant, nous avons un cluster RAC à deux nœuds, chaque nœud ayant une adresse IP différente.
L'utilisateur final ne se soucie pas du nœud auquel sa session est connectée. L'utilisateur final souhaite simplement accéder au cluster. L'un ou l'autre nœud suffira. La configuration TNSNAMES.ORA de l'utilisateur final peut dire d'essayer d'abord 192.168.1.1 et si cela ne fonctionne pas, essayez 192.168.1.2 à la place. De cette manière, Oracle RAC fournit une solution de haute disponibilité.
Nous arrivons maintenant à toute la raison pour laquelle les adresses IP virtuelles doivent être utilisées. Que faire si l'utilisateur final tente d'accéder au premier nœud (192.168.1.1) mais qu'il n'est pas disponible ? Le nœud est en panne pour une raison quelconque. L'utilisateur final peut facilement se connecter au nœud 192.168.1.2. Cependant, en raison du fonctionnement des réseaux TCP/IP, il peut s'écouler jusqu'à dix minutes avant que la connexion réseau à 192.168.1.1 expire avant que 192.168.1.2 ne soit accessible. La longue attente du délai d'attente TCP/IP est la seule raison pour laquelle Oracle RAC exploite les VIP. Nous voulons simplement réduire le temps d'accès à un autre nœud du cluster si le nœud demandé n'est pas disponible.
Une adresse IP traditionnelle est généralement liée à la carte réseau du serveur. L'administrateur informatique configurera le serveur pour qu'il utilise toujours cette adresse IP spécifique et aucun autre périphérique du réseau n'utilisera la même adresse IP. Remarque :J'essaie de simplifier les choses ici et d'éviter l'enregistrement DHCP et le bail pour ceux qui connaissent les sujets.
Une adresse IP virtuelle n'est pas liée à la carte réseau. Ce n'est même pas défini dans le système d'exploitation. Le VIP n'est pas une véritable adresse IP, de la même manière qu'une machine virtuelle n'est pas un véritable système. Il semble juste être réel pour ceux qui l'utilisent. Regardons donc notre cluster à deux nœuds, mais cette fois avec des VIP définis pour eux.
Nos serveurs ont toujours leurs adresses IP habituelles, 192.168.1.1 et 192.168.1.2 pour NODE1 et NODE2 respectivement. Ces deux nœuds sont également associés à des VIP. NODE1-VIP et NODE2-VIP sont désignés par les adresses IP 192.168.1.11 et 192.168.1.12 respectivement. Chaque nœud du cluster RAC a son adresse IP normale et un VIP. Il peut également être utile de savoir que le nom d'hôte et les noms VIP sont souvent définis dans DNS afin que nous n'ayons pas à nous souvenir spécifiquement des adresses IP.
Notez que l'utilisateur final demande maintenant à accéder à l'un des VIP. Les seules personnes qui devraient utiliser ces adresses IP traditionnelles sont les administrateurs informatiques qui doivent effectuer des travaux sur le serveur. Les utilisateurs finaux et toutes les applications doivent se connecter au VIP.
Rappelez-vous que j'ai dit plus tôt que le VIP n'est même pas défini dans le système d'exploitation ? Eh bien, si c'est le cas, alors comment tout sait-il que le VIP est affecté à ce nœud ? Tout cela est géré par Grid Infrastructure (GI). Lorsque GI est installé, l'un des écrans Oracle Universal Installer (OUI) demandera les noms des nœuds du cluster (les noms d'hôte) ainsi que le nom d'hôte virtuel. La capture d'écran ci-dessous montre à quoi ressemblait l'installation 11g GI lors de la demande de ces informations (capture d'écran de la documentation Oracle).
Le nom d'hôte public est configuré dans le système d'exploitation par l'administrateur. L'adresse IP virtuelle n'est pas configurée dans le système d'exploitation, mais Grid Infrastructure le sait. Pour comprendre comment cela fonctionne, nous devons faire une petite digression et comprendre le protocole de résolution d'adresse (ARP).
Lorsqu'un serveur est démarré et que ses composants réseau sont lancés, le protocole de résolution d'adresse est le mécanisme qui indique au commutateur devant le serveur d'acheminer tout le trafic pour son adresse IP vers l'adresse MAC de sa carte réseau. Le système d'exploitation, via ARP, indique au commutateur d'aller à NODE1 pour les requêtes 192.168.1.1.
Lorsque Grid Infrastructure démarre, l'une de ses tâches de démarrage consiste à faire quelque chose de similaire. GI, via ARP, indique au commutateur d'aller à NODE1 pour toutes les demandes NODE1-VIP (192.168.1.11). Jusqu'à ce que GI démarre le VIP, cette adresse VIP n'est pas routable.
Maintenant, voici la partie magique… lorsque NODE1 tombe en panne, GI sur un autre nœud du cluster détectera la panne. GI effectuera alors une nouvelle opération ARP qui informe le commutateur d'acheminer le VIP vers un autre nœud du cluster. Parce que le VIP est virtuel, il peut être réacheminé à la volée. Dans le diagramme ci-dessous, NODE1 a échoué. Son adresse IP traditionnelle n'est plus disponible non plus. GI a ré-ARP envoyé le VIP au nœud restant dans le cluster.
Le re-ARPing du VIP peut être accompli en quelques secondes. L'utilisateur final peut éprouver une brève pause dans sa communication réseau entre l'application et l'instance de base de données, mais c'est beaucoup, beaucoup moins que si nous attendions les délais d'attente TCP/IP.
Oracle 11gR2 a introduit les écouteurs SCAN. Un cluster Oracle RAC peut avoir au maximum trois écouteurs SCAN. Le nom SCAN est toujours dans le DNS, mais le DNS effectuera une rotation circulaire de la résolution du nom SCAN vers l'une des trois adresses IP différentes.
Dans le diagramme ci-dessous, notre cluster à deux nœuds a maintenant deux écouteurs SCAN. L'utilisateur final fait une demande de connexion à my-scan.acme.com et DNS résout le nom en 192.168.1.21 ou 192.168.1.22.
Comme indiqué ci-dessus, ces deux VIP SCAN sont affectés à différents nœuds du cluster. Si NODE1 tombe en panne, Grid Infrastructure déplacera à la fois NODE1-VIP et MY-SCAN (192.168.1.21) vers un nœud survivant du cluster, via la même opération de ré-ARP dont nous avons parlé plus tôt. Les nouveaux auditeurs SCAN et leurs VIP sont traités de la même manière que les VIP de l'ancien style.
Pour récapituler, les adresses IP virtuelles sont utilisées pour fournir un basculement plus rapide des communications réseau entre l'application et les nœuds du cluster. Le système d'exploitation utilise le protocole de résolution d'adresse pour faire savoir au commutateur réseau qu'il doit acheminer les connexions vers l'hôte. Grid Infrastructure utilise les mêmes opérations ARP pour indiquer au commutateur réseau où acheminer le trafic pour le VIP et le VIP SCAN. Si un nœud tombe en panne, GI re-ARP le VIP et SCAN VIP vers un autre nœud du cluster.
